REPLY FOR DETAILS!!

2018-09-28 Thread Ms CHIANG Lai Yuen JP
I will want you to partner me in a business...

---
This email has been checked for viruses by AVG.
https://www.avg.com



Re: [PATCH RT 2/2] watchdog, rt: prevent deferral of watchdogd wakeup

2018-09-28 Thread Thomas Gleixner
On Sat, 29 Sep 2018, kbuild test robot wrote:
> [also build test ERROR on v4.19-rc5 next-20180928]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 

It's against the RT tree, so it won't work against next or upstream. I
think it would be good to have a machine parseable tag to describe which
tree/branch/commit patches are applicable to. If that tag is missing, the
bot can assume it's against upstream/next.

Thanks,

tglx


Re: [PATCH] futex: Set USER_DS for the futex_detect_cmpxchg() test

2018-09-28 Thread Thomas Gleixner
On Fri, 28 Sep 2018, Max Filippov wrote:
> On Fri, Sep 28, 2018 at 2:08 PM, Andy Lutomirski  wrote:
> >> On Sep 28, 2018, at 1:26 PM, Thomas Gleixner  wrote:
> >>
> >>> On Fri, 28 Sep 2018, Max Filippov wrote:
> >>>
>  On Fri, Sep 28, 2018 at 11:02 AM, Andy Lutomirski  
>  wrote:
>  There may be a much nicer solution.  Unless I missed something, only
>  mips and xtensa even have the possibility of cmpxchg being missing.
>  We could just make those arches supply a futex-detecting helper.
> >>>
> >>> In case of xtensa availability of cmpxchg is known at build time.
> >>
> >> That makes it even simpler. Could you provide a patch which selects
> >> CONFIG_HAVE_FUTEX_CMPXCHG for the right set of CPUs please?
> >>
> >>
> >
> > I think that’s the wrong approach, since it won’t cover mips. How about 
> > adding this to mips and xtensa only:
> >
> > static inline void arch_have_futex_cmpxchg(void) {...};
> > #define arch_have_futex_cmpxchg arch_have_futex_cmpxchg
> >
> > And getting rid of the config option.
> 
> I'd rather do that, given that defining Kconfig entries that describe
> parts of xtensa configuration is somewhat awkward and redundant.

Fair enough.

Thanks,

tglx

Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

2018-09-28 Thread Thomas Gleixner
On Fri, 28 Sep 2018, Andi Kleen wrote:
> > > This new file descriptor argument doesn't exist today so it would
> > > need to create a new system call with more arguments
> > 
> > Is that true? The first argument is a pointer to a struct that
> > contains its own size, so it can be expanded without an ABI break. I
> > don't see any reason why you couldn't cram more stuff in there.
> 
> You're right we could put the fd into the perf_event, but the following is
> still true:
> 
> > > Obviously we would need to keep the old system call around
> > > for compability, so you would need to worry about this
> > > interaction in any case!
> > >
> > > So tying it together doesn't make any sense, because
> > > the problem has to be solved separately anyways.

And why so? You can keep the original functionality around with the
existing restrictions without breaking any existing user space. That
existing functionality does not require new knobs. It stays as is.

So if you want to use the enhanced version with per PMU permissions based
on file descriptors you need a new version of perf. That's nothing new, if
the kernel adds new features to any syscall, then you need new tools, new
libraries etc. The only guarantee the kernel makes is not to break existing
user space, but there is no guarantee that you can utilize new features
with existing userspace.

Thanks,

tglx


[PATCH v3] RISC-V: Show IPI stats

2018-09-28 Thread Anup Patel
This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.

Now the contents of /proc/interrupts" will look like below:
   CPU0   CPU1   CPU2   CPU3
  8: 17  7  6 14  SiFive PLIC   8  virtio0
 10: 10 10  9 11  SiFive PLIC  10  ttyS0
IPI0:   170673251 79  Rescheduling interrupts
IPI1: 1 12 27  1  Function call interrupts

Signed-off-by: Anup Patel 

Changes since v2:
 - Remove use of IPI_CALL_WAKEUP because it's being removed

Changes since v1:
 - Add stub inline show_ipi_stats() function for !CONFIG_SMP
 - Make ipi_names[] dynamically sized at compile time
 - Minor beautification of ipi_names[] using tabs

---
 arch/riscv/include/asm/smp.h |  9 +
 arch/riscv/kernel/irq.c  |  8 
 arch/riscv/kernel/smp.c  | 39 +---
 3 files changed, 49 insertions(+), 7 deletions(-)

diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
index fce312ce3516..5278ae8f1346 100644
--- a/arch/riscv/include/asm/smp.h
+++ b/arch/riscv/include/asm/smp.h
@@ -25,8 +25,13 @@
 extern unsigned long __cpuid_to_hardid_map[NR_CPUS];
 #define cpuid_to_hardid_map(cpu)__cpuid_to_hardid_map[cpu]
 
+struct seq_file;
+
 #ifdef CONFIG_SMP
 
+/* print IPI stats */
+void show_ipi_stats(struct seq_file *p, int prec);
+
 /* SMP initialization hook for setup_arch */
 void __init setup_smp(void);
 
@@ -47,6 +52,10 @@ void riscv_cpuid_to_hartid_mask(const struct cpumask *in, 
struct cpumask *out);
 
 #else
 
+static inline void show_ipi_stats(struct seq_file *p, int prec)
+{
+}
+
 static inline int riscv_hartid_to_cpuid(int hartid)
 {
return 0;
diff --git a/arch/riscv/kernel/irq.c b/arch/riscv/kernel/irq.c
index ca4593317e45..48e6b7db83a1 100644
--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /*
  * Possible interrupt causes:
@@ -24,6 +26,12 @@
  */
 #define INTERRUPT_CAUSE_FLAG   (1UL << (__riscv_xlen - 1))
 
+int arch_show_interrupts(struct seq_file *p, int prec)
+{
+   show_ipi_stats(p, prec);
+   return 0;
+}
+
 asmlinkage void __irq_entry do_IRQ(struct pt_regs *regs)
 {
struct pt_regs *old_regs = set_irq_regs(regs);
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index 89d95866f562..686fa7a427ff 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -22,22 +22,24 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 
-/* A collection of single bit ipi messages.  */
-static struct {
-   unsigned long bits cacheline_aligned;
-} ipi_data[NR_CPUS] __cacheline_aligned;
-
 enum ipi_message_type {
IPI_RESCHEDULE,
IPI_CALL_FUNC,
IPI_MAX
 };
 
+/* A collection of single bit ipi messages.  */
+static struct {
+   unsigned long stats[IPI_MAX] cacheline_aligned;
+   unsigned long bits cacheline_aligned;
+} ipi_data[NR_CPUS] __cacheline_aligned;
+
 int riscv_hartid_to_cpuid(int hartid)
 {
int i = -1;
@@ -67,6 +69,7 @@ int setup_profiling_timer(unsigned int multiplier)
 void riscv_software_interrupt(void)
 {
unsigned long *pending_ipis = &ipi_data[smp_processor_id()].bits;
+   unsigned long *stats = ipi_data[smp_processor_id()].stats;
 
/* Clear pending IPI */
csr_clear(sip, SIE_SSIE);
@@ -81,11 +84,15 @@ void riscv_software_interrupt(void)
if (ops == 0)
return;
 
-   if (ops & (1 << IPI_RESCHEDULE))
+   if (ops & (1 << IPI_RESCHEDULE)) {
+   stats[IPI_RESCHEDULE]++;
scheduler_ipi();
+   }
 
-   if (ops & (1 << IPI_CALL_FUNC))
+   if (ops & (1 << IPI_CALL_FUNC)) {
+   stats[IPI_CALL_FUNC]++;
generic_smp_call_function_interrupt();
+   }
 
BUG_ON((ops >> IPI_MAX) != 0);
 
@@ -111,6 +118,24 @@ send_ipi_message(const struct cpumask *to_whom, enum 
ipi_message_type operation)
sbi_send_ipi(cpumask_bits(&hartid_mask));
 }
 
+static const char *ipi_names[] = {
+   [IPI_RESCHEDULE]= "Rescheduling interrupts",
+   [IPI_CALL_FUNC] = "Function call interrupts",
+};
+
+void show_ipi_stats(struct seq_file *p, int prec)
+{
+   unsigned int cpu, i;
+
+   for (i = 0; i < IPI_MAX; i++) {
+   seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i,
+  prec >= 4 ? " " : "");
+   for_each_online_cpu(cpu)
+   seq_printf(p, "%10lu ", ipi_data[cpu].stats[i]);
+   seq_printf(p, " %s\n", ipi_names[i]);
+   }
+}
+
 void arch_send_call_function_ipi_mask(struct cpumask *mask)
 {
send_ipi_message(mask, IPI_CALL_FUNC);
-- 
2.17.1



Re: [PATCH v2 3/8] mtd: maps: gpio-addr-flash: Use devm_* functions

2018-09-28 Thread Ricardo Ribalda Delgado
Hi Boris

On Thu, 27 Sep 2018, 13:35 Boris Brezillon,  wrote:
>
> On Wed,  5 Sep 2018 16:36:38 +0200
> Ricardo Ribalda Delgado  wrote:
> > @@ -234,9 +234,11 @@ static int gpio_flash_probe(struct platform_device 
> > *pdev)
> >   state->map.copy_to= gf_copy_to;
> >   state->map.bankwidth  = pdata->width;
> >   state->map.size   = state->win_size * (1 << state->gpio_count);
> > - state->map.virt   = ioremap_nocache(memory->start, 
> > state->win_size);
> > - if (!state->map.virt)
> > - return -ENOMEM;
> > + state->map.virt   = devm_ioremap_resource(&pdev->dev, memory);
> > + if (IS_ERR(state->map.virt)) {
> > + dev_err(&pdev->dev, "failed to map memory\n");
>
> You can drop this error message, devm_ioremap_resource() already takes
> care of that (no need to send a new version, I'll fix it when applying).

Thanks for you review. I will do the port to gpiod next monday (I want
to try it on real hw)

Cheers!
>
> > + return PTR_ERR(state->map.virt);
> > + }
>


Re: [PATCH v2] gpiolib: Show correct direction from the beginning

2018-09-28 Thread Ricardo Ribalda Delgado
Hi Timur

In fact  gpiochip_init_valid_mask is called some lines after in the
same function. We could reorder the function. Would that work for you?

The driver breaking is upstream? Is it possible to access the hardware?

Thanks

[Sorry for the two html mails in a row, I did not try to work with my
phone before :) ]
On Fri, Sep 28, 2018 at 9:23 PM Timur Tabi  wrote:
>
> On Fri, Sep 28, 2018 at 2:14 PM Jeffrey Hugo  wrote:
> > Nack.  Causes a XPU violation to the GPIO config registers.
>
> That doesn't surprise me at all.
>
> I believe that the problem is that gpiochip_line_is_valid() is being
> called before gpiochip_irqchip_init_valid_mask() is called, which
> means that gpiochip_line_is_valid() always returns true.



-- 
Ricardo Ribalda


Re: [RFC 0/5] perf: Per PMU access controls (paranoid setting)

2018-09-28 Thread Thomas Gleixner
On Fri, 28 Sep 2018, Andi Kleen wrote:
> So there isn't a single answer, and that is why it is important
> that this if configurable.

I said clearly that I'm not opposed against making it configurable. But
because there is no single answer, it's even more important to have proper
documentation. And that's all I'm asking for aside of making it opt-in
instead of a wholesale expose everything approach.

Thanks,

tglx




Re: [PATCH] RISC-V: Show CPU ID and Hart ID separately in /proc/cpuinfo

2018-09-28 Thread Anup Patel
On Sat, Sep 29, 2018 at 7:16 AM Palmer Dabbelt  wrote:
>
> On Wed, 12 Sep 2018 07:38:22 PDT (-0700), a...@brainfault.org wrote:
> > Currently, /proc/cpuinfo show logical CPU ID as Hart ID which
> > is in-correct. This patch shows CPU ID and Hart ID separately
> > in /proc/cpuinfo using cpuid_to_hardid_map().
> >
> > With this patch, contents of /proc/cpuinfo looks as follows:
> > cpu   : 0
> > hart  : 1
> > isa   : rv64imafdcsu
> > mmu   : sv48
> >
> > cpu   : 1
> > hart  : 0
> > isa   : rv64imafdcsu
> > mmu   : sv48
> >
> > cpu   : 2
> > hart  : 3
> > isa   : rv64imafdcsu
> > mmu   : sv48
> >
> > cpu   : 3
> > hart  : 2
> > isa   : rv64imafdcsu
> > mmu   : sv48
> >
> > Signed-off-by: Anup Patel 
> > ---
> >  arch/riscv/kernel/cpu.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> > index f0f0ec2737b7..7c1342e242e6 100644
> > --- a/arch/riscv/kernel/cpu.c
> > +++ b/arch/riscv/kernel/cpu.c
> > @@ -87,7 +87,8 @@ static int c_show(struct seq_file *m, void *v)
> >  NULL);
> >   const char *compat, *isa, *mmu;
> >
> > - seq_printf(m, "hart\t: %lu\n", cpu_id);
> > + seq_printf(m, "cpu\t: %lu\n", cpu_id);
> > + seq_printf(m, "hart\t: %lu\n", cpuid_to_hardid_map(cpu_id));
> >   if (!of_property_read_string(node, "riscv,isa", &isa)
> >   && isa[0] == 'r'
> >   && isa[1] == 'v')
>
> I like this, but it doesn't appear to apply.  Do you mind sending something
> against Linus' master?  Then I should be able to sort it out.
>

This patch is requires cpuid_to_hardid_map() added by Atish's
patchset so I have requested Atish to make this patch part of
his v6 patchset.

Thanks,
Anup


Re: [PATCH] RISC-V: Show IPI stats

2018-09-28 Thread Anup Patel
On Sat, Sep 29, 2018 at 7:15 AM Palmer Dabbelt  wrote:
>
> On Mon, 10 Sep 2018 06:46:59 PDT (-0700), Christoph Hellwig wrote:
> > On Fri, Sep 07, 2018 at 06:14:29PM +0530, Anup Patel wrote:
> >> This patch provides arch_show_interrupts() implementation to
> >> show IPI stats via /proc/interrupts.
> >>
> >> Now the contents of /proc/interrupts" will look like below:
> >>CPU0   CPU1   CPU2   CPU3
> >>   8: 17  7  6 14  SiFive PLIC   8  virtio0
> >>  10: 10 10  9 11  SiFive PLIC  10  ttyS0
> >> IPI0:   170673251 79  Rescheduling interrupts
> >> IPI1: 1 12 27  1  Function call interrupts
> >> IPI2: 0  0  0  0  CPU wake-up interrupts
> >>
> >> Signed-off-by: Anup Patel 
> >
> > Thanks, this looks pretty sensible to me.  Maybe we want to also show
> > timer interrupts if we do this?
>
> IIRC we used to have some issue where the timer interrupt ID in
> /proc/interrupts aliased with a possible PLIC interrupt ID, but that was back
> when we had a big mess of chained interrupt drivers that didn't really talk to
> each other.  I think at some point I might have just removed the timer
> interrupt from /proc/interrupts as a hack, but now that our interrupt
> controller mess is sorted out it'd be better to have it.

If we have irqdomain and irqchip for HLIC then showing timer interrupts
becomes cleaner. My RISCV INTC patch achieves this.

>
> I'm fine taking this without the timer interrupts, as something is better than
> nothing.

Sure.

>
> >> --- a/arch/riscv/kernel/irq.c
> >> +++ b/arch/riscv/kernel/irq.c
> >> @@ -8,6 +8,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  /*
> >>   * Possible interrupt causes:
> >> @@ -24,6 +25,14 @@
> >>   */
> >>  #define INTERRUPT_CAUSE_FLAG(1UL << (__riscv_xlen - 1))
> >>
> >> +int arch_show_interrupts(struct seq_file *p, int prec)
> >> +{
> >> +#ifdef CONFIG_SMP
> >> +show_ipi_stats(p, prec);
> >> +#endif
> >> +return 0;
> >> +}
> >
> > If we don't also add timer stats I'd just move arch_show_interrupts
> > to smp.c and make it conditional.  If we don't this split might make
> > more sense.
>
> Makes sense, but I think timer interrupts are more interesting to see than 
> IPIs
> so we'll eventually pipe them through.  Might just be my workloads, though :)
>
> >> +static const char *ipi_names[IPI_MAX] = {
> >> +[IPI_RESCHEDULE] = "Rescheduling interrupts",
> >> +[IPI_CALL_FUNC] = "Function call interrupts",
> >> +[IPI_CALL_WAKEUP] = "CPU wake-up interrupts",
> >> +};
> >
> > No need for the explicit array size.  Also please use a few tabs to
> > align this nicely:
> >
> > static const char *ipi_names[] = {
> >   [IPI_RESCHEDULE]= "Rescheduling interrupts",
> >   [IPI_CALL_FUNC] = "Function call interrupts",
> >   [IPI_CALL_WAKEUP]   = "CPU wake-up interrupts",
> > };
>
> I don't see a v2 of this, was there one?  If not then I'll just clean up
> ipi_names and drop this on for-next.
>
> Thanks for the patch!

I will send v3 patch because IPI_CALL_WAKEUP is not going to be available.

I will base v3 patch upon v5 of Atish's patchset. Atish will take v3 of this
patch and make it part of his v6 patchset so that it will be easy for you
to apply.

Regards,
Anup


[PATCH 4/4] Staging: rts5208: sd: Fixed multiple coding style issues Fixed multiple braces issues

2018-09-28 Thread Maxime Desroches
---
 drivers/staging/rts5208/sd.c | 704 +--
 1 file changed, 268 insertions(+), 436 deletions(-)

diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index e7efa34195c7..930c61ccb047 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -109,9 +109,8 @@ static int sd_check_data0_status(struct rtsx_chip *chip)
u8 stat;
 
retval = rtsx_read_register(chip, REG_SD_STAT1, &stat);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
if (!(stat & SD_DAT0_STATUS)) {
sd_set_err_code(chip, SD_BUSY);
@@ -234,9 +233,8 @@ static int sd_send_cmd_get_rsp(struct rtsx_chip *chip, u8 
cmd_idx,
if ((cmd_idx != SEND_RELATIVE_ADDR) &&
(cmd_idx != SEND_IF_COND)) {
if (cmd_idx != STOP_TRANSMISSION) {
-   if (ptr[1] & 0x80) {
+   if (ptr[1] & 0x80)
return STATUS_FAIL;
-   }
}
 #ifdef SUPPORT_SD_LOCK
if (ptr[1] & 0x7D) {
@@ -284,9 +282,8 @@ static int sd_read_data(struct rtsx_chip *chip,
if (!buf)
buf_len = 0;
 
-   if (buf_len > 512) {
+   if (buf_len > 512)
return STATUS_FAIL;
-   }
 
rtsx_init_cmd(chip);
 
@@ -331,9 +328,8 @@ static int sd_read_data(struct rtsx_chip *chip,
 
if (buf && buf_len) {
retval = rtsx_read_ppbuf(chip, buf, buf_len);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
}
 
return STATUS_SUCCESS;
@@ -359,9 +355,8 @@ static int sd_write_data(struct rtsx_chip *chip, u8 
trans_mode,
 
if (buf && buf_len) {
retval = rtsx_write_ppbuf(chip, buf, buf_len);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
}
 
rtsx_init_cmd(chip);
@@ -426,9 +421,8 @@ static int sd_check_csd(struct rtsx_chip *chip, char 
check_wp)
break;
}
 
-   if (i == 6) {
+   if (i == 6)
return STATUS_FAIL;
-   }
 
memcpy(sd_card->raw_csd, rsp + 1, 15);
 
@@ -543,9 +537,8 @@ static int sd_set_sample_push_timing(struct rtsx_chip *chip)
}
 
retval = rtsx_write_register(chip, REG_SD_CFG1, 0x1C, val);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
return STATUS_SUCCESS;
 }
@@ -606,9 +599,8 @@ static int sd_set_clock_divider(struct rtsx_chip *chip, u8 
clk_div)
val = 0x20;
 
retval = rtsx_write_register(chip, REG_SD_CFG1, mask, val);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
return STATUS_SUCCESS;
 }
@@ -619,16 +611,14 @@ static int sd_set_init_para(struct rtsx_chip *chip)
int retval;
 
retval = sd_set_sample_push_timing(chip);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
 
sd_choose_proper_clock(chip);
 
retval = switch_clock(chip, sd_card->sd_clock);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
 
return STATUS_SUCCESS;
 }
@@ -651,9 +641,8 @@ int sd_select_card(struct rtsx_chip *chip, int select)
}
 
retval = sd_send_cmd_get_rsp(chip, cmd_idx, addr, cmd_type, NULL, 0);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
 
return STATUS_SUCCESS;
 }
@@ -667,9 +656,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
 
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS, sd_card->sd_addr,
 SD_RSP_TYPE_R1, rsp, 5);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
 
if (rsp[1] & 0x02)
sd_card->sd_lock_status |= SD_LOCKED;
@@ -679,9 +667,8 @@ static int sd_update_lock_status(struct rtsx_chip *chip)
dev_dbg(rtsx_dev(chip), "sd_card->sd_lock_status = 0x%x\n",
sd_card->sd_lock_status);
 
-   if (rsp[1] & 0x01) {
+   if (rsp[1] & 0x01)
return STATUS_FAIL;
-   }
 
return STATUS_SUCCESS;
 }
@@ -698,9 +685,8 @@ static int sd_wait_state_data_ready(struct rtsx_chip *chip, 
u8 state,
retval = sd_send_cmd_get_rsp(chip, SEND_STATUS,
 sd_card->sd_addr, SD_RSP_TYPE_R1,
 rsp, 5);
-   if (retval != STATUS_SUCCESS) {
+   if (retval !

Re: [PATCH v5 0/9] PCI: mediatek: fixup find_port, enable_msi and add pm, module support

2018-09-28 Thread Ryder Lee
On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang 
> 
> This patchset includes misc patchs:
> 
> The patch 1 fixup the mtk_pcie_find_port logic which will cause system
> could not touch the EP's configuration space that connected to PCIe slot 1.
> 
> The patch 2 fixup the class type for MT7622.
> The patch 6 fixup the enable msi logic, the operation to enable msi
> should be after system clock is enabled. Call mtk_pcie_enable_msi in
> mtk_pcie_startup_port_v2 since the clock was all enabled at that time.
> 
> The patch 7 was rebased and refactor of the v4 patch[1], changes are:
>  -Add PM support for MT7622.
>  -Using mtk_pcie_enable_port to re-establish the link when resumed.
>  -Rebased on this patchset.
> 
> The patch 9 add loadable kernel module support.
> 
> [1] https://patchwork.kernel.org/patch/10479079
> 
> Change since v4:
>  - Add patch 2 to fixup class type for MT7622.
>  - Add patch 3 to remove the redundant dev->pm_domain check
>  - Add patch 4 to covert to use pci_host_probe
>  - Add patch 5 to re-arrange the function define, this is a prepare patch for
>fixup the enable_msi logic, no functional changed have been made by this 
> one.
>  - Add patch 8 to save the GIC IRQ in mtk_pcie_port as a prepare patch for 
> tear
>down the irq when remove the kernel module.
>  - Re-arrange the find_port flow suggest by Lorenzo to make the code parse 
> easier
>for the patch 1.
>  - Remove the .pm_support in mtk_pcie_soc in patch 7 since if system pm was 
> not
>supported, then those pm callbacks will never be executed for MT7622. So 
> the
>.pm_support is not needed.
> 
> Change since v3:
>  - Remove pm_runtime_XXX ops in suspend and resume callbacks in the third 
> patch.
>  - Rebase to 4.19-rc1.
> 
> Change since v2:
>  - Fix the list_for_each_entry_safe parameter error.
>  - Add Ryder's Acked-by flag.
> 
> Change since v1:
>  - A bit of code refact of the first patch suggested by Andy Shevchenko, and
>commit message updated.
>  - Using __maybe_unused.
>  - Remove the redundant list_empty check of the fourth patch.
> 
> Honghui Zhang (9):
>   PCI: mediatek: Using slot's devfn for compare to fix
> mtk_pcie_find_port logic
>   PCI: mediatek: Fixup class ID for MT7622 as PCI_CLASS_BRIDGE_PCI
>   PCI: mediatek: Remove the redundant dev->pm_domain check
>   PCI: mediatek: Convert to use pci_host_probe()
>   PCI: mediatek: Move the mtk_pcie_startup_port_v2 function's define
> after mtk_pcie_setup_irq
>   PCI: mediatek: Enable msi after clock enabled
>   PCI: mediatek: Add system pm support for MT2712 and MT7622
>   PCI: mediatek: Save the GIC IRQ in mtk_pcie_port
>   PCI: mediatek: Add loadable kernel module support
> 
>  drivers/pci/controller/Kconfig |   2 +-
>  drivers/pci/controller/pcie-mediatek.c | 326 
> +
>  2 files changed, 210 insertions(+), 118 deletions(-)
> 

Acked-by: Ryder Lee  for the whole series.



Re: [PATCH v5 4/9] PCI: mediatek: Convert to use pci_host_probe()

2018-09-28 Thread Ryder Lee
On Sat, 2018-09-29 at 08:16 +0800, Honghui Zhang wrote:
> On Fri, 2018-09-28 at 23:41 +0800, Ryder Lee wrote:
> > On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> > > From: Honghui Zhang 
> > > 
> > > Part of mtk_pcie_register_host is an open-coded version of
> > > pci_host_probe(). So instead of duplicating this code, use
> > > pci_host_probe() directly and remove mtk_pcie_register_host.
> > > 
> > > Signed-off-by: Honghui Zhang 
> > > ---
> > >  drivers/pci/controller/pcie-mediatek.c | 37 
> > > --
> > >  1 file changed, 8 insertions(+), 29 deletions(-)
> > > 
> > > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > > b/drivers/pci/controller/pcie-mediatek.c
> > > index e2c4127..cbf4543 100644
> > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > @@ -1125,34 +1125,6 @@ static int mtk_pcie_request_resources(struct 
> > > mtk_pcie *pcie)
> > >   return 0;
> > >  }
> > >  
> > > -static int mtk_pcie_register_host(struct pci_host_bridge *host)
> > > -{
> > > - struct mtk_pcie *pcie = pci_host_bridge_priv(host);
> > > - struct pci_bus *child;
> > > - int err;
> > 
> > To make the patch simple, could we keep these host->*. and return
> > pci_host_probe() directly?
> 
> Well, I guess it's not necessary to keep the mtk_pcie_register_host just
> wrap pci_host_probe(). Put those host->* directly in probe function is
> no harm, it will reduce one function call and related parameter passing.
> 
> I may update this patch to keep the mtk_pcie_register_host if you insist
> though I prefer the current way.
> 
> Thanks.

Okay. I'm fine with this.

> > > - host->busnr = pcie->busn.start;
> > > - host->dev.parent = pcie->dev;
> > > - host->ops = pcie->soc->ops;
> > > - host->map_irq = of_irq_parse_and_map_pci;
> > > - host->swizzle_irq = pci_common_swizzle;
> > > - host->sysdata = pcie;
> > > -
> > > - err = pci_scan_root_bus_bridge(host);
> > > - if (err < 0)
> > > - return err;
> > > -
> > > - pci_bus_size_bridges(host->bus);
> > > - pci_bus_assign_resources(host->bus);
> > > -
> > > - list_for_each_entry(child, &host->bus->children, node)
> > > - pcie_bus_configure_settings(child);
> > > -
> > > - pci_bus_add_devices(host->bus);
> > > -
> > > - return 0;
> > > -}
> > > -
> > >  static int mtk_pcie_probe(struct platform_device *pdev)
> > >  {
> > >   struct device *dev = &pdev->dev;
> > > @@ -1179,7 +1151,14 @@ static int mtk_pcie_probe(struct platform_device 
> > > *pdev)
> > >   if (err)
> > >   goto put_resources;
> > >  
> > > - err = mtk_pcie_register_host(host);
> > > + host->busnr = pcie->busn.start;
> > > + host->dev.parent = pcie->dev;
> > > + host->ops = pcie->soc->ops;
> > > + host->map_irq = of_irq_parse_and_map_pci;
> > > + host->swizzle_irq = pci_common_swizzle;
> > > + host->sysdata = pcie;
> > > +
> > > + err = pci_host_probe(host);
> > >   if (err)
> > >   goto put_resources;
> > >  
> > 
> > 
> 
> 




[PATCH 6/7] dmaengine: sprd: Support DMA 2-stage transfer mode

2018-09-28 Thread Baolin Wang
From: Eric Long 

The Spreadtrum DMA controller supports channel 2-stage tansfer mode,
that means we can request 2 dma channels, one for source channel, and
another one for destination channel. Once the source channel's transaction
is done, it will trigger the destination channel's transaction automatically
by hardware signal.

Signed-off-by: Eric Long 
Signed-off-by: Baolin Wang 
---
 drivers/dma/sprd-dma.c   |   98 +-
 include/linux/dma/sprd-dma.h |   62 --
 2 files changed, 156 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index cefe42f..50d6569 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -36,6 +36,8 @@
 #define SPRD_DMA_GLB_CHN_EN_STS0x1c
 #define SPRD_DMA_GLB_DEBUG_STS 0x20
 #define SPRD_DMA_GLB_ARB_SEL_STS   0x24
+#define SPRD_DMA_GLB_2STAGE_GRP1   0x28
+#define SPRD_DMA_GLB_2STAGE_GRP2   0x2c
 #define SPRD_DMA_GLB_REQ_UID(uid)  (0x4 * ((uid) - 1))
 #define SPRD_DMA_GLB_REQ_UID_OFFSET0x2000
 
@@ -57,6 +59,18 @@
 #define SPRD_DMA_CHN_SRC_BLK_STEP  0x38
 #define SPRD_DMA_CHN_DES_BLK_STEP  0x3c
 
+/* SPRD_DMA_GLB_2STAGE_GRP register definition */
+#define SPRD_DMA_GLB_2STAGE_EN BIT(24)
+#define SPRD_DMA_GLB_CHN_INT_MASK  GENMASK(23, 20)
+#define SPRD_DMA_GLB_LIST_DONE_TRG BIT(19)
+#define SPRD_DMA_GLB_TRANS_DONE_TRGBIT(18)
+#define SPRD_DMA_GLB_BLOCK_DONE_TRGBIT(17)
+#define SPRD_DMA_GLB_FRAG_DONE_TRG BIT(16)
+#define SPRD_DMA_GLB_TRG_OFFSET16
+#define SPRD_DMA_GLB_DEST_CHN_MASK GENMASK(13, 8)
+#define SPRD_DMA_GLB_DEST_CHN_OFFSET   8
+#define SPRD_DMA_GLB_SRC_CHN_MASK  GENMASK(5, 0)
+
 /* SPRD_DMA_CHN_INTC register definition */
 #define SPRD_DMA_INT_MASK  GENMASK(4, 0)
 #define SPRD_DMA_INT_CLR_OFFSET24
@@ -118,6 +132,10 @@
 #define SPRD_DMA_SRC_TRSF_STEP_OFFSET  0
 #define SPRD_DMA_TRSF_STEP_MASKGENMASK(15, 0)
 
+/* define DMA channel mode & trigger mode mask */
+#define SPRD_DMA_CHN_MODE_MASK GENMASK(7, 0)
+#define SPRD_DMA_TRG_MODE_MASK GENMASK(7, 0)
+
 /* define the DMA transfer step type */
 #define SPRD_DMA_NONE_STEP 0
 #define SPRD_DMA_BYTE_STEP 1
@@ -170,6 +188,8 @@ struct sprd_dma_chn {
struct dma_slave_config slave_cfg;
u32 chn_num;
u32 dev_id;
+   enum sprd_dma_chn_mode  chn_mode;
+   enum sprd_dma_trg_mode  trg_mode;
struct sprd_dma_desc*cur_desc;
 };
 
@@ -206,6 +226,16 @@ static inline struct sprd_dma_desc 
*to_sprd_dma_desc(struct virt_dma_desc *vd)
return container_of(vd, struct sprd_dma_desc, vd);
 }
 
+static void sprd_dma_glb_update(struct sprd_dma_dev *sdev, u32 reg,
+   u32 mask, u32 val)
+{
+   u32 orig = readl(sdev->glb_base + reg);
+   u32 tmp;
+
+   tmp = (orig & ~mask) | val;
+   writel(tmp, sdev->glb_base + reg);
+}
+
 static void sprd_dma_chn_update(struct sprd_dma_chn *schan, u32 reg,
u32 mask, u32 val)
 {
@@ -389,6 +419,49 @@ static enum sprd_dma_req_mode sprd_dma_get_req_type(struct 
sprd_dma_chn *schan)
return (frag_reg >> SPRD_DMA_REQ_MODE_OFFSET) & SPRD_DMA_REQ_MODE_MASK;
 }
 
+static int sprd_dma_set_2stage_config(struct sprd_dma_chn *schan)
+{
+   struct sprd_dma_dev *sdev = to_sprd_dma_dev(&schan->vc.chan);
+   u32 val, chn = schan->chn_num + 1;
+
+   switch (schan->chn_mode) {
+   case SPRD_DMA_SRC_CHN0:
+   val = chn & SPRD_DMA_GLB_SRC_CHN_MASK;
+   val |= BIT(schan->trg_mode - 1) << SPRD_DMA_GLB_TRG_OFFSET;
+   val |= SPRD_DMA_GLB_2STAGE_EN;
+   sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP1, val, val);
+   break;
+
+   case SPRD_DMA_SRC_CHN1:
+   val = chn & SPRD_DMA_GLB_SRC_CHN_MASK;
+   val |= BIT(schan->trg_mode - 1) << SPRD_DMA_GLB_TRG_OFFSET;
+   val |= SPRD_DMA_GLB_2STAGE_EN;
+   sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP2, val, val);
+   break;
+
+   case SPRD_DMA_DST_CHN0:
+   val = (chn << SPRD_DMA_GLB_DEST_CHN_OFFSET) &
+   SPRD_DMA_GLB_DEST_CHN_MASK;
+   val |= SPRD_DMA_GLB_2STAGE_EN;
+   sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP1, val, val);
+   break;
+
+   case SPRD_DMA_DST_CHN1:
+   val = (chn << SPRD_DMA_GLB_DEST_CHN_OFFSET) &
+   SPRD_DMA_GLB_DEST_CHN_MASK;
+   val |= SPRD_DMA_GLB_2STAGE_EN;
+   sprd_dma_glb_update(sdev, SPRD_DMA_GLB_2STAGE_GRP2, val, val);
+   break;
+
+   default:
+   dev_err(sdev->dma_dev.dev, "invalid channel mode setting %d\n",
+   schan->chn_mode);
+   return -EINVAL;
+   }
+
+

