Re: INFO: rcu detected stall in corrupted (4)
On Fri, Sep 4, 2020 at 8:49 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:0f091e43 netlabel: remove unused param from audit_log_form..
> git tree: net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=14551a7190
> kernel config: https://syzkaller.appspot.com/x/.config?x=61025c6fd3261bb1
> dashboard link: https://syzkaller.appspot.com/bug?extid=aa7d098bd6fa788fae8e
> compiler: gcc (GCC) 10.1.0-syz 20200507
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14eeda2590
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=161472f590
>
> The issue was bisected to:
>
> commit 5a781ccbd19e4664babcbe4b4ead7aa2b9283d22
> Author: Vinicius Costa Gomes
> Date: Sat Sep 29 00:59:43 2018 +
>
> tc: Add support for configuring the taprio scheduler
This still happens. The bisection and repro look correct, the repro
also sets up taprio scheduler;
https://syzkaller.appspot.com/bug?id=7349616606afa3c986c377792f7ccbf9daae1142
Vinicius, could you please take a look? Thanks
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1309647690
> console output: https://syzkaller.appspot.com/x/log.txt?x=1709647690
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+aa7d098bd6fa788fa...@syzkaller.appspotmail.com
> Fixes: 5a781ccbd19e ("tc: Add support for configuring the taprio scheduler")
>
> hrtimer: interrupt took 18040217 ns
> rcu: INFO: rcu_preempt self-detected stall on CPU
> rcu:0-: (1 ticks this GP) idle=4ae/0/0x1 softirq=7665/7665 fqs=3
> (t=11294 jiffies g=9289 q=363)
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/cedbc405ae81531f%40google.com.
Re: [PATCH 1/3] clocksource/drivers/timer-ti-dm: Fix posted mode status check order
* Grygorii Strashko [210304 20:58]: > On 04/03/2021 09:21, Tony Lindgren wrote: > > When the timer is configured in posted mode, we need to check the write- > > posted status register (TWPS) before writing to the register. ... > > --- a/drivers/clocksource/timer-ti-dm-systimer.c > > +++ b/drivers/clocksource/timer-ti-dm-systimer.c > > @@ -449,13 +449,13 @@ static int dmtimer_set_next_event(unsigned long > > cycles, > > struct dmtimer_systimer *t = >t; > > void __iomem *pend = t->base + t->pend; > > - writel_relaxed(0x - cycles, t->base + t->counter); > > while (readl_relaxed(pend) & WP_TCRR) > > cpu_relax(); > > + writel_relaxed(0x - cycles, t->base + t->counter); > > - writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl); > > while (readl_relaxed(pend) & WP_TCLR) > > cpu_relax(); > > + writel_relaxed(OMAP_TIMER_CTRL_ST, t->base + t->ctrl); > > It seems static [and inline] helper here could be better solution. no? Well we wanted to get rid of the confusing macros. And in this case I suspect we can eventually do just one read of the pending register for the registers used mask rather than check the status separately multiple times. But that needs to be carefully tested and is not a fix :) Regards, Tony
Re: [RFC PATCH 1/5] rpmb: add Replay Protected Memory Block (RPMB) subsystem
On Thu, Mar 04, 2021 at 09:56:24PM +0100, Arnd Bergmann wrote: > On Wed, Mar 3, 2021 at 2:54 PM Alex Bennée wrote: > > > > A number of storage technologies support a specialised hardware > > partition designed to be resistant to replay attacks. The underlying > > HW protocols differ but the operations are common. The RPMB partition > > cannot be accessed via standard block layer, but by a set of specific > > commands: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. Such a > > partition provides authenticated and replay protected access, hence > > suitable as a secure storage. > > > > The RPMB layer aims to provide in-kernel API for Trusted Execution > > Environment (TEE) devices that are capable to securely compute block > > frame signature. In case a TEE device wishes to store a replay > > protected data, requests the storage device via RPMB layer to store > > the data. > > > > A TEE device driver can claim the RPMB interface, for example, via > > class_interface_register(). The RPMB layer provides a series of > > operations for interacting with the device. > > > > * program_key - a one time operation for setting up a new device > > * get_capacity - introspect the device capacity > > * get_write_count - check the write counter > > * write_blocks - write a series of blocks to the RPMB device > > * read_blocks - read a series of blocks from the RPMB device > > Based on the discussion we had today in a meeting, it seems the > main change that is needed is to get back to the original model > of passing the encrypted data to the kernel instead of cleartext > data, as the main use case we know of is to have the key inside of > the TEE device and not available to the kernel or user space. > Yes, for OP-TEE we have to encrypt all data going to RPMB, since the information goes via non-secure world. We get the integrity by applying the HMAC with the key that is being discussed in this thread. The TEE owns and is responsible for programming the key (and that should be something that is achieved as part of the manufacturing process). > This is also required to be able to forward the encrypted data > through the same interface on a KVM host, when the guest > uses virtio-rpmb, and the host forwards the data into an mmc or > ufs device. > > That said, I can also imagine use cases where we do want to > store the key in the kernel's keyring, so maybe we end up needing > both. > The concern I have in those cases is that you need to share the RPMB key in some way if you need to access the RPMB device from secure side as well as from the non-secure side. Technically doable I guess, but in practice and in terms of security it doesn't seem like a good approach. In a shared environment like that you also have the problem that you need to agree on how to actually store files on the RPMB device. OP-TEE has it's own "FAT-look-a-like" implementation when using RPMB. But if you need mutual access, then you need to get into agreement on where to actually store the files in the RPMB. However, if secure side for some reason doesn't use RPMB at all, then kernel could of course take control of it and use it. I would probably not spend too much time on taking that use case into account until we actually see a real need for it. > > The detailed operation of implementing the access is left to the TEE > > device driver itself. > > > > [This is based-on Thomas Winkler's proposed API from: > > > > > > https://lore.kernel.org/linux-mmc/1478548394-8184-2-git-send-email-tomas.wink...@intel.com/ > > > > The principle difference is the framing details and HW specific > > bits (JDEC vs NVME frames) are left to the lower level TEE driver to > > worry about. The eventual userspace ioctl interface will aim to be > > similarly generic. This is an RFC to follow up on: > > > > Subject: RPMB user space ABI > > Date: Thu, 11 Feb 2021 14:07:00 + > > Message-ID: <87mtwashi4@linaro.org>] > > > > Signed-off-by: Alex Bennée > > Cc: Tomas Winkler > > Cc: Ulf Hansson > > Cc: Linus Walleij > > Cc: Arnd Bergmann > > Cc: Ilias Apalodimas > > --- > > MAINTAINERS| 7 + > > drivers/char/Kconfig | 2 + > > drivers/char/Makefile | 1 + > > drivers/char/rpmb/Kconfig | 11 + > > drivers/char/rpmb/Makefile | 7 + > > drivers/char/rpmb/core.c | 429 + > > include/linux/rpmb.h | 163 ++ > > > My feeling is that it should be a top-level subsystem, in drivers/rpmb > rather than drivers/char/rpmb, as you implement an abstraction layer > that other drivers can plug into, rather than a simple driver. > >Arnd -- Regards, Joakim
Re: [RFC PATCH v1] powerpc: Enable KFENCE for PPC32
On Fri, Mar 05, 2021 at 04:01PM +1100, Michael Ellerman wrote:
> Marco Elver writes:
> > On Thu, Mar 04, 2021 at 12:48PM +0100, Christophe Leroy wrote:
> >> Le 04/03/2021 à 12:31, Marco Elver a écrit :
> >> > On Thu, 4 Mar 2021 at 12:23, Christophe Leroy
> >> > wrote:
> >> > > Le 03/03/2021 à 11:56, Marco Elver a écrit :
> >> > > >
> >> > > > Somewhat tangentially, I also note that e.g. show_regs(regs) (which
> >> > > > was printed along the KFENCE report above) didn't include the top
> >> > > > frame in the "Call Trace", so this assumption is definitely not
> >> > > > isolated to KFENCE.
> >> > > >
> >> > >
> >> > > Now, I have tested PPC64 (with the patch I sent yesterday to modify
> >> > > save_stack_trace_regs()
> >> > > applied), and I get many failures. Any idea ?
> >> > >
> >> > > [ 17.653751][ T58]
> >> > > ==
> >> > > [ 17.654379][ T58] BUG: KFENCE: invalid free in
> >> > > .kfence_guarded_free+0x2e4/0x530
> >> > > [ 17.654379][ T58]
> >> > > [ 17.654831][ T58] Invalid free of 0xc0003c9c (in
> >> > > kfence-#77):
> >> > > [ 17.655358][ T58] .kfence_guarded_free+0x2e4/0x530
> >> > > [ 17.655775][ T58] .__slab_free+0x320/0x5a0
> >> > > [ 17.656039][ T58] .test_double_free+0xe0/0x198
> >> > > [ 17.656308][ T58] .kunit_try_run_case+0x80/0x110
> >> > > [ 17.656523][ T58] .kunit_generic_run_threadfn_adapter+0x38/0x50
> >> > > [ 17.657161][ T58] .kthread+0x18c/0x1a0
> >> > > [ 17.659148][ T58] .ret_from_kernel_thread+0x58/0x70
> >> > > [ 17.659869][ T58]
> > [...]
> >> >
> >> > Looks like something is prepending '.' to function names. We expect
> >> > the function name to appear as-is, e.g. "kfence_guarded_free",
> >> > "test_double_free", etc.
> >> >
> >> > Is there something special on ppc64, where the '.' is some convention?
> >> >
> >>
> >> I think so, see
> >> https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES
> >>
> >> Also see commit https://github.com/linuxppc/linux/commit/02424d896
> >
> > Thanks -- could you try the below patch? You'll need to define
> > ARCH_FUNC_PREFIX accordingly.
> >
> > We think, since there are only very few architectures that add a prefix,
> > requiring to define something like ARCH_FUNC_PREFIX is
> > the simplest option. Let me know if this works for you.
> >
> > There an alternative option, which is to dynamically figure out the
> > prefix, but if this simpler option is fine with you, we'd prefer it.
>
> We have rediscovered this problem in basically every tracing / debugging
> feature added in the last 20 years :)
>
> I think the simplest solution is the one tools/perf/util/symbol.c uses,
> which is to just skip a leading '.'.
>
> Does that work?
>
> diff --git a/mm/kfence/report.c b/mm/kfence/report.c
> index ab83d5a59bb1..67b49dc54b38 100644
> --- a/mm/kfence/report.c
> +++ b/mm/kfence/report.c
> @@ -67,6 +67,9 @@ static int get_stack_skipnr(const unsigned long
> stack_entries[], int num_entries
> for (skipnr = 0; skipnr < num_entries; skipnr++) {
> int len = scnprintf(buf, sizeof(buf), "%ps", (void
> *)stack_entries[skipnr]);
>
> + if (buf[0] == '.')
> + buf++;
> +
Unfortunately this does not work, since buf is an array. We'd need an
offset, and it should be determined outside the loop. I had a solution
like this, but it turned out quite complex (see below). And since most
architectures do not require this, decided that the safest option is to
use the macro approach with ARCH_FUNC_PREFIX, for which Christophe
already prepared a patch and tested:
https://lore.kernel.org/linux-mm/20210304144000.1148590-1-el...@google.com/
https://lkml.kernel.org/r/afaec81a551ef15345cb7d7563b3fac3d7041c3a.1614868445.git.christophe.le...@csgroup.eu
Since KFENCE requires anyway, we'd prefer this approach
(vs. dynamically detecting).
Thanks,
-- Marco
-- >8 --
diff --git a/mm/kfence/report.c b/mm/kfence/report.c
index 519f037720f5..b0590199b039 100644
--- a/mm/kfence/report.c
+++ b/mm/kfence/report.c
@@ -43,8 +43,8 @@ static void seq_con_printf(struct seq_file *seq, const char
*fmt, ...)
static int get_stack_skipnr(const unsigned long stack_entries[], int
num_entries,
const enum kfence_error_type *type)
{
+ int skipnr, fallback = 0, fprefix_chars = 0;
char buf[64];
- int skipnr, fallback = 0;
if (type) {
/* Depending on error type, find different stack entries. */
@@ -64,11 +64,24 @@ static int get_stack_skipnr(const unsigned long
stack_entries[], int num_entries
}
}
+ if (scnprintf(buf, sizeof(buf), "%ps", (void *)kfree)) {
+ /*
+* Some architectures (e.g. ppc64) add a constant prefix to
+* function names. Determine if such a prefix exists.
+*/
+ const char *str =
Re: [PATCH 2/3] clocksource/drivers/timer-ti-dm: Remove extra of_node_put()
* Grygorii Strashko [210304 20:56]: > > > On 04/03/2021 09:21, Tony Lindgren wrote: > > We have of_translate_address() already do of_node_put() as needed. > > I probably looked at __of_translate_address() earlier by accident > > that of_translate_address() uses. > > I do not see of_node_put() in of_translate_address() and > __of_translate_address() is doing of_node_get(dev); > ? Oh right.. this is confusing.. Yeah we can ignore this patch. We should have the use count set for only the system timer(s) we claim. Regards, Tony
[PATCH][next] net: plip: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- drivers/net/plip/plip.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/plip/plip.c b/drivers/net/plip/plip.c index 4406b353123e..e26cf91bdec2 100644 --- a/drivers/net/plip/plip.c +++ b/drivers/net/plip/plip.c @@ -516,6 +516,7 @@ plip_receive(unsigned short nibble_timeout, struct net_device *dev, *data_p |= (c0 << 1) & 0xf0; write_data (dev, 0x00); /* send ACK */ *ns_p = PLIP_NB_BEGIN; + break; case PLIP_NB_2: break; } @@ -808,6 +809,7 @@ plip_send_packet(struct net_device *dev, struct net_local *nl, return HS_TIMEOUT; } } + break; case PLIP_PK_LENGTH_LSB: if (plip_send(nibble_timeout, dev, -- 2.27.0
Re: linux-next: Fixes tag needs some work in the block tree
On Thu, Mar 04, 2021 at 05:26:42PM -0700, Jens Axboe wrote: > Christoph, since there's multiple commits with issues, mind resending > a fixed branch? Then I'll drop the one I pulled today. I've fixed the commit id and dropped the patch without the author signoff, but your branch still has the current patches.
Re: [PATCH v4 02/15] gpio: regmap: set gpio_chip of_node
Hi Andy, > El 4 mar 2021, a las 17:33, Andy Shevchenko > escribió: > > On Thu, Mar 4, 2021 at 5:44 PM Álvaro Fernández Rojas > wrote: >>> El 4 mar 2021, a las 16:28, Andy Shevchenko >>> escribió: >>> On Thu, Mar 4, 2021 at 5:24 PM Álvaro Fernández Rojas >>> wrote: > El 4 mar 2021, a las 16:17, Andy Shevchenko > escribió: > On Thu, Mar 4, 2021 at 5:06 PM Álvaro Fernández Rojas > wrote: >>> El 4 mar 2021, a las 11:35, Andy Shevchenko >>> escribió: >>> On Thu, Mar 4, 2021 at 10:57 AM Álvaro Fernández Rojas >>> wrote: > + * @of_node: (Optional) The device node >>> + struct device_node *of_node; >>> >>> Can we use fwnode from day 1, please? >> >> Could you explain this? I haven’t dealt with fwnode never :$ >> BTW, this is done to fix this check when parsing gpio ranges: >> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpio/gpiolib-of.c#L933-L934 > > Use struct fwnode_handle pointer instead of OF-specific one. But is that compatible with the current gpiolib-of code? :$ >>> >>> Yes (after a bit of amendment I have sent today as v2: >>> https://lore.kernel.org/linux-gpio/20210304150215.80652-1-andriy.shevche...@linux.intel.com/T/#u). >> >> Well that doesn’t fulfill my definition of “current gpiolib-of code”… >> @Linus what should I do about this? > > Well, fwnode is a generic, and I strongly against spreading > OF-specific code when we have fwnode working. But let's hear Linus > out, of course! > > But it seems you are right and the library needs a few more amendments. Yes, but I’m trying to do as few amendments as possible since I already have quite a large amount of patches :) > > Also here is the question, why do you need to have that field in the > regmap config structure and can't simply use the parent's fwnode? > Also I'm puzzled why it's not working w/o this patch: GPIO library > effectively assigns parent's fwnode (okay, of_node right now). Because gpio regmap a child node of the pin controller, which is the one probed (gpio regmap is probed from the pin controller). Therefore the parent’s fwnode is useless, since the correct gpio_chip node is the child's one (we have pin-ranges declared in the child node, referencing the parent pinctrl node). >>> >>> I see. Can you point me out to the code where we get the node and >>> where it's being retrieved / filled? >> >> Sure, this is where the child node is searched: >> https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L100-L109 >> Then the gpio child node is probed and assigned here: >> https://github.com/Noltari/linux/blob/6d1ebb8ff26ed54592eef1fcd3b58834acb48c04/drivers/pinctrl/bcm/pinctrl-bcm63xx.c#L51 > > So, this is not (*yet) in upstream, correct? No it’s not, but I've already changed the approach several times and I’m starting to get tired about it... > > So, why not to switch to fwnode API in that driver as well? > > When you do that and supply fwnode thru the regmap configuration, in > the gpio-regmap we may assign it to of_node (via to_of_node() API). > >> Basically, I based that part of the code on the ingenic pin controller: >> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/pinctrl/pinctrl-ingenic.c#L2485-L2491 >> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/Documentation/devicetree/bindings/pinctrl/ingenic%2Cpinctrl.yaml#L155-L176 > > This doesn't use remgap GPIO. Yes, I know, but there aren’t any pinctrl drivers using regmap GPIO right now, so I couldn’t base my code on anything else :) > > -- > With Best Regards, > Andy Shevchenko Best regards, Álvaro.
arch/powerpc/kvm/book3s_hv_nested.c:218:6: error: stack frame size of 2176 bytes in function 'kvmhv_enter_nested_guest'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 280d542f6ffac0e6d65dc267f92191d509b13b64
commit: cf59eb13e151ef42c37ae31864046c17e481ed8f KVM: PPC: Book3S: Fix symbol
undeclared warnings
date: 5 months ago
config: powerpc-randconfig-r006-20210305 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
4d90e460bcc7b3e5ff6c7e2e05e974772489c4b8)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf59eb13e151ef42c37ae31864046c17e481ed8f
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout cf59eb13e151ef42c37ae31864046c17e481ed8f
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> arch/powerpc/kvm/book3s_hv_nested.c:218:6: error: stack frame size of 2176
>> bytes in function 'kvmhv_enter_nested_guest' [-Werror,-Wframe-larger-than=]
long kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu)
^
1 error generated.
vim +/kvmhv_enter_nested_guest +218 arch/powerpc/kvm/book3s_hv_nested.c
873db2cd9a6d7f Suraj Jitindar Singh 2018-12-14 217
360cae313702cd Paul Mackerras 2018-10-08 @218 long
kvmhv_enter_nested_guest(struct kvm_vcpu *vcpu)
360cae313702cd Paul Mackerras 2018-10-08 219 {
360cae313702cd Paul Mackerras 2018-10-08 220 long int err, r;
360cae313702cd Paul Mackerras 2018-10-08 221 struct kvm_nested_guest
*l2;
360cae313702cd Paul Mackerras 2018-10-08 222 struct pt_regs l2_regs,
saved_l1_regs;
360cae313702cd Paul Mackerras 2018-10-08 223 struct hv_guest_state
l2_hv, saved_l1_hv;
360cae313702cd Paul Mackerras 2018-10-08 224 struct kvmppc_vcore *vc
= vcpu->arch.vcore;
360cae313702cd Paul Mackerras 2018-10-08 225 u64 hv_ptr, regs_ptr;
360cae313702cd Paul Mackerras 2018-10-08 226 u64 hdec_exp;
360cae313702cd Paul Mackerras 2018-10-08 227 s64 delta_purr,
delta_spurr, delta_ic, delta_vtb;
360cae313702cd Paul Mackerras 2018-10-08 228 u64 mask;
360cae313702cd Paul Mackerras 2018-10-08 229 unsigned long lpcr;
360cae313702cd Paul Mackerras 2018-10-08 230
360cae313702cd Paul Mackerras 2018-10-08 231 if
(vcpu->kvm->arch.l1_ptcr == 0)
360cae313702cd Paul Mackerras 2018-10-08 232 return
H_NOT_AVAILABLE;
360cae313702cd Paul Mackerras 2018-10-08 233
360cae313702cd Paul Mackerras 2018-10-08 234 /* copy parameters in */
360cae313702cd Paul Mackerras 2018-10-08 235 hv_ptr =
kvmppc_get_gpr(vcpu, 4);
1508c22f112ce1 Alexey Kardashevskiy 2020-06-09 236 regs_ptr =
kvmppc_get_gpr(vcpu, 5);
1508c22f112ce1 Alexey Kardashevskiy 2020-06-09 237 vcpu->srcu_idx =
srcu_read_lock(>kvm->srcu);
360cae313702cd Paul Mackerras 2018-10-08 238 err =
kvm_vcpu_read_guest(vcpu, hv_ptr, _hv,
1508c22f112ce1 Alexey Kardashevskiy 2020-06-09 239
sizeof(struct hv_guest_state)) ||
1508c22f112ce1 Alexey Kardashevskiy 2020-06-09 240
kvm_vcpu_read_guest(vcpu, regs_ptr, _regs,
1508c22f112ce1 Alexey Kardashevskiy 2020-06-09 241
sizeof(struct pt_regs));
1508c22f112ce1 Alexey Kardashevskiy 2020-06-09 242
srcu_read_unlock(>kvm->srcu, vcpu->srcu_idx);
360cae313702cd Paul Mackerras 2018-10-08 243 if (err)
360cae313702cd Paul Mackerras 2018-10-08 244 return
H_PARAMETER;
1508c22f112ce1 Alexey Kardashevskiy 2020-06-09 245
10b5022db7861a Suraj Jitindar Singh 2018-10-08 246 if
(kvmppc_need_byteswap(vcpu))
10b5022db7861a Suraj Jitindar Singh 2018-10-08 247
byteswap_hv_regs(_hv);
360cae313702cd Paul Mackerras 2018-10-08 248 if (l2_hv.version !=
HV_GUEST_STATE_VERSION)
360cae313702cd Paul Mackerras 2018-10-08 249 return H_P2;
360cae313702cd Paul Mackerras 2018-10-08 250
10b5022db7861a Suraj Jitindar Singh 2018-10-08 251 if
(kvmppc_need_byteswap(vcpu))
10b5022db7861a Suraj Jitindar Singh 2018-10-08 252
byteswap_pt_regs(_regs);
9d0b048da788c1 Suraj Jitindar Singh 2018-10-08 253 if (l2_hv.vcpu_token >=
NR_CPUS)
9d0b048da788c1 Suraj Jitindar Singh 2018-10-08 254 return
H_PARAMETER;
9d0b048da788c1 Suraj Jitindar Singh 2018-10-08 255
360cae313702cd Paul Mackerras 2018-10-08 256 /* translate
[PATCH][next] net: rose: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- net/rose/rose_route.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/rose/rose_route.c b/net/rose/rose_route.c index 6e35703ff353..c0e04c261a15 100644 --- a/net/rose/rose_route.c +++ b/net/rose/rose_route.c @@ -347,6 +347,7 @@ static int rose_del_node(struct rose_route_struct *rose_route, case 1: rose_node->neighbour[1] = rose_node->neighbour[2]; + break; case 2: break; } @@ -508,6 +509,7 @@ void rose_rt_device_down(struct net_device *dev) fallthrough; case 1: t->neighbour[1] = t->neighbour[2]; + break; case 2: break; } -- 2.27.0
[PATCH][next] net: core: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- net/core/dev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/dev.c b/net/core/dev.c index 6c5967e80132..2bfdd528c7c3 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -5265,6 +5265,7 @@ static int __netif_receive_skb_core(struct sk_buff **pskb, bool pfmemalloc, goto another_round; case RX_HANDLER_EXACT: deliver_exact = true; + break; case RX_HANDLER_PASS: break; default: -- 2.27.0
[PATCH][next] firewire: core: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a fallthrough pseudo-keyword. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- drivers/firewire/core-topology.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/firewire/core-topology.c b/drivers/firewire/core-topology.c index ec68ed27b0a5..b63d55f5ebd3 100644 --- a/drivers/firewire/core-topology.c +++ b/drivers/firewire/core-topology.c @@ -58,6 +58,7 @@ static u32 *count_ports(u32 *sid, int *total_port_count, int *child_port_count) case SELFID_PORT_PARENT: case SELFID_PORT_NCONN: (*total_port_count)++; + fallthrough; case SELFID_PORT_NONE: break; } -- 2.27.0
[PATCH][next] net: bridge: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Acked-by: Nikolay Aleksandrov Signed-off-by: Gustavo A. R. Silva --- net/bridge/br_input.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c index 85d9dae2..8875e953ac53 100644 --- a/net/bridge/br_input.c +++ b/net/bridge/br_input.c @@ -144,6 +144,7 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb break; case BR_PKT_UNICAST: dst = br_fdb_find_rcu(br, eth_hdr(skb)->h_dest, vid); + break; default: break; } -- 2.27.0
[PATCH][next] net: ax25: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- net/ax25/af_ax25.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c index 269ee89d2c2b..2631efc6e359 100644 --- a/net/ax25/af_ax25.c +++ b/net/ax25/af_ax25.c @@ -850,6 +850,7 @@ static int ax25_create(struct net *net, struct socket *sock, int protocol, case AX25_P_ROSE: if (ax25_protocol_is_registered(AX25_P_ROSE)) return -ESOCKTNOSUPPORT; + break; #endif default: break; -- 2.27.0
Re: [PATCH v10 5/9] x509: Detect sm2 keys by their parameters OID
Hi,
On 3/5/21 8:51 AM, Stefan Berger wrote:
From: Stefan Berger
Detect whether a key is an sm2 type of key by its OID in the parameters
array rather than assuming that everything under OID_id_ecPublicKey
is sm2, which is not the case.
Cc: David Howells
Cc: keyri...@vger.kernel.org
Signed-off-by: Stefan Berger
Reviewed-by: Tianjia Zhang
---
crypto/asymmetric_keys/x509_cert_parser.c | 12 +++-
include/linux/oid_registry.h | 1 +
lib/oid_registry.c| 13 +
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 52c9b455fc7d..1621ceaf5c95 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -459,6 +459,7 @@ int x509_extract_key_data(void *context, size_t hdrlen,
const void *value, size_t vlen)
{
struct x509_parse_context *ctx = context;
+ enum OID oid;
ctx->key_algo = ctx->last_oid;
switch (ctx->last_oid) {
@@ -470,7 +471,16 @@ int x509_extract_key_data(void *context, size_t hdrlen,
ctx->cert->pub->pkey_algo = "ecrdsa";
break;
case OID_id_ecPublicKey:
- ctx->cert->pub->pkey_algo = "sm2";
+ if (parse_OID(ctx->params, ctx->params_size, ) != 0)
+ return -EBADMSG;
+
+ switch (oid) {
+ case OID_sm2:
+ ctx->cert->pub->pkey_algo = "sm2";
+ break;
+ default:
+ return -ENOPKG;
+ }
break;
default:
return -ENOPKG;
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index b504e2f36b25..f32d91895e4d 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -121,6 +121,7 @@ enum OID {
};
extern enum OID look_up_OID(const void *data, size_t datasize);
+extern int parse_OID(const void *data, size_t datasize, enum OID *oid);
extern int sprint_oid(const void *, size_t, char *, size_t);
extern int sprint_OID(enum OID, char *, size_t);
diff --git a/lib/oid_registry.c b/lib/oid_registry.c
index f7ad43f28579..508e0b34b5f0 100644
--- a/lib/oid_registry.c
+++ b/lib/oid_registry.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "oid_registry_data.c"
MODULE_DESCRIPTION("OID Registry");
@@ -92,6 +93,18 @@ enum OID look_up_OID(const void *data, size_t datasize)
}
EXPORT_SYMBOL_GPL(look_up_OID);
+int parse_OID(const void *data, size_t datasize, enum OID *oid)
+{
+ const unsigned char *v = data;
+
+ if (datasize < 2 || v[0] != ASN1_OID || v[1] != datasize - 2)
+ return -EBADMSG;
+
+ *oid = look_up_OID(data + 2, datasize - 2);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(parse_OID);
+
/*
* sprint_OID - Print an Object Identifier into a buffer
* @data: The encoded OID to print
Tested-by: Tianjia Zhang
Best regards,
Tianjia
[PATCH][next] decnet: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- net/decnet/dn_route.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c index 2193ae529e75..37c90c1fdc93 100644 --- a/net/decnet/dn_route.c +++ b/net/decnet/dn_route.c @@ -1407,7 +1407,7 @@ static int dn_route_input_slow(struct sk_buff *skb) flags |= RTCF_DOREDIRECT; local_src = DN_FIB_RES_PREFSRC(res); - + break; case RTN_BLACKHOLE: case RTN_UNREACHABLE: break; -- 2.27.0
Re: [PATCH] ANDROID: usb: core: Send uevent when USB TOPO layer over 6
On Fri, Mar 05, 2021 at 03:17:37PM +0800, Chien Kun Niu wrote: > Greg KH 於 2021年3月3日 週三 下午5:10寫道： > > > > On Wed, Mar 03, 2021 at 05:03:25PM +0800, Chien Kun Niu wrote: > > > Hi , Greg > > > > > > What tool will "catch" this? Where is that code located at? > > > => I prepare merge the code to Android phone , so I used Android HLOS > > > to catch this uevent. > > > > Very odd quoting style, perhaps you might want to read up on how to do > > this properly at: > > https://en.wikipedia.org/wiki/Posting_style#Interleaved_style > > > > > uevents are not for stuff like this, you are trying to send "error > > > conditions" to userspace, please use the "proper" interfaces like this > > > and not abuse existing ones. > > > => Sorry , I am not sure what is the "proper" interfaces your mean. > > > Could you please give me more description? > > > > How does the kernel normally send error conditions that it detects in > > hardware to userspace? > > > > I will create a sysfs attribute to record the hub status. > If there is a new hub with over 6 USB TOPO layer connected, I will use > the sysfs_notify to send the "error conditions" to userspace. > Is it a proper interfaces to delivery "error conditions"? Maybe, it all depends on what you are wanting to show here. Try it out and see, it's easier to review patches that you have shown work properly for your use case than it is to try to discuss general issues. thanks, greg k-h
Re: [PATCH v9 2/9] x509: Detect sm2 keys by their parameters OID
Hi, On 3/4/21 7:46 AM, Stefan Berger wrote: Tianjia, can you say whether SM2 support works for you before and after applying this patch? I cannot verify it with an sm2 key I have created using a sequence of commands like this: > modprobe sm2_generic > id=$(keyctl newring test @u) > keyctl padd asymmetric "" $id < sm2.der add_key: Key was rejected by service > keyctl padd asymmetric "" $id < eckeys/cert-prime192v1-0.der 88506426 The sm2 key is reject but the pime192v1 key works just fine. SM2 support neither worked for me before nor after this patch here. The difference is that before it returned 'add_key: Package not installed'. This is my sm2 cert: > base64 < sm2.der MIIBbzCCARWgAwIBAgIUfqwndeAy7reymWLwvCHOgYPU2YUwCgYIKoZIzj0EAwIwDTELMAkGA1UE AwwCbWUwHhcNMjEwMTI0MTgwNjQ3WhcNMjIwMTI0MTgwNjQ3WjANMQswCQYDVQQDDAJtZTBZMBMG ByqGSM49AgEGCCqBHM9VAYItA0IABEtiMaczdk46MEugmOsY/u+puf5qoi7JdLd/w3VpdixvDd26 vrxLKL7lCTVn5w3a07G7QB1dgdMDpzIRgWrVXC6jUzBRMB0GA1UdDgQWBBSxOVnE7ihvTb6Nczb4 /mow+HIc9TAfBgNVHSMEGDAWgBSxOVnE7ihvTb6Nczb4/mow+HIc9TAPBgNVHRMBAf8EBTADAQH/ MAoGCCqGSM49BAMCA0gAMEUCIE1kiji2ABUy663NANe0iCPjCeeqg02Yk4b3K+Ci/Qh4AiEA/cFB eJEVklyveRMvuTP7BN7FG4U8iRdtedjiX+YrNio= Regards, Stefan Yes, it works fine here. Your test method may be wrong. First of all, the certificate looks wrong, I don’t know if it is not sent completely. Secondly, the SM2 algorithm must be compiled with builtin. There will be a problem when it is compiled into a module. This is a restriction for SM2 signature with Za. you may refer to this discussion: https://lkml.org/lkml/2021/1/12/1736 In addition, give you a self-signed root certificate for my test: -BEGIN CERTIFICATE- MIICLjCCAdWgAwIBAgIUEoozP6LzMYWh4gCpcWlzsUyfgsIwCgYIKoEcz1UBg3Uw bTELMAkGA1UEBhMCQ04xCzAJBgNVBAgMAkdTMQswCQYDVQQHDAJHdDENMAsGA1UE CgwEYmFiYTELMAkGA1UECwwCT1MxCzAJBgNVBAMMAmNhMRswGQYJKoZIhvcNAQkB FgxjYUB3b3JsZC5jb20wHhcNMjAwNDE1MTE1NDA3WhcNMzAwNDEzMTE1NDA3WjBt MQswCQYDVQQGEwJDTjELMAkGA1UECAwCR1MxCzAJBgNVBAcMAkd0MQ0wCwYDVQQK DARiYWJhMQswCQYDVQQLDAJPUzELMAkGA1UEAwwCY2ExGzAZBgkqhkiG9w0BCQEW DGNhQHdvcmxkLmNvbTBZMBMGByqGSM49AgEGCCqBHM9VAYItA0IABMTGRiHezKm5 MiKHlyfa5Bv5jLxge/WRRG0nLNsZx1yf0XQTQBR/tFFjPGePEr7+Fa1CPgYpXExx i44coYMmQT6jUzBRMB0GA1UdDgQWBBSjd9GWIe98Ll9J0dquxgCktp9DrTAfBgNV HSMEGDAWgBSjd9GWIe98Ll9J0dquxgCktp9DrTAPBgNVHRMBAf8EBTADAQH/MAoG CCqBHM9VAYN1A0cAMEQCIAvLWIfGFq85u/vVMLc5H1D/DnrNS0VhSkQA4daRO4tc AiABbeWENcQZDZLWTuqG9P2KDPOoNqV/QV/+0XjMAVblhg== -END CERTIFICATE- If you can, please add: Tested-by: Tianjia Zhang good luck! Tianjia
[PATCH][next] net: cassini: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- drivers/net/ethernet/sun/cassini.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c index 9ff894ba8d3e..54f45d8c79a7 100644 --- a/drivers/net/ethernet/sun/cassini.c +++ b/drivers/net/ethernet/sun/cassini.c @@ -1599,6 +1599,7 @@ static inline int cas_mdio_link_not_up(struct cas *cp) cas_phy_write(cp, MII_BMCR, val); break; } + break; default: break; } -- 2.27.0
[PATCH][next] net: 3c509: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva --- drivers/net/ethernet/3com/3c509.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/3com/3c509.c b/drivers/net/ethernet/3com/3c509.c index 53e1f7e07959..96cc5fc36eb5 100644 --- a/drivers/net/ethernet/3com/3c509.c +++ b/drivers/net/ethernet/3com/3c509.c @@ -1051,6 +1051,7 @@ el3_netdev_get_ecmd(struct net_device *dev, struct ethtool_link_ksettings *cmd) break; case 3: cmd->base.port = PORT_BNC; + break; default: break; } -- 2.27.0
[PATCH][next] net: mscc: ocelot: Fix fall-through warnings for Clang
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva Reviewed-by: Vladimir Oltean --- drivers/net/ethernet/mscc/ocelot_vcap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/mscc/ocelot_vcap.c b/drivers/net/ethernet/mscc/ocelot_vcap.c index 37a232911395..7945393a0655 100644 --- a/drivers/net/ethernet/mscc/ocelot_vcap.c +++ b/drivers/net/ethernet/mscc/ocelot_vcap.c @@ -761,6 +761,7 @@ static void is1_entry_set(struct ocelot *ocelot, int ix, vcap_key_bytes_set(vcap, , VCAP_IS1_HK_ETYPE, etype.value, etype.mask); } + break; } default: break; -- 2.27.0
Re: [PATCH v6] i2c: virtio: add a virtio i2c frontend driver
On 05-03-21, 15:00, Jie Deng wrote:
> On 2021/3/5 11:09, Viresh Kumar wrote:
> > On 05-03-21, 09:46, Jie Deng wrote:
> > > On 2021/3/4 14:06, Viresh Kumar wrote:
> > > > > + mutex_lock(>i2c_lock);
> > > > I have never worked with i2c stuff earlier, but I don't think you need
> > > > a lock
> > > > here. The transactions seem to be serialized by the i2c-core by itself
> > > > (look at
> > > > i2c_transfer() in i2c-core-base.c), though there is another exported
> > > > version
> > > > __i2c_transfer() but the comment over it says the callers must take
> > > > adapter lock
> > > > before calling it.
> > > Lock is needed since no "lock_ops" is registered in this i2c_adapter.
> > drivers/i2c/i2c-core-base.c:
> >
> > static int i2c_register_adapter(struct i2c_adapter *adap)
> > {
> > ...
> >
> > if (!adap->lock_ops)
> > adap->lock_ops = _adapter_lock_ops;
> >
> > ...
> > }
> >
> > This should take care of it ?
>
>
> The problem is that you can't guarantee that adap->algo->master_xfer is only
> called
> from i2c_transfer. Any function who holds the adapter can call
> adap->algo->master_xfer
> directly. So I think it is safer to have a lock in virtio_i2c_xfer.
So I tried to look for such callers in the kernel.
$ git grep -l "\ > > > > +static struct i2c_adapter virtio_adapter = {
> > > > > + .owner = THIS_MODULE,
> > > > > + .name = "Virtio I2C Adapter",
> > > > > + .class = I2C_CLASS_DEPRECATED,
> > > > Why are we using something that is deprecated here ?
> > > Warn users that the adapter doesn't support classes anymore.
> > So this is the right thing to do? Or this is what we expect from new
> > drivers?
> > Sorry, I am just new to this stuff and so...
>
>
> https://patchwork.ozlabs.org/project/linux-i2c/patch/20170729121143.3980-1-...@the-dreams.de/
Frankly this confused me even further :)
The earlier comment in the code said:
"/* Warn users that adapter will stop using classes */"
so this looks more for existing drivers..
Then the commit message says this:
"Hopefully making clear that it is not needed for new drivers."
and comment says:
"/* Warn users that the adapter doesn't support classes anymore */"
Reading this it looks this is only required for existing adapters so they can
warn userspace and shouldn't be required for new drivers.
Am I reading it incorrectly ?
--
viresh
Re: [PATCH] md: bcache: fix error return code of cached_dev_cache_miss()
Hi Coly,
Thanks a lot for your detailed explanation :)
Best wishes,
Jia-Ju Bai
On 2021/3/5 12:05, Coly Li wrote:
On 3/5/21 10:46 AM, Jia-Ju Bai wrote:
When bch_bio_alloc_pages() fails, no error return code of
cached_dev_cache_miss() is assigned.
To fix this bug, ret is assigned with -ENOMEN as error return code.
Reported-by: TOTE Robot
Signed-off-by: Jia-Ju Bai
---
drivers/md/bcache/request.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index 29c231758293..9ecaf26c8d60 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -930,8 +930,10 @@ static int cached_dev_cache_miss(struct btree *b, struct
search *s,
cache_bio->bi_private= >cl;
bch_bio_map(cache_bio, NULL);
- if (bch_bio_alloc_pages(cache_bio, __GFP_NOWARN|GFP_NOIO))
+ if (bch_bio_alloc_pages(cache_bio, __GFP_NOWARN|GFP_NOIO)) {
+ ret = -ENOMEM;
goto out_put;
+ }
if (reada)
bch_mark_cache_readahead(s->iop.c, s->d);
Thanks for looking at bcache :-)
Without the above change, -EINTR will be returned. -EINTR is special in
bache's btree iteration code. See bcache_btree_root() from bcache.h,
347 #define bcache_btree_root(fn, c, op, ...) \
348 ({ \
349 int _r = -EINTR;\
350 do {\
351 struct btree *_b = (c)->root;\
352 bool _w = insert_lock(op, _b); \
353 rw_lock(_w, _b, _b->level); \
354 if (_b == (c)->root && \
355 _w == insert_lock(op, _b)) { \
356 _r = bch_btree_ ## fn(_b, op, ##__VA_ARGS__); \
357 } \
358 rw_unlock(_w, _b); \
359 bch_cannibalize_unlock(c); \
360 if (_r == -EINTR) \
361 \
362 } while (_r == -EINTR); \
363 \
364 finish_wait(&(c)->btree_cache_wait, &(op)->wait); \
365 _r; \
366 })
cached_dev_cache_miss() is called by the following code path,
cache_lookup() ==> bch_btree_map_keys() ==> bcache_btree_root() ==>
bch_btree_map_keys_recurse() ==> cache_lookup_fn()
Therefore the return value of cached_dev_cache_miss() will be returned
from where s->d->cache_miss() is called from cache_lookup_fn(). And in
macro bcache_btree_root() this return value will be checked. If the
return value is -EINTR, then the whole iteration will be re-do again.
Returning -ENOMEM works but if the memory allocation failed, there is no
chance to re-do the cache lookup again from bcache_btree_root(). When
system memory is in heavy usage, we want the lookup to try more times
(because GFP_NOIO is set), which is much better then returning -EIO
immediately to caller.
Therefore NOT setting ret to -ENOMEM in the patching location should be
an on-purpose coding, IMHO.
Thanks.
Coly Li
Re: [PATCH v1] mm, hwpoison: do not lock page again when me_huge_page() successfully recovers
On Thu, Mar 04, 2021 at 03:44:37PM +0900, Naoya Horiguchi wrote:
> From: Naoya Horiguchi
Hi Naoya,
good catch!
> Currently me_huge_page() temporary unlocks page to perform some actions
> then locks it again later. My testcase (which calls hard-offline on some
> tail page in a hugetlb, then accesses the address of the hugetlb range)
> showed that page allocation code detects the page lock on buddy page and
> printed out "BUG: Bad page state" message. PG_hwpoison does not prevent
> it because PG_hwpoison flag is set on any subpage of the hugetlb page
> but the 2nd page lock is on the head page.
I am having difficulties to parse "PG_hwpoison does not prevent it because
PG_hwpoison flag is set on any subpage of the hugetlb page".
What do you mean by that?
>
> This patch suggests to drop the 2nd page lock to fix the issue.
>
> Fixes: commit 78bb920344b8 ("mm: hwpoison: dissolve in-use hugepage in
> unrecoverable memory error")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Naoya Horiguchi
The fix looks fine to me:
Reviewed-by: Oscar Salvador
--
Oscar Salvador
SUSE L3
Re: [PATCH v6] i2c: virtio: add a virtio i2c frontend driver
On 2021/3/5 1:47 下午, Jie Deng wrote:
On 2021/3/4 17:15, Jason Wang wrote:
On 2021/3/4 9:59 上午, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device specification can be found on
https://lists.oasis-open.org/archives/virtio-comment/202101/msg8.html.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 289
include/uapi/linux/virtio_i2c.h | 42 ++
include/uapi/linux/virtio_ids.h | 1 +
5 files changed, 346 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-virtio.c
create mode 100644 include/uapi/linux/virtio_i2c.h
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 05ebf75..0860395 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module. If so, the module
will be called i2c-ali1535.
+config I2C_VIRTIO
+ tristate "Virtio I2C Adapter"
+ depends on VIRTIO
Please use select here. There's no prompt for VIRTIO.
OK.
+ help
+ If you say yes to this option, support will be included for
the virtio
+ I2C adapter driver. The hardware can be emulated by any
device model
+ software according to the virtio protocol.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-virtio.
+
config I2C_ALI1563
tristate "ALI 1563"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 615f35e..b88da08 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -6,6 +6,9 @@
# ACPI drivers
obj-$(CONFIG_I2C_SCMI) += i2c-scmi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
# PC SMBus host controller drivers
obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o
obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o
diff --git a/drivers/i2c/busses/i2c-virtio.c
b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..98c0fcc
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * The Virtio I2C Specification:
+ *
https://raw.githubusercontent.com/oasis-tcs/virtio-spec/master/virtio-i2c.tex
+ *
+ * Copyright (c) 2021 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct i2c_adapter adap;
+ struct mutex i2c_lock;
+ struct virtqueue *vq;
+};
+
+/**
+ * struct virtio_i2c_req - the virtio I2C request structure
+ * @out_hdr: the OUT header of the virtio I2C message
+ * @buf: the buffer into which data is read, or from which it's
written
+ * @in_hdr: the IN header of the virtio I2C message
+ */
+struct virtio_i2c_req {
+ struct virtio_i2c_out_hdr out_hdr;
+ u8 *buf;
+ struct virtio_i2c_in_hdr in_hdr;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(>completion);
+}
+
+static int virtio_i2c_send_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+ struct i2c_msg *msgs, int nr)
+{
+ struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
+ int i, outcnt, incnt, err = 0;
+ u8 *buf;
+
+ for (i = 0; i < nr; i++) {
+ if (!msgs[i].len)
+ break;
+
+ /* Only 7-bit mode supported for this moment. For the
address format,
+ * Please check the Virtio I2C Specification.
+ */
+ reqs[i].out_hdr.addr = cpu_to_le16(msgs[i].addr << 1);
+
+ if (i != nr - 1)
+ reqs[i].out_hdr.flags |= VIRTIO_I2C_FLAGS_FAIL_NEXT;
+
+ outcnt = incnt = 0;
+ sg_init_one(_hdr, [i].out_hdr,
sizeof(reqs[i].out_hdr));
+ sgs[outcnt++] = _hdr;
+
+ buf = kzalloc(msgs[i].len, GFP_KERNEL);
+ if (!buf)
+ break;
+
+ reqs[i].buf = buf;
+ sg_init_one(_buf, reqs[i].buf, msgs[i].len);
+
+ if (msgs[i].flags & I2C_M_RD) {
+ sgs[outcnt + incnt++] = _buf;
+ } else {
+
[PATCH v5] tools/x86: Add a kcpuid tool to show raw CPU features
End users frequently want to know what features their processor supports, independent of what the kernel supports. /proc/cpuinfo is great. It is omnipresent and since it is provided by the kernel it is always as up to date as the kernel. But, it could be ambiguous about processor features which can be disabled by the kernel at boot-time or compile-time. There are some user space tools showing more raw features, but they are not bound with kernel, and go with distros. Many end users are still using old distros with new kernels (upgraded by themselves), and may not upgrade the distros only to get a newer tool. So here arise the need for a new tool, which * shows raw CPU features read from the CPUID instruction * will be easier to update compared to existing userspace tooling (perhaps distributed like perf) * inherits "modern" kernel development process, in contrast to some of the existing userspace CPUID tools which are still being developed without git and distributed in tarballs from non-https sites. * Can produce output consistent with /proc/cpuinfo to make comparison easier. The CPUID leaf definitions are kept in an .csv file which allows for updating only that file to add support for new feature leafs. This is based on prototype code from Borislav Petkov (http://sr71.net/~dave/intel/stupid-cpuid.c). [ bp: Massage, add #define _GNU_SOURCE to fix implicit declaration of function ‘strcasestr' warning. ] Originally-from: Borislav Petkov Suggested-by: Dave Hansen Suggested-by: Borislav Petkov Signed-off-by: Feng Tang Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/1603344083-100742-1-git-send-email-feng.t...@intel.com --- Changelog: v5: * rebased against v5.11 * fix a buffer overflow issue in v4 v4: * rebase against 5.11-rc4 * Boris helped to find and fix a segmentation fault and one compile warning * add more cpuid info into cpuid.csv * will show boolean bit flags only by default * some code cleanup v3: * use .csv file instead of plain text file which also uses comma to separate fields (Borislav) * add option to support a user specified .csv file (Dave) * make install will put the csv file under /usr/share/hwdata/ (Dave) v2: * use a new text file to store all the bits definition of each CPUID leaf/subleafs, which is easier for future expansion, as the core .c file will be kept untouched, suggested by Borislav/Dave * some code cleanup tools/arch/x86/kcpuid/Makefile | 24 ++ tools/arch/x86/kcpuid/cpuid.csv | 380 +++ tools/arch/x86/kcpuid/kcpuid.c | 646 3 files changed, 1050 insertions(+) create mode 100644 tools/arch/x86/kcpuid/Makefile create mode 100644 tools/arch/x86/kcpuid/cpuid.csv create mode 100644 tools/arch/x86/kcpuid/kcpuid.c diff --git a/tools/arch/x86/kcpuid/Makefile b/tools/arch/x86/kcpuid/Makefile new file mode 100644 index 000..87b554f --- /dev/null +++ b/tools/arch/x86/kcpuid/Makefile @@ -0,0 +1,24 @@ +# SPDX-License-Identifier: GPL-2.0 +# Makefile for x86/kcpuid tool + +kcpuid : kcpuid.c + +CFLAGS = -Wextra + +BINDIR ?= /usr/sbin + +HWDATADIR ?= /usr/share/misc/ + +override CFLAGS += -O2 -Wall -I../../../include + +%: %.c + $(CC) $(CFLAGS) -o $@ $< $(LDFLAGS) + +.PHONY : clean +clean : + @rm -f kcpuid + +install : kcpuid + install -d $(DESTDIR)$(BINDIR) + install -m 755 -p kcpuid $(DESTDIR)$(BINDIR)/kcpuid + install -m 444 -p cpuid.csv $(HWDATADIR)/cpuid.csv diff --git a/tools/arch/x86/kcpuid/cpuid.csv b/tools/arch/x86/kcpuid/cpuid.csv new file mode 100644 index 000..f4a5b85 --- /dev/null +++ b/tools/arch/x86/kcpuid/cpuid.csv @@ -0,0 +1,380 @@ +# The basic row format is: +# LEAF, SUBLEAF, register_name, bits, short_name, long_description + +# Leaf 00H + 0,0, EAX, 31:0, max_basic_leafs, Max input value for supported subleafs + +# Leaf 01H + 1,0, EAX,3:0, stepping, Stepping ID + 1,0, EAX,7:4, model, Model + 1,0, EAX, 11:8, family, Family ID + 1,0, EAX, 13:12, processor, Processor Type + 1,0, EAX, 19:16, model_ext, Extended Model ID + 1,0, EAX, 27:20, family_ext, Extended Family ID + + 1,0, EBX,7:0, brand, Brand Index + 1,0, EBX, 15:8, clflush_size, CLFLUSH line size (value * 8) in bytes + 1,0, EBX, 23:16, max_cpu_id, Maxim number of addressable logic cpu in this package + 1,0, EBX, 31:24, apic_id, Initial APIC ID + + 1,0, ECX, 0, sse3, Streaming SIMD Extensions 3(SSE3) + 1,0, ECX, 1, pclmulqdq, PCLMULQDQ instruction supported + 1,0, ECX, 2, dtes64, DS area uses 64-bit layout + 1,0, ECX, 3, mwait, MONITOR/MWAIT supported + 1,0, ECX, 4, ds_cpl, CPL Qualified Debug Store which allows for branch message storage qualified by CPL
Re: [PATCH] [v2] Input: Add "Share" button to Microsoft Xbox One controller.
On Thu, 2021-03-04 at 20:42 -0800, Roderick Colenbrander wrote:
> (resend in plain text)
> +benjamin in a more explicit way
>
> Hi Chris,
>
> I see the need for the Record button. I wonder what makes sense from
> the Linux kernel perspective. For DualShock 4 and DualSense there is a
> Share button too (it introduced it). For DualShock 4 that was mapped
> to 'Select' I think per Linux gamepad spec. For DualSense in 5.12 we
> did the same... Though if there is a true 'Record' button we want to
> use moving forward. Maybe we still want to change the button
> definition for DualSensein 5.12 while we can...
>
> It would be good to get some consensus on these buttons.
The XBox One Series X controller has 3 of those "middle" buttons, 2
equivalent to Start/Select on older controllers (that were already
present on older versions of the pad) and Share.
https://www.xbox.com/en-US/accessories/controllers/xbox-wireless-controller
The Options buttons on the DS4 replaces Start and Select:
https://manuals.playstation.net/document/en/ps4/basic/pn_controller.html
so Share got added, but Select taken away, which is why you had to
label it Select in the driver.
I don't really see how to fix that without retroactively re-adding
buttons to the DS4 controller ;)
>
> Thanks,
> Roderick
>
>
> On Thu, Mar 4, 2021 at 6:25 PM Chris Ye wrote:
> >
> > Hi Bastien, just want to follow up again on this. I've checked
> > again
> > with the Xbox team that the "Share button" is given for the product,
> > the HID usage profile and mapping to RECORD is what Xbox team expects
> > and they want the same mapping for USB.
> >
> > Thanks!
> > Chris
> >
> >
> > On Tue, Mar 2, 2021 at 3:57 PM Chris Ye wrote:
> > >
> > > Hi Bastien,
> > > The "Share button" is a name Microsoft calls it, it actually
> > > has
> > > HID descriptor defined in the bluetooth interface, which the HID
> > > usage
> > > is:
> > > consumer 0xB2:
> > > 0x05, 0x0C, // Usage Page (Consumer)
> > > 0x0A, 0xB2, 0x00, // Usage (Record)
> > > Microsoft wants the same key code to be generated consistently for
> > > USB
> > > and bluetooth.
> > > Thanks!
> > > Chris
> > >
> > >
> > > On Tue, Mar 2, 2021 at 1:50 AM Bastien Nocera
> > > wrote:
> > > >
> > > > On Thu, 2021-02-25 at 05:32 +, Chris Ye wrote:
> > > > > Add "Share" button input capability and input event mapping for
> > > > > Microsoft Xbox One controller.
> > > > > Fixed Microsoft Xbox One controller share button not working
> > > > > under USB
> > > > > connection.
> > > > >
> > > > > Signed-off-by: Chris Ye
> > > > > ---
> > > > > drivers/input/joystick/xpad.c | 9 -
> > > > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/input/joystick/xpad.c
> > > > > b/drivers/input/joystick/xpad.c
> > > > > index 9f0d07dcbf06..0c3374091aff 100644
> > > > > --- a/drivers/input/joystick/xpad.c
> > > > > +++ b/drivers/input/joystick/xpad.c
> > > > > @@ -79,6 +79,7 @@
> > > > > #define MAP_DPAD_TO_BUTTONS (1 << 0)
> > > > > #define MAP_TRIGGERS_TO_BUTTONS (1 << 1)
> > > > > #define MAP_STICKS_TO_NULL (1 << 2)
> > > > > +#define MAP_SHARE_BUTTON (1 << 3)
> > > > > #define DANCEPAD_MAP_CONFIG (MAP_DPAD_TO_BUTTONS
> > > > > > \
> > > > > MAP_TRIGGERS_TO_BUTTONS |
> > > > > MAP_STICKS_TO_NULL)
> > > > >
> > > > > @@ -130,6 +131,7 @@ static const struct xpad_device {
> > > > > { 0x045e, 0x02e3, "Microsoft X-Box One Elite pad", 0,
> > > > > XTYPE_XBOXONE },
> > > > > { 0x045e, 0x02ea, "Microsoft X-Box One S pad", 0,
> > > > > XTYPE_XBOXONE
> > > > > },
> > > > > { 0x045e, 0x0719, "Xbox 360 Wireless Receiver",
> > > > > MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
> > > > > + { 0x045e, 0x0b12, "Microsoft X-Box One X pad",
> > > > > MAP_SHARE_BUTTON, XTYPE_XBOXONE },
> > > > > { 0x046d, 0xc21d, "Logitech Gamepad F310", 0,
> > > > > XTYPE_XBOX360 },
> > > > > { 0x046d, 0xc21e, "Logitech Gamepad F510", 0,
> > > > > XTYPE_XBOX360 },
> > > > > { 0x046d, 0xc21f, "Logitech Gamepad F710", 0,
> > > > > XTYPE_XBOX360 },
> > > > > @@ -862,6 +864,8 @@ static void xpadone_process_packet(struct
> > > > > usb_xpad
> > > > > *xpad, u16 cmd, unsigned char
> > > > > /* menu/view buttons */
> > > > > input_report_key(dev, BTN_START, data[4] & 0x04);
> > > > > input_report_key(dev, BTN_SELECT, data[4] & 0x08);
> > > > > + if (xpad->mapping & MAP_SHARE_BUTTON)
> > > > > + input_report_key(dev, KEY_RECORD, data[22] &
> > > > > 0x01);
> > > > >
> > > > > /* buttons A,B,X,Y */
> > > > > input_report_key(dev, BTN_A, data[4] & 0x10);
> > > > > @@ -1669,9 +1673,12 @@ static int xpad_init_input(struct
> > > > > usb_xpad
> > > > > *xpad)
> > > > >
> > > > > /* set up model-specific ones */
> > > > > if (xpad->xtype == XTYPE_XBOX360 ||
Re: [PATCH] ANDROID: usb: core: Send uevent when USB TOPO layer over 6
Greg KH 於 2021年3月3日 週三 下午5:10寫道：
>
> On Wed, Mar 03, 2021 at 05:03:25PM +0800, Chien Kun Niu wrote:
> > Hi , Greg
> >
> > What tool will "catch" this? Where is that code located at?
> > => I prepare merge the code to Android phone , so I used Android HLOS
> > to catch this uevent.
>
> Very odd quoting style, perhaps you might want to read up on how to do
> this properly at:
> https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
>
> > uevents are not for stuff like this, you are trying to send "error
> > conditions" to userspace, please use the "proper" interfaces like this
> > and not abuse existing ones.
> > => Sorry , I am not sure what is the "proper" interfaces your mean.
> > Could you please give me more description?
>
> How does the kernel normally send error conditions that it detects in
> hardware to userspace?
>
I will create a sysfs attribute to record the hub status.
If there is a new hub with over 6 USB TOPO layer connected, I will use
the sysfs_notify to send the "error conditions" to userspace.
Is it a proper interfaces to delivery "error conditions"?
> > You just created a whole new sysfs class with no Documentation/ABI/
> > update?
> > => Yes, I will add it.
> >
> > Wait, how did you even test this code? This will not work if you have
> > more than one hub in the system at a single time, right?
> > => I build the test build which flash in Android phone and connect
> > several hubs to try it.
> > When the new hub which met MAX_TOPO_LEVEL connected , it sent
> > notify to user space.
> >
> > Phone --↓
> > hub --↓
> > hub --↓
> >...--↓
> > hub
> >
> > if (hdev->level == MAX_TOPO_LEVEL) {
> > dev_err(>dev,
> > "Unsupported bus topology: hub nested too deep\n");
> > hub_over_tier();
> > return -E2BIG;
> > }
> >
>
> But you only have a single hub variable, and a huge memory leak, did you
> not detect that in your testing?
>
> > So, proof that this works? How did you test this?
> > => I use the Pixel phone to verify the code , the framework received
> > the uevent when the last connected hub over "MAX_TOPO_LEVEL".
>
> Try it on a desktop as well, with many hubs and see what happens :(
>
> > Also, you have a memory leak in this submission :(
> > => Do you mean I should add device_destroy here ?
>
> What do you think should be done?
>
> >
> > hub_device =
> > device_create(hub_class, NULL, MKDEV(0, 0), NULL, "usb_hub");
> > +if (IS_ERR(hub_device))
> > + return PTR_ERR(hub_device);
> >
> > void usb_hub_cleanup(void)
> > {
> > +if (!IS_ERR(hub_device))
> > +device_destroy(hub_class, hub_device->devt);
> >
> > if (!IS_ERR(hub_class))
> > class_destroy(hub_class);
>
> I don't think you are understanding that you can have multiple hubs in
> the system at the same time :(
>
> thanks,
>
> greg k-h
Thanks,
Chien Kun Niu
Re: [PATCH -next] mtd: parsers: ofpart: make symbol 'bcm4908_partitions_quirks' static
On 04.03.2021 07:46, 'Wei Yongjun wrote:
From: Wei Yongjun
The sparse tool complains as follows:
drivers/mtd/parsers/ofpart_core.c:25:32: warning:
symbol 'bcm4908_partitions_quirks' was not declared. Should it be static?
This symbol is not used outside of ofpart_core.c, so this
commit marks it static.
Fixes: 457da931b608 ("mtd: parsers: ofpart: support BCM4908 fixed partitions")
Reported-by: Hulk Robot
Signed-off-by: Wei Yongjun
Looks good ofc, thanks.
Re: [PATCH] ibmvnic: remove excessive irqsave
On Fri, 5 Mar 2021 06:49:14 +0100 Christophe Leroy wrote: > Le 05/03/2021 ?? 02:43, angkery a ??crit?0?2: > > From: Junlin Yang > > > > ibmvnic_remove locks multiple spinlocks while disabling interrupts: > > spin_lock_irqsave(>state_lock, flags); > > spin_lock_irqsave(>rwi_lock, flags); > > > > there is no need for the second irqsave,since interrupts are > > disabled at that point, so remove the second irqsave: > > The probl??me is not that there is no need. The problem is a lot more > serious: As reported by coccinella, the second _irqsave() overwrites > the value saved in 'flags' by the first _irqsave, therefore when the > second _irqrestore comes, the value in 'flags' is not valid, the > value saved by the first _irqsave has been lost. This likely leads to > IRQs remaining disabled, which is _THE_ problem really. > Thank you for explaining the real problem. I will update the commit information with your description. > > spin_lock_irqsave(>state_lock, flags); > > spin_lock(>rwi_lock); > > > > Generated by: ./scripts/coccinelle/locks/flags.cocci > > ./drivers/net/ethernet/ibm/ibmvnic.c:5413:1-18: > > ERROR: nested lock+irqsave that reuses flags from line 5404. > > > > Signed-off-by: Junlin Yang > > --- > > drivers/net/ethernet/ibm/ibmvnic.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/ethernet/ibm/ibmvnic.c > > b/drivers/net/ethernet/ibm/ibmvnic.c index 2464c8a..a52668d 100644 > > --- a/drivers/net/ethernet/ibm/ibmvnic.c > > +++ b/drivers/net/ethernet/ibm/ibmvnic.c > > @@ -5408,9 +5408,9 @@ static void ibmvnic_remove(struct vio_dev > > *dev) > > * after setting state, so __ibmvnic_reset() which is > > called > > * from the flush_work() below, can make progress. > > */ > > - spin_lock_irqsave(>rwi_lock, flags); > > + spin_lock(>rwi_lock); > > adapter->state = VNIC_REMOVING; > > - spin_unlock_irqrestore(>rwi_lock, flags); > > + spin_unlock(>rwi_lock); > > > > spin_unlock_irqrestore(>state_lock, flags); > > > >
[PATCH 2/2] iio:magnetometer: Support for ST magnetic sensors
Add support for STMicroelectronics digital magnetic sensors,
LSM303AH,LSM303AGR,LIS2MDL,ISM303DAC,IIS2MDC.
The patch tested with IIS2MDC instrument.
Signed-off-by: LI Qingwu
---
drivers/iio/magnetometer/Kconfig | 23 ++
drivers/iio/magnetometer/Makefile | 4 +
drivers/iio/magnetometer/st_mag40_buffer.c | 191 +++
drivers/iio/magnetometer/st_mag40_core.c | 371 +
drivers/iio/magnetometer/st_mag40_core.h | 136
drivers/iio/magnetometer/st_mag40_i2c.c| 180 ++
drivers/iio/magnetometer/st_mag40_spi.c| 188 +++
7 files changed, 1093 insertions(+)
create mode 100644 drivers/iio/magnetometer/st_mag40_buffer.c
create mode 100644 drivers/iio/magnetometer/st_mag40_core.c
create mode 100644 drivers/iio/magnetometer/st_mag40_core.h
create mode 100644 drivers/iio/magnetometer/st_mag40_i2c.c
create mode 100644 drivers/iio/magnetometer/st_mag40_spi.c
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index 1697a8c03506..bfd2866faa99 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -205,4 +205,27 @@ config SENSORS_RM3100_SPI
To compile this driver as a module, choose M here: the module
will be called rm3100-spi.
+config ST_MAG40_IIO
+ tristate "STMicroelectronics
LIS2MDL/LSM303AH/LSM303AGR/ISM303DAC/IIS2MDC sensor"
+ depends on (I2C || SPI) && SYSFS
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ select ST_MAG40_I2C_IIO if (I2C)
+ select ST_MAG40_SPI_IIO if (SPI)
+ help
+ Say yes here to build support for STMicroelectronics magnetometers:
+ LIS2MDL, LSM303AH, LSM303AGR, ISM303DAC, IIS2MDC.
+
+ To compile this driver as a module, choose M here. The module
+ will be called st_mag40.
+
+config ST_MAG40_I2C_IIO
+ tristate
+ depends on ST_MAG40_IIO
+ depends on I2C
+
+config ST_MAG40_SPI_IIO
+ tristate
+ depends on ST_MAG40_IIO
+ depends on SPI
endmenu
diff --git a/drivers/iio/magnetometer/Makefile
b/drivers/iio/magnetometer/Makefile
index ba1bc34b82fa..b6b427cfc284 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -25,6 +25,10 @@ obj-$(CONFIG_SENSORS_HMC5843)+=
hmc5843_core.o
obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
+st_mag40-y += st_mag40_buffer.o st_mag40_core.o
+obj-$(CONFIG_ST_MAG40_IIO) += st_mag40.o
+obj-$(CONFIG_ST_MAG40_I2C_IIO) += st_mag40_i2c.o
+obj-$(CONFIG_ST_MAG40_SPI_IIO) += st_mag40_spi.o
obj-$(CONFIG_SENSORS_RM3100) += rm3100-core.o
obj-$(CONFIG_SENSORS_RM3100_I2C) += rm3100-i2c.o
obj-$(CONFIG_SENSORS_RM3100_SPI) += rm3100-spi.o
diff --git a/drivers/iio/magnetometer/st_mag40_buffer.c
b/drivers/iio/magnetometer/st_mag40_buffer.c
new file mode 100644
index ..d2a67c9dae5e
--- /dev/null
+++ b/drivers/iio/magnetometer/st_mag40_buffer.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * STMicroelectronics st_mag40 driver
+ *
+ * Copyright 2016 STMicroelectronics Inc.
+ *
+ * Matteo Dameno
+ * Armando Visconti
+ * Lorenzo Bianconi
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "st_mag40_core.h"
+
+#define ST_MAG40_EWMA_DIV 128
+static inline s64 st_mag40_ewma(s64 old, s64 new, int weight)
+{
+ s64 diff, incr;
+
+ diff = new - old;
+ incr = div_s64((ST_MAG40_EWMA_DIV - weight) * diff,
+ ST_MAG40_EWMA_DIV);
+
+ return old + incr;
+}
+
+static irqreturn_t st_mag40_trigger_irq_handler(int irq, void *private)
+{
+ struct st_mag40_data *cdata = private;
+ s64 ts;
+ u8 weight = (cdata->odr >= 50) ? 96 : 0;
+
+ ts = st_mag40_get_timestamp();
+ cdata->delta_ts = st_mag40_ewma(cdata->delta_ts, ts - cdata->ts_irq,
weight);
+ cdata->ts_irq = ts;
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t st_mag40_trigger_thread_handler(int irq, void *private)
+{
+ struct st_mag40_data *cdata = private;
+ u8 status;
+ int err;
+
+ err = cdata->tf->read(cdata, ST_MAG40_STATUS_ADDR,
+ sizeof(status), );
+ if (err < 0)
+ return IRQ_HANDLED;
+
+ if (!(status & ST_MAG40_AVL_DATA_MASK))
+ return IRQ_NONE;
+
+ iio_trigger_poll_chained(cdata->iio_trig);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t st_mag40_buffer_thread_handler(int irq, void *p)
+{
+ u8 buffer[ALIGN(ST_MAG40_OUT_LEN, sizeof(s64)) + sizeof(s64)];
+ struct iio_poll_func *pf = p;
+ struct iio_dev *iio_dev = pf->indio_dev;
+ struct st_mag40_data *cdata = iio_priv(iio_dev);
+ int err;
+
+ err = cdata->tf->read(cdata, ST_MAG40_OUTX_L_ADDR,
[PATCH 1/2] dt-bindings: iio: st,st-sensors.yaml New iis2mdc bindings
Add support for ST magnetometer lsm303ah,sm303dac and iis2mdc. The patch tested with IIS2MDC instrument. Signed-off-by: LI Qingwu --- Documentation/devicetree/bindings/iio/st,st-sensors.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index db291a9390b7..6fd61ffde72b 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -66,6 +66,11 @@ properties: - st,lis3mdl-magn - st,lis2mdl - st,lsm9ds1-magn + - st,lsm303ah_magn + - st,ism303dac_magn + - st,iis2mdc_magn + - st,lsm303agr_magn + - st,lis2mdl_magn # Pressure sensors - st,lps001wp-press - st,lps25h-press -- 2.17.1
Re: [PATCH v8 2/5] drm: ttm_pool: Rework ttm_pool to use drm_page_pool
Hi John, I love your patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.12-rc1] [cannot apply to linux/master drm-intel/for-linux-next drm-tip/drm-tip next-20210305] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/John-Stultz/Generic-page-pool-deferred-freeing-for-system-dmabuf-heap/20210305-072137 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 3cb60ee6323968b694208c4cbd56a7176396e931 config: parisc-randconfig-r024-20210305 (attached as .config) compiler: hppa-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/701300f424bbe73234f3dc3b62581a5e6ddef78a git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review John-Stultz/Generic-page-pool-deferred-freeing-for-system-dmabuf-heap/20210305-072137 git checkout 701300f424bbe73234f3dc3b62581a5e6ddef78a # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): hppa-linux-ld: drivers/gpu/drm/page_pool.o: in function `drm_page_pool_shrinker_setup': >> (.text.drm_page_pool_shrinker_setup+0x0): multiple definition of >> `init_module'; drivers/gpu/drm/drm_drv.o:(.init.text+0x0): first defined here hppa-linux-ld: drivers/gpu/drm/page_pool.o: in function `drm_page_pool_shrinker_teardown': >> (.text.drm_page_pool_shrinker_teardown+0x0): multiple definition of >> `cleanup_module'; drivers/gpu/drm/drm_drv.o:(.text.drm_core_exit+0x0): first >> defined here --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH v6 3/3] hwrng: bcm2835: add reset support
BCM6368 devices need to reset the IPSEC controller in order to generate true
random numbers.
This is what BCM6368 produces without a reset:
root@OpenWrt:/# cat /dev/hwrng | rngtest -c 1000
rngtest 6.10
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 2032
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 1000
rngtest: FIPS 140-2(2001-10-10) Monobit: 2
rngtest: FIPS 140-2(2001-10-10) Poker: 1000
rngtest: FIPS 140-2(2001-10-10) Runs: 1000
rngtest: FIPS 140-2(2001-10-10) Long run: 30
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=37.253; avg=320.827; max=635.783)Mibits/s
rngtest: FIPS tests speed: (min=12.141; avg=15.034; max=16.428)Mibits/s
rngtest: Program run time: 1336176 microseconds
Signed-off-by: Álvaro Fernández Rojas
---
v6: fix commit description.
v5: remove reset_control_rearm().
v4: add reset_control_rearm().
v3: no changes.
v2: no changes.
drivers/char/hw_random/bcm2835-rng.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/char/hw_random/bcm2835-rng.c
b/drivers/char/hw_random/bcm2835-rng.c
index be5be395b341..e7dd457e9b22 100644
--- a/drivers/char/hw_random/bcm2835-rng.c
+++ b/drivers/char/hw_random/bcm2835-rng.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#define RNG_CTRL 0x0
#define RNG_STATUS 0x4
@@ -32,6 +33,7 @@ struct bcm2835_rng_priv {
void __iomem *base;
bool mask_interrupts;
struct clk *clk;
+ struct reset_control *reset;
};
static inline struct bcm2835_rng_priv *to_rng_priv(struct hwrng *rng)
@@ -92,6 +94,10 @@ static int bcm2835_rng_init(struct hwrng *rng)
if (ret)
return ret;
+ ret = reset_control_reset(priv->reset);
+ if (ret)
+ return ret;
+
if (priv->mask_interrupts) {
/* mask the interrupt */
val = rng_readl(priv, RNG_INT_MASK);
@@ -156,6 +162,10 @@ static int bcm2835_rng_probe(struct platform_device *pdev)
if (IS_ERR(priv->clk))
return PTR_ERR(priv->clk);
+ priv->reset = devm_reset_control_get_optional_exclusive(dev, NULL);
+ if (IS_ERR(priv->reset))
+ return PTR_ERR(priv->reset);
+
priv->rng.name = pdev->name;
priv->rng.init = bcm2835_rng_init;
priv->rng.read = bcm2835_rng_read;
--
2.20.1
[PATCH v6 2/3] dt-bindings: rng: bcm2835: document reset support
brcm,bcm6368-rng controllers require resetting the IPSEC clock in order to get a functional RNG. Signed-off-by: Álvaro Fernández Rojas --- v6: fix dt-bindings warnings. v5: no changes. v4: pass dt_binding_check. v3: make resets required if brcm,bcm6368-rng. v2: document reset support. .../devicetree/bindings/rng/brcm,bcm2835.yaml | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml index 5174492e22f3..6da674666d45 100644 --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml @@ -28,6 +28,12 @@ properties: clock-names: const: ipsec + resets: +maxItems: 1 + + reset-names: +const: ipsec + interrupts: maxItems: 1 @@ -44,6 +50,8 @@ then: required: - clocks - clock-names +- resets +- reset-names additionalProperties: false @@ -68,4 +76,7 @@ examples: clocks = <_clk 18>; clock-names = "ipsec"; + +resets = <_rst 4>; +reset-names = "ipsec"; }; -- 2.20.1
[PATCH v6 1/3] dt-bindings: rng: bcm2835: add clock constraints
brcm,bcm6368-rng controllers require enabling the IPSEC clock in order to get a functional RNG. Signed-off-by: Álvaro Fernández Rojas --- v6: add new patch making clocks mandatory for BCM6368. .../devicetree/bindings/rng/brcm,bcm2835.yaml | 10 ++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml index c147900f9041..5174492e22f3 100644 --- a/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml +++ b/Documentation/devicetree/bindings/rng/brcm,bcm2835.yaml @@ -35,6 +35,16 @@ required: - compatible - reg +if: + properties: +compatible: + enum: +- brcm,bcm6368-rng +then: + required: +- clocks +- clock-names + additionalProperties: false examples: -- 2.20.1
[PATCH v6 0/3] hwrng: bcm2835: add reset support
Some devices may need to perform a reset before using the RNG, such as the BCM6368. v6: fix dt-bindings documentation, add patch makings clocks mandatory for BCM6368. v5: remove reset_control_rearm() and apply on latest herbert/cryptodev-2.6.git. v4: fix documentation, add reset_control_rearm(). v3: make resets required if brcm,bcm6368-rng. v2: document reset support. Álvaro Fernández Rojas (3): dt-bindings: rng: bcm2835: add clock constraints dt-bindings: rng: bcm2835: document reset support hwrng: bcm2835: add reset support .../devicetree/bindings/rng/brcm,bcm2835.yaml | 21 +++ drivers/char/hw_random/bcm2835-rng.c | 10 + 2 files changed, 31 insertions(+) -- 2.20.1
Re: [PATCH v6] i2c: virtio: add a virtio i2c frontend driver
On 2021/3/5 11:09, Viresh Kumar wrote:
On 05-03-21, 09:46, Jie Deng wrote:
On 2021/3/4 14:06, Viresh Kumar wrote:
depends on I2C as well ?
No need that. The dependency of I2C is included in the Kconfig in its parent
directory.
Sorry about that, I must have figured that out myself.
(Though a note on the way we reply to messages, please leave an empty line
before and after your messages, it gets difficult to find the inline replies
otherwise. )
+ if (!(req && req == [i])) {
I find this less readable compared to:
if (!req || req != [i]) {
Different people may have different tastes.
Please check Andy's comment in this link.
https://lists.linuxfoundation.org/pipermail/virtualization/2020-September/049933.html
Heh, everyone wants you to do it differently :)
If we leave compilers optimizations aside (because it will generate the exact
same code for both the cases, I tested it as well to be doubly sure), The
original statement used in this patch has 3 conditional statements in it and the
way I suggested has only two.
Andy, thoughts ?
And anyway, this isn't biggest of my worries, just that I had to notice it
somehow :)
For all the above errors where you simply break out, you still need to free the
memory for buf, right ?
Will try to use reqs[i].buf = msgs[i].buf to avoid allocation.
I think it would be better to have all such deallocations done at a single
place, i.e. after the completion callback is finished.. Trying to solve this
everywhere is going to make this more messy.
I think there is no need to have allocations/deallocations/memcpy for
reqs[i].buf any more
if using msgs[i].buf directly.
+ mutex_lock(>i2c_lock);
I have never worked with i2c stuff earlier, but I don't think you need a lock
here. The transactions seem to be serialized by the i2c-core by itself (look at
i2c_transfer() in i2c-core-base.c), though there is another exported version
__i2c_transfer() but the comment over it says the callers must take adapter lock
before calling it.
Lock is needed since no "lock_ops" is registered in this i2c_adapter.
drivers/i2c/i2c-core-base.c:
static int i2c_register_adapter(struct i2c_adapter *adap)
{
...
if (!adap->lock_ops)
adap->lock_ops = _adapter_lock_ops;
...
}
This should take care of it ?
The problem is that you can't guarantee that adap->algo->master_xfer is
only called
from i2c_transfer. Any function who holds the adapter can call
adap->algo->master_xfer
directly. So I think it is safer to have a lock in virtio_i2c_xfer.
+
+ ret = virtio_i2c_send_reqs(vq, reqs, msgs, num);
+ if (ret == 0)
+ goto err_unlock_free;
+
+ nr = ret;
+
+ virtqueue_kick(vq);
+
+ time_left = wait_for_completion_timeout(>completion, adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "virtio i2c backend timeout.\n");
+ ret = -ETIMEDOUT;
You need to free bufs of the requests here as well..
Just want to make sure you didn't miss this comment.
Will try to use msgs[i].buf directly. So it should be no free bufs any more.
+static struct i2c_adapter virtio_adapter = {
+ .owner = THIS_MODULE,
+ .name = "Virtio I2C Adapter",
+ .class = I2C_CLASS_DEPRECATED,
Why are we using something that is deprecated here ?
Warn users that the adapter doesn't support classes anymore.
So this is the right thing to do? Or this is what we expect from new drivers?
Sorry, I am just new to this stuff and so...
https://patchwork.ozlabs.org/project/linux-i2c/patch/20170729121143.3980-1-...@the-dreams.de/
+struct virtio_i2c_out_hdr {
+ __le16 addr;
+ __le16 padding;
+ __le32 flags;
+};
It might be worth setting __packed for the structures here, even when we have
taken care of padding ourselves, for both the structures..
Please check Michael's comment https://lkml.org/lkml/2020/9/3/339.
I agreed to remove "__packed" .
When Michael commented the structure looked like this:
Actually it can be ignored as the compiler isn't going to add any padding by
itself in this case (since you already took care of it) as the structure will be
aligned to the size of the biggest element here. I generally consider it to be a
good coding-style to make sure we don't add any unwanted stuff in there by
mistake.
Anyway, we can see it in future if this is going to be required or not, if and
when we add new fields here.
Re: [PATCH] MIPS: Support large stack.
在 2021/3/5 11:12, HongJieDeng 写道: From: Hongjie Deng We need more stack space, xori/ori no longer apply when _THREAD_MASK exceeds 16 bits Signed-off-by: Hongjie Deng --- arch/mips/include/asm/stackframe.h | 8 arch/mips/kernel/genex.S | 6 ++ 2 files changed, 14 insertions(+) diff --git a/arch/mips/include/asm/stackframe.h b/arch/mips/include/asm/stackframe.h index aa430a6..6ebc39f 100644 --- a/arch/mips/include/asm/stackframe.h +++ b/arch/mips/include/asm/stackframe.h @@ -278,8 +278,16 @@ sll k0, 3 /* extract cu0 bit */ bltzk0, 9f +#if_THREAD_MASK < (1 << 16 - 1) ori $28, sp, _THREAD_MASK xori$28, _THREAD_MASK +#else + li $28, _THREAD_MASK + or $28, sp, $28 + li $24, _THREAD_MASK + xor $28, $28, $24 Hi Hongjie, li breaks MIPS64, please try PTR_LI instead. Also loading immediate cost a lot on MIPS, you may save a unnecessary li by: + PTR_LI v1, _THREAD_MASK + or gp, sp, v1 + xor gp, gp, v1 Also clobber v0/v1 seems much more reasonable than $24 here +#endif + #ifdef CONFIG_CPU_CAVIUM_OCTEON .setmips64 pref0, 0($28) /* Prefetch the current pointer */ diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S index bcce32a..5ea4fe4 100644 --- a/arch/mips/kernel/genex.S +++ b/arch/mips/kernel/genex.S @@ -662,8 +662,14 @@ isrdhwr: #endif MTC0k0, CP0_EPC /* I hope three instructions between MTC0 and ERET are enough... */ +#if_THREAD_MASK < (1 << 16 - 1) ori k1, _THREAD_MASK xorik1, _THREAD_MASK +#else + li $24 ,_THREAD_MASK + or k1, k1, $24 + xor k1, k1, $24 +#endif Ditto. Actually another possible solution could be `.set at=v1` around it and let aeembler to decide if it needs a extra register. Thanks. - Jiaxun LONG_L v1, TI_TP_VALUE(k1) .setpush .setarch=r4000
RE: [PATCH V4 2/2] power: supply: bq27xxx: Add support for BQ78Z100
Hi Sebastian,
Thanks a lot for your input, I changed according your input in PATCH V5, please
review.
About "why 0x instead of just '0' like in the other entries?", since I
got an error from checkpatch.pl.
ERROR: space prohibited before that ',' (ctx:WxW)
#100: FILE: drivers/power/supply/bq27xxx_battery.c:1015:
+ [BQ78Z100] = BQ27XXX_DATA(bq78z100, 0 , BQ27Z561_O_BITS),
^
Best Regards
**
Li Qingwu (Terry)
Senior Embedded Software Engineer
Leica Geosystems(Shanghai)Co.,Limited
(Tel): +86 21 61061036
(FAX): +86 21 61061008
(Mobile): +86 187 0185 9600
E-mail: qing-wu...@leica-geosystems.com.cn
Http: www.leica-geosystems.com.cn
**
-Original Message-
From: Sebastian Reichel
Sent: Wednesday, March 3, 2021 12:22 AM
To: LI Qingwu
Cc: robh...@kernel.org; dmur...@ti.com; p...@kernel.org; k...@kernel.org;
linux...@vger.kernel.org; devicet...@vger.kernel.org;
linux-kernel@vger.kernel.org; TERTYCHNYI Grygorii
; ZHIZHIKIN Andrey
Subject: Re: [PATCH V4 2/2] power: supply: bq27xxx: Add support for BQ78Z100
Hi,
On Fri, Feb 05, 2021 at 07:10:04AM +, LI Qingwu wrote:
> Add support for TI BQ78Z100, I2C interface gas gauge.
> It provides a fully integrated safety protection and authentication
> for 1 to 2-series cell Li-Ion and Li-Polymer battery packs.
>
> The patch was tested with BQ78Z100 equipment.
>
> Reviewed-by: Krzysztof Kozlowski
> Signed-off-by: LI Qingwu
> ---
> drivers/power/supply/bq27xxx_battery.c | 46 +-
> drivers/power/supply/bq27xxx_battery_i2c.c | 2 +
> include/linux/power/bq27xxx_battery.h | 1 +
> 3 files changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/bq27xxx_battery.c
> b/drivers/power/supply/bq27xxx_battery.c
> index 315e0909e6a4..c8579ec7a4f8 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -39,6 +39,7 @@
> * https://www.ti.com/product/bq27z561
> * https://www.ti.com/product/bq28z610
> * https://www.ti.com/product/bq34z100-g1
> + * https://www.ti.com/product/bq78z100
> */
>
> #include
> @@ -497,7 +498,27 @@ static u8
> [BQ27XXX_REG_DCAP] = 0x3c,
> [BQ27XXX_REG_AP] = 0x22,
> BQ27XXX_DM_REG_ROWS,
> - };
> + },
> + bq78z100_regs[BQ27XXX_REG_MAX] = {
> + [BQ27XXX_REG_CTRL] = 0x00,
> + [BQ27XXX_REG_TEMP] = 0x06,
> + [BQ27XXX_REG_INT_TEMP] = 0x28,
> + [BQ27XXX_REG_VOLT] = 0x08,
> + [BQ27XXX_REG_AI] = 0x14,
> + [BQ27XXX_REG_FLAGS] = 0x0a,
> + [BQ27XXX_REG_TTE] = 0x16,
> + [BQ27XXX_REG_TTF] = 0x18,
> + [BQ27XXX_REG_TTES] = INVALID_REG_ADDR,
Datasheet states StandbyTimeToEmpty = 0x1C?
> + [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
> + [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
missing BQ27XXX_REG_RC. Looks like chip has support for it at address 0x10.
> + [BQ27XXX_REG_FCC] = 0x12,
> + [BQ27XXX_REG_CYCT] = 0x2a,
> + [BQ27XXX_REG_AE] = 0x22,
REG_AE is available energy. REG_AP is average power. Obviously two completley
different things and cannot be the same register.
A quick glance at the datasheet suggests AE does not exist.
> + [BQ27XXX_REG_SOC] = 0x2c,
> + [BQ27XXX_REG_DCAP] = 0x3c,
> + [BQ27XXX_REG_AP] = 0x22,
> + BQ27XXX_DM_REG_ROWS,
> +};
Please fix indention of };
>
> static enum power_supply_property bq27000_props[] = {
> POWER_SUPPLY_PROP_STATUS,
> @@ -792,6 +813,27 @@ static enum power_supply_property bq34z100_props[] = {
> POWER_SUPPLY_PROP_MANUFACTURER,
> };
>
> +static enum power_supply_property bq78z100_props[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> + POWER_SUPPLY_PROP_CAPACITY,
> + POWER_SUPPLY_PROP_CAPACITY_LEVEL,
> + POWER_SUPPLY_PROP_TEMP,
> + POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
> + POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG,
You are not providing data for this? (BQ27XXX_REG_TTECP is not set).
Please revisit the list of exposed properties and provide a dump of
/sys/class/power_supply//uevent in your submission.
Currently you should see some -ENODATA.
> + POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
> + POWER_SUPPLY_PROP_TECHNOLOGY,
> + POWER_SUPPLY_PROP_CHARGE_FULL,
> + POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
> + POWER_SUPPLY_PROP_CYCLE_COUNT,
> + POWER_SUPPLY_PROP_ENERGY_NOW,
> + POWER_SUPPLY_PROP_POWER_AVG,
> + POWER_SUPPLY_PROP_HEALTH,
> + POWER_SUPPLY_PROP_MANUFACTURER,
> +};
> +
> struct bq27xxx_dm_reg {
> u8 subclass_id;
> u8 offset;
> @@ -890,6 +932,7 @@ static struct bq27xxx_dm_reg bq27621_dm_regs[] = {
[PATCH] power: supply: cpcap-charger: Remove unnecessary conversion to bool
Fix the following coccicheck warnings: ./drivers/power/supply/cpcap-charger.c:468:31-36: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/power/supply/cpcap-charger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c index 641dcad..0437480 100644 --- a/drivers/power/supply/cpcap-charger.c +++ b/drivers/power/supply/cpcap-charger.c @@ -465,7 +465,7 @@ static bool cpcap_charger_vbus_valid(struct cpcap_charger_ddata *ddata) error = iio_read_channel_processed(channel, ); if (error >= 0) - return value > 3900 ? true : false; + return value > 3900; dev_err(ddata->dev, "error reading VBUS: %i\n", error); -- 1.8.3.1
[PATCH V5 2/2] power: supply: bq27xxx: Add support for BQ78Z100
Add support for TI BQ78Z100, I2C interface gas gauge.
It provides a fully integrated safety protection
and authentication for 1 to 2-series cell Li-Ion and
Li-Polymer battery packs.
The patch was tested with BQ78Z100 equipment.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: LI Qingwu
---
drivers/power/supply/bq27xxx_battery.c | 44 ++
drivers/power/supply/bq27xxx_battery_i2c.c | 2 +
include/linux/power/bq27xxx_battery.h | 1 +
3 files changed, 47 insertions(+)
diff --git a/drivers/power/supply/bq27xxx_battery.c
b/drivers/power/supply/bq27xxx_battery.c
index 4c4a7b1c64c5..05a4f9190160 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -39,6 +39,7 @@
* https://www.ti.com/product/bq27z561
* https://www.ti.com/product/bq28z610
* https://www.ti.com/product/bq34z100-g1
+ * https://www.ti.com/product/bq78z100
*/
#include
@@ -515,6 +516,27 @@ static u8
[BQ27XXX_REG_DCAP] = 0x3c,
[BQ27XXX_REG_AP] = 0x22,
BQ27XXX_DM_REG_ROWS,
+ },
+ bq78z100_regs[BQ27XXX_REG_MAX] = {
+ [BQ27XXX_REG_CTRL] = 0x00,
+ [BQ27XXX_REG_TEMP] = 0x06,
+ [BQ27XXX_REG_INT_TEMP] = 0x28,
+ [BQ27XXX_REG_VOLT] = 0x08,
+ [BQ27XXX_REG_AI] = 0x14,
+ [BQ27XXX_REG_FLAGS] = 0x0a,
+ [BQ27XXX_REG_TTE] = 0x16,
+ [BQ27XXX_REG_TTF] = 0x18,
+ [BQ27XXX_REG_TTES] = 0x1c,
+ [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
+ [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
+ [BQ27XXX_REG_RC] = 0x10,
+ [BQ27XXX_REG_FCC] = 0x12,
+ [BQ27XXX_REG_CYCT] = 0x2a,
+ [BQ27XXX_REG_AE] = INVALID_REG_ADDR,
+ [BQ27XXX_REG_SOC] = 0x2c,
+ [BQ27XXX_REG_DCAP] = 0x3c,
+ [BQ27XXX_REG_AP] = 0x22,
+ BQ27XXX_DM_REG_ROWS,
};
static enum power_supply_property bq27000_props[] = {
@@ -813,6 +835,26 @@ static enum power_supply_property bq34z100_props[] = {
POWER_SUPPLY_PROP_MANUFACTURER,
};
+static enum power_supply_property bq78z100_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_VOLTAGE_NOW,
+ POWER_SUPPLY_PROP_CURRENT_NOW,
+ POWER_SUPPLY_PROP_CAPACITY,
+ POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+ POWER_SUPPLY_PROP_TEMP,
+ POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+ POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CHARGE_FULL,
+ POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
+ POWER_SUPPLY_PROP_CYCLE_COUNT,
+ POWER_SUPPLY_PROP_ENERGY_NOW,
+ POWER_SUPPLY_PROP_POWER_AVG,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_MANUFACTURER,
+};
+
struct bq27xxx_dm_reg {
u8 subclass_id;
u8 offset;
@@ -911,6 +953,7 @@ static struct bq27xxx_dm_reg bq27621_dm_regs[] = {
#define bq27z561_dm_regs 0
#define bq28z610_dm_regs 0
#define bq34z100_dm_regs 0
+#define bq78z100_dm_regs 0
#define BQ27XXX_O_ZERO BIT(0)
#define BQ27XXX_O_OTDC BIT(1) /* has OTC/OTD overtemperature flags */
@@ -969,6 +1012,7 @@ static struct {
[BQ28Z610] = BQ27XXX_DATA(bq28z610, 0 , BQ27Z561_O_BITS),
[BQ34Z100] = BQ27XXX_DATA(bq34z100, 0 , BQ27XXX_O_OTDC |
BQ27XXX_O_SOC_SI | \
BQ27XXX_O_HAS_CI |
BQ27XXX_O_MUL_CHEM),
+ [BQ78Z100] = BQ27XXX_DATA(bq78z100, 0x, BQ27Z561_O_BITS),
};
static DEFINE_MUTEX(bq27xxx_list_lock);
diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c
b/drivers/power/supply/bq27xxx_battery_i2c.c
index eb4f4284982f..46f078350fd3 100644
--- a/drivers/power/supply/bq27xxx_battery_i2c.c
+++ b/drivers/power/supply/bq27xxx_battery_i2c.c
@@ -248,6 +248,7 @@ static const struct i2c_device_id bq27xxx_i2c_id_table[] = {
{ "bq27z561", BQ27Z561 },
{ "bq28z610", BQ28Z610 },
{ "bq34z100", BQ34Z100 },
+ { "bq78z100", BQ78Z100 },
{},
};
MODULE_DEVICE_TABLE(i2c, bq27xxx_i2c_id_table);
@@ -284,6 +285,7 @@ static const struct of_device_id
bq27xxx_battery_i2c_of_match_table[] = {
{ .compatible = "ti,bq27z561" },
{ .compatible = "ti,bq28z610" },
{ .compatible = "ti,bq34z100" },
+ { .compatible = "ti,bq78z100" },
{},
};
MODULE_DEVICE_TABLE(of, bq27xxx_battery_i2c_of_match_table);
diff --git a/include/linux/power/bq27xxx_battery.h
b/include/linux/power/bq27xxx_battery.h
index 111a40d0d3d5..ac17618043b1 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -33,6 +33,7 @@ enum bq27xxx_chip {
BQ27Z561,
BQ28Z610,
BQ34Z100,
+ BQ78Z100,
};
struct bq27xxx_device_info;
--
2.17.1
[PATCH V5 0/2] power: bq27xxx: add bq78z100
Changes in V5: 1. Change [BQ27XXX_REG_TTES] from INVALID_REG_ADDR to 0x1c, the StandbyTimeToEmpty command of bq78z100. 2. Add [BQ27XXX_REG_RC] = 0x10. the RemainingCapacity command of bq78z100. 3. Set [BQ27XXX_REG_AE] to INVALID_REG_ADDR, support by bq78z100. 4. Delete property POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG, not support by bq78z100 LI Qingwu (2): dt-bindings: power: bq27xxx: add bq78z100 power: supply: bq27xxx: Add support for BQ78Z100 .../bindings/power/supply/bq27xxx.yaml| 1 + drivers/power/supply/bq27xxx_battery.c| 44 +++ drivers/power/supply/bq27xxx_battery_i2c.c| 2 + include/linux/power/bq27xxx_battery.h | 1 + 4 files changed, 48 insertions(+) -- 2.17.1
[PATCH V5 1/2] dt-bindings: power: bq27xxx: add bq78z100
Add bindings for TI BQ78Z100. An I2C interface gas gauge. It provides a fully integrated safety protection and authentication for 1 to 2-series cell Li-Ion and Li-Polymer battery packs. Acked-by: Rob Herring Signed-off-by: LI Qingwu --- Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml index 45beefccf31a..712e974b28b6 100644 --- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml +++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml @@ -52,6 +52,7 @@ properties: - ti,bq27z561 - ti,bq28z610 - ti,bq34z100 + - ti,bq78z100 reg: maxItems: 1 -- 2.17.1
Re: [PATCH 1/2] erofs: avoid memory allocation failure during rolling decompression
On Fri, Mar 05, 2021 at 02:22:18PM +0800, Huang Jianan via Linux-erofs wrote:
> It should be better to ensure memory allocation during rolling
> decompression to avoid io error.
Currently, err would be treated as io error. Therefore, it'd be
better to ensure memory allocation during rolling decompression
to avoid such io error.
In the long term, we might consider adding another !Uptodate case
for such case.
>
> Signed-off-by: Huang Jianan
> Signed-off-by: Guo Weichao
> ---
> fs/erofs/decompressor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
> index 49347e681a53..fb0fa4e5b9ea 100644
> --- a/fs/erofs/decompressor.c
> +++ b/fs/erofs/decompressor.c
> @@ -86,7 +86,7 @@ static int z_erofs_lz4_prepare_destpages(struct
> z_erofs_decompress_req *rq,
> victim = availables[--top];
> get_page(victim);
> } else {
> - victim = erofs_allocpage(pagepool, GFP_KERNEL);
> + victim = erofs_allocpage(pagepool, GFP_KERNEL |
> __GFP_NOFAIL);
80 char limitation.
Thanks,
Gao Xiang
> if (!victim)
> return -ENOMEM;
> set_page_private(victim, Z_EROFS_SHORTLIVED_PAGE);
> --
> 2.25.1
>
Re: [PATCH 2/4] kbuild: collect minimum tool versions into scripts/tool-version.sh
On Fri, Mar 5, 2021 at 7:10 AM Nicolas Pitre wrote: > > On Thu, 4 Mar 2021, Masahiro Yamada wrote: > > > The kernel build uses various tools, many of which are provided by the > > same software suite, for example, LLVM and Binutils. > > > > When we raise the minimal version of Clang/LLVM, we need to update > > clang_min_version in scripts/cc-version.sh and also lld_min_version in > > scripts/ld-version.sh. > > > > In fact, Kbuild can handle CC=clang and LD=ld.lld independently, and we > > could manage their minimal version separately, but it does not make > > much sense. > > > > Make scripts/tool-version.sh a central place of minimum tool versions > > so that we do not need to touch multiple files. > > It would be better and self-explanatory if a script that provides the > minimum version of a tool was actually called ... min_tool-version.sh or > the like. Otherwise one might think it would give e.g. the current > version of installed tools. > > > Nicolas You are right. I will rename it. -- Best Regards Masahiro Yamada
Re: futex breakage in 4.9 stable branch
On Thu, 2021-03-04 at 19:47 +0100, Thomas Gleixner wrote:
> On Thu, Mar 04 2021 at 10:12, Mike Galbraith wrote:
> > On Mon, 2021-03-01 at 18:29 +0100, Ben Hutchings wrote:
> >
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -874,8 +874,12 @@ static void free_pi_state(struct futex_p
> > * and has cleaned up the pi_state already
> > */
> > if (pi_state->owner) {
> > + unsigned long flags;
> > +
> > + raw_spin_lock_irqsave(_state->pi_mutex.wait_lock, flags);
> > pi_state_update_owner(pi_state, NULL);
> > rt_mutex_proxy_unlock(_state->pi_mutex);
> > + raw_spin_unlock_irqrestore(_state->pi_mutex.wait_lock,
> > flags);
>
> This hunk is missing in 4.9 as well.
>
> > }
> >
> > if (current->pi_state_cache)
> > @@ -1406,7 +1410,7 @@ static int wake_futex_pi(u32 __user *uad
> > if (pi_state->owner != current)
> > return -EINVAL;
> >
> > - raw_spin_lock(_state->pi_mutex.wait_lock);
> > + raw_spin_lock_irq(_state->pi_mutex.wait_lock);
> > new_owner = rt_mutex_next_owner(_state->pi_mutex);
> >
> > /*
>
> That looks correct.
Thanks for the eyeballs. FWIW, updated 4.4.259-rt214 on top of that is
a happy camper as well.
-Mike
Re: [PATCH 2/4] kbuild: collect minimum tool versions into scripts/tool-version.sh
On Thu, Mar 4, 2021 at 9:11 AM Nathan Chancellor wrote:
>
> On Thu, Mar 04, 2021 at 03:33:31AM +0900, Masahiro Yamada wrote:
> > The kernel build uses various tools, many of which are provided by the
> > same software suite, for example, LLVM and Binutils.
> >
> > When we raise the minimal version of Clang/LLVM, we need to update
> > clang_min_version in scripts/cc-version.sh and also lld_min_version in
> > scripts/ld-version.sh.
> >
> > In fact, Kbuild can handle CC=clang and LD=ld.lld independently, and we
> > could manage their minimal version separately, but it does not make
> > much sense.
> >
> > Make scripts/tool-version.sh a central place of minimum tool versions
> > so that we do not need to touch multiple files.
> >
> > This script prints the minimal version of the given tool.
> >
> > $ scripts/tool-version.sh gcc
> > 4.9.0
> > $ scripts/tool-version.sh llvm
> > 10.0.1
> > $ scripts/tool-version.sh binutils
> > 2.23.0
> > $ scripts/tool-version.sh foo
> > foo: unknown tool
> >
> > Signed-off-by: Masahiro Yamada
>
> Reviewed-by: Nathan Chancellor
>
> Two comments below.
>
> > ---
> >
> > scripts/cc-version.sh | 20 +---
> > scripts/ld-version.sh | 11 ---
> > scripts/tool-version.sh | 27 +++
> > 3 files changed, 36 insertions(+), 22 deletions(-)
> > create mode 100755 scripts/tool-version.sh
> >
> > diff --git a/scripts/cc-version.sh b/scripts/cc-version.sh
> > index 3f2ee885b116..4772f1ef9cac 100755
> > --- a/scripts/cc-version.sh
> > +++ b/scripts/cc-version.sh
> > @@ -6,18 +6,6 @@
> >
> > set -e
> >
> > -# When you raise the minimum compiler version, please update
> > -# Documentation/process/changes.rst as well.
> > -gcc_min_version=4.9.0
> > -clang_min_version=10.0.1
> > -icc_min_version=16.0.3 # temporary
> > -
> > -# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293
> > -# https://lore.kernel.org/r/20210107111841.gn1...@shell.armlinux.org.uk
> > -if [ "$SRCARCH" = arm64 ]; then
> > - gcc_min_version=5.1.0
> > -fi
> > -
> > # Print the compiler name and some version components.
> > get_compiler_info()
> > {
> > @@ -48,18 +36,20 @@ set -- $(get_compiler_info "$@")
> >
> > name=$1
> >
> > +tool_version=$(dirname $0)/tool-version.sh
>
> I realize these scripts are currently called by their full path but is
> it worth making this '$(dirname "$(readlink -f "$0")")' here and in
> ld-version.sh just in case that does not happen?
Not sure.
A relative path still works.
So, I did not do what I did not need to do.
> > case "$name" in
> > GCC)
> > version=$2.$3.$4
> > - min_version=$gcc_min_version
> > + min_version=$($tool_version gcc)
> > ;;
> > Clang)
> > version=$2.$3.$4
> > - min_version=$clang_min_version
> > + min_version=$($tool_version llvm)
> > ;;
> > ICC)
> > version=$(($2 / 100)).$(($2 % 100)).$3
> > - min_version=$icc_min_version
> > + min_version=$($tool_version icc)
> > ;;
> > *)
> > echo "$orig_args: unknown compiler" >&2
> > diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
> > index a463273509b5..e824f7675693 100755
> > --- a/scripts/ld-version.sh
> > +++ b/scripts/ld-version.sh
> > @@ -6,11 +6,6 @@
> >
> > set -e
> >
> > -# When you raise the minimum linker version, please update
> > -# Documentation/process/changes.rst as well.
> > -bfd_min_version=2.23.0
> > -lld_min_version=10.0.1
> > -
> > # Convert the version string x.y.z to a canonical 5 or 6-digit form.
> > get_canonical_version()
> > {
> > @@ -35,10 +30,12 @@ set -- $("$@" --version)
> > IFS=' '
> > set -- $1
> >
> > +tool_version=$(dirname $0)/tool-version.sh
> > +
> > if [ "$1" = GNU -a "$2" = ld ]; then
> > shift $(($# - 1))
> > version=$1
> > - min_version=$bfd_min_version
> > + min_version=$($tool_version binutils)
> > name=BFD
> > disp_name="GNU ld"
> > elif [ "$1" = GNU -a "$2" = gold ]; then
> > @@ -46,7 +43,7 @@ elif [ "$1" = GNU -a "$2" = gold ]; then
> > exit 1
> > elif [ "$1" = LLD ]; then
> > version=$2
> > - min_version=$lld_min_version
> > + min_version=$($tool_version llvm)
> > name=LLD
> > disp_name=LLD
> > else
> > diff --git a/scripts/tool-version.sh b/scripts/tool-version.sh
> > new file mode 100755
> > index ..b4aa27e2c3d3
> > --- /dev/null
> > +++ b/scripts/tool-version.sh
> > @@ -0,0 +1,27 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +#
> > +# Print the minimum supported version of the given tool.
> > +
> > +set -e
> > +
> > +# When you raise the minimum version, please update
> > +# Documentation/process/changes.rst as well.
> > +gcc_min_version=4.9.0
> > +llvm_min_version=10.0.1
> > +icc_min_version=16.0.3 # temporary
> > +binutils_min_version=2.23.0
> > +
> > +# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293
> > +# https://lore.kernel.org/r/20210107111841.gn1...@shell.armlinux.org.uk
> > +if [ "$SRCARCH" = arm64 ]; then
> >
Re: [PATCH 2/2] erofs: decompress in endio if possible
On Fri, Mar 05, 2021 at 02:22:19PM +0800, Huang Jianan via Linux-erofs wrote:
> z_erofs_decompressqueue_endio may not be executed in the interrupt
> context, for example, when dm-verity is turned on. In this scenario,
> io should be decompressed directly to avoid additional scheduling
> overhead. Also there is no need to wait for endio to execute
> synchronous decompression.
z_erofs_decompressqueue_endio may not be executed in the atomic
context, for example, when dm-verity is turned on. In this scenario,
data can be decompressed directly to get rid of additional kworker
scheduling overhead. Also, it makes no sense to apply synchronous
decompression for such case.
>
> Signed-off-by: Huang Jianan
> Signed-off-by: Guo Weichao
> ---
> fs/erofs/internal.h | 3 ++
> fs/erofs/super.c| 1 +
> fs/erofs/zdata.c| 102
> 3 files changed, 60 insertions(+), 46 deletions(-)
>
> diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
> index 77965490dced..a19bcbb681fc 100644
> --- a/fs/erofs/internal.h
> +++ b/fs/erofs/internal.h
> @@ -71,6 +71,9 @@ struct erofs_sb_info {
> /* pseudo inode to manage cached pages */
> struct inode *managed_cache;
>
> + /* decide whether to decompress synchronously */
> + bool sync_decompress;
bool readahead_sync_decompress;
> +
> /* # of pages needed for EROFS lz4 rolling decompression */
> u16 lz4_max_distance_pages;
> #endif /* CONFIG_EROFS_FS_ZIP */
> diff --git a/fs/erofs/super.c b/fs/erofs/super.c
> index 37f1cc9d28cc..5b9a21d10a30 100644
> --- a/fs/erofs/super.c
> +++ b/fs/erofs/super.c
> @@ -188,6 +188,7 @@ static int erofs_read_superblock(struct super_block *sb)
> goto out;
> }
>
> + sbi->sync_decompress = false;
Ah, could you rebase the patch on the top of 5.12-rc1
rather than dev-test? since I've fold your
"erofs: support adjust lz4 history window size"
into a new patchset, see:
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/linux.git/log/?h=erofs/compr_cfgs
> /* parse on-disk compression configurations */
> z_erofs_load_lz4_config(sbi, dsb);
> ret = 0;
> diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
> index 6cb356c4217b..727dd01f55c1 100644
> --- a/fs/erofs/zdata.c
> +++ b/fs/erofs/zdata.c
> @@ -706,56 +706,11 @@ static int z_erofs_do_read_page(struct
> z_erofs_decompress_frontend *fe,
> goto out;
> }
>
> -static void z_erofs_decompress_kickoff(struct z_erofs_decompressqueue *io,
> -bool sync, int bios)
> -{
> - /* wake up the caller thread for sync decompression */
> - if (sync) {
> - unsigned long flags;
> -
> - spin_lock_irqsave(>u.wait.lock, flags);
> - if (!atomic_add_return(bios, >pending_bios))
> - wake_up_locked(>u.wait);
> - spin_unlock_irqrestore(>u.wait.lock, flags);
> - return;
> - }
> -
> - if (!atomic_add_return(bios, >pending_bios))
> - queue_work(z_erofs_workqueue, >u.work);
> -}
Is it necessary to move the code snippet?
> -
> static bool z_erofs_page_is_invalidated(struct page *page)
> {
> return !page->mapping && !z_erofs_is_shortlived_page(page);
> }
>
> -static void z_erofs_decompressqueue_endio(struct bio *bio)
> -{
> - tagptr1_t t = tagptr_init(tagptr1_t, bio->bi_private);
> - struct z_erofs_decompressqueue *q = tagptr_unfold_ptr(t);
> - blk_status_t err = bio->bi_status;
> - struct bio_vec *bvec;
> - struct bvec_iter_all iter_all;
> -
> - bio_for_each_segment_all(bvec, bio, iter_all) {
> - struct page *page = bvec->bv_page;
> -
> - DBG_BUGON(PageUptodate(page));
> - DBG_BUGON(z_erofs_page_is_invalidated(page));
> -
> - if (err)
> - SetPageError(page);
> -
> - if (erofs_page_is_managed(EROFS_SB(q->sb), page)) {
> - if (!err)
> - SetPageUptodate(page);
> - unlock_page(page);
> - }
> - }
> - z_erofs_decompress_kickoff(q, tagptr_unfold_tags(t), -1);
> - bio_put(bio);
> -}
> -
> static int z_erofs_decompress_pcluster(struct super_block *sb,
> struct z_erofs_pcluster *pcl,
> struct list_head *pagepool)
> @@ -991,6 +946,60 @@ static void z_erofs_decompressqueue_work(struct
> work_struct *work)
> kvfree(bgq);
> }
>
> +static void z_erofs_decompress_kickoff(struct z_erofs_decompressqueue *io,
> +bool sync, int bios)
> +{
> + struct erofs_sb_info *const sbi = EROFS_SB(io->sb);
> +
> + /* wake up the caller thread for sync decompression */
> + if (sync) {
> + unsigned long flags;
> +
> + spin_lock_irqsave(>u.wait.lock, flags);
> + if (!atomic_add_return(bios, >pending_bios))
> +
[PATCH] drm/amd/display: Remove unnecessary conversion to bool
Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:8257:16-21: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3e1fd1e..10de6c2 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -8307,8 +8307,7 @@ static void amdgpu_dm_atomic_commit_tail(struct drm_atomic_state *state) hdcp_update_display( adev->dm.hdcp_workqueue, aconnector->dc_link->link_index, aconnector, new_con_state->hdcp_content_type, - new_con_state->content_protection == DRM_MODE_CONTENT_PROTECTION_DESIRED ? true - : false); + new_con_state->content_protection == DRM_MODE_CONTENT_PROTECTION_DESIRED); } #endif -- 1.8.3.1
Re: [PATCH v1] powerpc: Include running function as first entry in save_stack_trace() and friends
Le 04/03/2021 à 20:24, Segher Boessenkool a écrit :
On Thu, Mar 04, 2021 at 09:54:44AM -0800, Nick Desaulniers wrote:
On Thu, Mar 4, 2021 at 9:42 AM Marco Elver wrote:
include/linux/compiler.h:246:
prevent_tail_call_optimization
commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")
https://github.com/linuxppc/linux/commit/a9a3ed1eff36
That is much heavier than needed (an mb()). You can just put an empty
inline asm after a call before a return, and that call cannot be
optimised to a sibling call: (the end of a function is an implicit
return:)
Instead of:
void g(void);
void f(int x)
if (x)
g();
}
Do:
void g(void);
void f(int x)
if (x)
g();
asm("");
}
This costs no extra instructions, and certainly not something as heavy
as an mb()! It works without the "if" as well, of course, but with it
it is a more interesting example of a tail call.
In the commit mentionned at the top, it is said:
The next attempt to prevent compilers from tail-call optimizing
the last function call cpu_startup_entry(), ... , was to add an empty asm("").
This current solution was short and sweet, and reportedly, is supported
by both compilers but we didn't get very far this time: future (LTO?)
optimization passes could potentially eliminate this, which leads us
to the third attempt: having an actual memory barrier there which the
compiler cannot ignore or move around etc.
Christophe
Re: [RFC PATCH 4/12] HV: Add Write/Read MSR registers via ghcb
On 3/4/2021 1:16 AM, Vitaly Kuznetsov wrote:
Tianyu Lan writes:
From: Tianyu Lan
Hyper-V provides GHCB protocol to write Synthetic Interrupt
Controller MSR registers and these registers are emulated by
Hypervisor rather than paravisor.
Hyper-V requests to write SINTx MSR registers twice(once via
GHCB and once via wrmsr instruction including the proxy bit 21)
Guest OS ID MSR also needs to be set via GHCB.
Signed-off-by: Tianyu Lan
---
arch/x86/hyperv/Makefile| 2 +-
arch/x86/hyperv/hv_init.c | 18 +--
arch/x86/hyperv/ivm.c | 178 ++
arch/x86/include/asm/mshyperv.h | 21 +++-
arch/x86/kernel/cpu/mshyperv.c | 46
drivers/hv/channel.c| 2 +-
drivers/hv/hv.c | 188 ++--
include/asm-generic/mshyperv.h | 10 +-
8 files changed, 343 insertions(+), 122 deletions(-)
create mode 100644 arch/x86/hyperv/ivm.c
diff --git a/arch/x86/hyperv/Makefile b/arch/x86/hyperv/Makefile
index 48e2c51464e8..5d2de10809ae 100644
--- a/arch/x86/hyperv/Makefile
+++ b/arch/x86/hyperv/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-y := hv_init.o mmu.o nested.o irqdomain.o
+obj-y := hv_init.o mmu.o nested.o irqdomain.o ivm.o
obj-$(CONFIG_X86_64) += hv_apic.o hv_proc.o
ifdef CONFIG_X86_64
diff --git a/arch/x86/hyperv/hv_init.c b/arch/x86/hyperv/hv_init.c
index 90e65fbf4c58..87b1dd9c84d6 100644
--- a/arch/x86/hyperv/hv_init.c
+++ b/arch/x86/hyperv/hv_init.c
@@ -475,6 +475,9 @@ void __init hyperv_init(void)
ghcb_base = (void **)this_cpu_ptr(ms_hyperv.ghcb_base);
*ghcb_base = ghcb_va;
+
+ /* Hyper-V requires to write guest os id via ghcb in SNP IVM. */
+ hv_ghcb_msr_write(HV_X64_MSR_GUEST_OS_ID, guest_id);
}
rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
@@ -561,6 +564,7 @@ void hyperv_cleanup(void)
/* Reset our OS id */
wrmsrl(HV_X64_MSR_GUEST_OS_ID, 0);
+ hv_ghcb_msr_write(HV_X64_MSR_GUEST_OS_ID, 0);
/*
* Reset hypercall page reference before reset the page,
@@ -668,17 +672,3 @@ bool hv_is_hibernation_supported(void)
return !hv_root_partition && acpi_sleep_state_supported(ACPI_STATE_S4);
}
EXPORT_SYMBOL_GPL(hv_is_hibernation_supported);
-
-enum hv_isolation_type hv_get_isolation_type(void)
-{
- if (!(ms_hyperv.features_b & HV_ISOLATION))
- return HV_ISOLATION_TYPE_NONE;
- return FIELD_GET(HV_ISOLATION_TYPE, ms_hyperv.isolation_config_b);
-}
-EXPORT_SYMBOL_GPL(hv_get_isolation_type);
-
-bool hv_is_isolation_supported(void)
-{
- return hv_get_isolation_type() != HV_ISOLATION_TYPE_NONE;
-}
-EXPORT_SYMBOL_GPL(hv_is_isolation_supported);
diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
new file mode 100644
index ..4332bf7aaf9b
--- /dev/null
+++ b/arch/x86/hyperv/ivm.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Hyper-V Isolation VM interface with paravisor and hypervisor
+ *
+ * Author:
+ * Tianyu Lan
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+union hv_ghcb {
+ struct ghcb ghcb;
+} __packed __aligned(PAGE_SIZE);
+
+void hv_ghcb_msr_write(u64 msr, u64 value)
+{
+ union hv_ghcb *hv_ghcb;
+ void **ghcb_base;
+ unsigned long flags;
+
+ if (!ms_hyperv.ghcb_base)
+ return;
+
+ local_irq_save(flags);
+ ghcb_base = (void **)this_cpu_ptr(ms_hyperv.ghcb_base);
+ hv_ghcb = (union hv_ghcb *)*ghcb_base;
+ if (!hv_ghcb) {
+ local_irq_restore(flags);
+ return;
+ }
+
+ memset(hv_ghcb, 0x00, HV_HYP_PAGE_SIZE);
+
+ hv_ghcb->ghcb.protocol_version = 1;
+ hv_ghcb->ghcb.ghcb_usage = 0;
+
+ ghcb_set_sw_exit_code(_ghcb->ghcb, SVM_EXIT_MSR);
+ ghcb_set_rcx(_ghcb->ghcb, msr);
+ ghcb_set_rax(_ghcb->ghcb, lower_32_bits(value));
+ ghcb_set_rdx(_ghcb->ghcb, value >> 32);
+ ghcb_set_sw_exit_info_1(_ghcb->ghcb, 1);
+ ghcb_set_sw_exit_info_2(_ghcb->ghcb, 0);
+
+ VMGEXIT();
+
+ if ((hv_ghcb->ghcb.save.sw_exit_info_1 & 0x) == 1)
+ pr_warn("Fail to write msr via ghcb.\n.");
+
+ local_irq_restore(flags);
+}
+EXPORT_SYMBOL_GPL(hv_ghcb_msr_write);
+
+void hv_ghcb_msr_read(u64 msr, u64 *value)
+{
+ union hv_ghcb *hv_ghcb;
+ void **ghcb_base;
+ unsigned long flags;
+
+ if (!ms_hyperv.ghcb_base)
+ return;
+
+ local_irq_save(flags);
+ ghcb_base = (void **)this_cpu_ptr(ms_hyperv.ghcb_base);
+ hv_ghcb = (union hv_ghcb *)*ghcb_base;
+ if (!hv_ghcb) {
+ local_irq_restore(flags);
+ return;
+ }
+
+ memset(hv_ghcb, 0x00, PAGE_SIZE);
+ hv_ghcb->ghcb.protocol_version = 1;
+ hv_ghcb->ghcb.ghcb_usage = 0;
+
+ ghcb_set_sw_exit_code(_ghcb->ghcb,
[PATCH v2 0/2] crypto: qat - fixes related to 'dma_map_single'
This patchset fix bugs related to 'dma_map_single' use: Hui Tang (2): crypto: qat - fix 'dma_unmap_single' invalid address crypto: qat - fix use of 'dma_map_single' v1 -> v2: 1.fix build warning reported by kernel test rebot 2.add patch #1 drivers/crypto/qat/qat_common/qat_algs.c | 32 1 file changed, 20 insertions(+), 12 deletions(-) -- 2.8.1
[PATCH v2 2/2] crypto: qat - fix use of 'dma_map_single'
DMA_TO_DEVICE synchronisation must be done after the last modification
of the memory region by the software and before it is handed off to
the device.
Signed-off-by: Hui Tang
Reported-by: kernel test robot
Reported-by: Dan Carpenter
---
drivers/crypto/qat/qat_common/qat_algs.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index ea1c689..f998ed5 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -718,8 +718,8 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
int n = sg_nents(sgl);
struct qat_alg_buf_list *bufl;
struct qat_alg_buf_list *buflout = NULL;
- dma_addr_t blp;
- dma_addr_t bloutp;
+ dma_addr_t blp = DMA_MAPPING_ERROR;
+ dma_addr_t bloutp = DMA_MAPPING_ERROR;
struct scatterlist *sg;
size_t sz_out, sz = struct_size(bufl, bufers, n + 1);
@@ -734,10 +734,6 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
for_each_sg(sgl, sg, n, i)
bufl->bufers[i].addr = DMA_MAPPING_ERROR;
- blp = dma_map_single(dev, bufl, sz, DMA_TO_DEVICE);
- if (unlikely(dma_mapping_error(dev, blp)))
- goto err_in;
-
for_each_sg(sgl, sg, n, i) {
int y = sg_nctr;
@@ -753,6 +749,9 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
sg_nctr++;
}
bufl->num_bufs = sg_nctr;
+ blp = dma_map_single(dev, bufl, sz, DMA_TO_DEVICE);
+ if (unlikely(dma_mapping_error(dev, blp)))
+ goto err_in;
qat_req->buf.bl = bufl;
qat_req->buf.blp = blp;
qat_req->buf.sz = sz;
@@ -772,9 +771,6 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
for_each_sg(sglout, sg, n, i)
bufers[i].addr = DMA_MAPPING_ERROR;
- bloutp = dma_map_single(dev, buflout, sz_out, DMA_TO_DEVICE);
- if (unlikely(dma_mapping_error(dev, bloutp)))
- goto err_out;
for_each_sg(sglout, sg, n, i) {
int y = sg_nctr;
@@ -791,6 +787,9 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
}
buflout->num_bufs = sg_nctr;
buflout->num_mapped_bufs = sg_nctr;
+ bloutp = dma_map_single(dev, buflout, sz_out, DMA_TO_DEVICE);
+ if (unlikely(dma_mapping_error(dev, bloutp)))
+ goto err_out;
qat_req->buf.blout = buflout;
qat_req->buf.bloutp = bloutp;
qat_req->buf.sz_out = sz_out;
@@ -802,17 +801,21 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
return 0;
err_out:
+ if (!dma_mapping_error(dev, bloutp))
+ dma_unmap_single(dev, bloutp, sz_out, DMA_TO_DEVICE);
+
n = sg_nents(sglout);
for (i = 0; i < n; i++)
if (!dma_mapping_error(dev, buflout->bufers[i].addr))
dma_unmap_single(dev, buflout->bufers[i].addr,
buflout->bufers[i].len,
DMA_BIDIRECTIONAL);
- if (!dma_mapping_error(dev, bloutp))
- dma_unmap_single(dev, bloutp, sz_out, DMA_TO_DEVICE);
kfree(buflout);
err_in:
+ if (!dma_mapping_error(dev, blp))
+ dma_unmap_single(dev, blp, sz, DMA_TO_DEVICE);
+
n = sg_nents(sgl);
for (i = 0; i < n; i++)
if (!dma_mapping_error(dev, bufl->bufers[i].addr))
@@ -820,8 +823,6 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
bufl->bufers[i].len,
DMA_BIDIRECTIONAL);
- if (!dma_mapping_error(dev, blp))
- dma_unmap_single(dev, blp, sz, DMA_TO_DEVICE);
kfree(bufl);
dev_err(dev, "Failed to map buf for dma\n");
--
2.8.1
[PATCH v2 1/2] crypto: qat - fix unmap invalid dma address
'dma_mapping_error' return a negative value if 'dma_addr' is equal to
'DMA_MAPPING_ERROR' not zero, so fix initialization of 'dma_addr'.
Signed-off-by: Hui Tang
---
drivers/crypto/qat/qat_common/qat_algs.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/crypto/qat/qat_common/qat_algs.c
index ff78c73..ea1c689 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -719,7 +719,7 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
struct qat_alg_buf_list *bufl;
struct qat_alg_buf_list *buflout = NULL;
dma_addr_t blp;
- dma_addr_t bloutp = 0;
+ dma_addr_t bloutp;
struct scatterlist *sg;
size_t sz_out, sz = struct_size(bufl, bufers, n + 1);
@@ -731,6 +731,9 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
if (unlikely(!bufl))
return -ENOMEM;
+ for_each_sg(sgl, sg, n, i)
+ bufl->bufers[i].addr = DMA_MAPPING_ERROR;
+
blp = dma_map_single(dev, bufl, sz, DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(dev, blp)))
goto err_in;
@@ -764,10 +767,14 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance
*inst,
dev_to_node(_DEV(inst->accel_dev)));
if (unlikely(!buflout))
goto err_in;
+
+ bufers = buflout->bufers;
+ for_each_sg(sglout, sg, n, i)
+ bufers[i].addr = DMA_MAPPING_ERROR;
+
bloutp = dma_map_single(dev, buflout, sz_out, DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(dev, bloutp)))
goto err_out;
- bufers = buflout->bufers;
for_each_sg(sglout, sg, n, i) {
int y = sg_nctr;
--
2.8.1
Re: WARNING in ieee802154_get_llsec_params
syzbot has bisected this issue to:
commit b60673c4c418bef7550d02faf53c34fbfeb366bf
Author: Jakub Kicinski
Date: Tue Mar 3 05:05:15 2020 +
nl802154: add missing attribute validation for dev_type
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=100b11b0d0
start commit: f5427c24 Add linux-next specific files for 20210304
git tree: linux-next
final oops: https://syzkaller.appspot.com/x/report.txt?x=120b11b0d0
console output: https://syzkaller.appspot.com/x/log.txt?x=140b11b0d0
kernel config: https://syzkaller.appspot.com/x/.config?x=a7876f68bf0bea99
dashboard link: https://syzkaller.appspot.com/bug?extid=cde43a581a8e5f317bc2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=124c7b46d0
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1276f5b0d0
Reported-by: syzbot+cde43a581a8e5f317...@syzkaller.appspotmail.com
Fixes: b60673c4c418 ("nl802154: add missing attribute validation for dev_type")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Re: [PATCH v3 7/9] KVM: vmx/pmu: Add Arch LBR emulation and its VMCS field
On 2021/3/5 1:23, Sean Christopherson wrote: On Thu, Mar 04, 2021, Xu, Like wrote: On 2021/3/4 1:26, Sean Christopherson wrote: On Wed, Mar 03, 2021, Like Xu wrote: New VMX controls bits for Arch LBR are added. When bit 21 in vmentry_ctrl is set, VM entry will write the value from the "Guest IA32_LBR_CTL" guest state field to IA32_LBR_CTL. When bit 26 in vmexit_ctrl is set, VM exit will clear IA32_LBR_CTL after the value has been saved to the "Guest IA32_LBR_CTL" guest state field. ... @@ -2529,7 +2532,8 @@ static __init int setup_vmcs_config(struct vmcs_config *vmcs_conf, VM_EXIT_LOAD_IA32_EFER | VM_EXIT_CLEAR_BNDCFGS | VM_EXIT_PT_CONCEAL_PIP | - VM_EXIT_CLEAR_IA32_RTIT_CTL; + VM_EXIT_CLEAR_IA32_RTIT_CTL | + VM_EXIT_CLEAR_IA32_LBR_CTL; So, how does MSR_ARCH_LBR_CTL get restored on the host? What if the host wants to keep _its_ LBR recording active while the guest is running? Thank you! I will add "host_lbrctlmsr" field to "struct vcpu_vmx" and repeat the update/get_debugctlmsr() stuff. I am not remotely confident that tracking LBRCTL via vcpu_vmx is correct, and I'm far less confident that the existing DEBUGCTL logic is correct. As Jim pointed out[*], intel_pmu_handle_irq() can run at any time, and it's not at all clear to me that the DEBUGCTL coming out of the NMI handler is guaranteed to be the same value going in. Ditto for LBRCTL. It's not true for "Ditto for LBRCTL". Because the usage of ARCH_LBR_CTL is specified for LBR, not the shared case of DEBUGCTL. And all LBR events created from KVM or host perf syscall are all under the control of host perf subsystem. The irq handler would restore the original value of the ARCH_LBR_CTL even it's called after the KVM snapshots DEBUCTL on vCPU load. The change is transparent to the update_lbrctlmsr() and get_lbrctlmsr(). Actually, NMIs aside, KVM's DEBUGCTL handling is provably broken since writing /sys/devices/cpu/freeze_on_smi is propagated to other CPUs via IRQ, and KVM snapshots DEBUCTL on vCPU load, i.e. runs with IRQs enabled long after grabbing the value. WARNING: CPU: 5 PID: 0 at arch/x86/events/intel/core.c:4066 flip_smm_bit+0xb/0x30 RIP: 0010:flip_smm_bit+0xb/0x30 Call Trace: flush_smp_call_function_queue+0x118/0x1a0 __sysvec_call_function+0x2c/0x90 asm_call_irq_on_stack+0x12/0x20 This kind of bug with the keyword "flip_smm_bit" did not appear on the mailing list. Would you mind to share testcases or more details about the steps to reproduce ? So, rather than pile on more MSR handling that is at best dubious, and at worst broken, I would like to see KVM properly integrate with perf to ensure KVM restores the correct, fresh values of all MSRs that are owned by perf. Or at least add something that guarantees that intel_pmu_handle_irq() preserves the MSRs. As is, it's impossible to review these KVM changes without deep, deep knowledge of what perf is doing. Jim complained more about the inconsistent maintenance of MSR_IA32_PEBS_ENABLE between KVM and perf subsystem. The issue bothers the host due to the subsystem integration, but the guest's use of PBES will be safe and reliable. We could cover more details in the guest PEBS enabling thread. https://lkml.kernel.org/r/20210209225653.1393771-1-jmatt...@google.com
RE: [RFC PATCH 2/5] char: rpmb: provide a user space interface
> On Thu, Mar 4, 2021 at 8:54 PM Winkler, Tomas > wrote: > > > Winkler, Tomas writes: > > > >> "Winkler, Tomas" writes: > > > >> > > > >> >> The user space API is achieved via a number of synchronous > IOCTLs. > > > >> >> > > > >> >> * RPMB_IOC_VER_CMD - simple versioning API > > > >> >> * RPMB_IOC_CAP_CMD - query of underlying capabilities > > > >> >> * RPMB_IOC_PKEY_CMD - one time programming of access key > > > >> >> * RPMB_IOC_COUNTER_CMD - query the write counter > > > >> >> * RPMB_IOC_WBLOCKS_CMD - write blocks to device > > > >> >> * RPMB_IOC_RBLOCKS_CMD - read blocks from device > > > >> >> > > > >> >> The keys used for programming and writing blocks to the device > > > >> >> are key_serial_t handles as provided by the keyctl() interface. > > > >> >> > > > >> >> [AJB: here there are two key differences between this and the > > > >> >> original proposal. The first is the dropping of the sequence > > > >> >> of preformated frames in favour of explicit actions. The > > > >> >> second is the introduction of key_serial_t and the keyring API > > > >> >> for referencing the key to use] > > > >> > > > > >> > Putting it gently I'm not sure this is good idea, from the > > > >> > security point of > > > >> view. > > > >> > The key has to be possession of the one that signs the frames > > > >> > as they are, > > > >> it doesn't mean it is linux kernel keyring, it can be other party > > > >> on different system. > > > >> > With this approach you will make the other usecases not applicable. > > > >> > It is less then trivial to move key securely from one system to > another. > > > >> > > > >> OK I can understand the desire for such a use-case but it does > > > >> constrain the interface on the kernel with access to the hardware > > > >> to purely providing a pipe to the raw hardware while also having > > > >> to expose the details of the HW to userspace. > > > > This is the use case in Android. The key is in the "trusty" which > > > > different os running in a virtual environment. The file storage > > > > abstraction is implemented there. I'm not sure the point of > > > > constraining the kernel, can you please elaborate on that. > > > > > > Well the kernel is all about abstracting differences not baking in > assumptions. > > > However can I ask a bit more about this security model? > > > Is the secure enclave just a separate userspace process or is it in > > > a separate virtual machine? Is it accessible at all by the kernel running > > > the > driver? > > > > It's not an assumption this is working for few years already > > (https://source.android.com/security/trusty#application_services) > > The model is that you have a trusted environment (TEE) in which can be in > any of the form you described above. > > And there is established agreement via the RPMB key that TEE is only > > entity that can produce content to be stored on RPBM, The RPMB > hardware also ensure that nobody can catch it in the middle and replay that > storage event. > > > > My point is that interface you are suggesting is not covering all possible > usages of RPMB, actually usages that are already in place. > > It turned out that the application that we (Linaro) need does have the same > requirements and needs to store the key in a TEE, transferring the message > with the MAC into the kernel, rather than keeping the key stored in user > space or kernel. > > However, after I had a look at the nvme-rpmb user space implementation, I > found that this is different, and always expects the key to be stored in a > local > file: > https://github.com/linux-nvme/nvme-cli/blob/master/nvme-rpmb.c#L878 This doesn't make it very safe > This both works with the same kernel interface though, as the kernel would > still get the data along with the HMAC, rather than having the key stored in > the kernel, but it does mean that the frame gets passed to the kernel in a > device specific layout, with at least nvme using an incompatible layout from > everything else. NVMe is not by JEDEC so this layout is different and there are some changes but the overall storage operations are the same story. I do have a solution also for NVME inclusion into the framework. I haven't published that part yet. It won't support virtio part, as this requires some legal work to include that into virtio spec. Thanks Tomas > Arnd
[PATCH 3/3] dt-bindings: pinctrl: qcom-pmic-gpio: Add pmic gpio support
Add compatibles for PM7325, PM8350C, PMK8350 and PMR735A GPIO support to the Qualcomm technologies Inc PMIC GPIO binding. Signed-off-by: satya priya --- Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index fc787aa..37a4333 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -40,6 +40,10 @@ properties: - qcom,pm6150-gpio - qcom,pm6150l-gpio - qcom,pmx55-gpio + - qcom,pm7325-gpio + - qcom,pm8350c-gpio + - qcom,pmk8350-gpio + - qcom,pmr735a-gpio - enum: - qcom,spmi-gpio @@ -102,6 +106,10 @@ properties: - gpio1-gpio12 for pm8150l (hole on gpio7) - gpio1-gpio10 for pm6150 - gpio1-gpio12 for pm6150l + - gpio1-gpio10 for pm7325 + - gpio1-gpio9 for pm8350c + - gpio1-gpio4 for pmk8350 + - gpio1-gpio4 for pmr735a $ref: /schemas/types.yaml#/definitions/string-array items: -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/3] pinctrl: qcom: spmi-gpio: Add support for four variants
Add PM7325, PM8350c, PMK8350 and PMR735A compatibles for GPIO
support.
Signed-off-by: satya priya
---
drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
index 9801c71..90f4f78 100644
--- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
+++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c
@@ -1131,6 +1131,10 @@ static const struct of_device_id pmic_gpio_of_match[] = {
{ .compatible = "qcom,pm6150l-gpio", .data = (void *) 12 },
/* pmx55 has 11 GPIOs with holes on 3, 7, 10, 11 */
{ .compatible = "qcom,pmx55-gpio", .data = (void *) 11 },
+ { .compatible = "qcom,pm7325-gpio", .data = (void *) 10 },
+ { .compatible = "qcom,pm8350c-gpio", .data = (void *) 9 },
+ { .compatible = "qcom,pmk8350-gpio", .data = (void *) 4 },
+ { .compatible = "qcom,pmr735a-gpio", .data = (void *) 4 },
{ },
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 2/3] dt-bindings: pinctrl: qcom-pmic-gpio: Convert pmic gpio bindings to YAML
Convert Qualcomm PMIC GPIO bindings from .txt to .yaml format. Signed-off-by: satya priya --- .../devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 272 .../bindings/pinctrl/qcom,pmic-gpio.yaml | 273 + 2 files changed, 273 insertions(+), 272 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt deleted file mode 100644 index 7648ab0..000 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ /dev/null @@ -1,272 +0,0 @@ -Qualcomm PMIC GPIO block - -This binding describes the GPIO block(s) found in the 8xxx series of -PMIC's from Qualcomm. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,pm8005-gpio" - "qcom,pm8018-gpio" - "qcom,pm8038-gpio" - "qcom,pm8058-gpio" - "qcom,pm8916-gpio" - "qcom,pm8917-gpio" - "qcom,pm8921-gpio" - "qcom,pm8941-gpio" - "qcom,pm8950-gpio" - "qcom,pm8994-gpio" - "qcom,pm8998-gpio" - "qcom,pma8084-gpio" - "qcom,pmi8950-gpio" - "qcom,pmi8994-gpio" - "qcom,pmi8998-gpio" - "qcom,pms405-gpio" - "qcom,pm660-gpio" - "qcom,pm660l-gpio" - "qcom,pm8150-gpio" - "qcom,pm8150b-gpio" - "qcom,pm6150-gpio" - "qcom,pm6150l-gpio" - "qcom,pmx55-gpio" - - And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" - if the device is on an spmi bus or an ssbi bus respectively - -- reg: - Usage: required - Value type: - Definition: Register base of the GPIO block and length. - -- interrupts: - Usage: required - Value type: - Definition: Must contain an array of encoded interrupt specifiers for - each available GPIO - -- gpio-controller: - Usage: required - Value type: - Definition: Mark the device node as a GPIO controller - -- #gpio-cells: - Usage: required - Value type: - Definition: Must be 2; - the first cell will be used to define gpio number and the - second denotes the flags for this gpio - -Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for -a general description of GPIO and interrupt bindings. - -Please refer to pinctrl-bindings.txt in this directory for details of the -common pinctrl bindings used by client devices, including the meaning of the -phrase "pin configuration node". - -The pin configuration nodes act as a container for an arbitrary number of -subnodes. Each of these subnodes represents some desired configuration for a -pin or a list of pins. This configuration can include the -mux function to select on those pin(s), and various pin configuration -parameters, as listed below. - - -SUBNODES: - -The name of each subnode is not important; all subnodes should be enumerated -and processed purely based on their content. - -Each subnode only affects those parameters that are explicitly listed. In -other words, a subnode that lists a mux function but no pin configuration -parameters implies no information about any pin configuration parameters. -Similarly, a pin subnode that describes a pullup parameter implies no -information about e.g. the mux function. - -The following generic properties as defined in pinctrl-bindings.txt are valid -to specify in a pin configuration subnode: - -- pins: - Usage: required - Value type: - Definition: List of gpio pins affected by the properties specified in - this subnode. Valid pins are: - gpio1-gpio4 for pm8005 - gpio1-gpio6 for pm8018 - gpio1-gpio12 for pm8038 - gpio1-gpio40 for pm8058 - gpio1-gpio4 for pm8916 - gpio1-gpio38 for pm8917 - gpio1-gpio44 for pm8921 - gpio1-gpio36 for pm8941 - gpio1-gpio8 for pm8950 (hole on gpio3) - gpio1-gpio22 for pm8994 - gpio1-gpio26 for pm8998 - gpio1-gpio22 for pma8084 - gpio1-gpio2 for pmi8950 - gpio1-gpio10 for pmi8994 - gpio1-gpio12 for pms405 (holes on gpio1, gpio9 and gpio10) - gpio1-gpio10 for pm8150 (holes on gpio2, gpio5, gpio7 -and gpio8) -
Re: linux-next: manual merge of the tty tree with the powerpc-fixes tree
On Fri, Mar 05, 2021 at 12:05:23PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the tty tree got a conflict in:
>
> drivers/tty/hvc/hvcs.c
>
> between commit:
>
> 386a966f5ce7 ("vio: make remove callback return void")
>
> from the powerpc-fixes tree and commit:
>
> fb8d350c291c ("tty: hvc, drop unneeded forward declarations")
>
> from the tty tree.
>
> I fixed it up (they both removed the forward decalrartion of
> hvcs_remove(), but the latter removed more) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Thanks, that's the correct fix, we knew this was going to happen :(
greg k-h
[PATCH 0/3] Add GPIO support for the PM7325, PM8350c, PMK8350 and PMR735A
satya priya (3): pinctrl: qcom: spmi-gpio: Add support for four variants dt-bindings: pinctrl: qcom-pmic-gpio: Convert pmic gpio bindings to YAML dt-bindings: pinctrl: qcom-pmic-gpio: Add pmic gpio support .../devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 272 .../bindings/pinctrl/qcom,pmic-gpio.yaml | 281 + drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 4 + 3 files changed, 285 insertions(+), 272 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH] hwrng: bcm2835: set quality to 1000
Hi Florian, > El 4 mar 2021, a las 23:28, Florian Fainelli escribió: > > On 3/4/21 7:11 AM, Nicolas Saenz Julienne wrote: >> On Wed, 2021-03-03 at 10:29 +0100, Álvaro Fernández Rojas wrote: >>> Hi Herbert, >>> El 3 mar 2021, a las 10:20, Herbert Xu escribió: On Sat, Feb 20, 2021 at 08:12:45PM +0100, Álvaro Fernández Rojas wrote: > > I ran rngtest and this is what I got: This is meaningless except for sources that have not been whitened. Your justification needs to be based on what the hardware does or is documented to do. >>> >>> Ok, so I guess that we’re never setting that value to anything since there’s >>> no public documentation about that ¯\_(ツ)_/¯. >> >> @Florian, is there a way you might be able to get the official value? > > I will be looking into the documentation this weekend and let you know > whether we can change the driver's quality accordingly. Could you do that for iproc-rng200.c too? > -- > Florian Best regards, Álvaro.
Re: [RFC PATCH 2/12] x86/Hyper-V: Add new hvcall guest address host visibility support
On 3/4/2021 12:58 AM, Vitaly Kuznetsov wrote:
Tianyu Lan writes:
From: Tianyu Lan
Add new hvcall guest address host visibility support. Mark vmbus
ring buffer visible to host when create gpadl buffer and mark back
to not visible when tear down gpadl buffer.
Signed-off-by: Sunil Muthuswamy
Co-Developed-by: Sunil Muthuswamy
Signed-off-by: Tianyu Lan
---
arch/x86/include/asm/hyperv-tlfs.h | 13
arch/x86/include/asm/mshyperv.h| 4 +--
arch/x86/kernel/cpu/mshyperv.c | 46 ++
drivers/hv/channel.c | 53 --
drivers/net/hyperv/hyperv_net.h| 1 +
drivers/net/hyperv/netvsc.c| 9 +++--
drivers/uio/uio_hv_generic.c | 6 ++--
include/asm-generic/hyperv-tlfs.h | 1 +
include/linux/hyperv.h | 3 +-
9 files changed, 126 insertions(+), 10 deletions(-)
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index fb1893a4c32b..d22b1c3f425a 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -573,4 +573,17 @@ enum hv_interrupt_type {
#include
+/* All input parameters should be in single page. */
+#define HV_MAX_MODIFY_GPA_REP_COUNT\
+ ((PAGE_SIZE - 2 * sizeof(u64)) / (sizeof(u64)))
Would it be easier to express this as '((PAGE_SIZE / sizeof(u64)) - 2'
Yes, will update. Thanks.
+
+/* HvCallModifySparseGpaPageHostVisibility hypercall */
+struct hv_input_modify_sparse_gpa_page_host_visibility {
+ u64 partition_id;
+ u32 host_visibility:2;
+ u32 reserved0:30;
+ u32 reserved1;
+ u64 gpa_page_list[HV_MAX_MODIFY_GPA_REP_COUNT];
+} __packed;
+
#endif
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index ccf60a809a17..1e8275d35c1f 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -262,13 +262,13 @@ static inline void hv_set_msi_entry_from_desc(union
hv_msi_entry *msi_entry,
msi_entry->address.as_uint32 = msi_desc->msg.address_lo;
msi_entry->data.as_uint32 = msi_desc->msg.data;
}
-
stray change
struct irq_domain *hv_create_pci_msi_domain(void);
int hv_map_ioapic_interrupt(int ioapic_id, bool level, int vcpu, int vector,
struct hv_interrupt_entry *entry);
int hv_unmap_ioapic_interrupt(int ioapic_id, struct hv_interrupt_entry
*entry);
-
+int hv_set_mem_host_visibility(void *kbuffer, u32 size, u32 visibility);
+int hv_mark_gpa_visibility(u16 count, const u64 pfn[], u32 visibility);
#else /* CONFIG_HYPERV */
static inline void hyperv_init(void) {}
static inline void hyperv_setup_mmu_ops(void) {}
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index e88bc296afca..347c32eac8fd 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -37,6 +37,8 @@
bool hv_root_partition;
EXPORT_SYMBOL_GPL(hv_root_partition);
+#define HV_PARTITION_ID_SELF ((u64)-1)
+
We seem to have this already:
include/asm-generic/hyperv-tlfs.h:#define HV_PARTITION_ID_SELF
((u64)-1)
struct ms_hyperv_info ms_hyperv;
EXPORT_SYMBOL_GPL(ms_hyperv);
@@ -477,3 +479,47 @@ const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
.init.msi_ext_dest_id = ms_hyperv_msi_ext_dest_id,
.init.init_platform = ms_hyperv_init_platform,
};
+
+int hv_mark_gpa_visibility(u16 count, const u64 pfn[], u32 visibility)
+{
+ struct hv_input_modify_sparse_gpa_page_host_visibility **input_pcpu;
+ struct hv_input_modify_sparse_gpa_page_host_visibility *input;
+ u16 pages_processed;
+ u64 hv_status;
+ unsigned long flags;
+
+ /* no-op if partition isolation is not enabled */
+ if (!hv_is_isolation_supported())
+ return 0;
+
+ if (count > HV_MAX_MODIFY_GPA_REP_COUNT) {
+ pr_err("Hyper-V: GPA count:%d exceeds supported:%lu\n", count,
+ HV_MAX_MODIFY_GPA_REP_COUNT);
+ return -EINVAL;
+ }
+
+ local_irq_save(flags);
+ input_pcpu = (struct hv_input_modify_sparse_gpa_page_host_visibility **)
+ this_cpu_ptr(hyperv_pcpu_input_arg);
+ input = *input_pcpu;
+ if (unlikely(!input)) {
+ local_irq_restore(flags);
+ return -1;
-EFAULT/-ENOMEM/... maybe ?
Yes, will update.
+ }
+
+ input->partition_id = HV_PARTITION_ID_SELF;
+ input->host_visibility = visibility;
+ input->reserved0 = 0;
+ input->reserved1 = 0;
+ memcpy((void *)input->gpa_page_list, pfn, count * sizeof(*pfn));
+ hv_status = hv_do_rep_hypercall(
+ HVCALL_MODIFY_SPARSE_GPA_PAGE_HOST_VISIBILITY, count,
+ 0, input, _processed);
+ local_irq_restore(flags);
+
+ if (!(hv_status & HV_HYPERCALL_RESULT_MASK))
+ return 0;
+
+ return -EFAULT;
Re: [PATCH] powerpc/pseries: export LPAR security flavor in lparcfg
Laurent Dufour writes: > This is helpful to read the security flavor from inside the LPAR. We already have /sys/kernel/debug/powerpc/security_features. Is that not sufficient? > Export it like this in /proc/powerpc/lparcfg: > > $ grep security_flavor /proc/powerpc/lparcfg > security_flavor=1 > > Value means: > 0 Speculative execution fully enabled > 1 Speculative execution controls to mitigate user-to-kernel attacks > 2 Speculative execution controls to mitigate user-to-kernel and > user-to-user side-channel attacks Those strings come from the FSP help, but we have no guarantee it won't mean something different in future. cheers
[PATCH 2/2] erofs: decompress in endio if possible
z_erofs_decompressqueue_endio may not be executed in the interrupt
context, for example, when dm-verity is turned on. In this scenario,
io should be decompressed directly to avoid additional scheduling
overhead. Also there is no need to wait for endio to execute
synchronous decompression.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/internal.h | 3 ++
fs/erofs/super.c| 1 +
fs/erofs/zdata.c| 102
3 files changed, 60 insertions(+), 46 deletions(-)
diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h
index 77965490dced..a19bcbb681fc 100644
--- a/fs/erofs/internal.h
+++ b/fs/erofs/internal.h
@@ -71,6 +71,9 @@ struct erofs_sb_info {
/* pseudo inode to manage cached pages */
struct inode *managed_cache;
+ /* decide whether to decompress synchronously */
+ bool sync_decompress;
+
/* # of pages needed for EROFS lz4 rolling decompression */
u16 lz4_max_distance_pages;
#endif /* CONFIG_EROFS_FS_ZIP */
diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index 37f1cc9d28cc..5b9a21d10a30 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -188,6 +188,7 @@ static int erofs_read_superblock(struct super_block *sb)
goto out;
}
+ sbi->sync_decompress = false;
/* parse on-disk compression configurations */
z_erofs_load_lz4_config(sbi, dsb);
ret = 0;
diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c
index 6cb356c4217b..727dd01f55c1 100644
--- a/fs/erofs/zdata.c
+++ b/fs/erofs/zdata.c
@@ -706,56 +706,11 @@ static int z_erofs_do_read_page(struct
z_erofs_decompress_frontend *fe,
goto out;
}
-static void z_erofs_decompress_kickoff(struct z_erofs_decompressqueue *io,
- bool sync, int bios)
-{
- /* wake up the caller thread for sync decompression */
- if (sync) {
- unsigned long flags;
-
- spin_lock_irqsave(>u.wait.lock, flags);
- if (!atomic_add_return(bios, >pending_bios))
- wake_up_locked(>u.wait);
- spin_unlock_irqrestore(>u.wait.lock, flags);
- return;
- }
-
- if (!atomic_add_return(bios, >pending_bios))
- queue_work(z_erofs_workqueue, >u.work);
-}
-
static bool z_erofs_page_is_invalidated(struct page *page)
{
return !page->mapping && !z_erofs_is_shortlived_page(page);
}
-static void z_erofs_decompressqueue_endio(struct bio *bio)
-{
- tagptr1_t t = tagptr_init(tagptr1_t, bio->bi_private);
- struct z_erofs_decompressqueue *q = tagptr_unfold_ptr(t);
- blk_status_t err = bio->bi_status;
- struct bio_vec *bvec;
- struct bvec_iter_all iter_all;
-
- bio_for_each_segment_all(bvec, bio, iter_all) {
- struct page *page = bvec->bv_page;
-
- DBG_BUGON(PageUptodate(page));
- DBG_BUGON(z_erofs_page_is_invalidated(page));
-
- if (err)
- SetPageError(page);
-
- if (erofs_page_is_managed(EROFS_SB(q->sb), page)) {
- if (!err)
- SetPageUptodate(page);
- unlock_page(page);
- }
- }
- z_erofs_decompress_kickoff(q, tagptr_unfold_tags(t), -1);
- bio_put(bio);
-}
-
static int z_erofs_decompress_pcluster(struct super_block *sb,
struct z_erofs_pcluster *pcl,
struct list_head *pagepool)
@@ -991,6 +946,60 @@ static void z_erofs_decompressqueue_work(struct
work_struct *work)
kvfree(bgq);
}
+static void z_erofs_decompress_kickoff(struct z_erofs_decompressqueue *io,
+ bool sync, int bios)
+{
+ struct erofs_sb_info *const sbi = EROFS_SB(io->sb);
+
+ /* wake up the caller thread for sync decompression */
+ if (sync) {
+ unsigned long flags;
+
+ spin_lock_irqsave(>u.wait.lock, flags);
+ if (!atomic_add_return(bios, >pending_bios))
+ wake_up_locked(>u.wait);
+ spin_unlock_irqrestore(>u.wait.lock, flags);
+ return;
+ }
+
+ if (!atomic_add_return(bios, >pending_bios)) {
+ if (in_atomic() || irqs_disabled()) {
+ queue_work(z_erofs_workqueue, >u.work);
+ if (unlikely(!sbi->sync_decompress))
+ sbi->sync_decompress = true;
+ }
+ else
+ z_erofs_decompressqueue_work(>u.work);
+ }
+}
+
+static void z_erofs_decompressqueue_endio(struct bio *bio)
+{
+ tagptr1_t t = tagptr_init(tagptr1_t, bio->bi_private);
+ struct z_erofs_decompressqueue *q = tagptr_unfold_ptr(t);
+ blk_status_t err = bio->bi_status;
+ struct bio_vec *bvec;
+ struct bvec_iter_all
[PATCH 1/2] erofs: avoid memory allocation failure during rolling decompression
It should be better to ensure memory allocation during rolling
decompression to avoid io error.
Signed-off-by: Huang Jianan
Signed-off-by: Guo Weichao
---
fs/erofs/decompressor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
index 49347e681a53..fb0fa4e5b9ea 100644
--- a/fs/erofs/decompressor.c
+++ b/fs/erofs/decompressor.c
@@ -86,7 +86,7 @@ static int z_erofs_lz4_prepare_destpages(struct
z_erofs_decompress_req *rq,
victim = availables[--top];
get_page(victim);
} else {
- victim = erofs_allocpage(pagepool, GFP_KERNEL);
+ victim = erofs_allocpage(pagepool, GFP_KERNEL |
__GFP_NOFAIL);
if (!victim)
return -ENOMEM;
set_page_private(victim, Z_EROFS_SHORTLIVED_PAGE);
--
2.25.1
RE: [PATCH v3 1/1] PCI/RCEC: Fix RCiEP capable devices RCEC association
Hi Bjorn,
Do you have any comments on this patch? If need any changes, please let me
know.
Thanks!
-Qiuxu
> -Original Message-
> From: Zhuo, Qiuxu
> Sent: Monday, February 22, 2021 9:17 AM
> To: Bjorn Helgaas
> Cc: Zhuo, Qiuxu ; Lorenzo Pieralisi
> ; Krzysztof Wilczyński ; Kelley,
> Sean V ; Luck, Tony ; Jin, Wen
> ; linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH v3 1/1] PCI/RCEC: Fix RCiEP capable devices RCEC association
>
> Function rcec_assoc_rciep() incorrectly used "rciep->devfn" (a single byte
> encoding the device and function number) as the device number to check
> whether the corresponding bit was set in the RCiEPBitmap of the RCEC (Root
> Complex Event Collector) while enumerating over each bit of the RCiEPBitmap.
>
> As per the PCI Express Base Specification, Revision 5.0, Version 1.0, Section
> 7.9.10.2, "Association Bitmap for RCiEPs", p. 935, only needs to use a device
> number to check whether the corresponding bit was set in the RCiEPBitmap.
>
> Fix rcec_assoc_rciep() using the PCI_SLOT() macro and convert the value of
> "rciep->devfn" to a device number to ensure that the RCiEP devices associated
> with the RCEC are linked when the RCEC is enumerated.
>
> Fixes: 507b460f8144 ("PCI/ERR: Add pcie_link_rcec() to associate RCiEPs")
> Reported-and-tested-by: Wen Jin
> Reviewed-by: Sean V Kelley
> Signed-off-by: Qiuxu Zhuo
> ---
> v2->v3:
> Drop "[ Krzysztof: Update commit message. ]" from the commit message
>
> drivers/pci/pcie/rcec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pcie/rcec.c b/drivers/pci/pcie/rcec.c index
> 2c5c552994e4..d0bcd141ac9c 100644
> --- a/drivers/pci/pcie/rcec.c
> +++ b/drivers/pci/pcie/rcec.c
> @@ -32,7 +32,7 @@ static bool rcec_assoc_rciep(struct pci_dev *rcec, struct
> pci_dev *rciep)
>
> /* Same bus, so check bitmap */
> for_each_set_bit(devn, , 32)
> - if (devn == rciep->devfn)
> + if (devn == PCI_SLOT(rciep->devfn))
> return true;
>
> return false;
> --
> 2.17.1
Re: [PATCH v3 02/11] blk: Introduce ->corrupted_range() for block device
On Thu, Mar 04, 2021 at 02:42:50PM -0800, Darrick J. Wong wrote: > My vision here, however, is to establish upcalls for /both/ types of > stroage. I already have patches for doing these kinds of callbacks properly for the block layer. They will be posted shortly.
Re: [PATCH 1/4] kbuild: remove LLVM=1 test from HAS_LTO_CLANG
On Thu, Mar 4, 2021 at 5:47 AM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> + Sami
>
> On Wed, Mar 3, 2021 at 10:34 AM Masahiro Yamada wrote:
> >
> > This guarding is wrong. As Documentation/kbuild/llvm.rst notes, LLVM=1
> > switches the default of tools, but you can still override CC, LD, etc.
> > individually.
> >
> > BTW, LLVM is not 1/0 flag. If LLVM is not passed in, it is empty.
>
> Do we have the same problem with LLVM_IAS? LGTM otherwise, but wanted
> to check that before signing off.
3/4 will replace this LLVM_IAS check with AS_IS_LLVM.
We do not need to add a noise change.
>
> (Also, the rest of the patches in this series seem more related to
> DWARFv5 cleanups; this patch seems orthogonal while those are a
> visible progression).
Kind of orthogonal, but I am touching the same code hunk,
which would cause a merge conflict.
> >
> > Non-zero return code is all treated as failure anyway.
> >
> > So, $(success,test $(LLVM) -eq 1) and $(success,test "$(LLVM)" = 1)
> > works equivalently in the sense that both are expanded to 'n' if LLVM
> > is not given. The difference is that the former internally fails due
> > to syntax error.
> >
> > $ test ${LLVM} -eq 1
> > bash: test: -eq: unary operator expected
> > $ echo $?
> > 2
> >
> > $ test "${LLVM}" -eq 1
> > bash: test: : integer expression expected
> > $ echo $?
> > 2
> >
> > $ test "${LLVM}" = 1
> > echo $?
> > 1
> >
> > $ test -n "${LLVM}"
> > $ echo $?
> > 1
> >
> > Signed-off-by: Masahiro Yamada
> > ---
> >
> > arch/Kconfig | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/arch/Kconfig b/arch/Kconfig
> > index 2bb30673d8e6..2af10ebe5ed0 100644
> > --- a/arch/Kconfig
> > +++ b/arch/Kconfig
> > @@ -632,7 +632,6 @@ config HAS_LTO_CLANG
> > def_bool y
> > # Clang >= 11: https://github.com/ClangBuiltLinux/linux/issues/510
> > depends on CC_IS_CLANG && CLANG_VERSION >= 11 && LD_IS_LLD
> > - depends on $(success,test $(LLVM) -eq 1)
>
> IIRC, we needed some other LLVM utilities like llvm-nm and llvm-ar,
> which are checked below. So I guess we can still support CC=clang
> AR=llvm-ar NM=llvm-nm, and this check is redundant.
Yes, I think so.
>
> > depends on $(success,test $(LLVM_IAS) -eq 1)
> > depends on $(success,$(NM) --help | head -n 1 | grep -qi llvm)
> > depends on $(success,$(AR) --help | head -n 1 | grep -qi llvm)
> > --
> > 2.27.0
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdkhZGv_q9vgDdYY44OrbzmMD_E%2BGL3SyOk-jQ0kdXtMzg%40mail.gmail.com.
--
Best Regards
Masahiro Yamada
Re: [RFC PATCH 1/12] x86/Hyper-V: Add visibility parameter for vmbus_establish_gpadl()
Hi Vitaly:
Thanks for your review.
On 3/4/2021 12:27 AM, Vitaly Kuznetsov wrote:
Tianyu Lan writes:
From: Tianyu Lan
Add visibility parameter for vmbus_establish_gpadl() and prepare
to change host visibility when create gpadl for buffer.
"No functional change" as you don't actually use the parameter.
Yes, will add it into commit log.
Signed-off-by: Sunil Muthuswamy
Co-Developed-by: Sunil Muthuswamy
Signed-off-by: Tianyu Lan
Nit: Sunil's SoB looks misleading because the patch is from you,
Co-Developed-by should be sufficient.
Will update.
---
arch/x86/include/asm/hyperv-tlfs.h | 9 +
drivers/hv/channel.c | 20 +++-
drivers/net/hyperv/netvsc.c| 8 ++--
drivers/uio/uio_hv_generic.c | 7 +--
include/linux/hyperv.h | 3 ++-
5 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index e6cd3fee562b..fb1893a4c32b 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++ b/arch/x86/include/asm/hyperv-tlfs.h
@@ -236,6 +236,15 @@ enum hv_isolation_type {
/* TSC invariant control */
#define HV_X64_MSR_TSC_INVARIANT_CONTROL 0x4118
+/* Hyper-V GPA map flags */
+#define HV_MAP_GPA_PERMISSIONS_NONE0x0
+#define HV_MAP_GPA_READABLE0x1
+#define HV_MAP_GPA_WRITABLE0x2
+
+#define VMBUS_PAGE_VISIBLE_READ_ONLY HV_MAP_GPA_READABLE
+#define VMBUS_PAGE_VISIBLE_READ_WRITE (HV_MAP_GPA_READABLE|HV_MAP_GPA_WRITABLE)
+#define VMBUS_PAGE_NOT_VISIBLE HV_MAP_GPA_PERMISSIONS_NONE
+
Are these x86-only? If not, then we should probably move these defines
to include/asm-generic/hyperv-tlfs.h. In case they are, we should do
something as we're using them from arch neutral places.
Also, could you please add a comment stating that these flags define
host's visibility of a page and not guest's (this seems to be not
obvious at least to me).
/*
* Declare the MSR used to setup pages used to communicate with the
hypervisor.
*/
diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 0bd202de7960..daa21cc72beb 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -242,7 +242,7 @@ EXPORT_SYMBOL_GPL(vmbus_send_modifychannel);
*/
static int create_gpadl_header(enum hv_gpadl_type type, void *kbuffer,
u32 size, u32 send_offset,
- struct vmbus_channel_msginfo **msginfo)
+ struct vmbus_channel_msginfo **msginfo, u32
visibility)
{
int i;
int pagecount;
@@ -391,7 +391,7 @@ static int create_gpadl_header(enum hv_gpadl_type type,
void *kbuffer,
static int __vmbus_establish_gpadl(struct vmbus_channel *channel,
enum hv_gpadl_type type, void *kbuffer,
u32 size, u32 send_offset,
- u32 *gpadl_handle)
+ u32 *gpadl_handle, u32 visibility)
{
struct vmbus_channel_gpadl_header *gpadlmsg;
struct vmbus_channel_gpadl_body *gpadl_body;
@@ -405,7 +405,8 @@ static int __vmbus_establish_gpadl(struct vmbus_channel
*channel,
next_gpadl_handle =
(atomic_inc_return(_connection.next_gpadl_handle) - 1);
- ret = create_gpadl_header(type, kbuffer, size, send_offset, );
+ ret = create_gpadl_header(type, kbuffer, size, send_offset,
+ , visibility);
if (ret)
return ret;
@@ -496,10 +497,10 @@ static int __vmbus_establish_gpadl(struct vmbus_channel *channel,
* @gpadl_handle: some funky thing
*/
int vmbus_establish_gpadl(struct vmbus_channel *channel, void *kbuffer,
- u32 size, u32 *gpadl_handle)
+ u32 size, u32 *gpadl_handle, u32 visibility)
{
return __vmbus_establish_gpadl(channel, HV_GPADL_BUFFER, kbuffer, size,
- 0U, gpadl_handle);
+ 0U, gpadl_handle, visibility);
}
EXPORT_SYMBOL_GPL(vmbus_establish_gpadl);
@@ -610,10 +611,11 @@ static int __vmbus_open(struct vmbus_channel *newchannel,
newchannel->ringbuffer_gpadlhandle = 0;
err = __vmbus_establish_gpadl(newchannel, HV_GPADL_RING,
- page_address(newchannel->ringbuffer_page),
- (send_pages + recv_pages) << PAGE_SHIFT,
- newchannel->ringbuffer_send_offset <<
PAGE_SHIFT,
- >ringbuffer_gpadlhandle);
+ page_address(newchannel->ringbuffer_page),
+ (send_pages + recv_pages) << PAGE_SHIFT,
+ newchannel->ringbuffer_send_offset << PAGE_SHIFT,
+ >ringbuffer_gpadlhandle,
+
Re: [PATCH] ibmvnic: remove excessive irqsave
> On Mar 4, 2021, at 11:49 PM, Christophe Leroy > wrote: > > > > Le 05/03/2021 à 02:43, angkery a écrit : >> From: Junlin Yang >> ibmvnic_remove locks multiple spinlocks while disabling interrupts: >> spin_lock_irqsave(>state_lock, flags); >> spin_lock_irqsave(>rwi_lock, flags); >> there is no need for the second irqsave,since interrupts are disabled >> at that point, so remove the second irqsave: > > The problème is not that there is no need. The problem is a lot more serious: > As reported by coccinella, the second _irqsave() overwrites the value saved > in 'flags' by the first _irqsave, therefore when the second _irqrestore > comes, the value in 'flags' is not valid, the value saved by the first > _irqsave has been lost. This likely leads to IRQs remaining disabled, which > is _THE_ problem really. That does sounds like a more serious functional problem than coccinella check. Thanks for your explanation. > >> spin_lock_irqsave(>state_lock, flags); >> spin_lock(>rwi_lock); >> Generated by: ./scripts/coccinelle/locks/flags.cocci >> ./drivers/net/ethernet/ibm/ibmvnic.c:5413:1-18: >> ERROR: nested lock+irqsave that reuses flags from line 5404. >> Signed-off-by: Junlin Yang >> --- >> drivers/net/ethernet/ibm/ibmvnic.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> diff --git a/drivers/net/ethernet/ibm/ibmvnic.c >> b/drivers/net/ethernet/ibm/ibmvnic.c >> index 2464c8a..a52668d 100644 >> --- a/drivers/net/ethernet/ibm/ibmvnic.c >> +++ b/drivers/net/ethernet/ibm/ibmvnic.c >> @@ -5408,9 +5408,9 @@ static void ibmvnic_remove(struct vio_dev *dev) >> * after setting state, so __ibmvnic_reset() which is called >> * from the flush_work() below, can make progress. >> */ >> -spin_lock_irqsave(>rwi_lock, flags); >> +spin_lock(>rwi_lock); >> adapter->state = VNIC_REMOVING; >> -spin_unlock_irqrestore(>rwi_lock, flags); >> +spin_unlock(>rwi_lock); >> spin_unlock_irqrestore(>state_lock, flags); >>
Re: [PATCH] kbuild: add CONFIG_VMLINUX_MAP expert option
On Wed, Feb 24, 2021 at 7:53 PM Rasmus Villemoes
wrote:
>
> It can be quite useful to have ld emit a link map file, in order to
> debug or verify that special sections end up where they are supposed
> to, and to see what LD_DEAD_CODE_DATA_ELIMINATION manages to get rid
> of.
>
> The only reason I'm not just adding this unconditionally is that the
> .map file can be rather large (several MB), and that's a waste of
> space when one isn't interested in these things. Also hide the prompt
> behind CONFIG_EXPERT.
>
> Signed-off-by: Rasmus Villemoes
> ---
> .gitignore | 1 +
> Makefile| 3 ++-
> lib/Kconfig.debug | 9 +
> scripts/link-vmlinux.sh | 9 +
> 4 files changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/.gitignore b/.gitignore
> index 3af66272d6f1..d3038aff4485 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -58,6 +58,7 @@ modules.order
> /TAGS
> /linux
> /vmlinux
> +/vmlinux.map
Could you move this one line below
so that vmlinux.map is placed between
vmlinux.32 and vmlinux.symvers ?
I know this list is not sorted...
> /vmlinux.32
> /vmlinux.symvers
> /vmlinux-gdb.py
Please add this to Documentation/dontdiff as well.
> diff --git a/Makefile b/Makefile
> index b18dbc634690..be6fbd99a214 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1501,7 +1501,8 @@ endif # CONFIG_MODULES
> # Directories & files removed with 'make clean'
> CLEAN_FILES += include/ksym vmlinux.symvers \
>modules.builtin modules.builtin.modinfo modules.nsdeps \
> - compile_commands.json
> + compile_commands.json \
> + vmlinux.map
Do you need this ?
You already added this to cleanup() of scripts/link-vmlinux.sh,
which is invoked from 'make clean'.
> # Directories & files removed with 'make mrproper'
> MRPROPER_FILES += include/config include/generated \
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 5ea0c1773b0a..d6af084c11ae 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -412,6 +412,15 @@ config VMLINUX_VALIDATION
> depends on STACK_VALIDATION && DEBUG_ENTRY && !PARAVIRT
> default y
>
> +config VMLINUX_MAP
> + bool "Generate vmlinux.map file when linking" if EXPERT
Please use depends on EXPERT
because VMLINUX_MAP is not select or implied by anyone.
> + help
> + Selecting this option will pass "-Map=vmlinux.map" to ld
> + when linking vmlinux. That file can be useful for verifying
> + and debugging magic section games, and for seeing which
> + pieces of code get eliminated with
> + CONFIG_LD_DEAD_CODE_DATA_ELIMINATION.
> +
> config DEBUG_FORCE_WEAK_PER_CPU
> bool "Force weak per-cpu definitions"
> depends on DEBUG_KERNEL
> diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
> index 3b261b0f74f0..bba58839db40 100755
> --- a/scripts/link-vmlinux.sh
> +++ b/scripts/link-vmlinux.sh
> @@ -166,6 +166,12 @@ vmlinux_link()
> strip_debug=-Wl,--strip-debug
> fi
>
> + if [ -n "${CONFIG_VMLINUX_MAP}" ]; then
> + map_option="-Map=${output}.map"
> + else
> + map_option=""
> + fi
> +
For consistency, please do like strip_debug, that is,
define this as a local variable, and
set the value of the 'if' case.
> if [ "${SRCARCH}" != "um" ]; then
> if [ -n "${CONFIG_LTO_CLANG}" ]; then
> # Use vmlinux.o instead of performing the slow LTO
> @@ -187,6 +193,7 @@ vmlinux_link()
> ${LD} ${KBUILD_LDFLAGS} ${LDFLAGS_vmlinux} \
> ${strip_debug#-Wl,} \
> -o ${output}\
> + ${map_option} \
> -T ${lds} ${objects}
> else
> objects="-Wl,--whole-archive\
> @@ -200,6 +207,7 @@ vmlinux_link()
> ${CC} ${CFLAGS_vmlinux} \
> ${strip_debug} \
> -o ${output}\
> + ${map_option:+-Wl,${map_option}}\
> -Wl,-T,${lds} \
> ${objects} \
> -lutil -lrt -lpthread
> @@ -303,6 +311,7 @@ cleanup()
> rm -f .tmp_vmlinux*
> rm -f System.map
> rm -f vmlinux
> + rm -f vmlinux.map
> rm -f vmlinux.o
> }
>
> --
> 2.29.2
>
--
Best Regards
Masahiro Yamada
[PATCH net 1/1] stmmac: intel: Fixes clock registration error seen for multiple interfaces
From: Wong Vee Khee
Issue seen when enumerating multiple Intel mGbE interfaces in EHL.
[6.898141] intel-eth-pci :00:1d.2: enabling device ( -> 0002)
[6.900971] intel-eth-pci :00:1d.2: Fail to register stmmac-clk
[6.906434] intel-eth-pci :00:1d.2: User ID: 0x51, Synopsys ID: 0x52
We fix it by making the clock name to be unique following the format
of stmmac-pci_name(pci_dev) so that we can differentiate the clock for
these Intel mGbE interfaces in EHL platform as follow:
/sys/kernel/debug/clk/stmmac-:00:1d.1
/sys/kernel/debug/clk/stmmac-:00:1d.2
/sys/kernel/debug/clk/stmmac-:00:1e.4
Fixes: 58da0cfa6cf1 ("net: stmmac: create dwmac-intel.c to contain all Intel
platform")
Signed-off-by: Wong Vee Khee
Signed-off-by: Voon Weifeng
Co-developed-by: Ong Boon Leong
Signed-off-by: Ong Boon Leong
---
drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index f2896872a86c..0b64f7710d17 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -233,6 +233,7 @@ static void common_default_data(struct plat_stmmacenet_data
*plat)
static int intel_mgbe_common_data(struct pci_dev *pdev,
struct plat_stmmacenet_data *plat)
{
+ char clk_name[20];
int ret;
int i;
@@ -301,8 +302,10 @@ static int intel_mgbe_common_data(struct pci_dev *pdev,
plat->eee_usecs_rate = plat->clk_ptp_rate;
/* Set system clock */
+ sprintf(clk_name, "%s-%s", "stmmac", pci_name(pdev));
+
plat->stmmac_clk = clk_register_fixed_rate(>dev,
- "stmmac-clk", NULL, 0,
+ clk_name, NULL, 0,
plat->clk_ptp_rate);
if (IS_ERR(plat->stmmac_clk)) {
--
2.17.0
[PATCH V2 mips/linux.git] firmware: bcm47xx_nvram: refactor finding & reading NVRAM
From: Rafał Miłecki
1. Use meaningful variable names (e.g. "flash_start", "res_size" instead
of e.g. "iobase", "end")
2. Always operate on "offset" instead of mix of start, end, size, etc.
3. Add helper checking for NVRAM to avoid duplicating code
4. Use "found" variable instead of goto
5. Use simpler checking of offsets and sizes (2 nested loops with
trivial check instead of extra function)
This change has been tested on BCM4706. Updated code checks the same
offsets as before. Driver still finds & copies NVRAM content.
Signed-off-by: Rafał Miłecki
---
V2: Fix comment to match actual function name
Reported-by: kernel test robot
---
drivers/firmware/broadcom/bcm47xx_nvram.c | 111 --
1 file changed, 63 insertions(+), 48 deletions(-)
diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
b/drivers/firmware/broadcom/bcm47xx_nvram.c
index 835ece9c00f1..b47c80a79358 100644
--- a/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -34,26 +34,47 @@ static char nvram_buf[NVRAM_SPACE];
static size_t nvram_len;
static const u32 nvram_sizes[] = {0x6000, 0x8000, 0xF000, 0x1};
-static u32 find_nvram_size(void __iomem *end)
+/**
+ * bcm47xx_nvram_is_valid - check for a valid NVRAM at specified memory
+ */
+static bool bcm47xx_nvram_is_valid(void __iomem *nvram)
{
- struct nvram_header __iomem *header;
- int i;
+ return ((struct nvram_header *)nvram)->magic == NVRAM_MAGIC;
+}
- for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
- header = (struct nvram_header *)(end - nvram_sizes[i]);
- if (header->magic == NVRAM_MAGIC)
- return nvram_sizes[i];
+/**
+ * bcm47xx_nvram_copy - copy NVRAM to internal buffer
+ */
+static void bcm47xx_nvram_copy(void __iomem *nvram_start, size_t res_size)
+{
+ struct nvram_header __iomem *header = nvram_start;
+ size_t copy_size;
+
+ copy_size = header->len;
+ if (copy_size > res_size) {
+ pr_err("The nvram size according to the header seems to be
bigger than the partition on flash\n");
+ copy_size = res_size;
+ }
+ if (copy_size >= NVRAM_SPACE) {
+ pr_err("nvram on flash (%zu bytes) is bigger than the reserved
space in memory, will just copy the first %i bytes\n",
+ copy_size, NVRAM_SPACE - 1);
+ copy_size = NVRAM_SPACE - 1;
}
- return 0;
+ __ioread32_copy(nvram_buf, nvram_start, DIV_ROUND_UP(copy_size, 4));
+ nvram_buf[NVRAM_SPACE - 1] = '\0';
+ nvram_len = copy_size;
}
-/* Probe for NVRAM header */
-static int nvram_find_and_copy(void __iomem *iobase, u32 lim)
+/**
+ * bcm47xx_nvram_find_and_copy - find NVRAM on flash mapping & copy it
+ */
+static int bcm47xx_nvram_find_and_copy(void __iomem *flash_start, size_t
res_size)
{
- struct nvram_header __iomem *header;
- u32 off;
- u32 size;
+ size_t flash_size;
+ size_t offset;
+ bool found;
+ int i;
if (nvram_len) {
pr_warn("nvram already initialized\n");
@@ -61,49 +82,43 @@ static int nvram_find_and_copy(void __iomem *iobase, u32
lim)
}
/* TODO: when nvram is on nand flash check for bad blocks first. */
- off = FLASH_MIN;
- while (off <= lim) {
- /* Windowed flash access */
- size = find_nvram_size(iobase + off);
- if (size) {
- header = (struct nvram_header *)(iobase + off - size);
- goto found;
+
+ found = false;
+
+ /* Try every possible flash size and check for NVRAM at its end */
+ for (flash_size = FLASH_MIN; flash_size <= res_size; flash_size <<= 1) {
+ for (i = 0; i < ARRAY_SIZE(nvram_sizes); i++) {
+ offset = flash_size - nvram_sizes[i];
+ if (bcm47xx_nvram_is_valid(flash_start + offset)) {
+ found = true;
+ break;
+ }
}
- off <<= 1;
+
+ if (found)
+ break;
}
/* Try embedded NVRAM at 4 KB and 1 KB as last resorts */
- header = (struct nvram_header *)(iobase + 4096);
- if (header->magic == NVRAM_MAGIC) {
- size = NVRAM_SPACE;
- goto found;
- }
- header = (struct nvram_header *)(iobase + 1024);
- if (header->magic == NVRAM_MAGIC) {
- size = NVRAM_SPACE;
- goto found;
+ if (!found) {
+ offset = 4096;
+ if (bcm47xx_nvram_is_valid(flash_start + offset))
+ found = true;
}
- pr_err("no nvram found\n");
- return -ENXIO;
-
-found:
- __ioread32_copy(nvram_buf, header, sizeof(*header) / 4);
- nvram_len = ((struct nvram_header
Re: [PATCH] powerpc/perf: prevent mixed EBB and non-EBB events
> On 24-Feb-2021, at 5:51 PM, Thadeu Lima de Souza Cascardo
> wrote:
>
> EBB events must be under exclusive groups, so there is no mix of EBB and
> non-EBB events on the same PMU. This requirement worked fine as perf core
> would not allow other pinned events to be scheduled together with exclusive
> events.
>
> This assumption was broken by commit 1908dc911792 ("perf: Tweak
> perf_event_attr::exclusive semantics").
>
> After that, the test cpu_event_pinned_vs_ebb_test started succeeding after
> read_events, but worse, the task would not have given access to PMC1, so
> when it tried to write to it, it was killed with "illegal instruction".
>
> Preventing mixed EBB and non-EBB events from being add to the same PMU will
> just revert to the previous behavior and the test will succeed.
Hi,
Thanks for checking this. I checked your patch which is fixing “check_excludes”
to make
sure all events must agree on EBB. But in the PMU group constraints, we already
have check for
EBB events. This is in arch/powerpc/perf/isa207-common.c (
isa207_get_constraint function ).
<<>>
mask |= CNST_EBB_VAL(ebb);
value |= CNST_EBB_MASK;
<<>>
But the above setting for mask and value is interchanged. We actually need to
fix here.
Below patch should fix this:
diff --git a/arch/powerpc/perf/isa207-common.c
b/arch/powerpc/perf/isa207-common.c
index e4f577da33d8..8b5eeb6fb2fb 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -447,8 +447,8 @@ int isa207_get_constraint(u64 event, unsigned long *maskp,
unsigned long *valp,
* EBB events are pinned & exclusive, so this should never actually
* hit, but we leave it as a fallback in case.
*/
- mask |= CNST_EBB_VAL(ebb);
- value |= CNST_EBB_MASK;
+ mask |= CNST_EBB_MASK;
+ value |= CNST_EBB_VAL(ebb);
*maskp = mask;
*valp = value;
Can you please try with this patch.
Thanks
Athira
>
> Fixes: 1908dc911792 (perf: Tweak perf_event_attr::exclusive semantics)
> Signed-off-by: Thadeu Lima de Souza Cascardo
> ---
> arch/powerpc/perf/core-book3s.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 43599e671d38..d767f7944f85 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -1010,9 +1010,25 @@ static int check_excludes(struct perf_event **ctrs,
> unsigned int cflags[],
> int n_prev, int n_new)
> {
> int eu = 0, ek = 0, eh = 0;
> + bool ebb = false;
> int i, n, first;
> struct perf_event *event;
>
> + n = n_prev + n_new;
> + if (n <= 1)
> + return 0;
> +
> + first = 1;
> + for (i = 0; i < n; ++i) {
> + event = ctrs[i];
> + if (first) {
> + ebb = is_ebb_event(event);
> + first = 0;
> + } else if (is_ebb_event(event) != ebb) {
> + return -EAGAIN;
> + }
> + }
> +
> /*
>* If the PMU we're on supports per event exclude settings then we
>* don't need to do any of this logic. NB. This assumes no PMU has both
> @@ -1021,10 +1037,6 @@ static int check_excludes(struct perf_event **ctrs,
> unsigned int cflags[],
> if (ppmu->flags & PPMU_ARCH_207S)
> return 0;
>
> - n = n_prev + n_new;
> - if (n <= 1)
> - return 0;
> -
> first = 1;
> for (i = 0; i < n; ++i) {
> if (cflags[i] & PPMU_LIMITED_PMC_OK) {
> --
> 2.27.0
>
kernel/rcu/tree.c:2073:23: warning: stack frame size of 2112 bytes in function 'rcu_gp_kthread'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 280d542f6ffac0e6d65dc267f92191d509b13b64 commit: 7dffe01765d9309b8bd5505503933ec0ec53d192 rcu: Add lockdep_assert_irqs_disabled() to raw_spin_unlock_rcu_node() macros date: 8 weeks ago config: powerpc-randconfig-r035-20210305 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 4d90e460bcc7b3e5ff6c7e2e05e974772489c4b8) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7dffe01765d9309b8bd5505503933ec0ec53d192 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 7dffe01765d9309b8bd5505503933ec0ec53d192 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): __do_insb ^ arch/powerpc/include/asm/io.h:541:56: note: expanded from macro '__do_insb' #define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from kernel/rcu/tree.c:26: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :244:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from kernel/rcu/tree.c:26: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :246:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from kernel/rcu/tree.c:26: In file included from include/linux/interrupt.h:11: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :3:1: note: expanded from here __do_outsb ^ arch/powerpc/include/asm/io.h:544:58: note: expanded from macro '__do_outsb' #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n))
Re: [PATCH] ibmvnic: remove excessive irqsave
Le 05/03/2021 à 02:43, angkery a écrit : From: Junlin Yang ibmvnic_remove locks multiple spinlocks while disabling interrupts: spin_lock_irqsave(>state_lock, flags); spin_lock_irqsave(>rwi_lock, flags); there is no need for the second irqsave,since interrupts are disabled at that point, so remove the second irqsave: The problème is not that there is no need. The problem is a lot more serious: As reported by coccinella, the second _irqsave() overwrites the value saved in 'flags' by the first _irqsave, therefore when the second _irqrestore comes, the value in 'flags' is not valid, the value saved by the first _irqsave has been lost. This likely leads to IRQs remaining disabled, which is _THE_ problem really. spin_lock_irqsave(>state_lock, flags); spin_lock(>rwi_lock); Generated by: ./scripts/coccinelle/locks/flags.cocci ./drivers/net/ethernet/ibm/ibmvnic.c:5413:1-18: ERROR: nested lock+irqsave that reuses flags from line 5404. Signed-off-by: Junlin Yang --- drivers/net/ethernet/ibm/ibmvnic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 2464c8a..a52668d 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -5408,9 +5408,9 @@ static void ibmvnic_remove(struct vio_dev *dev) * after setting state, so __ibmvnic_reset() which is called * from the flush_work() below, can make progress. */ - spin_lock_irqsave(>rwi_lock, flags); + spin_lock(>rwi_lock); adapter->state = VNIC_REMOVING; - spin_unlock_irqrestore(>rwi_lock, flags); + spin_unlock(>rwi_lock); spin_unlock_irqrestore(>state_lock, flags);
Re: [PATCH v6] i2c: virtio: add a virtio i2c frontend driver
On 2021/3/4 17:15, Jason Wang wrote:
On 2021/3/4 9:59 上午, Jie Deng wrote:
Add an I2C bus driver for virtio para-virtualization.
The controller can be emulated by the backend driver in
any device model software by following the virtio protocol.
The device specification can be found on
https://lists.oasis-open.org/archives/virtio-comment/202101/msg8.html.
By following the specification, people may implement different
backend drivers to emulate different controllers according to
their needs.
Co-developed-by: Conghui Chen
Signed-off-by: Conghui Chen
Signed-off-by: Jie Deng
---
drivers/i2c/busses/Kconfig | 11 ++
drivers/i2c/busses/Makefile | 3 +
drivers/i2c/busses/i2c-virtio.c | 289
include/uapi/linux/virtio_i2c.h | 42 ++
include/uapi/linux/virtio_ids.h | 1 +
5 files changed, 346 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-virtio.c
create mode 100644 include/uapi/linux/virtio_i2c.h
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 05ebf75..0860395 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -21,6 +21,17 @@ config I2C_ALI1535
This driver can also be built as a module. If so, the module
will be called i2c-ali1535.
+config I2C_VIRTIO
+ tristate "Virtio I2C Adapter"
+ depends on VIRTIO
Please use select here. There's no prompt for VIRTIO.
OK.
+ help
+ If you say yes to this option, support will be included for
the virtio
+ I2C adapter driver. The hardware can be emulated by any device
model
+ software according to the virtio protocol.
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-virtio.
+
config I2C_ALI1563
tristate "ALI 1563"
depends on PCI
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 615f35e..b88da08 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -6,6 +6,9 @@
# ACPI drivers
obj-$(CONFIG_I2C_SCMI) += i2c-scmi.o
+# VIRTIO I2C host controller driver
+obj-$(CONFIG_I2C_VIRTIO) += i2c-virtio.o
+
# PC SMBus host controller drivers
obj-$(CONFIG_I2C_ALI1535) += i2c-ali1535.o
obj-$(CONFIG_I2C_ALI1563) += i2c-ali1563.o
diff --git a/drivers/i2c/busses/i2c-virtio.c
b/drivers/i2c/busses/i2c-virtio.c
new file mode 100644
index 000..98c0fcc
--- /dev/null
+++ b/drivers/i2c/busses/i2c-virtio.c
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Virtio I2C Bus Driver
+ *
+ * The Virtio I2C Specification:
+ *
https://raw.githubusercontent.com/oasis-tcs/virtio-spec/master/virtio-i2c.tex
+ *
+ * Copyright (c) 2021 Intel Corporation. All rights reserved.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+/**
+ * struct virtio_i2c - virtio I2C data
+ * @vdev: virtio device for this controller
+ * @completion: completion of virtio I2C message
+ * @adap: I2C adapter for this controller
+ * @i2c_lock: lock for virtqueue processing
+ * @vq: the virtio virtqueue for communication
+ */
+struct virtio_i2c {
+ struct virtio_device *vdev;
+ struct completion completion;
+ struct i2c_adapter adap;
+ struct mutex i2c_lock;
+ struct virtqueue *vq;
+};
+
+/**
+ * struct virtio_i2c_req - the virtio I2C request structure
+ * @out_hdr: the OUT header of the virtio I2C message
+ * @buf: the buffer into which data is read, or from which it's written
+ * @in_hdr: the IN header of the virtio I2C message
+ */
+struct virtio_i2c_req {
+ struct virtio_i2c_out_hdr out_hdr;
+ u8 *buf;
+ struct virtio_i2c_in_hdr in_hdr;
+};
+
+static void virtio_i2c_msg_done(struct virtqueue *vq)
+{
+ struct virtio_i2c *vi = vq->vdev->priv;
+
+ complete(>completion);
+}
+
+static int virtio_i2c_send_reqs(struct virtqueue *vq,
+ struct virtio_i2c_req *reqs,
+ struct i2c_msg *msgs, int nr)
+{
+ struct scatterlist *sgs[3], out_hdr, msg_buf, in_hdr;
+ int i, outcnt, incnt, err = 0;
+ u8 *buf;
+
+ for (i = 0; i < nr; i++) {
+ if (!msgs[i].len)
+ break;
+
+ /* Only 7-bit mode supported for this moment. For the
address format,
+ * Please check the Virtio I2C Specification.
+ */
+ reqs[i].out_hdr.addr = cpu_to_le16(msgs[i].addr << 1);
+
+ if (i != nr - 1)
+ reqs[i].out_hdr.flags |= VIRTIO_I2C_FLAGS_FAIL_NEXT;
+
+ outcnt = incnt = 0;
+ sg_init_one(_hdr, [i].out_hdr,
sizeof(reqs[i].out_hdr));
+ sgs[outcnt++] = _hdr;
+
+ buf = kzalloc(msgs[i].len, GFP_KERNEL);
+ if (!buf)
+ break;
+
+ reqs[i].buf = buf;
+ sg_init_one(_buf, reqs[i].buf, msgs[i].len);
+
+ if (msgs[i].flags & I2C_M_RD) {
+ sgs[outcnt + incnt++] = _buf;
+ } else {
+ memcpy(reqs[i].buf, msgs[i].buf,
[PATCH] ibmvnic: remove excessive irqsave
From: Junlin Yang ibmvnic_remove locks multiple spinlocks while disabling interrupts: spin_lock_irqsave(>state_lock, flags); spin_lock_irqsave(>rwi_lock, flags); there is no need for the second irqsave,since interrupts are disabled at that point, so remove the second irqsave: spin_lock_irqsave(>state_lock, flags); spin_lock(>rwi_lock); Generated by: ./scripts/coccinelle/locks/flags.cocci ./drivers/net/ethernet/ibm/ibmvnic.c:5413:1-18: ERROR: nested lock+irqsave that reuses flags from line 5404. Signed-off-by: Junlin Yang --- drivers/net/ethernet/ibm/ibmvnic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c index 2464c8a..a52668d 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -5408,9 +5408,9 @@ static void ibmvnic_remove(struct vio_dev *dev) * after setting state, so __ibmvnic_reset() which is called * from the flush_work() below, can make progress. */ - spin_lock_irqsave(>rwi_lock, flags); + spin_lock(>rwi_lock); adapter->state = VNIC_REMOVING; - spin_unlock_irqrestore(>rwi_lock, flags); + spin_unlock(>rwi_lock); spin_unlock_irqrestore(>state_lock, flags); -- 1.9.1
Re: [PATCH 04/13] dt-bindings: qcom,pdc: Add compatible for sc7280
On 2/23/2021 1:09 PM, Stephen Boyd wrote: Quoting Rajendra Nayak (2021-02-11 23:28:41) Add the compatible string for sc7180 SoC from Qualcomm Signed-off-by: Rajendra Nayak --- Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt | 1 + Is this being YAML-ified at some point? forgot to mention, Maulik already has a patch for it which he plans to post soon. -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH net 1/1] net: stmmac: Fix VLAN filter delete timeout issue in Intel mGBE SGMII
For Intel mGbE controller, MAC VLAN filter delete operation will time-out
if serdes power-down sequence happened first during driver remove() with
below message.
[82294.764958] intel-eth-pci :00:1e.4 eth2: stmmac_dvr_remove: removing
driver
[82294.778677] intel-eth-pci :00:1e.4 eth2: Timeout accessing
MAC_VLAN_Tag_Filter
[82294.779997] intel-eth-pci :00:1e.4 eth2: failed to kill vid 0081/0
[82294.947053] intel-eth-pci :00:1d.2 eth1: stmmac_dvr_remove: removing
driver
[82295.002091] intel-eth-pci :00:1d.1 eth0: stmmac_dvr_remove: removing
driver
Therefore, we delay the serdes power-down to be after unregister_netdev()
which triggers the VLAN filter delete.
Fixes: b9663b7ca6ff ("net: stmmac: Enable SERDES power up/down sequence")
Signed-off-by: Ong Boon Leong
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0eba44e9c1f8..208cae344ffa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -5249,13 +5249,16 @@ int stmmac_dvr_remove(struct device *dev)
netdev_info(priv->dev, "%s: removing driver", __func__);
stmmac_stop_all_dma(priv);
+ stmmac_mac_set(priv, priv->ioaddr, false);
+ netif_carrier_off(ndev);
+ unregister_netdev(ndev);
+ /* Serdes power down needs to happen after VLAN filter
+* is deleted that is triggered by unregister_netdev().
+*/
if (priv->plat->serdes_powerdown)
priv->plat->serdes_powerdown(ndev, priv->plat->bsp_priv);
- stmmac_mac_set(priv, priv->ioaddr, false);
- netif_carrier_off(ndev);
- unregister_netdev(ndev);
#ifdef CONFIG_DEBUG_FS
stmmac_exit_fs(ndev);
#endif
--
2.17.0
Re: [PATCH v2 13/14] arm64: dts: qcom: sc7280: Add cpuidle states
On 3/4/2021 5:43 AM, Stephen Boyd wrote: Quoting Rajendra Nayak (2021-03-03 04:17:57) From: Maulik Shah Add cpuidle states for little and big cpus. Please also say "The latency values are preliminary placeholders and will be updated once testing provides the real numbers". will do when I respin, thanks. Signed-off-by: Maulik Shah Signed-off-by: Rajendra Nayak --- With that commit text update Reviewed-by: Stephen Boyd -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH v2 12/14] arm64: dts: qcom: sc7280: Add SPMI PMIC arbiter device for SC7280
On 3/4/2021 5:42 AM, Stephen Boyd wrote:
Quoting Rajendra Nayak (2021-03-03 04:17:56)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index fe4fdb9..aa6f847 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -239,6 +239,25 @@
interrupt-controller;
};
+ spmi_bus: spmi@c44 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg = <0 0x0c44 0 0x1100>,
+ <0 0x0c60 0 0x200>,
+ <0 0x0e60 0 0x10>,
+ <0 0x0e70 0 0xa>,
+ <0 0x0c40a000 0 0x26000>;
+ reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
+ interrupt-names = "periph_irq";
+ interrupts-extended = < 1 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,ee = <0>;
+ qcom,channel = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
I see the binding says these should be 2 instead of 1 but I suspect that
is incorrect.
yeah looks like the bindings need to be fixed
+ interrupt-controller;
+ #interrupt-cells = <4>;
+ cell-index = <0>;
Is cell-index used? Please remove as I don't see it used anywhere and
not in the binding.
I'll drop it. thanks
+ };
+
tlmm: pinctrl@f10 {
compatible = "qcom,sc7280-pinctrl";
reg = <0 0x0f10 0 0x100>;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH net-next RFC] net: x25: Queue received packets in the drivers instead of per-CPU queues
X.25 Layer 3 (the Packet Layer) expects layer 2 to provide a reliable
datalink service such that no packets are reordered or dropped. And
X.25 Layer 2 (the LAPB layer) is indeed designed to provide such service.
However, this reliability is not preserved when a driver calls "netif_rx"
to deliver the received packets to layer 3, because "netif_rx" will put
the packets into per-CPU queues before they are delivered to layer 3.
If there are multiple CPUs, the order of the packets may not be preserved.
The per-CPU queues may also drop packets if there are too many.
Therefore, we should not call "netif_rx" to let it queue the packets.
Instead, we should use our own queue that won't reorder or drop packets.
This patch changes all X.25 drivers to use their own queues instead of
calling "netif_rx". The patch also documents this requirement in the
"x25-iface" documentation.
Cc: Martin Schiller
Signed-off-by: Xie He
---
Documentation/networking/x25-iface.rst | 65 --
drivers/net/wan/hdlc_x25.c | 29 +++-
drivers/net/wan/lapbether.c| 46 --
3 files changed, 79 insertions(+), 61 deletions(-)
diff --git a/Documentation/networking/x25-iface.rst
b/Documentation/networking/x25-iface.rst
index df401891dce6..f34e9ec64937 100644
--- a/Documentation/networking/x25-iface.rst
+++ b/Documentation/networking/x25-iface.rst
@@ -70,60 +70,13 @@ First Byte = 0x03 (X25_IFACE_PARAMS)
LAPB parameters. To be defined.
+Requirements for the device driver
+--
-Possible Problems
-=
-
-(Henner Eisen, 2000-10-28)
-
-The X.25 packet layer protocol depends on a reliable datalink service.
-The LAPB protocol provides such reliable service. But this reliability
-is not preserved by the Linux network device driver interface:
-
-- With Linux 2.4.x (and above) SMP kernels, packet ordering is not
- preserved. Even if a device driver calls netif_rx(skb1) and later
- netif_rx(skb2), skb2 might be delivered to the network layer
- earlier that skb1.
-- Data passed upstream by means of netif_rx() might be dropped by the
- kernel if the backlog queue is congested.
-
-The X.25 packet layer protocol will detect this and reset the virtual
-call in question. But many upper layer protocols are not designed to
-handle such N-Reset events gracefully. And frequent N-Reset events
-will always degrade performance.
-
-Thus, driver authors should make netif_rx() as reliable as possible:
-
-SMP re-ordering will not occur if the driver's interrupt handler is
-always executed on the same CPU. Thus,
-
-- Driver authors should use irq affinity for the interrupt handler.
-
-The probability of packet loss due to backlog congestion can be
-reduced by the following measures or a combination thereof:
-
-(1) Drivers for kernel versions 2.4.x and above should always check the
-return value of netif_rx(). If it returns NET_RX_DROP, the
-driver's LAPB protocol must not confirm reception of the frame
-to the peer.
-This will reliably suppress packet loss. The LAPB protocol will
-automatically cause the peer to re-transmit the dropped packet
-later.
-The lapb module interface was modified to support this. Its
-data_indication() method should now transparently pass the
-netif_rx() return value to the (lapb module) caller.
-(2) Drivers for kernel versions 2.2.x should always check the global
-variable netdev_dropping when a new frame is received. The driver
-should only call netif_rx() if netdev_dropping is zero. Otherwise
-the driver should not confirm delivery of the frame and drop it.
-Alternatively, the driver can queue the frame internally and call
-netif_rx() later when netif_dropping is 0 again. In that case, delivery
-confirmation should also be deferred such that the internal queue
-cannot grow to much.
-This will not reliably avoid packet loss, but the probability
-of packet loss in netif_rx() path will be significantly reduced.
-(3) Additionally, driver authors might consider to support
-CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up
-when a previously congested backlog queue becomes empty again.
-The driver could uses this for flow-controlling the peer by means
-of the LAPB protocol's flow-control service.
+Packets should not be reordered or dropped when delivering between the
+Packet Layer and the device driver.
+
+To avoid packets from being reordered or dropped when delivering from
+the device driver to the Packet Layer, the device driver should not
+call "netif_rx" to deliver the received packets. Instead, it should
+call "netif_receive_skb_core" from softirq context to deliver them.
diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
index 4aaa6388b9ee..28e9cb2c5f1e 100644
--- a/drivers/net/wan/hdlc_x25.c
+++ b/drivers/net/wan/hdlc_x25.c
@@ -23,6 +23,8 @@
struct x25_state {
x25_hdlc_proto settings;
+
Re: [PATCH v2 05/14] arm64: dts: qcom: sc7280: Add RSC and PDC devices
On 3/4/2021 5:34 AM, Stephen Boyd wrote:
Quoting Rajendra Nayak (2021-03-03 04:17:49)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 4a56d9c..21c2399 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -30,6 +31,18 @@
};
};
+ reserved_memory: reserved-memory {
Do we plan to use this label at any point? I'd prefer we remove this
until it becomes useful.
sure, i'll drop it
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ aop_cmd_db_mem: memory@8086 {
+ reg = <0x0 0x8086 0x0 0x2>;
+ compatible = "qcom,cmd-db";
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <2>;
#size-cells = <0>;
@@ -203,6 +229,7 @@
interrupt-controller;
#interrupt-cells = <2>;
gpio-ranges = < 0 0 175>;
+ wakeup-parent = <>;
qup_uart5_default: qup-uart5-default {
pins = "gpio46", "gpio47";
@@ -287,6 +314,23 @@
status = "disabled";
};
};
+
+ apps_rsc: rsc@1820 {
Any better name than 'rsc'? Maybe 'power-controller'?
hmm, Maulik, any thoughts? This would perhaps need the bindings docs
to be updated as well (and maybe the existing platform DTs using rsc too)
+ compatible = "qcom,rpmh-rsc";
+ reg = <0 0x1820 0 0x1>,
+ <0 0x1821 0 0x1>,
+ <0 0x1822 0 0x1>;
+ reg-names = "drv-0", "drv-1", "drv-2";
+ interrupts = ,
+,
+;
+ qcom,tcs-offset = <0xd00>;
+ qcom,drv-id = <2>;
+ qcom,tcs-config = ,
+ ,
+ ,
+ ;
+ };
};
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH v2] arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems
According to latest errata of J721e [1], HS400 mode is not supported
in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2
subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v
in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode.
Also, update the itap delay values for all the MMCSD subsystems according
the latest J721e data sheet[2]
[1] - https://www.ti.com/lit/er/sprz455/sprz455.pdf
[2] - https://www.ti.com/lit/ds/symlink/tda4vm.pdf
Fixes: cd48ce86a4d0 ("arm64: dts: ti: k3-j721e-common-proc-board: Add support
for SD card UHS modes")
Signed-off-by: Aswath Govindraju
---
Changes since v1:
- Corrected the fixes tag to latest commit that makes changes to the
sdhci DT nodes.
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 8c84dafb7125..f1e7da3dfa27 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -1042,13 +1042,16 @@
assigned-clocks = <_clks 91 1>;
assigned-clock-parents = <_clks 91 2>;
bus-width = <8>;
- mmc-hs400-1_8v;
+ mmc-hs200-1_8v;
mmc-ddr-1_8v;
ti,otap-del-sel-legacy = <0xf>;
ti,otap-del-sel-mmc-hs = <0xf>;
ti,otap-del-sel-ddr52 = <0x5>;
ti,otap-del-sel-hs200 = <0x6>;
ti,otap-del-sel-hs400 = <0x0>;
+ ti,itap-del-sel-legacy = <0x10>;
+ ti,itap-del-sel-mmc-hs = <0xa>;
+ ti,itap-del-sel-ddr52 = <0x3>;
ti,trm-icp = <0x8>;
ti,strobe-sel = <0x77>;
dma-coherent;
@@ -1069,9 +1072,15 @@
ti,otap-del-sel-sdr25 = <0xf>;
ti,otap-del-sel-sdr50 = <0xc>;
ti,otap-del-sel-ddr50 = <0xc>;
+ ti,itap-del-sel-legacy = <0x0>;
+ ti,itap-del-sel-sd-hs = <0x0>;
+ ti,itap-del-sel-sdr12 = <0x0>;
+ ti,itap-del-sel-sdr25 = <0x0>;
+ ti,itap-del-sel-ddr50 = <0x2>;
ti,trm-icp = <0x8>;
ti,clkbuf-sel = <0x7>;
dma-coherent;
+ sdhci-caps-mask = <0x2 0x0>;
};
main_sdhci2: mmc@4f98000 {
@@ -1089,9 +1098,15 @@
ti,otap-del-sel-sdr25 = <0xf>;
ti,otap-del-sel-sdr50 = <0xc>;
ti,otap-del-sel-ddr50 = <0xc>;
+ ti,itap-del-sel-legacy = <0x0>;
+ ti,itap-del-sel-sd-hs = <0x0>;
+ ti,itap-del-sel-sdr12 = <0x0>;
+ ti,itap-del-sel-sdr25 = <0x0>;
+ ti,itap-del-sel-ddr50 = <0x2>;
ti,trm-icp = <0x8>;
ti,clkbuf-sel = <0x7>;
dma-coherent;
+ sdhci-caps-mask = <0x2 0x0>;
};
usbss0: cdns-usb@4104000 {
--
2.17.1
Re: [PATCH] tracing: fix memory leaks in __create_synth_event()
On Thu, Mar 04, 2021 at 09:40:49AM -0500, Steven Rostedt wrote: > On Thu, 4 Mar 2021 15:15:24 +0530 > Vamshi K Sthambamkadi wrote: > > Not anything to do with you. I have a set of fixes that I have queued that > requires a ~13 hour test to run before I push off to Linus. When it was > almost done, I discovered another bug. Fixed it. Killed the almost completed > running test, and restarted it for another 13 hour run. I woke up this > morning happy to see that it passed, but then found your patch. > > Wash, rinse, repeat! :-p Sorry for wrong timing of sending this patch :) Thanks for looking into it, and applying it. Regards, Vamshi
Re: A note on the 5.12-rc1 tag
On Fri, Mar 5, 2021 at 1:58 AM Josh Triplett wrote:
> On Wed, Mar 03, 2021 at 12:53:18PM -0800, Linus Torvalds wrote:
> > One additional reason for this note is that I want to not just warn
> > people to not run this if you have a swapfile - even if you are
> > personally not impacted (like I am, and probably most people are -
> > swap partitions all around) - I want to make sure that nobody starts
> > new topic branches using that 5.12-rc1 tag. I know a few developers
> > tend to go "Ok, rc1 is out, I got all my development work into this
> > merge window, I will now fast-forward to rc1 and use that as a base
> > for the next release". Don't do it this time. It may work perfectly
> > well for you because you have the common partition setup, but it can
> > end up being a horrible base for anybody else that might end up
> > bisecting into that area.
>
> Even if people avoid basing their topic branches on 5.12-rc1, it's still
> possible for a future bisect to end up wandering to one of the existing
> dangerous commits, if someone's trying to find a historical bug and git
> happens to choose that as a halfway point. And if they happen to be
> using a swap file, they could end up with serious data loss, years from
> now when "5.12-rc1 is broken" isn't on the top of their mind or even
> something they heard about originally.
>
> Would it make sense to add a feature to git that allows defining a
> "dangerous" region for bisect? Rough sketch:
> - Add a `/.git-bisect-dangerous` file to the repository, containing a
> list of of commit range expressions (contains commit X, doesn't
> contain commit Y) and associated messages ("Do not use these kernels
> if you have a swap file; if you need to bisect into here, disable swap
> files first").
> - git-bisect, as it navigates commits, always checks that file for any
> commit it processes, and adds any new entries it sees into
> `.git/bisect-dangerous`; it never removes entries from there.
The `git bisect skip` machinery uses `refs/bisect/skip-` refs
instead of such a file, so I wonder if such a file is needed. It could
be used to store a map between skipped commits and the associated
messages though. Or git notes could be used for that purpose.
By the way I wonder what should happen if a commit is associated with
a message by a `/.git-bisect-dangerous` file, but in another branch
such file associates it with a different message. I guess all the
different messages should be stored, and then displayed.
> - git-bisect avoids choosing bisection points anywhere in that range
> until it absolutely has to (because it's narrowed an issue to that
> range). This can use something similar to the existing `git bisect
> skip` machinery. Manual bisections print the message at that point.
> Automated bisections (`git bisect run`) stop and print the range
> without narrowing further, unless the user passes something like
> `--dangerous-ok=commit-range`.
Yeah, using the `git bisect skip` machinery looks like a good idea.
Instead of `/.git-bisect-dangerous`, the file could actually be called
`/.git-bisect-skip` and could also store ranges where the code doesn't
compile, or completely misbehave, without necessarily being dangerous.
The dangerous status would only be conveyed by the associated messages
then.
Another way could be to directly share some special refs similar to
the existing `refs/bisect/skip-` refs, instead of a
`/.git-bisect-dangerous` file. This would likely raise some issues
about how to create and share these refs and the associated messages
though.
> (git notes would be nice for this, but they're hard to share reliably;
> the above mechanism to accumulate entries from a file in the repo seems
> simpler. I can imagine other possibilities.)
If the notes are created automatically from the `/.git-bisect-skip`
files and stored in `refs/notes/skip`, then they might not need to be
shared. If people already share notes, they would just need to stop
sharing those in `refs/notes/skip`.
> Does something like this seem potentially reasonable, and worth doing to
> help people avoid future catastrophic data loss?
It seems reasonable as part of the skip mechanism.
[PATCH 2/3] dt-bindings: input: pm8941-pwrkey: Convert power key bindings to yaml
Convert power key bindings from .txt to .yaml format.
Signed-off-by: satya priya
---
.../bindings/input/qcom,pm8941-pwrkey.txt | 53 ---
.../bindings/input/qcom,pm8941-pwrkey.yaml | 76 ++
2 files changed, 76 insertions(+), 53 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
create mode 100644
Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
deleted file mode 100644
index 34ab576..000
--- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt
+++ /dev/null
@@ -1,53 +0,0 @@
-Qualcomm PM8941 PMIC Power Key
-
-PROPERTIES
-
-- compatible:
- Usage: required
- Value type:
- Definition: must be one of:
- "qcom,pm8941-pwrkey"
- "qcom,pm8941-resin"
-
-- reg:
- Usage: required
- Value type:
- Definition: base address of registers for block
-
-- interrupts:
- Usage: required
- Value type:
- Definition: key change interrupt; The format of the specifier is
- defined by the binding document describing the node's
- interrupt parent.
-
-- debounce:
- Usage: optional
- Value type:
- Definition: time in microseconds that key must be pressed or released
- for state change interrupt to trigger.
-
-- bias-pull-up:
- Usage: optional
- Value type:
- Definition: presence of this property indicates that the KPDPWR_N pin
- should be configured for pull up.
-
-- linux,code:
- Usage: optional
- Value type:
- Definition: The input key-code associated with the power key.
- Use the linux event codes defined in
- include/dt-bindings/input/linux-event-codes.h
- When property is omitted KEY_POWER is assumed.
-
-EXAMPLE
-
- pwrkey@800 {
- compatible = "qcom,pm8941-pwrkey";
- reg = <0x800>;
- interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
- debounce = <15625>;
- bias-pull-up;
- linux,code = ;
- };
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml
b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml
new file mode 100644
index 000..302866d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/qcom,pm8941-pwrkey.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm PM8941 PMIC Power Key
+
+maintainers:
+ - Courtney Cavin
+ - Vinod Koul
+
+properties:
+ compatible:
+enum:
+ - qcom,pm8941-pwrkey
+ - qcom,pm8941-resin
+
+ interrupts:
+description: |
+ Key change interrupt; The format of the specifier is
+ defined by the binding document describing the node's
+ interrupt parent.
+
+ debounce:
+description: |
+ Time in microseconds that key must be pressed or
+ released for state change interrupt to trigger.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+ bias-pull-up:
+description: |
+ Presence of this property indicates that the KPDPWR_N
+ pin should be configured for pull up.
+$ref: /schemas/types.yaml#/definitions/flag
+
+ linux,code:
+description: |
+ The input key-code associated with the power key.
+ Use the linux event codes defined in
+ include/dt-bindings/input/linux-event-codes.h
+ When property is omitted KEY_POWER is assumed.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include
+ #include
+ #include
+ spmi_bus: spmi@c44 {
+ reg = <0x0c44 0x1100>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ pmk8350: pmic@0 {
+ reg = <0x0 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmk8350_pon: pon_hlos@1300 {
+ reg = <0x1300>;
+ pwrkey {
+compatible = "qcom,pm8941-pwrkey";
+interrupts = < 0x0 0x8 0 IRQ_TYPE_EDGE_BOTH >;
+debounce = <15625>;
+bias-pull-up;
+linux,code = ;
+ };
+ };
+ };
+ };
+...
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 1/3] input: pm8941-pwrkey: add support for PMK8350 PON_HLOS PMIC peripheral
From: David Collins
On Qualcomm Technologies, Inc. PMIC PMK8350, the PON peripheral
is split into two peripherals: PON_HLOS and PON_PBS. The
application processor only has write access to PON_HLOS which
limits it to only receiving PON interrupts.
Add support for the PMK8350 PON_HLOS peripheral so that its
KPDPWR_N and RESIN_N interrupts can be used to detect key
presses.
Signed-off-by: David Collins
Signed-off-by: satya priya
---
drivers/input/misc/pm8941-pwrkey.c | 103 ++---
1 file changed, 72 insertions(+), 31 deletions(-)
diff --git a/drivers/input/misc/pm8941-pwrkey.c
b/drivers/input/misc/pm8941-pwrkey.c
index cf81044..2044d187 100644
--- a/drivers/input/misc/pm8941-pwrkey.c
+++ b/drivers/input/misc/pm8941-pwrkey.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * Copyright (c) 2010-2011, Code Aurora Forum. All rights reserved.
+ * Copyright (c) 2010-2011, 2020, The Linux Foundation. All rights reserved.
* Copyright (c) 2014, Sony Mobile Communications Inc.
*/
@@ -22,6 +22,8 @@
#define PON_RT_STS 0x10
#define PON_KPDPWR_N_SET BIT(0)
#define PON_RESIN_N_SET BIT(1)
+#define PON_GEN3_RESIN_N_SET BIT(6)
+#define PON_GEN3_KPDPWR_N_SET BIT(7)
#define PON_PS_HOLD_RST_CTL0x5a
#define PON_PS_HOLD_RST_CTL2 0x5b
@@ -38,8 +40,12 @@
#define PON_DBC_DELAY_MASK0x7
struct pm8941_data {
- unsigned int pull_up_bit;
- unsigned int status_bit;
+ unsigned intpull_up_bit;
+ unsigned intstatus_bit;
+ boolsupports_ps_hold_poff_config;
+ boolsupports_debounce_config;
+ const char *name;
+ const char *phys;
};
struct pm8941_pwrkey {
@@ -231,34 +237,40 @@ static int pm8941_pwrkey_probe(struct platform_device
*pdev)
input_set_capability(pwrkey->input, EV_KEY, pwrkey->code);
- pwrkey->input->name = "pm8941_pwrkey";
- pwrkey->input->phys = "pm8941_pwrkey/input0";
-
- req_delay = (req_delay << 6) / USEC_PER_SEC;
- req_delay = ilog2(req_delay);
-
- error = regmap_update_bits(pwrkey->regmap,
- pwrkey->baseaddr + PON_DBC_CTL,
- PON_DBC_DELAY_MASK,
- req_delay);
- if (error) {
- dev_err(>dev, "failed to set debounce: %d\n", error);
- return error;
+ pwrkey->input->name = pwrkey->data->name;
+ pwrkey->input->phys = pwrkey->data->phys;
+
+ if (pwrkey->data->supports_debounce_config) {
+ req_delay = (req_delay << 6) / USEC_PER_SEC;
+ req_delay = ilog2(req_delay);
+
+ error = regmap_update_bits(pwrkey->regmap,
+ pwrkey->baseaddr + PON_DBC_CTL,
+ PON_DBC_DELAY_MASK,
+ req_delay);
+ if (error) {
+ dev_err(>dev, "failed to set debounce: %d\n",
+ error);
+ return error;
+ }
}
- error = regmap_update_bits(pwrkey->regmap,
- pwrkey->baseaddr + PON_PULL_CTL,
- pwrkey->data->pull_up_bit,
- pull_up ? pwrkey->data->pull_up_bit : 0);
- if (error) {
- dev_err(>dev, "failed to set pull: %d\n", error);
- return error;
+ if (pwrkey->data->pull_up_bit) {
+ error = regmap_update_bits(pwrkey->regmap,
+ pwrkey->baseaddr + PON_PULL_CTL,
+ pwrkey->data->pull_up_bit,
+ pull_up ? pwrkey->data->pull_up_bit :
+0);
+ if (error) {
+ dev_err(>dev, "failed to set pull: %d\n", error);
+ return error;
+ }
}
error = devm_request_threaded_irq(>dev, pwrkey->irq,
NULL, pm8941_pwrkey_irq,
IRQF_ONESHOT,
- "pm8941_pwrkey", pwrkey);
+ pwrkey->data->name, pwrkey);
if (error) {
dev_err(>dev, "failed requesting IRQ: %d\n", error);
return error;
@@ -271,12 +283,14 @@ static int pm8941_pwrkey_probe(struct platform_device
*pdev)
return error;
}
- pwrkey->reboot_notifier.notifier_call = pm8941_reboot_notify,
- error = register_reboot_notifier(>reboot_notifier);
- if (error) {
- dev_err(>dev, "failed to register reboot notifier: %d\n",
- error);
-
[PATCH 3/3] dt-bindings: input: pm8941-pwrkey: Add pmk8350 compatible strings
From: David Collins Add power key and resin compatible strings for the PMK8350 PMIC. These are needed to distinguish key PON_HLOS register differences between PMK8350 and previous PMIC PON modules. Signed-off-by: David Collins Signed-off-by: satya priya --- Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml index 302866d..32ac762 100644 --- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml @@ -15,6 +15,8 @@ properties: enum: - qcom,pm8941-pwrkey - qcom,pm8941-resin + - qcom,pmk8350-pwrkey + - qcom,pmk8350-resin interrupts: description: | -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
[PATCH 0/3] Add support for PMK8350 PON_HLOS PMIC peripheral
David Collins (2): input: pm8941-pwrkey: add support for PMK8350 PON_HLOS PMIC peripheral dt-bindings: input: pm8941-pwrkey: Add pmk8350 compatible strings satya priya (1): dt-bindings: input: pm8941-pwrkey: Convert power key bindings to yaml .../bindings/input/qcom,pm8941-pwrkey.txt | 53 --- .../bindings/input/qcom,pm8941-pwrkey.yaml | 78 drivers/input/misc/pm8941-pwrkey.c | 103 ++--- 3 files changed, 150 insertions(+), 84 deletions(-) delete mode 100644 Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt create mode 100644 Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.yaml -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH V3 0/2] arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory
On 3/5/21 10:54 AM, Anshuman Khandual wrote: > This series fixes pfn_valid() for ZONE_DEVICE based memory and also improves > its performance for normal hotplug memory. While here, it also reorganizes > pfn_valid() on CONFIG_SPARSEMEM. This series is based on v5.12-rc1. > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Ard Biesheuvel > Cc: Mark Rutland > Cc: James Morse > Cc: Robin Murphy > Cc: Jérôme Glisse > Cc: Dan Williams > Cc: David Hildenbrand > Cc: Mike Rapoport > Cc: Veronika Kabatova > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > > Changes in V3: > > - Validate the pfn before fetching mem_section with __pfn_to_section() in > [PATCH 2/2] Hello Veronica, Could you please help recreate the earlier failure [1] but with this series applies on v5.12-rc1. Thank you. [1] https://lore.kernel.org/linux-arm-kernel/cki.8d1cb60fec.k6njmef...@redhat.com/ - Anshuman
Re: [PATCH] arm64: dts: ti: k3-j721e-main: Update the speed modes supported and their itap delay values for MMCSD subsystems
Hi Nishanth,
On 05/03/21 10:44 am, Nishanth Menon wrote:
> On 10:59-20210301, Kishon Vijay Abraham I wrote:
>> On 25/02/21 6:57 pm, Aswath Govindraju wrote:
>>> According to latest errata of J721e [1], HS400 mode is not supported
>>> in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2
>>> subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v
>>> in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode.
>>>
>>> Also, update the itap delay values for all the MMCSD subsystems according
>>> the latest J721e data sheet[2]
>>>
>>> [1] - https://www.ti.com/lit/er/sprz455/sprz455.pdf
>>> [2] - https://www.ti.com/lit/ds/symlink/tda4vm.pdf
>>>
>>> Fixes: e6dc10f200da ("arm64: dts: ti: j721e-main: Add SDHCI nodes")
>>> Signed-off-by: Aswath Govindraju
>>
>> Reviewed-by: Kishon Vijay Abraham I
>
>
> In some offline testing, I realized that the patch wont apply cleanly to
> e6dc10f200da
>
> cd48ce86a4d0c1ffec86aa46a26da993c9af5f53 might be a better candidate for
> this - I will drop the patch from my queue in the morning, could you
> update the patch with a new rev with appropriate Fixes?
>
Sorry, I'll send a respin(v2) of this patch after correcting the fixes
tag to,
Fixes: cd48ce86a4d0 ("arm64: dts: ti: k3-j721e-common-proc-board: Add
support for SD card UHS modes")
Thanks,
Aswath
arch/mips/mm/tlbex.c:2599 check_pabits() warn: always true condition '(fillbits >= ((__builtin_constant_p(0)) < 2) - __builtin_clzll(0)):((4 <= 4)) => (0-u32max >= 0)'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 280d542f6ffac0e6d65dc267f92191d509b13b64
commit: 2f78788b55baa3410b1ec91a576286abe1ad4d6a ilog2: improve ilog2 for
constant arguments
date: 3 months ago
config: mips-randconfig-m031-20210305 (attached as .config)
compiler: mips64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
smatch warnings:
arch/mips/mm/tlbex.c:2599 check_pabits() warn: always true condition '(fillbits
>= ((__builtin_constant_p(0)) ?(((0) < 2) ?0:63 - __builtin_clzll(0)):((4 <=
4)) ?__ilog2_u32(0):__ilog2_u64(0))) => (0-u32max >= 0)'
vim +2599 arch/mips/mm/tlbex.c
c5b367835cfc7a Steven J. Hill 2015-02-26 2569
00bf1c691d082c Paul Burton2015-09-22 2570 static void check_pabits(void)
00bf1c691d082c Paul Burton2015-09-22 2571 {
00bf1c691d082c Paul Burton2015-09-22 2572 unsigned long entry;
00bf1c691d082c Paul Burton2015-09-22 2573 unsigned pabits,
fillbits;
00bf1c691d082c Paul Burton2015-09-22 2574
00bf1c691d082c Paul Burton2015-09-22 2575 if (!cpu_has_rixi ||
!_PAGE_NO_EXEC) {
00bf1c691d082c Paul Burton2015-09-22 2576 /*
00bf1c691d082c Paul Burton2015-09-22 2577 * We'll only
be making use of the fact that we can rotate bits
00bf1c691d082c Paul Burton2015-09-22 2578 * into the
fill if the CPU supports RIXI, so don't bother
00bf1c691d082c Paul Burton2015-09-22 2579 * probing this
for CPUs which don't.
00bf1c691d082c Paul Burton2015-09-22 2580 */
00bf1c691d082c Paul Burton2015-09-22 2581 return;
00bf1c691d082c Paul Burton2015-09-22 2582 }
00bf1c691d082c Paul Burton2015-09-22 2583
00bf1c691d082c Paul Burton2015-09-22 2584 write_c0_entrylo0(~0ul);
00bf1c691d082c Paul Burton2015-09-22 2585
back_to_back_c0_hazard();
00bf1c691d082c Paul Burton2015-09-22 2586 entry =
read_c0_entrylo0();
00bf1c691d082c Paul Burton2015-09-22 2587
00bf1c691d082c Paul Burton2015-09-22 2588 /* clear all non-PFN
bits */
00bf1c691d082c Paul Burton2015-09-22 2589 entry &= ~((1 <<
MIPS_ENTRYLO_PFN_SHIFT) - 1);
00bf1c691d082c Paul Burton2015-09-22 2590 entry &=
~(MIPS_ENTRYLO_RI | MIPS_ENTRYLO_XI);
00bf1c691d082c Paul Burton2015-09-22 2591
00bf1c691d082c Paul Burton2015-09-22 2592 /* find a lower bound
on PABITS, and upper bound on fill bits */
00bf1c691d082c Paul Burton2015-09-22 2593 pabits =
fls_long(entry) + 6;
00bf1c691d082c Paul Burton2015-09-22 2594 fillbits = max_t(int,
(int)BITS_PER_LONG - pabits, 0);
00bf1c691d082c Paul Burton2015-09-22 2595
00bf1c691d082c Paul Burton2015-09-22 2596 /* minus the RI & XI
bits */
00bf1c691d082c Paul Burton2015-09-22 2597 fillbits -=
min_t(unsigned, fillbits, 2);
00bf1c691d082c Paul Burton2015-09-22 2598
00bf1c691d082c Paul Burton2015-09-22 @2599 if (fillbits >=
ilog2(_PAGE_NO_EXEC))
00bf1c691d082c Paul Burton2015-09-22 2600
fill_includes_sw_bits = true;
00bf1c691d082c Paul Burton2015-09-22 2601
00bf1c691d082c Paul Burton2015-09-22 2602 pr_debug("Entry*
registers contain %u fill bits\n", fillbits);
00bf1c691d082c Paul Burton2015-09-22 2603 }
00bf1c691d082c Paul Burton2015-09-22 2604
:: The code at line 2599 was first introduced by commit
:: 00bf1c691d082c1945fdba032c03a9a82e9e7e61 MIPS: tlbex: Avoid placing
software PTE bits in Entry* PFN fields
:: TO: Paul Burton
:: CC: Ralf Baechle
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH net-next 6/6] net: qualcomm: rmnet: don't use C bit-fields in rmnet checksum header
On Thu 04 Mar 16:34 CST 2021, Alex Elder wrote:
> Replace the use of C bit-fields in the rmnet_map_ul_csum_header
> structure with a single two-byte (big endian) structure member,
> and use field masks to encode or get values within it.
>
> Previously rmnet_map_ipv4_ul_csum_header() would update values in
> the host byte-order fields, and then forcibly fix their byte order
> using a combination of byte order operations and types.
>
> Instead, just compute the value that needs to go into the new
> structure member and save it with a simple byte-order conversion.
>
> Make similar simplifications in rmnet_map_ipv6_ul_csum_header().
>
> Finally, in rmnet_map_checksum_uplink_packet() a set of assignments
> zeroes every field in the upload checksum header. Replace that with
> a single memset() operation.
>
> Signed-off-by: Alex Elder
> ---
> .../ethernet/qualcomm/rmnet/rmnet_map_data.c | 34 ++-
> include/linux/if_rmnet.h | 21 ++--
> 2 files changed, 21 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> index 29d485b868a65..db76bbf000aa1 100644
> --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map_data.c
> @@ -198,23 +198,19 @@ rmnet_map_ipv4_ul_csum_header(void *iphdr,
> struct rmnet_map_ul_csum_header *ul_header,
> struct sk_buff *skb)
> {
> - __be16 *hdr = (__be16 *)ul_header;
> struct iphdr *ip4h = iphdr;
> u16 offset;
> + u16 val;
>
> offset = skb_transport_header(skb) - (unsigned char *)iphdr;
> ul_header->csum_start_offset = htons(offset);
>
> - ul_header->csum_insert_offset = skb->csum_offset;
> - ul_header->csum_enabled = 1;
> + val = be16_encode_bits(1, MAP_CSUM_UL_ENABLED_FMASK);
Why are you using be16_ here? Won't that cancel the htons() below?
Regards,
Bjorn
> if (ip4h->protocol == IPPROTO_UDP)
> - ul_header->udp_ind = 1;
> - else
> - ul_header->udp_ind = 0;
> + val |= be16_encode_bits(1, MAP_CSUM_UL_UDP_FMASK);
> + val |= be16_encode_bits(skb->csum_offset, MAP_CSUM_UL_OFFSET_FMASK);
>
> - /* Changing remaining fields to network order */
> - hdr++;
> - *hdr = htons((__force u16)*hdr);
> + ul_header->csum_info = htons(val);
>
> skb->ip_summed = CHECKSUM_NONE;
>
> @@ -241,24 +237,19 @@ rmnet_map_ipv6_ul_csum_header(void *ip6hdr,
> struct rmnet_map_ul_csum_header *ul_header,
> struct sk_buff *skb)
> {
> - __be16 *hdr = (__be16 *)ul_header;
> struct ipv6hdr *ip6h = ip6hdr;
> u16 offset;
> + u16 val;
>
> offset = skb_transport_header(skb) - (unsigned char *)ip6hdr;
> ul_header->csum_start_offset = htons(offset);
>
> - ul_header->csum_insert_offset = skb->csum_offset;
> - ul_header->csum_enabled = 1;
> -
> + val = be16_encode_bits(1, MAP_CSUM_UL_ENABLED_FMASK);
> if (ip6h->nexthdr == IPPROTO_UDP)
> - ul_header->udp_ind = 1;
> - else
> - ul_header->udp_ind = 0;
> + val |= be16_encode_bits(1, MAP_CSUM_UL_UDP_FMASK);
> + val |= be16_encode_bits(skb->csum_offset, MAP_CSUM_UL_OFFSET_FMASK);
>
> - /* Changing remaining fields to network order */
> - hdr++;
> - *hdr = htons((__force u16)*hdr);
> + ul_header->csum_info = htons(val);
>
> skb->ip_summed = CHECKSUM_NONE;
>
> @@ -425,10 +416,7 @@ void rmnet_map_checksum_uplink_packet(struct sk_buff
> *skb,
> }
>
> sw_csum:
> - ul_header->csum_start_offset = 0;
> - ul_header->csum_insert_offset = 0;
> - ul_header->csum_enabled = 0;
> - ul_header->udp_ind = 0;
> + memset(ul_header, 0, sizeof(*ul_header));
>
> priv->stats.csum_sw++;
> }
> diff --git a/include/linux/if_rmnet.h b/include/linux/if_rmnet.h
> index 1fbb7531238b6..149d696feb520 100644
> --- a/include/linux/if_rmnet.h
> +++ b/include/linux/if_rmnet.h
> @@ -33,17 +33,16 @@ struct rmnet_map_dl_csum_trailer {
>
> struct rmnet_map_ul_csum_header {
> __be16 csum_start_offset;
> -#if defined(__LITTLE_ENDIAN_BITFIELD)
> - u16 csum_insert_offset:14;
> - u16 udp_ind:1;
> - u16 csum_enabled:1;
> -#elif defined (__BIG_ENDIAN_BITFIELD)
> - u16 csum_enabled:1;
> - u16 udp_ind:1;
> - u16 csum_insert_offset:14;
> -#else
> -#error "Please fix "
> -#endif
> + __be16 csum_info; /* MAP_CSUM_UL_*_FMASK */
> } __aligned(1);
>
> +/* csum_info field:
> + * ENABLED: 1 = checksum computation requested
> + * UDP: 1 = UDP checksum (zero checkum means no checksum)
> + * OFFSET: where (offset in bytes) to insert computed checksum
> + */
> +#define MAP_CSUM_UL_OFFSET_FMASK GENMASK(13, 0)
> +#define MAP_CSUM_UL_UDP_FMASK
[PATCH V3 2/2] arm64/mm: Reorganize pfn_valid()
There are multiple instances of pfn_to_section_nr() and __pfn_to_section()
when CONFIG_SPARSEMEM is enabled. This can be optimized if memory section
is fetched earlier. This replaces the open coded PFN and ADDR conversion
with PFN_PHYS() and PHYS_PFN() helpers. While there, also add a comment.
This does not cause any functional change.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Ard Biesheuvel
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: David Hildenbrand
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/init.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 5920c527845a..3685e12aba9b 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -219,16 +219,26 @@ static void __init zone_sizes_init(unsigned long min,
unsigned long max)
int pfn_valid(unsigned long pfn)
{
- phys_addr_t addr = pfn << PAGE_SHIFT;
+ phys_addr_t addr = PFN_PHYS(pfn);
- if ((addr >> PAGE_SHIFT) != pfn)
+ /*
+* Ensure the upper PAGE_SHIFT bits are clear in the
+* pfn. Else it might lead to false positives when
+* some of the upper bits are set, but the lower bits
+* match a valid pfn.
+*/
+ if (PHYS_PFN(addr) != pfn)
return 0;
#ifdef CONFIG_SPARSEMEM
+{
+ struct mem_section *ms;
+
if (pfn_to_section_nr(pfn) >= NR_MEM_SECTIONS)
return 0;
- if (!valid_section(__pfn_to_section(pfn)))
+ ms = __pfn_to_section(pfn);
+ if (!valid_section(ms))
return 0;
/*
@@ -240,8 +250,9 @@ int pfn_valid(unsigned long pfn)
* memory sections covering all of hotplug memory including
* both normal and ZONE_DEVICE based.
*/
- if (!early_section(__pfn_to_section(pfn)))
- return pfn_section_valid(__pfn_to_section(pfn), pfn);
+ if (!early_section(ms))
+ return pfn_section_valid(ms, pfn);
+}
#endif
return memblock_is_map_memory(addr);
}
--
2.20.1
[PATCH V3 1/2] arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory
pfn_valid() validates a pfn but basically it checks for a valid struct page
backing for that pfn. It should always return positive for memory ranges
backed with struct page mapping. But currently pfn_valid() fails for all
ZONE_DEVICE based memory types even though they have struct page mapping.
pfn_valid() asserts that there is a memblock entry for a given pfn without
MEMBLOCK_NOMAP flag being set. The problem with ZONE_DEVICE based memory is
that they do not have memblock entries. Hence memblock_is_map_memory() will
invariably fail via memblock_search() for a ZONE_DEVICE based address. This
eventually fails pfn_valid() which is wrong. memblock_is_map_memory() needs
to be skipped for such memory ranges. As ZONE_DEVICE memory gets hotplugged
into the system via memremap_pages() called from a driver, their respective
memory sections will not have SECTION_IS_EARLY set.
Normal hotplug memory will never have MEMBLOCK_NOMAP set in their memblock
regions. Because the flag MEMBLOCK_NOMAP was specifically designed and set
for firmware reserved memory regions. memblock_is_map_memory() can just be
skipped as its always going to be positive and that will be an optimization
for the normal hotplug memory. Like ZONE_DEVICE based memory, all normal
hotplugged memory too will not have SECTION_IS_EARLY set for their sections
Skipping memblock_is_map_memory() for all non early memory sections would
fix pfn_valid() problem for ZONE_DEVICE based memory and also improve its
performance for normal hotplug memory as well.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Ard Biesheuvel
Cc: Robin Murphy
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Acked-by: David Hildenbrand
Fixes: 73b20c84d42d ("arm64: mm: implement pte_devmap support")
Signed-off-by: Anshuman Khandual
---
arch/arm64/mm/init.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 0ace5e68efba..5920c527845a 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -230,6 +230,18 @@ int pfn_valid(unsigned long pfn)
if (!valid_section(__pfn_to_section(pfn)))
return 0;
+
+ /*
+* ZONE_DEVICE memory does not have the memblock entries.
+* memblock_is_map_memory() check for ZONE_DEVICE based
+* addresses will always fail. Even the normal hotplugged
+* memory will never have MEMBLOCK_NOMAP flag set in their
+* memblock entries. Skip memblock search for all non early
+* memory sections covering all of hotplug memory including
+* both normal and ZONE_DEVICE based.
+*/
+ if (!early_section(__pfn_to_section(pfn)))
+ return pfn_section_valid(__pfn_to_section(pfn), pfn);
#endif
return memblock_is_map_memory(addr);
}
--
2.20.1
