Re: [PATCH 2/4] drm/vmwgfx: remove CONFIG_INTEL_IOMMU ifdefs v2
On Mon, 2019-02-04 at 13:11 +0100, Thomas Hellström wrote: > On Mon, 2019-02-04 at 09:19 +0100, Christoph Hellwig wrote: > > On Fri, Jan 25, 2019 at 09:12:13AM +0100, Thomas Hellstrom wrote: > > > -#if !defined(CONFIG_SWIOTLB) && !defined(CONFIG_INTEL_IOMMU) > > > - /* > > > - * No coherent page pool > > > - */ > > > - if (dev_priv->map_mode == vmw_dma_alloc_coherent) > > > + /* No TTM coherent page pool? FIXME: Ask TTM instead! */ > > > + if (!(IS_ENABLED(CONFIG_SWIOTLB) || > > > IS_ENABLED(CONFIG_INTEL_IOMMU)) && > > > + (dev_priv->map_mode == vmw_dma_alloc_coherent)) > > > return -EINVAL; > > > -#endif > > > + > > > > I don't think this edited in change makes any sense. The swiotlb > > vs > > dma-direct versions of dma_alloc_coherent are the same, so this > > check > > seems very obsfucating. > > So this part of code is identical in functionality to the previous > version. It checks whether the TTM module has the coherent page pool > enabled. (an identical test is present in TTM). What we *really* need > to do here instead is to ask TTM whether it has enabled its coherent > page pool instead of trying to mimic TTM's test, and I have a > changeset > under review for that. But as mentioned previously, I don't want to > change the TTM interface outside of a merge window, so we either have > to live with the above for 5.0 or keep the old defines. I'd prefer > the > former so I don't have to respin the patch series once more. > > Thanks, > Thoams > Hi, Christoph, I need to get this merged this week. Could you please ack or ack removing this hunk + updating the following patches for merge errors? If no response, I'll add a Cc: tag on the patch and a #v1 to your s-o- b. Thanks, Thomas
Re: mmotm 2019-02-04-17-47 uploaded (fs/binfmt_elf.c)
Hi Randy, On Mon, 4 Feb 2019 20:26:43 -0800 Randy Dunlap wrote: > > on x86_64 UML: (although should be many places) > > ../fs/binfmt_elf.c: In function ‘write_note_info’: > ../fs/binfmt_elf.c:2122:19: error: ‘tmp’ undeclared (first use in this > function) >for (i = 0; i < tmp->num_notes; i++) This only a problem for !defined(CORE_DUMP_USE_REGSET) architectures, but a problem none the less. -- Cheers, Stephen Rothwell pgpneTRplZ_4a.pgp Description: OpenPGP digital signature
Re: [PATCH v2] tpm/st33zp24: Fix the name collisions in tpm_st33zp24_spi and tpm_i2c_infineon
Hi Jarkko,
I love your patch! Yet something to improve:
[auto build test ERROR on jss-tpmdd/next]
[also build test ERROR on v5.0-rc4 next-20190204]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Jarkko-Sakkinen/tpm-st33zp24-Fix-the-name-collisions-in-tpm_st33zp24_spi-and-tpm_i2c_infineon/20190205-150003
base: git://git.infradead.org/users/jjs/linux-tpmdd next
config: nds32-allyesconfig (attached as .config)
compiler: nds32le-linux-gcc (GCC) 6.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=6.4.0 make.cross ARCH=nds32
All errors (new ones prefixed by >>):
drivers/char/tpm/tpm_i2c_infineon.c: In function 'tpm_tis_i2c_send':
>> drivers/char/tpm/tpm_i2c_infineon.c:531:12: error:
>> 'TPM_I2C_INFINEON_BUFSIZE' undeclared (first use in this function)
if (len > TPM_I2C_INFINEON_BUFSIZE)
^~~~
drivers/char/tpm/tpm_i2c_infineon.c:531:12: note: each undeclared identifier
is reported only once for each function it appears in
vim +/TPM_I2C_INFINEON_BUFSIZE +531 drivers/char/tpm/tpm_i2c_infineon.c
522
523 static int tpm_tis_i2c_send(struct tpm_chip *chip, u8 *buf, size_t len)
524 {
525 int rc, status;
526 ssize_t burstcnt;
527 size_t count = 0;
528 u8 retries = 0;
529 u8 sts = TPM_STS_GO;
530
> 531 if (len > TPM_I2C_INFINEON_BUFSIZE)
532 return -E2BIG;
533
534 if (request_locality(chip, 0) < 0)
535 return -EBUSY;
536
537 status = tpm_tis_i2c_status(chip);
538 if ((status & TPM_STS_COMMAND_READY) == 0) {
539 tpm_tis_i2c_ready(chip);
540 if (wait_for_stat
541 (chip, TPM_STS_COMMAND_READY,
542 chip->timeout_b, ) < 0) {
543 rc = -ETIME;
544 goto out_err;
545 }
546 }
547
548 while (count < len - 1) {
549 burstcnt = get_burstcount(chip);
550
551 /* burstcnt < 0 = TPM is busy */
552 if (burstcnt < 0)
553 return burstcnt;
554
555 if (burstcnt > (len - 1 - count))
556 burstcnt = len - 1 - count;
557
558 rc = iic_tpm_write(TPM_DATA_FIFO(tpm_dev.locality),
559 &(buf[count]), burstcnt);
560 if (rc == 0)
561 count += burstcnt;
562 else if (rc < 0)
563 retries++;
564
565 /* avoid endless loop in case of broken HW */
566 if (retries > MAX_COUNT_LONG) {
567 rc = -EIO;
568 goto out_err;
569 }
570
571 wait_for_stat(chip, TPM_STS_VALID,
572chip->timeout_c, );
573
574 if ((status & TPM_STS_DATA_EXPECT) == 0) {
575 rc = -EIO;
576 goto out_err;
577 }
578 }
579
580 /* write last byte */
581 iic_tpm_write(TPM_DATA_FIFO(tpm_dev.locality), &(buf[count]),
1);
582 wait_for_stat(chip, TPM_STS_VALID, chip->timeout_c, );
583 if ((status & TPM_STS_DATA_EXPECT) != 0) {
584 rc = -EIO;
585 goto out_err;
586 }
587
588 /* go and do it */
589 iic_tpm_write(TPM_STS(tpm_dev.locality), , 1);
590
591 return len;
592 out_err:
593 tpm_tis_i2c_ready(chip);
594 /* The TPM needs some time to clean up here,
595 * so we sleep rather than keeping the bus busy
596 */
597 usleep_range(SLEEP_DURATION_RESET_LOW, SLEEP_DURATION_RESET_HI);
598 release_locality(chip, tpm_dev.locality, 0);
599 return rc;
600 }
601
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v7 03/28] x86/asm/suspend: use SYM_DATA for data
On 04. 02. 19, 21:18, Borislav Petkov wrote: >> --- a/arch/x86/kernel/acpi/wakeup_64.S >> +++ b/arch/x86/kernel/acpi/wakeup_64.S >> @@ -133,4 +133,4 @@ saved_rbx: .quad 0 >> saved_rip: .quad 0 >> saved_rsp: .quad 0 >> >> -ENTRY(saved_magic) .quad 0 >> +SYM_DATA(saved_magic, .quad 0) > > Ok, I like the proper ELF symbol typing with this: NOTYPE goes away. > > 74408: 82021920 0 NOTYPE GLOBAL DEFAULT 11 saved_magic > > -> > > 74366: 820218f0 8 OBJECT GLOBAL DEFAULT 11 saved_magic I also suggest noticing the size 0 -> 8 change ;). thanks, -- js suse labs
[PATCH] kbuild: move archive command to scripts/Makefile.lib
scripts/Makefile.build and arch/s390/boot/Makefile use the same command (thin archiving with symbol table creation). Avoid the code duplication, and move it to scripts/Makefile.lib. Signed-off-by: Masahiro Yamada --- arch/s390/boot/Makefile | 3 --- scripts/Makefile.build | 6 +- scripts/Makefile.lib| 6 ++ 3 files changed, 7 insertions(+), 8 deletions(-) diff --git a/arch/s390/boot/Makefile b/arch/s390/boot/Makefile index 11ca879..c844eaf 100644 --- a/arch/s390/boot/Makefile +++ b/arch/s390/boot/Makefile @@ -57,9 +57,6 @@ $(obj)/section_cmp%: vmlinux $(obj)/compressed/vmlinux FORCE $(obj)/compressed/vmlinux: $(obj)/startup.a FORCE $(Q)$(MAKE) $(build)=$(obj)/compressed $@ -quiet_cmd_ar = AR $@ - cmd_ar = rm -f $@; $(AR) rcsTP$(KBUILD_ARFLAGS) $@ $(real-prereqs) - $(obj)/startup.a: $(OBJECTS) FORCE $(call if_changed,ar) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index f8e2794..99be01c 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -424,13 +424,9 @@ $(modorder-target): $(subdir-ym) FORCE # Rule to compile a set of .o files into one .a file (with symbol table) # ifdef lib-target -quiet_cmd_link_l_target = AR $@ - -# lib target archives do get a symbol table and index -cmd_link_l_target = rm -f $@; $(AR) rcsTP$(KBUILD_ARFLAGS) $@ $(real-prereqs) $(lib-target): $(lib-y) FORCE - $(call if_changed,link_l_target) + $(call if_changed,ar) targets += $(lib-target) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index c0abd9a..8a1f64f 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -233,6 +233,12 @@ $(obj)/%: $(src)/%_shipped quiet_cmd_ld = LD $@ cmd_ld = $(LD) $(ld_flags) $(real-prereqs) -o $@ +# Archive +# --- + +quiet_cmd_ar = AR $@ + cmd_ar = rm -f $@; $(AR) rcsTP$(KBUILD_ARFLAGS) $@ $(real-prereqs) + # Objcopy # --- -- 2.7.4
Re: [PATCH V4 3/9] x86/jump_label: Move checking code away from __jump_label_transform()
On Mon, Feb 04, 2019 at 08:58:56PM +0100, Daniel Bristot de Oliveira wrote:
> Move the check of the current code, before updating an entry, to specialized
> functions. No changes in the method, only code relocation.
>
> Signed-off-by: Daniel Bristot de Oliveira
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Greg Kroah-Hartman
> Cc: Masami Hiramatsu
> Cc: "Steven Rostedt (VMware)"
> Cc: Jiri Kosina
> Cc: Josh Poimboeuf
> Cc: "Peter Zijlstra (Intel)"
> Cc: Chris von Recklinghausen
> Cc: Jason Baron
> Cc: Scott Wood
> Cc: Marcelo Tosatti
> Cc: Clark Williams
> Cc: x...@kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/x86/kernel/jump_label.c | 60 +---
> 1 file changed, 42 insertions(+), 18 deletions(-)
>
> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
> index f99bd26bd3f1..e443c43478eb 100644
> --- a/arch/x86/kernel/jump_label.c
> +++ b/arch/x86/kernel/jump_label.c
> @@ -35,16 +35,53 @@ static void bug_at(unsigned char *ip, int line)
> BUG();
> }
>
> +static inline void __jump_label_trans_check_enable(struct jump_entry *entry,
> +enum jump_label_type type,
> +const unsigned char
> *ideal_nop,
> +int init)
> +{
> + const unsigned char default_nop[] = { STATIC_KEY_INIT_NOP };
> + const void *expect;
> + int line;
> +
> + if (init) {
> + expect = default_nop; line = __LINE__;
> + } else {
> + expect = ideal_nop; line = __LINE__;
> + }
> +
> + if (memcmp((void *)jump_entry_code(entry), expect, JUMP_LABEL_NOP_SIZE))
> + bug_at((void *)jump_entry_code(entry), line);
> +}
> +
> +static inline void __jump_label_trans_check_disable(struct jump_entry *entry,
> + enum jump_label_type type,
> + union jump_code_union *jmp,
> + int init)
> +{
> + const unsigned char default_nop[] = { STATIC_KEY_INIT_NOP };
> + const void *expect;
> + int line;
> +
> + if (init) {
> + expect = default_nop; line = __LINE__;
> + } else {
> + expect = jmp->code; line = __LINE__;
> + }
> +
> + if (memcmp((void *)jump_entry_code(entry), expect, JUMP_LABEL_NOP_SIZE))
> + bug_at((void *)jump_entry_code(entry), line);
> +}
Why the carve out?
The next patch is adding __jump_label_set_jump_code() which calls them
so you could just as well keep the functionality all in that function without
having too many helpers which are called only once...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [Qemu-devel] security implications of caching with virtio pmem (was Re: [PATCH v3 0/5] kvm "virtio pmem" device)
+CC [Dave Chinner], to maintain updated CC list > > This patch series has implementation for "virtio pmem". > > "virtio pmem" is fake persistent memory(nvdimm) in guest > > which allows to bypass the guest page cache. This also > > implements a VIRTIO based asynchronous flush mechanism. > > > At Pankaj's request I looked at information leak implications of virtio > pmem in light of the recent page cache side channels paper > (https://arxiv.org/pdf/1901.01161.pdf) - to see what > kind of side channels it might create if any. TLDR - I think that > depending on the host side implementation there could be some, but this > might be addressable by better documentation in both code and spec. > The fake dax approach backing the guest memory by a host page cache > does seem to have potential issues. > > For clarity: we are talking about leaking information either to a VM, or > within a VM (I did not look into leaks to hypervisor in configurations > such as SEV) through host page cache. > > Leaks into a VM: It seems clear that while pmem allows memory accesses > versus read/write with e.g. a block device, from host page cache point > of view this doesn't matter much: reads populate cache in the same way > as memory faults. Thus ignoring presence of information leaks (which is > an interesting question e.g. in light of recent discard support) pmem > doesn't seem to be any better or worse for leaking information into a > VM. > > Leaks within VM: Right now pmem seems to bypass the guest page cache > completely. Whether pmem memory is then resident in a page cache would > be up to the device/host. Assuming that it is, the "Preventing > Efficient Eviction while Increasing the System Performance" > countermeasure for the page cache side channel attack would appear to > become ineffective with pmem. What is suggested is a per-process > management of the page cache, and host does not have visibility of > processes within a VM. Another possible countermeasure - not discussed > in the paper - could be modify the applications to lock the security > relevant pages in memory. Again this becomes impractical with pmem as > host does not have visibility into that. However note that as long > as the only countermeasure linux uses is "Privileged Access" > (i.e. blocking mincore) nothing can be done as guest page cache > remains as vulnerable as host page cache. > > > Countermeasures: which host-side countermeasures can be designed would > depend on which countermeasures are used guest-side - we would need to > make sure they are not broken by pmem. For "Preventing Efficient > Eviction while Increasing the System Performance" modifying the host > implementation to ensure that pmem device bypasses the host page cache > would seem to address the security problem.Similarly, ensuring that a > real memory device (e.g. DAX, RAM such as hugetlbfs, pmem for nested > virt) is used for pmem would make the memory locking countermeasure > work. Whether with such limitations the device is still useful > performance wise is an open question. These questions probably should > be addressed in the documentation, spec and possible qemu code. > > > > Severity of the security implications: some people argue that the > security implications of the page cache leaks are minor. I do not have > an opinion on this: the severity would seem to depend on the specific > configuration. > > > Other security implications: recent discussion seems to suggest there > are other concerns around e.g. resource management and thus DOS > potential. If that's so, it's a matter for a separate discussion > as I didn't look into that in depth. > > Some or all of the above might be based on a misunderstanding of the > current pmem code, the whitepaper and linux page cache in general. > If so I apologise, do not hesitate to call out any mistakes. > > Thanks! > > -- > MST > >
Re: [RESEND PATCH v2 8/8] Input: sx8654 - convert #defined flags to BIT(x)
On Tue, Jan 29, 2019 at 12:23:01PM +0100, Richard Leitner wrote: > Hi Joe, > > On 29/01/2019 06:40, Joe Perches wrote: > > On Mon, 2019-01-28 at 16:25 -0800, Dmitry Torokhov wrote: > > > On Tue, Dec 18, 2018 at 09:40:02AM +0100, Richard Leitner wrote: > > > > Some of the #defined register values are one-bit flags. Convert them to > > > > use the BIT(x) macro instead of 1 byte hexadecimal values. This improves > > > > readability and clarifies the intent. > > > > > > > > Signed-off-by: Richard Leitner > > > > > > Applied, thank you. > > > > Not so sure this should be applied. > > > > > > diff --git a/drivers/input/touchscreen/sx8654.c > > > > b/drivers/input/touchscreen/sx8654.c > > [] > > > > @@ -46,7 +47,7 @@ > > [] > > > > /* bits for I2C_REG_IRQSRC */ > > > > -#define IRQ_PENTOUCH_TOUCHCONVDONE 0x08 > > > > -#define IRQ_PENRELEASE 0x04 > > > > +#define IRQ_PENTOUCH_TOUCHCONVDONE BIT(7) > > > > +#define IRQ_PENRELEASE BIT(6) > > > > Shouldn't this be BIT(3) and BIT(2) > > or did you mean to change the values too? > > > > If so, this change should be noted in the commit message. > > > > That's true, those values should stay the same. Thanks for the catch! Thanks Joe! > > @Dimitry: Should I send an updated version or do you fix it yourself? > I updated the values and pushed out the new version. Thanks. -- Dmitry
Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
On Mon, Feb 04, 2019 at 04:38:21PM -0500, Michael S. Tsirkin wrote: > It was designed to make, when set, as many guests as we can work > correctly, and it seems to be successful in doing exactly that. > > Unfortunately there could be legacy guests that do work correctly but > become slow. Whether trying to somehow work around that > can paint us into a corner where things again don't > work for some people is a question worth discussing. The other problem is that some qemu machines just throw passthrough devices and virtio devices on the same virtual PCI(e) bus, and have a common IOMMU setup for the whole bus / root port / domain. I think this is completely bogus, but unfortunately it is out in the field. Given that power is one of these examples I suspect that is what Thiago referes to. But in this case the answer can't be that we pile on hack ontop of another, but instead introduce a new qemu machine that separates these clearly, and make that mandatory for the secure guest support.
Re: [PATCH V4 2/9] jump_label: Add the jump_label_can_update_check() helper
> Subject: Re: [PATCH V4 2/9] jump_label: Add the jump_label_can_update_check()
> helper
s/the/a/
On Mon, Feb 04, 2019 at 08:58:55PM +0100, Daniel Bristot de Oliveira wrote:
> Move the check of if a jump_entry is valid to a function.
s/of //
> diff --git a/kernel/jump_label.c b/kernel/jump_label.c
> index 288d630da22d..456c0d7cbb5b 100644
> --- a/kernel/jump_label.c
> +++ b/kernel/jump_label.c
> @@ -374,22 +374,32 @@ static enum jump_label_type jump_label_type(struct
> jump_entry *entry)
> return enabled ^ branch;
> }
>
> +bool jump_label_can_update_check(struct jump_entry *entry, bool init)
static.
Also, "jump_label_can_update" is sufficient for a name AFAICT.
> +{
> + /*
> + * An entry->code of 0 indicates an entry which has been
> + * disabled because it was in an init text area.
> + */
> + if (init || !jump_entry_is_init(entry)) {
> + if (!kernel_text_address(jump_entry_code(entry))) {
> + WARN_ONCE(1, "can't patch jump_label at %pS",
> + (void *)jump_entry_code(entry));
> + return 0;
> + }
> + return 1;
> + }
> + return 0;
Those should be bools which it returns, no?
Also, I'd do the function this way, to make it more readable and not
have three returns back-to-back. :)
/*
* An entry->code of 0 indicates an entry which has been disabled because it
* was in an init text area.
*/
bool jump_label_can_update(struct jump_entry *entry, bool init)
{
if (!init && jump_entry_is_init(entry))
return false;
if (WARN_ON_ONCE(!kernel_text_address(jump_entry_code(entry))),
"can't patch jump_label at %pS", (void
*)jump_entry_code(entry))
return false;
return true;
}
That second check could be even:
if (WARN_ON_ONCE(!kernel_text_address(jump_entry_code(entry))),
"can't patch jump_label at %pS", (void
*)jump_entry_code(entry))
return false;
but that's not more readable than above, I'd say.
> static void __jump_label_update(struct static_key *key,
> struct jump_entry *entry,
> struct jump_entry *stop,
> bool init)
> {
> for_each_label_entry(key, entry, stop) {
> - /*
> - * An entry->code of 0 indicates an entry which has been
> - * disabled because it was in an init text area.
> - */
> - if (init || !jump_entry_is_init(entry)) {
> - if (kernel_text_address(jump_entry_code(entry)))
> - arch_jump_label_transform(entry,
> jump_label_type(entry));
> - else
> - WARN_ONCE(1, "can't patch jump_label at %pS",
> - (void *)jump_entry_code(entry));
> + if (jump_label_can_update_check(entry, init)) {
> + arch_jump_label_transform(entry,
> + jump_label_type(entry));
Yeah, let that one stick out.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [RFC PATCH v5 10/10] watchdog: bd70528: Initial support for ROHM BD70528 watchdog block
On Mon, Feb 04, 2019 at 06:38:43AM -0800, Guenter Roeck wrote:
> On 2/4/19 4:49 AM, Matti Vaittinen wrote:
> > Initial support for watchdog block included in ROHM BD70528
> > power management IC.
> >
> > Configurations for low power states are still to be checked.
> >
> > Signed-off-by: Matti Vaittinen
> > ---
> > drivers/watchdog/Kconfig | 12 +++
> > drivers/watchdog/Makefile | 1 +
> > drivers/watchdog/bd70528_wdt.c | 187
> > +
> > 3 files changed, 200 insertions(+)
> > create mode 100644 drivers/watchdog/bd70528_wdt.c
> >
> > +
> > +struct wdtbd70528 {
> > + struct device *dev;
> > + struct regmap *regmap;
> > + struct mutex *rtc_lock;
> > + struct watchdog_device wdt;
> > +};
> > +
> > +static int bd70528_wdt_set_locked(struct wdtbd70528 *w, int enable)
> > +{
> > + struct bd70528 *bd70528;
> > +
> > + bd70528 = container_of(w->rtc_lock, struct bd70528, rtc_timer_lock);
> > + return bd70528->wdt_set(bd70528, enable, NULL);
> > +}
>
> Please add an empty line here.
Ok.
> > +static int bd70528_wdt_set(struct wdtbd70528 *w, int enable)
> > +{
> > + int ret;
> > +
> > + mutex_lock(w->rtc_lock);
> > + ret = bd70528_wdt_set_locked(w, enable);
> > + mutex_unlock(w->rtc_lock);
> > +
> > + return ret;
> > +}
> > +
> > +static int bd70528_wdt_start(struct watchdog_device *wdt)
> > +{
> > + struct wdtbd70528 *w = watchdog_get_drvdata(wdt);
> > +
> > + dev_dbg(w->dev, "WDT ping...\n");
> > + return bd70528_wdt_set(w, 1);
> > +}
> > +
> > +static int bd70528_wdt_stop(struct watchdog_device *wdt)
> > +{
> > + struct wdtbd70528 *w = watchdog_get_drvdata(wdt);
> > +
> > + dev_dbg(w->dev, "WDT stopping...\n");
> > + return bd70528_wdt_set(w, 0);
> > +}
> > +
> > +static int bd70528_wdt_set_timeout(struct watchdog_device *wdt,
> > + unsigned int timeout)
> > +{
> > + unsigned int hours;
> > + unsigned int minutes;
> > + unsigned int seconds;
> > + int ret;
> > + struct wdtbd70528 *w = watchdog_get_drvdata(wdt);
> > +
> > + seconds = timeout;
> > + hours = timeout / (60 * 60);
> > + /* Maximum timeout is 1h 59m 59s => hours is 1 or 0 */
> > + if (hours)
> > + seconds -= (60 * 60);
> > + minutes = seconds / 60;
> > + seconds = seconds % 60;
> > +
> > + mutex_lock(w->rtc_lock);
> > +
> > + ret = bd70528_wdt_set_locked(w, 0);
> > + if (ret)
> > + goto out_unlock;
> > +
> > + ret = regmap_update_bits(w->regmap, BD70528_REG_WDT_HOUR,
> > +BD70528_MASK_WDT_HOUR, hours);
> > + if (ret) {
> > + dev_err(w->dev, "Failed to set WDT hours\n");
> > + goto out_en_unlock;
> > + }
> > + ret = regmap_update_bits(w->regmap, BD70528_REG_WDT_MINUTE,
> > +BD70528_MASK_WDT_MINUTE, bin2bcd(minutes));
> > + if (ret) {
> > + dev_err(w->dev, "Failed to set WDT minutes\n");
> > + goto out_en_unlock;
> > + }
> > + ret = regmap_update_bits(w->regmap, BD70528_REG_WDT_SEC,
> > +BD70528_MASK_WDT_SEC, bin2bcd(seconds));
> > + if (ret)
> > + dev_err(w->dev, "Failed to set WDT seconds\n");
> > + else
> > + dev_dbg(w->dev, "WDT tmo set to %u\n", timeout);
> > +
> > +out_en_unlock:
> > + ret = bd70528_wdt_set_locked(w, 1);
> > +out_unlock:
> > + mutex_unlock(w->rtc_lock);
> > +
> > + return ret;
> > +}
> > +
> > +static const struct watchdog_info bd70528_wdt_info = {
> > + .identity = "bd70528-wdt",
> > + .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
> > +};
> > +
> > +static const struct watchdog_ops bd70528_wdt_ops = {
> > + .start = bd70528_wdt_start,
> > + .stop = bd70528_wdt_stop,
> > + .set_timeout= bd70528_wdt_set_timeout,
> > +};
> > +
> > +/* Max time we can set is 1 hour, 59 minutes and 59 seconds */
> > +#define WDT_MAX_MS ((2 * 60 * 60 - 1) * 1000)
> > +/* Minimum time is 1 second */
> > +#define WDT_MIN_MS 1000
> > +#define DEFAULT_TIMEOUT 60
> > +
>
> Please move to top, and tab-align the values.
Ok.
> Otherwise I am ok with the patch.
>
> On a side note, isn't it past time to drop the RFC ?
Well, the two main things for me to send this as RFC were the
regmap-irq change (which I had already discussed with Mark, and which is
now applied already - so that's Ok) and splitting the existing
include/linux/mfd/rohm-bd718x7.h header (patches 1 - 3). I hoped to get
commnts from Lee, Stephen and Mark for the idea of header split (this
impacts to already submitted bd718x7 driver and I was unsure if this good
or bad approach) but I haven't heard of Lee or Stephen yet.
Still, I have now received acks for dt-bindings, regulators, gpio and
now also for wdt - and I don't think these are heavily impacted even if
the header split was not Ok - so I guess dropping the RFC makes sense.
Thanks for pointing that out.
I'll send v6 with changes you
Re: mm: race in put_and_wait_on_page_locked()
On Mon, Feb 4, 2019 at 8:43 PM Hugh Dickins wrote: > > Something I shall not be doing, is verifying the correctness of the > low-level get_page_unless_zero() versus page_ref_freeze() protocol > on arm64 and power - nobody has reported on x86, and I do wonder if > there's a barrier missing somewhere, that could manifest in this way - > but I'm unlikely to be the one to find that (and also think that any > weakness there should have shown up long before now). Remind me what the page_ref_freeze() rules even _are_? It's a very special thing, setting the page count down to zero if it matches the "expected" count. Now, if another CPU does a put_page() at that point, that certainly will hit the "oops, we dropped the ref to something that was zero". So the "expected" count had better be only references we have and own 100%, but some of those references aren't really necessarily private to our thread. For example, what happens if (a) one CPU is doing migration_entry_wait() (counting expected page refs etc, before doing page_ref_freeze) (b) another CPU is dirtying a page that was in the swap cache and takes a reference to it, but drops it from the swap cache Note how (b) does not change the refcount on the page at all, because it just moves the ref-count from "swap cache entry" to "I own the page in my page tables". Which means that when (a) does the "count expected count, and match it", it happily matches, and the page_ref_freeze() succeeds and makes the page count be zero. But now (b) has a private reference to that page, and can drop it, so the "freeze" isn't a freeze at all. Ok, so clearly the above cannot happen, and there's something I'm missing with the freezing. I think we hold the page lock while this is going on, which means those two things cannot happen at the same time. But maybe there is something else that does the above kind of "move page ref from one owner to another"? The page_ref_freeze() rules don't seem to be documented anywhere. Linus
Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP
- Original Message -
> On Fri, Nov 30, 2018 at 1:07 PM Jan Stancek wrote:
> >
> > LTP proc01 testcase has been observed to rarely trigger crashes
> > on arm64:
> > page_mapped+0x78/0xb4
> > stable_page_flags+0x27c/0x338
> > kpageflags_read+0xfc/0x164
> > proc_reg_read+0x7c/0xb8
> > __vfs_read+0x58/0x178
> > vfs_read+0x90/0x14c
> > SyS_read+0x60/0xc0
> >
> > Issue is that page_mapped() assumes that if compound page is not
> > huge, then it must be THP. But if this is 'normal' compound page
> > (COMPOUND_PAGE_DTOR), then following loop can keep running
> > (for HPAGE_PMD_NR iterations) until it tries to read from memory
> > that isn't mapped and triggers a panic:
> > for (i = 0; i < hpage_nr_pages(page); i++) {
> > if (atomic_read([i]._mapcount) >= 0)
> > return true;
> > }
> >
> > I could replicate this on x86 (v4.20-rc4-98-g60b548237fed) only
> > with a custom kernel module [1] which:
> > - allocates compound page (PAGEC) of order 1
> > - allocates 2 normal pages (COPY), which are initialized to 0xff
> > (to satisfy _mapcount >= 0)
> > - 2 PAGEC page structs are copied to address of first COPY page
> > - second page of COPY is marked as not present
> > - call to page_mapped(COPY) now triggers fault on access to 2nd
> > COPY page at offset 0x30 (_mapcount)
> >
> > [1]
> > https://github.com/jstancek/reproducers/blob/master/kernel/page_mapped_crash/repro.c
> >
> > Fix the loop to iterate for "1 << compound_order" pages.
> >
> > Debugged-by: Laszlo Ersek
> > Suggested-by: "Kirill A. Shutemov"
> > Signed-off-by: Jan Stancek
> > ---
> > mm/util.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Changes in v2:
> > - change the loop instead so we check also mapcount of subpages
> >
> > diff --git a/mm/util.c b/mm/util.c
> > index 8bf08b5b5760..5c9c7359ee8a 100644
> > --- a/mm/util.c
> > +++ b/mm/util.c
> > @@ -478,7 +478,7 @@ bool page_mapped(struct page *page)
> > return true;
> > if (PageHuge(page))
> > return false;
> > - for (i = 0; i < hpage_nr_pages(page); i++) {
> > + for (i = 0; i < (1 << compound_order(page)); i++) {
> > if (atomic_read([i]._mapcount) >= 0)
> > return true;
> > }
> > --
> > 1.8.3.1
>
> Hi all
>
> This patch landed in the 4.9-stable tree starting from 4.9.151 and it
> broke our MIPS1004kc system with CONFIG_HIGHMEM=y.
Hi,
are you using THP (CONFIG_TRANSPARENT_HUGEPAGE)?
The changed line should affect only THP and normal compound pages,
so a test with THP disabled might be interesting.
>
> The breakage consists of random processes dying with SIGILL or SIGSEGV
> when we stress test the system with high memory pressure and explicit
> memory compaction requested through /proc/sys/vm/compact_memory.
> Reverting this patch fixes the crashes.
>
> We can put some effort on debugging if there are no obvious
> explanations for this. Keep in mind that this is 32-bit system with
> HIGHMEM.
Nothing obvious that I can see. I've been trying to reproduce on
32-bit x86 Fedora with no luck so far.
Regards,
Jan
Re: [PATCH] mtd: spi-nor: cadence-quadspi: write upto 8-bytes data in STIG mode
On 04-Feb-19 7:07 PM, Vignesh R wrote:
Hi,
On 03/02/19 5:50 PM, tudor.amba...@microchip.com wrote:
+ Vignesh
Thanks for looping in.
On 01/28/2019 07:02 AM, Purna Chandra Mandal wrote:
cadence-quadspi controller allows upto eight bytes of data to
be written in software Triggered Instruction generator (STIG) mode
of operation. Lower 4 bytes are written through writedatalower and
upper 4 bytes by writedataupper register.
This patch allows all the 8 bytes to be written.
Code as such looks fine. But, how was this tested? How can I trigger
this new code path with current linux-next? AFAICS, STIG mode write is
used to in nor->write_reg() path, and I dont see any nor->write_reg()
call with >4bytes len.
Currently there is no linux user of write_reg() for write_len > 4byte.
For volatile and non-volatile sector locking [1], we have one out of
tree implementation and that is specific to flash chip "mt25qu02g". In
this implementation we need additional sector address (4 byte) to be
provided for each lock-bit write/erase operation. So total write len in
write_reg() will be 6 bytes (=1 for opcode, 4 for sect addr, 1 for
data). We are finalizing the patch for review.
Since cadence qspi controller do support the 8-byte read/write in STIG
mode, I have tried here to enable that in write_reg(), similar to
read_reg().
[1]
https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_128mb_3v_65nm.pdf
Signed-off-by: Purna Chandra Mandal
Looks good for me:
Reviewed-by: Tudor Ambarus
Vignesh, can we have your R-b or T-b tag?
Cheers,
ta
---
drivers/mtd/spi-nor/cadence-quadspi.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 04cedd3a2bf6..7f78f9409ddd 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -418,9 +418,10 @@ static int cqspi_command_write(struct spi_nor *nor, const
u8 opcode,
void __iomem *reg_base = cqspi->iobase;
unsigned int reg;
unsigned int data;
+ u32 write_len;
int ret;
- if (n_tx > 4 || (n_tx && !txbuf)) {
+ if (n_tx > CQSPI_STIG_DATA_LEN_MAX || (n_tx && !txbuf)) {
dev_err(nor->dev,
"Invalid input argument, cmdlen %d txbuf 0x%p\n",
n_tx, txbuf);
@@ -433,10 +434,18 @@ static int cqspi_command_write(struct spi_nor *nor, const
u8 opcode,
reg |= ((n_tx - 1) & CQSPI_REG_CMDCTRL_WR_BYTES_MASK)
<< CQSPI_REG_CMDCTRL_WR_BYTES_LSB;
data = 0;
- memcpy(, txbuf, n_tx);
+ write_len = (n_tx > 4) ? 4 : n_tx;
+ memcpy(, txbuf, write_len);
+ txbuf += write_len;
writel(data, reg_base + CQSPI_REG_CMDWRITEDATALOWER);
- }
+ if (n_tx > 4) {
+ data = 0;
+ write_len = n_tx - 4;
+ memcpy(, txbuf, write_len);
+ writel(data, reg_base + CQSPI_REG_CMDWRITEDATAUPPER);
+ }
+ }
ret = cqspi_exec_flash_cmd(cqspi, reg);
return ret;
}
Re: [PATCH v4 00/16] block: sed-opal: support shadow MBR done flag and write
On Tue, Feb 05, 2019 at 12:06:54AM +0100, David Kozub wrote: > This will unfortunately trigger some changes (conflict resolving - e.g. if I > move the last two patches in the current series forward, in front of the > patches with new functionality). What is the proper procedure w.r.t. > Reviewed-by tags which were already given? Common sense would make me keep > them for trivial changes and remove them if the patch should be re-reviewed. > Is that correct? I don't think there is a general rule. As long as the change is trivial I keep them personally, otherwise I drop them. E.g. if you just remove a few hunk because of new code that isn't present now I'd keep them, if there are more complex changes to the code flow I would consider dropping them. > FWIW I also hacked together a tool to cover my usecase: > https://gitlab.com/zub2/opalctl > > The selling point is that it can handle passwords the same way that sedutil > (https://github.com/Drive-Trust-Alliance/sedutil) does. That actually is pretty nice, as it allows people to migrate over (not that I've heard of a whole lot of usage of sedutil, but being compatible to some extent is always nice)
[PATCH V3] lightnvm: pblk: prevent stall due to wb threshold
In order to respect mw_cuinits, pblk's write buffer maintains a
backpointer to protect data not yet persisted; when writing to the write
buffer, this backpointer defines a threshold that pblk's rate-limiter
enforces.
On small PU configurations, the following scenarios might take place: (i)
the threshold is larger than the write buffer and (ii) the threshold is
smaller than the write buffer, but larger than the maximun allowed
split bio - 256KB at this moment (Note that writes are not always
split - we only do this when we the size of the buffer is smaller
than the buffer). In both cases, pblk's rate-limiter prevents the I/O to
be written to the buffer, thus stalling.
This patch fixes the original backpointer implementation by considering
the threshold both on buffer creation and on the rate-limiters path,
when bio_split is triggered (case (ii) above).
Fixes: 766c8ceb16fc ("lightnvm: pblk: guarantee that backpointer is respected
on writer stall")
Signed-off-by: Javier González
---
Changes since V1:
- Fix a bad arithmetinc on the rate-limiter max_io calculation (from
Hans)
Changes since V2:
- Address case where mw_cunits = 0 in the new math
drivers/lightnvm/pblk-rb.c | 25 +++--
drivers/lightnvm/pblk-rl.c | 5 ++---
drivers/lightnvm/pblk.h| 2 +-
3 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/drivers/lightnvm/pblk-rb.c b/drivers/lightnvm/pblk-rb.c
index d4ca8c64ee0f..a6133b50ed9c 100644
--- a/drivers/lightnvm/pblk-rb.c
+++ b/drivers/lightnvm/pblk-rb.c
@@ -45,10 +45,23 @@ void pblk_rb_free(struct pblk_rb *rb)
/*
* pblk_rb_calculate_size -- calculate the size of the write buffer
*/
-static unsigned int pblk_rb_calculate_size(unsigned int nr_entries)
+static unsigned int pblk_rb_calculate_size(unsigned int nr_entries,
+ unsigned int threshold)
{
- /* Alloc a write buffer that can at least fit 128 entries */
- return (1 << max(get_count_order(nr_entries), 7));
+ unsigned int thr_sz = 1 << (get_count_order(threshold + NVM_MAX_VLBA));
+ unsigned int max_sz = max(thr_sz, nr_entries);
+ unsigned int max_io;
+
+ /* Alloc a write buffer that can (i) fit at least two split bios
+* (considering max I/O size NVM_MAX_VLBA, and (ii) guarantee that the
+* threshold will be respected
+*/
+ max_io = (1 << max((int)(get_count_order(max_sz)),
+ (int)(get_count_order(NVM_MAX_VLBA << 1;
+ if ((threshold + NVM_MAX_VLBA) >= max_io)
+ max_io <<= 1;
+
+ return max_io;
}
/*
@@ -67,12 +80,12 @@ int pblk_rb_init(struct pblk_rb *rb, unsigned int size,
unsigned int threshold,
unsigned int alloc_order, order, iter;
unsigned int nr_entries;
- nr_entries = pblk_rb_calculate_size(size);
+ nr_entries = pblk_rb_calculate_size(size, threshold);
entries = vzalloc(array_size(nr_entries, sizeof(struct pblk_rb_entry)));
if (!entries)
return -ENOMEM;
- power_size = get_count_order(size);
+ power_size = get_count_order(nr_entries);
power_seg_sz = get_count_order(seg_size);
down_write(_rb_lock);
@@ -149,7 +162,7 @@ int pblk_rb_init(struct pblk_rb *rb, unsigned int size,
unsigned int threshold,
* Initialize rate-limiter, which controls access to the write buffer
* by user and GC I/O
*/
- pblk_rl_init(>rl, rb->nr_entries);
+ pblk_rl_init(>rl, rb->nr_entries, threshold);
return 0;
}
diff --git a/drivers/lightnvm/pblk-rl.c b/drivers/lightnvm/pblk-rl.c
index 76116d5f78e4..b014957dde0b 100644
--- a/drivers/lightnvm/pblk-rl.c
+++ b/drivers/lightnvm/pblk-rl.c
@@ -207,7 +207,7 @@ void pblk_rl_free(struct pblk_rl *rl)
del_timer(>u_timer);
}
-void pblk_rl_init(struct pblk_rl *rl, int budget)
+void pblk_rl_init(struct pblk_rl *rl, int budget, int threshold)
{
struct pblk *pblk = container_of(rl, struct pblk, rl);
struct nvm_tgt_dev *dev = pblk->dev;
@@ -217,7 +217,6 @@ void pblk_rl_init(struct pblk_rl *rl, int budget)
int sec_meta, blk_meta;
unsigned int rb_windows;
-
/* Consider sectors used for metadata */
sec_meta = (lm->smeta_sec + lm->emeta_sec[0]) * l_mg->nr_free_lines;
blk_meta = DIV_ROUND_UP(sec_meta, geo->clba);
@@ -234,7 +233,7 @@ void pblk_rl_init(struct pblk_rl *rl, int budget)
/* To start with, all buffer is available to user I/O writers */
rl->rb_budget = budget;
rl->rb_user_max = budget;
- rl->rb_max_io = budget >> 1;
+ rl->rb_max_io = threshold ? (budget - threshold) : (budget - 1);
rl->rb_gc_max = 0;
rl->rb_state = PBLK_RL_HIGH;
diff --git a/drivers/lightnvm/pblk.h b/drivers/lightnvm/pblk.h
index 72ae8755764e..a6386d5acd73 100644
--- a/drivers/lightnvm/pblk.h
+++ b/drivers/lightnvm/pblk.h
@@ -924,7 +924,7 @@ int pblk_gc_sysfs_force(struct pblk
Re: [PATCH v2] powerpc: drop page_is_ram() and walk_system_ram_range()
Le 04/02/2019 à 11:24, Michael Ellerman a écrit :
Christophe Leroy writes:
Since commit c40dd2f76644 ("powerpc: Add System RAM to /proc/iomem")
it is possible to use the generic walk_system_ram_range() and
the generic page_is_ram().
To enable the use of walk_system_ram_range() by the IBM EHEA
ethernet driver, the generic function has to be exported.
I'm not sure if we have a policy on that, but I suspect we'd rather not
add a new export on all arches unless we need to. Especially seeing as
the only user is the EHEA code which is heavily in maintenance mode.
If you take the exemple of function walk_iomem_res_desc(), that's
similar. It is only used by x86 it seems and exported for nvdimm/e820
driver only.
See commit d76401ade0bb6ab0a7 ("libnvdimm, e820: Register all pmem
resources")
I'll put the export in powerpc code and make sure that builds.
I thought there was a rule that EXPORT_SYMBOL has to immediately follow
the function it exports. At least checkpatch checks for that.
Christophe
As powerpc was the only (last?) user of CONFIG_ARCH_HAS_WALK_MEMORY,
the #ifdef around the generic walk_system_ram_range() has become
useless and can be dropped.
Yes it was the only user:
a99824f327c7 ("[POWERPC] Add arch-specific walk_memory_remove() for 64-bit
powerpc")
I'll update the changelog.
cheers
Fixes: c40dd2f76644 ("powerpc: Add System RAM to /proc/iomem")
Signed-off-by: Christophe Leroy
---
arch/powerpc/Kconfig| 3 ---
arch/powerpc/include/asm/page.h | 1 -
arch/powerpc/mm/mem.c | 33 -
kernel/resource.c | 5 +
4 files changed, 1 insertion(+), 41 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2890d36eb531..f92e6754edf1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -478,9 +478,6 @@ config ARCH_CPU_PROBE_RELEASE
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
-config ARCH_HAS_WALK_MEMORY
- def_bool y
-
config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 5c5ea2413413..aa4497175bd3 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -326,7 +326,6 @@ struct page;
extern void clear_user_page(void *page, unsigned long vaddr, struct page *pg);
extern void copy_user_page(void *to, void *from, unsigned long vaddr,
struct page *p);
-extern int page_is_ram(unsigned long pfn);
extern int devmem_is_allowed(unsigned long pfn);
#ifdef CONFIG_PPC_SMLPAR
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 33cc6f676fa6..fa9916c2c662 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -80,11 +80,6 @@ static inline pte_t *virt_to_kpte(unsigned long vaddr)
#define TOP_ZONE ZONE_NORMAL
#endif
-int page_is_ram(unsigned long pfn)
-{
- return memblock_is_memory(__pfn_to_phys(pfn));
-}
-
pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
unsigned long size, pgprot_t vma_prot)
{
@@ -176,34 +171,6 @@ int __meminit arch_remove_memory(int nid, u64 start, u64
size,
#endif
#endif /* CONFIG_MEMORY_HOTPLUG */
-/*
- * walk_memory_resource() needs to make sure there is no holes in a given
- * memory range. PPC64 does not maintain the memory layout in /proc/iomem.
- * Instead it maintains it in memblock.memory structures. Walk through the
- * memory regions, find holes and callback for contiguous regions.
- */
-int
-walk_system_ram_range(unsigned long start_pfn, unsigned long nr_pages,
- void *arg, int (*func)(unsigned long, unsigned long, void *))
-{
- struct memblock_region *reg;
- unsigned long end_pfn = start_pfn + nr_pages;
- unsigned long tstart, tend;
- int ret = -1;
-
- for_each_memblock(memory, reg) {
- tstart = max(start_pfn, memblock_region_memory_base_pfn(reg));
- tend = min(end_pfn, memblock_region_memory_end_pfn(reg));
- if (tstart >= tend)
- continue;
- ret = (*func)(tstart, tend - tstart, arg);
- if (ret)
- break;
- }
- return ret;
-}
-EXPORT_SYMBOL_GPL(walk_system_ram_range);
-
#ifndef CONFIG_NEED_MULTIPLE_NODES
void __init mem_topology_setup(void)
{
diff --git a/kernel/resource.c b/kernel/resource.c
index 915c02e8e5dd..2e1636041508 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -448,8 +448,6 @@ int walk_mem_res(u64 start, u64 end, void *arg,
arg, func);
}
-#if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
-
/*
* This function calls the @func callback against all memory ranges of type
* System RAM which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY.
@@ -480,8 +478,7 @@ int walk_system_ram_range(unsigned long start_pfn, unsigned
long nr_pages,
}
Re: [PATCH] signal: always allocate siginfo for SI_TKILL
Linus Torvalds writes: > On Tue, Feb 5, 2019 at 2:41 AM Eric W. Biederman > wrote: >> >> I think the simpler change to just do: > > Ack. Changelog and sign-off? Apologies I got distracted by processes ignoring SIGKILL. I will write this up and send it out in the morning. Eric
[PATCH -mm] elf: fixup compilation
Signed-off-by: Alexey Dobriyan
---
fold into elf-use-list_for_each_entry.patch
fs/binfmt_elf.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -2110,8 +2110,8 @@ static int write_note_info(struct elf_note_info *info,
/* write out the thread status notes section */
list_for_each_entry(ets, >thread_list, list) {
- for (i = 0; i < tmp->num_notes; i++)
- if (!writenote(>notes[i], cprm))
+ for (i = 0; i < ets->num_notes; i++)
+ if (!writenote(>notes[i], cprm))
return 0;
}
[PATCH v3 2/2] Bluetooth: hci_ldisc: Add NULL check for tiocmget() and tiocmset() in hci_uart_set_flow_control()
tiocmget() or tiocmset() operations are optional. Just return from
hci_uart_set_flow_control() if tiocmget() or tiocmset() operation is
NULL.
Fixes: 2a973dfada2b ("hci_uart: Add new line discipline enhancements")
Cc: # 4.2
Signed-off-by: Myungho Jung
---
Changes in v2:
- Remove braces in if statment
Changes in v3:
- Split into 2 patches
- Add stable CC and fixes tags
drivers/bluetooth/hci_ldisc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index fbf7b4df23ab..cb31c2d8d826 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -314,6 +314,10 @@ void hci_uart_set_flow_control(struct hci_uart *hu, bool
enable)
return;
}
+ /* tiocmget() and tiocmset() operations are optional */
+ if (!tty->driver->ops->tiocmget || !tty->driver->ops->tiocmset)
+ return;
+
if (enable) {
/* Disable hardware flow control */
ktermios = tty->termios;
--
2.17.1
[PATCH v3 1/2] Bluetooth: hci_ath: Add NULL check for tiocmget() and tiocmset() in ath_setup()
tiocmget() and tiocmset() operations are optional so they are not
guaranteed to be set. Return ENODEV in ath_setup() if tty driver doesn't
support the operations.
Fixes: 4c876c0edbdc ("hci_uart: Add Atheros support for address config")
Cc: # 4.1
Signed-off-by: Myungho Jung
---
Changes in v2:
- Add NULL check and return error in ath_setup() instead of
ath_hci_uart_work()
Changes in v3:
- Fix to return -ENODEV
- Split into 2 patches
- Add stable CC and fixes tags
drivers/bluetooth/hci_ath.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/hci_ath.c b/drivers/bluetooth/hci_ath.c
index d568fbd94d6c..9f1ac1805d23 100644
--- a/drivers/bluetooth/hci_ath.c
+++ b/drivers/bluetooth/hci_ath.c
@@ -185,8 +185,14 @@ static int ath_set_bdaddr(struct hci_dev *hdev, const
bdaddr_t *bdaddr)
static int ath_setup(struct hci_uart *hu)
{
+ struct tty_struct *tty = hu->tty;
+
BT_DBG("hu %p", hu);
+ /* tty driver should support operations to set RTS */
+ if (!tty->driver->ops->tiocmget || !tty->driver->ops->tiocmset)
+ return -ENODEV;
+
hu->hdev->set_bdaddr = ath_set_bdaddr;
return 0;
--
2.17.1
[PATCH v3 0/2] Bluetooth: Add NULL check for tiocmget() and tiocmset()
tiocmget() and tiocmset() operations are optional and some tty drivers like pty miss the operations. Add NULL checks to prevent from dereference. Myungho Jung (2): Bluetooth: hci_ath: Add NULL check for tiocmget() and tiocmset() in ath_setup() Bluetooth: hci_ldisc: Add NULL check for tiocmget() and tiocmset() in hci_uart_set_flow_control() drivers/bluetooth/hci_ath.c | 6 ++ drivers/bluetooth/hci_ldisc.c | 4 2 files changed, 10 insertions(+) -- 2.17.1
Re: [PATCH 4.9 00/30] 4.9.155-stable review
On Mon, 4 Feb 2019 at 16:12, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.9.155 release. > There are 30 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Feb 6 10:35:37 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.155-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.9.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.9.155-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.9.y git commit: 09c6f7d1841f28f385a0082252c5c041dad35ec1 git describe: v4.9.154-31-g09c6f7d1841f Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.154-31-g09c6f7d1841f No regressions (compared to build v4.9.153-46-gac8774c5cafe) No fixes (compared to build v4.9.153-46-gac8774c5cafe) Ran 22030 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
[PATCH v2 2/2] dt-bindings: panel: td028ttec1: add backlight property
This adds an additional backlight property as described
in panel-common.txt
Signed-off-by: Andreas Kemnade
---
Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
index ed34253d9fb1..898e06ecf4ef 100644
--- a/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
+++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
@@ -6,6 +6,7 @@ Required properties:
Optional properties:
- label: a symbolic name for the panel
+- backlight: phandle of the backlight device
Required nodes:
- Video port for DPI input
@@ -21,6 +22,7 @@ lcd-panel: td028ttec1@0 {
spi-cpha;
label = "lcd";
+ backlight = <>;
port {
lcd_in: endpoint {
remote-endpoint = <_out>;
--
2.11.0
compile error at sun6i_video
Hi MultiMedia ML I got below compile error at SH. ... CC drivers/tty/tty_io.o /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c: In function 'sun6i_video_start_streaming': /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c:141:29: error: passing argument 1 of 'media_pipeline_start' from incompatible pointer type [-Werror=incompatible-pointer-types] ret = media_pipeline_start(>vdev.entity, >vdev.pipe); ^~~ In file included from /opt/RB02197/home/morimoto/save/WORK/linux/include/media/media-device.h:26, from /opt/RB02197/home/morimoto/save/WORK/linux/include/media/v4l2-device.h:24, from /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c:10: /opt/RB02197/home/morimoto/save/WORK/linux/include/media/media-entity.h:1030:84: note: expected 'struct media_pad *' but argument is of type 'struct media_entity *' __must_check int media_pipeline_start(struct media_pad *pad, ^ /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c:205:22: error: passing argument 1 of 'media_pipeline_stop' from incompatible pointer type [-Werror=incompatible-pointer-types] media_pipeline_stop(>vdev.entity); ^~~ In file included from /opt/RB02197/home/morimoto/save/WORK/linux/include/media/media-device.h:26, from /opt/RB02197/home/morimoto/save/WORK/linux/include/media/v4l2-device.h:24, from /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c:10: /opt/RB02197/home/morimoto/save/WORK/linux/include/media/media-entity.h:1055:44: note: expected 'struct media_pad *' but argument is of type 'struct media_entity *' void media_pipeline_stop(struct media_pad *pad); ~~^~~ /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c: In function 'sun6i_video_stop_streaming': /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c:229:22: error: passing argument 1 of 'media_pipeline_stop' from incompatible pointer type [-Werror=incompatible-pointer-types] media_pipeline_stop(>vdev.entity); ^~~ In file included from /opt/RB02197/home/morimoto/save/WORK/linux/include/media/media-device.h:26, from /opt/RB02197/home/morimoto/save/WORK/linux/include/media/v4l2-device.h:24, from /opt/RB02197/home/morimoto/save/WORK/linux/drivers/media/platform/sunxi/sun6i-csi/sun6i_video.c:10: /opt/RB02197/home/morimoto/save/WORK/linux/include/media/media-entity.h:1055:44: note: expected 'struct media_pad *' but argument is of type 'struct media_entity *' void media_pipeline_stop(struct media_pad *pad); ~~^~~ Best regards --- Kuninori Morimoto
[PATCH v2 1/2] drm/omap: panel-tpo-td028ttec1: add backlight support
This panel has a backlight, so fetch it from devicetree using the
corresponding property as documented in panel-common.txt. It is
implemented the same way as in panel-dpi.c
This ensures the backlight is also disabled when the display is
turned off like when doing xset dpms force off.
Signed-off-by: Andreas Kemnade
---
Changes in v2:
- do not reorder initialisation
- fix commit message
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index 7ddc8c574a61..1db8740f3c21 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -35,6 +35,8 @@ struct panel_drv_data {
struct videomode vm;
+ struct backlight_device *backlight;
+
struct spi_device *spi_dev;
};
@@ -268,6 +270,8 @@ static int td028ttec1_panel_enable(struct omap_dss_device
*dssdev)
r |= jbt_ret_write_0(ddata, JBT_REG_DISPLAY_ON);
+ backlight_enable(ddata->backlight);
+
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
transfer_err:
@@ -283,6 +287,8 @@ static void td028ttec1_panel_disable(struct omap_dss_device
*dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
+ backlight_disable(ddata->backlight);
+
dev_dbg(dssdev->dev, "td028ttec1_panel_disable()\n");
jbt_ret_write_0(ddata, JBT_REG_DISPLAY_OFF);
@@ -334,6 +340,10 @@ static int td028ttec1_panel_probe(struct spi_device *spi)
if (ddata == NULL)
return -ENOMEM;
+ ddata->backlight = devm_of_find_backlight(>dev);
+ if (IS_ERR(ddata->backlight))
+ return PTR_ERR(ddata->backlight);
+
dev_set_drvdata(>dev, ddata);
ddata->spi_dev = spi;
--
2.11.0
Re: [PATCH 4.14 00/46] 4.14.98-stable review
On Mon, 4 Feb 2019 at 16:15, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.98 release. > There are 46 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Feb 6 10:35:31 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.98-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. NOTE: LTP syscalls fanotify09 test case PASS now. The fanotify fix back ported to 4.14 Summary kernel: 4.14.98-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 0576694f34d99f183fb11743e8ef11e39e0349bf git describe: v4.14.97-47-g0576694f34d9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.97-47-g0576694f34d9 No regressions (compared to build v4.14.96-71-g9dc1bec76994) Fixes (compared to build v4.14.96-71-g9dc1bec76994) LTP syscalls fanotify09 test case PASS now. The fanotify fix back ported to 4.14 Ran 22303 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
[PATCH v2 0/2] drm/omap: panel-tpo-td028ttec1: add backlight support
This panel has a backlight, so add a property describing that and add the code to use that. This makes things like xset dpms force off also turn off the backlight, so we do not need to rely on additional userspace programs to do that. Andreas Kemnade (2): drm/omap: panel-tpo-td028ttec1: add backlight support dt-bindings: panel: td028ttec1: add backlight property .../devicetree/bindings/display/panel/tpo,td028ttec1.txt | 2 ++ drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c| 10 ++ 2 files changed, 12 insertions(+) -- 2.11.0
Re: [PATCH] signal: always allocate siginfo for SI_TKILL
On Tue, Feb 5, 2019 at 2:41 AM Eric W. Biederman wrote: > > I think the simpler change to just do: Ack. Changelog and sign-off? Linus
Re: [PATCH v5 00/13] x86: Enable FSGSBASE instructions
On February 1, 2019 6:43:25 PM PST, Andy Lutomirski wrote: >Hi hpa- > >A while back, you were working on some patches to make modify_ldt() >play better with this series. What happened to them? > >--Andy Looks like I need to dig them out... -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[tip:x86/cleanups] x86/resctrl: Remove duplicate MSR_MISC_FEATURE_CONTROL definition
Commit-ID: 8ad382dd11ebed9f87edfeda6e738c472a911203
Gitweb: https://git.kernel.org/tip/8ad382dd11ebed9f87edfeda6e738c472a911203
Author: Reinette Chatre
AuthorDate: Mon, 4 Feb 2019 12:41:36 -0800
Committer: Borislav Petkov
CommitDate: Tue, 5 Feb 2019 07:21:56 +0100
x86/resctrl: Remove duplicate MSR_MISC_FEATURE_CONTROL definition
The definition of MSR_MISC_FEATURE_CONTROL was first introduced in
98af74599ea0 ("x86 msr_index.h: Define MSR_MISC_FEATURE_CONTROL")
and present in Linux since v4.11.
The Cache Pseudo-Locking code added this duplicate definition in more
recent
f2a177292bd0 ("x86/intel_rdt: Discover supported platforms via prefetch
disable bits"),
available since v4.19.
Remove the duplicate definition from the resctrl subsystem and let that
code obtain the needed definition from the core architecture msr-index.h
instead.
Fixes: f2a177292bd0 ("x86/intel_rdt: Discover supported platforms via prefetch
disable bits")
Signed-off-by: Reinette Chatre
Signed-off-by: Borislav Petkov
Cc: Fenghua Yu
Cc: gavin.hind...@intel.com
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: jithu.jos...@intel.com
Cc: Thomas Gleixner
Cc: Tony Luck
Cc: x86-ml
Link:
https://lkml.kernel.org/r/ff6b95d9b6ef6f4ac96267f130719ba1af09614b.1549312475.git.reinette.cha...@intel.com
---
arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
index 14bed6af8377..604c0e3bcc83 100644
--- a/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
+++ b/arch/x86/kernel/cpu/resctrl/pseudo_lock.c
@@ -33,13 +33,6 @@
#define CREATE_TRACE_POINTS
#include "pseudo_lock_event.h"
-/*
- * MSR_MISC_FEATURE_CONTROL register enables the modification of hardware
- * prefetcher state. Details about this register can be found in the MSR
- * tables for specific platforms found in Intel's SDM.
- */
-#define MSR_MISC_FEATURE_CONTROL 0x01a4
-
/*
* The bits needed to disable hardware prefetching varies based on the
* platform. During initialization we will discover which bits to use.
Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"
On Mon 04 Feb 20:58 PST 2019, Alim Akhtar wrote:
> Hi Marc,
>
> On 04/02/19 11:12 PM, Marc Gonzalez wrote:
> > This reverts commit 60f0187031c05e04cbadffb62f557d0ff3564490.
> >
> > Calling ufshcd_set_vccq_rail_unused hangs my system.
> > It seems vccq is not *not* needed.
> >
> > Signed-off-by: Marc Gonzalez
> > ---
>
> AFAIK Samsung and Toshiba UFS devices does not use VCCQ (this pin is
> either floating or connected to Ground, at least on the devices that I
> have worked on).
But why does such system define a vccq-supply? If the system doesn't
have a regulator connected to VCCQ, then the UFS driver shouldn't be
told that there is one. And if VCCQ is optional the UFS driver should
support the fact that this regulator might not be supplied (i.e. call
regulator_get_optional() and handle the error indicating that the supply
isn't specified).
Regards,
Bjorn
> You said your system hanged, I believe you have set UFS_DEVICE_NO_VCCQ
> quirks, in that case VCCQ regulator should having been disabled.
> So you mean your system hanged because vccq regulator got disabled?
>
> > drivers/scsi/ufs/ufs.h| 1 -
> > drivers/scsi/ufs/ufshcd.c | 59 +++
> > 2 files changed, 4 insertions(+), 56 deletions(-)
> >
> > diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> > index dd65fea07687..7da7318eb6a6 100644
> > --- a/drivers/scsi/ufs/ufs.h
> > +++ b/drivers/scsi/ufs/ufs.h
> > @@ -514,7 +514,6 @@ struct ufs_vreg {
> > struct regulator *reg;
> > const char *name;
> > bool enabled;
> > - bool unused;
> > int min_uV;
> > int max_uV;
> > int min_uA;
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index 9ba7671b84f8..8b9a01073d62 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -245,7 +245,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
> > static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
> > bool skip_ref_clk);
> > static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
> > -static int ufshcd_set_vccq_rail_unused(struct ufs_hba *hba, bool unused);
> > static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
> > static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
> > static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
> > @@ -6819,11 +6818,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba)
> > ufs_fixup_device_setup(hba, );
> > ufshcd_tune_unipro_params(hba);
> >
> > - ret = ufshcd_set_vccq_rail_unused(hba,
> > - (hba->dev_quirks & UFS_DEVICE_NO_VCCQ) ? true : false);
> > - if (ret)
> > - goto out;
> > -
> > /* UFS device is also active now */
> > ufshcd_set_ufs_dev_active(hba);
> > ufshcd_force_reset_auto_bkops(hba);
> > @@ -7007,24 +7001,13 @@ static int ufshcd_config_vreg_load(struct device
> > *dev, struct ufs_vreg *vreg,
> > static inline int ufshcd_config_vreg_lpm(struct ufs_hba *hba,
> > struct ufs_vreg *vreg)
> > {
> > - if (!vreg)
> > - return 0;
> > - else if (vreg->unused)
> > - return 0;
> > - else
> > - return ufshcd_config_vreg_load(hba->dev, vreg,
> > - UFS_VREG_LPM_LOAD_UA);
> > + return ufshcd_config_vreg_load(hba->dev, vreg, UFS_VREG_LPM_LOAD_UA);
> > }
> >
> > static inline int ufshcd_config_vreg_hpm(struct ufs_hba *hba,
> > struct ufs_vreg *vreg)
> > {
> > - if (!vreg)
> > - return 0;
> > - else if (vreg->unused)
> > - return 0;
> > - else
> > - return ufshcd_config_vreg_load(hba->dev, vreg, vreg->max_uA);
> > + return ufshcd_config_vreg_load(hba->dev, vreg, vreg->max_uA);
> > }
> >
> > static int ufshcd_config_vreg(struct device *dev,
> > @@ -7062,9 +7045,7 @@ static int ufshcd_enable_vreg(struct device *dev,
> > struct ufs_vreg *vreg)
> > {
> > int ret = 0;
> >
> > - if (!vreg)
> > - goto out;
> > - else if (vreg->enabled || vreg->unused)
> > + if (!vreg || vreg->enabled)
> > goto out;
> >
> > ret = ufshcd_config_vreg(dev, vreg, true);
> > @@ -7084,9 +7065,7 @@ static int ufshcd_disable_vreg(struct device *dev,
> > struct ufs_vreg *vreg)
> > {
> > int ret = 0;
> >
> > - if (!vreg)
> > - goto out;
> > - else if (!vreg->enabled || vreg->unused)
> > + if (!vreg || !vreg->enabled)
> > goto out;
> >
> > ret = regulator_disable(vreg->reg);
> > @@ -7192,36 +7171,6 @@ static int ufshcd_init_hba_vreg(struct ufs_hba *hba)
> > return 0;
> > }
> >
> > -static int ufshcd_set_vccq_rail_unused(struct ufs_hba *hba, bool unused)
> > -{
> > - int ret = 0;
> > - struct ufs_vreg_info *info = >vreg_info;
> > -
> > - if (!info)
> > - goto out;
> > - else if (!info->vccq)
> > - goto out;
> > -
> > -
Re: [PATCH 10/10] venus: dec: make decoder compliant with stateful codec API
On Fri, Feb 1, 2019 at 12:18 AM Nicolas Dufresne wrote: > > Le jeudi 31 janvier 2019 à 22:34 +0900, Tomasz Figa a écrit : > > On Thu, Jan 31, 2019 at 9:42 PM Philipp Zabel > > wrote: > > > Hi Nicolas, > > > > > > On Wed, 2019-01-30 at 10:32 -0500, Nicolas Dufresne wrote: > > > > Le mercredi 30 janvier 2019 à 15:17 +0900, Tomasz Figa a écrit : > > > > > > I don't remember saying that, maybe I meant to say there might be a > > > > > > workaround ? > > > > > > > > > > > > For the fact, here we queue the headers (or first frame): > > > > > > > > > > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L624 > > > > > > > > > > > > Then few line below this helper does G_FMT internally: > > > > > > > > > > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L634 > > > > > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2object.c#L3907 > > > > > > > > > > > > And just plainly fails if G_FMT returns an error of any type. This > > > > > > was > > > > > > how Kamil designed it initially for MFC driver. There was no other > > > > > > alternative back then (no EAGAIN yet either). > > > > > > > > > > Hmm, was that ffmpeg then? > > > > > > > > > > So would it just set the OUTPUT width and height to 0? Does it mean > > > > > that gstreamer doesn't work with coda and mtk-vcodec, which don't have > > > > > such wait in their g_fmt implementations? > > > > > > > > I don't know for MTK, I don't have the hardware and didn't integrate > > > > their vendor pixel format. For the CODA, I know it works, if there is > > > > no wait in the G_FMT, then I suppose we are being really lucky with the > > > > timing (it would be that the drivers process the SPS/PPS synchronously, > > > > and a simple lock in the G_FMT call is enough to wait). Adding Philipp > > > > in CC, he could explain how this works, I know they use GStreamer in > > > > production, and he would have fixed GStreamer already if that was > > > > causing important issue. > > > > > > CODA predates the width/height=0 rule on the coded/OUTPUT queue. > > > It currently behaves more like a traditional mem2mem device. > > > > The rule in the latest spec is that if width/height is 0 then CAPTURE > > format is determined only after the stream is parsed. Otherwise it's > > instantly deduced from the OUTPUT resolution. > > > > > When width/height is set via S_FMT(OUT) or output crop selection, the > > > driver will believe it and set the same (rounded up to macroblock > > > alignment) on the capture queue without ever having seen the SPS. > > > > That's why I asked whether gstreamer sets width and height of OUTPUT > > to non-zero values. If so, there is no regression, as the specs mimic > > the coda behavior. > > I see, with Philipp's answer it explains why it works. Note that > GStreamer sets the display size on the OUTPUT format (in fact we pass > as much information as we have, because a) it's generic code and b) it > will be needed someday when we enable pre-allocation (REQBUFS before > SPS/PPS is passed, to avoid the setup delay introduce by allocation, > mostly seen with CMA base decoder). In any case, the driver reported > display size should always be ignored in GStreamer, the only > information we look at is the G_SELECTION for the case the x/y or the > cropping rectangle is non-zero. > > Note this can only work if the capture queue is not affected by the > coded size, or if the round-up made by the driver is bigger or equal to > that coded size. I believe CODA falls into the first category, since > the decoding happens in a separate set of buffers and are then de-tiled > into the capture buffers (if understood correctly). Sounds like it would work only if coded size is equal to the visible size (that GStreamer sets) rounded up to full macroblocks. Non-zero x or y in the crop could be problematic too. Hans, what's your view on this? Should we require G_FMT(CAPTURE) to wait until a format becomes available or the OUTPUT queue runs out of buffers? > > I would say, best is just to test the updated Venus driver, which is in > my queue. The updated Venus driver doesn't implement the behavior I referred to, but rather the legacy wait in G_FMT(CAPTURE) as in s5p-mfc.
Re: [PATCH 4.4 00/65] 4.4.173-stable review
On Mon, 4 Feb 2019 at 16:10, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.4.173 release. > There are 65 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Feb 6 10:35:30 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.173-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.4.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.4.173-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.4.y git commit: 256c5e4d5358cf3c649b53a0c8bef02f499e357c git describe: v4.4.172-66-g256c5e4d5358 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.172-66-g256c5e4d5358 No regressions (compared to build v4.4.172) No fixes (compared to build v4.4.172) Ran 17275 total tests in the following environments and test suites. Environments -- - i386 - juno-r2 - arm64 - qemu_arm - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * install-android-platform-tools-r2600 * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none Summary kernel: 4.4.173-rc2 git repo: https://git.linaro.org/lkft/arm64-stable-rc.git git branch: 4.4.173-rc2-hikey-20190204-367 git commit: e7819526baa5163360b89a0c45d2e09992772ff6 git describe: 4.4.173-rc2-hikey-20190204-367 Test details: https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.173-rc2-hikey-20190204-367 No regressions (compared to build 4.4.173-rc1-hikey-20190204-366) No fixes (compared to build 4.4.173-rc1-hikey-20190204-366) Ran 2826 total tests in the following environments and test suites. Environments -- - hi6220-hikey - arm64 - qemu_arm64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-fs-tests -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH V9 3/5] i2c: tegra: Add DMA support
05.02.2019 4:37, Sowjanya Komatineni пишет: >> I know that APB DMA driver enables flow control based on the channels spec, >> but still won't hurt to explicitly show that channels are flow-controlled. >> Ideally APB DMA driver should respect the device_fc field. >> >> dma_sconfig.device_fc = true; > > > Dmitry, > Thanks for all feedback. Sent updated patch V10 which has all below V9 > feedback changes. > > - Added explicit flow control settings to dma slave config and error check so > need to move releasing of dma resources to separate function as I am using it > multiple places (when dma slave config failed, on tegra drive remove, > tegra_i2c_init_dma). > As a part of this, moved error handling also inside init_dma as you suggested > in earlier feedback. > - Added apbdma hw support flag to now allow Tegra186 and later use APBDMA > driver. > - Updated to register tegra_i2c_driver from module level rather than subsys > level. > - Fixed timeout for bus clear to 50ms (10ms is enough but considering slaves > responding slow). Also added adapter timeout to 6s considering worst case > transfer rate. > - other minor fixes. > > Please review. > - Sowjanya > Thank you very much for keeping up with the new versions! The v10 is reviewed now. It is very close to final, but there is one new fatal bug there that leaves FIFO control register unconfigured in a case of error. I also pointed at some other minor cases that could be improved, please see my replies.
Re: [PATCH 4.20 00/80] 4.20.7-stable review
On Mon, 4 Feb 2019 at 16:20, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.20.7 release. > There are 80 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Feb 6 10:35:33 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.20.7-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.20.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.20.7-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.20.y git commit: cc6e62e7b38a4a9309c07e6e5d45d8e619570823 git describe: v4.20.6-81-gcc6e62e7b38a Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.20-oe/build/v4.20.6-81-gcc6e62e7b38a No regressions (compared to build v4.20.5-121-gb3b8ce0697df) No fixes (compared to build v4.20.5-121-gb3b8ce0697df) Ran 21126 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-fs-tests * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
[PATCH 2/2] drivers: xhci: Add quirk to reset xHCI port PHY
Add a quirk to reset xHCI port PHY on port disconnect event.
Stingray USB HS PHY has an issue, that USB High Speed device detected
at Full Speed after the same port has connected to Full speed device.
This problem can be resolved with that port PHY reset on disconnect.
Signed-off-by: Srinath Mannam
Reviewed-by: Ray Jui
---
drivers/usb/core/hcd.c | 6 ++
drivers/usb/core/phy.c | 21 +
drivers/usb/core/phy.h | 1 +
drivers/usb/host/xhci-plat.c | 3 +++
drivers/usb/host/xhci-ring.c | 9 ++---
drivers/usb/host/xhci.h | 1 +
include/linux/usb/hcd.h | 1 +
7 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 015b126..e2b87a6 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2663,6 +2663,12 @@ int usb_hcd_find_raw_port_number(struct usb_hcd *hcd,
int port1)
return hcd->driver->find_raw_port_number(hcd, port1);
}
+int usb_hcd_phy_port_reset(struct usb_hcd *hcd, int port)
+{
+ return usb_phy_roothub_port_reset(hcd->phy_roothub, port);
+}
+EXPORT_SYMBOL_GPL(usb_hcd_phy_port_reset);
+
static int usb_hcd_request_irqs(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags)
{
diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
index 38b2c77..c64767d 100644
--- a/drivers/usb/core/phy.c
+++ b/drivers/usb/core/phy.c
@@ -162,6 +162,27 @@ void usb_phy_roothub_power_off(struct usb_phy_roothub
*phy_roothub)
}
EXPORT_SYMBOL_GPL(usb_phy_roothub_power_off);
+int usb_phy_roothub_port_reset(struct usb_phy_roothub *phy_roothub, int port)
+{
+ struct usb_phy_roothub *roothub_entry;
+ struct list_head *head;
+ int i = 0;
+
+ if (!phy_roothub)
+ return -EINVAL;
+
+ head = _roothub->list;
+
+ list_for_each_entry(roothub_entry, head, list) {
+ if (i == port)
+ return phy_reset(roothub_entry->phy);
+ i++;
+ }
+
+ return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_port_reset);
+
int usb_phy_roothub_suspend(struct device *controller_dev,
struct usb_phy_roothub *phy_roothub)
{
diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
index 88a3c03..e8be444 100644
--- a/drivers/usb/core/phy.h
+++ b/drivers/usb/core/phy.h
@@ -18,6 +18,7 @@ int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);
void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub);
+int usb_phy_roothub_port_reset(struct usb_phy_roothub *phy_roothub, int port);
int usb_phy_roothub_suspend(struct device *controller_dev,
struct usb_phy_roothub *phy_roothub);
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ef09cb0..5a3b486 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -289,6 +289,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (device_property_read_bool(tmpdev, "quirk-broken-port-ped"))
xhci->quirks |= XHCI_BROKEN_PORT_PED;
+ if (device_property_read_bool(tmpdev, "usb-phy-port-reset"))
+ xhci->quirks |= XHCI_RESET_PHY_ON_DISCONNECT;
+
device_property_read_u32(tmpdev, "imod-interval-ns",
>imod_interval);
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 40fa25c..2dc3116 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1685,9 +1685,12 @@ static void handle_port_status(struct xhci_hcd *xhci,
if (hcd->speed < HCD_USB3) {
xhci_test_and_clear_bit(xhci, port, PORT_PLC);
- if ((xhci->quirks & XHCI_RESET_PLL_ON_DISCONNECT) &&
- (portsc & PORT_CSC) && !(portsc & PORT_CONNECT))
- xhci_cavium_reset_phy_quirk(xhci);
+ if ((portsc & PORT_CSC) && !(portsc & PORT_CONNECT)) {
+ if (xhci->quirks & XHCI_RESET_PLL_ON_DISCONNECT)
+ xhci_cavium_reset_phy_quirk(xhci);
+ else if (xhci->quirks & XHCI_RESET_PHY_ON_DISCONNECT)
+ usb_hcd_phy_port_reset(hcd, port_id - 1);
+ }
}
cleanup:
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 652dc36..530c5ff 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1846,6 +1846,7 @@ struct xhci_hcd {
#define XHCI_DEFAULT_PM_RUNTIME_ALLOW BIT_ULL(33)
#define XHCI_RESET_PLL_ON_DISCONNECT BIT_ULL(34)
#define XHCI_SNPS_BROKEN_SUSPENDBIT_ULL(35)
+#define XHCI_RESET_PHY_ON_DISCONNECT BIT_ULL(36)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
diff --git a/include/linux/usb/hcd.h
[PATCH 1/2] dt-bindings: usb-xhci: Add usb-phy-port-reset property
Add usb-phy-port-reset optional property to set quirk in xhci platform driver which forces USB port PHY reset on port disconnect event. Signed-off-by: Srinath Mannam Reviewed-by: Ray Jui --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index fea8b15..ecbdb15 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -40,6 +40,7 @@ Optional properties: - usb3-lpm-capable: determines if platform is USB3 LPM capable - quirk-broken-port-ped: set if the controller has broken port disable mechanism - imod-interval-ns: default interrupt moderation interval is 5000ns + - usb-phy-port-reset: set this to do USB PORT PHY reset while disconnect - phys : see usb-hcd.txt in the current directory additionally the properties from usb-hcd.txt (in the current directory) are -- 2.7.4
[PATCH 0/2] Reset xHCI port PHY on disconnect
This patch set adds a quirk in xHCI driver to reset PHY of xHCI port on its disconnect event. This patch set is based on Linux-5.0-rc2. Srinath Mannam (2): dt-bindings: usb-xhci: Add usb-phy-port-reset property drivers: xhci: Add quirk to reset xHCI port PHY Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + drivers/usb/core/hcd.c | 6 ++ drivers/usb/core/phy.c | 21 + drivers/usb/core/phy.h | 1 + drivers/usb/host/xhci-plat.c | 3 +++ drivers/usb/host/xhci-ring.c | 9 ++--- drivers/usb/host/xhci.h| 1 + include/linux/usb/hcd.h| 1 + 8 files changed, 40 insertions(+), 3 deletions(-) -- 2.7.4
Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid
On Mon, Feb 04, 2019 at 03:24:23PM -0800, Dave Hansen wrote: > Actually, there's one part of all this that I forgot. Will split lock > detection be enumerated _widely_? You never know what users will do. The moment it gets out, it better be designed properly, along with the chicken bits. > IOW, will my laptop in 5 years enumerate support for it? Don't tell me this is going to be another MPX fiasco :-\ Or is this something along the lines of "let's see whether it takes off and if yes, we'll commit to it or otherwise remove it and not even waste a CPUID leaf"? > If so, we surely don't want to enable this everyhwhere: it will break > old apps. Doesn't that mean that we need both feature detection and > another separate bit for folks to opt-in? Well, if it breaks old apps, it probably needs to be opt-in anyway. And for that you don't need setcpuid either - you simply boot with "split_lock_ac" or whatever and the kernel pokes that MSR_TEST_CTL or whatever else it needs to detect in hw for split lock and sets the X86_FEATURE bits if detection is successful. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCH 4.19 00/74] 4.19.20-stable review
On Mon, 4 Feb 2019 at 16:17, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.20 release. > There are 74 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed Feb 6 10:35:34 UTC 2019. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.20-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Summary kernel: 4.19.20-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 690bd91d787289dc15b2f79fe32d1006c974cc92 git describe: v4.19.19-75-g690bd91d7872 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.19-75-g690bd91d7872 No regressions (compared to build v4.19.18-107-g0cbcaa92df11) No fixes (compared to build v4.19.18-107-g0cbcaa92df11) Ran 21250 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * boot * install-android-platform-tools-r2600 * kselftest * libhugetlbfs * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-timers-tests * spectre-meltdown-checker-test * ltp-open-posix-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
linux-next: Tree for Feb 5
Hi all, Changes since 20190204: The vfs tree lost its build failure. The net-next tree lost its build failure. The drm-tegra tree lost its build failure. The akpm-current tree gained a conflict against the net tree. Non-merge commits (relative to Linus' tree): 5606 6290 files changed, 231350 insertions(+), 149552 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 296 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (8834f5600cf3 Linux 5.0-rc5) Merging fixes/master (d8d0c3a7f601 x86/syscalls: Mark expected switch fall-throughs) Merging kbuild-current/fixes (6db2983cd806 kallsyms: Handle too long symbols in kallsyms.c) Merging arc-current/for-curr (c4a8fb41246c ARCv2: lib: memcpy: fix doing prefetchw outside of buffer) Merging arm-current/fixes (1b5ba3507842 ARM: 8824/1: fix a migrating irq bug when hotplug cpu) Merging arm64-fixes/for-next/fixes (f7daa9c8fd19 arm64: hibernate: Clean the __hyp_text to PoC after resume) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (7bea7ac0ca01 powerpc/syscalls: Fix syscall tracing) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (0429f237ce08 Merge branch 's390-qeth-fixes') Merging bpf/master (0429f237ce08 Merge branch 's390-qeth-fixes') Merging ipsec/master (09db51241118 esp: Skip TX bytes accounting when sending from a request socket) Merging netfilter/master (f6ac85858976 netfilter: nf_tables: unbind set in rule from commit path) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (8c22d81d5535 MAINTAINERS: add entry for redpine wireless driver) Merging mac80211/master (e005bd7ddea0 cfg80211: call disconnect_wk when AP stops) Merging rdma-fixes/for-rc (7b21b69ab203 IB/uverbs: Fix OOPs in uverbs_user_mmap_disassociate) Merging sound-current/for-linus (305a0ade1809 ALSA: hda - Serialize codec registrations) Merging sound-asoc-fixes/for-linus (72a52a2e9596 Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (3a3a75eaefb1 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (2186097e00f9 Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f14bcc0add3a Revert "PCI: armada8k: Add support for gpio controlled reset signal") Merging driver-core.current/driver-core-linus (36991ca68db9 blk-mq: protect debugfs_create_files() from failures) Merging tty.current/tty-linus (fedb5760648a serial: fix race between flush_to_ldisc and tty_open) Merging usb.current/usb-linus (a07ddce4df80 usb: typec: tcpm: Correct the PPS out_volt calculation) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x: fix race condition in _probe) Merging usb-serial-fixes/usb-linus (f17b5f06cb92 Linux 5.0-rc4) Merging usb-chipidea-fixes/ci-for-usb-stable (d6d768a0ec3c usb: chipidea: fix static checker warning for NULL pointer) Merging phy/fixes (827cb0323928 phy: ath79-usb: Fix the main reset
Re: [PATCH v5 2/2] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller
Hi,
On 29/01/19 9:02 PM, tudor.amba...@microchip.com wrote:
>
>
> On 01/28/2019 07:49 AM, Vignesh R wrote:
>> Cadence OSPI controller IP supports Octal IO (x8 IO lines),
>> It also has an integrated PHY. IP register layout is very
>> similar to existing QSPI IP except for additional bits to support Octal
>> and Octal DDR mode. Therefore, extend current driver to support Octal
>> mode. Only Octal SDR read (1-1-8)mode is supported for now.
>>
>> Tested with mt35xu512aba Octal flash on TI's AM654 EVM.
>>
>> Signed-off-by: Vignesh R
>> Reviewed-by: Tudor Ambarus
>> ---
>>
>> v5:
>> s/cqsi_base_hwcaps_mask/CQSPI_BASE_HWCAPS_MASK/g
>> Add back cqspi_driver_platdata definition for base compatible.
>>
>> v4: Fix comments by Tudor on v3
>> v3: No changes
>> v2: Declare Octal mode capability based on compatible.
>>
>> drivers/mtd/spi-nor/cadence-quadspi.c | 58 +--
>> 1 file changed, 46 insertions(+), 12 deletions(-)
[...]
>>
>> static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np)
>> {
>> -const struct spi_nor_hwcaps hwcaps = {
>> -.mask = SNOR_HWCAPS_READ |
>> -SNOR_HWCAPS_READ_FAST |
>> -SNOR_HWCAPS_READ_1_1_2 |
>> -SNOR_HWCAPS_READ_1_1_4 |
>> -SNOR_HWCAPS_PP,
>> -};
>> struct platform_device *pdev = cqspi->pdev;
>> struct device *dev = >dev;
>> +const struct cqspi_driver_platdata *ddata;
>> +struct spi_nor_hwcaps hwcaps;
>> struct cqspi_flash_pdata *f_pdata;
>> struct spi_nor *nor;
>> struct mtd_info *mtd;
>> unsigned int cs;
>> int i, ret;
>>
>> +ddata = of_device_get_match_data(dev);
>> +if (!ddata)
>> +hwcaps.mask = CQSPI_BASE_HWCAPS_MASK;
>
> Now that .data is set in all cqspi_dt_ids[], maybe it's better to print a
> message and return an error here. But I guess it's a matter of taste, so not a
> show stopper.
Since, driver data is kernel internal field, I guess there is little
help in printing out the error to the user when its missing. I prefer to
keep this as is, as basic Quad mode is supported by all versions of the IP.
Regards
Vignesh
>
>> +else
>> +hwcaps.mask = ddata->hwcaps_mask;
>> +
>> /* Get flash device data */
>> for_each_available_child_of_node(dev->of_node, np) {
>> ret = of_property_read_u32(np, "reg", );
>> @@ -1310,7 +1326,7 @@ static int cqspi_probe(struct platform_device *pdev)
>> struct cqspi_st *cqspi;
>> struct resource *res;
>> struct resource *res_ahb;
>> -unsigned long data;
>> +const struct cqspi_driver_platdata *ddata;
>> int ret;
>> int irq;
>>
>> @@ -1377,8 +1393,8 @@ static int cqspi_probe(struct platform_device *pdev)
>> }
>>
>> cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
>> -data = (unsigned long)of_device_get_match_data(dev);
>> -if (data & CQSPI_NEEDS_WR_DELAY)
>> +ddata = of_device_get_match_data(dev);
>> +if (ddata && (ddata->quirks & CQSPI_NEEDS_WR_DELAY))
>> cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
>> cqspi->master_ref_clk_hz);
>>
>> @@ -1460,14 +1476,32 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
>> #define CQSPI_DEV_PM_OPSNULL
>> #endif
>>
>> +static const struct cqspi_driver_platdata cdns_qspi = {
>> +.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
>> +};
>> +
>> +static const struct cqspi_driver_platdata k2g_qspi = {
>> +.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK,
>> +.quirks = CQSPI_NEEDS_WR_DELAY,
>> +};
>> +
>> +static const struct cqspi_driver_platdata am654_ospi = {
>> +.hwcaps_mask = CQSPI_BASE_HWCAPS_MASK | SNOR_HWCAPS_READ_1_1_8,
>> +.quirks = CQSPI_NEEDS_WR_DELAY,
>> +};
>> +
>> static const struct of_device_id cqspi_dt_ids[] = {
>> {
>> .compatible = "cdns,qspi-nor",
>> -.data = (void *)0,
>> +.data = _qspi,
>> },
>> {
>> .compatible = "ti,k2g-qspi",
>> -.data = (void *)CQSPI_NEEDS_WR_DELAY,
>> +.data = _qspi,
>> +},
>> +{
>> +.compatible = "ti,am654-ospi",
>> +.data = _ospi,
>> },
>> { /* end of table */ }
>> };
>>
--
Regards
Vignesh
Re: [PATCH v3 08/10] x86/setcpuid: Add kernel option setcpuid
On Mon, Feb 04, 2019 at 02:14:30PM -0800, Fenghua Yu wrote:
> With "setcpuid=", there is no additional code to add as long as
> enumeration code is available.
Wait, are you saying that all the other enablement of new features is
easy and the only problem is patching {early_,}init_intel() so you'd
prefer not to patch it each time and use a cmdline param instead which
is error prone and really user-unfriendly?!
Usually, the patch adding the CPUID flag and checking is the easiest
one.
Also, you do realize that even if it gets applied, it will need
to sanity-check everything passed in, which means, it will accept
*only* the leafs which you guys don't have in CPUID?! It won't be a
lets-enable-this-random-cpuid-bits-and-see-what-happens deal.
Because I don't think anyone will be willing to debug reports from such
random enablements. The qemu+kvm "experiments" are already painful
enough.
By then you're better off simply patching {early_,}init_intel() I'd say.
> Every time a new feature like this case, the early_init_intel() needs
> to be changed for FMS etc.
Yes, as part of the enablement. You really seldomly - if ever at all -
have a new feature which only needs CPUID enablement. Unless it is some
feature flag to show support for new insns but that gets applied almost
immediately and I doubt userspace even uses it through /proc/cpuinfo -
they do their own querying of CPUID.
Because if they do the latter, setcpuid= will give you nothing unless we
enforce CPUID faulting. Except *that* is not present everywhere...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [PATCHv3 11/27] PCI: mobiveil: only fix up the Class Code field
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:39 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> Fix up the Class Code to PCI bridge, do not change the Revision ID.
> And move the fixup to mobiveil_host_init function.
>
> Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge
> IP driver")
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index 78e575e71f4d..8eee1ab7ee24 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -653,6 +653,12 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
>type, resource_size(win->res));
> }
>
> + /* fixup for PCIe class register */
> + value = csr_readl(pcie, PAB_INTP_AXI_PIO_CLASS);
> + value &= 0xff;
> + value |= (PCI_CLASS_BRIDGE_PCI << 16);
> + csr_writel(pcie, value, PAB_INTP_AXI_PIO_CLASS);
> +
> /* setup MSI hardware registers */
> mobiveil_pcie_enable_msi(pcie);
>
> @@ -896,9 +902,6 @@ static int mobiveil_pcie_probe(struct platform_device
> *pdev)
> goto error;
> }
>
> - /* fixup for PCIe class register */
> - csr_writel(pcie, 0x060402ab, PAB_INTP_AXI_PIO_CLASS);
> -
> /* initialize the IRQ domains */
> ret = mobiveil_pcie_init_irq_domain(pcie);
> if (ret) {
> --
> 2.17.1
>
Re: [PATCHv3 12/27] PCI: mobiveil: move out the link up waiting from mobiveil_host_init
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:39 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> Host initial sequence does not depend on PCIe link up, so move it
> to the place just before the enumeration.
>
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index 8eee1ab7ee24..c2848c22b466 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -582,15 +582,8 @@ static void mobiveil_pcie_enable_msi(struct
> mobiveil_pcie *pcie)
> static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> {
> u32 value, pab_ctrl, type;
> - int err;
> struct resource_entry *win;
>
> - err = mobiveil_bringup_link(pcie);
> - if (err) {
> - dev_info(>pdev->dev, "link bring-up failed\n");
> - return err;
> - }
> -
> /*
> * program Bus Master Enable Bit in Command Register in PAB Config
> * Space
> @@ -662,7 +655,7 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> /* setup MSI hardware registers */
> mobiveil_pcie_enable_msi(pcie);
>
> - return err;
> + return 0;
> }
>
> static void mobiveil_mask_intx_irq(struct irq_data *data)
> @@ -922,6 +915,12 @@ static int mobiveil_pcie_probe(struct platform_device
> *pdev)
> bridge->map_irq = of_irq_parse_and_map_pci;
> bridge->swizzle_irq = pci_common_swizzle;
>
> + ret = mobiveil_bringup_link(pcie);
> + if (ret) {
> + dev_info(dev, "link bring-up failed\n");
> + goto error;
> + }
> +
> /* setup the kernel resources for the newly added PCIe root bus */
> ret = pci_scan_root_bus_bridge(bridge);
> if (ret)
> --
> 2.17.1
>
Re: [PATCHv3 10/27] PCI: mobiveil: fix the INTx process error
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:39 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> In the loop block, there is not code change the loop key,
> this patch updated the loop key by re-read the INTx status
> register.
>
> This patch also change to clear the handled INTx status.
>
> Note: Need MV to test this fix.
>
> Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host
> Bridge IP driver")
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index 4ba458474e42..78e575e71f4d 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -361,6 +361,7 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> /* Handle INTx */
> if (intr_status & PAB_INTP_INTX_MASK) {
> shifted_status = csr_readl(pcie, PAB_INTP_AMBA_MISC_STAT);
> + shifted_status &= PAB_INTP_INTX_MASK;
> shifted_status >>= PAB_INTX_START;
> do {
> for_each_set_bit(bit, _status, PCI_NUM_INTX) {
> @@ -372,12 +373,16 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> dev_err_ratelimited(dev, "unexpected
> IRQ, INT%d\n",
> bit);
>
> - /* clear interrupt */
> - csr_writel(pcie,
> - shifted_status << PAB_INTX_START,
> + /* clear interrupt handled */
> + csr_writel(pcie, 1 << (PAB_INTX_START + bit),
>PAB_INTP_AMBA_MISC_STAT);
> }
> - } while ((shifted_status >> PAB_INTX_START) != 0);
> +
> + shifted_status = csr_readl(pcie,
> + PAB_INTP_AMBA_MISC_STAT);
> + shifted_status &= PAB_INTP_INTX_MASK;
> + shifted_status >>= PAB_INTX_START;
> + } while (shifted_status != 0);
> }
>
> /* read extra MSI status register */
> --
> 2.17.1
>
Re: [PATCH V10 4/5] i2c: tegra: update transfer timeout
05.02.2019 4:29, Sowjanya Komatineni пишет:
> Tegra194 allows max of 64K bytes and Tegra186 and prior allows
> max of 4K bytes of transfer per packet.
>
> one sec timeout is not enough for transfers more than 10K bytes
> at STD bus rate.
>
> This patch updates I2C transfer timeout based on the transfer size
> and I2C bus rate to allow enough time during max transfer size at
> lower bus speed.
>
> Signed-off-by: Sowjanya Komatineni
> Acked-by: Thierry Reding
> Reviewed-by: Dmitry Osipenko
> ---
> [V10] : Reduced the timeout for bus clear operation
> Added adapter timeout to cover worst case transfer rate (max transfer
> size at STD speed) incase if ARB LOST happens during middle/end of
> the transaction.
> [V9] : Rebased to 5.0-rc4
> Minor updates for readability of xfer time
> [V8] : Added comment with explaination of xfer time calculation
> [V5/V6/V7] : Same as V4
> [V4] : V4 series includes bus clear support and this patch is updated with
> fixed timeout of 1sec for bus clear operation.
> [V3] : Same as V2
> [V2] : Added this patch in V2 series to allow enough time for data transfer
> to happen.
> This patch has dependency with DMA patch as TEGRA_I2C_TIMEOUT define
> takes argument with this patch.
>
> drivers/i2c/busses/i2c-tegra.c | 22 --
> 1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 658cf01e3f59..341475204cb6 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -25,7 +25,6 @@
> #include
> #include
>
> -#define TEGRA_I2C_TIMEOUT (msecs_to_jiffies(1000))
> #define BYTES_PER_FIFO_WORD 4
>
> #define I2C_CNFG 0x000
> @@ -936,8 +935,9 @@ static int tegra_i2c_issue_bus_clear(struct tegra_i2c_dev
> *i2c_dev)
> i2c_writel(i2c_dev, reg, I2C_BUS_CLEAR_CNFG);
> tegra_i2c_unmask_irq(i2c_dev, I2C_INT_BUS_CLR_DONE);
>
> - time_left = wait_for_completion_timeout(_dev->msg_complete,
> - TEGRA_I2C_TIMEOUT);
> + time_left = wait_for_completion_timeout(
> + _dev->msg_complete,
> + msecs_to_jiffies(50));
> if (time_left == 0) {
> dev_err(i2c_dev->dev, "timed out for bus clear\n");
> return -ETIMEDOUT;
> @@ -964,6 +964,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
> *i2c_dev,
> u32 *buffer = NULL;
> int err = 0;
> bool dma = false;
> + u16 xfer_time = 100;
>
> tegra_i2c_flush_fifos(i2c_dev);
>
> @@ -982,6 +983,13 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
> *i2c_dev,
> dma = (xfer_size > I2C_PIO_MODE_MAX_LEN) && i2c_dev->dma_buf;
> i2c_dev->is_curr_dma_xfer = dma;
>
> + /*
> + * Transfer time in mSec = Total bits / transfer rate
> + * Total bits = 9 bits per byte (including ACK bit) + Start & stop bits
> + */
> + xfer_time += DIV_ROUND_CLOSEST(((xfer_size * 9) + 2) * MSEC_PER_SEC,
> + i2c_dev->bus_clk_rate);
> +
> spin_lock_irqsave(_dev->xfer_lock, flags);
>
> int_mask = I2C_INT_NO_ACK | I2C_INT_ARBITRATION_LOST;
> @@ -1089,7 +1097,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
> *i2c_dev,
>
> time_left = wait_for_completion_timeout(
> _dev->dma_complete,
> - TEGRA_I2C_TIMEOUT);
> + msecs_to_jiffies(xfer_time));
>
> if (time_left == 0) {
> dev_err(i2c_dev->dev, "DMA transfer timeout\n");
> @@ -1110,8 +1118,9 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev
> *i2c_dev,
> }
> }
>
> - time_left = wait_for_completion_timeout(_dev->msg_complete,
> - TEGRA_I2C_TIMEOUT);
> + time_left = wait_for_completion_timeout(
> + _dev->msg_complete,
> + msecs_to_jiffies(xfer_time));
> tegra_i2c_mask_irq(i2c_dev, int_mask);
>
> if (time_left == 0) {
> @@ -1367,6 +1376,7 @@ static int tegra_i2c_probe(struct platform_device *pdev)
> i2c_dev->div_clk = div_clk;
> i2c_dev->adapter.algo = _i2c_algo;
> i2c_dev->adapter.retries = 1;
> + i2c_dev->adapter.timeout = msecs_to_jiffies(6 * MSEC_PER_SEC);
There is a "HZ" constant in kernel which is equal to a number of jiffies per
second. It's a common practice to use it where appropriate, in this case it
will be:
i2c_dev->adapter.timeout = 6 * HZ;
> i2c_dev->irq = irq;
> i2c_dev->cont_id = pdev->id;
> i2c_dev->dev = >dev;
>
Re: perf_event_open+clone = unkillable process
ebied...@xmission.com (Eric W. Biederman) writes: > ebied...@xmission.com (Eric W. Biederman) writes: > >> Thomas Gleixner writes: >> >>> On Mon, 4 Feb 2019, Dmitry Vyukov wrote: >>> On Mon, Feb 4, 2019 at 10:27 AM Thomas Gleixner wrote: > > On Fri, 1 Feb 2019, Dmitry Vyukov wrote: > > > On Fri, Feb 1, 2019 at 5:48 PM Dmitry Vyukov > > wrote: > > > > > > Hello, > > > > > > The following program creates an unkillable process that eats CPU. > > > /proc/pid/stack is empty, I am not sure what other info I can > > > provide. > > > > > > Tested is on upstream commit > > > 4aa9fc2a435abe95a1e8d7f8c7b3d6356514b37a. > > > Config is attached. > > > > Looking through other reproducers that create unkillable processes, I > > think I found a much simpler reproducer (below). It's single threaded > > and just setups SIGBUS handler and does timer_create+timer_settime to > > send repeated SIGBUS. The resulting process can't be killed with > > SIGKILL. > > +Thomas for timers. > > +Oleg, Eric > > That's odd. With some tracing I can see that SIGKILL is generated and > queued, but its not delivered by some weird reason. I'm traveling in the > next days, so I won't be able to do much about it. Will look later this > week. Just a random though looking at the repro: can constant SIGBUS delivery starve delivery of all other signals (incl SIGKILL)? >>> >>> Indeed. SIGBUS is 7, SIGKILL is 9 and next_signal() delivers the lowest >>> number first >> >> We do have the special case in complete_signal that causes most of the >> signal delivery work of SIGKILL to happen when SIGKILL is queued. >> >> I need to look at your reproducer. It would require being a per-thread >> signal to cause problems in next_signal. >> >> It is definitely worth fixing if there is any way for userspace to block >> SIGKILL. > > Ugh. > > The practical problem appears much worse. > > Tracing the code I see that we attempt to deliver SIGBUS, I presume in a > per thread way. > > At some point the delivery of SIGBUS fails. Then the kernel attempts > to synchronously force SIGSEGV. Which should be the end of it. > > Unfortunately at that point our heuristic for dealing with syncrhonous > signals fails in next_signal and we attempt to deliver the timers > SIGBUS instead. > > I suspect it is time to byte the bullet and handle the synchronous > unblockable signals differently. I will see if I can cook up an > appropriate patch. Playing with this some more what I see happening is: SIGHUP and SIGSEGV get directed at sighup_handler. Timer delivers SIGHUP sighup_handler starts. timer delivers SIGHUP (before sighup_handler finishes) sighup_handler starts. timer delivers SIGHUP (before sighup_handler finishes) sighup_handler starts. timer delivers SIGHUP (before sighup_handler finishes) sighup_handler starts. Up until the stack is full. Then: timer delivers SIGHUP sighup_handler won't start Attempt force_sigsegv Confused kernel attempts to deliver SIGHUP (instead of a synchronous SIGSEGV) If you unconfuse the kernel there is an attempt to deliver SIGSEGV (the stack is full) Then the kernel changes the SIGSEGV handler to SIG_DFL Then SIGSEGV is successfully delivered terminating the application Which suggests 2 fixes. 1) making SIGKILL something that can't get hidden behind other signals. 2) Having a 3rd queue of signals for the synchronous signals. So that the synchronous signals can't be blocked by per thread signals. I have prototyped the 2nd one and it is enough to stop the infinite spin that causes problems here when the process stack fills up. Fixing SIGKILL will probably bring more benefits. Eric
Re: [PATCHv3 09/27] PCI: mobiveil: correct inbound/outbound window setup routines
ZQ,
please correct the tab spacing of the macro definitions, otherwise its OK.
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:39 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> Outbound window routine:
> - Removed unused var definition and register read operations.
> - Added the upper 32-bit cpu address setup of the window.
> - Instead of blindly write, only change the fields specified.
> - Masked the lower bits of window size in case override the
>control bits.
> - Check if the passing window number is available, instead of
>the total number of the initialized windows.
>
> Inbound window routine:
> - Added parameter 'u64 cpu_addr' to specify the cpu address
>of the window instead of using 'pci_addr'.
> - Changed 'int pci_addr' to 'u64 pci_addr', and added setup
>of the upper 32-bit pci address of the window.
> - Moved the PCIe PIO master enablement to mobiveil_host_init().
> - Instead of blindly write, only change the fields specified.
> - Masked the lower bits of window size in case override the
>control bits.
> - Check if the passing window number is available, instead of
>the total number of the initialized windows.
> - And added the statistic of initialized inbound windows.
>
> Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host
> Bridge IP driver")
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 70 +++---
> 1 file changed, 42 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index e88afc792a5c..4ba458474e42 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -65,9 +65,13 @@
> #define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win)
> #define WIN_ENABLE_SHIFT 0
> #define WIN_TYPE_SHIFT1
> +#define WIN_TYPE_MASK 0x3
> +#define WIN_SIZE_SHIFT10
> +#define WIN_SIZE_MASK 0x3f
>
> #define PAB_EXT_AXI_AMAP_SIZE(win) PAB_EXT_REG_ADDR(0xbaf0, win)
>
> +#define PAB_EXT_AXI_AMAP_AXI_WIN(win) PAB_EXT_REG_ADDR(0x80a0, win)
> #define PAB_AXI_AMAP_AXI_WIN(win) PAB_REG_ADDR(0x0ba4, win)
> #define AXI_WINDOW_ALIGN_MASK 3
>
> @@ -82,8 +86,10 @@
> #define PAB_PEX_AMAP_CTRL(win) PAB_REG_ADDR(0x4ba0, win)
> #define AMAP_CTRL_EN_SHIFT0
> #define AMAP_CTRL_TYPE_SHIFT 1
> +#define AMAP_CTRL_TYPE_MASK 3
>
> #define PAB_EXT_PEX_AMAP_SIZEN(win)PAB_EXT_REG_ADDR(0xbef0, win)
> +#define PAB_EXT_PEX_AMAP_AXI_WIN(win) PAB_EXT_REG_ADDR(0xb4a0, win)
> #define PAB_PEX_AMAP_AXI_WIN(win) PAB_REG_ADDR(0x4ba4, win)
> #define PAB_PEX_AMAP_PEX_WIN_L(win)PAB_REG_ADDR(0x4ba8, win)
> #define PAB_PEX_AMAP_PEX_WIN_H(win)PAB_REG_ADDR(0x4bac, win)
> @@ -455,49 +461,51 @@ static int mobiveil_pcie_parse_dt(struct mobiveil_pcie
> *pcie)
> }
>
> static void program_ib_windows(struct mobiveil_pcie *pcie, int win_num,
> - int pci_addr, u32 type, u64 size)
> + u64 cpu_addr, u64 pci_addr, u32 type, u64 size)
> {
> - int pio_ctrl_val;
> - int amap_ctrl_dw;
> + u32 value;
> u64 size64 = ~(size - 1);
>
> - if ((pcie->ib_wins_configured + 1) > pcie->ppio_wins) {
> + if (win_num >= pcie->ppio_wins) {
> dev_err(>pdev->dev,
> "ERROR: max inbound windows reached !\n");
> return;
> }
>
> - pio_ctrl_val = csr_readl(pcie, PAB_PEX_PIO_CTRL);
> - pio_ctrl_val |= 1 << PIO_ENABLE_SHIFT;
> - csr_writel(pcie, pio_ctrl_val, PAB_PEX_PIO_CTRL);
> -
> - amap_ctrl_dw = csr_readl(pcie, PAB_PEX_AMAP_CTRL(win_num));
> - amap_ctrl_dw |= (type << AMAP_CTRL_TYPE_SHIFT) |
> - (1 << AMAP_CTRL_EN_SHIFT) |
> - lower_32_bits(size64);
> - csr_writel(pcie, amap_ctrl_dw, PAB_PEX_AMAP_CTRL(win_num));
> + value = csr_readl(pcie, PAB_PEX_AMAP_CTRL(win_num));
> + value &= ~(AMAP_CTRL_TYPE_MASK << AMAP_CTRL_TYPE_SHIFT |
> +WIN_SIZE_MASK << WIN_SIZE_SHIFT);
> + value |= (type << AMAP_CTRL_TYPE_SHIFT) | (1 << AMAP_CTRL_EN_SHIFT) |
> +(lower_32_bits(size64) & WIN_SIZE_MASK << WIN_SIZE_SHIFT);
> + csr_writel(pcie, value, PAB_PEX_AMAP_CTRL(win_num));
>
> csr_writel(pcie, upper_32_bits(size64),
>PAB_EXT_PEX_AMAP_SIZEN(win_num));
>
> - csr_writel(pcie, pci_addr, PAB_PEX_AMAP_AXI_WIN(win_num));
> + csr_writel(pcie, lower_32_bits(cpu_addr),
> + PAB_PEX_AMAP_AXI_WIN(win_num));
> + csr_writel(pcie, upper_32_bits(cpu_addr),
> + PAB_EXT_PEX_AMAP_AXI_WIN(win_num));
> +
> + csr_writel(pcie, lower_32_bits(pci_addr),
> +
Re: [PATCHv3 08/27] PCI: mobiveil: use the 1st inbound window for MEM inbound transactions
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:39 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> The inbound windows have different register set with outbound windows.
> This patch change the MEM inbound window to the first one.
>
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index df71c11b4810..e88afc792a5c 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -616,7 +616,7 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
>CFG_WINDOW_TYPE, resource_size(pcie->ob_io_res));
>
> /* memory inbound translation window */
> - program_ib_windows(pcie, WIN_NUM_1, 0, MEM_WINDOW_TYPE, IB_WIN_SIZE);
> + program_ib_windows(pcie, WIN_NUM_0, 0, MEM_WINDOW_TYPE, IB_WIN_SIZE);
>
> /* Get the I/O and memory ranges from DT */
> resource_list_for_each_entry(win, >resources) {
> --
> 2.17.1
>
Re: [PATCHv3 07/27] PCI: mobiveil: use WIN_NUM_0 explicitly for CFG outbound window
Reviewed-by: Subrahmanya Lingappa On Tue, Jan 29, 2019 at 1:39 PM Z.q. Hou wrote: > > From: Hou Zhiqiang > > As the .map_bus() use the WIN_NUM_0 for CFG transactions, > it's better passing WIN_NUM_0 explicitly when initialize > the CFG outbound window. > > Signed-off-by: Hou Zhiqiang > Reviewed-by: Minghuan Lian > --- > V3: > - No change > > drivers/pci/controller/pcie-mobiveil.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/pci/controller/pcie-mobiveil.c > b/drivers/pci/controller/pcie-mobiveil.c > index b2cc9c097fc9..df71c11b4810 100644 > --- a/drivers/pci/controller/pcie-mobiveil.c > +++ b/drivers/pci/controller/pcie-mobiveil.c > @@ -612,9 +612,8 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie) > */ > > /* config outbound translation window */ > - program_ob_windows(pcie, pcie->ob_wins_configured, > - pcie->ob_io_res->start, 0, CFG_WINDOW_TYPE, > - resource_size(pcie->ob_io_res)); > + program_ob_windows(pcie, WIN_NUM_0, pcie->ob_io_res->start, 0, > + CFG_WINDOW_TYPE, resource_size(pcie->ob_io_res)); > > /* memory inbound translation window */ > program_ib_windows(pcie, WIN_NUM_1, 0, MEM_WINDOW_TYPE, IB_WIN_SIZE); > -- > 2.17.1 >
Re: [PATCHv3 06/27] PCI: mobiveil: replace the resource list iteration function
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:39 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> As it won't delete any node in this iteration, replaced
> the function resource_list_for_each_entry_safe() with
> the resource_list_for_each_entry().
>
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index 8ff873023b5f..b2cc9c097fc9 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -569,7 +569,7 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> {
> u32 value, pab_ctrl, type;
> int err;
> - struct resource_entry *win, *tmp;
> + struct resource_entry *win;
>
> err = mobiveil_bringup_link(pcie);
> if (err) {
> @@ -620,7 +620,7 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
> program_ib_windows(pcie, WIN_NUM_1, 0, MEM_WINDOW_TYPE, IB_WIN_SIZE);
>
> /* Get the I/O and memory ranges from DT */
> - resource_list_for_each_entry_safe(win, tmp, >resources) {
> + resource_list_for_each_entry(win, >resources) {
> if (resource_type(win->res) == IORESOURCE_MEM)
> type = MEM_WINDOW_TYPE;
> else if (resource_type(win->res) == IORESOURCE_IO)
> --
> 2.17.1
>
Re: [PATCH V10 1/5] i2c: tegra: sort all the include headers alphabetically
05.02.2019 4:29, Sowjanya Komatineni пишет: > This patch sorts all the include headers alphabetically for the > I2C Tegra driver. > > Signed-off-by: Sowjanya Komatineni Yours "Signed-off-by" should be that the last line of the commit message. Same for the other patches. > Acked-by: Thierry Reding > Reviewed-by: Dmitry Osipenko > ---
Re: [PATCHv3 05/27] PCI: mobiveil: correct PCI base address in MEM/IO outbound windows
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:39 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> It should get PCI base address from the DT node property 'ranges'
> to setup MEM/IO outbound windows instead of always zero.
>
> Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge
> IP driver")
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index a0dd337c6214..8ff873023b5f 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -630,8 +630,9 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
>
> /* configure outbound translation window */
> program_ob_windows(pcie, pcie->ob_wins_configured,
> - win->res->start, 0, type,
> - resource_size(win->res));
> + win->res->start,
> + win->res->start - win->offset,
> + type, resource_size(win->res));
> }
>
> /* setup MSI hardware registers */
> --
> 2.17.1
>
Re: [PATCH V10 3/5] i2c: tegra: Add DMA support
05.02.2019 4:29, Sowjanya Komatineni пишет:
> This patch adds DMA support for Tegra I2C.
>
> Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
> transfer size of the max FIFO depth and DMA mode is used for
> transfer size higher than max FIFO depth to save CPU overhead.
>
> PIO mode needs full intervention of CPU to fill or empty FIFO's
> and also need to service multiple data requests interrupt for the
> same transaction. This adds delay between data bytes of the same
> transfer when CPU is fully loaded and some slave devices has
> internal timeout for no bus activity and stops transaction to
> avoid bus hang. DMA mode is helpful in such cases.
>
> DMA mode is also helpful for Large transfers during downloading or
> uploading FW over I2C to some external devices.
>
> Signed-off-by: Sowjanya Komatineni
> ---
> [V10] : APBDMA is replaced with GPCDMA on Tegra186 and Tegra194 designs.
> Added apbdma hw support flag to now allow Tegra186 and later use
> APBDMA driver.
> Added explicit flow control enable for DMA slave config and error
> handling.
> Moved releasing DMA resources to seperate function to reuse in
> multiple places.
> Updated to register tegra_i2c_driver from module level rather than
> subsys
> level.
> Other minor feedback
> [V9] : Rebased to 5.0-rc4
> Removed dependency of APB DMA in Kconfig and added conditional check
> in I2C driver to decide on using DMA mode.
> Changed back the allocation of dma buffer during i2c probe.
> Fixed FIFO triggers depending on DMA Vs PIO.
> [V8] : Moved back dma init to i2c probe, removed ALL_PACKETS_XFER_COMPLETE
> interrupt and using PACKETS_XFER_COMPLETE interrupt only and some
> other fixes
> Updated Kconfig for APB_DMA dependency
> [V7] : Same as V6
> [V6] : Updated for proper buffer allocation/freeing, channel release.
> Updated to use exact xfer size for syncing dma buffer.
> [V5] : Same as V4
> [V4] : Updated to allocate DMA buffer only when DMA mode.
> Updated to fall back to PIO mode when DMA channel request or
> buffer allocation fails.
> [V3] : Updated without additional buffer allocation.
> [V2] : Updated based on V1 review feedback along with code cleanup for
> proper implementation of DMA.
>
> drivers/i2c/busses/i2c-tegra.c | 404
> -
> 1 file changed, 360 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index 118b7023a0f4..658cf01e3f59 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -8,6 +8,9 @@
>
> #include
> #include
> +#include
> +#include
> +#include
> #include
> #include
> #include
> @@ -44,6 +47,8 @@
> #define I2C_FIFO_CONTROL_RX_FLUSHBIT(0)
> #define I2C_FIFO_CONTROL_TX_TRIG_SHIFT 5
> #define I2C_FIFO_CONTROL_RX_TRIG_SHIFT 2
> +#define I2C_FIFO_CONTROL_TX_TRIG(x) (((x) - 1) << 5)
> +#define I2C_FIFO_CONTROL_RX_TRIG(x) (((x) - 1) << 2)
> #define I2C_FIFO_STATUS 0x060
> #define I2C_FIFO_STATUS_TX_MASK 0xF0
> #define I2C_FIFO_STATUS_TX_SHIFT 4
> @@ -125,6 +130,19 @@
> #define I2C_MST_FIFO_STATUS_TX_MASK 0xff
> #define I2C_MST_FIFO_STATUS_TX_SHIFT 16
>
> +/* Packet header size in bytes */
> +#define I2C_PACKET_HEADER_SIZE 12
> +
> +#define DATA_DMA_DIR_TX (1 << 0)
> +#define DATA_DMA_DIR_RX (1 << 1)
> +
> +/*
> + * Upto I2C_PIO_MODE_MAX_LEN bytes, controller will use PIO mode,
> + * above this, controller will use DMA to fill FIFO.
> + * MAX PIO len is 20 bytes excluding packet header.
> + */
> +#define I2C_PIO_MODE_MAX_LEN 32
> +
> /*
> * msg_end_type: The bus control which need to be send at end of transfer.
> * @MSG_END_STOP: Send stop pulse at end of transfer.
> @@ -166,6 +184,7 @@ enum msg_end_type {
> * allowing 0 length transfers.
> * @supports_bus_clear: Bus Clear support to recover from bus hang during
> * SDA stuck low from device for some unknown reasons.
> + * @has_apb_dma: Support of APBDMA on corresponding Tegra chip.
> */
> struct tegra_i2c_hw_feature {
> bool has_continue_xfer_support;
> @@ -180,6 +199,7 @@ struct tegra_i2c_hw_feature {
> bool has_mst_fifo;
> const struct i2c_adapter_quirks *quirks;
> bool supports_bus_clear;
> + bool has_apb_dma;
> };
>
> /**
> @@ -191,6 +211,7 @@ struct tegra_i2c_hw_feature {
> * @fast_clk: clock reference for fast clock of I2C controller
> * @rst: reset control for the I2C controller
> * @base: ioremapped registers cookie
> + * @base_phys: Physical base address of the I2C controller
> * @cont_id: I2C controller ID, used for packet header
> * @irq: IRQ number of transfer
Re: [PATCH 7/7] arm64: dts: qcom: qcs404: Add PCIe related nodes
On 25-01-19, 15:45, Bjorn Andersson wrote:
> The QCS404 has a PCIe2 PHY and a Qualcomm PCIe controller, add these to
> the platform dtsi and enable them for the EVB with the perst gpio
> and analog supplies defined.
>
> Signed-off-by: Bjorn Andersson
> ---
> arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 25 +
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 67
> 2 files changed, 92 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
> b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
> index 50b3589c7f15..579ddaf4f5fa 100644
> --- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
> @@ -21,6 +21,22 @@
> };
> };
>
> + {
> + status = "ok";
> +
> + perst-gpio = < 43 GPIO_ACTIVE_LOW>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_state>;
> +};
> +
> +_phy {
> + status = "ok";
> +
> + vdda-vp-supply = <_l3_1p05>;
> + vdda-vph-supply = <_l5_1p8>;
> +};
I would prefer the patches be split to qcs404 adding PCIe nodes and then
add the board node for EVB...
> +
> _adsp {
> status = "ok";
> };
> @@ -137,6 +153,15 @@
> };
>
> {
> + perst_state: perst {
> + pins = "gpio43";
> + function = "gpio";
> +
> + drive-strength = <2>;
> + bias-disable;
> + output-low;
> + };
> +
> sdc1_on: sdc1-on {
> clk {
> pins = "sdc1_clk";
> diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> index 76699435c8bd..7b219865ba7e 100644
> --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> @@ -3,6 +3,7 @@
>
> #include
> #include
> +#include
>
> / {
> interrupt-parent = <>;
> @@ -377,6 +378,7 @@
> compatible = "qcom,gcc-qcs404";
> reg = <0x0180 0x8>;
> #clock-cells = <1>;
> + #reset-cells = <1>;
>
> assigned-clocks = < GCC_APSS_AHB_CLK_SRC>;
> assigned-clock-rates = <1920>;
> @@ -405,6 +407,21 @@
> #interrupt-cells = <4>;
> };
>
> + pcie_phy: phy@7786000 {
> + compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
> + reg = <0x07786000 0xb8>;
> +
> + clocks = < GCC_PCIE_0_PIPE_CLK>;
> + resets = < GCC_PCIEPHY_0_PHY_BCR>,
> + < GCC_PCIE_0_PIPE_ARES>;
> + reset-names = "phy", "pipe";
> +
> + clock-output-names = "pcie_0_pipe_clk";
> + #phy-cells = <0>;
> +
> + status = "disabled";
> + };
> +
> sdcc1: sdcc@7804000 {
> compatible = "qcom,sdhci-msm-v5";
> reg = <0x07804000 0x1000>, <0x7805000 0x1000>;
> @@ -771,6 +788,56 @@
> status = "disabled";
> };
> };
> +
> + pcie: pci@1000 {
> + compatible = "qcom,pcie-qcs404", "snps,dw-pcie";
> + reg = <0x1000 0xf1d
> + 0x1f20 0xa8
> + 0x0778 0x2000
> + 0x10001000 0x2000>;
> + reg-names = "dbi", "elbi", "parf", "config";
> + device_type = "pci";
> + linux,pci-domain = <0>;
> + bus-range = <0x00 0xff>;
> + num-lanes = <1>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> +
> + ranges = <0x8100 0 0 0x10003000 0
> 0x0001 /* I/O */
> + 0x8200 0 0x10013000 0x10013000 0
> 0x007ed000>; /* memory */
> +
> + interrupts = ;
> + interrupt-names = "msi";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 0x7>;
> + interrupt-map = <0 0 0 1 GIC_SPI 68
> IRQ_TYPE_LEVEL_HIGH>, /* int_a */
> + <0 0 0 2 GIC_SPI 224
> IRQ_TYPE_LEVEL_HIGH>, /* int_b */
> + <0 0 0 3 GIC_SPI 267
> IRQ_TYPE_LEVEL_HIGH>, /* int_c */
> + <0 0 0 4 GIC_SPI 268
> IRQ_TYPE_LEVEL_HIGH>; /* int_d */
> + clocks = < GCC_PCIE_0_CFG_AHB_CLK>,
> + < GCC_PCIE_0_AUX_CLK>,
> + < GCC_PCIE_0_MSTR_AXI_CLK>,
> + < GCC_PCIE_0_SLV_AXI_CLK>;
> + clock-names = "iface", "aux", "master_bus", "slave_bus";
> +
> + resets = < GCC_PCIE_0_AXI_MASTER_ARES>,
> + <
Re: [PATCHv3 04/27] PCI: mobiveil: remove flag MSI_FLAG_MULTI_PCI_MSI
Zhiqiang,
why are we removing multi-MSI support ?
what functionality this driver is not providing to support it ?
Thanks.
On Tue, Jan 29, 2019 at 1:38 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> The current code does not support multiple MSIs, so remove
> the corresponding flag from the msi_domain_info structure.
>
> Fixes: 1e913e58335f ("PCI: mobiveil: Add MSI support")
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index 563210e731d3..a0dd337c6214 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -703,7 +703,7 @@ static struct irq_chip mobiveil_msi_irq_chip = {
>
> static struct msi_domain_info mobiveil_msi_domain_info = {
> .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> - MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
> + MSI_FLAG_PCI_MSIX),
> .chip = _msi_irq_chip,
> };
>
> --
> 2.17.1
>
make modules_install install is failing
Hi all, I am unable to execute make modules_install install. I get the following error: ln: target 'linux-00096-gd1aa1a8/source' is not a directory Makefile:1281: recipe for target '_modinst_' failed make[1]: *** [_modinst_] Error 1 Makefile:296: recipe for target '__build_one_by_one' failed make: *** [__build_one_by_one] Error 2 I made a change to a driver and did not commit the changes. I then built the kernel and two weird looking files appeared in my root directory: linux-00095-g94832d9-dirty linux-00096-gd1aa1a8 Since then , I have commited my changes and made the kernel again. The dirs still exist. I have tried manually removing them but they reappear whenever I make the kernel again. I am running the version: 5.0.0-rc2+ I am not able to make the kernel modules because of this. Is this a common problem? Any answers? Thank you
Re: [PATCH 2/7] dt-bindings: phy: Add binding for Qualcomm PCIe2 PHY
On 25-01-19, 15:45, Bjorn Andersson wrote:
> The Qualcomm PCIe2 PHY is a Synopsys based PCIe PHY found in a number of
> Qualcomm platforms, add a binding to describe this.
>
> Signed-off-by: Bjorn Andersson
> ---
> .../bindings/phy/qcom-pcie2-phy.txt | 40 +++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
> b/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
> new file mode 100644
> index ..7da02f9d78c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom-pcie2-phy.txt
> @@ -0,0 +1,40 @@
> +Qualcomm PCIe2 PHY controller
> +=
> +
> +The Qualcomm PCIe2 PHY is a Synopsys based phy found in a number of Qualcomm
> +platforms.
> +
> +Required properties:
> + - compatible: compatible list, should be:
> +"qcom,qcs404-pcie2-phy", "qcom,pcie2-phy"
> +
> + - reg: offset and length of the PHY register set.
> + - #phy-cells: must be 0.
> +
> + - clocks: a clock-specifier pair for the "pipe" clock
> +
> + - vdda-vp-supply: phandle to low voltage regulator
> + - vdda-vph-supply: phandle to high voltage regulator
> +
> + - resets: reset-specifier pairs for the "phy" and "pipe" resets
> + - reset-names: list of resets, should contain:
> + "phy" and "pipe"
> +
> + - clock-output-names: name of the outgoing clock signal from the PHY PLL
Should we specify the clk name here?
> +
> +Example:
> + phy@7786000 {
> + compatible = "qcom,qcs404-pcie2-phy", "qcom,pcie2-phy";
> + reg = <0x07786000 0xb8>;
> +
> + clocks = < GCC_PCIE_0_PIPE_CLK>;
> + resets = < GCC_PCIEPHY_0_PHY_BCR>,
> + < GCC_PCIE_0_PIPE_ARES>;
> + reset-names = "phy", "pipe";
> +
> + vdda-vp-supply = <_l3_1p05>;
> + vdda-vph-supply = <_l5_1p8>;
> +
> + clock-output-names = "pcie_0_pipe_clk";
> + #phy-cells = <0>;
> + };
> --
> 2.18.0
--
~Vinod
Re: [PATCHv3 03/27] PCI: mobiveil: correct the returned error number
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:38 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> This patch corrected the returned error number by convention,
> and removed a unnecessary error check.
>
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index b87471f08a40..563210e731d3 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -819,7 +819,7 @@ static int mobiveil_pcie_init_irq_domain(struct
> mobiveil_pcie *pcie)
>
> if (!pcie->intx_domain) {
> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> - return -ENODEV;
> + return -ENOMEM;
> }
>
> raw_spin_lock_init(>intx_mask_lock);
> @@ -845,11 +845,9 @@ static int mobiveil_pcie_probe(struct platform_device
> *pdev)
> /* allocate the PCIe port */
> bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> if (!bridge)
> - return -ENODEV;
> + return -ENOMEM;
>
> pcie = pci_host_bridge_priv(bridge);
> - if (!pcie)
> - return -ENOMEM;
>
> pcie->pdev = pdev;
>
> @@ -866,7 +864,7 @@ static int mobiveil_pcie_probe(struct platform_device
> *pdev)
> >resources,
> );
> if (ret) {
> dev_err(dev, "Getting bridge resources failed\n");
> - return -ENOMEM;
> + return ret;
> }
>
> /*
> --
> 2.17.1
>
Re: [PATCHv3 02/27] PCI: mobiveil: format the code without function change
Zhiqiang, On Tue, Jan 29, 2019 at 1:38 PM Z.q. Hou wrote: > > From: Hou Zhiqiang > > Just format the code without functionality change. > > Signed-off-by: Hou Zhiqiang > Reviewed-by: Minghuan Lian > --- > V3: > - No change > > drivers/pci/controller/pcie-mobiveil.c | 261 + > 1 file changed, 137 insertions(+), 124 deletions(-) > > diff --git a/drivers/pci/controller/pcie-mobiveil.c > b/drivers/pci/controller/pcie-mobiveil.c > index d55c7e780c6e..b87471f08a40 100644 > --- a/drivers/pci/controller/pcie-mobiveil.c > +++ b/drivers/pci/controller/pcie-mobiveil.c > @@ -31,38 +31,40 @@ > * translation tables are grouped into windows, each window registers are > * grouped into blocks of 4 or 16 registers each > */ > -#define PAB_REG_BLOCK_SIZE 16 > -#define PAB_EXT_REG_BLOCK_SIZE 4 > +#define PAB_REG_BLOCK_SIZE 16 > +#define PAB_EXT_REG_BLOCK_SIZE 4 > > -#define PAB_REG_ADDR(offset, win) (offset + (win * PAB_REG_BLOCK_SIZE)) > -#define PAB_EXT_REG_ADDR(offset, win) (offset + (win * > PAB_EXT_REG_BLOCK_SIZE)) > +#define PAB_REG_ADDR(offset, win) \ > + (offset + (win * PAB_REG_BLOCK_SIZE)) > +#define PAB_EXT_REG_ADDR(offset, win) \ > + (offset + (win * PAB_EXT_REG_BLOCK_SIZE)) > > -#define LTSSM_STATUS 0x0404 > -#define LTSSM_STATUS_L0_MASK 0x3f > -#define LTSSM_STATUS_L0 0x2d > +#define LTSSM_STATUS 0x0404 > +#define LTSSM_STATUS_L0_MASK 0x3f > +#define LTSSM_STATUS_L0 0x2d > > -#define PAB_CTRL 0x0808 > -#define AMBA_PIO_ENABLE_SHIFT 0 > -#define PEX_PIO_ENABLE_SHIFT 1 > -#define PAGE_SEL_SHIFT13 > -#define PAGE_SEL_MASK 0x3f > -#define PAGE_LO_MASK 0x3ff > -#define PAGE_SEL_OFFSET_SHIFT 10 > +#define PAB_CTRL 0x0808 > +#define AMBA_PIO_ENABLE_SHIFT 0 > +#define PEX_PIO_ENABLE_SHIFT 1 > +#define PAGE_SEL_SHIFT13 above line seems to have an extra tab which makes it not aligned with lines above. > +#define PAGE_SEL_MASK 0x3f > +#define PAGE_LO_MASK 0x3ff > +#define PAGE_SEL_OFFSET_SHIFT 10 > > -#define PAB_AXI_PIO_CTRL 0x0840 > -#define APIO_EN_MASK 0xf > +#define PAB_AXI_PIO_CTRL 0x0840 > +#define APIO_EN_MASK 0xf > > -#define PAB_PEX_PIO_CTRL 0x08c0 > -#define PIO_ENABLE_SHIFT 0 > +#define PAB_PEX_PIO_CTRL 0x08c0 > +#define PIO_ENABLE_SHIFT 0 > > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c > -#define PAB_INTP_AMBA_MISC_STAT0x0b1c > +#define PAB_INTP_AMBA_MISC_STAT0x0b1c > #define PAB_INTP_INTX_MASK0x01e0 > #define PAB_INTP_MSI_MASK 0x8 > > -#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > -#define WIN_ENABLE_SHIFT 0 > -#define WIN_TYPE_SHIFT1 > +#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > +#define WIN_ENABLE_SHIFT 0 > +#define WIN_TYPE_SHIFT1 please check the extra tab above > > #define PAB_EXT_AXI_AMAP_SIZE(win) PAB_EXT_REG_ADDR(0xbaf0, win) > > @@ -70,16 +72,16 @@ > #define AXI_WINDOW_ALIGN_MASK 3 > > #define PAB_AXI_AMAP_PEX_WIN_L(win)PAB_REG_ADDR(0x0ba8, win) > -#define PAB_BUS_SHIFT 24 > -#define PAB_DEVICE_SHIFT 19 > -#define PAB_FUNCTION_SHIFT16 > +#define PAB_BUS_SHIFT 24 > +#define PAB_DEVICE_SHIFT 19 > +#define PAB_FUNCTION_SHIFT16 > > #define PAB_AXI_AMAP_PEX_WIN_H(win)PAB_REG_ADDR(0x0bac, win) > #define PAB_INTP_AXI_PIO_CLASS 0x474 > > -#define PAB_PEX_AMAP_CTRL(win) PAB_REG_ADDR(0x4ba0, win) > -#define AMAP_CTRL_EN_SHIFT0 > -#define AMAP_CTRL_TYPE_SHIFT 1 > +#define PAB_PEX_AMAP_CTRL(win) PAB_REG_ADDR(0x4ba0, win) > +#define AMAP_CTRL_EN_SHIFT0 > +#define AMAP_CTRL_TYPE_SHIFT 1 > > #define PAB_EXT_PEX_AMAP_SIZEN(win)PAB_EXT_REG_ADDR(0xbef0, win) > #define PAB_PEX_AMAP_AXI_WIN(win) PAB_REG_ADDR(0x4ba4, win) > @@ -87,39 +89,39 @@ > #define PAB_PEX_AMAP_PEX_WIN_H(win)PAB_REG_ADDR(0x4bac, win) > > /* starting offset of INTX bits in status register */ > -#define PAB_INTX_START 5 > +#define PAB_INTX_START 5 > > /* supported number of MSI interrupts */ > -#define PCI_NUM_MSI16 > +#define PCI_NUM_MSI16 > > /* MSI registers */ > -#define MSI_BASE_LO_OFFSET 0x04 > -#define MSI_BASE_HI_OFFSET 0x08 > -#define MSI_SIZE_OFFSET0x0c > -#define MSI_ENABLE_OFFSET 0x14 > -#define MSI_STATUS_OFFSET 0x18 > -#define MSI_DATA_OFFSET0x20 > -#define MSI_ADDR_L_OFFSET 0x24 > -#define MSI_ADDR_H_OFFSET 0x28 > +#define MSI_BASE_LO_OFFSET 0x04 > +#define MSI_BASE_HI_OFFSET 0x08 > +#define MSI_SIZE_OFFSET0x0c > +#define
Re: [PATCHv3 01/27] PCI: mobiveil: uniform the register accessors
Reviewed-by: Subrahmanya Lingappa
On Tue, Jan 29, 2019 at 1:38 PM Z.q. Hou wrote:
>
> From: Hou Zhiqiang
>
> It's confused that R/W some registers by csr_readl()/csr_writel(),
> while others by read_paged_register()/write_paged_register().
> Actually the low 3KB of 4KB PCIe configure space can be accessed
> directly and high 1KB is paging area. So this patch uniformed the
> register accessors to csr_readl() and csr_writel() by comparing
> the register offset with page access boundary 3KB in the accessor
> internal.
>
> Signed-off-by: Hou Zhiqiang
> Reviewed-by: Minghuan Lian
> ---
> V3:
> - No change
>
> drivers/pci/controller/pcie-mobiveil.c | 179 +
> 1 file changed, 124 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-mobiveil.c
> b/drivers/pci/controller/pcie-mobiveil.c
> index 77052a0712d0..d55c7e780c6e 100644
> --- a/drivers/pci/controller/pcie-mobiveil.c
> +++ b/drivers/pci/controller/pcie-mobiveil.c
> @@ -47,7 +47,6 @@
> #define PAGE_SEL_SHIFT13
> #define PAGE_SEL_MASK 0x3f
> #define PAGE_LO_MASK 0x3ff
> -#define PAGE_SEL_EN 0xc00
> #define PAGE_SEL_OFFSET_SHIFT 10
>
> #define PAB_AXI_PIO_CTRL 0x0840
> @@ -117,6 +116,12 @@
> #define LINK_WAIT_MIN 9
> #define LINK_WAIT_MAX 10
>
> +#define PAGED_ADDR_BNDRY 0xc00
> +#define OFFSET_TO_PAGE_ADDR(off) \
> + ((off & PAGE_LO_MASK) | PAGED_ADDR_BNDRY)
> +#define OFFSET_TO_PAGE_IDX(off)\
> + ((off >> PAGE_SEL_OFFSET_SHIFT) & PAGE_SEL_MASK)
> +
> struct mobiveil_msi { /* MSI information */
> struct mutex lock; /* protect bitmap variable */
> struct irq_domain *msi_domain;
> @@ -145,15 +150,119 @@ struct mobiveil_pcie {
> struct mobiveil_msi msi;
> };
>
> -static inline void csr_writel(struct mobiveil_pcie *pcie, const u32 value,
> - const u32 reg)
> +/*
> + * mobiveil_pcie_sel_page - routine to access paged register
> + *
> + * Registers whose address greater than PAGED_ADDR_BNDRY (0xc00) are paged,
> + * for this scheme to work extracted higher 6 bits of the offset will be
> + * written to pg_sel field of PAB_CTRL register and rest of the lower 10
> + * bits enabled with PAGED_ADDR_BNDRY are used as offset of the register.
> + */
> +static void mobiveil_pcie_sel_page(struct mobiveil_pcie *pcie, u8 pg_idx)
> {
> - writel_relaxed(value, pcie->csr_axi_slave_base + reg);
> + u32 val;
> +
> + val = readl(pcie->csr_axi_slave_base + PAB_CTRL);
> + val &= ~(PAGE_SEL_MASK << PAGE_SEL_SHIFT);
> + val |= (pg_idx & PAGE_SEL_MASK) << PAGE_SEL_SHIFT;
> +
> + writel(val, pcie->csr_axi_slave_base + PAB_CTRL);
> }
>
> -static inline u32 csr_readl(struct mobiveil_pcie *pcie, const u32 reg)
> +static void *mobiveil_pcie_comp_addr(struct mobiveil_pcie *pcie, u32 off)
> {
> - return readl_relaxed(pcie->csr_axi_slave_base + reg);
> + if (off < PAGED_ADDR_BNDRY) {
> + /* For directly accessed registers, clear the pg_sel field */
> + mobiveil_pcie_sel_page(pcie, 0);
> + return pcie->csr_axi_slave_base + off;
> + }
> +
> + mobiveil_pcie_sel_page(pcie, OFFSET_TO_PAGE_IDX(off));
> + return pcie->csr_axi_slave_base + OFFSET_TO_PAGE_ADDR(off);
> +}
> +
> +static int mobiveil_pcie_read(void __iomem *addr, int size, u32 *val)
> +{
> + if ((uintptr_t)addr & (size - 1)) {
> + *val = 0;
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> + }
> +
> + switch (size) {
> + case 4:
> + *val = readl(addr);
> + break;
> + case 2:
> + *val = readw(addr);
> + break;
> + case 1:
> + *val = readb(addr);
> + break;
> + default:
> + *val = 0;
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> + }
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static int mobiveil_pcie_write(void __iomem *addr, int size, u32 val)
> +{
> + if ((uintptr_t)addr & (size - 1))
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> +
> + switch (size) {
> + case 4:
> + writel(val, addr);
> + break;
> + case 2:
> + writew(val, addr);
> + break;
> + case 1:
> + writeb(val, addr);
> + break;
> + default:
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> + }
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static u32 csr_read(struct mobiveil_pcie *pcie, u32 off, size_t size)
> +{
> + void *addr;
> + u32 val;
> + int ret;
> +
> + addr = mobiveil_pcie_comp_addr(pcie, off);
> +
> + ret = mobiveil_pcie_read(addr, size, );
> + if (ret)
> + dev_err(>pdev->dev, "read CSR address failed\n");
> +
> + return
linux-next: manual merge of the akpm-current tree with the net tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
net/sctp/stream.c
between commit:
cfe4bd7a257f ("sctp: check and update stream->out_curr when allocating
stream_out")
from the net tree and commit:
2bd3fbb3ff23 ("sctp: convert to genradix")
from the akpm-current tree.
I fixed it up (the latter removed the code modified by the former, so I
did that) and can carry the fix as necessary. This is now fixed as far as
linux-next is concerned, but any non trivial conflicts should be mentioned
to your upstream maintainer when your tree is submitted for merging.
You may also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
pgpvoUQvkwLGl.pgp
Description: OpenPGP digital signature
Re: [PATCH v3 5/5] Revert "scsi: ufs: disable vccq if it's not needed by UFS device"
Hi Marc,
On 04/02/19 11:12 PM, Marc Gonzalez wrote:
> This reverts commit 60f0187031c05e04cbadffb62f557d0ff3564490.
>
> Calling ufshcd_set_vccq_rail_unused hangs my system.
> It seems vccq is not *not* needed.
>
> Signed-off-by: Marc Gonzalez
> ---
AFAIK Samsung and Toshiba UFS devices does not use VCCQ (this pin is
either floating or connected to Ground, at least on the devices that I
have worked on).
You said your system hanged, I believe you have set UFS_DEVICE_NO_VCCQ
quirks, in that case VCCQ regulator should having been disabled.
So you mean your system hanged because vccq regulator got disabled?
> drivers/scsi/ufs/ufs.h| 1 -
> drivers/scsi/ufs/ufshcd.c | 59 +++
> 2 files changed, 4 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
> index dd65fea07687..7da7318eb6a6 100644
> --- a/drivers/scsi/ufs/ufs.h
> +++ b/drivers/scsi/ufs/ufs.h
> @@ -514,7 +514,6 @@ struct ufs_vreg {
> struct regulator *reg;
> const char *name;
> bool enabled;
> - bool unused;
> int min_uV;
> int max_uV;
> int min_uA;
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 9ba7671b84f8..8b9a01073d62 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -245,7 +245,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba);
> static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
>bool skip_ref_clk);
> static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
> -static int ufshcd_set_vccq_rail_unused(struct ufs_hba *hba, bool unused);
> static int ufshcd_uic_hibern8_exit(struct ufs_hba *hba);
> static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
> static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
> @@ -6819,11 +6818,6 @@ static int ufshcd_probe_hba(struct ufs_hba *hba)
> ufs_fixup_device_setup(hba, );
> ufshcd_tune_unipro_params(hba);
>
> - ret = ufshcd_set_vccq_rail_unused(hba,
> - (hba->dev_quirks & UFS_DEVICE_NO_VCCQ) ? true : false);
> - if (ret)
> - goto out;
> -
> /* UFS device is also active now */
> ufshcd_set_ufs_dev_active(hba);
> ufshcd_force_reset_auto_bkops(hba);
> @@ -7007,24 +7001,13 @@ static int ufshcd_config_vreg_load(struct device
> *dev, struct ufs_vreg *vreg,
> static inline int ufshcd_config_vreg_lpm(struct ufs_hba *hba,
>struct ufs_vreg *vreg)
> {
> - if (!vreg)
> - return 0;
> - else if (vreg->unused)
> - return 0;
> - else
> - return ufshcd_config_vreg_load(hba->dev, vreg,
> -UFS_VREG_LPM_LOAD_UA);
> + return ufshcd_config_vreg_load(hba->dev, vreg, UFS_VREG_LPM_LOAD_UA);
> }
>
> static inline int ufshcd_config_vreg_hpm(struct ufs_hba *hba,
>struct ufs_vreg *vreg)
> {
> - if (!vreg)
> - return 0;
> - else if (vreg->unused)
> - return 0;
> - else
> - return ufshcd_config_vreg_load(hba->dev, vreg, vreg->max_uA);
> + return ufshcd_config_vreg_load(hba->dev, vreg, vreg->max_uA);
> }
>
> static int ufshcd_config_vreg(struct device *dev,
> @@ -7062,9 +7045,7 @@ static int ufshcd_enable_vreg(struct device *dev,
> struct ufs_vreg *vreg)
> {
> int ret = 0;
>
> - if (!vreg)
> - goto out;
> - else if (vreg->enabled || vreg->unused)
> + if (!vreg || vreg->enabled)
> goto out;
>
> ret = ufshcd_config_vreg(dev, vreg, true);
> @@ -7084,9 +7065,7 @@ static int ufshcd_disable_vreg(struct device *dev,
> struct ufs_vreg *vreg)
> {
> int ret = 0;
>
> - if (!vreg)
> - goto out;
> - else if (!vreg->enabled || vreg->unused)
> + if (!vreg || !vreg->enabled)
> goto out;
>
> ret = regulator_disable(vreg->reg);
> @@ -7192,36 +7171,6 @@ static int ufshcd_init_hba_vreg(struct ufs_hba *hba)
> return 0;
> }
>
> -static int ufshcd_set_vccq_rail_unused(struct ufs_hba *hba, bool unused)
> -{
> - int ret = 0;
> - struct ufs_vreg_info *info = >vreg_info;
> -
> - if (!info)
> - goto out;
> - else if (!info->vccq)
> - goto out;
> -
> - if (unused) {
> - /* shut off the rail here */
> - ret = ufshcd_toggle_vreg(hba->dev, info->vccq, false);
> - /*
> - * Mark this rail as no longer used, so it doesn't get enabled
> - * later by mistake
> - */
> - if (!ret)
> - info->vccq->unused = true;
> - } else {
> - /*
> - * rail should have been already enabled hence just make sure
> - * that unused flag is cleared.
> - */
> -
Re: [REGRESSION 4.20-rc1] 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds")
On Tue, Nov 13, 2018 at 03:54:53PM +0200, Ville Syrjälä wrote:
> Hi Paul,
> After 4.20-rc1 some of my 32bit UP machines no longer reboot/shutdown.
> I bisected this down to commit 45975c7d21a1 ("rcu: Define RCU-sched
> API in terms of RCU for Tree RCU PREEMPT builds").
>
> I traced the hang into
> -> cpufreq_suspend()
> -> cpufreq_stop_governor()
> -> cpufreq_dbs_governor_stop()
>-> gov_clear_update_util()
> -> synchronize_sched()
> -> synchronize_rcu()
>
> Only PREEMPT=y is affected for obvious reasons, but that couldn't
> explain why the same UP kernel booted on an SMP machine worked fine.
> Eventually I realized that the difference between working and
> non-working machine was IOAPIC vs. PIC. With initcall_debug I saw
> that we mask everything in the PIC before cpufreq is shut down,
Hello Paul & Ville.
I'm not a kernel hacker, just a n00b playing with various non-x86
systems, but I've been forced getting into kernel hacking due to
the same issue.
Since February, I'm working on porting some trivial out-of-tree
drivers to the upstream, and noticed my Yeeloong 8089D, a machine running
the Loongson 2F 64-bit MIPS-III processor, will completely hang during
reboot or shutdown. I tried bisecting it for 24 hours without sleep, but
the attempt had failed.
I managed to narrow it in-between 4.19 and 4.20, most unusual thing I've
observed was its probabilistic nature. The chance of triggering it seems
getting progressively higher since 4.20, making pinpointing the specific
commit difficult, finally with a 100% chance since Linux 4.19.
I initially suspected a bug in the platform driver, later I also tried
to disable various kernel hardening options, all without success. At this
point I've realized, because it has shown to be probabilistic, it must be
a race condition, and since it's an uniprocessor system, it must be the
CPU scheduler getting preempted somehow. Disabling CONFIG_PREEMPT makes
the issue go away. I tried to add various preempt_disable() in the platform
driver but didn't work.
Finally I've hooked up a netconsole and started adding printk()s.
[ 23.652000] loongson2_cpufreq loongson2_cpufreq: shutdown
[ 23.656000] loongson-gpio loongson-gpio: shutdown
[ 23.66] migrate_to_reboot_cpu()
[ 23.664000] syscore_shutdown()
[ 23.668000] PM: Calling i8259A_shutdown+0x0/0xa8
[ 23.672000] PM: Calling irq_gc_shutdown+0x0/0x88
[ 23.672000] PM: Calling cpufreq_suspend+0x0/0x1a0
[ 23.672000] cpufreq_suspend()
[ 23.672000] cpufreq_suspend: Suspending Governors
[ 23.672000] cpufreq_stop_governor()
[ 23.672000] cpufreq_stop_governor: for CPU 0
Looks like something in the core cpufreq code? So I tried searching
"cpufreq_stop_governor()" at LKML... Oops!
So it must be the same issue. To summary, the issue exists on all Linux
kernels since 4.20-rc1, and the chance of triggering it, is now 100%.
What is the current progress of purposed solutions? If a complete solution
is still work-in-progress, could we simply submit a hotfix into the linux-stable
trees, so at least the issue can be temporarily solved? What can I do to help
testing?
Thanks!
Tom Li
Re: [PATCH 0/8 v5] k3dma patches to add support for hi3660/HiKey960
On 04-02-19, 11:15, John Stultz wrote: > On Mon, Feb 4, 2019 at 1:03 AM Vinod Koul wrote: > > > > On 24-01-19, 12:24, John Stultz wrote: > > > This patch series is based on recent work by Tanglei Han, and > > > adds support for hi3660 SoCs as found on the HiKey960 board, > > > along with a few patches I've been carrying. > > > > Applied and fixed the minor style issues in patch 5, and retagged 3 thru > > 5 to dmaengine: xxx, thanks > > My apologies for the style mistake. Your help is very much appreciated > here! Thanks so much again! No issues it was a minor one so didnt warrant a respin! > > Just to clarify, are you planning on taking the reviewed binding > documents (patches 1&2) via your tree? yes sorry I should have clarified since this is multi-subsystem series. I have applied 1 thru 5 that includes DT binding. I do that typically for dmaengine driver patches with Rob's ack. Thanks -- ~Vinod
[PATCH v2 2/2] PCI: iproc: Add PCIe 32bit outbound memory configuration
Add configuration to support IPROC PCIe host controller outbound memory
window mapping with SOC address range inside 4GB boundary, which is 32 bit
AXI address.
Signed-off-by: Srinath Mannam
Signed-off-by: Abhishek Shah
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Vikram Prakash
---
drivers/pci/controller/pcie-iproc.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index b882255..080f142 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie *pcie,
u64 axi_addr,
resource_size_t window_size =
ob_map->window_sizes[size_idx] * SZ_1M;
- if (size < window_size)
- continue;
+ /*
+* Keep iterating until we reach the last window and
+* with the minimal window size at index zero. In this
+* case, we take a compromise by mapping it using the
+* minimum window size that can be supported
+*/
+ if (size < window_size) {
+ if (size_idx > 0 || window_idx > 0)
+ continue;
+
+ /*
+* For the corner case of reaching the minimal
+* window size that can be supported on the
+* last window
+*/
+ axi_addr = ALIGN_DOWN(axi_addr, window_size);
+ pci_addr = ALIGN_DOWN(pci_addr, window_size);
+ size = window_size;
+ }
if (!IS_ALIGNED(axi_addr, window_size) ||
!IS_ALIGNED(pci_addr, window_size)) {
--
2.7.4
[PATCH v2 0/2] Add IPROC PCIe new features
This patch set extends support of new IPROC PCIe host controller features - Add CRS check using controller register status flags - Add 32bit outbound window mapping configuration This patch set is based on Linux-5.0-rc2. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed set order mode patch from patchset. Srinath Mannam (2): PCI: iproc: Add CRS check in config read PCI: iproc: Add PCIe 32bit outbound memory configuration drivers/pci/controller/pcie-iproc.c | 44 + 1 file changed, 40 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH v2 1/2] PCI: iproc: Add CRS check in config read
In the current implementation, config read output data 0x0001 is
assumed as CRS completion. But sometimes 0x0001 can be a valid data.
IPROC PCIe host controller has a register to show config read request
status flags like SC, UR, CRS and CA. So that extra check is added to
confirm the CRS using status flags before reissue config read.
Signed-off-by: Srinath Mannam
Reviewed-by: Ray Jui
---
drivers/pci/controller/pcie-iproc.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index c20fd6b..b882255 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -60,6 +60,10 @@
#define APB_ERR_EN_SHIFT 0
#define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
+#define CFG_RD_SUCCESS 0
+#define CFG_RD_UR 1
+#define CFG_RD_CRS 2
+#define CFG_RD_CA 3
#define CFG_RETRY_STATUS 0x0001
#define CFG_RETRY_STATUS_TIMEOUT_US50 /* 500 milliseconds */
@@ -289,6 +293,9 @@ enum iproc_pcie_reg {
IPROC_PCIE_IARR4,
IPROC_PCIE_IMAP4,
+ /* config read status */
+ IPROC_PCIE_CFG_RD_STATUS,
+
/* link status */
IPROC_PCIE_LINK_STATUS,
@@ -350,6 +357,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_IMAP3] = 0xe08,
[IPROC_PCIE_IARR4] = 0xe68,
[IPROC_PCIE_IMAP4] = 0xe70,
+ [IPROC_PCIE_CFG_RD_STATUS] = 0xee0,
[IPROC_PCIE_LINK_STATUS]= 0xf0c,
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
};
@@ -474,10 +482,12 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct
iproc_pcie *pcie,
return (pcie->base + offset);
}
-static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
+void __iomem *cfg_data_p)
{
int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
unsigned int data;
+ u32 status;
/*
* As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
@@ -498,6 +508,15 @@ static unsigned int iproc_pcie_cfg_retry(void __iomem
*cfg_data_p)
*/
data = readl(cfg_data_p);
while (data == CFG_RETRY_STATUS && timeout--) {
+ /*
+* CRS state is set in CFG_RD status register
+* This will handle the case where CFG_RETRY_STATUS is
+* valid config data.
+*/
+ status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
+ if (status != CFG_RD_CRS)
+ return data;
+
udelay(1);
data = readl(cfg_data_p);
}
@@ -576,7 +595,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus,
unsigned int devfn,
if (!cfg_data_p)
return PCIBIOS_DEVICE_NOT_FOUND;
- data = iproc_pcie_cfg_retry(cfg_data_p);
+ data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
*val = data;
if (size <= 2)
--
2.7.4
[PATCH v2 0/2] Add IPROC PCIe new features
This patch set extends support of new IPROC PCIe host controller features - Add CRS state check using controller register status flags - Add 32bit outbound window mapping configuration This patch set is based on Linux-5.0-rc2. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed set order mode patch from patchset. Srinath Mannam (2): PCI: iproc: Add CRS state check in config read PCI: iproc: Add PCIe 32bit outbound memory configuration drivers/pci/controller/pcie-iproc.c | 44 + 1 file changed, 40 insertions(+), 4 deletions(-) -- 2.7.4
Re: [PATCH v4 0/5] Register an Energy Model for Arm reference platforms
On 04-02-19, 11:09, Quentin Perret wrote: > The Energy Model (EM) framework feeds interested subsystems (the > scheduler/EAS as of now) with power costs provided by drivers. Yet, no > driver is actually doing that upstream yet. This series updates a set of > CPUFreq drivers in order to register power costs in the EM framework for > some of the Arm reference platforms for EAS: Hikey960, Juno and TC2. > > The series is split as follows: > - Patch 01 introduces in PM_OPP a helper function which estimates the >CPU power using the P=CV²f equation also used by IPA. It should be >noted that this introduces duplicate code with IPA, which will >eventually be fixed by migrating IPA to using PM_EM. The ideal plan >would be to do so later, in a separate patch series. I would indeed >prefer to keep the thermal and CPUFreq discussion separate at this >stage, if deemed acceptable. > - Patches 02-04 make use of that PM_OPP helper function from the >following CPUFreq drivers: cpufreq-dt, scpi-cpufreq and >arm_big_little. > - Patch 05 modifies the SCMI cpufreq driver to pass the power costs >obtained from firmware to PM_EM. This patch is independent from the >rest of the series. > > > Changes since v3 (20190201093101.31869-1-quentin.per...@arm.com) > - Moved the OPP count inside dev_pm_opp_of_register_em() (Matthias, >Sudeep) Applied. Thanks. -- viresh
Re: [PATCH REGRESSION] Revert "ath10k: add quiet mode support for QCA6174/QCA9377"
Brian Norris writes:
> On Mon, Feb 4, 2019 at 8:43 AM Kalle Valo wrote:
>> Brian Norris wrote:
>>
>> > This reverts commit cfb353c0dc058bc1619cc226d3cbbda1f360bdd3.
>> >
>> > WCN3990 firmware does not yet implement this feature, and so it crashes
>> > like this:
>> >
>> > fatal error received: err_qdi.c:456:EX:wlan_process:1:WLAN
>> > RT:207a:PC=b001b4f0
>> >
>> > This feature can be re-implemented with a proper service bitmap or other
>> > feature-discovery mechanism in the future. But it should not break
>> > working boards.
>> >
>> > Fixes: cfb353c0dc05 ("ath10k: add quiet mode support for QCA6174/QCA9377")
>> > Cc: Yu Wang
>> > Cc: Rakesh Pillai
>> > Cc: Govind Singh
>> > Cc:
>> > Signed-off-by: Brian Norris
>>
>> This regression should be fixed by (which is in v4.20):
>>
>> 53884577fbce ath10k: skip sending quiet mode cmd for WCN3990
>>
>> So this revert should not be needed anymore and I'll drop this.
>
> Yes, that seems to work for me. I'll probably replace the revert with
> the above in my downstream. Thanks!
>
> Can't really be fixed now, but it would have been nice to have a Fixes
> tag on that one.
Indeed. Sorry, missed that.
--
Kalle Valo
Re: perf_event_open+clone = unkillable process
ebied...@xmission.com (Eric W. Biederman) writes: > Thomas Gleixner writes: > >> On Mon, 4 Feb 2019, Dmitry Vyukov wrote: >> >>> On Mon, Feb 4, 2019 at 10:27 AM Thomas Gleixner wrote: >>> > >>> > On Fri, 1 Feb 2019, Dmitry Vyukov wrote: >>> > >>> > > On Fri, Feb 1, 2019 at 5:48 PM Dmitry Vyukov wrote: >>> > > > >>> > > > Hello, >>> > > > >>> > > > The following program creates an unkillable process that eats CPU. >>> > > > /proc/pid/stack is empty, I am not sure what other info I can provide. >>> > > > >>> > > > Tested is on upstream commit 4aa9fc2a435abe95a1e8d7f8c7b3d6356514b37a. >>> > > > Config is attached. >>> > > >>> > > Looking through other reproducers that create unkillable processes, I >>> > > think I found a much simpler reproducer (below). It's single threaded >>> > > and just setups SIGBUS handler and does timer_create+timer_settime to >>> > > send repeated SIGBUS. The resulting process can't be killed with >>> > > SIGKILL. >>> > > +Thomas for timers. >>> > >>> > +Oleg, Eric >>> > >>> > That's odd. With some tracing I can see that SIGKILL is generated and >>> > queued, but its not delivered by some weird reason. I'm traveling in the >>> > next days, so I won't be able to do much about it. Will look later this >>> > week. >>> >>> Just a random though looking at the repro: can constant SIGBUS >>> delivery starve delivery of all other signals (incl SIGKILL)? >> >> Indeed. SIGBUS is 7, SIGKILL is 9 and next_signal() delivers the lowest >> number first > > We do have the special case in complete_signal that causes most of the > signal delivery work of SIGKILL to happen when SIGKILL is queued. > > I need to look at your reproducer. It would require being a per-thread > signal to cause problems in next_signal. > > It is definitely worth fixing if there is any way for userspace to block > SIGKILL. Ugh. The practical problem appears much worse. Tracing the code I see that we attempt to deliver SIGBUS, I presume in a per thread way. At some point the delivery of SIGBUS fails. Then the kernel attempts to synchronously force SIGSEGV. Which should be the end of it. Unfortunately at that point our heuristic for dealing with syncrhonous signals fails in next_signal and we attempt to deliver the timers SIGBUS instead. I suspect it is time to byte the bullet and handle the synchronous unblockable signals differently. I will see if I can cook up an appropriate patch. Eric
Re: mmotm 2019-02-04-17-47 uploaded (fs/binfmt_elf.c)
On 2/4/19 5:48 PM, a...@linux-foundation.org wrote: > The mm-of-the-moment snapshot 2019-02-04-17-47 has been uploaded to > >http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once a week. > > You will need quilt to apply these patches to the latest Linus release (4.x > or 4.x-rcY). The series file is in broken-out.tar.gz and is duplicated in > http://ozlabs.org/~akpm/mmotm/series on x86_64 UML: (although should be many places) ../fs/binfmt_elf.c: In function ‘write_note_info’: ../fs/binfmt_elf.c:2122:19: error: ‘tmp’ undeclared (first use in this function) for (i = 0; i < tmp->num_notes; i++) ^ -- ~Randy
Re: [RFC][Patch v8 1/7] KVM: Support for guest free page hinting
On Mon, Feb 04, 2019 at 03:18:48PM -0500, Nitesh Narayan Lal wrote:
> This patch includes the following:
> 1. Basic skeleton for the support
> 2. Enablement of x86 platform to use the same
>
> Signed-off-by: Nitesh Narayan Lal
> ---
> arch/x86/Kbuild | 2 +-
> arch/x86/kvm/Kconfig | 8
> arch/x86/kvm/Makefile| 2 ++
> include/linux/gfp.h | 9 +
> include/linux/page_hinting.h | 17 +
> virt/kvm/page_hinting.c | 36
> 6 files changed, 73 insertions(+), 1 deletion(-)
> create mode 100644 include/linux/page_hinting.h
> create mode 100644 virt/kvm/page_hinting.c
>
> diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
> index c625f57472f7..3244df4ee311 100644
> --- a/arch/x86/Kbuild
> +++ b/arch/x86/Kbuild
> @@ -2,7 +2,7 @@ obj-y += entry/
>
> obj-$(CONFIG_PERF_EVENTS) += events/
>
> -obj-$(CONFIG_KVM) += kvm/
> +obj-$(subst m,y,$(CONFIG_KVM)) += kvm/
>
> # Xen paravirtualization support
> obj-$(CONFIG_XEN) += xen/
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 72fa955f4a15..2fae31459706 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -96,6 +96,14 @@ config KVM_MMU_AUDIT
>This option adds a R/W kVM module parameter 'mmu_audit', which allows
>auditing of KVM MMU events at runtime.
>
> +# KVM_FREE_PAGE_HINTING will allow the guest to report the free pages to the
> +# host in regular interval of time.
> +config KVM_FREE_PAGE_HINTING
> + def_bool y
> + depends on KVM
> + select VIRTIO
> + select VIRTIO_BALLOON
> +
> # OK, it's a little counter-intuitive to do this, but it puts it neatly under
> # the virtualization menu.
> source "drivers/vhost/Kconfig"
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index 69b3a7c30013..78640a80501e 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -16,6 +16,8 @@ kvm-y += x86.o mmu.o emulate.o
> i8259.o irq.o lapic.o \
> i8254.o ioapic.o irq_comm.o cpuid.o pmu.o mtrr.o \
> hyperv.o page_track.o debugfs.o
>
> +obj-$(CONFIG_KVM_FREE_PAGE_HINTING)+= $(KVM)/page_hinting.o
> +
> kvm-intel-y += vmx/vmx.o vmx/vmenter.o vmx/pmu_intel.o vmx/vmcs12.o
> vmx/evmcs.o vmx/nested.o
> kvm-amd-y+= svm.o pmu_amd.o
>
> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> index 5f5e25fd6149..e596527284ba 100644
> --- a/include/linux/gfp.h
> +++ b/include/linux/gfp.h
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
>
> struct vm_area_struct;
>
> @@ -456,6 +457,14 @@ static inline struct zonelist *node_zonelist(int nid,
> gfp_t flags)
> return NODE_DATA(nid)->node_zonelists + gfp_zonelist(flags);
> }
>
> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
> +#define HAVE_ARCH_FREE_PAGE
> +static inline void arch_free_page(struct page *page, int order)
> +{
> + guest_free_page(page, order);
> +}
> +#endif
> +
> #ifndef HAVE_ARCH_FREE_PAGE
> static inline void arch_free_page(struct page *page, int order) { }
> #endif
OK so arch_free_page hook is used to tie into mm code,
with follow-up patches the pages get queued in a list
and then sent to hypervisor so it can free them.
Fair enough but how do we know the page is
not reused by the time it's received by the hypervisor?
If it's reused then isn't it a problem that
hypervisor calls MADV_DONTNEED on them?
> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
> new file mode 100644
> index ..b54f7428f348
> --- /dev/null
> +++ b/include/linux/page_hinting.h
> @@ -0,0 +1,17 @@
> +/*
> + * Size of the array which is used to store the freed pages is defined by
> + * MAX_FGPT_ENTRIES. If possible, we have to find a better way using which
> + * we can get rid of the hardcoded array size.
> + */
> +#define MAX_FGPT_ENTRIES 1000
> +/*
> + * hypervisor_pages - It is a dummy structure passed with the hypercall.
> + * @pfn: page frame number for the page which needs to be sent to the host.
> + * @order: order of the page needs to be reported to the host.
> + */
> +struct hypervisor_pages {
> + unsigned long pfn;
> + unsigned int order;
> +};
> +
> +void guest_free_page(struct page *page, int order);
> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
> new file mode 100644
> index ..818bd6b84e0c
> --- /dev/null
> +++ b/virt/kvm/page_hinting.c
> @@ -0,0 +1,36 @@
> +#include
> +#include
> +#include
> +
> +/*
> + * struct kvm_free_pages - Tracks the pages which are freed by the guest.
> + * @pfn: page frame number for the page which is freed.
> + * @order: order corresponding to the page freed.
> + * @zonenum: zone number to which the freed page belongs.
> + */
> +struct kvm_free_pages {
> + unsigned long pfn;
> + unsigned int order;
> + int zonenum;
> +};
> +
> +/*
> + * struct page_hinting - holds
Re: [PATCH v2 0/3] slub: Do trivial comments fixes
On Mon, Feb 04, 2019 at 03:04:10PM -0800, Andrew Morton wrote: > On Mon, 4 Feb 2019 11:57:10 +1100 "Tobin C. Harding" > wrote: > > > Here is v2 of the comments fixes [to single SLUB header file] > > Thanks. I think I'll put these into a single patch. Awesome, thank you.
Re: [v3 PATCH 1/2] PCI: read fixed bus numbers in EA for type 1 functions
Hi Bjorn,
Any comments?
Thanks,
Sundeep
On Wed, Jan 23, 2019 at 6:48 PM wrote:
>
> From: Subbaraya Sundeep
>
> As per the spec - ECN_Enhanced_Allocation_23_Oct_2014_Final
> and section 6.9.1.2, EA capability contains fixed secondary
> and subordinate bus numbers for type 1 functions.
> This patch adds support to read the fixed bus numbers
> from EA capability for bridge.
>
> Signed-off-by: Subbaraya Sundeep
> ---
> v3:
> As per Bjorn's suggestion placed EA stuff in pci_ea_init and
> captured bus numbers in pci_dev
> v2:
> None just added Sean
>
> drivers/pci/pci.c | 10 --
> include/linux/pci.h | 4
> include/uapi/linux/pci_regs.h | 4
> 3 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index c25acac..484b63e 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2909,6 +2909,7 @@ void pci_ea_init(struct pci_dev *dev)
> u8 num_ent;
> int offset;
> int i;
> + u32 dw;
>
> /* find PCI EA capability in list */
> ea = pci_find_capability(dev, PCI_CAP_ID_EA);
> @@ -2922,9 +2923,14 @@ void pci_ea_init(struct pci_dev *dev)
>
> offset = ea + PCI_EA_FIRST_ENT;
>
> - /* Skip DWORD 2 for type 1 functions */
> - if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE)
> + /* Note fixed bus numbers for type 1 functions */
> + if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> + pci_read_config_dword(dev, offset, );
> + dev->fixed_sec_busnr = dw & PCI_EA_FIXED_SEC_BUS;
> + dev->fixed_sub_busnr = (dw & PCI_EA_FIXED_SUB_BUS) >>
> + PCI_EA_FIXED_SUB_SHIFT;
> offset += 4;
> + }
>
> /* parse each EA entry */
> for (i = 0; i < num_ent; ++i)
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 65f1d8c..3e9a3ae 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -459,6 +459,10 @@ struct pci_dev {
> char*driver_override; /* Driver name to force a match */
>
> unsigned long priv_flags; /* Private flags for the PCI driver */
> +
> + /* bus numbers from EA capability if this device is a bridge */
> + u8 fixed_sec_busnr; /* Fixed Secondary Bus number */
> + u8 fixed_sub_busnr; /* Fixed Subordinate Bus number */
> };
>
> static inline struct pci_dev *pci_physfn(struct pci_dev *dev)
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index e1e9888..51e9ac0 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -372,6 +372,10 @@
> #define PCI_EA_FIRST_ENT_BRIDGE8 /* First EA Entry for Bridges
> */
> #define PCI_EA_ES 0x0007 /* Entry Size */
> #define PCI_EA_BEI0x00f0 /* BAR Equivalent Indicator */
> +/* Fixed Secondary and Subordinate bus numbers in EA for Bridge */
> +#define PCI_EA_FIXED_SEC_BUS 0xff
> +#define PCI_EA_FIXED_SUB_BUS 0xff00
> +#define PCI_EA_FIXED_SUB_SHIFT 8
> /* 0-5 map to BARs 0-5 respectively */
> #define PCI_EA_BEI_BAR0 0
> #define PCI_EA_BEI_BAR5 5
> --
> 1.8.3.1
>
[PATCH v3 3/4] memory: jz4780-nemc: Reduce size of const array
The maximum value found in that array is 15, there's no need to store
these values as uint32_t, a uint8_t is enough.
Signed-off-by: Paul Cercueil
---
v2: Remove casts to uint32_t
v3: No change
drivers/memory/jz4780-nemc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/jz4780-nemc.c b/drivers/memory/jz4780-nemc.c
index bcf06adefc96..66b8b43eaeff 100644
--- a/drivers/memory/jz4780-nemc.c
+++ b/drivers/memory/jz4780-nemc.c
@@ -161,7 +161,7 @@ static bool jz4780_nemc_configure_bank(struct jz4780_nemc
*nemc,
* Conversion of tBP and tAW cycle counts to values supported by the
* hardware (round up to the next supported value).
*/
- static const uint32_t convert_tBP_tAW[] = {
+ static const u8 convert_tBP_tAW[] = {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
/* 11 - 12 -> 12 cycles */
--
2.11.0
[PATCH v3 4/4] memory: jz4780_nemc: Add support for the JZ4740
Add support for the JZ4740 SoC from Ingenic.
Signed-off-by: Paul Cercueil
Reviewed-by: Boris Brezillon
---
v2: No change
v3: Support the JZ4740 instead of the JZ4725B (exact same functionality
but JZ4740 is already fully upstream)
drivers/memory/jz4780-nemc.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/memory/jz4780-nemc.c b/drivers/memory/jz4780-nemc.c
index 66b8b43eaeff..f3a19b9b76ac 100644
--- a/drivers/memory/jz4780-nemc.c
+++ b/drivers/memory/jz4780-nemc.c
@@ -44,9 +44,14 @@
#define NEMC_NFCSR_NFCEn(n)BITn) - 1) << 1) + 1)
#define NEMC_NFCSR_TNFEn(n)BIT(16 + (n) - 1)
+struct jz_soc_info {
+ u8 tas_tah_cycles_max;
+};
+
struct jz4780_nemc {
spinlock_t lock;
struct device *dev;
+ const struct jz_soc_info *soc_info;
void __iomem *base;
struct clk *clk;
uint32_t clk_period;
@@ -202,7 +207,7 @@ static bool jz4780_nemc_configure_bank(struct jz4780_nemc
*nemc,
if (of_property_read_u32(node, "ingenic,nemc-tAS", ) == 0) {
smcr &= ~NEMC_SMCR_TAS_MASK;
cycles = jz4780_nemc_ns_to_cycles(nemc, val);
- if (cycles > 15) {
+ if (cycles > nemc->soc_info->tas_tah_cycles_max) {
dev_err(nemc->dev, "tAS %u is too high (%u cycles)\n",
val, cycles);
return false;
@@ -214,7 +219,7 @@ static bool jz4780_nemc_configure_bank(struct jz4780_nemc
*nemc,
if (of_property_read_u32(node, "ingenic,nemc-tAH", ) == 0) {
smcr &= ~NEMC_SMCR_TAH_MASK;
cycles = jz4780_nemc_ns_to_cycles(nemc, val);
- if (cycles > 15) {
+ if (cycles > nemc->soc_info->tas_tah_cycles_max) {
dev_err(nemc->dev, "tAH %u is too high (%u cycles)\n",
val, cycles);
return false;
@@ -278,6 +283,10 @@ static int jz4780_nemc_probe(struct platform_device *pdev)
if (!nemc)
return -ENOMEM;
+ nemc->soc_info = device_get_match_data(dev);
+ if (!nemc->soc_info)
+ return -EINVAL;
+
spin_lock_init(>lock);
nemc->dev = dev;
@@ -370,8 +379,17 @@ static int jz4780_nemc_remove(struct platform_device *pdev)
return 0;
}
+static const struct jz_soc_info jz4740_soc_info = {
+ .tas_tah_cycles_max = 7,
+};
+
+static const struct jz_soc_info jz4780_soc_info = {
+ .tas_tah_cycles_max = 15,
+};
+
static const struct of_device_id jz4780_nemc_dt_match[] = {
- { .compatible = "ingenic,jz4780-nemc" },
+ { .compatible = "ingenic,jz4740-nemc", .data = _soc_info, },
+ { .compatible = "ingenic,jz4780-nemc", .data = _soc_info, },
{},
};
--
2.11.0
[PATCH v3 2/4] memory: Kconfig: Drop dependency on MACH_JZ4780 for jz4780
Depending on MACH_JZ4780 prevent us from creating a generic kernel that works on more than one MIPS board. Instead, we just depend on MIPS being set. Signed-off-by: Paul Cercueil Reviewed-by: Boris Brezillon --- v2: No change v3: No change drivers/memory/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig index 2d91b00e3591..3d411575fcb6 100644 --- a/drivers/memory/Kconfig +++ b/drivers/memory/Kconfig @@ -122,7 +122,7 @@ config FSL_IFC config JZ4780_NEMC bool "Ingenic JZ4780 SoC NEMC driver" default y - depends on MACH_JZ4780 || COMPILE_TEST + depends on MIPS || COMPILE_TEST depends on HAS_IOMEM && OF help This driver is for the NAND/External Memory Controller (NEMC) in -- 2.11.0
[PATCH v3 1/4] dt-bindings: memory: jz4780: Add compatible string for JZ4740 SoC
Add a compatible string to support the memory controller built into the JZ4740 SoC from Ingenic. Signed-off-by: Paul Cercueil Reviewed-by: Boris Brezillon Reviewed-by: Rob Herring --- v2: No change v3: Change compatible string for jz4740 instead of j4725b .../devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt b/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt index f936b5589b19..59b8dcc118ee 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt @@ -5,6 +5,7 @@ controller in Ingenic JZ4780 Required properties: - compatible: Should be set to one of: +"ingenic,jz4740-nemc" (JZ4740) "ingenic,jz4780-nemc" (JZ4780) - reg: Should specify the NEMC controller registers location and length. - clocks: Clock for the NEMC controller. -- 2.11.0
[PATCH v3 0/4] Ingenic JZ47xx NEMC patchset V3
Hi, Since the V2 of my patchset I could test it on the JZ4740, and see that the hardware is the exact same as on the JZ4725B. As the JZ4740 is already fully upstream, and also older, I now add support for the JZ4740 instead of the JZ4725B. The only patches modified since v2 are the 1/4 and 4/4, and the change is a dumb rename of '4725b' into '4740', so I kept the Reviewed-by: for these two. I hope it's OK. Cheers, -Paul
Re: [PATCH] powerpc/powernv/npu: Remove redundant change_pte() hook
On Thursday, 31 January 2019 12:11:06 PM AEDT Andrea Arcangeli wrote:
> On Thu, Jan 31, 2019 at 06:30:22PM +0800, Peter Xu wrote:
> > The change_pte() notifier was designed to use as a quick path to
> > update secondary MMU PTEs on write permission changes or PFN changes.
> > For KVM, it could reduce the vm-exits when vcpu faults on the pages
> > that was touched up by KSM. It's not used to do cache invalidations,
> > for example, if we see the notifier will be called before the real PTE
> > update after all (please see set_pte_at_notify that set_pte_at was
> > called later).
Thanks for the fixup. I didn't realise that invalidate_range() always gets
called but I now see that is the case so this change looks good to me as well.
Reviewed-by: Alistair Popple
> > All the necessary cache invalidation should all be done in
> > invalidate_range() already.
> >
> > CC: Benjamin Herrenschmidt
> > CC: Paul Mackerras
> > CC: Michael Ellerman
> > CC: Alistair Popple
> > CC: Alexey Kardashevskiy
> > CC: Mark Hairgrove
> > CC: Balbir Singh
> > CC: David Gibson
> > CC: Andrea Arcangeli
> > CC: Jerome Glisse
> > CC: Jason Wang
> > CC: linuxppc-...@lists.ozlabs.org
> > CC: linux-kernel@vger.kernel.org
> > Signed-off-by: Peter Xu
> > ---
> >
> > arch/powerpc/platforms/powernv/npu-dma.c | 10 --
> > 1 file changed, 10 deletions(-)
>
> Reviewed-by: Andrea Arcangeli
>
> It doesn't make sense to implement change_pte as an invalidate,
> change_pte is not compulsory to implement so if one wants to have
> invalidates only, change_pte method shouldn't be implemented in the
> first place and the common code will guarantee to invoke the range
> invalidates instead.
>
> Currently the whole change_pte optimization is effectively disabled as
> noted in past discussions with Jerome (because of the range
> invalidates that always surrounds it), so we need to revisit the whole
> change_pte logic and decide it to re-enable it or to drop it as a
> whole, but in the meantime it's good to cleanup spots like below that
> should leave change_pte alone.
>
> There are several examples of mmu_notifiers_ops in the kernel that
> don't implement change_pte, in fact it's the majority. Of all mmu
> notifier users, only nv_nmmu_notifier_ops, intel_mmuops_change and
> kvm_mmu_notifier_ops implements change_pte and as Peter found out by
> source review nv_nmmu_notifier_ops, intel_mmuops_change are wrong
> about it and should stop implementing it as an invalidate.
>
> In short change_pte is only implemented correctly from KVM which can
> really updates the spte and flushes the TLB but the spte update
> remains and could avoid a vmexit if we figure out how to re-enable the
> optimization safely (the TLB fill after change_pte in KVM EPT/shadow
> secondary MMU will be looked up by the CPU in hardware).
>
> If change_pte is implemented, it should update the mapping like KVM
> does and not do an invalidate.
>
> Thanks,
> Andrea
>
> > diff --git a/arch/powerpc/platforms/powernv/npu-dma.c
> > b/arch/powerpc/platforms/powernv/npu-dma.c index
> > 3f58c7dbd581..c003b29d870e 100644
> > --- a/arch/powerpc/platforms/powernv/npu-dma.c
> > +++ b/arch/powerpc/platforms/powernv/npu-dma.c
> > @@ -917,15 +917,6 @@ static void pnv_npu2_mn_release(struct mmu_notifier
> > *mn,>
> > mmio_invalidate(npu_context, 0, ~0UL);
> >
> > }
> >
> > -static void pnv_npu2_mn_change_pte(struct mmu_notifier *mn,
> > - struct mm_struct *mm,
> > - unsigned long address,
> > - pte_t pte)
> > -{
> > - struct npu_context *npu_context = mn_to_npu_context(mn);
> > - mmio_invalidate(npu_context, address, PAGE_SIZE);
> > -}
> > -
> >
> > static void pnv_npu2_mn_invalidate_range(struct mmu_notifier *mn,
> >
> > struct mm_struct *mm,
> > unsigned long start, unsigned long end)
> >
> > @@ -936,7 +927,6 @@ static void pnv_npu2_mn_invalidate_range(struct
> > mmu_notifier *mn,>
> > static const struct mmu_notifier_ops nv_nmmu_notifier_ops = {
> >
> > .release = pnv_npu2_mn_release,
> >
> > - .change_pte = pnv_npu2_mn_change_pte,
> >
> > .invalidate_range = pnv_npu2_mn_invalidate_range,
> >
> > };
Re: [PATCH 06/10] x86/cpu: Add Icelake to Intel family
On 04-Feb-19 11:04 PM, Thomas Gleixner wrote: On Fri, 1 Feb 2019, Rajneesh Bhardwaj wrote: Add CPUID of Icelake (ICL) mobile processors to Intel family list. The Information related to ICL CPUID is referenced from below Coreboot project link. https://github.com/coreboot/coreboot/blob/5ebcea33cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h Coreboot files are hardly authoritive information about CPUIDs. It may take a while for it to be published in the SDMs. diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 0dd6b0f4000e..12b65bdb3d80 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -52,6 +52,8 @@ #define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 +#define INTEL_FAM6_ICELAKE_MOBILE 0x7E Please use TABs instead of a random number of spaces. Sure, I will fix this. Thanks, tglx
Re: remove exofs, the T10 OSD code and block/scsi bidi support V4
Christoph, > The only real user of the T10 OSD protocol, the pNFS object layout > driver never went to the point of having shipping products, and we > removed it 1.5 years ago. Exofs is just a simple example without real > life users. > > The code has been mostly unmaintained for years and is getting in the > way of block / SCSI changes, and does not even work properly currently, > so I think it's finally time to drop it. Applied to 5.1/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 0/4] mpt3sas: Add Atlas and Ambrosia device support.
Suganath, > Posting below patches to include new devices Ambrosia, Atlas. Applied to 5.1/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH 3/3] locking/qspinlock: Introduce starvation avoidance into CNA
> On Jan 31, 2019, at 5:00 AM, Peter Zijlstra wrote: > > On Wed, Jan 30, 2019 at 10:01:35PM -0500, Alex Kogan wrote: >> Choose the next lock holder among spinning threads running on the same >> socket with high probability rather than always. With small probability, >> hand the lock to the first thread in the secondary queue or, if that >> queue is empty, to the immediate successor of the current lock holder >> in the main queue. Thus, assuming no failures while threads hold the >> lock, every thread would be able to acquire the lock after a bounded >> number of lock transitions, with high probability. >> >> Note that we could make the inter-socket transition deterministic, >> by sticking a counter of intra-socket transitions in the head node >> of the secondary queue. At the handoff time, we could increment >> the counter and check if it is below a threshold. This adds another >> field to queue nodes and nearly-certain local cache miss to read and >> update this counter during the handoff. While still beating stock, >> this variant adds certain overhead over the probabilistic variant. > > (also heavily suffers from the socket == node confusion) > > How would you suggest RT 'tunes' this? > > RT relies on FIFO fairness of the basic spinlock primitives; you just > completely wrecked that. This is true that CNA trades some fairness for shorter lock handover latency, much like any other NUMA-aware lock. Can you explain, however, what exactly breaks here? It seems that even today, qspinlock does not support RT_PREEMPT, given that it uses per-CPU queue nodes. Thank you, — Alex
Re: [PATCH][V2][next] regulator: axp20x: check rdev is null before dereferencing it
On Sat, Dec 22, 2018 at 7:32 PM Colin King wrote:
>
> From: Colin Ian King
>
> Currently rdev is dereferenced when assigning desc before rdev is null
> checked, hence there is a potential null pointer dereference on rdev.
> Fix this by null checking rdev first.
>
> Detected by CoverityScan, CID#1476031 ("Dereference before null check")
>
> Fixes: 77e3e3b165db ("regulator: axp20x: add software based soft_start for
> AXP209 LDO3")
> Signed-off-by: Colin Ian King
This patch somehow fell through the cracks. Sorry about that.
Both are really false positives. Both functions are callbacks for the
regulator core to use. If you look through the core code, rdev->desc->ops
is used to check for these callbacks before they are called. rdev is always
passed in, and rdev->desc is always valid after regulator_register.
ChenYu
> ---
>
> V2: Fix 2nd occurrance of this thinko
>
> ---
> drivers/regulator/axp20x-regulator.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/regulator/axp20x-regulator.c
> b/drivers/regulator/axp20x-regulator.c
> index 48af859fd053..0dfa4ea6bbdf 100644
> --- a/drivers/regulator/axp20x-regulator.c
> +++ b/drivers/regulator/axp20x-regulator.c
> @@ -367,7 +367,7 @@ static const int axp209_dcdc2_ldo3_slew_rates[] = {
> static int axp20x_set_ramp_delay(struct regulator_dev *rdev, int ramp)
> {
> struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
> - const struct regulator_desc *desc = rdev->desc;
> + const struct regulator_desc *desc;
> u8 reg, mask, enable, cfg = 0xff;
> const int *slew_rates;
> int rate_count = 0;
> @@ -375,6 +375,8 @@ static int axp20x_set_ramp_delay(struct regulator_dev
> *rdev, int ramp)
> if (!rdev)
> return -EINVAL;
>
> + desc = rdev->desc;
> +
> switch (axp20x->variant) {
> case AXP209_ID:
> if (desc->id == AXP20X_DCDC2) {
> @@ -436,11 +438,13 @@ static int axp20x_set_ramp_delay(struct regulator_dev
> *rdev, int ramp)
> static int axp20x_regulator_enable_regmap(struct regulator_dev *rdev)
> {
> struct axp20x_dev *axp20x = rdev_get_drvdata(rdev);
> - const struct regulator_desc *desc = rdev->desc;
> + const struct regulator_desc *desc;
>
> if (!rdev)
> return -EINVAL;
>
> + desc = rdev->desc;
> +
> switch (axp20x->variant) {
> case AXP209_ID:
> if ((desc->id == AXP20X_LDO3) &&
> --
> 2.19.1
>
Re: [PATCH for-next] scsi: ufs: Update dwc driver maintainer to Pedro Sousa
Joao, > Currently I am managing the Synopsys drivers & tools team (full-time) and > so I am passing the DWC UFS driver maintenance to Pedro Sousa. Applied to 5.1/scsi-queue, thanks. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH -next] hugetlbfs: a terminator for hugetlb_param_specs[]
On 2/4/19 5:22 PM, Qian Cai wrote:
> Booting up an arm64 server with CONFIG_VALIDATE_FS_PARSER=n triggers a
> out-of-bounds error below, due to the commit 2284cf59cbce ("hugetlbfs:
> Convert to fs_context") missed a terminator for hugetlb_param_specs[],
> and causes this loop in fs_lookup_key(),
>
> for (p = desc->specs; p->name; p++)
>
> could not exit properly due to p->name is never be NULL.
>
> [ 91.575203] BUG: KASAN: global-out-of-bounds in fs_lookup_key+0x60/0x94
> [ 91.581810] Read of size 8 at addr 200010deeb10 by task mount/2461
> [ 91.597350] Call trace:
> [ 91.597357] dump_backtrace+0x0/0x2b0
> [ 91.597361] show_stack+0x24/0x30
> [ 91.597373] dump_stack+0xc0/0xf8
> [ 91.623263] print_address_description+0x64/0x2b0
> [ 91.627965] kasan_report+0x150/0x1a4
> [ 91.627970] __asan_report_load8_noabort+0x30/0x3c
> [ 91.627974] fs_lookup_key+0x60/0x94
> [ 91.627977] fs_parse+0x104/0x990
> [ 91.627986] hugetlbfs_parse_param+0xc4/0x5e8
> [ 91.651081] vfs_parse_fs_param+0x2e4/0x378
> [ 91.658118] vfs_parse_fs_string+0xbc/0x12c
> [ 91.658122] do_mount+0x11f0/0x1640
> [ 91.658125] ksys_mount+0xc0/0xd0
> [ 91.658129] __arm64_sys_mount+0xcc/0xe4
> [ 91.658137] el0_svc_handler+0x28c/0x338
> [ 91.681740] el0_svc+0x8/0xc
>
> Fixes: 2284cf59cbce ("hugetlbfs: Convert to fs_context")
> Signed-off-by: Qian Cai
Thanks for fixing this. Looks like a simple oversight when 2284cf59cbce
was added.
Reviewed-by: Mike Kravetz
I just started looking at the new mount API now. It would be good if
David also took a look to make sure everything else is OK.
FYI David, the fs_parameter_spec example in the documentation (mount_api.txt)
is also missing a terminator.
--
Mike Kravetz
> ---
> fs/hugetlbfs/inode.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index abf0c2eb834e..4f352743930f 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -81,6 +81,7 @@ static const struct fs_parameter_spec hugetlb_param_specs[]
> = {
> fsparam_string("pagesize", Opt_pagesize),
> fsparam_string("size", Opt_size),
> fsparam_u32 ("uid", Opt_uid),
> + {}
> };
>
> static const struct fs_parameter_description hugetlb_fs_parameters = {
>
linux-next: build warnings after merge of the staging tree
Hi Greg,
After merging the staging tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
drivers/iio/chemical/sps30.c: In function 'sps30_read_raw':
drivers/iio/chemical/sps30.c:289:4: warning: this statement may fall through
[-Wimplicit-fallthrough=]
switch (chan->channel2) {
^~
drivers/iio/chemical/sps30.c:299:3: note: here
default:
^~~
drivers/iio/chemical/sps30.c: In function 'sps30_do_cmd':
drivers/iio/chemical/sps30.c:120:10: warning: this statement may fall through
[-Wimplicit-fallthrough=]
buf[1] = (u8)SPS30_AUTO_CLEANING_PERIOD;
^
drivers/iio/chemical/sps30.c:121:2: note: here
case SPS30_READ_DATA_READY_FLAG:
^~~~
Introduced by commits
232e0f6ddeae ("iio: chemical: add support for Sensirion SPS30 sensor")
62129a0849d2 ("iio: chemical: sps30: allow changing self cleaning period")
I get this warning because I am building with -Wimplicit-fallthrough
in attempt to catch new additions early. The gcc warning can be turned
off by adding a /* fall through */ comment at the point the fall through
happens (assuming that the fall through is intentional).
--
Cheers,
Stephen Rothwell
pgpT33P1MWZL4.pgp
Description: OpenPGP digital signature
Re: [PATCH] scsi: aacraid: clean up some indentation and formatting issues
Colin, > There are several issues with badly indented statements. Fix these and > clean up the formatting. Applied to 5.1/scsi-queue, thanks! -- Martin K. Petersen Oracle Linux Engineering
[PATCH 5/6] ASoC: codecs: Kconfig: Show knob, and depend on MIPS || COMPILE_TEST
Show the knob to enable or disable the jz4740-codec driver, add a proper description, and add a dependency on MIPS || COMPILE_TEST, as this driver is only useful on MIPS. Signed-off-by: Paul Cercueil --- sound/soc/codecs/Kconfig | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 62bdb7e333b8..2a6d3f86ca96 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -560,8 +560,15 @@ config SND_SOC_CX20442 depends on TTY config SND_SOC_JZ4740_CODEC + depends on MIPS || COMPILE_TEST select REGMAP_MMIO - tristate + tristate "Ingenic JZ4740 internal CODEC" + help + Enable support for the internal CODEC found in the JZ4740 SoC + from Ingenic. + + This driver can also be built as a module. If so, the module + will be called snd-soc-jz4740-codec. config SND_SOC_L3 tristate -- 2.11.0
[PATCH 6/6] ASoC: codecs: Add jz4725b-codec driver
Add jz4725b-codec driver to support the internal CODEC found in the
JZ4725B SoC from Ingenic.
Signed-off-by: Paul Cercueil
---
sound/soc/codecs/Kconfig | 12 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/jz4725b.c | 599 +
3 files changed, 613 insertions(+)
create mode 100644 sound/soc/codecs/jz4725b.c
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 2a6d3f86ca96..7b27b70d0a92 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -88,6 +88,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_INNO_RK3036
select SND_SOC_ISABELLE if I2C
select SND_SOC_JZ4740_CODEC
+ select SND_SOC_JZ4725B_CODEC
select SND_SOC_LM4857 if I2C
select SND_SOC_LM49453 if I2C
select SND_SOC_MAX98088 if I2C
@@ -570,6 +571,17 @@ config SND_SOC_JZ4740_CODEC
This driver can also be built as a module. If so, the module
will be called snd-soc-jz4740-codec.
+config SND_SOC_JZ4725B_CODEC
+ depends on MIPS || COMPILE_TEST
+ select REGMAP
+ tristate "Ingenic JZ4725B internal CODEC"
+ help
+ Enable support for the internal CODEC found in the JZ4725B SoC
+ from Ingenic.
+
+ This driver can also be built as a module. If so, the module
+ will be called snd-soc-jz4725b-codec.
+
config SND_SOC_L3
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 66f55d185620..5ea9eaff1817 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -84,6 +84,7 @@ snd-soc-ics43432-objs := ics43432.o
snd-soc-inno-rk3036-objs := inno_rk3036.o
snd-soc-isabelle-objs := isabelle.o
snd-soc-jz4740-codec-objs := jz4740.o
+snd-soc-jz4725b-codec-objs := jz4725b.o
snd-soc-l3-objs := l3.o
snd-soc-lm4857-objs := lm4857.o
snd-soc-lm49453-objs := lm49453.o
@@ -350,6 +351,7 @@ obj-$(CONFIG_SND_SOC_ICS43432) += snd-soc-ics43432.o
obj-$(CONFIG_SND_SOC_INNO_RK3036) += snd-soc-inno-rk3036.o
obj-$(CONFIG_SND_SOC_ISABELLE) += snd-soc-isabelle.o
obj-$(CONFIG_SND_SOC_JZ4740_CODEC) += snd-soc-jz4740-codec.o
+obj-$(CONFIG_SND_SOC_JZ4725B_CODEC)+= snd-soc-jz4725b-codec.o
obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o
obj-$(CONFIG_SND_SOC_LM4857) += snd-soc-lm4857.o
obj-$(CONFIG_SND_SOC_LM49453) += snd-soc-lm49453.o
diff --git a/sound/soc/codecs/jz4725b.c b/sound/soc/codecs/jz4725b.c
new file mode 100644
index ..e3dba92f30bd
--- /dev/null
+++ b/sound/soc/codecs/jz4725b.c
@@ -0,0 +1,599 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * JZ4725B CODEC driver
+ *
+ * Copyright (C) 2019, Paul Cercueil
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ICDC_RGADW_OFFSET 0x00
+#define ICDC_RGDATA_OFFSET 0x04
+
+/* ICDC internal register access control register(RGADW) */
+#define ICDC_RGADW_RGWRBIT(16)
+
+#define ICDC_RGADW_RGADDR_OFFSET 8
+#defineICDC_RGADW_RGADDR_MASK GENMASK(14,
ICDC_RGADW_RGADDR_OFFSET)
+
+#define ICDC_RGADW_RGDIN_OFFSET0
+#defineICDC_RGADW_RGDIN_MASK GENMASK(7,
ICDC_RGADW_RGDIN_OFFSET)
+
+/* ICDC internal register data output register (RGDATA)*/
+#define ICDC_RGDATA_IRQBIT(8)
+
+#define ICDC_RGDATA_RGDOUT_OFFSET 0
+#define ICDC_RGDATA_RGDOUT_MASKGENMASK(7,
ICDC_RGDATA_RGDOUT_OFFSET)
+
+/* JZ internal register space */
+enum {
+ JZ4725B_CODEC_REG_AICR,
+ JZ4725B_CODEC_REG_CR1,
+ JZ4725B_CODEC_REG_CR2,
+ JZ4725B_CODEC_REG_CCR1,
+ JZ4725B_CODEC_REG_CCR2,
+ JZ4725B_CODEC_REG_PMR1,
+ JZ4725B_CODEC_REG_PMR2,
+ JZ4725B_CODEC_REG_CRR,
+ JZ4725B_CODEC_REG_ICR,
+ JZ4725B_CODEC_REG_IFR,
+ JZ4725B_CODEC_REG_CGR1,
+ JZ4725B_CODEC_REG_CGR2,
+ JZ4725B_CODEC_REG_CGR3,
+ JZ4725B_CODEC_REG_CGR4,
+ JZ4725B_CODEC_REG_CGR5,
+ JZ4725B_CODEC_REG_CGR6,
+ JZ4725B_CODEC_REG_CGR7,
+ JZ4725B_CODEC_REG_CGR8,
+ JZ4725B_CODEC_REG_CGR9,
+ JZ4725B_CODEC_REG_CGR10,
+ JZ4725B_CODEC_REG_TR1,
+ JZ4725B_CODEC_REG_TR2,
+ JZ4725B_CODEC_REG_CR3,
+ JZ4725B_CODEC_REG_AGC1,
+ JZ4725B_CODEC_REG_AGC2,
+ JZ4725B_CODEC_REG_AGC3,
+ JZ4725B_CODEC_REG_AGC4,
+ JZ4725B_CODEC_REG_AGC5,
+};
+
+#define REG_AICR_CONFIG1_OFFSET0
+#define REG_AICR_CONFIG1_MASK (0xf << REG_AICR_CONFIG1_OFFSET)
+
+#define REG_CR1_SB_MICBIAS_OFFSET 7
+#define REG_CR1_MONO_OFFSET6
+#define REG_CR1_DAC_MUTE_OFFSET5
+#define REG_CR1_HP_DIS_OFFSET 4
+#define REG_CR1_DACSEL_OFFSET 3
+#define REG_CR1_BYPASS_OFFSET 2
+
+#define REG_CR2_DAC_DEEMP_OFFSET 7
+#define REG_CR2_DAC_ADWL_OFFSET5
[PATCH 3/6] ASoC: codecs: jz4740: Use SPDX license notifier
Add license information as a standard SPDX license notifier instead of custom text. Signed-off-by: Paul Cercueil --- sound/soc/codecs/jz4740.c | 12 +++- 1 file changed, 3 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/jz4740.c b/sound/soc/codecs/jz4740.c index 9395b583432c..af57a7d6ec12 100644 --- a/sound/soc/codecs/jz4740.c +++ b/sound/soc/codecs/jz4740.c @@ -1,14 +1,8 @@ +// SPDX-License-Identifier: GPL-2.0 /* - * Copyright (C) 2009-2010, Lars-Peter Clausen - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - * - * You should have received a copy of the GNU General Public License along - * with this program; if not, write to the Free Software Foundation, Inc., - * 675 Mass Ave, Cambridge, MA 02139, USA. + * JZ4740 CODEC driver * + * Copyright (C) 2009-2010, Lars-Peter Clausen */ #include -- 2.11.0
[PATCH 1/6] dt-bindings: sound: Document jz4740-codec bindings
Add documentation about how to probe the jz4740-codec driver from
devicetree.
Signed-off-by: Paul Cercueil
---
.../bindings/sound/ingenic,jz4740-codec.txt | 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/ingenic,jz4740-codec.txt
diff --git a/Documentation/devicetree/bindings/sound/ingenic,jz4740-codec.txt
b/Documentation/devicetree/bindings/sound/ingenic,jz4740-codec.txt
new file mode 100644
index ..1ffcade87e7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ingenic,jz4740-codec.txt
@@ -0,0 +1,20 @@
+Ingenic JZ4740 codec controller
+
+Required properties:
+- compatible : "ingenic,jz4740-codec"
+- reg : codec registers location and length
+- clocks : phandle to the AIC clock.
+- clock-names: must be set to "aic".
+- #sound-dai-cells: Must be set to 0.
+
+Example:
+
+codec: audio-codec@10020080 {
+ compatible = "ingenic,jz4740-codec";
+ reg = <0x10020080 0x8>;
+
+ #sound-dai-cells = <0>;
+
+ clocks = < JZ4740_CLK_AIC>;
+ clock-names = "aic";
+};
--
2.11.0
[PATCH 4/6] ASoC: codecs: jz4740: Add support for devicetree
Add support for probing the driver from devicetree.
Signed-off-by: Paul Cercueil
---
sound/soc/codecs/jz4740.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/sound/soc/codecs/jz4740.c b/sound/soc/codecs/jz4740.c
index af57a7d6ec12..b5a1323f0883 100644
--- a/sound/soc/codecs/jz4740.c
+++ b/sound/soc/codecs/jz4740.c
@@ -347,10 +347,19 @@ static int jz4740_codec_probe(struct platform_device
*pdev)
return ret;
}
+#ifdef CONFIG_OF
+static const struct of_device_id jz4740_codec_of_matches[] = {
+ { .compatible = "ingenic,jz4740-codec", },
+ { }
+};
+MODULE_DEVICE_TABLE(of, jz4740_codec_of_matches);
+#endif
+
static struct platform_driver jz4740_codec_driver = {
.probe = jz4740_codec_probe,
.driver = {
.name = "jz4740-codec",
+ .of_match_table = of_match_ptr(jz4740_codec_of_matches),
},
};
--
2.11.0
[PATCH 2/6] dt-bindings: sound: Document jz4725b-codec bindings
Add documentation about how to probe the jz4725b-codec driver from
devicetree.
Signed-off-by: Paul Cercueil
---
.../bindings/sound/ingenic,jz4725b-codec.txt | 20
1 file changed, 20 insertions(+)
create mode 100644
Documentation/devicetree/bindings/sound/ingenic,jz4725b-codec.txt
diff --git a/Documentation/devicetree/bindings/sound/ingenic,jz4725b-codec.txt
b/Documentation/devicetree/bindings/sound/ingenic,jz4725b-codec.txt
new file mode 100644
index ..05adc0d47b13
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ingenic,jz4725b-codec.txt
@@ -0,0 +1,20 @@
+Ingenic JZ4725B codec controller
+
+Required properties:
+- compatible : "ingenic,jz4725b-codec"
+- reg : codec registers location and length
+- clocks : phandle to the AIC clock.
+- clock-names: must be set to "aic".
+- #sound-dai-cells: Must be set to 0.
+
+Example:
+
+codec: audio-codec@100200a4 {
+ compatible = "ingenic,jz4725b-codec";
+ reg = <0x100200a4 0x8>;
+
+ #sound-dai-cells = <0>;
+
+ clocks = < JZ4725B_CLK_AIC>;
+ clock-names = "aic";
+};
--
2.11.0
Re: perf_event_open+clone = unkillable process
Thomas Gleixner writes: > On Mon, 4 Feb 2019, Dmitry Vyukov wrote: > >> On Mon, Feb 4, 2019 at 10:27 AM Thomas Gleixner wrote: >> > >> > On Fri, 1 Feb 2019, Dmitry Vyukov wrote: >> > >> > > On Fri, Feb 1, 2019 at 5:48 PM Dmitry Vyukov wrote: >> > > > >> > > > Hello, >> > > > >> > > > The following program creates an unkillable process that eats CPU. >> > > > /proc/pid/stack is empty, I am not sure what other info I can provide. >> > > > >> > > > Tested is on upstream commit 4aa9fc2a435abe95a1e8d7f8c7b3d6356514b37a. >> > > > Config is attached. >> > > >> > > Looking through other reproducers that create unkillable processes, I >> > > think I found a much simpler reproducer (below). It's single threaded >> > > and just setups SIGBUS handler and does timer_create+timer_settime to >> > > send repeated SIGBUS. The resulting process can't be killed with >> > > SIGKILL. >> > > +Thomas for timers. >> > >> > +Oleg, Eric >> > >> > That's odd. With some tracing I can see that SIGKILL is generated and >> > queued, but its not delivered by some weird reason. I'm traveling in the >> > next days, so I won't be able to do much about it. Will look later this >> > week. >> >> Just a random though looking at the repro: can constant SIGBUS >> delivery starve delivery of all other signals (incl SIGKILL)? > > Indeed. SIGBUS is 7, SIGKILL is 9 and next_signal() delivers the lowest > number first We do have the special case in complete_signal that causes most of the signal delivery work of SIGKILL to happen when SIGKILL is queued. I need to look at your reproducer. It would require being a per-thread signal to cause problems in next_signal. It is definitely worth fixing if there is any way for userspace to block SIGKILL. Eric