[PATCH 4/7] dmaengine: sprd: Set cur_desc as NULL when free or terminate one dma channel

2018-09-28 Thread Baolin Wang
From: Eric Long 

It will be failed to start one new transfer if the channel started one
none interrupt transfer before, since we will only set the schan->cur_desc
as NULL depending on the transfer interrupt now. Thus we should set
schan->cur_desc as NULL when free or terminate one dma channel to
avoid this issue.

Signed-off-by: Eric Long 
Signed-off-by: Baolin Wang 
---
 drivers/dma/sprd-dma.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index e6a74dc..1b39661 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -439,6 +439,7 @@ static void sprd_dma_stop(struct sprd_dma_chn *schan)
sprd_dma_stop_and_disable(schan);
sprd_dma_unset_uid(schan);
sprd_dma_clear_int(schan);
+   schan->cur_desc = NULL;
 }
 
 static bool sprd_dma_check_trans_done(struct sprd_dma_desc *sdesc,
-- 
1.7.9.5



[PATCH 0/7] Add some fixes and new feature for SPRD DMA

2018-09-28 Thread Baolin Wang
This patchset removes the direction usage from struct dma_slave_config,
and add one new field to save the direction. It also fixes some issues
for link-list transfer. Moreover this patchset adds new 2-stage transfer
support for our DMA.

Baolin Wang (1):
  dmaengine: sprd: Remove direction usage from struct dma_slave_config

Eric Long (6):
  dmaengine: sprd: Get transfer residue depending on the transfer
direction
  dmaengine: sprd: Fix the last link-list configuration
  dmaengine: sprd: Set cur_desc as NULL when free or terminate one dma
channel
  dmaengine: sprd: Support DMA link-list cyclic callback
  dmaengine: sprd: Support DMA 2-stage transfer mode
  dmaengine: sprd: Add me as one of the module authors

 drivers/dma/sprd-dma.c   |  152 +-
 include/linux/dma/sprd-dma.h |   62 -
 2 files changed, 194 insertions(+), 20 deletions(-)

-- 
1.7.9.5



[PATCH 1/7] dmaengine: sprd: Remove direction usage from struct dma_slave_config

2018-09-28 Thread Baolin Wang
The direction field of struct dma_slave_config was marked deprecated,
thus remove the usage.

Signed-off-by: Baolin Wang 
---
 drivers/dma/sprd-dma.c |3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 38d4e4f..c226dc93 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -847,9 +847,6 @@ static int sprd_dma_slave_config(struct dma_chan *chan,
struct sprd_dma_chn *schan = to_sprd_dma_chan(chan);
struct dma_slave_config *slave_cfg = &schan->slave_cfg;
 
-   if (!is_slave_direction(config->direction))
-   return -EINVAL;
-
memcpy(slave_cfg, config, sizeof(*config));
return 0;
 }
-- 
1.7.9.5



[PATCH 7/7] dmaengine: sprd: Add me as one of the module authors

2018-09-28 Thread Baolin Wang
From: Eric Long 

Add me as one of the module authors.

Signed-off-by: Eric Long 
Signed-off-by: Baolin Wang 
---
 drivers/dma/sprd-dma.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 50d6569..e2f0167 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -1226,4 +1226,5 @@ static int __maybe_unused sprd_dma_runtime_resume(struct 
device *dev)
 MODULE_LICENSE("GPL v2");
 MODULE_DESCRIPTION("DMA driver for Spreadtrum");
 MODULE_AUTHOR("Baolin Wang ");
+MODULE_AUTHOR("Eric Long ");
 MODULE_ALIAS("platform:sprd-dma");
-- 
1.7.9.5



[PATCH 5/7] dmaengine: sprd: Support DMA link-list cyclic callback

2018-09-28 Thread Baolin Wang
From: Eric Long 

The Spreadtrum DMA link-list mode is always one cyclic transfer,
so we should clear the SPRD_DMA_LLIST_END flag for the link-list
configuration. Moreover add cyclic callback support for the cyclic
transfer.

Signed-off-by: Eric Long 
Signed-off-by: Baolin Wang 
---
 drivers/dma/sprd-dma.c |   25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 1b39661..cefe42f 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -463,7 +463,7 @@ static irqreturn_t dma_irq_handle(int irq, void *dev_id)
struct sprd_dma_desc *sdesc;
enum sprd_dma_req_mode req_type;
enum sprd_dma_int_type int_type;
-   bool trans_done = false;
+   bool trans_done = false, cyclic = false;
u32 i;
 
while (irq_status) {
@@ -478,13 +478,19 @@ static irqreturn_t dma_irq_handle(int irq, void *dev_id)
 
sdesc = schan->cur_desc;
 
-   /* Check if the dma request descriptor is done. */
-   trans_done = sprd_dma_check_trans_done(sdesc, int_type,
-  req_type);
-   if (trans_done == true) {
-   vchan_cookie_complete(&sdesc->vd);
-   schan->cur_desc = NULL;
-   sprd_dma_start(schan);
+   /* cyclic mode schedule callback */
+   cyclic = schan->linklist.phy_addr ? true : false;
+   if (cyclic == true) {
+   vchan_cyclic_callback(&sdesc->vd);
+   } else {
+   /* Check if the dma request descriptor is done. */
+   trans_done = sprd_dma_check_trans_done(sdesc, int_type,
+  req_type);
+   if (trans_done == true) {
+   vchan_cookie_complete(&sdesc->vd);
+   schan->cur_desc = NULL;
+   sprd_dma_start(schan);
+   }
}
spin_unlock(&schan->vc.lock);
}
@@ -692,9 +698,6 @@ static int sprd_dma_fill_desc(struct dma_chan *chan,
 
/* link-list configuration */
if (schan->linklist.phy_addr) {
-   if (sg_index == sglen - 1)
-   hw->frg_len |= SPRD_DMA_LLIST_END;
-
hw->cfg |= SPRD_DMA_LINKLIST_EN;
 
/* link-list index */
-- 
1.7.9.5



[PATCH 2/7] dmaengine: sprd: Get transfer residue depending on the transfer direction

2018-09-28 Thread Baolin Wang
From: Eric Long 

Add one field to save the transfer direction for struct sprd_dma_desc,
which is used to get correct transfer residue depending on the transfer
direction.

[Baolin Wang adds one field to present the transfer direction]
Signed-off-by: Eric Long 
Signed-off-by: Baolin Wang 
---
 drivers/dma/sprd-dma.c |   21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index c226dc93..4f3587b 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -159,6 +159,7 @@ struct sprd_dma_chn_hw {
 struct sprd_dma_desc {
struct virt_dma_descvd;
struct sprd_dma_chn_hw  chn_hw;
+   enum dma_transfer_direction dir;
 };
 
 /* dma channel description */
@@ -331,6 +332,17 @@ static void sprd_dma_stop_and_disable(struct sprd_dma_chn 
*schan)
sprd_dma_disable_chn(schan);
 }
 
+static unsigned long sprd_dma_get_src_addr(struct sprd_dma_chn *schan)
+{
+   unsigned long addr, addr_high;
+
+   addr = readl(schan->chn_base + SPRD_DMA_CHN_SRC_ADDR);
+   addr_high = readl(schan->chn_base + SPRD_DMA_CHN_WARP_PTR) &
+   SPRD_DMA_HIGH_ADDR_MASK;
+
+   return addr | (addr_high << SPRD_DMA_HIGH_ADDR_OFFSET);
+}
+
 static unsigned long sprd_dma_get_dst_addr(struct sprd_dma_chn *schan)
 {
unsigned long addr, addr_high;
@@ -534,7 +546,12 @@ static enum dma_status sprd_dma_tx_status(struct dma_chan 
*chan,
else
pos = 0;
} else if (schan->cur_desc && schan->cur_desc->vd.tx.cookie == cookie) {
-   pos = sprd_dma_get_dst_addr(schan);
+   struct sprd_dma_desc *sdesc = to_sprd_dma_desc(vd);
+
+   if (sdesc->dir == DMA_DEV_TO_MEM)
+   pos = sprd_dma_get_dst_addr(schan);
+   else
+   pos = sprd_dma_get_src_addr(schan);
} else {
pos = 0;
}
@@ -804,6 +821,8 @@ static int sprd_dma_fill_linklist_desc(struct dma_chan 
*chan,
if (!sdesc)
return NULL;
 
+   sdesc->dir = dir;
+
for_each_sg(sgl, sg, sglen, i) {
len = sg_dma_len(sg);
 
-- 
1.7.9.5



[PATCH 3/7] dmaengine: sprd: Fix the last link-list configuration

2018-09-28 Thread Baolin Wang
From: Eric Long 

We will pass sglen as 0 configure the last link-list configuration
when filling the descriptor, which will cause the incorrect link-list
configuration. Thus we should check if the sglen is 0 to configure
the correct link-list configuration.

Signed-off-by: Eric Long 
Signed-off-by: Baolin Wang 
---
 drivers/dma/sprd-dma.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/sprd-dma.c b/drivers/dma/sprd-dma.c
index 4f3587b..e6a74dc 100644
--- a/drivers/dma/sprd-dma.c
+++ b/drivers/dma/sprd-dma.c
@@ -697,7 +697,8 @@ static int sprd_dma_fill_desc(struct dma_chan *chan,
hw->cfg |= SPRD_DMA_LINKLIST_EN;
 
/* link-list index */
-   temp = (sg_index + 1) % sglen;
+   temp = sglen ? (sg_index + 1) % sglen : 0;
+
/* Next link-list configuration's physical address offset */
temp = temp * sizeof(*hw) + SPRD_DMA_CHN_SRC_ADDR;
/*
-- 
1.7.9.5



[PATCH] fs/dax.c: Use vmf_error() helper

2018-09-28 Thread zhong jiang
These codes can be replaced with new inline vmf_error().

Signed-off-by: zhong jiang 
---
 fs/dax.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index b68ce48..e732f70 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1311,9 +1311,8 @@ static vm_fault_t dax_fault_return(int error)
 {
if (error == 0)
return VM_FAULT_NOPAGE;
-   if (error == -ENOMEM)
-   return VM_FAULT_OOM;
-   return VM_FAULT_SIGBUS;
+
+   return vmf_error(error);
 }
 
 /*
-- 
1.7.12.4



[BUG] sleep in atomic in 8250 runtime PM code path

2018-09-28 Thread Jisheng Zhang
Hi,

Recently I found I could trigger sleep in atomic bug on berlin after commit
d76c74387e1c ("serial: 8250_dw: Fix runtime PM handling"). The path looks like:

dw8250_probe => serial850_register_8250_port => uart_add_one_port=>
register_console => console_unlock => univ8250_console_write =>
serial8250_console_write => serial8250_rpm_get => pm_runtime_get_sync

The irq is disabled by printk_safe_enter_irqsave() in console_unlock, but
pm_runtime_get_sync can't be called in atomic context...

I guess the reason why we didn't notice it is due to the fact that
only OMAP and DW sets UART_CAP_RPM currently, and DW set the flag in
May 2018.

Per my understanding, the bug sits in the 8250 core driver rather than
8250_dw.c.

Thanks


Response to SFConservancy: The copyright holder can rescind.

2018-09-28 Thread freedomfromruin

The software freedom conservancy has tendered its response:
http://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/
http://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4


""
"The GPLv2 have several provisions that, when taken together, can be 
construed as an irrevocable license from each contributor. "

""

It cites:


  " That license granted to downstream is irrevocable, again 
provided that the downstream user complies with the license terms: 
"[P]arties who have received copies, or rights, from you under this 
License will not have their licenses terminated so long as such parties 
remain in full compliance" (GPLv2§4). "


However this is disingenuous

The full text of section 4 is as follows:

""
  4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License.  Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
""



The "You" in section 4 is speaking of the licensee regarding 
sub-licensees, it is not speaking to the licensor/copyright-holder.


IE: if the licensee loses his license, through operation of the 
automatic-revocation provisions, the sub-licensees do not also lose 
their licenses.


IE: The language is disclaiming a chain topography for license 
distribution, and instead substituting a hub-and-spoke topography (all 
licenses originating from the copyright holder, not the 
previous-in-line)


GPLv3 added a no-rescission clause for a reason: the reason being to 
attempt to create an estoppel defense for the licensees against the 
licensor. You will notice that Eben Moglen never speaks on these issues. 
(He preumably is aware of the weaknesses vis a vis the US copyright 
regime.)


Section 6 further clarifies the hub-and-spoke model:
""
   6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
""

The memorandum posted then goes on to a discussion of estoppel, 
detrimental reliance, etc; noting that users may have relied on the 
software and their licenses may be estopped from being revoked from said 
users since doing so might cause them unanticipated loss. This is 
speaking of already published, existent, versions of the program used by 
end users.


The memorandum seems to ignore what happens to "upstream" once said 
project  receives a revocation notice. Thought it may be possible that 
users of a published piece of software may have defenses to license 
revocation, the same is not true regarding the rescinded property 
vis-a-vis future prospective versions of the software nor of future 
prospective licensees of said software.


That is: once the grant to use the code in question is rescinded, future 
versions of the software may not use that code. Current users of the 
software may be-able to raise an estoppel / detrimental reliance defense 
regarding the current published software, however the programmers 
working on the next version of said software cannot continue to use the 
property in future versions of the software (such would be a copyright 
violation once the gratuitous license is rescinded by the grantor).


Additionally, prospective-licensees, once the grant was rescinded and 
such was published, would have no same-such estoppel defense (not being 
user-licensees at the time of revocation).


(Ignoring this eventuality in the published memorandum, is, of-course, 
by design.)
(Now, to note: the free-software movement is focused on the freedom of 
the user, not the progenitors of the software, so one could certainly 
say that ignoring some developer-focused analysis is consistent with 
their prerogative...)


[PATCH 3/3] Staging: rts5208: rtsx_scsi: Fixed multiple coding style issues Fized multiple braces issues

2018-09-28 Thread Maxime Desroches
---
 drivers/staging/rts5208/rtsx_scsi.c | 108 ++--
 1 file changed, 36 insertions(+), 72 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_scsi.c 
b/drivers/staging/rts5208/rtsx_scsi.c
index c9a6d97938f6..9c594a778425 100644
--- a/drivers/staging/rts5208/rtsx_scsi.c
+++ b/drivers/staging/rts5208/rtsx_scsi.c
@@ -507,9 +507,8 @@ static int inquiry(struct scsi_cmnd *srb, struct rtsx_chip 
*chip)
}
 
buf = vmalloc(scsi_bufflen(srb));
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
 #ifdef SUPPORT_MAGIC_GATE
if ((chip->mspro_formatter_enable) &&
@@ -637,9 +636,8 @@ static int request_sense(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
}
 
buf = vmalloc(scsi_bufflen(srb));
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
tmp = (unsigned char *)sense;
memcpy(buf, tmp, scsi_bufflen(srb));
@@ -783,9 +781,8 @@ static int mode_sense(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
 #endif
 
buf = kmalloc(data_size, GFP_KERNEL);
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
page_code = srb->cmnd[2] & 0x3f;
 
@@ -999,9 +996,8 @@ static int read_format_capacity(struct scsi_cmnd *srb, 
struct rtsx_chip *chip)
buf_len = (scsi_bufflen(srb) > 12) ? 0x14 : 12;
 
buf = kmalloc(buf_len, GFP_KERNEL);
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
buf[i++] = 0;
buf[i++] = 0;
@@ -1076,9 +1072,8 @@ static int read_capacity(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
}
 
buf = kmalloc(8, GFP_KERNEL);
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
card_size = get_card_size(chip, lun);
buf[0] = (unsigned char)((card_size - 1) >> 24);
@@ -1116,9 +,8 @@ static int read_eeprom(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
len = ((u16)srb->cmnd[4] << 8) | srb->cmnd[5];
 
buf = vmalloc(len);
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1180,9 +1174,8 @@ static int write_eeprom(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb),
len);
buf = vmalloc(len);
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1227,9 +1220,8 @@ static int read_mem(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
}
 
buf = vmalloc(len);
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
retval = rtsx_force_power_on(chip, SSC_PDCTL);
if (retval != STATUS_SUCCESS) {
@@ -1282,9 +1274,8 @@ static int write_mem(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
 
len = (unsigned short)min_t(unsigned int, scsi_bufflen(srb), len);
buf = vmalloc(len);
-   if (!buf) {
+   if (!buf)
return TRANSPORT_ERROR;
-   }
 
rtsx_stor_get_xfer_buf(buf, len, srb);
scsi_set_resid(srb, scsi_bufflen(srb) - len);
@@ -1702,41 +1693,35 @@ static int set_chip_mode(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
if (phy_debug_mode) {
chip->phy_debug_mode = 1;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
-   }
 
rtsx_disable_bus_int(chip);
 
retval = rtsx_read_phy_register(chip, 0x1C, ®);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
-   }
 
reg |= 0x0001;
retval = rtsx_write_phy_register(chip, 0x1C, reg);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
-   }
} else {
chip->phy_debug_mode = 0;
retval = rtsx_write_register(chip, CDRESUMECTL, 0x77, 0x77);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
-   }
 
rtsx_enable_bus_int(chip);
 
retval = rtsx_read_phy_register(chip, 0x1C, ®);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return TRANSPORT_FAILED;
-   }
 

Reminder: Licenses and revocability, in a paragraph or less. GPL 2 is revocable at the will of the grantor.

2018-09-28 Thread freedomfromruin

As has been stated in easily accessible terms elsewhere:
"Most courts hold that simple, non-exclusive licenses with unspecified 
durations that are silent on revocability are revocable at will. This 
means that the licensor may terminate the license at any time, with or 
without cause." +


Version 2 of the GPL specifies no duration, nor does it declare that it 
is non-revocable by the grantor.


(Also note: A perpetual license may violate the rule against 
perpetuities in various jurisdictions where it is applied not only to 
real property but additionally to personal property (and the like), 
which is why the GPL-3's term of duration is set as the duration of 
copyright on the program (and not "forever"))


+[https://www.sidley.com/en/insights/newsupdates/2013/02/the-terms-revocable-and-irrevocable-in-license-agreements-tips-and-pitfalls]




[PATCH] MAINTAINERS: fix pattern in ARM/Synaptics berlin SoC section

2018-09-28 Thread Jisheng Zhang
Berlin SoC files has been moved from marvell dir to synaptics dir, but
commit bc52497a595d ("MAINTAINERS: update entry for ARM/berlin") didn't
update the dir accordingly. This patch fixes it.

From another side, new derivative SoCs from Synaptics may not be named
as berlin*, so let's update the entries accordingly.

Fixes: bc52497a595d ("MAINTAINERS: update entry for ARM/berlin")
Signed-off-by: Jisheng Zhang 
Reported-by: Joe Perches 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a255240d1452..2be912b67905 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,14 +2093,14 @@ F:  arch/arm/boot/dts/stm32*
 F: arch/arm/mach-stm32/
 F: drivers/clocksource/armv7m_systick.c
 
-ARM/Synaptics Berlin SoC support
+ARM/Synaptics SoC support
 M: Jisheng Zhang 
 M: Sebastian Hesselbarth 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
 F: arch/arm/mach-berlin/
 F: arch/arm/boot/dts/berlin*
-F: arch/arm64/boot/dts/marvell/berlin*
+F: arch/arm64/boot/dts/synaptics/
 
 ARM/TANGO ARCHITECTURE
 M: Marc Gonzalez 
-- 
2.19.0



[PATCH 1/2] Staging: rts5208: rtsx_card: Fixed multiple coding style issues

2018-09-28 Thread Maxime Desroches
Fixed multiple coding style issues

Signed-off-by: Maxime Desroches 
---
 drivers/staging/rts5208/rtsx_card.c | 96 +++--
 1 file changed, 37 insertions(+), 59 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_card.c 
b/drivers/staging/rts5208/rtsx_card.c
index d26a8e372fce..b45abbe29bc2 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -647,9 +647,8 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
dev_dbg(rtsx_dev(chip), "Switch SSC clock to %dMHz (cur_clk = %d)\n",
clk, chip->cur_clk);
 
-   if ((clk <= 2) || (n > max_n)) {
+   if ((clk <= 2) || (n > max_n))
return STATUS_FAIL;
-   }
 
mcu_cnt = (u8)(125 / clk + 3);
if (mcu_cnt > 7)
@@ -688,15 +687,13 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
}
 
retval = rtsx_send_cmd(chip, 0, WAIT_TIME);
-   if (retval < 0) {
+   if (retval < 0)
return STATUS_ERROR;
-   }
 
udelay(10);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
chip->cur_clk = clk;
 
@@ -790,49 +787,44 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
}
 
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, CLK_LOW_FREQ);
-   if (retval) {
+   if (retval)
return retval;
-   }
if (sd_vpclk_phase_reset) {
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
 PHASE_NOT_RESET, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
 PHASE_NOT_RESET, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
}
retval = rtsx_write_register(chip, CLK_DIV, 0xFF,
 (div << 4) | mcu_cnt);
-   if (retval) {
+   if (retval)
return retval;
-   }
retval = rtsx_write_register(chip, CLK_SEL, 0xFF, sel);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
if (sd_vpclk_phase_reset) {
udelay(200);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
 PHASE_NOT_RESET, PHASE_NOT_RESET);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
 PHASE_NOT_RESET, PHASE_NOT_RESET);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
udelay(200);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
chip->cur_clk = clk;
 
@@ -878,9 +870,8 @@ int enable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
 
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, clk_en);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
return STATUS_SUCCESS;
 }
@@ -898,9 +889,8 @@ int disable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
 
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
return STATUS_SUCCESS;
 }
@@ -924,9 +914,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val1);
 
retval = rtsx_send_cmd(chip, 0, 100);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
 
udelay(chip->pmos_pwr_on_interval);
 
@@ -934,9 +923,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val2);
 
retval = rtsx_send_cmd(chip, 0, 100);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
 
return STATUS_SUCCESS;
 }
@@ -955,9 +943,8 @@ int card_power_off(struct rtsx_chip *chip, u8 card)
}
 
retval = rtsx_write_register(chip, CARD_PWR_CTL, mask, val);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
return STATUS_SUCCESS;
 }
@@ -969,9 +956,8 @@ int card_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
unsigned int lun = SCSI_LUN(srb);
int i;
 
-   if (!chip->rw_card[lun]) {
+   if (!chip->rw_card[lun])
retur

[PATCH 2/2] Staging: rts5208: rtsx_chip: Fixed multiple coding style issues

2018-09-28 Thread Maxime Desroches
Fixed multiple braces issues
Signed-off-by: Maxime Desroches 
---
 drivers/staging/rts5208/rtsx_chip.c | 463 
 1 file changed, 199 insertions(+), 264 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_chip.c 
b/drivers/staging/rts5208/rtsx_chip.c
index 6b1234bff09c..6bec2ddc75f2 100644
--- a/drivers/staging/rts5208/rtsx_chip.c
+++ b/drivers/staging/rts5208/rtsx_chip.c
@@ -116,34 +116,31 @@ static int rtsx_pre_handle_sdio_old(struct rtsx_chip 
*chip)
 0xFF,
 MS_INS_PU | SD_WP_PU |
 SD_CD_PU | SD_CMD_PU);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
} else {
retval = rtsx_write_register(chip, FPGA_PULL_CTL,
 0xFF,
 FPGA_SD_PULL_CTL_EN);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
}
retval = rtsx_write_register(chip, CARD_SHARE_MODE, 0xFF,
 CARD_SHARE_48_SD);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
/* Enable SDIO internal clock */
retval = rtsx_write_register(chip, 0xFF2C, 0x01, 0x01);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
retval = rtsx_write_register(chip, SDIO_CTRL, 0xFF,
 SDIO_BUS_CTRL | SDIO_CD_CTRL);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
chip->sd_int = 1;
chip->sd_io = 1;
@@ -164,16 +161,16 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip 
*chip)
if (chip->driver_first_load) {
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_read_register(chip, 0xFE5A, &tmp);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
if (tmp & 0x08)
sw_bypass_sd = true;
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_read_register(chip, 0xFE70, &tmp);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
if (tmp & 0x80)
sw_bypass_sd = true;
}
@@ -192,9 +189,9 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip *chip)
u8 cd_toggle_mask = 0;
 
retval = rtsx_read_register(chip, TLPTISTAT, &tmp);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
cd_toggle_mask = 0x08;
 
if (tmp & cd_toggle_mask) {
@@ -202,22 +199,20 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip 
*chip)
if (CHECK_PID(chip, 0x5288)) {
retval = rtsx_write_register(chip, 0xFE5A,
 0x08, 0x00);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
} else if (CHECK_PID(chip, 0x5208)) {
retval = rtsx_write_register(chip, 0xFE70,
 0x80, 0x00);
-   if (retval) {
+   if (retval)
return retval;
-   }
}
 
retval = rtsx_write_register(chip, TLPTISTAT, 0xFF,
 tmp);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
chip->need_reset |= SD_CARD;
} else {
@@ -225,36 +220,35 @@ static int rtsx_pre_handle_sdio_new(struct rtsx_chip 
*chip)
 
if (chip->asic_code) {
retval = sd_pull_ctl_enable(chip);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
+

Re: [PATCH v2 0/5] Fix some bugs on RV32 build fail and issue

2018-09-28 Thread Zong Li
Palmer Dabbelt  於 2018年9月29日 週六 上午7:52寫道:
>
> On Wed, 26 Sep 2018 01:31:09 PDT (-0700), zong...@gmail.com wrote:
> > This patches contain the modificaion as follows:
> > 1. Fix up the building fail on RV32.
> > 2. Add umoddi3 and udivmoddi4 functions for RV32.
> > 3. Fix ioremap problem on RV32.
> >
> > Changes in v2:
> >  - Retain the copyright notices from libgcc in umoddi3.c and udivmoddi4.c.
> >
> > Vincent Chen (1):
> >   RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap
> >
> > Zong Li (4):
> >   RISC-V: Build tishift only on 64-bit
> >   RISC-V: Use swiotlb on RV64 only
> >   lib: Add umoddi3 and udivmoddi4 of GCC library routines
> >   RISC-V: Select GENERIC_LIB_UMODDI3 on RV32
> >
> >  arch/riscv/Kconfig|   1 +
> >  arch/riscv/kernel/setup.c |   3 +
> >  arch/riscv/lib/Makefile   |   3 +-
> >  arch/riscv/mm/ioremap.c   |   2 +-
> >  lib/Kconfig   |   3 +
> >  lib/Makefile  |   1 +
> >  lib/udivmoddi4.c  | 309 
> > ++
> >  lib/umoddi3.c |  34 +
> >  8 files changed, 354 insertions(+), 2 deletions(-)
> >  create mode 100644 lib/udivmoddi4.c
> >  create mode 100644 lib/umoddi3.c
>
> I like what this does, but there's a license issue here that Christoph pointed
> out.  It'd be great to have RV32I systems booting 4.19, do you think there's a
> chance you can sort this out next week so we can get it into the last RC?  
> That
> would help with the rv32i glibc process, as we'll actually be able to boot an
> upstream kernel.
>
> It looks like the functions we have an issue with come from libgcc2.c, which
> doesn't change very much.  As far as I can tell we might be able to get away
> with these functions from 4.2.1, which was licensed under the GPLv2.  Here's
> the relevant functions on GCC's github mirror
>
> 
> https://github.com/gcc-mirror/gcc/blob/gcc-4_2_1-release/gcc/libgcc2.c#L559
> 
> https://github.com/gcc-mirror/gcc/blob/gcc-4_2_1-release/gcc/libgcc2.c#L844
>
> These look very similar to what you send out.  As far as I can tell, if you
> base your code on the GPLv2 version then this should be fine to include.
>
> Thanks!

Thanks for the help and useful information. I will modify the
implementation and submit the next version.


Re: [PATCH 3/4] infiniband/mm: convert to the new put_user_page() call

2018-09-28 Thread John Hubbard
On 9/28/18 8:39 AM, Jason Gunthorpe wrote:
> On Thu, Sep 27, 2018 at 10:39:47PM -0700, john.hubb...@gmail.com wrote:
>> From: John Hubbard 
[...]
>>
>> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
>> index a41792dbae1f..9430d697cb9f 100644
>> +++ b/drivers/infiniband/core/umem.c
>> @@ -60,7 +60,7 @@ static void __ib_umem_release(struct ib_device *dev, 
>> struct ib_umem *umem, int d
>>  page = sg_page(sg);
>>  if (!PageDirty(page) && umem->writable && dirty)
>>  set_page_dirty_lock(page);
>> -put_page(page);
>> +put_user_page(page);
> 
> Would it make sense to have a release/put_user_pages_dirtied to absorb
> the set_page_dity pattern too? I notice in this patch there is some
> variety here, I wonder what is the right way?
> 
> Also, I'm told this code here is a big performance bottleneck when the
> number of pages becomes very long (think >> GB of memory), so having a
> future path to use some kind of batching/threading sound great.
> 

Yes. And you asked for this the first time, too. Consistent! :) Sorry for
being slow to pick it up. It looks like there are several patterns, and
we have to support both set_page_dirty() and set_page_dirty_lock(). So
the best combination looks to be adding a few variations of
release_user_pages*(), but leaving put_user_page() alone, because it's
the "do it yourself" basic one. Scatter-gather will be stuck with that.

Here's a differential patch with that, that shows a nice little cleanup in 
a couple of IB places, and as you point out, it also provides the hooks for 
performance upgrades (via batching) in the future.

Does this API look about right?

diff --git a/drivers/infiniband/hw/hfi1/user_pages.c 
b/drivers/infiniband/hw/hfi1/user_pages.c
index c7516029af33..48afec362c31 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -123,11 +123,7 @@ void hfi1_release_user_pages(struct mm_struct *mm, struct 
page **p,
 {
size_t i;
 
-   for (i = 0; i < npages; i++) {
-   if (dirty)
-   set_page_dirty_lock(p[i]);
-   put_user_page(p[i]);
-   }
+   release_user_pages_lock(p, npages, dirty);
 
if (mm) { /* during close after signal, mm can be NULL */
down_write(&mm->mmap_sem);
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c 
b/drivers/infiniband/hw/qib/qib_user_pages.c
index 3f8fd42dd7fc..c57a3a6730b6 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -40,13 +40,7 @@
 static void __qib_release_user_pages(struct page **p, size_t num_pages,
 int dirty)
 {
-   size_t i;
-
-   for (i = 0; i < num_pages; i++) {
-   if (dirty)
-   set_page_dirty_lock(p[i]);
-   put_user_page(p[i]);
-   }
+   release_user_pages_lock(p, num_pages, dirty);
 }
 
 /*
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 72caf803115f..b280d0181e06 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -138,6 +138,9 @@ extern int overcommit_ratio_handler(struct ctl_table *, 
int, void __user *,
 extern int overcommit_kbytes_handler(struct ctl_table *, int, void __user *,
size_t *, loff_t *);
 
+int set_page_dirty(struct page *page);
+int set_page_dirty_lock(struct page *page);
+
 #define nth_page(page,n) pfn_to_page(page_to_pfn((page)) + (n))
 
 /* to align the pointer to the (next) page boundary */
@@ -949,12 +952,56 @@ static inline void put_user_page(struct page *page)
put_page(page);
 }
 
-/* A drop-in replacement for release_pages(): */
+/* For get_user_pages*()-pinned pages, use these variants instead of
+ * release_pages():
+ */
+static inline void release_user_pages_dirty(struct page **pages,
+   unsigned long npages)
+{
+   while (npages) {
+   set_page_dirty(pages[npages]);
+   put_user_page(pages[npages]);
+   --npages;
+   }
+}
+
+static inline void release_user_pages_dirty_lock(struct page **pages,
+unsigned long npages)
+{
+   while (npages) {
+   set_page_dirty_lock(pages[npages]);
+   put_user_page(pages[npages]);
+   --npages;
+   }
+}
+
+static inline void release_user_pages_basic(struct page **pages,
+   unsigned long npages)
+{
+   while (npages) {
+   put_user_page(pages[npages]);
+   --npages;
+   }
+}
+
 static inline void release_user_pages(struct page **pages,
- unsigned long npages)
+ unsigned long npages,
+ bool set_dirty)
 {
-   while (npages)
-   put_user_page(pages[--npag

RE: linux-next: manual merge of the rdma tree with Linus' tree

2018-09-28 Thread Parav Pandit
Hi Stephen,

> -Original Message-
> From: Stephen Rothwell 
> Sent: Thursday, September 27, 2018 7:01 PM
> To: Doug Ledford ; Jason Gunthorpe
> 
> Cc: Linux-Next Mailing List ; Linux Kernel
> Mailing List ; Parav Pandit
> 
> Subject: linux-next: manual merge of the rdma tree with Linus' tree
> 
> Hi all,
> 
> Today's linux-next merge of the rdma tree got a conflict in:
> 
>   drivers/infiniband/core/cache.c
> 
> between commit:
> 
>   5c5702e259dc ("RDMA/core: Set right entry state before releasing
> reference")
> 
> from Linus' tree and commit:
> 
>   43c7c851b9bc ("RDMA/core: Use dev_err/dbg/etc instead of pr_* + ibdev-
> >name")
> 
> from the rdma tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This is now 
> fixed
> as far as linux-next is concerned, but any non trivial conflicts should be
> mentioned to your upstream maintainer when your tree is submitted for
> merging.  You may also want to consider cooperating with the maintainer of
> the conflicting tree to minimise any particularly complex conflicts.
> 

Sorry for the late reply. For some reason mail ended up in spam folder which I 
noticed now.
I should have watched the device naming series.
My fix went to for-rc and I guess it wasn't applied to for-next which resulted 
into this merge conflict.
My understanding is, maintainers usually try to avoid merge conflict between 
for-next and for-rc branches before sending pull request from rdma tree.
I will try to be more careful in future to notify maintainer about it.

Your changes below looks good. Thanks.
Reviewed-by: Parav Pandit  
> --
> Cheers,
> Stephen Rothwell
> 
> diff --cc drivers/infiniband/core/cache.c index
> 3208ad6ad540,ebc64418d809..
> --- a/drivers/infiniband/core/cache.c
> +++ b/drivers/infiniband/core/cache.c
> @@@ -337,39 -335,6 +335,38 @@@ static int add_roce_gid(struct ib_gid_t
>   return 0;
>   }
> 
>  +/**
>  + * del_gid - Delete GID table entry
>  + *
>  + * @ib_dev: IB device whose GID entry to be deleted
>  + * @port:   Port number of the IB device
>  + * @table:  GID table of the IB device for a port
>  + * @ix: GID entry index to delete
>  + *
>  + */
>  +static void del_gid(struct ib_device *ib_dev, u8 port,
>  +struct ib_gid_table *table, int ix)
>  +{
>  +struct ib_gid_table_entry *entry;
>  +
>  +lockdep_assert_held(&table->lock);
>  +
> - pr_debug("%s device=%s port=%d index=%d gid %pI6\n", __func__,
> -  ib_dev->name, port, ix,
> -  table->data_vec[ix]->attr.gid.raw);
> ++dev_dbg(&ib_dev->dev, "%s port=%d index=%d gid %pI6\n",
>__func__, port,
> ++ix, table->data_vec[ix]->attr.gid.raw);
>  +
>  +write_lock_irq(&table->rwlock);
>  +entry = table->data_vec[ix];
>  +entry->state = GID_TABLE_ENTRY_PENDING_DEL;
>  +/*
>  + * For non RoCE protocol, GID entry slot is ready to use.
>  + */
>  +if (!rdma_protocol_roce(ib_dev, port))
>  +table->data_vec[ix] = NULL;
>  +write_unlock_irq(&table->rwlock);
>  +
>  +put_gid_entry_locked(entry);
>  +}
>  +
>   /**
>* add_modify_gid - Add or modify GID table entry
>*


Re: [PATCH] arm: support big-endian for the virt architecture

2018-09-28 Thread Jason A. Donenfeld
Hey Arnd,

On Fri, Sep 28, 2018 at 9:19 PM Arnd Bergmann  wrote:
> You can probably work around it by enabling ARCH_HIGHBANK,
> which is a minimal platform with no other requirements, so it
> should only add a few milliseconds to the build.

Nice hack, thanks for the suggestion. Committed here:
https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/WireGuard.git/commit/?id=56ff2eb9480e6c691a5b8d8ff1fa01090df61e1d

> Another option would be to do the testing on top of linux-next,
> which should have your fix starting on Monday. Testing on
> linux-next carries a higher risk of running into unrelated
> regressions, but also lets you find out about conflicts with
> other patches early on.

I do actually test on linux-next (and tons of other kernels too), but
I like to have things working for at least the latest mainline.

Jason


Re: [PATCH 2/2] mmc: mediatek: add bus_clk control

2018-09-28 Thread Chaotian Jing
On Sat, 2018-09-29 at 01:28 +0800, Sean Wang wrote:
> Hi,
> 
> On Fri, 2018-09-28 at 19:40 +0800, Chaotian Jing wrote:
> > when gate MSDC0_HCLK, access register will hang, even the MSDC driver
> > will never accessing register after HCLK was gated, but for safety, need
> > gate the bus_clk(which used to access register) too.
> > 
> > Signed-off-by: Chaotian Jing 
> > ---
> >  drivers/mmc/host/mtk-sd.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> > index 0484138..1c1c967 100644
> > --- a/drivers/mmc/host/mtk-sd.c
> > +++ b/drivers/mmc/host/mtk-sd.c
> > @@ -387,6 +387,7 @@ struct msdc_host {
> >  
> > struct clk *src_clk;/* msdc source clock */
> > struct clk *h_clk;  /* msdc h_clk */
> > +   struct clk *bus_clk;/* bus clock which used to access register */
> > struct clk *src_clk_cg; /* msdc source clock control gate */
> > u32 mclk;   /* mmc subsystem clock frequency */
> > u32 src_clk_freq;   /* source clock frequency */
> > @@ -660,12 +661,14 @@ static void msdc_gate_clock(struct msdc_host *host)
> >  {
> > clk_disable_unprepare(host->src_clk_cg);
> > clk_disable_unprepare(host->src_clk);
> > +   clk_disable_unprepare(host->bus_clk);
> > clk_disable_unprepare(host->h_clk);
> >  }
> >  
> >  static void msdc_ungate_clock(struct msdc_host *host)
> >  {
> > clk_prepare_enable(host->h_clk);
> > +   clk_prepare_enable(host->bus_clk);
> > clk_prepare_enable(host->src_clk);
> > clk_prepare_enable(host->src_clk_cg);
> > while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
> > @@ -1900,6 +1903,9 @@ static int msdc_drv_probe(struct platform_device 
> > *pdev)
> > goto host_free;
> > }
> >  
> > +   host->bus_clk = devm_clk_get(&pdev->dev, "bus_clk");
> > +   if (IS_ERR(host->bus_clk))
> > +   host->bus_clk = NULL;
> 
> The implementation would cause all SoCs to treat the bus_clk as the optional.
> It seems you should add a flag to see what SoC requires the bus_clk to 
> successfully access the related registers.

>  Yes, but is no harm to other SoCs, just like the handle of "source_cg"
> > /*source clock control gate is optional clock*/
> > host->src_clk_cg = devm_clk_get(&pdev->dev, "source_cg");
> > if (IS_ERR(host->src_clk_cg))
> 
> 




Re: [PATCH 1/2] mmc: dt-bindings: add "bus-clk" for MT2712

2018-09-28 Thread Chaotian Jing
On Sat, 2018-09-29 at 01:34 +0800, Sean Wang wrote:
> On Fri, 2018-09-28 at 19:40 +0800, Chaotian Jing wrote:
> > On MT2712 MSDC0/3, HCLK/bus-clk need gate/ungate together,
> > or will hang when access MSDC register.
> > 
> > Signed-off-by: Chaotian Jing 
> > ---
> >  Documentation/devicetree/bindings/mmc/mtk-sd.txt | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
> > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > index f33467a..182299b 100644
> > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> > @@ -22,6 +22,7 @@ Required properties:
> > "source" - source clock (required)
> > "hclk" - HCLK which used for host (required)
> > "source_cg" - independent source clock gate (required for MT2712)
> > +   "bus_clk" - bus clk used for internal register access(required for 
> > MT2712 MSDC0/3)
> 
> use a full name in the description such as changing "clk" to "clock" and
> 
> add an extra blank char prior to left parenthesis
> 
OK, fixed at v1 version.

> >  - pinctrl-names: should be "default", "state_uhs"
> >  - pinctrl-0: should contain default/high speed pin ctrl
> >  - pinctrl-1: should contain uhs mode pin ctrl
> 
> 




[PATCH v1 2/2] mmc: mediatek: add bus_clk control

2018-09-28 Thread Chaotian Jing
when gate MSDC0_HCLK, access register will hang, even the MSDC driver
will never accessing register after HCLK was gated, but for safety, need
gate the bus_clk(which used to access register) too.

Signed-off-by: Chaotian Jing 
---
 drivers/mmc/host/mtk-sd.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 0484138..1c1c967 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -387,6 +387,7 @@ struct msdc_host {
 
struct clk *src_clk;/* msdc source clock */
struct clk *h_clk;  /* msdc h_clk */
+   struct clk *bus_clk;/* bus clock which used to access register */
struct clk *src_clk_cg; /* msdc source clock control gate */
u32 mclk;   /* mmc subsystem clock frequency */
u32 src_clk_freq;   /* source clock frequency */
@@ -660,12 +661,14 @@ static void msdc_gate_clock(struct msdc_host *host)
 {
clk_disable_unprepare(host->src_clk_cg);
clk_disable_unprepare(host->src_clk);
+   clk_disable_unprepare(host->bus_clk);
clk_disable_unprepare(host->h_clk);
 }
 
 static void msdc_ungate_clock(struct msdc_host *host)
 {
clk_prepare_enable(host->h_clk);
+   clk_prepare_enable(host->bus_clk);
clk_prepare_enable(host->src_clk);
clk_prepare_enable(host->src_clk_cg);
while (!(readl(host->base + MSDC_CFG) & MSDC_CFG_CKSTB))
@@ -1900,6 +1903,9 @@ static int msdc_drv_probe(struct platform_device *pdev)
goto host_free;
}
 
+   host->bus_clk = devm_clk_get(&pdev->dev, "bus_clk");
+   if (IS_ERR(host->bus_clk))
+   host->bus_clk = NULL;
/*source clock control gate is optional clock*/
host->src_clk_cg = devm_clk_get(&pdev->dev, "source_cg");
if (IS_ERR(host->src_clk_cg))
-- 
1.8.1.1.dirty



[PATCH v1 1/2] mmc: dt-bindings: add "bus-clk" for MT2712

2018-09-28 Thread Chaotian Jing
On MT2712 MSDC0/3, HCLK/bus-clk need gate/ungate together,
or will hang when access MSDC register.

Signed-off-by: Chaotian Jing 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index f33467a..f2208f4 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -22,6 +22,7 @@ Required properties:
"source" - source clock (required)
"hclk" - HCLK which used for host (required)
"source_cg" - independent source clock gate (required for MT2712)
+   "bus_clk" - bus clock used for internal register access (required for 
MT2712 MSDC0/3)
 - pinctrl-names: should be "default", "state_uhs"
 - pinctrl-0: should contain default/high speed pin ctrl
 - pinctrl-1: should contain uhs mode pin ctrl
-- 
1.8.1.1.dirty



Re: [PATCH 0/4] get_user_pages*() and RDMA: first steps

2018-09-28 Thread John Hubbard
On 9/28/18 2:49 PM, Jerome Glisse wrote:
> On Fri, Sep 28, 2018 at 12:06:12PM -0700, John Hubbard wrote:
>> On 9/28/18 8:29 AM, Jerome Glisse wrote:
>>> On Thu, Sep 27, 2018 at 10:39:45PM -0700, john.hubb...@gmail.com wrote:
 From: John Hubbard 
[...]
>>> So the solution is to wait (possibly for days, months, years) that the
>>> RDMA or GPU which did GUP and do not have mmu notifier, release the page
>>> (or put_user_page()) ?
>>>
>>> This sounds bads. Like i said during LSF/MM there is no way to properly
>>> fix hardware that can not be preempted/invalidated ... most GPU are fine.
>>> Few RDMA are fine, most can not ...
>>>
>>
>> Hi Jerome,
>>
>> Personally, I'm think that this particular design is the best one I've seen
>> so far, but if other, better designs show up, than let's do those instead, 
>> sure.
>>
>> I guess your main concern is that this might take longer than other 
>> approaches.
>>
>> As for time frame, perhaps I made it sound worse than it really is. I have 
>> patches
>> staged already for all of the simpler call sites, and for about half of the 
>> more
>> complicated ones. The core solution in mm is not large, and we've gone 
>> through a 
>> few discussion threads about it back in July or so, so it shouldn't take too 
>> long
>> to perfect it.
>>
>> So it may be a few months to get it all reviewed and submitted, but I don't
>> see "years" by any stretch.
> 
> Bit of miss-comprehention there :) By month, years, i am talking about
> the time it will take for some user to release the pin they have on the
> page. Not the time to push something upstream.
> 
> AFAICT RDMA driver do not have any upper bound on how long they can hold
> a page reference and thus your solution can leave one CPU core stuck for
> as long as the pin is active. Worst case might lead to all CPU core waiting
> for something that might never happen.
> 

Actually, the latest direction on that discussion was toward periodically
writing back, even while under RDMA, via bounce buffers:

  https://lkml.kernel.org/r/20180710082100.mkdwngdv5kkrc...@quack2.suse.cz

I still think that's viable. Of course, there are other things besides 
writeback (see below) that might also lead to waiting.

>>> If it is just about fixing the set_page_dirty() bug then just looking at
>>> refcount versus mapcount should already tell you if you can remove the
>>> buffer head from the page or not. Which would fix the bug without complex
>>> changes (i still like the put_user_page just for symetry with GUP).
>>>
>>
>> It's about more than that. The goal is to make it safe and correct to
>> use a non-CPU device to read and write to "pinned" memory, especially when
>> that memory is backed by a file system.
>>
>> I recall there were objections to just narrowly fixing the set_page_dirty()
>> bug, because the underlying problem is large and serious. So here we are.
> 
> Except that you can not solve that issue without proper hardware. GPU are
> fine. RDMA are broken except the mellanox5 hardware which can invalidate
> at anytime its page table thus allowing to write protect the page at any
> time.

Today, people are out there using RDMA without page-fault-capable hardware.
And they are hitting problems, as we've seen. From the discussions so far,
I don't think it's impossible to solve the problems, even for "lesser", 
non-fault-capable hardware. Especially once we decide on what is reasonable
and supported.  Certainly the existing situation needs *something* to 
change, even if it's (I don't recommend this) "go forth and tell the world
to stop using RDMA with their current hardware".

> 
> With the solution put forward here you can potentialy wait _forever_ for
> the driver that holds a pin to drop it. This was the point i was trying to
> get accross during LSF/MM. 

I agree that just blocking indefinitely is generally unacceptable for kernel
code, but we can probably avoid it for many cases (bounce buffers), and
if we think it is really appropriate (file system unmounting, maybe?) then
maybe tolerate it in some rare cases.  

>You can not fix broken hardware that decided to
> use GUP to do a feature they can't reliably do because their hardware is
> not capable to behave.
> 
> Because code is easier here is what i was meaning:
> 
> https://cgit.freedesktop.org/~glisse/linux/commit/?h=gup&id=a5dbc0fe7e71d347067579f13579df372ec48389
> https://cgit.freedesktop.org/~glisse/linux/commit/?h=gup&id=01677bc039c791a16d5f82b3ef84917d62fac826
> 

While that may work sometimes, I don't think it is reliable enough to trust for
identifying pages that have been gup-pinned. There's just too much overloading 
of
other mechanisms going on there, and if we pile on top with this constraint of 
"if you
have +3 refcounts, and this particular combination of page counts and 
mapcounts, then
you're definitely a long-term pinned page", I think users will find a lot of 
corner
cases for us that break that assumption. 

So I think we agree that the put_user_page() approach

Re: Bad MAINTAINERS pattern in section 'ARM/Synaptics Berlin SoC support'

2018-09-28 Thread Jisheng Zhang
On Fri, 28 Sep 2018 14:51:32 -0700 Joe Perches  wrote:

> Please fix this defect appropriately.
> 
> linux-next MAINTAINERS section:
> 
>   2111ARM/Synaptics Berlin SoC support
>   2112M:  Jisheng Zhang 
>   2113M:  Sebastian Hesselbarth 
>   2114L:  linux-arm-ker...@lists.infradead.org (moderated for 
> non-subscribers)
>   2115S:  Maintained
>   2116F:  arch/arm/mach-berlin/
>   2117F:  arch/arm/boot/dts/berlin*
> -->   2118F:  arch/arm64/boot/dts/marvell/berlin*  

Thanks so much. I will fix it soon.

> 
> Commit that introduced this:
> 
> commit bc52497a595d2246923749177d99e4216703b0f4
>  Author: Jisheng Zhang 
>  Date:   Fri Mar 30 11:02:11 2018 +0800
>  
>  MAINTAINERS: update entry for ARM/berlin
>  
>  Synaptics has acquired the Multimedia Solutions Business of Marvell[1].
>  So change the berlin entry name and move it to its alphabetical
>  location. We move to ARM/Synaptics instead of ARM/Marvell.
>  
>  This patch also updates my email address from marvell to synaptics.
>  
>  [1] https://www.synaptics.com/company/news/conexant-marvell
>  
>  Signed-off-by: Jisheng Zhang 
>  Reviewed-by: Andrew Lunn 
>  Signed-off-by: Arnd Bergmann 
>  
>   MAINTAINERS | 18 +-
>   1 file changed, 9 insertions(+), 9 deletions(-)
> 
> Last commit with arch/arm64/boot/dts/marvell/berlin*
> 
> commit 031106ce95a201f6dd4c5ebf35abb900cf34e2ba
> Author: Jisheng Zhang 
> Date:   Wed May 16 17:43:28 2018 +0800
> 
> arm64: dts: move berlin SoC files from marvell dir to synaptics dir
> 
> Move device tree files as part of transition from Marvell berlin to
> Synaptics berlin.
> 
> Signed-off-by: Jisheng Zhang 
> 
>  arch/arm64/boot/dts/Makefile | 1 +
>  arch/arm64/boot/dts/marvell/Makefile | 4 
>  arch/arm64/boot/dts/synaptics/Makefile   | 4 
>  arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-dmp.dts | 0
>  arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct-stb.dts | 0
>  arch/arm64/boot/dts/{marvell => synaptics}/berlin4ct.dtsi| 0
>  6 files changed, 5 insertions(+), 4 deletions(-)



[PATCH] Staging: rts5208: rtsx_card: Fixed multiple coding style issues

2018-09-28 Thread Maxime Desroches
Fixed multiple coding style issues

Signed-off-by: Maxime Desroches 
---
 drivers/staging/rts5208/rtsx_card.c | 96 +++--
 1 file changed, 37 insertions(+), 59 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_card.c 
b/drivers/staging/rts5208/rtsx_card.c
index d26a8e372fce..b45abbe29bc2 100644
--- a/drivers/staging/rts5208/rtsx_card.c
+++ b/drivers/staging/rts5208/rtsx_card.c
@@ -647,9 +647,8 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
dev_dbg(rtsx_dev(chip), "Switch SSC clock to %dMHz (cur_clk = %d)\n",
clk, chip->cur_clk);
 
-   if ((clk <= 2) || (n > max_n)) {
+   if ((clk <= 2) || (n > max_n))
return STATUS_FAIL;
-   }
 
mcu_cnt = (u8)(125 / clk + 3);
if (mcu_cnt > 7)
@@ -688,15 +687,13 @@ int switch_ssc_clock(struct rtsx_chip *chip, int clk)
}
 
retval = rtsx_send_cmd(chip, 0, WAIT_TIME);
-   if (retval < 0) {
+   if (retval < 0)
return STATUS_ERROR;
-   }
 
udelay(10);
retval = rtsx_write_register(chip, CLK_CTL, CLK_LOW_FREQ, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
chip->cur_clk = clk;
 
@@ -790,49 +787,44 @@ int switch_normal_clock(struct rtsx_chip *chip, int clk)
}
 
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, CLK_LOW_FREQ);
-   if (retval) {
+   if (retval)
return retval;
-   }
if (sd_vpclk_phase_reset) {
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
 PHASE_NOT_RESET, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
 PHASE_NOT_RESET, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
}
retval = rtsx_write_register(chip, CLK_DIV, 0xFF,
 (div << 4) | mcu_cnt);
-   if (retval) {
+   if (retval)
return retval;
-   }
retval = rtsx_write_register(chip, CLK_SEL, 0xFF, sel);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
if (sd_vpclk_phase_reset) {
udelay(200);
retval = rtsx_write_register(chip, SD_VPCLK0_CTL,
 PHASE_NOT_RESET, PHASE_NOT_RESET);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
retval = rtsx_write_register(chip, SD_VPCLK1_CTL,
 PHASE_NOT_RESET, PHASE_NOT_RESET);
-   if (retval) {
+   if (retval)
return retval;
-   }
+
udelay(200);
}
retval = rtsx_write_register(chip, CLK_CTL, 0xFF, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
chip->cur_clk = clk;
 
@@ -878,9 +870,8 @@ int enable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
 
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, clk_en);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
return STATUS_SUCCESS;
 }
@@ -898,9 +889,8 @@ int disable_card_clock(struct rtsx_chip *chip, u8 card)
clk_en |= MS_CLK_EN;
 
retval = rtsx_write_register(chip, CARD_CLK_EN, clk_en, 0);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
return STATUS_SUCCESS;
 }
@@ -924,9 +914,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val1);
 
retval = rtsx_send_cmd(chip, 0, 100);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
 
udelay(chip->pmos_pwr_on_interval);
 
@@ -934,9 +923,8 @@ int card_power_on(struct rtsx_chip *chip, u8 card)
rtsx_add_cmd(chip, WRITE_REG_CMD, CARD_PWR_CTL, mask, val2);
 
retval = rtsx_send_cmd(chip, 0, 100);
-   if (retval != STATUS_SUCCESS) {
+   if (retval != STATUS_SUCCESS)
return STATUS_FAIL;
-   }
 
return STATUS_SUCCESS;
 }
@@ -955,9 +943,8 @@ int card_power_off(struct rtsx_chip *chip, u8 card)
}
 
retval = rtsx_write_register(chip, CARD_PWR_CTL, mask, val);
-   if (retval) {
+   if (retval)
return retval;
-   }
 
return STATUS_SUCCESS;
 }
@@ -969,9 +956,8 @@ int card_rw(struct scsi_cmnd *srb, struct rtsx_chip *chip,
unsigned int lun = SCSI_LUN(srb);
int i;
 
-   if (!chip->rw_card[lun]) {
+   if (!chip->rw_card[lun])
retur

Re: [PATCH] RISC-V: Show CPU ID and Hart ID separately in /proc/cpuinfo

2018-09-28 Thread Palmer Dabbelt

On Wed, 12 Sep 2018 07:38:22 PDT (-0700), a...@brainfault.org wrote:

Currently, /proc/cpuinfo show logical CPU ID as Hart ID which
is in-correct. This patch shows CPU ID and Hart ID separately
in /proc/cpuinfo using cpuid_to_hardid_map().

With this patch, contents of /proc/cpuinfo looks as follows:
cpu : 0
hart: 1
isa : rv64imafdcsu
mmu : sv48

cpu : 1
hart: 0
isa : rv64imafdcsu
mmu : sv48

cpu : 2
hart: 3
isa : rv64imafdcsu
mmu : sv48

cpu : 3
hart: 2
isa : rv64imafdcsu
mmu : sv48

Signed-off-by: Anup Patel 
---
 arch/riscv/kernel/cpu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index f0f0ec2737b7..7c1342e242e6 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -87,7 +87,8 @@ static int c_show(struct seq_file *m, void *v)
   NULL);
const char *compat, *isa, *mmu;

-   seq_printf(m, "hart\t: %lu\n", cpu_id);
+   seq_printf(m, "cpu\t: %lu\n", cpu_id);
+   seq_printf(m, "hart\t: %lu\n", cpuid_to_hardid_map(cpu_id));
if (!of_property_read_string(node, "riscv,isa", &isa)
&& isa[0] == 'r'
&& isa[1] == 'v')


I like this, but it doesn't appear to apply.  Do you mind sending something 
against Linus' master?  Then I should be able to sort it out.


Thanks!


Re: [RFC PATCH 1/5] RISC-V: Make IPI triggering flexible

2018-09-28 Thread Palmer Dabbelt

On Mon, 10 Sep 2018 06:34:18 PDT (-0700), Christoph Hellwig wrote:

On Thu, Sep 06, 2018 at 04:15:14PM +0530, Anup Patel wrote:

This patch is doing two things:
1. Allow IRQCHIP driver to provide IPI trigger mechanism


And the big questions is why do we want that?  The last thing we
want is for people to "innovate" on how they deliver IPIs.  RISC-V
has defined an SBI interface for it to hide all the details, and
we should not try to handle systems that are not SBI compliant.

Eventuall we might want to revisit the SBI to improve on shortcomings
if there are any, but we should not allow random irqchip drivers to
override this.


I agree.  The whole point of the SBI is to provide an interface that everyone 
uses so we can the go figure out how to make this fast later.  If each platform 
has their own magic IPI hooks then this will end up being a mess.


We've got some schemes floating around to make the SBI fast (essentially an SBI 
VDSO), I'd prefer to push on that rather than adding a bunch of complexity 
here.





2. Have more generic IPI handler in arch/riscv so that IRQCHIP driver
can call it


And that is rather irrelevant without 1) above.


Re: [PATCH 1/2] of/fdt: Allow architectures to override CONFIG_CMDLINE logic

2018-09-28 Thread Palmer Dabbelt

On Fri, 07 Sep 2018 13:29:03 PDT (-0700), robh...@kernel.org wrote:

On Fri, Sep 7, 2018 at 1:55 PM Paul Burton  wrote:


The CONFIG_CMDLINE-related logic in early_init_dt_scan_chosen() falls
back to copying CONFIG_CMDLINE into boot_command_line/data if the DT has
a /chosen node but that node has no bootargs property or a bootargs
property of length zero.


The Risc-V guys found a similar issue if chosen is missing[1]. I
started a patch[2] to address that, but then looking at the different
arches wasn't sure if I'd break something. I don't recall for sure,
but it may have been MIPS that worried me.


IIRC we actually determined it didn't even work correctly on RISC-V, but I 
never actually got the time to figure out why and then forgot about it.  Sorry!





This is problematic for the MIPS architecture because we support
concatenating arguments from either the DT or the bootloader with those
from CONFIG_CMDLINE, but the behaviour of early_init_dt_scan_chosen()
gives us no way of knowing whether boot_command_line contains arguments
from DT or already contains CONFIG_CMDLINE. This can lead to us
concatenating CONFIG_CMDLINE with itself, duplicating command line
arguments which can be problematic (eg. for earlycon which will attempt
to register the same console twice & warn about it).


If CONFIG_CMDLINE_EXTEND is set, you know it contains CONFIG_CMDLINE.
But I guess part of the problem is MIPS using its own kconfig options.


Move the CONFIG_CMDLINE-related logic to a weak function that
architectures can provide their own version of, such that we continue to
use the existing logic for architectures where it's suitable but also
allow MIPS to override this behaviour such that the architecture code
knows when CONFIG_CMDLINE is used.


More arch specific functions is not what I want. Really, all the
cmdline manipulating logic doesn't belong in DT code, but it shouldn't
be in the arch specific code either IMO. Really it should be some
common kernel function which calls into the DT code to retrieve the DT
bootargs and that's it. Then you can skip calling that kernel function
if you really need non-standard handling.

Perhaps you should consider filling DT bootargs with the cmdline from
bootloader. IOW, make the legacy case look like the non-legacy case
early, and then the kernel doesn't have to deal with both cases later
on.

Rob

[1] https://lkml.org/lkml/2018/3/14/701
[2] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git dt/cmdline


Re: [PATCH] RISC-V: Show IPI stats

2018-09-28 Thread Palmer Dabbelt

On Mon, 10 Sep 2018 06:46:59 PDT (-0700), Christoph Hellwig wrote:

On Fri, Sep 07, 2018 at 06:14:29PM +0530, Anup Patel wrote:

This patch provides arch_show_interrupts() implementation to
show IPI stats via /proc/interrupts.

Now the contents of /proc/interrupts" will look like below:
   CPU0   CPU1   CPU2   CPU3
  8: 17  7  6 14  SiFive PLIC   8  virtio0
 10: 10 10  9 11  SiFive PLIC  10  ttyS0
IPI0:   170673251 79  Rescheduling interrupts
IPI1: 1 12 27  1  Function call interrupts
IPI2: 0  0  0  0  CPU wake-up interrupts

Signed-off-by: Anup Patel 


Thanks, this looks pretty sensible to me.  Maybe we want to also show
timer interrupts if we do this?


IIRC we used to have some issue where the timer interrupt ID in 
/proc/interrupts aliased with a possible PLIC interrupt ID, but that was back 
when we had a big mess of chained interrupt drivers that didn't really talk to 
each other.  I think at some point I might have just removed the timer 
interrupt from /proc/interrupts as a hack, but now that our interrupt 
controller mess is sorted out it'd be better to have it.


I'm fine taking this without the timer interrupts, as something is better than 
nothing.



--- a/arch/riscv/kernel/irq.c
+++ b/arch/riscv/kernel/irq.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 

 /*
  * Possible interrupt causes:
@@ -24,6 +25,14 @@
  */
 #define INTERRUPT_CAUSE_FLAG   (1UL << (__riscv_xlen - 1))

+int arch_show_interrupts(struct seq_file *p, int prec)
+{
+#ifdef CONFIG_SMP
+   show_ipi_stats(p, prec);
+#endif
+   return 0;
+}


If we don't also add timer stats I'd just move arch_show_interrupts
to smp.c and make it conditional.  If we don't this split might make
more sense.


Makes sense, but I think timer interrupts are more interesting to see than IPIs 
so we'll eventually pipe them through.  Might just be my workloads, though :)



+static const char *ipi_names[IPI_MAX] = {
+   [IPI_RESCHEDULE] = "Rescheduling interrupts",
+   [IPI_CALL_FUNC] = "Function call interrupts",
+   [IPI_CALL_WAKEUP] = "CPU wake-up interrupts",
+};


No need for the explicit array size.  Also please use a few tabs to
align this nicely:

static const char *ipi_names[] = {
[IPI_RESCHEDULE]= "Rescheduling interrupts",
[IPI_CALL_FUNC] = "Function call interrupts",
[IPI_CALL_WAKEUP]   = "CPU wake-up interrupts",
};


I don't see a v2 of this, was there one?  If not then I'll just clean up 
ipi_names and drop this on for-next.


Thanks for the patch!


[PATCH] MAINTAINERS: removed staging/ft1000 driver

2018-09-28 Thread Deepa Dinamani
Delete the ft1000 MAINTAINERS entry, concluding the
earlier removal of the driver in commit 6512edec48b2
("staging: ft1000: remove obsolete driver").

Reported-by: Joe Perches 
Signed-off-by: Deepa Dinamani 
---
 MAINTAINERS | 5 -
 1 file changed, 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c62b724bb60..6b29bc4da920 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13908,11 +13908,6 @@ L: linux-er...@lists.ozlabs.org
 S: Maintained
 F: drivers/staging/erofs/
 
-STAGING - FLARION FT1000 DRIVERS
-M: Marek Belisko 
-S: Odd Fixes
-F: drivers/staging/ft1000/
-
 STAGING - INDUSTRIAL IO
 M: Jonathan Cameron 
 L: linux-...@vger.kernel.org
-- 
2.17.1



Re: [git pull] Input updates for v4.19-rc5

2018-09-28 Thread Greg Kroah-Hartman
On Fri, Sep 28, 2018 at 04:57:51PM -0700, Dmitry Torokhov wrote:
> Hi Greg,
> 
> Please pull from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
> 
> to receive updates for the input subsystem. Just a few driver fixes.

Now pulled, thanks.

greg k-h


Re: [GIT PULL] spi fixes for v4.19

2018-09-28 Thread Greg Kroah-Hartman
On Fri, Sep 28, 2018 at 03:30:41PM +0100, Mark Brown wrote:
> The following changes since commit 5223c9c1cbfc0cd4d0a1b50758e0949af3290fa1:
> 
>   spi: spi-fsl-dspi: fix broken DSPI_EOQ_MODE (2018-08-28 20:55:23 +0100)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 
> tags/spi-fix-v4.19-rc5

Now pulled, thanks.

greg k-h


Re: [GIT PULL] regulator fixes for v4.19

2018-09-28 Thread Greg Kroah-Hartman
On Fri, Sep 28, 2018 at 02:42:53PM +0100, Mark Brown wrote:
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> 
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> tags/regulator-v4.19-rc5

Now pulled, thanks.

greg k-h


Re: Bad MAINTAINERS pattern in section 'STAGING - FLARION FT1000 DRIVERS'

2018-09-28 Thread Joe Perches
On Fri, 2018-09-28 at 17:46 -0700, Greg Kroah-Hartman wrote:
> On Fri, Sep 28, 2018 at 03:04:23PM -0700, Joe Perches wrote:
> > Please fix this defect appropriately.
> > 
> > linux-next MAINTAINERS section:
> > 
> > 13899   STAGING - FLARION FT1000 DRIVERS
> > 13900   M:  Marek Belisko 
> > 13901   S:  Odd Fixes
> > --> 13902   F:  drivers/staging/ft1000/
> > 
> > Commit that introduced this:
> > 
> > commit a0138163cfbfdfbdc20e4477c77bd7046bd66bb4
> >  Author: Joe Perches 
> >  Date:   Tue Jul 5 15:21:34 2011 -0700
> >  
> >  MAINTAINERS: Add remaining staging entries
> >  
> >  Add the staging entries from various TODO files
> >  to MAINTAINERS.  Add a few web links as well.
> >  
> >  Miscellaneous staging typo section header fix.
> >  
> >  Signed-off-by: Joe Perches 
> >  Signed-off-by: Greg Kroah-Hartman 
> >  
> >   MAINTAINERS | 69 
> > -
> >   1 file changed, 68 insertions(+), 1 deletion(-)
> 
> So you are going to fix this, considering you created the problem?

_I_ did not create this problem.

You neglected to read the commit information below this in the
parent email.

When I wrote the MAINTAINERS patch in 2011, the files existed.

The files were removed in 2015 and you signed-off on their removal.

--
Last commit with drivers/staging/ft1000/

commit 6512edec48b2ccfe9bb969ce26ebbbcd49de6c4b
Author: Deepa Dinamani 
Date:   Wed Oct 21 18:42:37 2015 -0700

staging: ft1000: remove obsolete driver

Remove support for Qleadtek Flash-OFDM modems. Telecom carrier is
discontinuing service for the radio technology.
See http://www.gtigroup.org/news/ind/2015-08-18/6996.html.

Suggested-by: Arnd Bergmann 
Signed-off-by: Deepa Dinamani 
Acked-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman 
--

> This is an odd request to make of yourself in public, or was this a
> script gone wrong?

It was not a script gone wrong, though the output and emails
were scripted.

> confused,

No worries, it's easy to miss stuff.

fyi: the silly script I wrote is attached

Done using the latest -next with an empty patterns directory

$ perl ./scripts/get_maintainer.pl --self-test=patterns | \
  cut -f2 -d: | \
  while read line ; do \
perl ./dump_section.perl $line \
  done



dump_section.perl
Description: Perl program


Step-by-Step Tutorial: How to Setup Your Own e-Commerce Online Store using WooCommerce 3.4.5, Wordpress 4.9.8, and CentOS 1805 (LAMP) in Amazon AWS Cloud

2018-09-28 Thread Turritopsis Dohrnii Teo En Ming
Step-by-Step Tutorial: How to Setup Your Own e-Commerce Online Store
using WooCommerce 3.4.5, Wordpress 4.9.8, and CentOS 1805 (LAMP) in
Amazon AWS Cloud

Author: Mr. Turritopsis Dohrnii Teo En Ming
Country: Singapore
Date: 28th September 2018 Friday

Document Version: 1809.01

Abbreviations
=

LAMP: Linux + Apache Web Server + MySQL/MariaDB + PHP

WAMP: Windows + Apache Web Server + MySQL/MariaDB + PHP

SECTION 1 CREATING YOUR CENTOS 7.5 (1805) LINUX INSTANCE


001. Login to Amazon Web Services.

002. Click Services > Compute > EC2.

003. Click Network & Security > Key Pairs

004. Click Create Key Pair.

005. Enter your key pair name. Then click Create.

006. Be sure to download your private key in the form of a .PEM file.
You will need to convert it to a .PPK file later.

007. Click Instances > Instances.

008. Click Launch Instance.

009. Click AWS Marketplace.

010. Search for CentOS.

011. Select CentOS 7 (x86_64) - with Updates HVM Amazon Machine Image (AMI).

012. Click Continue.

013. Select General Purpose, t2.micro, 1 vCPU, 1 GB RAM (FREE TIER ELIGIBLE).

014. Click Next: Configure Instance Details.

015. Select Network: 

016. Select Subnet: 

017. Click Protect against accidental termination.

018. Click Next: Add Storage.

019. Click Next: Add Tags. Click Add tag.

020. Enter Key = Name and Value = Online Store.

021. Click Next: Configure Security Group

022. Click Select an existing security group.

023. Select VS_SG (Virtual Server Security Group).

024. Click Review and Launch. Click Launch.

025. Select a key pair. Click Launch Instances.

026. Click View Instances.

027. Click Network & Security > Elastic IPs.

028. Select an unused IPv4 address.

029. Click Actions > Associate address.

030. Select the Online Store instance.

031. Click Allow Elastic IP to be reassociated if already attached.

032. Click Associate. Click Close.

033. Login to CentOS 7.5 Linux using Putty.

SECTION 2 INSTALLING WORDPRESS 4.9.8


034. sudo yum install php php-mysql php-devel php-gd php-pecl-memcache
php-pspell php-snmp php-xmlrpc php-xml

Guide: How To Install MySQL / MariaDB on CentOS 7

Link: https://www.liquidweb.com/kb/how-to-install-mysql-mariadb-on-centos-7/

035. sudo yum -y install mariadb-server mariadb

036. sudo yum install wget

Guide: Installing WordPress: Detailed Instructions

Link: https://codex.wordpress.org/Installing_WordPress#Detailed_Instructions

037. wget https://wordpress.org/latest.tar.gz

038. tar xfvz latest.tar.gz

039. sudo passwd root

040. su -

041. systemctl start mariadb

042. systemctl enable mariadb

043. mysql

044. MariaDB [(none)]> CREATE DATABASE wordpress;

045. MariaDB [(none)]> GRANT ALL PRIVILEGES ON wordpress.* TO
"wordpress"@"localhost" IDENTIFIED BY "password";

046. MariaDB [(none)]> FLUSH PRIVILEGES;

047. MariaDB [(none)]> EXIT

048. cd /home/centos/wordpress

AFAIK Wordpress 4.9.8 cannot be installed in a subdirectory. If you
encounter a HTTP error code 500 doing so, be sure to check the Apache
Web Server error logs, that is, tail -f /var/log/httpd/error_log.

049. cp -R * /var/www/html

050. systemctl start httpd

051. systemctl enable httpd

052. sudo yum install nano

053. nano /etc/httpd/conf/httpd.conf

054. Append the following line

AddType application/x-httpd-php .php

055. systemctl restart httpd

Wordpress 4.9.8's PHP code won't execute on php-5.4.16, which is
installed by default on CentOS 7.5. It will return a HTTP error code
of 500. Install PHP-7.2.10 instead.

Guide: How to Install PHP 7 in CentOS 7

Link: https://www.tecmint.com/install-php-7-in-centos-7/

056. yum install
https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

057. yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm

058. yum install yum-utils

You will need minimum PHP 7.2.

059. yum-config-manager --enable remi-php72

060. yum install php php-mcrypt php-cli php-gd php-curl php-mysql
php-ldap php-zip php-fileinfo

061. php -v

PHP 7.2.10 is now installed.

062. systemctl stop httpd && systemctl start httpd

063. Go to http://

064. Click Let's go!

065. Fill in the following MySQL/MariaDB database connection information.

Database Name: wordpress

Username: wordpress

Password: password

Database Host: localhost

Table Prefix: wp_

066. Click Submit.

067. cd /var/www/html

068. nano wp-config.php

069. Copy and paste the contents of wp-config.php shown on the
Wordpress installation screen on your browser.

070. Click Run the installation.

071. Fill in the following information.

Site Title: Teo En Ming Corporation Online Store

Username: admin

Password: password

Your email: u...@example.com

Uncheck Discourage search engines from indexing this site

072. Click Install wordpress.

073. Click Login.

SECTION 3 INSTALLING WOOCOMMERCE 3.4.5
==

Follow the WooCommerce installation guide here:

https://doc

Re: [PATCH] sched/fair: vruntime should normalize when switching from fair

2018-09-28 Thread Wanpeng Li
On Sat, 29 Sep 2018 at 01:36, Dietmar Eggemann  wrote:
>
> On 09/28/2018 06:10 PM, Steve Muckle wrote:
> > On 09/27/2018 05:43 PM, Wanpeng Li wrote:
>  On your CPU4:
>  scheduler_ipi()
> -> sched_ttwu_pending()
>  -> ttwu_do_activate()=> p->sched_remote_wakeup should be
>  false, so ENQUEUE_WAKEUP is set, ENQUEUE_MIGRATED is not
>   -> ttwu_activate()
>    -> activate_task()
> -> enqueue_task()
>  -> enqueue_task_fair()
>   -> enqueue_entity()
>    bool renorm = !(flags &
>  ENQUEUE_WAKEUP) || (flags & ENQUEUE_MIGRATE)
>  so renorm is false in enqueue_entity(), why you mentioned that the
>  cfs_rq->min_vruntime is still added to the se->vruntime in
>  enqueue_task_fair()?
> >>>
> >>> Maybe this is a misunderstanding on my side but didn't you asked me to
> >>> '... Could you point out when the fair rq's min_vruntime is added to the
> >>> task's vruntime in your *later* scenario? ...'
> >>
> >> Yeah, if the calltrace above and my analysis is correct, then the fair
> >> rq's min_vruntime will not be added to the task's vruntime in your
> >> *later* scenario, which means that your patch is not necessary.
> >
> > In the scenario I observed, the task is not waking - it is running and
> > being deboosted from priority inheritance, transitioning from RT to CFS.
> >
> > Dietmar and I both were able to reproduce the issue with the testcase I
> > posted earlier in this thread.
>
> Correct, and with the same testcase I got this call stack in this scenario:
>
> [   35.588509] CPU: 1 PID: 2926 Comm: fair_task Not tainted
> 4.18.0-rc6-00052-g11b7dafa2edb-dirty #5
> [   35.597217] Hardware name: ARM Juno development board (r0) (DT)
> [   35.603080] Call trace:
> [   35.605509]  dump_backtrace+0x0/0x168
> [   35.609138]  show_stack+0x24/0x30
> [   35.612424]  dump_stack+0xac/0xe4
> [   35.615710]  enqueue_task_fair+0xae0/0x11c0
> [   35.619854]  rt_mutex_setprio+0x5a0/0x628
> [   35.623827]  mark_wakeup_next_waiter+0x7c/0xc8
> [   35.628228]  __rt_mutex_futex_unlock+0x30/0x50
> [   35.632630]  do_futex+0x74c/0xb28
> [   35.635912]  sys_futex+0x118/0x198
> [   35.639280]  el0_svc_naked+0x30/0x34

Thanks for pointing out. :)

Regards,
Wanpeng Li


Re: [GIT PULL] pin control fixes for v4.19 take 4

2018-09-28 Thread Greg KH
On Fri, Sep 28, 2018 at 08:59:32AM +0200, Linus Walleij wrote:
> Hi Greg,
> 
> here are some three pin control fixes for v4.19.
> All are x86 related.
> 
> Please pull them in!

Now pulled, thanks.

greg k-h


Re: Licenses and revocability, in a paragraph or less.

2018-09-28 Thread freedomfromruin
It is imperative that the people know their rights so that they are not 
taken advantage of by moneyed interests.


For those who are dispossessed there are remedies at law and in equity.

Here we have a situation where moneyed interests have found a social 
exploit to leverage into ascendancy, while
those who created the edifice which they have willed to conquer are shut 
out.


On 2018-09-28 03:56, Eric S. Raymond wrote:

freedomfromr...@aaathats3as.com :

As has been stated in easily accessible terms elsewhere:
"Most courts hold that simple, non-exclusive licenses with unspecified
durations that are silent on revocability are revocable at will. This 
means
that the licensor may terminate the license at any time, with or 
without

cause." +


Furthermore, license revocation is not the only option. In Jacobsen
vs. Katzer (535 F.3d 1373 (Fed. Cir. 2008) it was found that
open-source developers have an actionable right not to have their
software misappropriated even though the resulting damages are only
reputational rather than monetary.

Under that theory, developers can seek an injunction against a
misappropriating party without globally revoking their license.
The application of that case law to this situation is left as
an easy exercise for the reader.  Any competent paralegal could
write the brief in an evening. Hell, I could almost do it myself.

I do not personally want to see this happen.  But that it is possible
is a fact all parties must deal with.


Again: Licenses and revocability, in a paragraph or less. GPL 2 is revocable at the will of the grantor.

2018-09-28 Thread freedomfromruin

As has been stated in easily accessible terms elsewhere:
"Most courts hold that simple, non-exclusive licenses with unspecified 
durations that are silent on revocability are revocable at will. This 
means that the licensor may terminate the license at any time, with or 
without cause." +


Version 2 of the GPL specifies no duration, nor does it declare that it 
is non-revocable by the grantor.


(Also note: A perpetual license may violate the rule against 
perpetuities in various jurisdictions where it is applied not only to 
real property but additionally to personal property (and the like), 
which is why the GPL-3's term of duration is set as the duration of 
copyright on the program (and not "forever"))


+[https://www.sidley.com/en/insights/newsupdates/2013/02/the-terms-revocable-and-irrevocable-in-license-agreements-tips-and-pitfalls]




Re: [PATCH -V5 RESEND 03/21] swap: Support PMD swap mapping in swap_duplicate()

2018-09-28 Thread Huang, Ying
Daniel Jordan  writes:

> On Fri, Sep 28, 2018 at 04:19:03PM +0800, Huang, Ying wrote:
>> Daniel Jordan  writes:
>> > One way is to change
>> > copy_one_pte's return to int so we can just pass the error code back to
>> > copy_pte_range so it knows whether to try adding the continuation.
>> 
>> There may be even more problems.  After add_swap_count_continuation(),
>> copy_one_pte() will be retried, and the CPU may hang with dead loop.
>
> That's true, it would do that.
>
>> But before the changes in this patchset, the behavior is,
>> __swap_duplicate() return an error that isn't -ENOMEM, such as -EEXIST.
>> Then copy_one_pte() would thought the operation has been done
>> successfully, and go to call set_pte_at().  This will cause the system
>> state become inconsistent, and the system may panic or hang somewhere
>> later.
>> 
>> So per my understanding, if we thought page table corruption isn't a
>> real problem (that is, __swap_duplicate() will never return e.g. -EEXIST
>> if copied by copy_one_pte() indirectly), both the original and the new
>> code should be OK.
>> 
>> If we thought it is a real problem, we need to fix the original code and
>> keep it fixed in the new code.  Do you agree?
>
> Yes, if it was a real problem, which seems less and less the case the more I
> stare at this.
>
>> There's several ways to fix the problem.  But the page table shouldn't
>> be corrupted in practice, unless there's some programming error.  So I
>> suggest to make it as simple as possible via adding,
>> 
>> VM_BUG_ON(error != -ENOMEM);
>> 
>> in swap_duplicate().
>> 
>> Do you agree?
>
> Yes, I'm ok with that, adding in -ENOTDIR along with it.

Sure.  I will do this.

> The error handling in __swap_duplicate (before this series) still leaves
> something to be desired IMHO.  Why all the different returns when callers
> ignore them or only specifically check for -ENOMEM or -EEXIST?  Could maybe
> stand a cleanup, but outside this series.

Yes.  Maybe.  I guess you will work on this?

Best Regards,
Huang, Ying


Re: Bad MAINTAINERS pattern in section 'STAGING - FLARION FT1000 DRIVERS'

2018-09-28 Thread Greg Kroah-Hartman
On Fri, Sep 28, 2018 at 03:04:23PM -0700, Joe Perches wrote:
> Please fix this defect appropriately.
> 
> linux-next MAINTAINERS section:
> 
>   13899   STAGING - FLARION FT1000 DRIVERS
>   13900   M:  Marek Belisko 
>   13901   S:  Odd Fixes
> -->   13902   F:  drivers/staging/ft1000/
> 
> Commit that introduced this:
> 
> commit a0138163cfbfdfbdc20e4477c77bd7046bd66bb4
>  Author: Joe Perches 
>  Date:   Tue Jul 5 15:21:34 2011 -0700
>  
>  MAINTAINERS: Add remaining staging entries
>  
>  Add the staging entries from various TODO files
>  to MAINTAINERS.  Add a few web links as well.
>  
>  Miscellaneous staging typo section header fix.
>  
>  Signed-off-by: Joe Perches 
>  Signed-off-by: Greg Kroah-Hartman 
>  
>   MAINTAINERS | 69 
> -
>   1 file changed, 68 insertions(+), 1 deletion(-)

So you are going to fix this, considering you created the problem?

This is an odd request to make of yourself in public, or was this a
script gone wrong?

confused,

greg k-h


Re: [PATCH v3 2/2] spi: Introduce new driver for Qualcomm QuadSPI controller

2018-09-28 Thread Stephen Boyd
Quoting Ryan Case (2018-09-28 11:19:51)
> On Wed, Sep 26, 2018 at 11:43 PM Stephen Boyd  wrote:
> > Quoting Ryan Case (2018-09-26 13:52:04)
> > > From: Girish Mahadevan 
> > > +#include 
> > > +
> > > +#define AHB_MIN_HZ 960UL
> >
> > Is this used?
> 
> Nope. Do you want all currently unused defines removed or specifically this
> one? I saw precedent in other drivers for defining registers/flags/values of
> supported but unused functionality so I left these (big endian, DDR, ...).

I guess it's fine but I don't know if it will ever be used so remove it?
I'd leave the others if they help someone know what register bits exist.
That's usually how I handle it.

> 
> 
> > > +   speed_hz = slv->max_speed_hz;
> > > +   if (xfer->speed_hz)
> > > +   speed_hz = xfer->speed_hz;
> > > +
> > > +   ret = clk_set_rate(ctrl->clks[QSPI_CLK_CORE].clk, speed_hz * 4);
> >
> > Why 4? Is that related to the number of wires?
> 
> In normal operation the core clock should be running at 4x the rate of the
> transfer clock regardless of number of wires used.

Ok. Maybe add a comment so we understand that.

> 
> > > +   put_unaligned(rd_fifo, word_buf++);
> > > +   }
> > > +   ctrl->xfer.rx_buf = word_buf;
> > > +   }
> > > +
> > > +   if (bytes_to_read) {
> > > +   byte_buf = ctrl->xfer.rx_buf;
> >
> > Does this need to move forward by words_to_read bytes so that the left
> > over bytes are tacked onto the end? Or this should be an else if
> > statement?
> 
> When the words block completes it updates the rx_buf location so it is already
> at the correct offset for bytes.
> 

Ok I see. Subtle!



Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev

2018-09-28 Thread Dmitry Osipenko
On 9/29/18 3:27 AM, Tony Lindgren wrote:
> * Dmitry Osipenko  [180928 23:55]:
>> On 9/29/18 2:17 AM, Dmitry Osipenko wrote:
>>> On 9/29/18 1:41 AM, Tony Lindgren wrote:
 I'm still getting these errors after init:
>>>
>>> Thank you very much again, seems I got what's wrong with your case. The 
>>> ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on probe 
>>> and that value is getting updated only after the first voltage change, 
>>> hence _regulator_get_voltage() returns -22.
> 
> OK that's starting to make some sense now thanks.
> 
>>> Please try this patch:
>>
>> I've revised the patch and here is the current final version.
> 
> Hey cool this one works now :) I suggest you rework the whole series
> with these fixes. I recall the series had a problem with git bisect
> too between the patches. It will make life easier for other people
> who may need to git bisect these patches.

Awesome! There are few other things in this patchset that also need fixing. 
I've asked Maciej if he's going to continue working on the patches, waiting for 
the answer. I can pick up the patches and try to finish the work if necessary.


Hello

2018-09-28 Thread Margaret Kwan Wing Han
I have a legal business proposal worth $30.5M for you if interested reply 
me for more details. 

Regards, 
Ms Margaret Kwan Wing Han




Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev

2018-09-28 Thread Tony Lindgren
* Dmitry Osipenko  [180928 23:55]:
> On 9/29/18 2:17 AM, Dmitry Osipenko wrote:
> > On 9/29/18 1:41 AM, Tony Lindgren wrote:
> >> I'm still getting these errors after init:
> > 
> > Thank you very much again, seems I got what's wrong with your case. The 
> > ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on probe 
> > and that value is getting updated only after the first voltage change, 
> > hence _regulator_get_voltage() returns -22.

OK that's starting to make some sense now thanks.

> > Please try this patch:
> 
> I've revised the patch and here is the current final version.

Hey cool this one works now :) I suggest you rework the whole series
with these fixes. I recall the series had a problem with git bisect
too between the patches. It will make life easier for other people
who may need to git bisect these patches.

Thanks,

Tony


Re: [PATCH v7 1/6] seccomp: add a return code to trap to userspace

2018-09-28 Thread Aleksa Sarai
On 2018-09-27, Tycho Andersen  wrote:
> This patch introduces a means for syscalls matched in seccomp to notify
> some other task that a particular filter has been triggered.
> 
> The motivation for this is primarily for use with containers. For example,
> if a container does an init_module(), we obviously don't want to load this
> untrusted code, which may be compiled for the wrong version of the kernel
> anyway. Instead, we could parse the module image, figure out which module
> the container is trying to load and load it on the host.
> 
> As another example, containers cannot mknod(), since this checks
> capable(CAP_SYS_ADMIN). However, harmless devices like /dev/null or
> /dev/zero should be ok for containers to mknod, but we'd like to avoid hard
> coding some whitelist in the kernel. Another example is mount(), which has
> many security restrictions for good reason, but configuration or runtime
> knowledge could potentially be used to relax these restrictions.

Minor thing, but this is no longer _entirely_ true (now it checks
ns_capable(sb->s_user_ns)). I think the kernel module auto-loading is a
much more interesting example, but since this is just a commit message
feel free to ignore my pedantry. :P

> Signed-off-by: Tycho Andersen 
> CC: Kees Cook 
> CC: Andy Lutomirski 
> CC: Oleg Nesterov 
> CC: Eric W. Biederman 
> CC: "Serge E. Hallyn" 
> CC: Christian Brauner 
> CC: Tyler Hicks 
> CC: Akihiro Suda 

Would you mind adding me to the Cc: list for the next round of patches?
It's looking pretty neat!

Thanks!

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature


Response to SFConservancy's updated GPL guide.

2018-09-28 Thread vwdfrwd

The software freedom conservancy has tendered its response:
http://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/
http://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4


""
"The GPLv2 have several provisions that, when taken together, can be 
construed as an irrevocable license from each contributor. "

""

It cites:


  " That license granted to downstream is irrevocable, again 
provided that the downstream user complies with the license terms: 
"[P]arties who have received copies, or rights, from you under this 
License will not have their licenses terminated so long as such parties 
remain in full compliance" (GPLv2§4). "


However this is disingenuous

The full text of section 4 is as follows:

""
  4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License.  Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.
""



The "You" in section 4 is speaking of the licensee regarding 
sub-licensees, it is not speaking to the licensor/copyright-holder.


IE: if the licensee loses his license, through operation of the 
automatic-revocation provisions, the sub-licensees do not also lose 
their licenses.


IE: The language is disclaiming a chain topography for license 
distribution, and instead substituting a hub-and-spoke topography (all 
licenses originating from the copyright holder, not the 
previous-in-line)


GPLv3 added a no-rescission clause for a reason: the reason being to 
attempt to create an estoppel defense for the licensees against the 
licensor. You will notice that Eben Moglen never speaks on these issues. 
(He preumably is aware of the weaknesses vis a vis the US copyright 
regime.)


Section 6 further clarifies the hub-and-spoke model:
""
   6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.
""

The memorandum posted then goes on to a discussion of estoppel, 
detrimental reliance, etc; noting that users may have relied on the 
software and their licenses may be estopped from being revoked from said 
users since doing so might cause them unanticipated loss. This is 
speaking of already published, existent, versions of the program used by 
end users.


The memorandum seems to ignore what happens to "upstream" once said 
project  receives a revocation notice. Thought it may be possible that 
users of a published piece of software may have defenses to license 
revocation, the same is not true regarding the rescinded property 
vis-a-vis future prospective versions of the software nor of future 
prospective licensees of said software.


That is: once the grant to use the code in question is rescinded, future 
versions of the software may not use that code. Current users of the 
software may be-able to raise an estoppel / detrimental reliance defense 
regarding the current published software, however the programmers 
working on the next version of said software cannot continue to use the 
property in future versions of the software (such would be a copyright 
violation once the gratuitous license is rescinded by the grantor).


Additionally, prospective-licensees, once the grant was rescinded and 
such was published, would have no same-such estoppel defense (not being 
user-licensees at the time of revocation).


(Ignoring this eventuality in the published memorandum, is, of-course, 
by design.)
(Now, to note: the free-software movement is focused on the freedom of 
the user, not the progenitors of the software, so one could certainly 
say that ignoring some developer-focused analysis is consistent with 
their prerogative...)


Re: [RFC 2/3] RISC-V:Support per-hart timebase-frequency

2018-09-28 Thread Palmer Dabbelt

On Mon, 17 Sep 2018 07:23:08 PDT (-0700), Christoph Hellwig wrote:

On Fri, Sep 14, 2018 at 02:54:55PM -0700, Atish Patra wrote:

Follow the updated DT specs and read the timebase-frequency
from the boot cpu. Keep the old DT reading as well for backward
compatibility. This patch is rework of old patch from Palmer.

Signed-off-by: Atish Patra 


This setup looks a bit odd because it keeps blindly overwriting
riscv_timebase for every cpu found.  Shouldn't we at least check that
they all match for now as the rest of the port assumes that?


I agree.  There should be at least a warning if they don't match, but ideally 
we'd just support per-CPU timebases.  We have those systems already, they just 
don't boot Linux (at least, not yet :)).


Re: [RESEND PATCH] Revert "pwm: Set class for exported channels in sysfs"

2018-09-28 Thread Gottfried Haider
Hello Thierry & Fabrice,

>> Still, it is possible to send uevent (KOBJ_CHANGE) on pwmchipN device,
>> to notify of a change, e.g. pwmX channel being exported/unexported.

I tested this patch, and I am happy to report that it works with the
udev rule that Raspbian (Raspberry Pi's Debian derivative) has in
place:

SUBSYSTEM=="pwm*", PROGRAM="/bin/sh -c '\
chown -R root:gpio /sys/class/pwm && chmod -R 770 /sys/class/pwm;\
chown -R root:gpio
/sys/devices/platform/soc/*.pwm/pwm/pwmchip* && chmod -R 770
/sys/devices/platform/soc/*.pwm/pwm/pwmchip*\
'"


So while I can't comment on the uevent semantics, it would solve what
the original patch attempted to enable (non-root use of pwm).

Tested-by: Gottfried Haider 

Best,
Gottfried


Re: [PATCH v3 2/2] spi: Introduce new driver for Qualcomm QuadSPI controller

2018-09-28 Thread Doug Anderson
Hi,

On Fri, Sep 28, 2018 at 11:20 AM Ryan Case  wrote:
> > > +   master->max_speed_hz = 3;
> > > +   master->num_chipselect = QSPI_NUM_CS;
> > > +   master->bus_num = pdev->id;
> >
> > Can this come from DT aliases? I've never thought about qspi and
> > "regular" spi being in the same spi bus numbering system, but I suppose
> > that will happen now and we need to make sure that qspi numbers start
> > after the regular ones?
>
> I'm not sure. Can look into it.

In a previous response for the other Qualcomm SPI driver Mark said to
set this to -1.  Specifically the code was checking the alias and Mark
said:

> Don't do this, just set bus_num to -1 and let the core assign an ID.

[1] https://lkml.kernel.org/r/20180503233849.gf13...@sirena.org.uk

-Doug


Re: [PATCH v5 4/9] PCI: mediatek: Convert to use pci_host_probe()

2018-09-28 Thread Honghui Zhang
On Fri, 2018-09-28 at 23:41 +0800, Ryder Lee wrote:
> On Fri, 2018-09-28 at 18:04 +0800, honghui.zh...@mediatek.com wrote:
> > From: Honghui Zhang 
> > 
> > Part of mtk_pcie_register_host is an open-coded version of
> > pci_host_probe(). So instead of duplicating this code, use
> > pci_host_probe() directly and remove mtk_pcie_register_host.
> > 
> > Signed-off-by: Honghui Zhang 
> > ---
> >  drivers/pci/controller/pcie-mediatek.c | 37 
> > --
> >  1 file changed, 8 insertions(+), 29 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-mediatek.c 
> > b/drivers/pci/controller/pcie-mediatek.c
> > index e2c4127..cbf4543 100644
> > --- a/drivers/pci/controller/pcie-mediatek.c
> > +++ b/drivers/pci/controller/pcie-mediatek.c
> > @@ -1125,34 +1125,6 @@ static int mtk_pcie_request_resources(struct 
> > mtk_pcie *pcie)
> > return 0;
> >  }
> >  
> > -static int mtk_pcie_register_host(struct pci_host_bridge *host)
> > -{
> > -   struct mtk_pcie *pcie = pci_host_bridge_priv(host);
> > -   struct pci_bus *child;
> > -   int err;
> 
> To make the patch simple, could we keep these host->*. and return
> pci_host_probe() directly?

Well, I guess it's not necessary to keep the mtk_pcie_register_host just
wrap pci_host_probe(). Put those host->* directly in probe function is
no harm, it will reduce one function call and related parameter passing.

I may update this patch to keep the mtk_pcie_register_host if you insist
though I prefer the current way.

Thanks.
> 
> > -   host->busnr = pcie->busn.start;
> > -   host->dev.parent = pcie->dev;
> > -   host->ops = pcie->soc->ops;
> > -   host->map_irq = of_irq_parse_and_map_pci;
> > -   host->swizzle_irq = pci_common_swizzle;
> > -   host->sysdata = pcie;
> > -
> > -   err = pci_scan_root_bus_bridge(host);
> > -   if (err < 0)
> > -   return err;
> > -
> > -   pci_bus_size_bridges(host->bus);
> > -   pci_bus_assign_resources(host->bus);
> > -
> > -   list_for_each_entry(child, &host->bus->children, node)
> > -   pcie_bus_configure_settings(child);
> > -
> > -   pci_bus_add_devices(host->bus);
> > -
> > -   return 0;
> > -}
> > -
> >  static int mtk_pcie_probe(struct platform_device *pdev)
> >  {
> > struct device *dev = &pdev->dev;
> > @@ -1179,7 +1151,14 @@ static int mtk_pcie_probe(struct platform_device 
> > *pdev)
> > if (err)
> > goto put_resources;
> >  
> > -   err = mtk_pcie_register_host(host);
> > +   host->busnr = pcie->busn.start;
> > +   host->dev.parent = pcie->dev;
> > +   host->ops = pcie->soc->ops;
> > +   host->map_irq = of_irq_parse_and_map_pci;
> > +   host->swizzle_irq = pci_common_swizzle;
> > +   host->sysdata = pcie;
> > +
> > +   err = pci_host_probe(host);
> > if (err)
> > goto put_resources;
> >  
> 
> 




Re: [PATCH v5 00/12] SMP cleanup and new features

2018-09-28 Thread Palmer Dabbelt

On Thu, 13 Sep 2018 11:36:53 PDT (-0700), atish.pa...@wdc.com wrote:

This patch series has updated the assorted cleanup series by palmer.
The original cleanup patch series can be found here.
http://lists.infradead.org/pipermail/linux-riscv/2018-August/001232.html

It also implemented decoupling linux logical CPU ids from hart id.
Some of the work has been inspired from ARM64.
Tested on QEMU & HighFive Unleashed board with/without SMP enabled.

Both the patch series have been combined to avoid conflicts as a lot
of common code is changed in both the series. I have mostly addressed
review comments and fixed checkpatch errors from palmer's series.

v1->v2:

1. Dropped cpu_ops patch.
2. Moved back IRQ cause definitions to irq.h
3. Keep boot CPU hart id and assign zero as the CPU id for boot CPU.
4. Renamed CPU id and hart id correctly.

v2-v3:

1. Added cleanup patches from palmer.
2. Moved the hotplug related functions to it's own file.
3. Updated stub functions as per coding guidelines.
4. Renamed __cpu_logical_map to a more coherent name.

v3-v4:

1. Addressed minor typos in commit text and code.
2. Included Anup's do_IRQ patch.
3. Dropped CPU hotplug patch. As there are some concerns
   about approach, I will submit it separately.

v4->v5:

1. Minor typo fixes in commit text.

Anup Patel (1):
  RISC-V: No need to pass scause as arg to do_IRQ()

Atish Patra (4):
  RISC-V: Disable preemption before enabling interrupts
  RISC-V: Use WRITE_ONCE instead of direct access
  RISC-V: Add logical CPU indexing for RISC-V
  RISC-V: Use Linux logical CPU number instead of hartid

Palmer Dabbelt (7):
  RISC-V: Don't set cacheinfo.{physical_line_partition,attributes}
  RISC-V: Filter ISA and MMU values in cpuinfo
  RISC-V: Comment on the TLB flush in smp_callin()
  RISC-V: Provide a cleaner raw_smp_processor_id()
  RISC-V: Rename riscv_of_processor_hart to riscv_of_processor_hartid
  RISC-V: Rename im_okay_therefore_i_am to found_boot_cpu
  RISC-V: Use mmgrab()

 arch/riscv/include/asm/processor.h |  2 +-
 arch/riscv/include/asm/smp.h   | 38 -
 arch/riscv/include/asm/tlbflush.h  | 16 ++--
 arch/riscv/kernel/cacheinfo.c  |  7 
 arch/riscv/kernel/cpu.c| 83 --
 arch/riscv/kernel/entry.S  |  1 -
 arch/riscv/kernel/head.S   |  4 +-
 arch/riscv/kernel/irq.c|  4 +-
 arch/riscv/kernel/setup.c  | 10 +
 arch/riscv/kernel/smp.c| 43 +++-
 arch/riscv/kernel/smpboot.c| 46 ++---
 drivers/clocksource/riscv_timer.c  | 12 --
 drivers/irqchip/irq-sifive-plic.c  | 10 +++--
 13 files changed, 207 insertions(+), 69 deletions(-)


I didn't look closely because I assume your cleanups are better than mine, and 
than you at least gave this a boot test to ensure I didn't do anything too 
stupid :)


I'm preparing our first meaningful for-next now, I'll drop this one in.

Thanks for taking this over!


Re: [PATCH] MAINTAINERS: Drop dt-bindings/genpd/k2g.h

2018-09-28 Thread Santosh Shilimkar

Hi Anrd, Olof,

On 9/28/2018 3:46 PM, Nishanth Menon wrote:

Drop include/dt-bindings/genpd/k2g.h which disappeared from kernel tree
some time back, however MAINTAINERS file was missed to be updated.

Fixes: d16645054d2f ("dt-bindings: Drop k2g genpd device ID macros")
Cc: Rob Herring 
Cc: Dave Gerlach 
Cc: Santosh Shilimkar 
Cc: Tero Kristo 
Reported-by: Joe Perches 
Signed-off-by: Nishanth Menon 
---

A big oops.. Sorry about that. will do better next time. I tried to relook and
I think we have'nt missed any other files.

Based off next-20180928 tag.

Santosh, any chance you could pick this up -> Thread:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1776470.html


Could you please apply this to arm-soc tree if its not too
late ?


Acked-by: Santosh Shilimkar 


Re: [PATCH] Input: Support for Xbox1 PDP Camo series gamepad

2018-09-28 Thread Dmitry Torokhov
On Tue, Aug 28, 2018 at 12:48:11AM -0500, Ramses Ramírez wrote:
> The "Xbox One PDP Wired Controller - Camo series" has a different
> product-id than the regular PDP controller and the PDP stealth series,
> but it uses the same initialization sequence. This patch adds the
> product-id of the camo series to the structures that handle the other
> PDP Xbox One controllers.
> 
> Signed-off-by: Ramses Ramírez 

Applied, thank you.

> ---
>  drivers/input/joystick/xpad.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index cd620e009bad..d4b9db487b16 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -231,6 +231,7 @@ static const struct xpad_device {
>   { 0x0e6f, 0x0246, "Rock Candy Gamepad for Xbox One 2015", 0, 
> XTYPE_XBOXONE },
>   { 0x0e6f, 0x02ab, "PDP Controller for Xbox One", 0, XTYPE_XBOXONE },
>   { 0x0e6f, 0x02a4, "PDP Wired Controller for Xbox One - Stealth Series", 
> 0, XTYPE_XBOXONE },
> + { 0x0e6f, 0x02a6, "PDP Wired Controller for Xbox One - Camo Series", 0, 
> XTYPE_XBOXONE },
>   { 0x0e6f, 0x0301, "Logic3 Controller", 0, XTYPE_XBOX360 },
>   { 0x0e6f, 0x0346, "Rock Candy Gamepad for Xbox One 2016", 0, 
> XTYPE_XBOXONE },
>   { 0x0e6f, 0x0401, "Logic3 Controller", 0, XTYPE_XBOX360 },
> @@ -530,6 +531,8 @@ static const struct xboxone_init_packet 
> xboxone_init_packets[] = {
>   XBOXONE_INIT_PKT(0x0e6f, 0x02ab, xboxone_pdp_init2),
>   XBOXONE_INIT_PKT(0x0e6f, 0x02a4, xboxone_pdp_init1),
>   XBOXONE_INIT_PKT(0x0e6f, 0x02a4, xboxone_pdp_init2),
> + XBOXONE_INIT_PKT(0x0e6f, 0x02a6, xboxone_pdp_init1),
> + XBOXONE_INIT_PKT(0x0e6f, 0x02a6, xboxone_pdp_init2),
>   XBOXONE_INIT_PKT(0x24c6, 0x541a, xboxone_rumblebegin_init),
>   XBOXONE_INIT_PKT(0x24c6, 0x542a, xboxone_rumblebegin_init),
>   XBOXONE_INIT_PKT(0x24c6, 0x543a, xboxone_rumblebegin_init),
> -- 
> 2.17.1
> 

-- 
Dmitry


Re: [PATCH] mm: Fix int overflow in callers of do_shrink_slab()

2018-09-28 Thread Kirill Tkhai
On 29.09.2018 00:15, Andrew Morton wrote:
> On Fri, 28 Sep 2018 14:28:32 +0300 Kirill Tkhai  wrote:
> 
>> do_shrink_slab() returns unsigned long value, and
>> the placing into int variable cuts high bytes off.
>> Then we compare ret and 0xfffe (since SHRINK_EMPTY
>> is converted to ret type).
>>
>> Thus, big number of objects returned by do_shrink_slab()
>> may be interpreted as SHRINK_EMPTY, if low bytes of
>> their value are equal to 0xfffe. Fix that
>> by declaration ret as unsigned long in these functions.
> 
> Sigh.  How many times has this happened.
> 
>> Reported-by: Cyrill Gorcunov 
> 
> What did he report?  Was it code inspection?  Did the kernel explode? 
> etcetera.  I'm thinking that the fix should be backported but to
> determine that, we need to understand the end-user runtime effects, as
> always.  Please.

Yeah, it was just code inspection. It's need to be a really unlucky person
to meet this in real life -- the probability is very small.

The runtime effect would be the following. Such the unlucky person would
have a single shrinker, which is never called for a single memory cgroup,
despite there are objects charged.

Thanks,
Kirill


Re: [PATCH] input: sun4i-lradc: Convert to using %pOFn instead of device_node.name

2018-09-28 Thread Dmitry Torokhov
On Mon, Aug 27, 2018 at 08:52:24PM -0500, Rob Herring wrote:
> In preparation to remove the node name pointer from struct device_node,
> convert printf users to use the %pOFn format specifier.
> 
> Cc: Hans de Goede 
> Cc: Dmitry Torokhov 
> Cc: Maxime Ripard 
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Rob Herring 

Applied, thank you.

> ---
>  drivers/input/keyboard/sun4i-lradc-keys.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c 
> b/drivers/input/keyboard/sun4i-lradc-keys.c
> index a37c172452e6..57272df34cd5 100644
> --- a/drivers/input/keyboard/sun4i-lradc-keys.c
> +++ b/drivers/input/keyboard/sun4i-lradc-keys.c
> @@ -185,19 +185,19 @@ static int sun4i_lradc_load_dt_keymap(struct device 
> *dev,
>  
>   error = of_property_read_u32(pp, "channel", &channel);
>   if (error || channel != 0) {
> - dev_err(dev, "%s: Inval channel prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval channel prop\n", pp);
>   return -EINVAL;
>   }
>  
>   error = of_property_read_u32(pp, "voltage", &map->voltage);
>   if (error) {
> - dev_err(dev, "%s: Inval voltage prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval voltage prop\n", pp);
>   return -EINVAL;
>   }
>  
>   error = of_property_read_u32(pp, "linux,code", &map->keycode);
>   if (error) {
> - dev_err(dev, "%s: Inval linux,code prop\n", pp->name);
> + dev_err(dev, "%pOFn: Inval linux,code prop\n", pp);
>   return -EINVAL;
>   }
>  
> -- 
> 2.17.1
> 

-- 
Dmitry


[git pull] Input updates for v4.19-rc5

2018-09-28 Thread Dmitry Torokhov
Hi Greg,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. Just a few driver fixes.

Changelog:
-

Aaron Ma (1):
  Input: elantech - enable middle button of touchpad on ThinkPad P72

Andreas Schwab (1):
  Input: atakbd - fix Atari keymap

Anson Huang (1):
  Input: egalax_ts - add system wakeup support

Michael Schmitz (1):
  Input: atakbd - fix Atari CapsLock behaviour

Peter Hutterer (1):
  Input: uinput - allow for max == min during input_absinfo validation

Song Qiang (1):
  Input: gpio-keys - fix a documentation index issue

Diffstat:


 .../devicetree/bindings/input/gpio-keys.txt|  2 +-
 drivers/input/keyboard/atakbd.c| 74 --
 drivers/input/misc/uinput.c|  2 +-
 drivers/input/mouse/elantech.c |  2 +
 drivers/input/touchscreen/egalax_ts.c  |  6 ++
 5 files changed, 38 insertions(+), 48 deletions(-)

Thanks.


-- 
Dmitry


Re: [PATCH v2 0/5] Fix some bugs on RV32 build fail and issue

2018-09-28 Thread Palmer Dabbelt

On Wed, 26 Sep 2018 01:31:09 PDT (-0700), zong...@gmail.com wrote:

This patches contain the modificaion as follows:
1. Fix up the building fail on RV32.
2. Add umoddi3 and udivmoddi4 functions for RV32.
3. Fix ioremap problem on RV32.

Changes in v2:
 - Retain the copyright notices from libgcc in umoddi3.c and udivmoddi4.c.

Vincent Chen (1):
  RISC-V: Avoid corrupting the upper 32-bit of phys_addr_t in ioremap

Zong Li (4):
  RISC-V: Build tishift only on 64-bit
  RISC-V: Use swiotlb on RV64 only
  lib: Add umoddi3 and udivmoddi4 of GCC library routines
  RISC-V: Select GENERIC_LIB_UMODDI3 on RV32

 arch/riscv/Kconfig|   1 +
 arch/riscv/kernel/setup.c |   3 +
 arch/riscv/lib/Makefile   |   3 +-
 arch/riscv/mm/ioremap.c   |   2 +-
 lib/Kconfig   |   3 +
 lib/Makefile  |   1 +
 lib/udivmoddi4.c  | 309 ++
 lib/umoddi3.c |  34 +
 8 files changed, 354 insertions(+), 2 deletions(-)
 create mode 100644 lib/udivmoddi4.c
 create mode 100644 lib/umoddi3.c


I like what this does, but there's a license issue here that Christoph pointed 
out.  It'd be great to have RV32I systems booting 4.19, do you think there's a 
chance you can sort this out next week so we can get it into the last RC?  That 
would help with the rv32i glibc process, as we'll actually be able to boot an 
upstream kernel.


It looks like the functions we have an issue with come from libgcc2.c, which 
doesn't change very much.  As far as I can tell we might be able to get away 
with these functions from 4.2.1, which was licensed under the GPLv2.  Here's 
the relevant functions on GCC's github mirror


   https://github.com/gcc-mirror/gcc/blob/gcc-4_2_1-release/gcc/libgcc2.c#L559
   https://github.com/gcc-mirror/gcc/blob/gcc-4_2_1-release/gcc/libgcc2.c#L844

These look very similar to what you send out.  As far as I can tell, if you 
base your code on the GPLv2 version then this should be fine to include.


Thanks!


Re: [PATCH v6 2/2] iio: proximity: vl53l0x: add interrupt support

2018-09-28 Thread Rob Herring
On Fri, Sep 28, 2018 at 4:36 AM Song Qiang  wrote:
>
> On Wed, Sep 26, 2018 at 05:46:18PM -0500, Rob Herring wrote:
> > On Sat, Sep 22, 2018 at 04:05:23PM +0100, Jonathan Cameron wrote:
> > > On Tue, 18 Sep 2018 16:24:22 +0800
> > > Song Qiang  wrote:
> > >
> > > > The first version of this driver issues a measuring request and polling
> > > > for a status register in the device for measuring completes.
> > > > vl53l0x support configuring GPIO1 on it to generate interrupt to
> > > > indicate that new measurement is ready. This patch adds support for
> > > > using this mechanisim to reduce cpu cost.
> > > >
> > > > Signed-off-by: Song Qiang 
> > > Hi Song.
> > >
> > > Looks correct in principal but a few things to tidy up before
> > > this is ready to apply.
> > >
> > > Also we have an unrelated change in here to check the devices ID.
> > > That should be in it's own patch.
> > >
> > > Thanks,
> > >
> > > Jonathan
> > > > ---
> > > >  .../bindings/iio/proximity/vl53l0x.txt|  14 +-
> >
> > This should have been split with the complete binding in one patch
> > rather than piecemeal driver feature by feature.
> >
>
> Hi Rob,
>
> A few days ago when I was submitting this driver, I didn't do it very
> well, the function of this driver is limited. I added interrupt support
> the next day after you acked my first patch. I thought it's not polite
> to add something after someone acked that patch, so I send the interrupt
> support as a second patch. The first patch is merged to togreg now, but
> this doesn't. I don't know when can I add new functions to the code that
> just merged to togreg branch, could you offer some suggestions?

You just needed to state why you didn't add a ack. But really, just
don't send things except as RFC until they are "done".

What to do next depends on Jonathan and whether he wants a follow-up
patch or he will drop the first one.

> > > >  drivers/iio/proximity/vl53l0x-i2c.c   | 135 +++---
> > > >  2 files changed, 129 insertions(+), 20 deletions(-)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt 
> > > > b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> > > > index ab9a9539fec4..40290f8dd70f 100644
> > > > --- a/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> > > > +++ b/Documentation/devicetree/bindings/iio/proximity/vl53l0x.txt
> > > > @@ -4,9 +4,21 @@ Required properties:
> > > >   - compatible: must be "st,vl53l0x-i2c"
> >
> > Is there more than one interface on this device, such as SPI? If not,
> > then '-i2c' should be dropped.
> >
>
> Yes, there is a CCI(Camera Control Interface) for communication.

Isn't CCI just a subset of I2C? I should clarify my question is
whether there's more than 1 mutually exclusive control interface (as
many devices have control and data interfaces) where you could have 2
different drivers. A common example are devices with I2C and SPI
interfaces.

Rob


Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev

2018-09-28 Thread Dmitry Osipenko
On 9/29/18 2:17 AM, Dmitry Osipenko wrote:
> On 9/29/18 1:41 AM, Tony Lindgren wrote:
>> * Dmitry Osipenko  [180928 22:31]:
>>> On 9/28/18 11:22 PM, Tony Lindgren wrote:
 * Dmitry Osipenko  [180928 20:13]:
> Tony, could you please give a try to the patch below?
>
> Do the following:
>
> 1) git cherry-pick 696861761a58d8c93605b5663824929fb6540f16
> 2) git cherry-pick 456e7cdf3b1a14e2606b8b687385ab2e3f23a49a
> 3) Apply this patch:

 Seems to be getting closer, system boots up and starts
 init, but then I start getting tons of this on beagle-x15:
>>>
>>> Tony, could you please try this one? Fixed couple more bugs, should be good 
>>> now.
>>
>> I'm still getting these errors after init:
> 
> Thank you very much again, seems I got what's wrong with your case. The 
> ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on probe 
> and that value is getting updated only after the first voltage change, hence 
> _regulator_get_voltage() returns -22.
> 
> Please try this patch:

I've revised the patch and here is the current final version.


>From 0332e230568d5bba470f917f0b36dd9ef9e6e511 Mon Sep 17 00:00:00 2001
From: Dmitry Osipenko 
Date: Fri, 28 Sep 2018 21:49:20 +0300
Subject: [PATCH] Fixup regulator_balance_voltage() v4

---
 drivers/regulator/core.c | 58 +++-
 1 file changed, 34 insertions(+), 24 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 282511508698..17dce370f236 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3099,10 +3099,6 @@ static int regulator_set_voltage_unlocked(struct 
regulator *regulator,
voltage->min_uV = min_uV;
voltage->max_uV = max_uV;
 
-   ret = regulator_check_consumers(rdev, &min_uV, &max_uV, state);
-   if (ret < 0)
-   goto out2;
-
/* for not coupled regulators this will just set the voltage */
ret = regulator_balance_voltage(rdev, state);
if (ret < 0)
@@ -3187,7 +3183,9 @@ static int regulator_set_voltage_rdev(struct 
regulator_dev *rdev, int min_uV,
return ret;
 }
 
-static int regulator_get_optimal_voltage(struct regulator_dev *rdev)
+static int regulator_get_optimal_voltage(struct regulator_dev *rdev,
+int *min_uV, int *max_uV,
+suspend_state_t state)
 {
struct coupling_desc *c_desc = &rdev->coupling_desc;
struct regulator_dev **c_rdevs = c_desc->coupled_rdevs;
@@ -3202,7 +3200,8 @@ static int regulator_get_optimal_voltage(struct 
regulator_dev *rdev)
desired_max_uV = rdev->constraints->max_uV;
ret = regulator_check_consumers(rdev,
&desired_min_uV,
-   &desired_max_uV, PM_SUSPEND_ON);
+   &desired_max_uV,
+   state);
if (ret < 0)
goto out;
 
@@ -3210,8 +3209,10 @@ static int regulator_get_optimal_voltage(struct 
regulator_dev *rdev)
 * If there are no coupled regulators, simply set the voltage demanded
 * by consumers.
 */
-   if (n_coupled == 1) {
-   ret = desired_min_uV;
+   if (n_coupled == 1 || state != PM_SUSPEND_ON) {
+   *min_uV = desired_min_uV;
+   *max_uV = desired_max_uV;
+   ret = 1;
goto out;
}
 
@@ -3285,8 +3286,10 @@ static int regulator_get_optimal_voltage(struct 
regulator_dev *rdev)
ret = -EINVAL;
goto out;
}
-   ret = possible_uV;
+   ret = (possible_uV == desired_min_uV);
 
+   *min_uV = possible_uV;
+   *max_uV = desired_max_uV;
 out:
return ret;
 }
@@ -3298,7 +3301,8 @@ static int regulator_balance_voltage(struct regulator_dev 
*rdev,
struct regulator_dev *best_rdev;
struct coupling_desc *c_desc = &rdev->coupling_desc;
int n_coupled;
-   int i, best_delta, best_uV, ret = 1;
+   int i, best_delta, best_min_uV, best_max_uV, ret = 1;
+   bool last = false;
 
c_rdevs = c_desc->coupled_rdevs;
n_coupled = c_desc->n_coupled;
@@ -3314,9 +3318,10 @@ static int regulator_balance_voltage(struct 
regulator_dev *rdev,
 * Find the best possible voltage change on each loop. Leave the loop
 * if there isn't any possible change.
 */
-   while (1) {
+   while (!last) {
best_delta = 0;
-   best_uV = 0;
+   best_min_uV = 0;
+   best_max_uV = 0;
best_rdev = NULL;
 
/*
@@ -3330,24 +3335,29 @@ static int regulator_balance_voltage(struct 
regulator_dev *rdev,
 * max_spread constraint in order to balance
 * the coupled voltages.
 */
-   int optimal_uV, current_u

Re: [PATCH v7] regulator: fixed: Convert to use GPIO descriptor only

2018-09-28 Thread John Stultz
On Thu, Sep 6, 2018 at 6:01 AM Linus Walleij  wrote:
>
> As we augmented the regulator core to accept a GPIO descriptor instead
> of a GPIO number, we can augment the fixed GPIO regulator to look up
> and pass that descriptor directly from device tree or board GPIO
> descriptor look up tables.
>
> Some boards just auto-enumerate their fixed regulator platform devices
> and I have assumed they get names like "fixed-regulator.0" but it's
> pretty hard to guess this. I need some testing from board maintainers to
> be sure. Other boards are straight forward, using just plain
> "fixed-regulator" (ID -1) or "fixed-regulator.1" hammering down the
> device ID.

Hey Linus,
  Anders recently noted a regression in -next when running HiKey,
where USB fails to function.  I took a look and could reproduce this
as well, and after some unsuccessful muddling about in the usb
changes, I bisected it down to your commit here (specifically
efdfeb079cc3 in -next).

I'm not sure exactly why this would cause trouble, but I suspect it
has something to do w/ the cable-detect OTG to host-hub switch on the
HiKey.

Anyway, I just wanted to raise this with you so it can get sorted out
before that patch hits mainline.

thanks
-john


Re: [PATCH RT 2/2] watchdog, rt: prevent deferral of watchdogd wakeup

2018-09-28 Thread kbuild test robot
Hi Julia,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc5 next-20180928]
[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/Julia-Cartwright/kthread-convert-worker-lock-to-raw-spinlock/20180929-052522
config: i386-randconfig-s0-201838 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers//watchdog/watchdog_dev.c: In function 'watchdog_cdev_register':
>> drivers//watchdog/watchdog_dev.c:948:49: error: 'HRTIMER_MODE_REL_HARD' 
>> undeclared (first use in this function)
 hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
^
   drivers//watchdog/watchdog_dev.c:948:49: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/HRTIMER_MODE_REL_HARD +948 drivers//watchdog/watchdog_dev.c

   919  
   920  /*
   921   *  watchdog_cdev_register: register watchdog character device
   922   *  @wdd: watchdog device
   923   *  @devno: character device number
   924   *
   925   *  Register a watchdog character device including handling the 
legacy
   926   *  /dev/watchdog node. /dev/watchdog is actually a miscdevice and
   927   *  thus we set it up like that.
   928   */
   929  
   930  static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t 
devno)
   931  {
   932  struct watchdog_core_data *wd_data;
   933  int err;
   934  
   935  wd_data = kzalloc(sizeof(struct watchdog_core_data), 
GFP_KERNEL);
   936  if (!wd_data)
   937  return -ENOMEM;
   938  kref_init(&wd_data->kref);
   939  mutex_init(&wd_data->lock);
   940  
   941  wd_data->wdd = wdd;
   942  wdd->wd_data = wd_data;
   943  
   944  if (IS_ERR_OR_NULL(watchdog_kworker))
   945  return -ENODEV;
   946  
   947  kthread_init_work(&wd_data->work, watchdog_ping_work);
 > 948  hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, 
 > HRTIMER_MODE_REL_HARD);
   949  wd_data->timer.function = watchdog_timer_expired;
   950  
   951  if (wdd->id == 0) {
   952  old_wd_data = wd_data;
   953  watchdog_miscdev.parent = wdd->parent;
   954  err = misc_register(&watchdog_miscdev);
   955  if (err != 0) {
   956  pr_err("%s: cannot register miscdev on minor=%d 
(err=%d).\n",
   957  wdd->info->identity, WATCHDOG_MINOR, 
err);
   958  if (err == -EBUSY)
   959  pr_err("%s: a legacy watchdog module is 
probably present.\n",
   960  wdd->info->identity);
   961  old_wd_data = NULL;
   962  kfree(wd_data);
   963  return err;
   964  }
   965  }
   966  
   967  /* Fill in the data structures */
   968  cdev_init(&wd_data->cdev, &watchdog_fops);
   969  wd_data->cdev.owner = wdd->ops->owner;
   970  
   971  /* Add the device */
   972  err = cdev_add(&wd_data->cdev, devno, 1);
   973  if (err) {
   974  pr_err("watchdog%d unable to add device %d:%d\n",
   975  wdd->id,  MAJOR(watchdog_devt), wdd->id);
   976  if (wdd->id == 0) {
   977  misc_deregister(&watchdog_miscdev);
   978  old_wd_data = NULL;
   979  kref_put(&wd_data->kref, 
watchdog_core_data_release);
   980  }
   981  return err;
   982  }
   983  
   984  /* Record time of most recent heartbeat as 'just before now'. */
   985  wd_data->last_hw_keepalive = ktime_sub(ktime_get(), 1);
   986  
   987  /*
   988   * If the watchdog is running, prevent its driver from being 
unloaded,
   989   * and schedule an immediate ping.
   990   */
   991  if (watchdog_hw_running(wdd)) {
   992  __module_get(wdd->ops->owner);
   993  kref_get(&wd_data->kref);
   994  if (handle_boot_enabled)
   995  hrtimer_start(&wd_data->timer, 0, 
HRTIMER_MODE_REL);
   996  else
   997  pr_in

Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev

2018-09-28 Thread Dmitry Osipenko
On 9/29/18 1:41 AM, Tony Lindgren wrote:
> * Dmitry Osipenko  [180928 22:31]:
>> On 9/28/18 11:22 PM, Tony Lindgren wrote:
>>> * Dmitry Osipenko  [180928 20:13]:
 Tony, could you please give a try to the patch below?

 Do the following:

 1) git cherry-pick 696861761a58d8c93605b5663824929fb6540f16
 2) git cherry-pick 456e7cdf3b1a14e2606b8b687385ab2e3f23a49a
 3) Apply this patch:
>>>
>>> Seems to be getting closer, system boots up and starts
>>> init, but then I start getting tons of this on beagle-x15:
>>
>> Tony, could you please try this one? Fixed couple more bugs, should be good 
>> now.
> 
> I'm still getting these errors after init:

Thank you very much again, seems I got what's wrong with your case. The 
ti-abb-regulator driver sets the "abb->current_info_idx = -EINVAL" on probe and 
that value is getting updated only after the first voltage change, hence 
_regulator_get_voltage() returns -22.

Please try this patch:


>From 2f10c29547778499f614b363a7756a40099bfa5a Mon Sep 17 00:00:00 2001
From: Dmitry Osipenko 
Date: Fri, 28 Sep 2018 21:49:20 +0300
Subject: [PATCH] Fixup regulator_balance_voltage() v3

---
 drivers/regulator/core.c | 91 
 1 file changed, 55 insertions(+), 36 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 282511508698..d0edb66b37a2 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -105,7 +105,7 @@ static int _notifier_call_chain(struct regulator_dev *rdev,
  unsigned long event, void *data);
 static int _regulator_do_set_voltage(struct regulator_dev *rdev,
 int min_uV, int max_uV);
-static int regulator_balance_voltage(struct regulator_dev *rdev,
+static int regulator_balance_voltage(struct regulator *regulator,
 suspend_state_t state);
 static int regulator_set_voltage_rdev(struct regulator_dev *rdev,
  int min_uV, int max_uV,
@@ -2330,7 +2330,7 @@ int regulator_enable(struct regulator *regulator)
ret = _regulator_enable(rdev);
/* balance only if there are regulators coupled */
if (rdev->coupling_desc.n_coupled > 1)
-   regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+   regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
 
if (ret != 0 && rdev->supply)
@@ -2440,7 +2440,7 @@ int regulator_disable(struct regulator *regulator)
regulator_lock_dependent(rdev);
ret = _regulator_disable(rdev);
if (rdev->coupling_desc.n_coupled > 1)
-   regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+   regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
 
if (ret == 0 && rdev->supply)
@@ -2494,7 +2494,7 @@ int regulator_force_disable(struct regulator *regulator)
regulator->uA_load = 0;
ret = _regulator_force_disable(regulator->rdev);
if (rdev->coupling_desc.n_coupled > 1)
-   regulator_balance_voltage(rdev, PM_SUSPEND_ON);
+   regulator_balance_voltage(regulator, PM_SUSPEND_ON);
regulator_unlock_dependent(rdev);
 
if (rdev->supply)
@@ -3099,12 +3099,8 @@ static int regulator_set_voltage_unlocked(struct 
regulator *regulator,
voltage->min_uV = min_uV;
voltage->max_uV = max_uV;
 
-   ret = regulator_check_consumers(rdev, &min_uV, &max_uV, state);
-   if (ret < 0)
-   goto out2;
-
/* for not coupled regulators this will just set the voltage */
-   ret = regulator_balance_voltage(rdev, state);
+   ret = regulator_balance_voltage(regulator, state);
if (ret < 0)
goto out2;
 
@@ -3187,7 +3183,10 @@ static int regulator_set_voltage_rdev(struct 
regulator_dev *rdev, int min_uV,
return ret;
 }
 
-static int regulator_get_optimal_voltage(struct regulator_dev *rdev)
+static int regulator_get_optimal_voltage(struct regulator *regulator,
+struct regulator_dev *rdev,
+int *min_uV, int *max_uV,
+suspend_state_t state)
 {
struct coupling_desc *c_desc = &rdev->coupling_desc;
struct regulator_dev **c_rdevs = c_desc->coupled_rdevs;
@@ -3198,20 +3197,29 @@ static int regulator_get_optimal_voltage(struct 
regulator_dev *rdev)
int i, ret;
 
/* If consumers don't provide any demands, set voltage to min_uV */
-   desired_min_uV = rdev->constraints->min_uV;
-   desired_max_uV = rdev->constraints->max_uV;
-   ret = regulator_check_consumers(rdev,
-   &desired_min_uV,
-   &desired_max_uV, PM_SUSPEND_ON);
-   if (ret < 0)
-   goto out;
+   if (regulator->rdev == rdev) {
+   

Re: Bad MAINTAINERS pattern in section 'ACPI'

2018-09-28 Thread Bjorn Helgaas
[+cc Tony, Borislav (ACPI APEI reviewers), linux-pci]

On Fri, Sep 28, 2018 at 02:50:53PM -0700, Joe Perches wrote:
> Please fix this defect appropriately.
> 
> linux-next MAINTAINERS section:
> 
>   308 ACPI
>   309 M:  "Rafael J. Wysocki" 
>   310 M:  Len Brown 
>   311 L:  linux-a...@vger.kernel.org
>   312 W:  https://01.org/linux-acpi
>   313 Q:  https://patchwork.kernel.org/project/linux-acpi/list/
>   314 T:  git 
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
>   315 B:  https://bugzilla.kernel.org
>   316 S:  Supported
>   317 F:  drivers/acpi/
>   318 F:  drivers/pnp/pnpacpi/
>   319 F:  include/linux/acpi.h
>   320 F:  include/linux/fwnode.h
>   321 F:  include/acpi/
>   322 F:  Documentation/acpi/
>   323 F:  Documentation/ABI/testing/sysfs-bus-acpi
>   324 F:  Documentation/ABI/testing/configfs-acpi
>   325 F:  drivers/pci/*acpi*
>   326 F:  drivers/pci/*/*acpi*
> -->   327 F:  drivers/pci/*/*/*acpi*
>   328 F:  tools/power/acpi/

My proposal to fix this:

commit a99051c0d3c59fd259fd76a8bbd9837b76b509d9
Author: Bjorn Helgaas 
Date:   Fri Sep 28 17:34:21 2018 -0500

MAINTAINERS: Remove obsolete drivers/pci pattern from ACPI section

Prior to 256a45937093 ("PCI/AER: Squash aerdrv_acpi.c into aerdrv.c"),
drivers/pci/pcie/aer/aerdrv_acpi.c contained code to parse the ACPI HEST
table.  That code now lives in drivers/pci/pcie/aer.c.

Remove the "F: drivers/pci/*/*/*acpi*" pattern because it matches nothing.

We could add a "F: drivers/pci/pcie/aer.c" pattern to the ACPI APEI
section, but that file sees a lot of changes, almost none of which are of
interest to the ACPI folks.

Signed-off-by: Bjorn Helgaas 

diff --git a/MAINTAINERS b/MAINTAINERS
index 700408b7bc53..9babd8a0406b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -324,7 +324,6 @@ F:  Documentation/ABI/testing/sysfs-bus-acpi
 F: Documentation/ABI/testing/configfs-acpi
 F: drivers/pci/*acpi*
 F: drivers/pci/*/*acpi*
-F: drivers/pci/*/*/*acpi*
 F: tools/power/acpi/
 
 ACPI APEI


Re: [PATCH v7 0/6] seccomp trap to userspace

2018-09-28 Thread Jann Horn
On Sat, Sep 29, 2018 at 12:47 AM Michael Kerrisk (man-pages)
 wrote:
> On Sat, 29 Sep 2018 at 00:35, Kees Cook  wrote:
> > On Fri, Sep 28, 2018 at 3:16 PM, Michael Kerrisk (man-pages)
> >  wrote:
> > > On Sat, 29 Sep 2018 at 00:04, Tycho Andersen  wrote:
> > >> On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) 
> > >> wrote:
> > >> > On 09/27/2018 05:11 PM, Tycho Andersen wrote:
> > >> > > Here's v7 of the seccomp trap to userspace set. There are various 
> > >> > > minor
> > >> > > changes and bug fixes, but two major changes:
> > >> > >
> > >> > > * We now pass fds to the tracee via an ioctl, and do it immediately 
> > >> > > when
> > >> > >the ioctl is called. For this we needed some help from the vfs, so
> > >> > >I've put the one patch in this series and cc'd fsdevel. This does 
> > >> > > have
> > >> > >the advantage that the feature is now totally decoupled from the 
> > >> > > rest
> > >> > >of the set, which is itself useful (thanks Andy!)
> > >> > >
> > >> > > * Instead of putting all of the notification related stuff into the
> > >> > >struct seccomp_filter, it now lives in its own struct 
> > >> > > notification,
> > >> > >which is pointed to by struct seccomp_filter. This will save a 
> > >> > > lot of
> > >> > >memory (thanks Tyler!)
> > >> >
> > >> > Is there a documentation (man page) patch for this API change?
> > >>
> > >> Not yet, but once we decide on a final API I'll prepare one.
> > >
> > > Honestly, the production of such documentation should be part of the
> > > evolution towards the final API...
> > >
> > > Documentation is not an afterthought. It's a tool for pushing you, the
> > > developer (and others, your reviewers) to more deeply consider your
> > > design.
> >
> > In Tycho's defense, he did write up documentation in Documentation/
> > for the feature, so it won't be an afterthought. :)
>
> So, I missed that... How do I find this Documentation/ ?

It's in patch 1:
https://lore.kernel.org/lkml/20180927151119.9989-2-ty...@tycho.ws/


Re: Bad MAINTAINERS pattern in section 'Texas Instruments' System Control Interface (TISCI) Protocol Driver'

2018-09-28 Thread Nishanth Menon
On 22:04-20180928, Joe Perches wrote:
> Please fix this defect appropriately.
> 
> linux-next MAINTAINERS section:
> 
>   14531   Texas Instruments' System Control Interface (TISCI) Protocol 
> Driver
>   14532   M:  Nishanth Menon 
>   14533   M:  Tero Kristo 
>   14534   M:  Santosh Shilimkar 
>   14535   L:  linux-arm-ker...@lists.infradead.org
>   14536   S:  Maintained
>   14537   F:  
> Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>   14538   F:  drivers/firmware/ti_sci*
>   14539   F:  include/linux/soc/ti/ti_sci_protocol.h
>   14540   F:  
> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> -->   14541   F:  include/dt-bindings/genpd/k2g.h
>   14542   F:  drivers/soc/ti/ti_sci_pm_domains.c
>   14543   F:  Documentation/devicetree/bindings/reset/ti,sci-reset.txt
>   14544   F:  Documentation/devicetree/bindings/clock/ti,sci-clk.txt
>   14545   F:  drivers/clk/keystone/sci-clk.c
>   14546   F:  drivers/reset/reset-ti-sci.c

Sorry about that Joe. Thanks for the headsup.

https://patchwork.kernel.org/patch/10620509/ posted.
-- 
Regards,
Nishanth Menon


Re: [PATCH v7 0/6] seccomp trap to userspace

2018-09-28 Thread Michael Kerrisk (man-pages)
Hi Kees,
On Sat, 29 Sep 2018 at 00:35, Kees Cook  wrote:
>
> On Fri, Sep 28, 2018 at 3:16 PM, Michael Kerrisk (man-pages)
>  wrote:
> > Hi Tycho,
> >
> > On Sat, 29 Sep 2018 at 00:04, Tycho Andersen  wrote:
> >>
> >> On Fri, Sep 28, 2018 at 11:57:40PM +0200, Michael Kerrisk (man-opages) 
> >> wrote:
> >> > Hi Tycho,
> >> >
> >> > On 09/27/2018 05:11 PM, Tycho Andersen wrote:
> >> > > Hi all,
> >> > >
> >> > > Here's v7 of the seccomp trap to userspace set. There are various minor
> >> > > changes and bug fixes, but two major changes:
> >> > >
> >> > > * We now pass fds to the tracee via an ioctl, and do it immediately 
> >> > > when
> >> > >the ioctl is called. For this we needed some help from the vfs, so
> >> > >I've put the one patch in this series and cc'd fsdevel. This does 
> >> > > have
> >> > >the advantage that the feature is now totally decoupled from the 
> >> > > rest
> >> > >of the set, which is itself useful (thanks Andy!)
> >> > >
> >> > > * Instead of putting all of the notification related stuff into the
> >> > >struct seccomp_filter, it now lives in its own struct notification,
> >> > >which is pointed to by struct seccomp_filter. This will save a lot 
> >> > > of
> >> > >memory (thanks Tyler!)
> >> >
> >> > Is there a documentation (man page) patch for this API change?
> >>
> >> Not yet, but once we decide on a final API I'll prepare one.
> >
> > Honestly, the production of such documentation should be part of the
> > evolution towards the final API...
> >
> > Documentation is not an afterthought. It's a tool for pushing you, the
> > developer (and others, your reviewers) to more deeply consider your
> > design.
>
> In Tycho's defense, he did write up documentation in Documentation/
> for the feature, so it won't be an afterthought. :)

So, I missed that... How do I find this Documentation/ ?

> But yes, there's
> no manpage delta yet.

But, really, there should be, as part of the ongoing evolution of the patch...

(Apologies, Tycho. It may be that I came across a bit harshly.)

Thanks,

Michael


--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/


[PATCH] MAINTAINERS: Drop dt-bindings/genpd/k2g.h

2018-09-28 Thread Nishanth Menon
Drop include/dt-bindings/genpd/k2g.h which disappeared from kernel tree
some time back, however MAINTAINERS file was missed to be updated.

Fixes: d16645054d2f ("dt-bindings: Drop k2g genpd device ID macros")
Cc: Rob Herring 
Cc: Dave Gerlach 
Cc: Santosh Shilimkar 
Cc: Tero Kristo 
Reported-by: Joe Perches 
Signed-off-by: Nishanth Menon 
---

A big oops.. Sorry about that. will do better next time. I tried to relook and
I think we have'nt missed any other files.

Based off next-20180928 tag.

Santosh, any chance you could pick this up -> Thread:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1776470.html

 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c62b724bb60..633aa6385e37 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14550,7 +14550,6 @@ F:  
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
 F: drivers/firmware/ti_sci*
 F: include/linux/soc/ti/ti_sci_protocol.h
 F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
-F: include/dt-bindings/genpd/k2g.h
 F: drivers/soc/ti/ti_sci_pm_domains.c
 F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
 F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
-- 
2.15.1



Re: [PATCH] mm: enforce THP for VM_NOHUGEPAGE dax mappings

2018-09-28 Thread Yang Shi




On 9/28/18 3:36 PM, Dan Williams wrote:

On Fri, Sep 28, 2018 at 3:34 PM  wrote:

commit baabda261424517110ea98c6651f632ebf2561e3 ("mm: always enable thp
for dax mappings") says madvise hguepage policy makes less sense for
dax, and force enabling thp for dax mappings in all cases, even though
THP is set to "never".

However, transparent_hugepage_enabled() may return false if
VM_NOHUGEPAGE is set even though the mapping is dax.

So, move is_vma_dax() check to the very beginning to enforce THP for dax
mappings in all cases.

Cc: Dan Williams 
Cc: Jan Kara 
Cc: Ross Zwisler 
Cc: "Kirill A. Shutemov" 
Signed-off-by: Yang Shi 
---
I didn't find anyone mention the check should be before VM_NOHUGEPAGE in
the review for Dan's original patch. And, that patch commit log states
clearly that THP for dax mapping for all cases even though THP is never.
So, I'm supposed it should behave in this way.

No, if someone explicitly does MADV_NOHUGEPAGE then the kernel should
honor that, even if the mapping is DAX.


Thanks for confirming this. Actually, I had the same question before I 
came up with this patch. "all cases" sounds a little bit misleading.





Re: [PATCH] regulator: core: Pass max_uV value to regulator_set_voltage_rdev

2018-09-28 Thread Tony Lindgren
* Dmitry Osipenko  [180928 22:31]:
> On 9/28/18 11:22 PM, Tony Lindgren wrote:
> > * Dmitry Osipenko  [180928 20:13]:
> >> Tony, could you please give a try to the patch below?
> >>
> >> Do the following:
> >>
> >> 1) git cherry-pick 696861761a58d8c93605b5663824929fb6540f16
> >> 2) git cherry-pick 456e7cdf3b1a14e2606b8b687385ab2e3f23a49a
> >> 3) Apply this patch:
> > 
> > Seems to be getting closer, system boots up and starts
> > init, but then I start getting tons of this on beagle-x15:
> 
> Tony, could you please try this one? Fixed couple more bugs, should be good 
> now.

I'm still getting these errors after init:

[   29.008665] cpu cpu0: vbb failed for 121uV[min 95uV max 150uV]
[   29.015987] cpu cpu0: vbb failed for 106uV[min 85uV max 150uV]
[   29.022967] cpufreq: __target_index: Failed to change cpu frequency: -22
[   29.031993] cpu cpu0: vbb failed for 121uV[min 95uV max 150uV]
[   29.038932] cpu cpu0: vbb failed for 106uV[min 85uV max 150uV]
[   29.045962] cpufreq: __target_index: Failed to change cpu frequency: -22
[   29.055588] cpu cpu0: vbb failed for 121uV[min 95uV max 150uV]
[   29.062639] cpu cpu0: vbb failed for 106uV[min 85uV max 150uV]
[   29.069569] cpufreq: __target_index: Failed to change cpu frequency: -22
[   29.086215] cpu cpu0: vbb failed for 121uV[min 95uV max 150uV]
[   29.093366] cpu cpu0: vbb failed for 106uV[min 85uV max 150uV]
[   29.100295] cpufreq: __target_index: Failed to change cpu frequency: -22
[   29.110370] cpu cpu0: vbb failed for 121uV[min 95uV max 150uV]
[   29.118402] cpu cpu0: vbb failed for 106uV[min 85uV max 150uV]
[   29.125450] cpufreq: __target_index: Failed to change cpu frequency: -22
[   29.127884] palmas-usb 4807.i2c:tps659038@58:tps659038_usb: GPIO lookup 
for consumer id
[   29.136112] cpu cpu0: vbb failed for 121uV[min 95uV max 150uV]
[   29.140658] palmas-usb 4807.i2c:tps659038@58:tps659038_usb: using device 
tree for GPIO lookup
[   29.147728] cpu cpu0: vbb failed for 106uV[min 85uV max 150uV]
...

Regards,

Tony


Re: [PATCH 0/9] AHCI and SATA PHY support for BCM63138

2018-09-28 Thread Florian Fainelli
On 09/25/2018 09:12 AM, Florian Fainelli wrote:
> On 09/24/2018 11:19 PM, Kishon Vijay Abraham I wrote:
>>
>>
>> On Friday 21 September 2018 12:49 AM, Florian Fainelli wrote:
>>> On 09/20/2018 12:16 PM, Florian Fainelli wrote:
 Hi Kishon, Tejun,

 This patch series adds support for the SATA AHCI and PHY found on the
 ARM-basd BCM63138 DSL SoCs.

 It would probably make sense for patches 1-3 to go through Kishon's
 tree, patches 4-7 through Tejun's tree, and I would be merging the last
 two patches through the Broadcom ARM-SoC tree.

 Let me know if this is not a workable plan, thank you very much!
>>>
>>> Looks like I had left patches with the incorrect subject, please
>>> disregard the following patches:
>>>
>>> [PATCH 2/9] phy: broadcom: allow PHY_BRCM_SATA driver to be built for
>>> DSL SoCs
>>> [PATCH 5/9] ata: sata_brcmstb: Allow optional reset controller to be used
>>> [PATCH 6/9] ata: ahci_brcmstb: Match 63138 compatible strings
>>>
>>> since they have incorrect/inconsistent titles, the other patches are
>>> fine though. Sorry about that.
>>
>> merged the first 3 patches to linux-phy tree.
> 
> Thanks a lot Kishon!

Tejun, are you good with picking up patches 4-7 and I take the last two?
Can you make sure you pick up the ones that contain "ahci_brcm" in their
subject, I had incorrectly formatted them initially, sorry again about that.

Thank you!
-- 
Florian


Re: [PATCH] serial: 8250_dw: Fix runtime PM handling

2018-09-28 Thread Guenter Roeck
On Thu, May 10, 2018 at 03:13:56PM +0100, Phil Edworthy wrote:
> When using kgdb, you get an abort when accessing the UART registers.
> This is because the driver has already entered runtime PM and so turned
> off the bus clock needed to access the registers.
> 
> To fix this, set the capability indicating Runtime PM is active while idle.
> 

With this patch applied, I get the already reported traceback [1].
Obviously neither the promised revert [2] nor the presumed fix [3] made it
into the mainline Kernel.

Greg, can you please revert this patch ? If people don't care enough
to fix the problem, we should at least not have to suffer the consequences.

Thanks,
Guenter

> Signed-off-by: Phil Edworthy 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  drivers/tty/serial/8250/8250_dw.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/tty/serial/8250/8250_dw.c 
> b/drivers/tty/serial/8250/8250_dw.c
> index 0529b5cc094b..aff04f1de3a5 100644
> --- a/drivers/tty/serial/8250/8250_dw.c
> +++ b/drivers/tty/serial/8250/8250_dw.c
> @@ -576,6 +576,10 @@ static int dw8250_probe(struct platform_device *pdev)
>   if (!data->skip_autocfg)
>   dw8250_setup_port(p);
>  
> +#ifdef CONFIG_PM
> + uart.capabilities |= UART_CAP_RPM;
> +#endif
> +
>   /* If we have a valid fifosize, try hooking up DMA */
>   if (p->fifosize) {
>   data->dma.rxconf.src_maxburst = p->fifosize / 4;
> -- 
> 2.7.4

---
[1] https://www.spinics.net/lists/linux-serial/msg30379.html
[2] https://www.spinics.net/lists/linux-serial/msg30380.html
[3] https://www.spinics.net/lists/linux-serial/msg30757.html


[PATCH] i2c: brcmstb: Allow enabling the driver on DSL SoCs

2018-09-28 Thread Florian Fainelli
ARCH_BCM_63XX which is used by ARM-based DSL SoCs from Broadcom uses the
same controller, make it possible to select the STB driver and update
the Kconfig and help text a bit.

Signed-off-by: Florian Fainelli 
---
 drivers/i2c/busses/Kconfig | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 451d4ae50e66..fc3fd987f718 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -432,12 +432,13 @@ config I2C_BCM_KONA
  If you do not need KONA I2C interface, say N.
 
 config I2C_BRCMSTB
-   tristate "BRCM Settop I2C controller"
-   depends on ARCH_BRCMSTB || BMIPS_GENERIC || COMPILE_TEST
+   tristate "BRCM Settop/DSL I2C controller"
+   depends on ARCH_BRCMSTB || BMIPS_GENERIC || COMPILE_TEST || \
+  ARCH_BCM_63XX
default y
help
  If you say yes to this option, support will be included for the
- I2C interface on the Broadcom Settop SoCs.
+ I2C interface on the Broadcom Settop/DSL SoCs.
 
  If you do not need I2C interface, say N.
 
-- 
2.17.1



Re: [PATCH RT 2/2] watchdog, rt: prevent deferral of watchdogd wakeup

2018-09-28 Thread kbuild test robot
Hi Julia,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.19-rc5 next-20180928]
[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/Julia-Cartwright/kthread-convert-worker-lock-to-raw-spinlock/20180929-052522
config: i386-randconfig-x008-201838 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers//watchdog/watchdog_dev.c: In function 'watchdog_cdev_register':
>> drivers//watchdog/watchdog_dev.c:948:49: error: 'HRTIMER_MODE_REL_HARD' 
>> undeclared (first use in this function); did you mean 
>> 'HRTIMER_MODE_REL_SOFT'?
 hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
^
HRTIMER_MODE_REL_SOFT
   drivers//watchdog/watchdog_dev.c:948:49: note: each undeclared identifier is 
reported only once for each function it appears in

vim +948 drivers//watchdog/watchdog_dev.c

   919  
   920  /*
   921   *  watchdog_cdev_register: register watchdog character device
   922   *  @wdd: watchdog device
   923   *  @devno: character device number
   924   *
   925   *  Register a watchdog character device including handling the 
legacy
   926   *  /dev/watchdog node. /dev/watchdog is actually a miscdevice and
   927   *  thus we set it up like that.
   928   */
   929  
   930  static int watchdog_cdev_register(struct watchdog_device *wdd, dev_t 
devno)
   931  {
   932  struct watchdog_core_data *wd_data;
   933  int err;
   934  
   935  wd_data = kzalloc(sizeof(struct watchdog_core_data), 
GFP_KERNEL);
   936  if (!wd_data)
   937  return -ENOMEM;
   938  kref_init(&wd_data->kref);
   939  mutex_init(&wd_data->lock);
   940  
   941  wd_data->wdd = wdd;
   942  wdd->wd_data = wd_data;
   943  
   944  if (IS_ERR_OR_NULL(watchdog_kworker))
   945  return -ENODEV;
   946  
   947  kthread_init_work(&wd_data->work, watchdog_ping_work);
 > 948  hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, 
 > HRTIMER_MODE_REL_HARD);
   949  wd_data->timer.function = watchdog_timer_expired;
   950  
   951  if (wdd->id == 0) {
   952  old_wd_data = wd_data;
   953  watchdog_miscdev.parent = wdd->parent;
   954  err = misc_register(&watchdog_miscdev);
   955  if (err != 0) {
   956  pr_err("%s: cannot register miscdev on minor=%d 
(err=%d).\n",
   957  wdd->info->identity, WATCHDOG_MINOR, 
err);
   958  if (err == -EBUSY)
   959  pr_err("%s: a legacy watchdog module is 
probably present.\n",
   960  wdd->info->identity);
   961  old_wd_data = NULL;
   962  kfree(wd_data);
   963  return err;
   964  }
   965  }
   966  
   967  /* Fill in the data structures */
   968  cdev_init(&wd_data->cdev, &watchdog_fops);
   969  wd_data->cdev.owner = wdd->ops->owner;
   970  
   971  /* Add the device */
   972  err = cdev_add(&wd_data->cdev, devno, 1);
   973  if (err) {
   974  pr_err("watchdog%d unable to add device %d:%d\n",
   975  wdd->id,  MAJOR(watchdog_devt), wdd->id);
   976  if (wdd->id == 0) {
   977  misc_deregister(&watchdog_miscdev);
   978  old_wd_data = NULL;
   979  kref_put(&wd_data->kref, 
watchdog_core_data_release);
   980  }
   981  return err;
   982  }
   983  
   984  /* Record time of most recent heartbeat as 'just before now'. */
   985  wd_data->last_hw_keepalive = ktime_sub(ktime_get(), 1);
   986  
   987  /*
   988   * If the watchdog is running, prevent its driver from being 
unloaded,
   989   * and schedule an immediate ping.
   990   */
   991  if (watchdog_hw_running(wdd)) {
   992  __module_get(wdd->ops->owner);
   993  kref_get(&wd_data->kref);
   994  if (handle_boot_enabled)
   995  hrtimer_start(&wd_d

Re: [PATCH 05/13] staging:rtl8192u: Remove AdvCoding and GreenField - Style

2018-09-28 Thread John Whitmore
On Fri, Sep 28, 2018 at 02:35:50PM +0200, Greg KH wrote:
> On Wed, Sep 26, 2018 at 08:16:56PM +0100, John Whitmore wrote:
> > The member variables AdvCoding and GreenField are unused in code so
> > have been removed from the structure and associated initialisation
> > function.
> > 
> > This is a coding style change which should have no impact on runtime
> > code execution.
> > 
> > Signed-off-by: John Whitmore 
> > ---
> >  drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 2 --
> >  drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 2 --
> >  2 files changed, 4 deletions(-)
> > 
> > diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
> > b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > index 64d5359cf7e2..83fb8f34ccbd 100644
> > --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > @@ -39,10 +39,8 @@ enum ht_extension_chan_offset {
> >  
> >  struct ht_capability_ele {
> > //HT capability info
> > -   u8  AdvCoding:1;
> > u8  ChlWidth:1;
> > u8  MimoPwrSave:2;
> > -   u8  GreenField:1;
> 
> Don't these fields come from the hardware itself?  By removing them
> here, you just changed the memory layout of the structure.  Does the
> driver still work properly after this?  If you can't test it, I can't
> take this patch as it's too risky...
> 

Sorry, yes the structure looks like it should come from the hardware
but as the structure is allocated from memory I expected to find a
memcopy either to or from the hardware. Yes risky, just because I
couldn't find it don't mean the connection to hardware ain't there.

I'll lay off the risky and who knows if I keep wondering through the
driver I'll find that illusive connection.


[PATCH] pstore/ram: Fix failure-path memory leak in ramoops_init

2018-09-28 Thread Kees Cook
As reported by nixiaoming, with some minor clarifications:

1) memory leak in ramoops_register_dummy():
   dummy_data = kzalloc(sizeof(*dummy_data), GFP_KERNEL);
   but no kfree() if platform_device_register_data() fails.

2) memory leak in ramoops_init():
   Missing platform_device_unregister(dummy) and kfree(dummy_data)
   if platform_driver_register(&ramoops_driver) fails.

I've clarified the purpose of ramoops_register_dummy(), and added a
common cleanup routine for all three failure paths to call.

Reported-by: nixiaoming 
Cc: sta...@vger.kernel.org
Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Tony Luck 
Cc: Joel Fernandes 
Cc: Geliang Tang 
Signed-off-by: Kees Cook 
---
After my local testing I'll send this via the regular pstore tree.
---
 fs/pstore/ram.c | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index bbd1e357c23d..f4fd2e72add4 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -898,8 +898,22 @@ static struct platform_driver ramoops_driver = {
},
 };
 
-static void ramoops_register_dummy(void)
+static inline void ramoops_unregister_dummy(void)
 {
+   platform_device_unregister(dummy);
+   dummy = NULL;
+
+   kfree(dummy_data);
+   dummy_data = NULL;
+}
+
+static void __init ramoops_register_dummy(void)
+{
+   /*
+* Prepare a dummy platform data structure to carry the module
+* parameters. If mem_size isn't set, then there are no module
+* parameters, and we can skip this.
+*/
if (!mem_size)
return;
 
@@ -932,21 +946,28 @@ static void ramoops_register_dummy(void)
if (IS_ERR(dummy)) {
pr_info("could not create platform device: %ld\n",
PTR_ERR(dummy));
+   dummy = NULL;
+   ramoops_unregister_dummy();
}
 }
 
 static int __init ramoops_init(void)
 {
+   int ret;
+
ramoops_register_dummy();
-   return platform_driver_register(&ramoops_driver);
+   ret = platform_driver_register(&ramoops_driver);
+   if (ret != 0)
+   ramoops_unregister_dummy();
+
+   return ret;
 }
 late_initcall(ramoops_init);
 
 static void __exit ramoops_exit(void)
 {
platform_driver_unregister(&ramoops_driver);
-   platform_device_unregister(dummy);
-   kfree(dummy_data);
+   ramoops_unregister_dummy();
 }
 module_exit(ramoops_exit);
 
-- 
2.17.1


-- 
Kees Cook
Pixel Security


[PATCH v5 03/21] tpm: factor out tpm 1.x duration calculation to tpm1-cmd.c

2018-09-28 Thread Tomas Winkler
Factor out TPM 1.x commands calculation into tpm1-cmd.c file.
and change the prefix from tpm_ to tpm1_.
No functional change is done here.

Signed-off-by: Tomas Winkler 
Tested-by: Jarkko Sakkinen 
---
V2-V3: Rebase
V4: 1. Remove the licence statement it's already covered by SPDX.
2. Add kdoc to tpm1_calc_ordinal_duration().
V5: Adjust the kdoc to the new standard.

 drivers/char/tpm/Makefile|   1 +
 drivers/char/tpm/st33zp24/st33zp24.c |   2 +-
 drivers/char/tpm/tpm-interface.c | 284 +---
 drivers/char/tpm/tpm.h   |   2 +-
 drivers/char/tpm/tpm1-cmd.c  | 310 +++
 drivers/char/tpm/tpm_i2c_nuvoton.c   |  10 +-
 drivers/char/tpm/tpm_tis_core.c  |   2 +-
 drivers/char/tpm/xen-tpmfront.c  |   2 +-
 8 files changed, 322 insertions(+), 291 deletions(-)
 create mode 100644 drivers/char/tpm/tpm1-cmd.c

diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile
index efc785053627..a01c4cab902a 100644
--- a/drivers/char/tpm/Makefile
+++ b/drivers/char/tpm/Makefile
@@ -7,6 +7,7 @@ tpm-y := tpm-chip.o
 tpm-y += tpm-dev-common.o
 tpm-y += tpm-dev.o
 tpm-y += tpm-interface.o
+tpm-y += tpm1-cmd.o
 tpm-y += tpm2-cmd.o
 tpm-y += tpmrm-dev.o
 tpm-y += tpm2-space.o
diff --git a/drivers/char/tpm/st33zp24/st33zp24.c 
b/drivers/char/tpm/st33zp24/st33zp24.c
index abd675bec88c..16be974955ea 100644
--- a/drivers/char/tpm/st33zp24/st33zp24.c
+++ b/drivers/char/tpm/st33zp24/st33zp24.c
@@ -430,7 +430,7 @@ static int st33zp24_send(struct tpm_chip *chip, unsigned 
char *buf,
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
 
ret = wait_for_stat(chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
-   tpm_calc_ordinal_duration(chip, ordinal),
+   tpm1_calc_ordinal_duration(chip, ordinal),
&tpm_dev->read_queue, false);
if (ret < 0)
goto out_err;
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 129f640424b7..bb3eed907c72 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -33,7 +33,6 @@
 
 #include "tpm.h"
 
-#define TPM_MAX_ORDINAL 243
 #define TSC_MAX_ORDINAL 12
 #define TPM_PROTECTED_COMMAND 0x00
 #define TPM_CONNECTION_COMMAND 0x40
@@ -48,285 +47,6 @@ module_param_named(suspend_pcr, tpm_suspend_pcr, uint, 
0644);
 MODULE_PARM_DESC(suspend_pcr,
 "PCR to use for dummy writes to facilitate flush on suspend.");
 
-/*
- * Array with one entry per ordinal defining the maximum amount
- * of time the chip could take to return the result.  The ordinal
- * designation of short, medium or long is defined in a table in
- * TCG Specification TPM Main Part 2 TPM Structures Section 17. The
- * values of the SHORT, MEDIUM, and LONG durations are retrieved
- * from the chip during initialization with a call to tpm_get_timeouts.
- */
-static const u8 tpm_ordinal_duration[TPM_MAX_ORDINAL] = {
-   TPM_UNDEFINED,  /* 0 */
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,  /* 5 */
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_SHORT,  /* 10 */
-   TPM_SHORT,
-   TPM_MEDIUM,
-   TPM_LONG,
-   TPM_LONG,
-   TPM_MEDIUM, /* 15 */
-   TPM_SHORT,
-   TPM_SHORT,
-   TPM_MEDIUM,
-   TPM_LONG,
-   TPM_SHORT,  /* 20 */
-   TPM_SHORT,
-   TPM_MEDIUM,
-   TPM_MEDIUM,
-   TPM_MEDIUM,
-   TPM_SHORT,  /* 25 */
-   TPM_SHORT,
-   TPM_MEDIUM,
-   TPM_SHORT,
-   TPM_SHORT,
-   TPM_MEDIUM, /* 30 */
-   TPM_LONG,
-   TPM_MEDIUM,
-   TPM_SHORT,
-   TPM_SHORT,
-   TPM_SHORT,  /* 35 */
-   TPM_MEDIUM,
-   TPM_MEDIUM,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_MEDIUM, /* 40 */
-   TPM_LONG,
-   TPM_MEDIUM,
-   TPM_SHORT,
-   TPM_SHORT,
-   TPM_SHORT,  /* 45 */
-   TPM_SHORT,
-   TPM_SHORT,
-   TPM_SHORT,
-   TPM_LONG,
-   TPM_MEDIUM, /* 50 */
-   TPM_MEDIUM,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,  /* 55 */
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_MEDIUM, /* 60 */
-   TPM_MEDIUM,
-   TPM_MEDIUM,
-   TPM_SHORT,
-   TPM_SHORT,
-   TPM_MEDIUM, /* 65 */
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_SHORT,  /* 70 */
-   TPM_SHORT,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,  /* 75 */
-   TPM_UNDEFINED,
-   TPM_UNDEFINED,
-   

[PATCH v5 04/21] tpm: add tpm_calc_ordinal_duration() wrapper

2018-09-28 Thread Tomas Winkler
Add convenient wrapper for ordinal duration computation
to remove boiler plate if else statement over TPM2.

if (chip->flags & TPM_CHIP_FLAG_TPM2)
tpm2_calc_ordinal_duration(chip, ordinal);
else
tpm1_calc_ordinal_duration(chip, ordinal);

Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
---
V2-V3: Rebase.
V4: Add Kdoc.
V5: Adjust the kdoc to the new standard.

 drivers/char/tpm/st33zp24/st33zp24.c |  2 +-
 drivers/char/tpm/tpm-interface.c | 24 
 drivers/char/tpm/tpm.h   |  1 +
 drivers/char/tpm/tpm1-cmd.c  |  1 -
 drivers/char/tpm/tpm2-cmd.c  |  1 -
 drivers/char/tpm/tpm_i2c_nuvoton.c   |  2 +-
 drivers/char/tpm/tpm_tis_core.c  |  6 +-
 drivers/char/tpm/xen-tpmfront.c  |  2 +-
 8 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/drivers/char/tpm/st33zp24/st33zp24.c 
b/drivers/char/tpm/st33zp24/st33zp24.c
index 16be974955ea..abd675bec88c 100644
--- a/drivers/char/tpm/st33zp24/st33zp24.c
+++ b/drivers/char/tpm/st33zp24/st33zp24.c
@@ -430,7 +430,7 @@ static int st33zp24_send(struct tpm_chip *chip, unsigned 
char *buf,
ordinal = be32_to_cpu(*((__be32 *) (buf + 6)));
 
ret = wait_for_stat(chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
-   tpm1_calc_ordinal_duration(chip, ordinal),
+   tpm_calc_ordinal_duration(chip, ordinal),
&tpm_dev->read_queue, false);
if (ret < 0)
goto out_err;
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index bb3eed907c72..305eb3069101 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -47,6 +47,25 @@ module_param_named(suspend_pcr, tpm_suspend_pcr, uint, 0644);
 MODULE_PARM_DESC(suspend_pcr,
 "PCR to use for dummy writes to facilitate flush on suspend.");
 
+/**
+ * tpm_calc_ordinal_duration() - calculate the maximum command duration
+ * @chip:TPM chip to use.
+ * @ordinal: TPM command ordinal.
+ *
+ * The function returns the maximum amount of time the chip could take
+ * to return the result for a particular ordinal in jiffies.
+ *
+ * Return: A maximal duration time for an ordinal in jiffies.
+ */
+unsigned long tpm_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal)
+{
+   if (chip->flags & TPM_CHIP_FLAG_TPM2)
+   return tpm2_calc_ordinal_duration(chip, ordinal);
+   else
+   return tpm1_calc_ordinal_duration(chip, ordinal);
+}
+EXPORT_SYMBOL_GPL(tpm_calc_ordinal_duration);
+
 static int tpm_validate_command(struct tpm_chip *chip,
 struct tpm_space *space,
 const u8 *cmd,
@@ -220,10 +239,7 @@ static ssize_t tpm_try_transmit(struct tpm_chip *chip,
if (chip->flags & TPM_CHIP_FLAG_IRQ)
goto out_recv;
 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2)
-   stop = jiffies + tpm2_calc_ordinal_duration(chip, ordinal);
-   else
-   stop = jiffies + tpm1_calc_ordinal_duration(chip, ordinal);
+   stop = jiffies + tpm_calc_ordinal_duration(chip, ordinal);
do {
u8 status = chip->ops->status(chip);
if ((status & chip->ops->req_complete_mask) ==
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index c59d2c20c339..73511cd89bef 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -547,6 +547,7 @@ int tpm_get_timeouts(struct tpm_chip *);
 int tpm1_auto_startup(struct tpm_chip *chip);
 int tpm_do_selftest(struct tpm_chip *chip);
 unsigned long tpm1_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
+unsigned long tpm_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
 int tpm_pm_suspend(struct device *dev);
 int tpm_pm_resume(struct device *dev);
 
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 991260134659..dfbe9c60cbcf 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -307,4 +307,3 @@ unsigned long tpm1_calc_ordinal_duration(struct tpm_chip 
*chip, u32 ordinal)
else
return duration;
 }
-EXPORT_SYMBOL_GPL(tpm1_calc_ordinal_duration);
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index f08478c78bf7..5e7bf8842be0 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -132,7 +132,6 @@ unsigned long tpm2_calc_ordinal_duration(struct tpm_chip 
*chip, u32 ordinal)
else
return msecs_to_jiffies(TPM2_DURATION_DEFAULT);
 }
-EXPORT_SYMBOL_GPL(tpm2_calc_ordinal_duration);
 
 
 struct tpm2_pcr_read_out {
diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c 
b/drivers/char/tpm/tpm_i2c_nuvoton.c
index 5d20e98b844f..4146f822fba9 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c
@@ -456,7 +456,7 @@ static int i2c_nuvoton_se

Re: [PATCH] mm: enforce THP for VM_NOHUGEPAGE dax mappings

2018-09-28 Thread Dan Williams
On Fri, Sep 28, 2018 at 3:34 PM  wrote:
>
> commit baabda261424517110ea98c6651f632ebf2561e3 ("mm: always enable thp
> for dax mappings") says madvise hguepage policy makes less sense for
> dax, and force enabling thp for dax mappings in all cases, even though
> THP is set to "never".
>
> However, transparent_hugepage_enabled() may return false if
> VM_NOHUGEPAGE is set even though the mapping is dax.
>
> So, move is_vma_dax() check to the very beginning to enforce THP for dax
> mappings in all cases.
>
> Cc: Dan Williams 
> Cc: Jan Kara 
> Cc: Ross Zwisler 
> Cc: "Kirill A. Shutemov" 
> Signed-off-by: Yang Shi 
> ---
> I didn't find anyone mention the check should be before VM_NOHUGEPAGE in
> the review for Dan's original patch. And, that patch commit log states
> clearly that THP for dax mapping for all cases even though THP is never.
> So, I'm supposed it should behave in this way.

No, if someone explicitly does MADV_NOHUGEPAGE then the kernel should
honor that, even if the mapping is DAX.


[PATCH v5 08/21] tpm: factor out tpm1_get_random into tpm1-cmd.c

2018-09-28 Thread Tomas Winkler
Factor out get random implementation from tpm-interface.c
into tpm1_get_random function in tpm1-cmd.c.
No functional changes.

Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkine 
---
V2-V3: Rebase
V4-V5: Resend

 drivers/char/tpm/tpm-interface.c | 58 +---
 drivers/char/tpm/tpm.h   |  1 +
 drivers/char/tpm/tpm1-cmd.c  | 55 +
 3 files changed, 63 insertions(+), 51 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index a94a88f9f91c..a2205f26c74c 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -811,14 +811,6 @@ int tpm_pm_resume(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(tpm_pm_resume);
 
-#define TPM_ORD_GET_RANDOM 70
-#define TPM_GETRANDOM_RESULT_SIZE  18
-static const struct tpm_input_header tpm_getrandom_header = {
-   .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
-   .length = cpu_to_be32(14),
-   .ordinal = cpu_to_be32(TPM_ORD_GET_RANDOM)
-};
-
 /**
  * tpm_get_random() - get random bytes from the TPM's RNG
  * @chip:  a &struct tpm_chip instance, %NULL for the default chip
@@ -829,58 +821,22 @@ static const struct tpm_input_header tpm_getrandom_header 
= {
  */
 int tpm_get_random(struct tpm_chip *chip, u8 *out, size_t max)
 {
-   struct tpm_cmd_t tpm_cmd;
-   u32 recd, num_bytes = min_t(u32, max, TPM_MAX_RNG_DATA), rlength;
-   int err, total = 0, retries = 5;
-   u8 *dest = out;
+   int rc;
 
-   if (!out || !num_bytes || max > TPM_MAX_RNG_DATA)
+   if (!out || max > TPM_MAX_RNG_DATA)
return -EINVAL;
 
chip = tpm_find_get_ops(chip);
if (!chip)
return -ENODEV;
 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2) {
-   err = tpm2_get_random(chip, out, max);
-   tpm_put_ops(chip);
-   return err;
-   }
-
-   do {
-   tpm_cmd.header.in = tpm_getrandom_header;
-   tpm_cmd.params.getrandom_in.num_bytes = cpu_to_be32(num_bytes);
-
-   err = tpm_transmit_cmd(chip, NULL, &tpm_cmd,
-  TPM_GETRANDOM_RESULT_SIZE + num_bytes,
-  offsetof(struct tpm_getrandom_out,
-   rng_data),
-  0, "attempting get random");
-   if (err)
-   break;
-
-   recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len);
-   if (recd > num_bytes) {
-   total = -EFAULT;
-   break;
-   }
-
-   rlength = be32_to_cpu(tpm_cmd.header.out.length);
-   if (rlength < TPM_HEADER_SIZE +
- offsetof(struct tpm_getrandom_out, rng_data) +
- recd) {
-   total = -EFAULT;
-   break;
-   }
-   memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd);
-
-   dest += recd;
-   total += recd;
-   num_bytes -= recd;
-   } while (retries-- && total < max);
+   if (chip->flags & TPM_CHIP_FLAG_TPM2)
+   rc = tpm2_get_random(chip, out, max);
+   else
+   rc = tpm1_get_random(chip, out, max);
 
tpm_put_ops(chip);
-   return total ? total : -EIO;
+   return rc;
 }
 EXPORT_SYMBOL_GPL(tpm_get_random);
 
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 1c1980c79c30..496a56156e77 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -551,6 +551,7 @@ int tpm1_pcr_extend(struct tpm_chip *chip, int pcr_idx, 
const u8 *hash,
const char *log_msg);
 ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, cap_t *cap,
const char *desc, size_t min_cap_length);
+int tpm1_get_random(struct tpm_chip *chip, u8 *out, size_t max);
 unsigned long tpm_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal);
 int tpm_pm_suspend(struct device *dev);
 int tpm_pm_resume(struct device *dev);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 3bd079587ef5..e02f0c1c822f 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -469,3 +469,58 @@ ssize_t tpm1_getcap(struct tpm_chip *chip, u32 subcap_id, 
cap_t *cap,
return rc;
 }
 EXPORT_SYMBOL_GPL(tpm1_getcap);
+
+#define TPM_ORD_GET_RANDOM 70
+#define TPM_GETRANDOM_RESULT_SIZE  18
+static const struct tpm_input_header tpm_getrandom_header = {
+   .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
+   .length = cpu_to_be32(14),
+   .ordinal = cpu_to_be32(TPM_ORD_GET_RANDOM)
+};
+
+int tpm1_get_random(struct tpm_chip *chip, u8 *out, size_t max)
+{
+   struct tpm_cmd_t tpm_cmd;
+   u32 recd;
+   u32 num_bytes = min_t(u32, max, TPM_MAX_RNG_DATA);
+   u32 rlength;
+   int er

[PATCH v5 05/21] tpm: factor out tpm_get_timeouts()

2018-09-28 Thread Tomas Winkler
Factor out tpm_get_timeouts() into tpm2_get_timeouts()
and tpm1_get_timeouts()

Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
---
V2-V3: Rebase
V4: Fix the commit message.
V5: Resend.

 drivers/char/tpm/tpm-interface.c | 127 ++-
 drivers/char/tpm/tpm.h   |   5 +-
 drivers/char/tpm/tpm1-cmd.c  | 106 
 drivers/char/tpm/tpm2-cmd.c  |  22 +++
 4 files changed, 136 insertions(+), 124 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 305eb3069101..1fa0300f3829 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -502,132 +502,13 @@ EXPORT_SYMBOL_GPL(tpm_getcap);
 
 int tpm_get_timeouts(struct tpm_chip *chip)
 {
-   cap_t cap;
-   unsigned long timeout_old[4], timeout_chip[4], timeout_eff[4];
-   ssize_t rc;
-
if (chip->flags & TPM_CHIP_FLAG_HAVE_TIMEOUTS)
return 0;
 
-   if (chip->flags & TPM_CHIP_FLAG_TPM2) {
-   /* Fixed timeouts for TPM2 */
-   chip->timeout_a = msecs_to_jiffies(TPM2_TIMEOUT_A);
-   chip->timeout_b = msecs_to_jiffies(TPM2_TIMEOUT_B);
-   chip->timeout_c = msecs_to_jiffies(TPM2_TIMEOUT_C);
-   chip->timeout_d = msecs_to_jiffies(TPM2_TIMEOUT_D);
-   chip->duration[TPM_SHORT] =
-   msecs_to_jiffies(TPM2_DURATION_SHORT);
-   chip->duration[TPM_MEDIUM] =
-   msecs_to_jiffies(TPM2_DURATION_MEDIUM);
-   chip->duration[TPM_LONG] =
-   msecs_to_jiffies(TPM2_DURATION_LONG);
-   chip->duration[TPM_LONG_LONG] =
-   msecs_to_jiffies(TPM2_DURATION_LONG_LONG);
-
-   chip->flags |= TPM_CHIP_FLAG_HAVE_TIMEOUTS;
-   return 0;
-   }
-
-   rc = tpm_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap, NULL,
-   sizeof(cap.timeout));
-   if (rc == TPM_ERR_INVALID_POSTINIT) {
-   if (tpm_startup(chip))
-   return rc;
-
-   rc = tpm_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap,
-   "attempting to determine the timeouts",
-   sizeof(cap.timeout));
-   }
-
-   if (rc) {
-   dev_err(&chip->dev,
-   "A TPM error (%zd) occurred attempting to determine the 
timeouts\n",
-   rc);
-   return rc;
-   }
-
-   timeout_old[0] = jiffies_to_usecs(chip->timeout_a);
-   timeout_old[1] = jiffies_to_usecs(chip->timeout_b);
-   timeout_old[2] = jiffies_to_usecs(chip->timeout_c);
-   timeout_old[3] = jiffies_to_usecs(chip->timeout_d);
-   timeout_chip[0] = be32_to_cpu(cap.timeout.a);
-   timeout_chip[1] = be32_to_cpu(cap.timeout.b);
-   timeout_chip[2] = be32_to_cpu(cap.timeout.c);
-   timeout_chip[3] = be32_to_cpu(cap.timeout.d);
-   memcpy(timeout_eff, timeout_chip, sizeof(timeout_eff));
-
-   /*
-* Provide ability for vendor overrides of timeout values in case
-* of misreporting.
-*/
-   if (chip->ops->update_timeouts != NULL)
-   chip->timeout_adjusted =
-   chip->ops->update_timeouts(chip, timeout_eff);
-
-   if (!chip->timeout_adjusted) {
-   /* Restore default if chip reported 0 */
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(timeout_eff); i++) {
-   if (timeout_eff[i])
-   continue;
-
-   timeout_eff[i] = timeout_old[i];
-   chip->timeout_adjusted = true;
-   }
-
-   if (timeout_eff[0] != 0 && timeout_eff[0] < 1000) {
-   /* timeouts in msec rather usec */
-   for (i = 0; i != ARRAY_SIZE(timeout_eff); i++)
-   timeout_eff[i] *= 1000;
-   chip->timeout_adjusted = true;
-   }
-   }
-
-   /* Report adjusted timeouts */
-   if (chip->timeout_adjusted) {
-   dev_info(&chip->dev,
-HW_ERR "Adjusting reported timeouts: A %lu->%luus B 
%lu->%luus C %lu->%luus D %lu->%luus\n",
-timeout_chip[0], timeout_eff[0],
-timeout_chip[1], timeout_eff[1],
-timeout_chip[2], timeout_eff[2],
-timeout_chip[3], timeout_eff[3]);
-   }
-
-   chip->timeout_a = usecs_to_jiffies(timeout_eff[0]);
-   chip->timeout_b = usecs_to_jiffies(timeout_eff[1]);
-   chip->timeout_c = usecs_to_jiffies(timeout_eff[2]);
-   chip->timeout_d = usecs_to_jiffies(timeout_eff[3]);
-
-   rc = tpm_getcap(chip, TPM_CAP_PROP_TIS_DURATION, &cap,
-   "attempting to determine the durations",
-   size

[PATCH v5 09/21] tpm: move tpm 1.x selftest code from tpm-interface.c tpm1-cmd.c

2018-09-28 Thread Tomas Winkler
Move the tpm1 selftest code functions to tpm1-cmd.c
and adjust callers to use the new function names.
 1. tpm_pcr_read_dev() to tpm1_pcr_read_dev().
 2. tpm_continue_selftest() to tpm1_continue_selftest().
 3. tpm_do_selftest() to tpm1_do_selftest()

Signed-off-by: Tomas Winkler 
Tested-by: Jarkko Sakkinen 
Reviewed-by: Jarkko Sakkinen 
---

V2-V3: Rebase
V4: Fix the commit message.
V5: Resend.

 drivers/char/tpm/st33zp24/st33zp24.c |   2 +-
 drivers/char/tpm/tpm-interface.c | 148 +--
 drivers/char/tpm/tpm-sysfs.c |   2 +-
 drivers/char/tpm/tpm.h   |   4 +-
 drivers/char/tpm/tpm1-cmd.c  | 142 +
 drivers/char/tpm/tpm_tis_core.c  |   2 +-
 6 files changed, 150 insertions(+), 150 deletions(-)

diff --git a/drivers/char/tpm/st33zp24/st33zp24.c 
b/drivers/char/tpm/st33zp24/st33zp24.c
index abd675bec88c..64dc560859f2 100644
--- a/drivers/char/tpm/st33zp24/st33zp24.c
+++ b/drivers/char/tpm/st33zp24/st33zp24.c
@@ -649,7 +649,7 @@ int st33zp24_pm_resume(struct device *dev)
} else {
ret = tpm_pm_resume(dev);
if (!ret)
-   tpm_do_selftest(chip);
+   tpm1_do_selftest(chip);
}
return ret;
 } /* st33zp24_pm_resume() */
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index a2205f26c74c..70b20b4c789a 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -466,59 +466,6 @@ int tpm_get_timeouts(struct tpm_chip *chip)
 }
 EXPORT_SYMBOL_GPL(tpm_get_timeouts);
 
-#define TPM_ORD_CONTINUE_SELFTEST 83
-#define CONTINUE_SELFTEST_RESULT_SIZE 10
-
-static const struct tpm_input_header continue_selftest_header = {
-   .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
-   .length = cpu_to_be32(10),
-   .ordinal = cpu_to_be32(TPM_ORD_CONTINUE_SELFTEST),
-};
-
-/**
- * tpm_continue_selftest -- run TPM's selftest
- * @chip: TPM chip to use
- *
- * Returns 0 on success, < 0 in case of fatal error or a value > 0 representing
- * a TPM error code.
- */
-static int tpm_continue_selftest(struct tpm_chip *chip)
-{
-   int rc;
-   struct tpm_cmd_t cmd;
-
-   cmd.header.in = continue_selftest_header;
-   rc = tpm_transmit_cmd(chip, NULL, &cmd, CONTINUE_SELFTEST_RESULT_SIZE,
- 0, 0, "continue selftest");
-   return rc;
-}
-
-#define TPM_ORDINAL_PCRREAD 21
-#define READ_PCR_RESULT_SIZE 30
-#define READ_PCR_RESULT_BODY_SIZE 20
-static const struct tpm_input_header pcrread_header = {
-   .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
-   .length = cpu_to_be32(14),
-   .ordinal = cpu_to_be32(TPM_ORDINAL_PCRREAD)
-};
-
-int tpm_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
-{
-   int rc;
-   struct tpm_cmd_t cmd;
-
-   cmd.header.in = pcrread_header;
-   cmd.params.pcrread_in.pcr_idx = cpu_to_be32(pcr_idx);
-   rc = tpm_transmit_cmd(chip, NULL, &cmd, READ_PCR_RESULT_SIZE,
- READ_PCR_RESULT_BODY_SIZE, 0,
- "attempting to read a pcr value");
-
-   if (rc == 0)
-   memcpy(res_buf, cmd.params.pcrread_out.pcr_result,
-  TPM_DIGEST_SIZE);
-   return rc;
-}
-
 /**
  * tpm_is_tpm2 - do we a have a TPM2 chip?
  * @chip:  a &struct tpm_chip instance, %NULL for the default chip
@@ -559,10 +506,12 @@ int tpm_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 
*res_buf)
chip = tpm_find_get_ops(chip);
if (!chip)
return -ENODEV;
+
if (chip->flags & TPM_CHIP_FLAG_TPM2)
rc = tpm2_pcr_read(chip, pcr_idx, res_buf);
else
-   rc = tpm_pcr_read_dev(chip, pcr_idx, res_buf);
+   rc = tpm1_pcr_read_dev(chip, pcr_idx, res_buf);
+
tpm_put_ops(chip);
return rc;
 }
@@ -613,97 +562,6 @@ int tpm_pcr_extend(struct tpm_chip *chip, int pcr_idx, 
const u8 *hash)
 }
 EXPORT_SYMBOL_GPL(tpm_pcr_extend);
 
-/**
- * tpm_do_selftest - have the TPM continue its selftest and wait until it
- *   can receive further commands
- * @chip: TPM chip to use
- *
- * Returns 0 on success, < 0 in case of fatal error or a value > 0 representing
- * a TPM error code.
- */
-int tpm_do_selftest(struct tpm_chip *chip)
-{
-   int rc;
-   unsigned int loops;
-   unsigned int delay_msec = 100;
-   unsigned long duration;
-   u8 dummy[TPM_DIGEST_SIZE];
-
-   duration = tpm1_calc_ordinal_duration(chip, TPM_ORD_CONTINUE_SELFTEST);
-
-   loops = jiffies_to_msecs(duration) / delay_msec;
-
-   rc = tpm_continue_selftest(chip);
-   if (rc == TPM_ERR_INVALID_POSTINIT) {
-   chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
-   dev_info(&chip->dev, "TPM not ready (%d)\n", rc);
-   }
-   /* This may fail if there was no TPM driver during a suspend/resume
-* cycle; some may return 10 (BAD_OR

[PATCH v5 11/21] tpm: factor out tpm_startup function

2018-09-28 Thread Tomas Winkler
TPM manual startup is used only from within TPM 1.x or TPM 2.x
code, hence remove tpm_startup() function from tpm-interface.c
and add two static functions implementations tpm1_startup()
and tpm2_startup() into to tpm1-cmd.c and tpm2-cmd.c respectively.

Signed-off-by: Tomas Winkler 
Tested-by: Jarkko Sakkinen 
---
V2-V2: Resend.
V4: Fix the commit message.
V5: 1. A small fix in the kdoc.
2. Fixed Jarkko's name in Tested-by.

 drivers/char/tpm/tpm-interface.c | 41 
 drivers/char/tpm/tpm.h   |  1 -
 drivers/char/tpm/tpm1-cmd.c  | 37 +++-
 drivers/char/tpm/tpm2-cmd.c  | 34 +++--
 4 files changed, 68 insertions(+), 45 deletions(-)

diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 25242190a941..d33060511a27 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -413,47 +413,6 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct 
tpm_space *space,
 }
 EXPORT_SYMBOL_GPL(tpm_transmit_cmd);
 
-#define TPM_ORD_STARTUP 153
-#define TPM_ST_CLEAR 1
-
-/**
- * tpm_startup - turn on the TPM
- * @chip: TPM chip to use
- *
- * Normally the firmware should start the TPM. This function is provided as a
- * workaround if this does not happen. A legal case for this could be for
- * example when a TPM emulator is used.
- *
- * Return: same as tpm_transmit_cmd()
- */
-int tpm_startup(struct tpm_chip *chip)
-{
-   struct tpm_buf buf;
-   int rc;
-
-   dev_info(&chip->dev, "starting up the TPM manually\n");
-
-   if (chip->flags & TPM_CHIP_FLAG_TPM2) {
-   rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_STARTUP);
-   if (rc < 0)
-   return rc;
-
-   tpm_buf_append_u16(&buf, TPM2_SU_CLEAR);
-   } else {
-   rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_STARTUP);
-   if (rc < 0)
-   return rc;
-
-   tpm_buf_append_u16(&buf, TPM_ST_CLEAR);
-   }
-
-   rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
- "attempting to start the TPM");
-
-   tpm_buf_destroy(&buf);
-   return rc;
-}
-
 int tpm_get_timeouts(struct tpm_chip *chip)
 {
if (chip->flags & TPM_CHIP_FLAG_HAVE_TIMEOUTS)
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 862c9262e037..fa88102a0cab 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -540,7 +540,6 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct 
tpm_space *space,
 void *buf, size_t bufsiz,
 size_t min_rsp_body_length, unsigned int flags,
 const char *desc);
-int tpm_startup(struct tpm_chip *chip);
 int tpm_get_timeouts(struct tpm_chip *);
 
 int tpm1_pm_suspend(struct tpm_chip *chip, int tpm_suspend_pcr);
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index 3bd9f1fa77ce..5b2e743a3e51 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -308,6 +308,40 @@ unsigned long tpm1_calc_ordinal_duration(struct tpm_chip 
*chip, u32 ordinal)
return duration;
 }
 
+#define TPM_ORD_STARTUP 153
+#define TPM_ST_CLEAR 1
+
+/**
+ * tpm_startup - turn on the TPM
+ * @chip: TPM chip to use
+ *
+ * Normally the firmware should start the TPM. This function is provided as a
+ * workaround if this does not happen. A legal case for this could be for
+ * example when a TPM emulator is used.
+ *
+ * Return: same as tpm_transmit_cmd()
+ */
+static int tpm1_startup(struct tpm_chip *chip)
+{
+   struct tpm_buf buf;
+   int rc;
+
+   dev_info(&chip->dev, "starting up the TPM manually\n");
+
+   rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_STARTUP);
+   if (rc < 0)
+   return rc;
+
+   tpm_buf_append_u16(&buf, TPM_ST_CLEAR);
+
+   rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
+ "attempting to start the TPM");
+
+   tpm_buf_destroy(&buf);
+
+   return rc;
+}
+
 int tpm1_get_timeouts(struct tpm_chip *chip)
 {
cap_t cap;
@@ -317,7 +351,7 @@ int tpm1_get_timeouts(struct tpm_chip *chip)
rc = tpm1_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap, NULL,
 sizeof(cap.timeout));
if (rc == TPM_ERR_INVALID_POSTINIT) {
-   if (tpm_startup(chip))
+   if (tpm1_startup(chip))
return rc;
 
rc = tpm1_getcap(chip, TPM_CAP_PROP_TIS_TIMEOUT, &cap,
@@ -727,3 +761,4 @@ int tpm1_pm_suspend(struct tpm_chip *chip, int 
tpm_suspend_pcr)
 
return rc;
 }
+
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index 49df54b0e210..a3d39360620f 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -948,6 +948,36 @@ static int tpm2_get_cc_attrs_tbl(struct tp

[PATCH v5 20/21] tpm1: reimplement tpm1_continue_selftest() using tpm_buf

2018-09-28 Thread Tomas Winkler
Reimplement tpm1_continue_selftest() using tpm_buf structure.
This is the last command using the old tpm_cmd_t structure
and now the structure can be removed.

Cc: Nayna Jain 
Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
---

V3: New in the series.
V4: Resend.
V5: Fix &buf.data -> buf.data in tpm1_continue_selftest()

 drivers/char/tpm/tpm.h  |  9 -
 drivers/char/tpm/tpm1-cmd.c | 21 ++---
 2 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 2f06740f993d..7ada00f067f1 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -377,15 +377,6 @@ enum tpm_sub_capabilities {
TPM_CAP_PROP_TIS_DURATION = 0x120,
 };
 
-typedef union {
-   struct  tpm_input_header in;
-   struct  tpm_output_header out;
-} tpm_cmd_header;
-
-struct tpm_cmd_t {
-   tpm_cmd_header  header;
-} __packed;
-
 
 /* 128 bytes is an arbitrary cap. This could be as large as TPM_BUFSIZE - 18
  * bytes, but 128 is still a relatively large number of random bytes and
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index d418a27a75e0..6b04648f8184 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -602,15 +602,8 @@ int tpm1_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 
*res_buf)
 }
 
 #define TPM_ORD_CONTINUE_SELFTEST 83
-#define CONTINUE_SELFTEST_RESULT_SIZE 10
-static const struct tpm_input_header continue_selftest_header = {
-   .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
-   .length = cpu_to_be32(10),
-   .ordinal = cpu_to_be32(TPM_ORD_CONTINUE_SELFTEST),
-};
-
 /**
- * tpm_continue_selftest -- run TPM's selftest
+ * tpm_continue_selftest() - run TPM's selftest
  * @chip: TPM chip to use
  *
  * Returns 0 on success, < 0 in case of fatal error or a value > 0 representing
@@ -618,12 +611,18 @@ static const struct tpm_input_header 
continue_selftest_header = {
  */
 static int tpm1_continue_selftest(struct tpm_chip *chip)
 {
+   struct tpm_buf buf;
int rc;
-   struct tpm_cmd_t cmd;
 
-   cmd.header.in = continue_selftest_header;
-   rc = tpm_transmit_cmd(chip, NULL, &cmd, CONTINUE_SELFTEST_RESULT_SIZE,
+   rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_CONTINUE_SELFTEST);
+   if (rc)
+   return rc;
+
+   rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE,
  0, 0, "continue selftest");
+
+   tpm_buf_destroy(&buf);
+
return rc;
 }
 
-- 
2.14.4



[PATCH v5 17/21] tpm1: implement tpm1_pcr_read_dev() using tpm_buf structure

2018-09-28 Thread Tomas Winkler
Implement tpm1_pcr_read_dev() using tpm_buf and remove
now unneeded structures from tpm.h

Signed-off-by: Tomas Winkler 
Reviewed-by: Jarkko Sakkinen 
Tested-by: Jarkko Sakkinen 
---

V3: New in the series.
V4-V5: Resend.
 drivers/char/tpm/tpm.h  | 18 ++
 drivers/char/tpm/tpm1-cmd.c | 38 +-
 2 files changed, 23 insertions(+), 33 deletions(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index d6eca81a011a..d0402aa122ec 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -382,13 +382,10 @@ typedef union {
struct  tpm_output_header out;
 } tpm_cmd_header;
 
-struct tpm_pcrread_out {
-   u8  pcr_result[TPM_DIGEST_SIZE];
+struct tpm_cmd_t {
+   tpm_cmd_header  header;
 } __packed;
 
-struct tpm_pcrread_in {
-   __be32  pcr_idx;
-} __packed;
 
 /* 128 bytes is an arbitrary cap. This could be as large as TPM_BUFSIZE - 18
  * bytes, but 128 is still a relatively large number of random bytes and
@@ -396,17 +393,6 @@ struct tpm_pcrread_in {
  * compiler warnings about stack frame size. */
 #define TPM_MAX_RNG_DATA   128
 
-typedef union {
-   struct  tpm_pcrread_in  pcrread_in;
-   struct  tpm_pcrread_out pcrread_out;
-} tpm_cmd_params;
-
-struct tpm_cmd_t {
-   tpm_cmd_header  header;
-   tpm_cmd_params  params;
-} __packed;
-
-
 /* A string buffer type for constructing TPM commands. This is based on the
  * ideas of string buffer code in security/keys/trusted.h but is heap based
  * in order to keep the stack usage minimal.
diff --git a/drivers/char/tpm/tpm1-cmd.c b/drivers/char/tpm/tpm1-cmd.c
index b5c4fa158c30..d30f336518f6 100644
--- a/drivers/char/tpm/tpm1-cmd.c
+++ b/drivers/char/tpm/tpm1-cmd.c
@@ -571,29 +571,33 @@ int tpm1_get_random(struct tpm_chip *chip, u8 *dest, 
size_t max)
return rc;
 }
 
-#define TPM_ORDINAL_PCRREAD 21
-#define READ_PCR_RESULT_SIZE 30
-#define READ_PCR_RESULT_BODY_SIZE 20
-static const struct tpm_input_header pcrread_header = {
-   .tag = cpu_to_be16(TPM_TAG_RQU_COMMAND),
-   .length = cpu_to_be32(14),
-   .ordinal = cpu_to_be32(TPM_ORDINAL_PCRREAD)
-};
-
+#define TPM_ORD_PCRREAD 21
 int tpm1_pcr_read_dev(struct tpm_chip *chip, int pcr_idx, u8 *res_buf)
 {
+   struct tpm_buf buf;
int rc;
-   struct tpm_cmd_t cmd;
 
-   cmd.header.in = pcrread_header;
-   cmd.params.pcrread_in.pcr_idx = cpu_to_be32(pcr_idx);
-   rc = tpm_transmit_cmd(chip, NULL, &cmd, READ_PCR_RESULT_SIZE,
- READ_PCR_RESULT_BODY_SIZE, 0,
+   rc = tpm_buf_init(&buf, TPM_TAG_RQU_COMMAND, TPM_ORD_PCRREAD);
+   if (rc)
+   return rc;
+
+   tpm_buf_append_u32(&buf, pcr_idx);
+
+   rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE,
+ TPM_DIGEST_SIZE, 0,
  "attempting to read a pcr value");
+   if (rc)
+   goto out;
 
-   if (rc == 0)
-   memcpy(res_buf, cmd.params.pcrread_out.pcr_result,
-  TPM_DIGEST_SIZE);
+   if (tpm_buf_length(&buf) < TPM_DIGEST_SIZE) {
+   rc = -EFAULT;
+   goto out;
+   }
+
+   memcpy(res_buf, &buf.data[TPM_HEADER_SIZE], TPM_DIGEST_SIZE);
+
+out:
+   tpm_buf_destroy(&buf);
return rc;
 }
 
-- 
2.14.4



  1   2   3   4   5   6   >