Re: [PATCH 4.4 131/160] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings

[Michal Hocko]

On Tue 20-11-18 15:53:10, David Rientjes wrote:
> On Tue, 20 Nov 2018, Michal Hocko wrote:
> 
> > On Mon 19-11-18 14:16:24, David Rientjes wrote:
> > > On Mon, 19 Nov 2018, Greg Kroah-Hartman wrote:
> > > 
> > > > 4.4-stable review patch.  If anyone has any objections, please let me 
> > > > know.
> > > > 
> > > 
> > > As I noted when this patch was originally proposed and when I nacked 
> > > it[*] 
> > > because it causes a 13.9% increase in remote memory access latency and up 
> > > to 40% increase in remote memory allocation latency on much of our 
> > > software stack that uses MADV_HUGEPAGE after mremapping the text segment 
> > > to memory backed by hugepages, I don't think this is stable material.
> > 
> > There was a wider consensus that this is the most minimal fix for users
> > who see a regression introduced by 5265047ac301 ("mm, thp: really
> > limit transparent hugepage allocation to local node"). As it has been
> > discussed extensively there is no universal win but we should always opt
> > for the safer side which this patch is accomplishing. The changelog goes
> > in length explaining them along with numbers. I am not happy that your
> > particular workload is suffering but this area certainly requires much
> > more changes to satisfy wider range of users.
> > 
> > > The 4.4 kernel is almost three years old and this changes the NUMA 
> > > locality of any user of MADV_HUGEPAGE.
> > 
> > Yes and we have seen bug reports as we adopted this older kernel only
> > now.
> 
> I think the responsible thing to do would be allow users to remain on 
> their stable kernel that they know works, whether that's 4.4 or any of the 
> others this is proposed for, and downgrade from any current kernel release 
> that causes their workloads to have such severe regressions once they try 
> a kernel with this commit.

But we do know that there are people affected on 4.4 kernel. Besides
that we can revert in the stable tree as soon as we see bug reports on
new stable tree releases.

Really, there is no single proper behavior. It was a mistake to merge
5265047ac301. Since then we are in an unfortunate situation that some
workload might have started to depend on the new behavior.

But rather than repeating the previous long discussion I would call for
a new one which actually deals with fallouts. AFAIR there is a patch
series to reduce the fragmentation issues by Mel with a zero feedback so
far. I also think we should start discussing a new memory policy to
establish the semantic you are after.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH v1 02/11] clk: mediatek: add new member to mtk_pll_data

[Stephen Boyd]

Quoting Weiyi Lu (2018-11-19 19:51:20)
> On Tue, 2018-11-13 at 08:18 -0800, Nicolas Boichat wrote:
> > On Mon, Nov 5, 2018 at 10:43 PM Weiyi Lu  wrote:
> > > @@ -138,9 +140,10 @@ static void mtk_pll_set_rate_regs(struct mtk_clk_pll 
> > > *pll, u32 pcw,
> > >  static void mtk_pll_calc_values(struct mtk_clk_pll *pll, u32 *pcw, u32 
> > > *postdiv,
> > > u32 freq, u32 fin)
> > >  {
> > > -   unsigned long fmin = 1000 * MHZ;
> > > +   unsigned long fmin = pll->data->fmin ? pll->data->fmin : 1000 * 
> > > MHZ;
> > 
> > I'd put parentheses around (1000 * MHZ), to avoid the need to think
> > about precedence...
> > 
> 
> OK, thanks for the suggestion. will add in next version

Better style would be to not use a ternary statement for anything like
this and have an if condition instead.

Re: [tip:locking/core] locking/atomics: Check generated headers are up-to-date

[Ingo Molnar]

* tip-bot for Mark Rutland  wrote:

> Commit-ID:  8d32588077bdc390420cfa6946f407033a20d7a8
> Gitweb: 
> https://git.kernel.org/tip/8d32588077bdc390420cfa6946f407033a20d7a8
> Author: Mark Rutland 
> AuthorDate: Tue, 4 Sep 2018 11:48:29 +0100
> Committer:  Ingo Molnar 
> CommitDate: Thu, 1 Nov 2018 11:01:10 +0100
> 
> locking/atomics: Check generated headers are up-to-date
> 
> Now that all the generated atomic headers are in place, it would be good
> to ensure that:
> 
> a) the headers are up-to-date when scripting changes.
> 
> b) developers don't directly modify the generated headers.
> 
> To ensure both of these properties, let's add a Kbuild step to check
> that the generated headers are up-to-date.
> 
> Signed-off-by: Mark Rutland 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: catalin.mari...@arm.com
> Cc: Will Deacon 
> Cc: linuxdriv...@attotech.com
> Cc: dvyu...@google.com
> Cc: Boqun Feng 
> Cc: a...@arndb.de
> Cc: aryabi...@virtuozzo.com
> Cc: gli...@google.com
> Link: http://lkml.kernel.org/r/20180904104830.2975-6-mark.rutl...@arm.com
> Signed-off-by: Ingo Molnar 
> ---
>  Kbuild  | 18 --
>  scripts/atomic/check-atomics.sh | 19 +++
>  2 files changed, 35 insertions(+), 2 deletions(-)

These scripts are *awfully* slow to be run at every kernel build - even a 
reasonably fast machine:

  model name: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz

... they are adding 3-4 seconds to the build time:

[Before]:

  galatea:~/linux/linux> perf stat --null --repeat 3 make kernel/sched/core.o
  CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CALLscripts/checksyscalls.sh
  DESCEND  objtool
  CALLscripts/checksyscalls.sh
  DESCEND  objtool

 Performance counter stats for 'make kernel/sched/core.o' (3 runs):

  1.201874 +- 0.000371 seconds time elapsed  ( +-  0.03% )


[After]:

  galatea:~/linux/linux> perf stat --null --repeat 3 make kernel/sched/core.o

  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool

 Performance counter stats for 'make kernel/sched/core.o' (3 runs):

4.5987 +- 0.0109 seconds time elapsed  ( +-  0.24% )

Could we please get this fixed so that proper dependencies are checked 
and it's only regenerated when needed? This slowdown makes additive-build 
kernel development quite painful, as ~5 seconds is in the 'too long' 
category already, while 1.2 seconds is basically instantaneous.

I cannot even imagine the slowdown on a truly slow box where kernel 
development *has* to be additive.

Thanks,

Ingo

Re: [PATCH 4.19 000/205] 4.19.3-stable review

[Greg Kroah-Hartman]

On Tue, Nov 20, 2018 at 12:40:48PM -0800, Guenter Roeck wrote:
> On Mon, Nov 19, 2018 at 05:25:07PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.3 release.
> > There are 205 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Nov 21 16:24:55 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 135 pass: 135 fail: 0
> Qemu test results:
>   total: 291 pass: 291 fail: 0
> 
> Details are available at https://kerneltests.org/builders/.

Thanks for testing all of these and letting me know.

I'll look into the 3.18.y regressions before doing a release there...

greg k-h

Re: [PATCH v1 04/11] soc: mediatek: add new flow for mtcmos power.

[Stephen Boyd]

Quoting Weiyi Lu (2018-11-19 18:37:34)
> On Tue, 2018-11-13 at 11:31 -0800, Nicolas Boichat wrote:
> > On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu  wrote:

> > > @@ -226,6 +397,7 @@ static int scpsys_power_on(struct generic_pm_domain 
> > > *genpd)
> > > if (ret < 0)
> > > goto err_pwr_ack;
> > >
> > > +
> > 
> > Drop this.
> Why do we try to drop this? Once the power-on step fail, the following
> steps should not be permitted.

I just see a whitespace addition that doesn't do anything. I suspect
it's a style nitpick and common practice to not include spurious diffs
in the patch. So remove this hunk?

Re: Resend: How to handle the SMMU RAS Error in the kernel

[gengdongjiu]

Hi James,
   Thanks for the mail.

On 2018/11/20 2:05, James Morse wrote:
> Hi gengdongjiu,
> 
> On 17/11/2018 15:41, gengdongjiu wrote:
>> In the current kernel, it only handles three kinds of error, which is
>> memory error, PCIE device and ARM process. But now the SMMU already
>> support the RAS, how to handle the SMMU RAS error in the kernel?
> 
> What errors are being detected here?
> 
> I don't know much about the SMMU, but I think we should start with a list of
> errors that we want to handle.

In our platform, the SMMU RAS error mainly include below which flow the SMMU 
spec:
1. one bit ECC error, reported as CE.
2. two bits ECC error, reported as UEU.
3. fetch error in the SMMUv3 spec, reported as UER.

The 2 and 3 should be handled, but I do not know how do recovery to it.

> 
> 
> Is this a v8.2 fault handling interrupt from the SMMU taken to EL3?
> Or a cpu-access that was returned as external-abort? or a device access that 
> was
> told external-abort?
it flows v8.2 RAS spec, it is a v8.2 fault handling interrupt from the SMMU 
taken to EL3.

> 
> What do we intend to do with this error information? Does the DMA layer have
> error handling we can hook this into?

we can get the DMA layer error from the RAS registers, such as DMA read errors.
may be the handle method is disabling this SMMU to avoid propagation.

> 
> Is this just another interface for memory-errors? (e.g the SMMU provides a
> device/address pair and the kernel works out the physical page to run
> memory_failure() on)
I need to check more.

> 
> 
>> I check the UEFI_SPEC_2.7, the ACPI's CPER have the IOMMU type, but it
>> seems the IOMMU type only are specific to AMD’s IOMMU specification,
> 
> ... and Intel VT-d. It looks like UEFI generalises all these as types of 
> 'DMAr'.
yes, it is.

> 
> 
>> not have the ARM’s IOMMU section type, can we reuse this IOMMU section
>> type for the ARM SMMU?
> 
> The architecture specific records for AMD? No. Even if the information was the
> same, the presence of this record tells you its an AMD IOMMU, which its not.
> 
> The generic error section? Maybe.
> 
> Assuming the 'fault reason' list in Table 285 is sufficient to cover our list 
> or
> errors, we can use the 'DMAr Generic Errors' section, (N.2.11.1), to describe
> the generic bits of the error ... but SMMU doesn't have an 'Architecture 
> Type',
> so we at least need to get one allocated.
> 
> We will probably need an architecture specific 'DMAr Error Section'.
> 
> 
> I think adding the UEFI bits is probably the 'easy' bit. We should start with 
> a
> list of errors, and the error handling code. This way we know what we need to
> add to the spec.

The list of SMMU RAS error is shown below, but I still do not know how to 
handle it.
1. one bit ECC error
2. two bits ECC error
3. fetch error in the SMMUv3 spec

> 
> 
> 
> Thanks,
> 
> James
> 
> .
> 

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

[Geert Uytterhoeven]

Hi Finn,

On Wed, Nov 21, 2018 at 12:13 AM Finn Thain  wrote:
> On atari, the 68901 counts down to 0x01 and raises an interrupt. On mac,
> the 6522 counts down to 0x then raises an interrupt. No idea about
> amiga (Geert?) -- this has to be handled correctly to get a monotonic
> clocksource. I'll fix this in v3 (where the information is available).

The docs state that the CIA generates on interrupt on underflow, so I
guess that's the same behavior as the 6522 VIA.

Unfortunately the 24-bit ("TOD") counters in the two CIAs run from HSYNC
resp. VSYNC, which depends on the video mode, and thus can't be used
as a monotonic clock source.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[RFC PATCH] of: make MAX_RESERVED_REGIONS configurable

[miles.chen]

From: Miles Chen 

When we use more than 32 entries in /resered-memory,
there will be an error message: "not enough space all defined regions.".
We can increase MAX_RESERVED_REGIONS to fix this.

commit 22f8cc6e3373 ("drivers: of: increase MAX_RESERVED_REGIONS to 32")
increased MAX_RESERVED_REGIONS to 32 but I'm not sure if increasing
MAX_RESERVED_REGIONS to 64 is suitable for everyone.

In this RFC patch, CONFIG_MAX_OF_RESERVED_REGIONS is added and used as
MAX_RESERVED_REGIONS. Add a sanity test to make sure that
MAX_RESERVED_REGIONS is less than INIT_MEMBLOCK_REGIONS.
Users can configure CONFIG_MAX_OF_RESERVED_REGIONS according to their
need.

Signed-off-by: Miles Chen 
---
 drivers/of/Kconfig   | 9 +
 drivers/of/of_reserved_mem.c | 5 -
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index ad3fcad..63fff2e 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -86,6 +86,15 @@ config OF_RESERVED_MEM
help
  Helpers to allow for reservation of memory regions
 
+config MAX_OF_RESERVED_REGIONS
+   int "the max number of devicetree reserved memory regions"
+   depends on OF_RESERVED_MEM
+   default 32
+   help
+ Setup the max number of devicetree reserved memory regions
+ If unsure, leave the default value "32".
+
+
 config OF_RESOLVE
bool
 
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0..18a7729 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 
-#define MAX_RESERVED_REGIONS   32
+#define MAX_RESERVED_REGIONS   CONFIG_MAX_OF_RESERVED_REGIONS
 static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
 static int reserved_mem_count;
 
@@ -246,6 +246,9 @@ void __init fdt_init_reserved_mem(void)
 {
int i;
 
+   /* MAX_RESERVED_REGIONS should be bounded by INIT_MEMBLOCK_REGIONS */
+   BUILD_BUG_ON(MAX_RESERVED_REGIONS > INIT_MEMBLOCK_REGIONS);
+
/* check for overlapping reserved regions */
__rmem_check_for_overlap();
 
-- 
1.9.1

[PATCH 0/1] mm/gup: finish consolidating error handling

[john . hubbard]

From: John Hubbard 

Hi,

Keith Busch and Dan Williams noticed that this patch
(which was part of my RFC[1] for the get_user_pages + DMA
fix) also fixes a bug. Accordingly, I'm adjusting
the changelog and posting this as it's own patch.

[1] https://lkml.kernel.org/r/20181110085041.10071-1-jhubb...@nvidia.com

John Hubbard (1):
  mm/gup: finish consolidating error handling

 mm/gup.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.19.1

[PATCH] mm/gup: finish consolidating error handling

[john . hubbard]

From: John Hubbard 

Commit df06b37ffe5a4 ("mm/gup: cache dev_pagemap while pinning pages")
attempted to operate on each page that get_user_pages had retrieved. In
order to do that, it created a common exit point from the routine.
However, one case was missed, which this patch fixes up.

Also, there was still an unnecessary shadow declaration (with a
different type) of the "ret" variable, which this patch removes.

Fixes: df06b37ffe5a4 ("mm/gup: cache dev_pagemap while pinning pages")

Reviewed-by: Keith Busch 
Cc: Dan Williams 
Cc: Kirill A. Shutemov 
Cc: Dave Hansen 
Signed-off-by: John Hubbard 
---
 mm/gup.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index aa43620a3270..8cb68a50dbdf 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -702,12 +702,11 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
if (!vma || start >= vma->vm_end) {
vma = find_extend_vma(mm, start);
if (!vma && in_gate_area(mm, start)) {
-   int ret;
ret = get_gate_page(mm, start & PAGE_MASK,
gup_flags, &vma,
pages ? &pages[i] : NULL);
if (ret)
-   return i ? : ret;
+   goto out;
ctx.page_mask = 0;
goto next_page;
}
-- 
2.19.1

Re: [REGRESSION] x86, perf: counter freezing breaks rr

[Peter Zijlstra]

On Tue, Nov 20, 2018 at 02:38:54PM -0800, Andi Kleen wrote:
> > In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> > independent counters, because while one counter overflows, we'll stall
> > counting on all others until we've handled the PMI.
> > 
> > Even though the PMI might not be for them and they very much want/need
> > to continue counting.
> 
> We stop all counters in any case for the PMI. With freeze-on-PMI it just
> happens slightly earlier.

Hiding the PMI is fine and good. The PMI is not the workload. Stopping
it earlier is _NOT_ good, it hides your actual workload.

Re: [PATCH 20/25] sched/kcpustat: Introduce vtime-aware kcpustat accessor

[Peter Zijlstra]

On Tue, Nov 20, 2018 at 11:40:22PM +0100, Frederic Weisbecker wrote:
> On Tue, Nov 20, 2018 at 03:23:06PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 14, 2018 at 03:46:04AM +0100, Frederic Weisbecker wrote:
> > 
> > > +void kcpustat_cputime(struct kernel_cpustat *kcpustat, int cpu,
> > > +   u64 *user, u64 *nice, u64 *system,
> > > +   u64 *guest, u64 *guest_nice)
> > > +{
> > > + struct task_struct *curr;
> > > + struct vtime *vtime;
> > > + int err;
> > > +
> > > + if (!vtime_accounting_enabled()) {
> > > + kcpustat_cputime_raw(kcpustat, user, nice,
> > > +  system, guest, guest_nice);
> > > + return;
> > > + }
> > > +
> > > + rcu_read_lock();
> > > +
> > > + do {
> > > + curr = rcu_dereference(kcpustat->curr);
> > 
> > Like I explained earlier; I don't think the above is correct.
> > task_struct is itself not RCU protected.
> 
> But there is at least one put_task_struct() that is enqueued as an RCU 
> callback
> on release_task(). That patchset (try to) make sure that kcpustat->curr can't
> be assigned beyond that point.
> 
> Or did I misunderstand something?

Yeah; release_task() is not the normal exit path. Oleg can probably
remember how all that works, because I always get lost there :-/

In any case, have a look at task_rcu_dereference(), but that still does
not explain the rcu_assign_pointer() stuff you use to set
kcpustat->curr.

Re: [LKP] [crypto] 7da6667077: kmsg.tcrypt:failed_to_load_transform_for_cfb(aes)

[Herbert Xu]

On Wed, Nov 21, 2018 at 09:01:26AM +0800, kernel test robot wrote:
>
> #
> # Block modes
> #
> CONFIG_CRYPTO_CBC=y
> # CONFIG_CRYPTO_CFB is not set

Enabling CFB should make your error go away.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v3 2/2] proc: add /proc//arch_state

[Peter Zijlstra]

On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
> > Also; you were going to shop around with the other architectures to see
> > what they want/need for this interface. I see nothing on that.
> > 
> I'm open for your suggestion, :)

Well, we have linux-arch and the various maintainers are also listed in
MAINTAINERS. Go forth and ask..

Re: [PATCH v2 5/5] Staging: iio: adt7316: Use device tree data to assign irq_type

[Ardelean, Alexandru]

On Tue, 2018-11-20 at 22:30 +0530, Shreeya Patel wrote:
> ADT7316 driver no more uses platform data and hence use device tree
> data instead of platform data for assigning irq_type field.
> Switch case figures out the type of irq and if it's the default case
> then assign the default value to the irq_type i.e.
> irq_type = IRQF_TRIGGER_LOW
> 

1 comment inline

> Signed-off-by: Shreeya Patel 
> ---
>  drivers/staging/iio/addac/adt7316.c | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/iio/addac/adt7316.c
> b/drivers/staging/iio/addac/adt7316.c
> index 9c72538baf9e..c647875a64f5 100644
> --- a/drivers/staging/iio/addac/adt7316.c
> +++ b/drivers/staging/iio/addac/adt7316.c
> @@ -2101,8 +2101,7 @@ int adt7316_probe(struct device *dev, struct
> adt7316_bus *bus,
>  {
>   struct adt7316_chip_info *chip;
>   struct iio_dev *indio_dev;
> - unsigned short *adt7316_platform_data = dev->platform_data;
> - int irq_type = IRQF_TRIGGER_LOW;
> + int irq_type;
>   int ret = 0;
>  
>   indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
> @@ -2146,8 +2145,22 @@ int adt7316_probe(struct device *dev, struct
> adt7316_bus *bus,
>   indio_dev->modes = INDIO_DIRECT_MODE;
>  
>   if (chip->bus.irq > 0) {
> - if (adt7316_platform_data[0])
> - irq_type = adt7316_platform_data[0];
> + irq_type =
> + irqd_get_trigger_type(irq_get_irq_data(chip-
> >bus.irq));
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_HIGH:
> + case IRQF_TRIGGER_RISING:
> + break;
> + case IRQF_TRIGGER_LOW:
> + case IRQF_TRIGGER_FALLING:
> + break;
> + default:
> + dev_info(dev, "mode %d unsupported, using
> IRQF_TRIGGER_LOW\n",
> +  irq_type);
> + irq_type = IRQF_TRIGGER_LOW;
> + break;
> + }

It would be an idea to move this part [together with
devm_request_threaded_irq()] into a "adt7316_setup_irq()" function. To un-
clutter the code in the adt7316_probe() function.

>  
>   ret = devm_request_threaded_irq(dev, chip->bus.irq,
>   NULL,

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

[Kars de Jong]

Op wo 21 nov. 2018 om 00:13 schreef Finn Thain :
>
> On Tue, 20 Nov 2018, Kars de Jong wrote:
>
> > Op ma 19 nov. 2018 om 02:10 schreef Finn Thain :
> > >
> > > hp300_gettimeoffset() never checks the timer interrupt flag and will
> > > fail to notice when the timer counter gets reloaded. That means the
> > > clock could jump backwards.
> > >
> > > Remove this code and leave this platform on the 'jiffies' clocksource.
> > > Note that this amounts to a regression in clock precision. However,
> > > adopting the 'jiffies' clocksource does resolve the monotonicity issue.
> > >
> > > Signed-off-by: Finn Thain 
> > > ---
> > > hp300_gettimeoffset() cannot be used in a clocksource conversion
> > > unless it can be made monotonic. I can't fix this without knowing the
> > > details of the timer implementation, such as the relationship between
> > > the timer count and the interrupt flag.
> >
> > I don't really like this regression...
> >
>
> Me neither...
>
> I'll see if I can write a conversion patch based on the information you've
> provided. Can you test it?

I can try... It's been a while since I booted the machine to Linux
though (NFS support only).
MAME is also starting to support it, but not quite there yet :-)

> > According to NetBSD sources, there are 3 timers in the chip (originally
> > an MC6840 PTM).
>
> Thanks for the tip. I will examine the datasheet for the 6840.
>
> I'll also take another look at the NetBSD code.
>
> > Timer 1 is used as the system timer, timer 3 runs at the same rate and
> > is unused on Linux (on NetBSD it is used as the statistics/profiling
> > timer), and timer 3 is connected to timer 2 so you can make a 32-bit
> > timer out of the two timers together (also unused on Linux).
> >
> > Timers 1 counts down at 25 MHz.
>
> You mean, 250 kHz, right? The code in mainline programs the timer for 2500
> cycles, hoping to get 10 ms. That is, 250 cycles per ms.

Eh, yes, that makes a lot more sense.

> > The interrupt flag is set when the counter reaches 0 after which it is
> > automatically reloaded and starts counting down again.
> >
>
> Thanks.
>
> On atari, the 68901 counts down to 0x01 and raises an interrupt. On mac,
> the 6522 counts down to 0x then raises an interrupt. No idea about
> amiga (Geert?) -- this has to be handled correctly to get a monotonic
> clocksource. I'll fix this in v3 (where the information is available).

Cool!

Kars.

Re: [PATCH V5 1/2] thermal: imx: fix for dependency on cpu-freq

[Daniel Lezcano]

On 21/11/2018 06:49, Anson Huang wrote:
> The thermal driver is a standalone driver for monitoring SoC temperature
> by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
> is NOT set. So remove the dependency with CPU_THERMAL.
> 
> Introduce dummy function of legacy cooling register/unregister to make
> thermal driver probe successfully when CONFIG_CPU_FREQ is NOT set.
> 
> Signed-off-by: Anson Huang 

Reviewed-by: Daniel Lezcano 



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH V5 2/2] thermal: imx: save one condition block for normal case of nvmem initialization

[Daniel Lezcano]

On 21/11/2018 06:49, Anson Huang wrote:
> Put return value checks of calling imx_init_from_nvmem_cells()
> into one block to save one condition block for normal case.
> 
> Signed-off-by: Anson Huang 

Reviewed-by: Daniel Lezcano 

> ---
>  drivers/thermal/imx_thermal.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index c924396..bb6754a 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c
> @@ -742,9 +742,10 @@ static int imx_thermal_probe(struct platform_device 
> *pdev)
>  
>   if (of_find_property(pdev->dev.of_node, "nvmem-cells", NULL)) {
>   ret = imx_init_from_nvmem_cells(pdev);
> - if (ret == -EPROBE_DEFER)
> - return ret;
>   if (ret) {
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
>   dev_err(&pdev->dev, "failed to init from nvmem: %d\n",
>   ret);
>   return ret;
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 20/25] sched/kcpustat: Introduce vtime-aware kcpustat accessor

[Peter Zijlstra]

On Wed, Nov 21, 2018 at 09:18:19AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 20, 2018 at 11:40:22PM +0100, Frederic Weisbecker wrote:
> > On Tue, Nov 20, 2018 at 03:23:06PM +0100, Peter Zijlstra wrote:
> > > On Wed, Nov 14, 2018 at 03:46:04AM +0100, Frederic Weisbecker wrote:
> > > 
> > > > +void kcpustat_cputime(struct kernel_cpustat *kcpustat, int cpu,
> > > > + u64 *user, u64 *nice, u64 *system,
> > > > + u64 *guest, u64 *guest_nice)
> > > > +{
> > > > +   struct task_struct *curr;
> > > > +   struct vtime *vtime;
> > > > +   int err;
> > > > +
> > > > +   if (!vtime_accounting_enabled()) {
> > > > +   kcpustat_cputime_raw(kcpustat, user, nice,
> > > > +system, guest, guest_nice);
> > > > +   return;
> > > > +   }
> > > > +
> > > > +   rcu_read_lock();
> > > > +
> > > > +   do {
> > > > +   curr = rcu_dereference(kcpustat->curr);
> > > 
> > > Like I explained earlier; I don't think the above is correct.
> > > task_struct is itself not RCU protected.
> > 
> > But there is at least one put_task_struct() that is enqueued as an RCU 
> > callback
> > on release_task(). That patchset (try to) make sure that kcpustat->curr 
> > can't
> > be assigned beyond that point.
> > 
> > Or did I misunderstand something?
> 
> Yeah; release_task() is not the normal exit path. Oleg can probably
> remember how all that works, because I always get lost there :-/
> 
> In any case, have a look at task_rcu_dereference(), but that still does
> not explain the rcu_assign_pointer() stuff you use to set
> kcpustat->curr.

Also, why do you need kcpustat->curr at all, the above function has
@cpu, so you can equally use cpu_curr(cpu), no?

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

[Finn Thain]

On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Wed, Nov 21, 2018 at 12:13 AM Finn Thain  
> wrote:
> > On atari, the 68901 counts down to 0x01 and raises an interrupt. On 
> > mac, the 6522 counts down to 0x then raises an interrupt. No idea 
> > about amiga (Geert?) -- this has to be handled correctly to get a 
> > monotonic clocksource. I'll fix this in v3 (where the information is 
> > available).
> 
> The docs state that the CIA generates on interrupt on underflow, so I 
> guess that's the same behavior as the 6522 VIA.
> 

Difficult to say. The sequence varies from one implementation to another. 
Let's ignore the MSB and LSB and pretend it's one register:

MC68901: N, N-1, N-2, ..., 2, 1, N, N-1, N-2, ...
MC6840:  N, N-1, N-2, ..., 2, 1, 0, N, N-1, N-2, ...
SY6522:  N, N-1, N-2, ..., 2, 1, 0, 0x, N, N-1, N-2, ...

Now the question is, when the timer asserts its interrupt, and the count 
register is fetched immediately, what value does it have?

For the MC68901, you get 1. For the SY6522, you get 0x. For MC6840, as 
far as I can tell, you'd get 0.

I'll add some code to my github repo to find out what happens with CIA.

> Unfortunately the 24-bit ("TOD") counters in the two CIAs run from HSYNC 
> resp. VSYNC, which depends on the video mode, and thus can't be used as 
> a monotonic clock source.
> 

Is that because of video mode changes? Could the clocksource be 
unregistered before the mode change and then re-registered at a different 
frequency afterwards?

-- 

> Gr{oetje,eeting}s,
> 
> Geert
> 
> 

Re: [PATCH v2 08/15] irqchip: Add RDA8810PL interrupt driver

[Marc Zyngier]

On 21/11/2018 03:36, Manivannan Sadhasivam wrote:
> Add interrupt driver for RDA Micro RDA8810PL SoC.
> 
> Signed-off-by: Andreas Färber 
> Signed-off-by: Manivannan Sadhasivam 
> ---
>  arch/arm/mach-rda/Kconfig  |   1 +
>  drivers/irqchip/Kconfig|   4 ++
>  drivers/irqchip/Makefile   |   1 +
>  drivers/irqchip/irq-rda-intc.c | 113 +
>  4 files changed, 119 insertions(+)
>  create mode 100644 drivers/irqchip/irq-rda-intc.c
> 
> diff --git a/arch/arm/mach-rda/Kconfig b/arch/arm/mach-rda/Kconfig
> index dafab78d7aab..29012bc68ca4 100644
> --- a/arch/arm/mach-rda/Kconfig
> +++ b/arch/arm/mach-rda/Kconfig
> @@ -3,5 +3,6 @@ menuconfig ARCH_RDA
>   depends on ARCH_MULTI_V7
>   select COMMON_CLK
>   select GENERIC_IRQ_CHIP
> + select RDA_INTC
>   help
> This enables support for the RDA Micro 8810PL SoC family.
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 51a5ef0e96ed..9d54645870ad 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -195,6 +195,10 @@ config JCORE_AIC
>   help
> Support for the J-Core integrated AIC.
>  
> +config RDA_INTC
> + bool
> + select IRQ_DOMAIN
> +
>  config RENESAS_INTC_IRQPIN
>   bool
>   select IRQ_DOMAIN
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index 794c13d3ac3d..417108027e40 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -43,6 +43,7 @@ obj-$(CONFIG_IMGPDC_IRQ)+= irq-imgpdc.o
>  obj-$(CONFIG_IRQ_MIPS_CPU)   += irq-mips-cpu.o
>  obj-$(CONFIG_SIRF_IRQ)   += irq-sirfsoc.o
>  obj-$(CONFIG_JCORE_AIC)  += irq-jcore-aic.o
> +obj-$(CONFIG_RDA_INTC)   += irq-rda-intc.o
>  obj-$(CONFIG_RENESAS_INTC_IRQPIN)+= irq-renesas-intc-irqpin.o
>  obj-$(CONFIG_RENESAS_IRQC)   += irq-renesas-irqc.o
>  obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
> diff --git a/drivers/irqchip/irq-rda-intc.c b/drivers/irqchip/irq-rda-intc.c
> new file mode 100644
> index ..1b372bdb23bc
> --- /dev/null
> +++ b/drivers/irqchip/irq-rda-intc.c
> @@ -0,0 +1,113 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * RDA8810PL SoC irqchip driver
> + *
> + * Copyright RDA Microelectronics Company Limited
> + * Copyright (c) 2017 Andreas Färber
> + * Copyright (c) 2018 Manivannan Sadhasivam
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 

You shouldn't need to include this.

> +#include 
> +
> +#define RDA_INTC_FINALSTATUS 0x00
> +#define RDA_INTC_STATUS  0x04
> +#define RDA_INTC_MASK_SET0x08
> +#define RDA_INTC_MASK_CLR0x0c
> +#define RDA_INTC_WAKEUP_MASK 0x18
> +#define RDA_INTC_CPU_SLEEP   0x1c

Half of these constants are unused. Do we really need them?

> +
> +#define RDA_IRQ_MASK_ALL 0x
> +
> +#define RDA_NR_IRQS 32

Surely the mask can be derived from the number of interrupts?

> +
> +static void __iomem *base;

Everything in this driver is prefixed with rda_. It would seem valuable
to  do the same here, as "base" is a bit too generic.

> +
> +static void rda_intc_mask_irq(struct irq_data *d)
> +{
> + writel_relaxed(BIT(d->hwirq), base + RDA_INTC_MASK_CLR);
> +}
> +
> +static void rda_intc_unmask_irq(struct irq_data *d)
> +{
> + writel_relaxed(BIT(d->hwirq), base + RDA_INTC_MASK_SET);

Are the names MASK_CLR and MASK_SET from the datasheet? They seem to be
backward (you set the mask to unmask...), and seem to behave like an
enable instead. That's not a big issue, just curious.

> +}
> +
> +static int rda_intc_set_type(struct irq_data *data, unsigned int flow_type)
> +{
> + /* Hardware supports only level triggered interrupts */
> + if (flow_type & (IRQF_TRIGGER_HIGH | IRQF_TRIGGER_LOW))
> + irq_set_handler(data->irq, handle_level_irq);

Why do you need to do this? You've already configured it at map time,
and it is not changing under your feet. This should be written as:

if ((flow_type & (IRQF_TRIGGER_HIGH | IRQF_TRIGGER_LOW)) == flow_type)
return 0;

return -EINVAL;

> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static struct irq_domain *rda_irq_domain;

Please move this to the top of the file, next to "base".

> +
> +static void __exception_irq_entry rda_handle_irq(struct pt_regs *regs)
> +{
> + u32 stat = readl_relaxed(base + RDA_INTC_FINALSTATUS);
> + u32 hwirq;
> +
> + while (stat) {
> + hwirq = __fls(stat);
> + handle_domain_irq(rda_irq_domain, hwirq, regs);
> + stat &= ~(1 << hwirq);
> + }
> +}
> +
> +static struct irq_chip rda_irq_chip = {
> + .name   = "rda-intc",
> + .irq_mask   = rda_intc_mask_irq,
> + .irq_unmask = rda_intc_unmask_irq,
> + .irq_set_type   = rda_intc_set_type,
> +};
> +
> +static int rda_irq_map(struct irq_domain *d,
> + 

Re: [PATCH v3] thermal: qoriq: add multiple sensors support

[Daniel Lezcano]

On 21/11/2018 02:34, Andy Tang wrote:
> Hi all,
> 
> Do you have any comments on this patch?
> 
> I found for our thermal driver(qoriq_thermal.c) there are different between 
> the following two git trees:
> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git 
> branch: next  
> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git.
> branch: next
> 
> Could you please clarify which git tree/branch should I use?

SoC changes are submitted against linux-soc-thermal.git.

Generic thermal framework are sent against Zhang Rui's tree but it
happens sometimes Eduardo pick them also when the changes are related to
SoC behavior.

However, I agree that can be confusing :)

Eduardo, Rui,

how about to add a section in the maintainer handbook for the thermal to
clarify the expectations and the flow?

>> -Original Message-
>> From: Andy Tang
>> Sent: 2018年11月14日 15:29
>> To: rui.zh...@intel.com; daniel.lezc...@linaro.org
>> Cc: edubez...@gmail.com; linux...@vger.kernel.org;
>> linux-kernel@vger.kernel.org
>> Subject: RE: [PATCH v3] thermal: qoriq: add multiple sensors support
>>
>> PING.
>>
>> BR,
>> Andy
>>
>>> -Original Message-
>>> From: andy.t...@nxp.com 
>>> Sent: 2018年10月30日 9:00
>>> To: rui.zh...@intel.com; daniel.lezc...@linaro.org
>>> Cc: edubez...@gmail.com; linux...@vger.kernel.org;
>>> linux-kernel@vger.kernel.org; Andy Tang 
>>> Subject: [PATCH v3] thermal: qoriq: add multiple sensors support
>>>
>>> From: Yuantian Tang 
>>>
>>> The QorIQ Layerscape SoC has several thermal sensors but the current
>>> driver only supports one.
>>>
>>> Massage the code to be sensor oriented and allow the support for
>>> multiple sensors.
>>>
>>> Signed-off-by: Yuantian Tang 
>>> Reviewed-by: Daniel Lezcano 
>>> ---
>>> v3:
>>>   - add Reviewed-by
>>> v2:
>>>   - update the commit message
>>>   - refine the qoriq_tmu_register_tmu_zone()
>>>
>>>  drivers/thermal/qoriq_thermal.c |  100
>>> ++-
>>>  1 files changed, 46 insertions(+), 54 deletions(-)
>>>
>>> diff --git a/drivers/thermal/qoriq_thermal.c
>>> b/drivers/thermal/qoriq_thermal.c index 450ed66..8beb344 100644
>>> --- a/drivers/thermal/qoriq_thermal.c
>>> +++ b/drivers/thermal/qoriq_thermal.c
>>> @@ -59,14 +59,21 @@ struct qoriq_tmu_regs {
>>> u32 ttr3cr; /* Temperature Range 3 Control Register */
>>>  };
>>>
>>> +struct qoriq_tmu_data;
>>> +
>>>  /*
>>>   * Thermal zone data
>>>   */
>>> +struct qoriq_sensor {
>>> +   struct thermal_zone_device  *tzd;
>>> +   struct qoriq_tmu_data   *qdata;
>>> +   int id;
>>> +};
>>> +
>>>  struct qoriq_tmu_data {
>>> -   struct thermal_zone_device *tz;
>>> struct qoriq_tmu_regs __iomem *regs;
>>> -   int sensor_id;
>>> bool little_endian;
>>> +   struct qoriq_sensor *sensor[SITES_MAX];
>>>  };
>>>
>>>  static void tmu_write(struct qoriq_tmu_data *p, u32 val, void __iomem
>>> *addr) @@ -87,48 +94,51 @@ static u32 tmu_read(struct
>> qoriq_tmu_data
>>> *p, void __iomem *addr)
>>>
>>>  static int tmu_get_temp(void *p, int *temp)  {
>>> +   struct qoriq_sensor *qsensor = p;
>>> +   struct qoriq_tmu_data *qdata = qsensor->qdata;
>>> u32 val;
>>> -   struct qoriq_tmu_data *data = p;
>>>
>>> -   val = tmu_read(data, &data->regs->site[data->sensor_id].tritsr);
>>> +   val = tmu_read(qdata, &qdata->regs->site[qsensor->id].tritsr);
>>> *temp = (val & 0xff) * 1000;
>>>
>>> return 0;
>>>  }
>>>
>>> -static int qoriq_tmu_get_sensor_id(void)
>>> +static const struct thermal_zone_of_device_ops tmu_tz_ops = {
>>> +   .get_temp = tmu_get_temp,
>>> +};
>>> +
>>> +static int qoriq_tmu_register_tmu_zone(struct platform_device *pdev)
>>>  {
>>> -   int ret, id;
>>> -   struct of_phandle_args sensor_specs;
>>> -   struct device_node *np, *sensor_np;
>>> +   struct qoriq_tmu_data *qdata = platform_get_drvdata(pdev);
>>> +   int id, sites = 0;
>>>
>>> -   np = of_find_node_by_name(NULL, "thermal-zones");
>>> -   if (!np)
>>> -   return -ENODEV;
>>> +   for (id = 0; id < SITES_MAX; id++) {
>>> +   qdata->sensor[id] = devm_kzalloc(&pdev->dev,
>>> +   sizeof(struct qoriq_sensor), GFP_KERNEL);
>>> +   if (!qdata->sensor[id])
>>> +   return -ENOMEM;
>>>
>>> -   sensor_np = of_get_next_child(np, NULL);
>>> -   ret = of_parse_phandle_with_args(sensor_np, "thermal-sensors",
>>> -   "#thermal-sensor-cells",
>>> -   0, &sensor_specs);
>>> -   if (ret) {
>>> -   of_node_put(np);
>>> -   of_node_put(sensor_np);
>>> -   return ret;
>>> -   }
>>> +   qdata->sensor[id]->id = id;
>>> +   qdata->sensor[id]->qdata = qdata;
>>>
>>> -   if (sensor_specs.args_count >= 1) {
>>> -   id = sensor_specs.args[0];
>>> -   WARN(sensor_specs.args_count > 1,
>>> -   "%s: too many cells in sensor specifier %d\n",
>>> -   sensor_sp

Re: [PATCH v2 1/3] clk: analogbits: add Wide-Range PLL library

[Stephen Boyd]

Quoting Paul Walmsley (2018-11-08 17:01:54)
> On 10/25/18 12:47 AM, Stephen Boyd wrote:
> > Quoting Paul Walmsley (2018-10-20 06:50:22)
> >> diff --git a/drivers/clk/analogbits/wrpll-cln28hpc.c 
> >> b/drivers/clk/analogbits/wrpll-cln28hpc.c
> >> new file mode 100644
> >> index ..ebdef859cbf5
> >> --- /dev/null
> >> +++ b/drivers/clk/analogbits/wrpll-cln28hpc.c
> >> @@ -0,0 +1,387 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (C) 2018 SiFive, Inc.
> >> + * Wesley Terpstra
> >> + * Paul Walmsley
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> > Can you drop these two paragraphs? It's duplicated from the SPDX tag.
> 
> 
> Yep, fixed.
> 
> 
> >> + * This library supports configuration parsing and reprogramming of
> >> + * the CLN28HPC variant of the Analog Bits Wide Range PLL.  The
> >> + * intention is for this library to be reusable for any device that
> >> + * integrates this PLL; thus the register structure and programming
> >> + * details are expected to be provided by a separate IP block driver.
> >> + *
> >> + * The bulk of this code is primarily useful for clock configurations
> >> + * that must operate at arbitrary rates, as opposed to clock 
> >> configurations
> >> + * that are restricted by software or manufacturer guidance to a small,
> >> + * pre-determined set of performance points.
> >> + *
> >> + * References:
> >> + * - Analog Bits "Wide Range PLL Datasheet", version 2015.10.01
> >> + * - SiFive FU540-C000 Manual v1p0, Chapter 7 "Clocking and Reset"
> > Any html links?
> 
> 
> The Analog Bits datasheet is not available on-line, to my knowledge. 
> The comments in this driver are an attempt to document it for software
> developers.
> 
> 
> The SiFive datasheet is available online; just added a link to the comments.

Ok.

> 
> 
> >> + */
> >> +
> >> +#include 
> > Is this used?
> 
> 
> Yes - the library doesn't compile without it:

Alright.

> 
> 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +/* MIN_INPUT_FREQ: minimum input clock frequency, in Hz (Fref_min) */
> >> +#define MIN_INPUT_FREQ 700
> >> +
> >> +/* MAX_INPUT_FREQ: maximum input clock frequency, in Hz (Fref_max) */
> >> +#define MAX_INPUT_FREQ 6
> >> +
> >> +/* MIN_POST_DIVIDE_REF_FREQ: minimum post-divider reference frequency, in 
> >> Hz */
> >> +#define MIN_POST_DIVR_FREQ 700
> >> +
> >> +/* MAX_POST_DIVIDE_REF_FREQ: maximum post-divider reference frequency, in 
> >> Hz */
> >> +#define MAX_POST_DIVR_FREQ 2
> >> +
> >> +/* MIN_VCO_FREQ: minimum VCO frequency, in Hz (Fvco_min) */
> >> +#define MIN_VCO_FREQ   24UL
> >> +
> >> +/* MAX_VCO_FREQ: maximum VCO frequency, in Hz (Fvco_max) */
> >> +#define MAX_VCO_FREQ   48ULL
> >> +
> >> +/* MAX_DIVQ_DIVISOR: maximum output divisor.  Selected by DIVQ = 6 */
> >> +#define MAX_DIVQ_DIVISOR   64
> >> +
> >> +/* MAX_DIVR_DIVISOR: maximum reference divisor.  Selected by DIVR = 63 */
> >> +#define MAX_DIVR_DIVISOR   64
> >> +
> >> +/* MAX_LOCK_US: maximum PLL lock time, in microseconds (tLOCK_max) */
> >> +#define MAX_LOCK_US70
> >> +
> >> +/*
> >> + * ROUND_SHIFT: number of bits to shift to avoid precision loss in the 
> >> rounding
> >> + *  algorithm
> >> + */
> >> +#define ROUND_SHIFT20
> >> +
> >> +/*
> >> + * Private functions
> >> + */
> >> +
> >> +/**
> >> + * __wrpll_calc_filter_range() - determine PLL loop filter bandwidth
> >> + * @post_divr_freq: input clock rate after the R divider
> >> + *
> >> + * Select the value to be presented to the PLL RANGE input signals, based
> >> + * on the input clock frequency after the post-R-divider @post_divr_freq.
> >> + * This code follows the recommendations in the PLL datasheet for filter
> >> + * range selection.
> >> + *
> >> + * Return: The RANGE value to be presented to the PLL configuration 
> >> inputs,
> >> + * or -1 upon error.
> >> + */
> >> +static int __wrpll_calc_filter_range(unsigned long post_divr_freq)
> >> +{
> >> +   u8 range;
> >> +
> >> +   if (post_divr_freq < MIN_POST_DIVR_FREQ ||
> >> +   post_divr_freq > MAX_POST_DIVR_FREQ) {
> >> +   WARN(1, "%s: post-divider reference freq out of range: 
> >> %lu",
> >> +__func__, post_divr_freq);
> >> +   return -1;
> >> +   }
> >> +
> >> +   if (post_divr_freq < 1100)
> >> +   ra

Re: [PATCH 1/3] ARM: davinci: define gpio interrupts as separate resources

[Bartosz Golaszewski]

śr., 21 lis 2018 o 00:07 Sekhar Nori  napisał(a):
>
> On 20/11/18 12:08 PM, J, KEERTHY wrote:
> >
> >
> > On 11/20/2018 2:22 AM, Sekhar Nori wrote:
> >> On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
> >>> From: Bartosz Golaszewski 
> >>>
> >>> Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
> >>> IRQ numbering") the davinci GPIO driver fails to probe if we boot
> >>> in legacy mode from any of the board files. Since the driver now
> >>> expects every interrupt to be defined as a separate resource, split
> >>> the definition in devices-da8xx.c instead of having a single continuous
> >>> interrupt range.
> >>>
> >>> Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ
> >>> numbering")
> >>> Cc: sta...@vger.kernel.org
> >>> Signed-off-by: Bartosz Golaszewski 
> >>
> >> There are a number of other boards that need such fixing too. And the
> >> commit in question does not do a good job of explaining why it was
> >> needed in the first place. The description  just repeats what can be
> >> inferred by reading the patch.
> >
> > Cc Lokesh
> >
> > Sekhar,
> >
> > DT explicitly mentions every IRQ number. The patch in discussion
> > explicitly calls platform_get_irq for all the interrupts which to me is
> > the right thing to do as: platform_get_irq-->
> > of_irq_get-->irq_create_of_mapping--> sequence is to be done for every IRQ.
> >
> > k3-am654 definitely will need explicit calls to platform_get_irq as it
> > will be involving interrupt router and interrupt numbers need not be
> > continuous.
> >
> > So i do not think reverting the patch is the right idea.
>
> Well, all of this description of patch motivation should have been in
> the patch description to begin with.
>
> Bartosz, can you please extend this patch to fix this problem for other
> DaVinci SoCs too? I am on the road this week, but will do my best to
> queue these fixes at the earliest .
>
> Thanks,
> Sekhar

Ok, to make it easier for you, I'll resend all the patches addressing
the GPIO issue.

Bart

Re: [PATCH v2 06/15] arm: dts: Add devicetree for OrangePi 2G IoT board

[Arnd Bergmann]

On Wed, Nov 21, 2018 at 4:38 AM Manivannan Sadhasivam
 wrote:
> +   aliases {
> +   serial0 = &uart0;
> +   serial1 = &uart1;
> +   serial2 = &uart2;
> +   };
>
+
> +&uart2 {
> +   status = "okay";
> +   clocks = <&uart2_clk>;
> +};

This is clearly mismatched here: you mark only one uart as 'enabled, but
list three of them as aliases. Having 'serial0' point to a disabled uart
may easily break applications that expect the first one to be the
console.

Best make that

   serial0 = &uart2;

and drop the other ones if only one of them is exposed on the
board. If all three are usable, you should enable them all here,
and make sure that the numbering of the aliases matches the
labels on the board or its documentation.

Arnd

Re: [PATCH v2 1/3] thermal: tegra: continue if sensor register fails

[Daniel Lezcano]

On 13/11/2018 11:06, Wei Ni wrote:
> Don't bail when a sensor fails to register with the
> thermal zone and allow other sensors to register.
> This allows other sensors to register with thermal
> framework even if one sensor fails registration.

I'm not sure if ignoring the error is really safe. Can you describe the
real situation you want to overcome ? How do you differentiate critical
sensors ?

> Signed-off-by: Wei Ni 
> ---
>  drivers/thermal/tegra/soctherm.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/thermal/tegra/soctherm.c 
> b/drivers/thermal/tegra/soctherm.c
> index ed28110a3535..a824d2e63af3 100644
> --- a/drivers/thermal/tegra/soctherm.c
> +++ b/drivers/thermal/tegra/soctherm.c
> @@ -1370,9 +1370,9 @@ static int tegra_soctherm_probe(struct platform_device 
> *pdev)
>&tegra_of_thermal_ops);
>   if (IS_ERR(z)) {
>   err = PTR_ERR(z);
> - dev_err(&pdev->dev, "failed to register sensor: %d\n",
> - err);
> - goto disable_clocks;
> + dev_warn(&pdev->dev, "failed to register sensor %s: 
> %d\n",
> +  soc->ttgs[i]->name, err);
> + continue;
>   }
>  
>   zone->tz = z;
> @@ -1434,6 +1434,8 @@ static int __maybe_unused soctherm_resume(struct device 
> *dev)
>   struct thermal_zone_device *tz;
>  
>   tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
> + if (!tz)
> + continue;
>   err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
>   if (err) {
>   dev_err(&pdev->dev,
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

[Geert Uytterhoeven]

Hi Finn,

On Wed, Nov 21, 2018 at 9:41 AM Finn Thain  wrote:
> On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:
> > On Wed, Nov 21, 2018 at 12:13 AM Finn Thain  
> > wrote:
> > > On atari, the 68901 counts down to 0x01 and raises an interrupt. On
> > > mac, the 6522 counts down to 0x then raises an interrupt. No idea
> > > about amiga (Geert?) -- this has to be handled correctly to get a
> > > monotonic clocksource. I'll fix this in v3 (where the information is
> > > available).
> >
> > The docs state that the CIA generates on interrupt on underflow, so I
> > guess that's the same behavior as the 6522 VIA.
>
> Difficult to say. The sequence varies from one implementation to another.
> Let's ignore the MSB and LSB and pretend it's one register:
>
> MC68901: N, N-1, N-2, ..., 2, 1, N, N-1, N-2, ...
> MC6840:  N, N-1, N-2, ..., 2, 1, 0, N, N-1, N-2, ...
> SY6522:  N, N-1, N-2, ..., 2, 1, 0, 0x, N, N-1, N-2, ...
>
> Now the question is, when the timer asserts its interrupt, and the count
> register is fetched immediately, what value does it have?
>
> For the MC68901, you get 1. For the SY6522, you get 0x. For MC6840, as
> far as I can tell, you'd get 0.

I assume 0x. The 8520 CIA is almost identical to the 6526 CIA, as used in
the C64, which is a direct descendant of the 6522 VIA.

> > Unfortunately the 24-bit ("TOD") counters in the two CIAs run from HSYNC
> > resp. VSYNC, which depends on the video mode, and thus can't be used as
> > a monotonic clock source.
>
> Is that because of video mode changes? Could the clocksource be
> unregistered before the mode change and then re-registered at a different
> frequency afterwards?

On older Amigas (most plain 68000, unless expanded), video modes are fixed.
Some have a jumper to select the power supply tick instead of the VSYNC
signal, which is more accurate, but still runs at a low 50 or 60 Hz.
On anything more modern (A3000 and up), video modes are programmable.
In addition, blanking the screen according to VESA will disable sync signals,
thus stopping the clock, I assume.

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 2/2] clk: qcom: Support 'protected-clocks' property

[Stephen Boyd]

Quoting Stephen Boyd (2018-11-05 11:40:11)
> Certain firmware configurations "protect" clks and cause the entire
> system to reboot when a non-secure OS such as Linux tries to read or
> write protected clk registers. But other firmware configurations allow
> reading or writing the same registers, and they may actually require
> that the OS use the otherwise locked down clks. Support the
> 'protected-clocks' property by never registering these protected clks
> with the common clk framework. This way, when firmware is protecting
> these clks we won't have the chance to ever read or write these
> registers and take down the entire system.
> 
> Cc: Taniya Das 
> Cc: Bjorn Andersson 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

Re: [PATCH 1/2] dt-bindings: clk: Introduce 'protected-clocks' property

[Stephen Boyd]

Quoting Stephen Boyd (2018-11-05 11:40:10)
> Add a generic clk property for clks which are not intended to be used by
> the OS due to security restrictions put in place by firmware. For
> example, on some Qualcomm firmwares reading or writing certain clk
> registers causes the entire system to reboot, but on other firmwares
> reading and writing those same registers is required to make devices
> like QSPI work. Rather than adding one-off properties each time a new
> set of clks appears to be protected, let's add a generic clk property to
> describe any set of clks that shouldn't be touched by the OS. This way
> we never need to register the clks or use them in certain firmware
> configurations.
> 
> Cc: Rob Herring 
> Cc: Bjorn Andersson 
> Cc: Taniya Das 
> Signed-off-by: Stephen Boyd 
> ---

Applied to clk-next

Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Mark protected gcc clocks

[Stephen Boyd]

Quoting Bjorn Andersson (2018-11-05 21:50:13)
> As of v4.20-rc1 probing the GCC driver on a SDM845 device with the
> standard security implementation causes an access violation and an
> immediate system restart. Use the protected-clocks property to mark the
> offending clocks protected for the MTP, in order to allow it to boot.
> 
> Cc: Stephen Boyd 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> This depends on the acceptance of
> https://lore.kernel.org/lkml/20181105194011.43770-1-swb...@chromium.org/

Do you need me to merge this into clk-fixes so that Andy can send this
up for v4.20 final? I thought you may have other boot blocking issues so
this wouldn't be a critical fix.

Re: Backed up kernels

[Jean Delvare]

Hi Masahiro,

On Wed, 21 Nov 2018 15:59:49 +0900, Masahiro Yamada wrote:
> On Tue, Nov 20, 2018 at 10:40 PM Jean Delvare  wrote:
> > Therefore I am asking, can we change "make install" so that it does NOT
> > create a backup copy of an existing kernel?  
> 
> I think your suggestion makes sense,
> but "make install" is basically implemented
> by arch-specific shell script.
> (For example, arch/x86/boot/install.sh)

Thanks for the pointer. However I have a hard time believing that the
script above is what is run when I call "make install". It looks pretty
old, doesn't support kernel files with version strings, and only knows
of lilo as a boot loader.

But I see there is a hook at the beginning for a user or distribution
provided install script:

if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi

So I guess that what I really care about is the /sbin/installkernel
script on my system, which is part of the dracut package. Which means I
must talk to the dracut package maintainer of my distribution.

> Will you talk to the maintainers
> of architecture you are interested in?
> 
> (or send it to linux-a...@vger.kernel.org)

It doesn't seem x86-specific, as apparently a lot of code was
copy-and-pasted across architectures over time. It probably doesn't
make sense to change it on one architecture and not on the others.

Also, if anyone is using these basic kernel-provided installation
scripts, then keeping a backup may actually make sense, because the
kernel files have no version strings, so a new kernel would always
overwrite the previous one, only leaving one kernel in place. If that
kernel doesn't boot for whatever reason, then game over.

So I think we should leave things as is on the kernel side.

Thanks again,
-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH] arm64: dts: qcom: sdm845-mtp: Mark protected gcc clocks

[Stephen Boyd]

Quoting Bjorn Andersson (2018-11-05 21:50:13)
> As of v4.20-rc1 probing the GCC driver on a SDM845 device with the
> standard security implementation causes an access violation and an
> immediate system restart. Use the protected-clocks property to mark the
> offending clocks protected for the MTP, in order to allow it to boot.
> 
> Cc: Stephen Boyd 
> Signed-off-by: Bjorn Andersson 
> ---
> 

Sorry, I meant to say do you want me to send in the protected clk
patches into clk-fixes so it can be merged for v4.20 final. I expected
Andy to pick up these dts patches.

Re: [PATCH 1/4] perf intel-pt: fix potential NULL pointer dereference in intel_pt_process_auxtrace_info

[Adrian Hunter]

On 21/11/18 9:40 AM, Wen Yang wrote:
> This patch fixes a possible null pointer dereference in
> intel_pt_process_auxtrace_info, detected by the semantic patch
> deref_null.cocci, with the following warning:
> 
> ./tools/perf/util/intel-pt.c:2579:32-49: ERROR: session -> itrace_synth_opts 
> is NULL but dereferenced.
> 
> Signed-off-by: Wen Yang 
> Reviewed-by: Tan Hu 
> CC: Julia Lawall 
> ---
>  tools/perf/util/intel-pt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
> index 149ff36..bac20e8 100644
> --- a/tools/perf/util/intel-pt.c
> +++ b/tools/perf/util/intel-pt.c
> @@ -2575,7 +2575,8 @@ int intel_pt_process_auxtrace_info(union perf_event 
> *event,
>   if (session->itrace_synth_opts && session->itrace_synth_opts->set) {
>   pt->synth_opts = *session->itrace_synth_opts;
>   } else {
> - itrace_synth_opts__set_default(&pt->synth_opts,
> + if (session->itrace_synth_opts)
> + itrace_synth_opts__set_default(&pt->synth_opts,
>   session->itrace_synth_opts->default_no_sample);
>   if (use_browser != -1) {
>   pt->synth_opts.branches = false;
> 

I would prefer to tidy it up more generally, like this:


From: Adrian Hunter 
Date: Wed, 21 Nov 2018 11:03:04 +0200
Subject: [PATCH] perf auxtrace: Tidy itrace default options setting

Tidy itrace default options setting, reducing duplicated code and making
itrace_synth_opts__set_default() more flexible.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/auxtrace.c  | 15 +++
 tools/perf/util/auxtrace.h  |  4 ++--
 tools/perf/util/cs-etm.c|  8 ++--
 tools/perf/util/intel-bts.c | 11 ---
 tools/perf/util/intel-pt.c  |  7 ++-
 5 files changed, 21 insertions(+), 24 deletions(-)

diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
index 72d5ba2479bf..d6016fe23c07 100644
--- a/tools/perf/util/auxtrace.c
+++ b/tools/perf/util/auxtrace.c
@@ -962,15 +962,20 @@ s64 perf_event__process_auxtrace(struct perf_session 
*session,
 #define PERF_ITRACE_DEFAULT_LAST_BRANCH_SZ 64
 #define PERF_ITRACE_MAX_LAST_BRANCH_SZ 1024
 
-void itrace_synth_opts__set_default(struct itrace_synth_opts *synth_opts,
-   bool no_sample)
+bool itrace_synth_opts__set_default(struct itrace_synth_opts *synth_opts,
+   const struct itrace_synth_opts 
*tool_synth_opts)
 {
+   if (tool_synth_opts && tool_synth_opts->set) {
+   *synth_opts = *tool_synth_opts;
+   return false;
+   }
+
synth_opts->branches = true;
synth_opts->transactions = true;
synth_opts->ptwrites = true;
synth_opts->pwr_events = true;
synth_opts->errors = true;
-   if (no_sample) {
+   if (tool_synth_opts && tool_synth_opts->default_no_sample) {
synth_opts->period_type = PERF_ITRACE_PERIOD_INSTRUCTIONS;
synth_opts->period = 1;
synth_opts->calls = true;
@@ -982,6 +987,8 @@ void itrace_synth_opts__set_default(struct 
itrace_synth_opts *synth_opts,
synth_opts->callchain_sz = PERF_ITRACE_DEFAULT_CALLCHAIN_SZ;
synth_opts->last_branch_sz = PERF_ITRACE_DEFAULT_LAST_BRANCH_SZ;
synth_opts->initial_skip = 0;
+
+   return true;
 }
 
 /*
@@ -1006,7 +1013,7 @@ int itrace_parse_synth_opts(const struct option *opt, 
const char *str,
}
 
if (!str) {
-   itrace_synth_opts__set_default(synth_opts, false);
+   itrace_synth_opts__set_default(synth_opts, NULL);
return 0;
}
 
diff --git a/tools/perf/util/auxtrace.h b/tools/perf/util/auxtrace.h
index 8e50f96d4b23..74c6d21231ed 100644
--- a/tools/perf/util/auxtrace.h
+++ b/tools/perf/util/auxtrace.h
@@ -530,8 +530,8 @@ int perf_event__process_auxtrace_error(struct perf_session 
*session,
   union perf_event *event);
 int itrace_parse_synth_opts(const struct option *opt, const char *str,
int unset);
-void itrace_synth_opts__set_default(struct itrace_synth_opts *synth_opts,
-   bool no_sample);
+bool itrace_synth_opts__set_default(struct itrace_synth_opts *synth_opts,
+   const struct itrace_synth_opts 
*tool_synth_opts);
 
 size_t perf_event__fprintf_auxtrace_error(union perf_event *event, FILE *fp);
 void perf_session__auxtrace_error_inc(struct perf_session *session,
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 73430b73570d..a1a20b4f3f82 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1450,13 +1450,9 @@ int cs_etm__process_auxtrace_info(union perf_event 
*event,
return 0;
}
 
-   if (session->itrace_synth_opts && session->itrace_synth_opts->set) {
-   etm

Re: [PATCH 4/4] perf intel-pt/bts: fix potential NULL pointer dereference in intel_bts_process_auxtrace_info

[Adrian Hunter]

On 21/11/18 9:43 AM, Wen Yang wrote:
> This patch fixes a possible null pointer dereference in
> intel_bts_process_auxtrace_info, detected by the semantic patch
> deref_null.cocci, with the following warning:
> 
> ./tools/perf/util/intel-bts.c:921:32-49: ERROR: session -> itrace_synth_opts 
> is NULL but dereferenced.
> 
> Signed-off-by: Wen Yang 
> Reviewed-by: Tan Hu 
> CC: Julia Lawall 
> ---
>  tools/perf/util/intel-bts.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
> index 7b27d77..b0258f4 100644
> --- a/tools/perf/util/intel-bts.c
> +++ b/tools/perf/util/intel-bts.c
> @@ -917,7 +917,8 @@ int intel_bts_process_auxtrace_info(union perf_event 
> *event,
>   if (session->itrace_synth_opts && session->itrace_synth_opts->set) {
>   bts->synth_opts = *session->itrace_synth_opts;
>   } else {
> - itrace_synth_opts__set_default(&bts->synth_opts,
> + if (session->itrace_synth_opts)
> + itrace_synth_opts__set_default(&bts->synth_opts,
>   session->itrace_synth_opts->default_no_sample);
>   if (session->itrace_synth_opts)
>   bts->synth_opts.thread_stack =
> 

See response to patch 1.

RE: [PATCH v3] thermal: qoriq: add multiple sensors support

[Andy Tang]

Hi Daniel,

Thanks for your explanation. The problem is these two trees are not synced well.
Let's take our driver(qoriq_thermal.c) for example.

Git log on Rui's tree next branch:
2dfef65 thermal: qoriq: Switch to SPDX identifier
1a893a5 thermal: qoriq: Simplify the 'site' variable assignment
f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register()
c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures
0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points()
4352844 thermal: qoriq: Add thermal management support

Git log on linux-soc-thermal tree branch next:
6017e2a thermal: qoriq: add i.mx8mq support
9b96566 thermal: Convert to using %pOFn instead of device_node.name
c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures
0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points()
4352844 thermal: qoriq: Add thermal management support

You can see that the first 2-3 commits on these two tress are different.

The strange thing is they seems sync well on Linus' tree:
0ef7791 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal
6017e2a thermal: qoriq: add i.mx8mq support
9b96566 thermal: Convert to using %pOFn instead of device_node.name
2dfef65 thermal: qoriq: Switch to SPDX identifier
1a893a5 thermal: qoriq: Simplify the 'site' variable assignment
f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register()
c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures
0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points()
4352844 thermal: qoriq: Add thermal management support

Currently my patch was created based on Run's tree, probably I should rebase it 
to soc tree.
But whichever tree I use, it can't be merged to Linus' tree without conflict.

Something I missed?

BR,
Andy
> -Original Message-
> From: Daniel Lezcano 
> Sent: 2018年11月21日 16:44
> To: Andy Tang ; rui.zh...@intel.com;
> edubez...@gmail.com
> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3] thermal: qoriq: add multiple sensors support
> 
> On 21/11/2018 02:34, Andy Tang wrote:
> > Hi all,
> >
> > Do you have any comments on this patch?
> >
> > I found for our thermal driver(qoriq_thermal.c) there are different
> between the following two git trees:
> > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
> > branch: next
> >
> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.gi
> t.
> > branch: next
> >
> > Could you please clarify which git tree/branch should I use?
> 
> SoC changes are submitted against linux-soc-thermal.git.
> 
> Generic thermal framework are sent against Zhang Rui's tree but it
> happens sometimes Eduardo pick them also when the changes are related
> to SoC behavior.
> 
> However, I agree that can be confusing :)
> 
> Eduardo, Rui,
> 
> how about to add a section in the maintainer handbook for the thermal to
> clarify the expectations and the flow?
> 
> >> -Original Message-
> >> From: Andy Tang
> >> Sent: 2018年11月14日 15:29
> >> To: rui.zh...@intel.com; daniel.lezc...@linaro.org
> >> Cc: edubez...@gmail.com; linux...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org
> >> Subject: RE: [PATCH v3] thermal: qoriq: add multiple sensors support
> >>
> >> PING.
> >>
> >> BR,
> >> Andy
> >>
> >>> -Original Message-
> >>> From: andy.t...@nxp.com 
> >>> Sent: 2018年10月30日 9:00
> >>> To: rui.zh...@intel.com; daniel.lezc...@linaro.org
> >>> Cc: edubez...@gmail.com; linux...@vger.kernel.org;
> >>> linux-kernel@vger.kernel.org; Andy Tang 
> >>> Subject: [PATCH v3] thermal: qoriq: add multiple sensors support
> >>>
> >>> From: Yuantian Tang 
> >>>
> >>> The QorIQ Layerscape SoC has several thermal sensors but the
> current
> >>> driver only supports one.
> >>>
> >>> Massage the code to be sensor oriented and allow the support for
> >>> multiple sensors.
> >>>
> >>> Signed-off-by: Yuantian Tang 
> >>> Reviewed-by: Daniel Lezcano 
> >>> ---
> >>> v3:
> >>>   - add Reviewed-by
> >>> v2:
> >>>   - update the commit message
> >>>   - refine the qoriq_tmu_register_tmu_zone()
> >>>
> >>>  drivers/thermal/qoriq_thermal.c |  100
> >>> ++-
> >>>  1 files changed, 46 insertions(+), 54 deletions(-)
> >>>
> >>> diff --git a/drivers/thermal/qoriq_thermal.c
> >>> b/drivers/thermal/qoriq_thermal.c index 450ed66..8beb344 100644
> >>> --- a/drivers/thermal/qoriq_thermal.c
> >>> +++ b/drivers/thermal/qoriq_thermal.c
> >>> @@ -59,14 +59,21 @@ struct qoriq_tmu_regs {
> >>>   u32 ttr3cr; /* Temperature Range 3 Control Register */
> >>>  };
> >>>
> >>> +struct qoriq_tmu_data;
> >>> +
> >>>  /*
> >>>   * Thermal zone data
> >>>   */
> >>> +struct qoriq_sensor {
> >>> + struct thermal_zone_device  *tzd;
> >>> + struct qoriq_tmu_data   *qdata;
> >>> + int id;
> >>> +};
> >>> +
> >>>  struct qoriq_tmu_data {
> >>> - struct t

Re: [PATCH v1 04/11] soc: mediatek: add new flow for mtcmos power.

[Weiyi Lu]

On Wed, 2018-11-21 at 00:07 -0800, Stephen Boyd wrote:
> Quoting Weiyi Lu (2018-11-19 18:37:34)
> > On Tue, 2018-11-13 at 11:31 -0800, Nicolas Boichat wrote:
> > > On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu  wrote:
> 
> > > > @@ -226,6 +397,7 @@ static int scpsys_power_on(struct generic_pm_domain 
> > > > *genpd)
> > > > if (ret < 0)
> > > > goto err_pwr_ack;
> > > >
> > > > +
> > > 
> > > Drop this.
> > Why do we try to drop this? Once the power-on step fail, the following
> > steps should not be permitted.
> 
> I just see a whitespace addition that doesn't do anything. I suspect
> it's a style nitpick and common practice to not include spurious diffs
> in the patch. So remove this hunk?
> 
Oops! I missed the extra whitespace. I will remove it. Many thanks.

Re: [PATCH 1/2] ASoC: sdm845: Update slot_width for Quaternary TDM port

[Srinivas Kandagatla]

On 16/11/18 07:41, Rohit kumar wrote:

Change slot_width for quaternary TDM port to 16 and
update bclk rate for TDM and MI2S interfaces
accordingly.

Signed-off-by: Rohit kumar  > ---
  sound/soc/qcom/sdm845.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)



Acked-by: Srinivas Kandagatla 

Re: [PATCH 2/2] ASoC: sdm845: Add support for Secondary MI2S interface

[Srinivas Kandagatla]

On 16/11/18 07:41, Rohit kumar wrote:

Add support to configure bit clock for secondary MI2S
TX interface.

Signed-off-by: Rohit kumar
---
  sound/soc/qcom/sdm845.c | 18 ++


Acked-by: Srinivas Kandagatla 

Re: [PATCH] regulator: wm8994: Don't use devres for enable GPIOs

[Marek Szyprowski]

Hi,

On 2018-11-20 18:25, Marek Szyprowski wrote:
> Hi Charles,
>
> On 2018-11-20 18:01, Charles Keepax wrote:
>> We need to manage the life time of the enable GPIO against the regulator
>> device but the OF node lives on the parent MFD device. As such we can't
>> use the devm functions which assume the same device will be used for
>> both.
>>
>> Reported-by: Marek Szyprowski 
>> Signed-off-by: Charles Keepax 
>> ---
>>
>> This patch is only build tested so it would be good to get a
>> tested by from Marek before applying.
> Sadly it looks that it is not enough. The issue is still there:
>
> wm8994 4-001a: Failed to get supply 'DBVDD1': -517
> wm8994 4-001a: Failed to get supplies: -517
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:2421
> regulator_ena_gpio_free+0x70/0xa0
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.20.0-rc3-next-20181120-1-g330f37c7fb0c #5090
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0x90/0xc8)
> [] (dump_stack) from [] (__warn+0xf8/0x124)
> [] (__warn) from [] (warn_slowpath_null+0x40/0x48)
> [] (warn_slowpath_null) from []
> (regulator_ena_gpio_free+0x70/0xa0)
> [] (regulator_ena_gpio_free) from []
> (regulator_unregister+0x134/0x17c)
> [] (regulator_unregister) from []
> (release_nodes+0x164/0x1dc)
> [] (release_nodes) from []
> (device_release_driver_internal+0x18c/0x21c)
> [] (device_release_driver_internal) from []
> (bus_remove_device+0xdc/0x12c)
> [] (bus_remove_device) from [] (device_del+0x108/0x2e0)
> [] (device_del) from [] (platform_device_del+0x20/0x8c)
> [] (platform_device_del) from []
> (platform_device_unregister+0xc/0x18)
> [] (platform_device_unregister) from []
> (mfd_remove_devices_fn+0x58/0x64)
> [] (mfd_remove_devices_fn) from []
> (device_for_each_child_reverse+0x34/0x74)
> [] (device_for_each_child_reverse) from []
> (mfd_remove_devices+0x20/0x30)
> [] (mfd_remove_devices) from []
> (wm8994_i2c_probe+0x2dc/0x8d0)
> [] (wm8994_i2c_probe) from []
> (i2c_device_probe+0x234/0x2b0)
> [] (i2c_device_probe) from [] (really_probe+0x224/0x3f4)
> [] (really_probe) from []
> (driver_probe_device+0x70/0x1c4)
> [] (driver_probe_device) from []
> (__driver_attach+0x120/0x144)
> [] (__driver_attach) from []
> (bus_for_each_dev+0x58/0x7c)
> [] (bus_for_each_dev) from []
> (bus_add_driver+0x174/0x250)
> [] (bus_add_driver) from [] (driver_register+0x7c/0x110)
> [] (driver_register) from []
> (i2c_register_driver+0x38/0xa8)
> [] (i2c_register_driver) from []
> (do_one_initcall+0x80/0x408)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0x3a0/0x4fc)
> [] (kernel_init_freeable) from []
> (kernel_init+0x8/0x118)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x20)
> Exception stack(0xef0e3fb0 to 0xef0e3ff8)
> 3fa0:   
> 
> 3fc0:       
> 
> 3fe0:     0013 
> irq event stamp: 176913
> hardirqs last  enabled at (176921): [] console_unlock+0x460/0x6ec
> hardirqs last disabled at (176940): [] console_unlock+0xb8/0x6ec
> softirqs last  enabled at (176956): [] __do_softirq+0x3a4/0x66c
> softirqs last disabled at (176967): [] irq_exit+0x140/0x168
>
> I will check more tomorrow.

I've checked a bit more and it looks that the issue is caused by
gpiod_put() in regulator_ena_gpio_free(). I've removed gpiod_put() call
from wm8994_ldo_remove(), switched to regulator_register() in
wm8994_ldo_probe() and added regulator_unregister() in
wm8994_ldo_remove(). This way the warning is gone. If there is any
other, simpler way to fix it, let me know. When regulator_register()
fails, gpiod will be freed only in some cases, depending what caused
failure. It looks that this needs some clarification...

>
>> Thanks,
>> Charles
>>
>>  drivers/regulator/wm8994-regulator.c | 28 +++-
>>  1 file changed, 23 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/regulator/wm8994-regulator.c 
>> b/drivers/regulator/wm8994-regulator.c
>> index d7fec533c403..f2592c30d0ca 100644
>> --- a/drivers/regulator/wm8994-regulator.c
>> +++ b/drivers/regulator/wm8994-regulator.c
>> @@ -31,6 +31,7 @@ struct wm8994_ldo {
>>  struct wm8994 *wm8994;
>>  struct regulator_consumer_supply supply;
>>  struct regulator_init_data init_data;
>> +struct gpio_desc *ena_gpiod;
>>  };
>>  
>>  #define WM8994_LDO1_MAX_SELECTOR 0x7
>> @@ -147,14 +148,19 @@ static int wm8994_ldo_probe(struct platform_device 
>> *pdev)
>>  config.regmap = wm8994->regmap;
>>  config.init_data = &ldo->init_data;
>>  
>> -/* Look up LDO enable GPIO from the parent device node */
>> -gpiod = devm_gpiod_get_optional(pdev->dev.parent,
>> -id ? "wlf,ldo2ena" : "wlf,ldo1ena",
>> -GPIOD_OUT

Re: [PATCH v2 5/5] Staging: iio: adt7316: Use device tree data to assign irq_type

[Shreeya Patel]

On Wed, 2018-11-21 at 08:21 +, Ardelean, Alexandru wrote:
> On Tue, 2018-11-20 at 22:30 +0530, Shreeya Patel wrote:
> > ADT7316 driver no more uses platform data and hence use device tree
> > data instead of platform data for assigning irq_type field.
> > Switch case figures out the type of irq and if it's the default
> > case
> > then assign the default value to the irq_type i.e.
> > irq_type = IRQF_TRIGGER_LOW
> > 
> 
> 1 comment inline
> 
> > Signed-off-by: Shreeya Patel 
> > ---
> >  drivers/staging/iio/addac/adt7316.c | 21 +
> >  1 file changed, 17 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/staging/iio/addac/adt7316.c
> > b/drivers/staging/iio/addac/adt7316.c
> > index 9c72538baf9e..c647875a64f5 100644
> > --- a/drivers/staging/iio/addac/adt7316.c
> > +++ b/drivers/staging/iio/addac/adt7316.c
> > @@ -2101,8 +2101,7 @@ int adt7316_probe(struct device *dev, struct
> > adt7316_bus *bus,
> >  {
> > struct adt7316_chip_info *chip;
> > struct iio_dev *indio_dev;
> > -   unsigned short *adt7316_platform_data = dev-
> > >platform_data;
> > -   int irq_type = IRQF_TRIGGER_LOW;
> > +   int irq_type;
> > int ret = 0;
> >  
> > indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
> > @@ -2146,8 +2145,22 @@ int adt7316_probe(struct device *dev, struct
> > adt7316_bus *bus,
> > indio_dev->modes = INDIO_DIRECT_MODE;
> >  
> > if (chip->bus.irq > 0) {
> > -   if (adt7316_platform_data[0])
> > -   irq_type = adt7316_platform_data[0];
> > +   irq_type =
> > +   irqd_get_trigger_type(irq_get_irq_data(chi
> > p-
> > > bus.irq));
> > 
> > +
> > +   switch (irq_type) {
> > +   case IRQF_TRIGGER_HIGH:
> > +   case IRQF_TRIGGER_RISING:
> > +   break;
> > +   case IRQF_TRIGGER_LOW:
> > +   case IRQF_TRIGGER_FALLING:
> > +   break;
> > +   default:
> > +   dev_info(dev, "mode %d unsupported, using
> > IRQF_TRIGGER_LOW\n",
> > +irq_type);
> > +   irq_type = IRQF_TRIGGER_LOW;
> > +   break;
> > +   }
> 
> It would be an idea to move this part [together with
> devm_request_threaded_irq()] into a "adt7316_setup_irq()" function.
> To un-
> clutter the code in the adt7316_probe() function.
> 

Yes, seems like a good idea!
Even other drivers are doing the same as you told me to do...thanks :)

I'll do the change after Jonathan picks up the other patches and will
wait for some other reviews to come up if there are any.

Thanks

> >  
> > ret = devm_request_threaded_irq(dev, chip-
> > >bus.irq,
> > NULL,

ASPEED graphics card: ast_pci_probe causes RCU stalls

[poza]

Hi,


we have on-board ASPEED Graphics card on PCIe.

kernel version: 4.16

I select following drive to enable ast graphics support.
Symbol: DRM_AST [=y] 
 
  \u2502
  AST server chips   
 
\u2502
  Location:  
 
  \u2502
  -> Device Drivers  
 
\u2502
-> Graphics support  
 
\u2502
  Defined at drivers/gpu/drm/ast/Kconfig:1   
 
  \u2502
  Depends on: HAS_IOMEM [=y] && DRM [=y] && PCI [=y] && MMU [=y] 
 
  \u2502

  Selects: DRM_TTM [=y] && DRM_KMS_HELPER [=y] && DRM_TTM [=y]

lspci -vvv output.
-

0007:02:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED 
Graphics Family (rev 41) (prog-if 00 [VGA controller])

Subsystem: ASPEED Technology, Inc. ASPEED Graphics Family
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Latency: 0
Interrupt: pin A routed to IRQ 255
Region 0: Memory at e7010100 (32-bit, non-prefetchable) 
[size=16M]
Region 1: Memory at e7010080 (32-bit, non-prefetchable) 
[size=128K]

Region 2: I/O ports at 6 [size=128]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)

Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/2 Maskable- 64bit+
Address:   Data: 


it seems to me that; ast_pci_probe seems to stuck in set_clock

[   38.293239] INFO: rcu_sched self-detected stall on CPU
[   38.300808]  0-: (35 ticks this GP) 
idle=256/1/4611686018427387906 softirq=183/183 fqs=187

[   38.313653]   (t=421 jiffies g=-232 c=-233 q=322)
[   38.320592] Task dump for CPU 0:
[   38.325566] kworker/0:0 R  running task0 3  2 
0x0002

[   38.335989] Workqueue: events work_for_cpu_fn
[   38.342409] Call trace:
[   38.346025]  dump_backtrace+0x0/0x170
[   38.351413]  show_stack+0x14/0x20
[   38.356297]  sched_show_task+0x104/0x128
[   38.362173]  dump_cpu_task+0x40/0x50
[   38.367441]  rcu_dump_cpu_stacks+0x94/0xd4
[   38.373480]  rcu_check_callbacks+0x574/0x7b0
[   38.379785]  update_process_times+0x2c/0x58
[   38.385946]  tick_sched_handle.isra.5+0x30/0x50
[   38.393830]  tick_sched_timer+0x40/0x90
[   38.399480]  __hrtimer_run_queues+0x120/0x1b8
[   38.405895]  hrtimer_interrupt+0xd4/0x250
[   38.411815]  arch_timer_handler_phys+0x28/0x40
[   38.418361]  handle_percpu_devid_irq+0x80/0x138
[   38.425152]  generic_handle_irq+0x24/0x38
[   38.431057]  __handle_domain_irq+0x5c/0xb0
[   38.437104]  gic_handle_irq+0x7c/0x184
[   38.442639]  el1_irq+0xb0/0x140
[   38.447265]  ast_get_index_reg_mask+0x4/0x38
[   38.453553]  __i2c_bit_add_bus+0x54/0x3e0
[   38.459532]  i2c_bit_add_bus+0x14/0x20
[   38.465057]  ast_mode_init+0x230/0x358
[   38.470584]  ast_driver_load+0x5a4/0x968
[   38.476368]  drm_dev_register+0x154/0x1d8
[   38.482283]  drm_get_pci_dev+0x94/0x160
[   38.488047]  ast_pci_probe+0x18/0x20
[   38.493318]  local_pci_probe+0x28/0x80
[   38.498830]  work_for_cpu_fn+0x18/0x28
[   38.504367]  process_one_work+0x1d4/0x310
[   38.510271]  worker_thread+0x230/0x470
[   38.515804]  kthread+0x128/0x130
[   38.520777]  ret_from_fork+0x10/0x18

Regards,
Oza.

Re: [PATCH AUTOSEL 4.9 08/17] drm/edid: Add 6 bpc quirk for BOE panel.

[Daniel Vetter]

On Wed, Nov 21, 2018 at 10:31 AM Daniel Vetter  wrote:
>
> On Tue, Nov 13, 2018 at 12:52:14AM -0500, Sasha Levin wrote:
> > From: "Lee, Shawn C" 
> >
> > [ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ]
> >
> > BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
> > But it's 6bpc panel only instead of 8 bpc.
> >
> > Add panel ID to edid quirk list and set 6 bpc as default to
> > work around this issue.
> >
> > Cc: Jani Nikula 
> > Cc: Maarten Lankhorst 
> > Cc: Gustavo Padovan 
> > Cc: Cooper Chiou 
> > Signed-off-by: Lee, Shawn C >
> > Signed-off-by: Daniel Vetter 
> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/1540792173-7288-1-git-send-email-shawn.c@intel.com
> > Signed-off-by: Sasha Levin 
>
> Given that I'm not a fan of AUTOSEL at all: This one here is correctly
> cherry-picked for stable, ack.

An idea that just crossed my mind: Could we integrate this into 0day
and suggest cc: stable before the patch even gets merged? Or is the
heuristics not good enough for that kind of automation?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

RE: [PATCH 01/14] ARM: milbeaut: Add basic support for Milbeaut m10v SoC

[sugaya.taichi]

Hi Rob

Thank you for your comments.

> -Original Message-
> From: Rob Herring [mailto:robh...@kernel.org]
> Sent: Tuesday, November 20, 2018 1:24 AM
> To: Sugaya, Taichi
> Cc: linux-clk; devicet...@vger.kernel.org; moderated list:ARM/FREESCALE
> IMX / MXC ARM ARCHITECTURE; linux-kernel@vger.kernel.org; open list:SERIAL
> DRIVERS; Michael Turquette; Stephen Boyd; Mark Rutland; Greg Kroah-Hartman;
> Daniel Lezcano; Thomas Gleixner; Russell King; Jiri Slaby; Masami Hiramatsu;
> Jassi Brar
> Subject: Re: [PATCH 01/14] ARM: milbeaut: Add basic support for Milbeaut
> m10v SoC
> 
> On Sun, Nov 18, 2018 at 7:00 PM Sugaya Taichi
>  wrote:
> >
> > This adds the basic M10V SoC support under arch/arm.
> > Since all cores are activated in the custom bootloader before booting
> > linux, it is necessary to wait for sub-cores using the trampoline area.
> >
> > Signed-off-by: Sugaya Taichi 
> > ---
> >  arch/arm/Kconfig  |   2 +
> >  arch/arm/Makefile |   1 +
> >  arch/arm/mach-milbeaut/Kconfig|  28 +++
> >  arch/arm/mach-milbeaut/Makefile   |   3 +
> >  arch/arm/mach-milbeaut/m10v_evb.c |  31 
> >  arch/arm/mach-milbeaut/platsmp.c  | 157
> ++
> >  6 files changed, 222 insertions(+)
> >  create mode 100644 arch/arm/mach-milbeaut/Kconfig
> >  create mode 100644 arch/arm/mach-milbeaut/Makefile
> >  create mode 100644 arch/arm/mach-milbeaut/m10v_evb.c
> >  create mode 100644 arch/arm/mach-milbeaut/platsmp.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 91be74d..0b8a1af 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -767,6 +767,8 @@ source "arch/arm/mach-mediatek/Kconfig"
> >
> >  source "arch/arm/mach-meson/Kconfig"
> >
> > +source "arch/arm/mach-milbeaut/Kconfig"
> > +
> >  source "arch/arm/mach-mmp/Kconfig"
> >
> >  source "arch/arm/mach-moxart/Kconfig"
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 05a91d8..627853c 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -190,6 +190,7 @@ machine-$(CONFIG_ARCH_MV78XX0)  +=
> mv78xx0
> >  machine-$(CONFIG_ARCH_MVEBU)   += mvebu
> >  machine-$(CONFIG_ARCH_MXC) += imx
> >  machine-$(CONFIG_ARCH_MEDIATEK)+= mediatek
> > +machine-$(CONFIG_ARCH_MILBEAUT)+= milbeaut
> >  machine-$(CONFIG_ARCH_MXS) += mxs
> >  machine-$(CONFIG_ARCH_NETX)+= netx
> >  machine-$(CONFIG_ARCH_NOMADIK) += nomadik
> > diff --git a/arch/arm/mach-milbeaut/Kconfig
> b/arch/arm/mach-milbeaut/Kconfig
> > new file mode 100644
> > index 000..63b6f69
> > --- /dev/null
> > +++ b/arch/arm/mach-milbeaut/Kconfig
> > @@ -0,0 +1,28 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +menuconfig ARCH_MILBEAUT
> > +   bool "Socionext Milbeaut SoCs"
> > +   depends on ARCH_MULTI_V7
> > +   select ARM_GIC
> 
> > +   select CLKDEV_LOOKUP
> > +   select GENERIC_CLOCKEVENTS
> > +   select CLKSRC_MMIO
> 
> The clock and timer drivers' kconfig entries should select these.
OK. move these to the correct kconfig.

> 
> > +   select ZONE_DMA
> 
> Why is this needed?
Ah, it may not be needed yet. confirm it.

> 
> > +   help
> > +   This enables support for Socionext Milbeaut SoCs
> > +
> > +if ARCH_MILBEAUT
> > +
> > +config ARCH_MILBEAUT_M10V
> > +   bool "Milbeaut SC2000/M10V platform"
> > +   select ARM_ARCH_TIMER
> > +   select M10V_TIMER
> > +   select PINCTRL
> > +   select PINCTRL_M10V
> > +   help
> > + Support for Socionext's MILBEAUT M10V based systems
> > +
> > +config MACH_M10V_EVB
> > +   bool "Support for Milbeaut Evaluation boards"
> 
> You shouldn't need a kconfig entry for each board.
I see. 

> 
> > +   default y
> > +
> > +endif
> > diff --git a/arch/arm/mach-milbeaut/Makefile
> b/arch/arm/mach-milbeaut/Makefile
> > new file mode 100644
> > index 000..64f6f52
> > --- /dev/null
> > +++ b/arch/arm/mach-milbeaut/Makefile
> > @@ -0,0 +1,3 @@
> > +obj-$(CONFIG_SMP) += platsmp.o
> > +obj-$(CONFIG_MACH_M10V_EVB) += m10v_evb.o
> > +
> > diff --git a/arch/arm/mach-milbeaut/m10v_evb.c
> b/arch/arm/mach-milbeaut/m10v_evb.c
> > new file mode 100644
> > index 000..a1fa7c3
> > --- /dev/null
> > +++ b/arch/arm/mach-milbeaut/m10v_evb.c
> 
> This all looks SoC specific, not board specific.
Um that is right..

> 
> > @@ -0,0 +1,31 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 Socionext Inc.
> > + * Copyright:   (C) 2015 Linaro Ltd.
> > + */
> > +
> > +#include 
> > +#include 
> 
> Not needed.
OK.

> 
> > +
> > +#include 
> > +#include 
> > +
> > +static struct map_desc m10v_io_desc[] __initdata = {
> > +};
> > +
> > +void __init m10v_map_io(void)
> > +{
> > +   debug_ll_io_init();
> 
> If you use earlycon instead, then this isn't needed.
> 
> > +   iotable_init(m10v_io_desc, ARRAY_SIZE(m10v_io_desc));
> 
> This isn't needed.
OK.

> 
> > +}
> > 

[PATCH 01/12] ARM: davinci: da8xx: define gpio interrupts as separate resources

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the definition of IRQ resources instead of having a single continuous
interrupt range.

Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/devices-da8xx.c | 40 +++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index 1fd3619f6a09..cf78da5ab054 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -701,6 +701,46 @@ static struct resource da8xx_gpio_resources[] = {
},
{ /* interrupt */
.start  = IRQ_DA8XX_GPIO0,
+   .end= IRQ_DA8XX_GPIO0,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DA8XX_GPIO1,
+   .end= IRQ_DA8XX_GPIO1,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DA8XX_GPIO2,
+   .end= IRQ_DA8XX_GPIO2,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DA8XX_GPIO3,
+   .end= IRQ_DA8XX_GPIO3,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DA8XX_GPIO4,
+   .end= IRQ_DA8XX_GPIO4,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DA8XX_GPIO5,
+   .end= IRQ_DA8XX_GPIO5,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DA8XX_GPIO6,
+   .end= IRQ_DA8XX_GPIO6,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DA8XX_GPIO7,
+   .end= IRQ_DA8XX_GPIO7,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DA8XX_GPIO8,
.end= IRQ_DA8XX_GPIO8,
.flags  = IORESOURCE_IRQ,
},
-- 
2.19.1

[PATCH 03/12] ARM: davinci: dm646x: define gpio interrupts as separate resources

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the definition of IRQ resources instead of having a single continuous
interrupt range.

Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/dm646x.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 6bd2ed069d0d..d9b93e2806d2 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -442,6 +442,16 @@ static struct resource dm646x_gpio_resources[] = {
},
{   /* interrupt */
.start  = IRQ_DM646X_GPIOBNK0,
+   .end= IRQ_DM646X_GPIOBNK0,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM646X_GPIOBNK1,
+   .end= IRQ_DM646X_GPIOBNK1,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM646X_GPIOBNK2,
.end= IRQ_DM646X_GPIOBNK2,
.flags  = IORESOURCE_IRQ,
},
-- 
2.19.1

[PATCH 00/12] ARM: davinci: fix GPIO breakage after v4.19

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

This is the entire set of changes needed to fix the broken GPIO support
for DaVinci boards in legacy mode after certain changes made to the
GPIO driver in 4.19, namely: commits 587f7a694f01 ("gpio: davinci: Use
dev name for label and automatic base selection") and eb3744a2dd01
("gpio: davinci: Do not assume continuous IRQ numbering").

Bartosz Golaszewski (12):
  ARM: davinci: da8xx: define gpio interrupts as separate resources
  ARM: davinci: dm365: define gpio interrupts as separate resources
  ARM: davinci: dm646x: define gpio interrupts as separate resources
  ARM: davinci: dm355: define gpio interrupts as separate resources
  ARM: davinci: dm644x: define gpio interrupts as separate resources
  gpio: davinci: restore a way to manually specify the GPIO base
  ARM: davinci: da850: set the GPIO base to 0
  ARM: davinci: dm365: set the GPIO base to 0
  ARM: davinci: dm646x: set the GPIO base to 0
  ARM: davinci: dm355: set the GPIO base to 0
  ARM: davinci: da830: set the GPIO base to 0
  ARM: davinci: dm644x: set the GPIO base to 0

 arch/arm/mach-davinci/da830.c  |  4 ++-
 arch/arm/mach-davinci/da850.c  |  4 ++-
 arch/arm/mach-davinci/devices-da8xx.c  | 40 ++
 arch/arm/mach-davinci/dm355.c  | 32 +
 arch/arm/mach-davinci/dm365.c  | 37 
 arch/arm/mach-davinci/dm644x.c | 22 
 arch/arm/mach-davinci/dm646x.c | 12 +++
 drivers/gpio/gpio-davinci.c|  2 +-
 include/linux/platform_data/gpio-davinci.h |  2 ++
 9 files changed, 152 insertions(+), 3 deletions(-)

-- 
2.19.1

[PATCH 12/12] ARM: davinci: dm644x: set the GPIO base to 0

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.

DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.

Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base 
selection")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/dm644x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index de1ec6dc01e9..38f92b7d413e 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -518,6 +518,8 @@ static struct resource dm644_gpio_resources[] = {
 };
 
 static struct davinci_gpio_platform_data dm644_gpio_platform_data = {
+   .no_auto_base   = true,
+   .base   = 0,
.ngpio  = 71,
 };
 
-- 
2.19.1

[PATCH 10/12] ARM: davinci: dm355: set the GPIO base to 0

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.

DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.

Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base 
selection")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/dm355.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 2b0f5d97ab7c..4c6e0bef4509 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -584,6 +584,8 @@ static struct resource dm355_gpio_resources[] = {
 };
 
 static struct davinci_gpio_platform_data dm355_gpio_platform_data = {
+   .no_auto_base   = true,
+   .base   = 0,
.ngpio  = 104,
 };
 
-- 
2.19.1

[PATCH 06/12] gpio: davinci: restore a way to manually specify the GPIO base

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.

Other boards may be broken too, which I haven't tested.

The problem is in the fact that most board files still use the legacy
GPIO API where lines are requested by numbers rather than descriptors.

While this should be fixed eventually, in order to unbreak the board
for now - provide a way to manually specify the GPIO base in platform
data.

Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base 
selection")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
Acked-by: Linus Walleij 
---
 drivers/gpio/gpio-davinci.c| 2 +-
 include/linux/platform_data/gpio-davinci.h | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 5c1564fcc24e..bdb29e51b417 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -258,7 +258,7 @@ static int davinci_gpio_probe(struct platform_device *pdev)
chips->chip.set = davinci_gpio_set;
 
chips->chip.ngpio = ngpio;
-   chips->chip.base = -1;
+   chips->chip.base = pdata->no_auto_base ? pdata->base : -1;
 
 #ifdef CONFIG_OF_GPIO
chips->chip.of_gpio_n_cells = 2;
diff --git a/include/linux/platform_data/gpio-davinci.h 
b/include/linux/platform_data/gpio-davinci.h
index f92a47e18034..a93841bfb9f7 100644
--- a/include/linux/platform_data/gpio-davinci.h
+++ b/include/linux/platform_data/gpio-davinci.h
@@ -17,6 +17,8 @@
 #define __DAVINCI_GPIO_PLATFORM_H
 
 struct davinci_gpio_platform_data {
+   boolno_auto_base;
+   u32 base;
u32 ngpio;
u32 gpio_unbanked;
 };
-- 
2.19.1

[PATCH 11/12] ARM: davinci: da830: set the GPIO base to 0

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.

DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.

Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base 
selection")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da830.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 0bc5bd2665df..2cc9fe4c3a91 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -759,7 +759,9 @@ static struct davinci_id da830_ids[] = {
 };
 
 static struct davinci_gpio_platform_data da830_gpio_platform_data = {
-   .ngpio = 128,
+   .no_auto_base   = true,
+   .base   = 0,
+   .ngpio  = 128,
 };
 
 int __init da830_register_gpio(void)
-- 
2.19.1

[PATCH 08/12] ARM: davinci: dm365: set the GPIO base to 0

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.

DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.

Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base 
selection")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/dm365.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 42665914166a..01fb2b0c82de 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -308,6 +308,8 @@ static struct resource dm365_gpio_resources[] = {
 };
 
 static struct davinci_gpio_platform_data dm365_gpio_platform_data = {
+   .no_auto_base   = true,
+   .base   = 0,
.ngpio  = 104,
.gpio_unbanked  = 8,
 };
-- 
2.19.1

[PATCH 09/12] ARM: davinci: dm646x: set the GPIO base to 0

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.

DaVinci board files use the legacy GPIO API with hard-coded GPIO line
numbers. Use the new fields in struct davinci_gpio_platform_data to
manually set the GPIO base to 0.

Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base 
selection")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/dm646x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index d9b93e2806d2..7dc54b2a610f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -458,6 +458,8 @@ static struct resource dm646x_gpio_resources[] = {
 };
 
 static struct davinci_gpio_platform_data dm646x_gpio_platform_data = {
+   .no_auto_base   = true,
+   .base   = 0,
.ngpio  = 43,
 };
 
-- 
2.19.1

[PATCH 07/12] ARM: davinci: da850: set the GPIO base to 0

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.

We now have the option to specify the GPIO base manually for davinci,
so add the relevant fields to platform data.

Fixes: 587f7a694f01 ("gpio: davinci: Use dev name for label and automatic base 
selection")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/da850.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4528bbf0c861..e7b78df2bfef 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -719,7 +719,9 @@ int __init da850_register_vpif_capture(struct 
vpif_capture_config
 }
 
 static struct davinci_gpio_platform_data da850_gpio_platform_data = {
-   .ngpio = 144,
+   .no_auto_base   = true,
+   .base   = 0,
+   .ngpio  = 144,
 };
 
 int __init da850_register_gpio(void)
-- 
2.19.1

[PATCH 04/12] ARM: davinci: dm355: define gpio interrupts as separate resources

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the definition of IRQ resources instead of having a single continuous
interrupt range.

Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/dm355.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 9f7d38d12c88..2b0f5d97ab7c 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -548,6 +548,36 @@ static struct resource dm355_gpio_resources[] = {
},
{   /* interrupt */
.start  = IRQ_DM355_GPIOBNK0,
+   .end= IRQ_DM355_GPIOBNK0,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM355_GPIOBNK1,
+   .end= IRQ_DM355_GPIOBNK1,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM355_GPIOBNK2,
+   .end= IRQ_DM355_GPIOBNK2,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM355_GPIOBNK3,
+   .end= IRQ_DM355_GPIOBNK3,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM355_GPIOBNK4,
+   .end= IRQ_DM355_GPIOBNK4,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM355_GPIOBNK5,
+   .end= IRQ_DM355_GPIOBNK5,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM355_GPIOBNK6,
.end= IRQ_DM355_GPIOBNK6,
.flags  = IORESOURCE_IRQ,
},
-- 
2.19.1

[PATCH 05/12] ARM: davinci: dm644x: define gpio interrupts as separate resources

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the definition of IRQ resources instead of having a single continuous
interrupt range.

Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/dm644x.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 0720da7809a6..de1ec6dc01e9 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -492,6 +492,26 @@ static struct resource dm644_gpio_resources[] = {
},
{   /* interrupt */
.start  = IRQ_GPIOBNK0,
+   .end= IRQ_GPIOBNK0,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_GPIOBNK1,
+   .end= IRQ_GPIOBNK1,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_GPIOBNK2,
+   .end= IRQ_GPIOBNK2,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_GPIOBNK3,
+   .end= IRQ_GPIOBNK3,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_GPIOBNK4,
.end= IRQ_GPIOBNK4,
.flags  = IORESOURCE_IRQ,
},
-- 
2.19.1

Re: [PATCH 1/4] mmc: sdhci-omap: Fix DCRC error handling during tuning

[Faiz Abbas]

Hi Kishon,

On 20/11/18 10:23 AM, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On 19/11/18 4:46 PM, Faiz Abbas wrote:
>> Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
>> disabled DCRC interrupts during tuning. This write to the interrupt
>> enable register gets overwritten in sdhci_prepare_data() and the
>> interrupt is not in fact disabled. Fix this by disabling the interrupt
>> in the host->ier variable.
>>
>> Signed-off-by: Faiz Abbas 
>> ---
>>   drivers/mmc/host/sdhci-omap.c | 7 +++
>>   1 file changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-omap.c
>> b/drivers/mmc/host/sdhci-omap.c
>> index 88347ce78f23..87138067e334 100644
>> --- a/drivers/mmc/host/sdhci-omap.c
>> +++ b/drivers/mmc/host/sdhci-omap.c
>> @@ -290,7 +290,6 @@ static int sdhci_omap_execute_tuning(struct
>> mmc_host *mmc, u32 opcode)
>>   u32 start_window = 0, max_window = 0;
>>   u8 cur_match, prev_match = 0;
>>   u32 length = 0, max_len = 0;
>> -    u32 ier = host->ier;
>>   u32 phase_delay = 0;
>>   int ret = 0;
>>   u32 reg;
>> @@ -317,9 +316,7 @@ static int sdhci_omap_execute_tuning(struct
>> mmc_host *mmc, u32 opcode)
>>    * during the tuning procedure. So disable it during the
>>    * tuning procedure.
>>    */
>> -    ier &= ~SDHCI_INT_DATA_CRC;
>> -    sdhci_writel(host, ier, SDHCI_INT_ENABLE);
>> -    sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
>> +    host->ier &= ~SDHCI_INT_DATA_CRC;
>>     while (phase_delay <= MAX_PHASE_DELAY) {
>>   sdhci_omap_set_dll(omap_host, phase_delay);
>> @@ -366,6 +363,8 @@ static int sdhci_omap_execute_tuning(struct
>> mmc_host *mmc, u32 opcode)
>>     ret:
>>   sdhci_reset(host, SDHCI_RESET_CMD | SDHCI_RESET_DATA);
>> +    /* Reenable forbidden interrupt */
>> +    host->ier |= SDHCI_INT_DATA_CRC;
> 
> It's better to have a backup of host->ier and restore the value here (in
> case DATA_CRC is disabled for other cases).
> 

host->ier is modified everywhere during an mmc request. I would not
expect it to hold its value after so many tuning commands. I can add a
bool to check of DCRC was enabled before and only then re-enable it.

Thanks,
Faiz

[PATCH 02/12] ARM: davinci: dm365: define gpio interrupts as separate resources

[Bartosz Golaszewski]

From: Bartosz Golaszewski 

Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the definition of IRQ resources instead of having a single continuous
interrupt range.

Fixes: eb3744a2dd01 ("gpio: davinci: Do not assume continuous IRQ numbering")
Cc: sta...@vger.kernel.org
Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/mach-davinci/dm365.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index abcf2a5ed89b..42665914166a 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -267,6 +267,41 @@ static struct resource dm365_gpio_resources[] = {
},
{   /* interrupt */
.start  = IRQ_DM365_GPIO0,
+   .end= IRQ_DM365_GPIO0,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM365_GPIO1,
+   .end= IRQ_DM365_GPIO1,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM365_GPIO2,
+   .end= IRQ_DM365_GPIO2,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM365_GPIO3,
+   .end= IRQ_DM365_GPIO3,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM365_GPIO4,
+   .end= IRQ_DM365_GPIO4,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM365_GPIO5,
+   .end= IRQ_DM365_GPIO5,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM365_GPIO6,
+   .end= IRQ_DM365_GPIO6,
+   .flags  = IORESOURCE_IRQ,
+   },
+   {
+   .start  = IRQ_DM365_GPIO7,
.end= IRQ_DM365_GPIO7,
.flags  = IORESOURCE_IRQ,
},
-- 
2.19.1

Re: [PATCH v3] thermal: qoriq: add multiple sensors support

[Daniel Lezcano]

On 21/11/2018 10:16, Andy Tang wrote:
> Hi Daniel,
> 
> Thanks for your explanation. The problem is these two trees are not synced 
> well.
> Let's take our driver(qoriq_thermal.c) for example.
> 
> Git log on Rui's tree next branch:
> 2dfef65 thermal: qoriq: Switch to SPDX identifier
> 1a893a5 thermal: qoriq: Simplify the 'site' variable assignment
> f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register()
> c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures
> 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points()
> 4352844 thermal: qoriq: Add thermal management support
> 
> Git log on linux-soc-thermal tree branch next:
> 6017e2a thermal: qoriq: add i.mx8mq support
> 9b96566 thermal: Convert to using %pOFn instead of device_node.name
> c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures
> 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points()
> 4352844 thermal: qoriq: Add thermal management support
> 
> You can see that the first 2-3 commits on these two tress are different.
> 
> The strange thing is they seems sync well on Linus' tree:
> 0ef7791 Merge branch 'linus' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal
> 6017e2a thermal: qoriq: add i.mx8mq support
> 9b96566 thermal: Convert to using %pOFn instead of device_node.name
> 2dfef65 thermal: qoriq: Switch to SPDX identifier
> 1a893a5 thermal: qoriq: Simplify the 'site' variable assignment
> f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register()
> c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures
> 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points()
> 4352844 thermal: qoriq: Add thermal management support
> 
> Currently my patch was created based on Run's tree, probably I should rebase 
> it to soc tree.
> But whichever tree I use, it can't be merged to Linus' tree without conflict.
> 
> Something I missed?

No.

Eduardo, Rui,

why not create a 'thermal' group ala 'tip' group with a single tree and
two branches:

thermal/next
thermal/fixes

 - Rui takes the core changes.
 - Eduardo takes the SoC changes.

 - Both commit to thermal/next
 - Both commit to thermal/fixes
 - Both merge thermal/fixes into thermal/core as often as possible.

That will help to have a more up to date branch, simplify the patch
submission path and reduce the latency for the merge windows.

If you need help, I can take care of applying the fixes only and merge
them to thermal/next.

That is how the tip subsystem works, Peter Ziljstra, Ingo Molnar, Thomas
Gleixner, have all permissions to commit in the tip tree but they take
care of their subsystems. If one is away for vacations or whatever,
someone else can take over during the absence.





>> -Original Message-
>> From: Daniel Lezcano 
>> Sent: 2018年11月21日 16:44
>> To: Andy Tang ; rui.zh...@intel.com;
>> edubez...@gmail.com
>> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v3] thermal: qoriq: add multiple sensors support
>>
>> On 21/11/2018 02:34, Andy Tang wrote:
>>> Hi all,
>>>
>>> Do you have any comments on this patch?
>>>
>>> I found for our thermal driver(qoriq_thermal.c) there are different
>> between the following two git trees:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
>>> branch: next
>>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.gi
>> t.
>>> branch: next
>>>
>>> Could you please clarify which git tree/branch should I use?
>>
>> SoC changes are submitted against linux-soc-thermal.git.
>>
>> Generic thermal framework are sent against Zhang Rui's tree but it
>> happens sometimes Eduardo pick them also when the changes are related
>> to SoC behavior.
>>
>> However, I agree that can be confusing :)
>>
>> Eduardo, Rui,
>>
>> how about to add a section in the maintainer handbook for the thermal to
>> clarify the expectations and the flow?
>>
 -Original Message-
 From: Andy Tang
 Sent: 2018年11月14日 15:29
 To: rui.zh...@intel.com; daniel.lezc...@linaro.org
 Cc: edubez...@gmail.com; linux...@vger.kernel.org;
 linux-kernel@vger.kernel.org
 Subject: RE: [PATCH v3] thermal: qoriq: add multiple sensors support

 PING.

 BR,
 Andy

> -Original Message-
> From: andy.t...@nxp.com 
> Sent: 2018年10月30日 9:00
> To: rui.zh...@intel.com; daniel.lezc...@linaro.org
> Cc: edubez...@gmail.com; linux...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Andy Tang 
> Subject: [PATCH v3] thermal: qoriq: add multiple sensors support
>
> From: Yuantian Tang 
>
> The QorIQ Layerscape SoC has several thermal sensors but the
>> current
> driver only supports one.
>
> Massage the code to be sensor oriented and allow the support for
> multiple sensors.
>
> Signed-off-by: Yuantian Tang 
> Reviewed-by: Daniel Lezcano 
> ---
> v3:
>>

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

[Finn Thain]

On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:

> The 8520 CIA is almost identical to the 6526 CIA, as used in the C64...
> 

The 6526 CIA datasheet says, "In continuous mode, the timer will count 
from the latched value to zero, generate and interrupt, reload the latched 
value and repeat the procedure continuously."

This suggests that either 0 or N (the latched value) would result from a 
read from the counter immediately following an interrupt. Who can say 
which? Just have to try it. The answer should allow us to avoid the risk 
of a clocksource that jumps forwards and backwards.

-- 

Re: [PATCH v3 2/2] proc: add /proc//arch_state

[Peter Zijlstra]

On Wed, Nov 21, 2018 at 09:19:36AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
> > > Also; you were going to shop around with the other architectures to see
> > > what they want/need for this interface. I see nothing on that.
> > > 
> > I'm open for your suggestion, :)
> 
> Well, we have linux-arch and the various maintainers are also listed in
> MAINTAINERS. Go forth and ask..

Ok, so I googled a wee bit (you could have too).

There's not that many architectures that build big hot chips
(powerpc,x86,arm64,s390) (mips, sparc64 and ia64 are pretty dead I
think, although the Fujitsu Sparc M10 X+/X SIMD looked like it could be
'fun').

Of those, powerpc altivec doesn't seem to be very wide, but you'd have
to ask the power folks. Same for s390 z13.

The Fujitsu/ARM64-SVE stuff looks like it can be big and hot.

And RISC-V has was vector extention, but I don't think anybody is
actually building big hot versions of that just yet.

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

[Geert Uytterhoeven]

Hi Finn,

On Wed, Nov 21, 2018 at 10:47 AM Finn Thain  wrote:
> On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:
> > The 8520 CIA is almost identical to the 6526 CIA, as used in the C64...
>
> The 6526 CIA datasheet says, "In continuous mode, the timer will count
> from the latched value to zero, generate and interrupt, reload the latched
> value and repeat the procedure continuously."

I stand corrected...

> This suggests that either 0 or N (the latched value) would result from a
> read from the counter immediately following an interrupt. Who can say
> which? Just have to try it. The answer should allow us to avoid the risk
> of a clocksource that jumps forwards and backwards.

The code in amiga_gettimeoffset() does:

ticks = hi << 8 | lo;

if (ticks > jiffy_ticks / 2)
/* check for pending interrupt */
if (cia_set_irq(&ciab_base, 0) & CIA_ICR_TA)
offset = 1;

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] regulator: wm8994: Don't use devres for enable GPIOs

[Charles Keepax]

On Wed, Nov 21, 2018 at 10:26:30AM +0100, Marek Szyprowski wrote:
> On 2018-11-20 18:25, Marek Szyprowski wrote:
> > On 2018-11-20 18:01, Charles Keepax wrote:
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:2421
> > regulator_ena_gpio_free+0x70/0xa0
> 
> I've checked a bit more and it looks that the issue is caused by
> gpiod_put() in regulator_ena_gpio_free(). I've removed gpiod_put() call
> from wm8994_ldo_remove(), switched to regulator_register() in
> wm8994_ldo_probe() and added regulator_unregister() in
> wm8994_ldo_remove(). This way the warning is gone. If there is any
> other, simpler way to fix it, let me know. When regulator_register()
> fails, gpiod will be freed only in some cases, depending what caused
> failure. It looks that this needs some clarification...
> 

Ah.. ok, so is perhaps what is happening here that both the
devm_gpio_get and the regualtor_ena_gpio_free are both trying to
free the GPIO? I assume the regulator core does this to handle
the case of shared GPIOs, so presumably the correct fix would
just be to switch from devm_gpiod_get to just plain gpiod_get and
not add the additional gpiod_put in wm8994_ldo_remove, as the
regulator core will handle freeing the GPIO for us.

I will respin the patch and lets see where that gets us to.

Thanks,
Charles

Re: [PATCH 05/14] clocksource/drivers/timer-milbeaut: Add Milbeaut M10V timer

[Daniel Lezcano]

Hi Sugaya,


On 19/11/2018 02:01, Sugaya Taichi wrote:
> Add Milbeaut M10V timer using 32bit timer in peripheral.

Give a better description of the timer as it is new timer introduced.

> Signed-off-by: Sugaya Taichi 
> ---
>  drivers/clocksource/Kconfig  |   8 +++
>  drivers/clocksource/Makefile |   1 +
>  drivers/clocksource/timer-m10v.c | 146 
> +++
>  3 files changed, 155 insertions(+)
>  create mode 100644 drivers/clocksource/timer-m10v.c
> 
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 55c77e4..a278d72 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -638,4 +638,12 @@ config GX6605S_TIMER
>   help
> This option enables support for gx6605s SOC's timer.
>  
> +config M10V_TIMER
> + bool "Milbeaut M10V timer driver" if COMPILE_TEST
> + depends on OF
> + depends on ARM
> + select TIMER_OF
> + help
> +   Enables the support for Milbeaut M10V timer driver.
> +
>  endmenu
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index dd91381..8e908b4 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -55,6 +55,7 @@ obj-$(CONFIG_CLKSRC_TI_32K) += timer-ti-32k.o
>  obj-$(CONFIG_CLKSRC_NPS) += timer-nps.o
>  obj-$(CONFIG_OXNAS_RPS_TIMER)+= timer-oxnas-rps.o
>  obj-$(CONFIG_OWL_TIMER)  += timer-owl.o
> +obj-$(CONFIG_M10V_TIMER) += timer-m10v.o
>  obj-$(CONFIG_SPRD_TIMER) += timer-sprd.o
>  obj-$(CONFIG_NPCM7XX_TIMER)  += timer-npcm7xx.o
>  
> diff --git a/drivers/clocksource/timer-m10v.c 
> b/drivers/clocksource/timer-m10v.c
> new file mode 100644
> index 000..ff97c23
> --- /dev/null
> +++ b/drivers/clocksource/timer-m10v.c
> @@ -0,0 +1,146 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Socionext Inc.
> + */
> +
> +#include 

--->

> +#include 

It is included from timer-of.h

<---

> +#include 
> +#include 
> +#include 

--->

> +#include 
> +#include 
> +#include 
> +#include 

Those are not needed IMO.

<-


> +#include "timer-of.h"
> +
> +#define FSL_TMR_TMCSR_OFS0x0
> +#define FSL_TMR_TMR_OFS  0x4
> +#define FSL_TMR_TMRLR1_OFS   0x8
> +#define FSL_TMR_TMRLR2_OFS   0xc
> +#define FSL_RMT_REGSZPCH 0x10
> +
> +#define FSL_TMR_TMCSR_OUTL   BIT(5)
> +#define FSL_TMR_TMCSR_RELD   BIT(4)
> +#define FSL_TMR_TMCSR_INTE   BIT(3)
> +#define FSL_TMR_TMCSR_UF BIT(2)
> +#define FSL_TMR_TMCSR_CNTE   BIT(1)
> +#define FSL_TMR_TMCSR_TRGBIT(0)
> +
> +#define FSL_TMR_TMCSR_CSL_DIV2   0
> +#define FSL_TMR_TMCSR_CSLBIT(10)
> +
> +#define M10V_TIMER_RATING500
> +
> +static irqreturn_t m10v_timer_interrupt(int irq, void *dev_id)
> +{
> + struct clock_event_device *clk = dev_id;
> + struct timer_of *to = to_timer_of(clk);
> + u32 val;
> +
> + val = readl_relaxed(timer_of_base(to) + FSL_TMR_TMCSR_OFS);
> + val &= ~FSL_TMR_TMCSR_UF;
> + writel_relaxed(val, timer_of_base(to) + FSL_TMR_TMCSR_OFS);
> +
> + clk->event_handler(clk);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int m10v_set_state_periodic(struct clock_event_device *clk)
> +{
> + struct timer_of *to = to_timer_of(clk);
> + u32 val = (FSL_TMR_TMCSR_CSL_DIV2 * FSL_TMR_TMCSR_CSL);

FSL_TMR_TMCSR_CSL_DIV2 is zero, so val is always zero.

> + writel_relaxed(val, timer_of_base(to) + FSL_TMR_TMCSR_OFS);
> +
> + writel_relaxed(to->of_clk.period, timer_of_base(to) +
> + FSL_TMR_TMRLR1_OFS);
> + val |= FSL_TMR_TMCSR_RELD | FSL_TMR_TMCSR_CNTE |
> + FSL_TMR_TMCSR_TRG | FSL_TMR_TMCSR_INTE;
> + writel_relaxed(val, timer_of_base(to) + FSL_TMR_TMCSR_OFS);
> + return 0;
> +}
> +
> +static int m10v_set_state_oneshot(struct clock_event_device *clk)
> +{
> + struct timer_of *to = to_timer_of(clk);
> + u32 val = (FSL_TMR_TMCSR_CSL_DIV2 * FSL_TMR_TMCSR_CSL);
> +
> + writel_relaxed(val, timer_of_base(to) + FSL_TMR_TMCSR_OFS);
> + return 0;
> +}
> +
> +static int m10v_clkevt_next_event(unsigned long event,
> +struct clock_event_device *clk)
> +{
> + struct timer_of *to = to_timer_of(clk);
> +
> + writel_relaxed(event, timer_of_base(to) + FSL_TMR_TMRLR1_OFS);
> + writel_relaxed((FSL_TMR_TMCSR_CSL_DIV2 * FSL_TMR_TMCSR_CSL) |

Same comment here.

> + FSL_TMR_TMCSR_CNTE | FSL_TMR_TMCSR_INTE |
> + FSL_TMR_TMCSR_TRG, timer_of_base(to) +
> + FSL_TMR_TMCSR_OFS);
> + return 0;
> +}
> +
> +static int m10v_config_clock_source(struct timer_of *to)
> +{
> + writel_relaxed(0, timer_of_base(to) + FSL_TMR_TMCSR_OFS);
> + writel_relaxed(~0, timer_of_base(to) + FSL_TMR_TMR_OFS);
> + writel_relaxed(~0, timer_of_base(to) + FSL_TMR_TMRLR1_OFS);
> + writel_relaxed(~0, timer_of_base(to) + FSL_TMR_TMRLR2_OFS);
> + writel_relaxed(BIT(4) | B

[PATCH v2] x86: modernize sync_bitops.h

[Jan Beulich]

Add missing insn suffixes and use rmwcc.h just like was (more or less)
recently done for bitops.h as well.

Signed-off-by: Jan Beulich 
---
v2: Re-base over rmwcc.h changes.
---
 arch/x86/include/asm/sync_bitops.h |   31 +--
 1 file changed, 9 insertions(+), 22 deletions(-)

--- 4.20-rc3/arch/x86/include/asm/sync_bitops.h
+++ 4.20-rc3-x86-sync-bitops-insn-suffixes/arch/x86/include/asm/sync_bitops.h
@@ -14,6 +14,8 @@
  * bit 0 is the LSB of addr; bit 32 is the LSB of (addr+1).
  */
 
+#include 
+
 #define ADDR (*(volatile long *)addr)
 
 /**
@@ -29,7 +31,7 @@
  */
 static inline void sync_set_bit(long nr, volatile unsigned long *addr)
 {
-   asm volatile("lock; bts %1,%0"
+   asm volatile("lock; " __ASM_SIZE(bts) " %1,%0"
 : "+m" (ADDR)
 : "Ir" (nr)
 : "memory");
@@ -47,7 +49,7 @@ static inline void sync_set_bit(long nr,
  */
 static inline void sync_clear_bit(long nr, volatile unsigned long *addr)
 {
-   asm volatile("lock; btr %1,%0"
+   asm volatile("lock; " __ASM_SIZE(btr) " %1,%0"
 : "+m" (ADDR)
 : "Ir" (nr)
 : "memory");
@@ -64,7 +66,7 @@ static inline void sync_clear_bit(long n
  */
 static inline void sync_change_bit(long nr, volatile unsigned long *addr)
 {
-   asm volatile("lock; btc %1,%0"
+   asm volatile("lock; " __ASM_SIZE(btc) " %1,%0"
 : "+m" (ADDR)
 : "Ir" (nr)
 : "memory");
@@ -78,14 +80,9 @@ static inline void sync_change_bit(long
  * This operation is atomic and cannot be reordered.
  * It also implies a memory barrier.
  */
-static inline int sync_test_and_set_bit(long nr, volatile unsigned long *addr)
+static inline bool sync_test_and_set_bit(long nr, volatile unsigned long *addr)
 {
-   unsigned char oldbit;
-
-   asm volatile("lock; bts %2,%1\n\tsetc %0"
-: "=qm" (oldbit), "+m" (ADDR)
-: "Ir" (nr) : "memory");
-   return oldbit;
+   return GEN_BINARY_RMWcc("lock; " __ASM_SIZE(bts), *addr, c, "Ir", nr);
 }
 
 /**
@@ -98,12 +95,7 @@ static inline int sync_test_and_set_bit(
  */
 static inline int sync_test_and_clear_bit(long nr, volatile unsigned long 
*addr)
 {
-   unsigned char oldbit;
-
-   asm volatile("lock; btr %2,%1\n\tsetc %0"
-: "=qm" (oldbit), "+m" (ADDR)
-: "Ir" (nr) : "memory");
-   return oldbit;
+   return GEN_BINARY_RMWcc("lock; " __ASM_SIZE(btr), *addr, c, "Ir", nr);
 }
 
 /**
@@ -116,12 +108,7 @@ static inline int sync_test_and_clear_bi
  */
 static inline int sync_test_and_change_bit(long nr, volatile unsigned long 
*addr)
 {
-   unsigned char oldbit;
-
-   asm volatile("lock; btc %2,%1\n\tsetc %0"
-: "=qm" (oldbit), "+m" (ADDR)
-: "Ir" (nr) : "memory");
-   return oldbit;
+   return GEN_BINARY_RMWcc("lock; " __ASM_SIZE(btc), *addr, c, "Ir", nr);
 }
 
 #define sync_test_bit(nr, addr) test_bit(nr, addr)

Re: BUG: unable to handle kernel NULL pointer dereference in write_port

[Kyungtae Kim]

Thank you for your reply.
But I think this kind of crash can occur in real PC as well, and I'm
just thinking of some way to stop it in the first place (if possible).
because malicious users can use this, so as to make the whole system
(kernel) work incorrectly.

Thanks,
Kyungtae

Re: [PATCH] staging: greybus: Parenthesis alignment

[Joe Perches]

On Wed, 2018-11-21 at 15:58 +1100, NeilBrown wrote:
> On Sun, Nov 18 2018, Joe Perches wrote:
> 
> > On Sun, 2018-11-18 at 20:28 +0100, Cristian Sicilia wrote:
> > > Some parameters are aligned with parentheses.
> > > Some parentheses are opened at end of line.
> > 
> > Given the very long identifier lengths, I wouldn't
> > consider many of these appropriate.
> > 
> > 80 column line lengths and long identifiers don't
> > play well together.
> > 
> > > diff --git a/drivers/staging/greybus/audio_codec.c 
> > > b/drivers/staging/greybus/audio_codec.c
> > 
> > []
> > > @@ -70,7 +70,7 @@ static int gbaudio_module_enable_tx(struct 
> > > gbaudio_codec_info *codec,
> > >   i2s_port = 0;   /* fixed for now */
> > >   cportid = data->connection->hd_cport_id;
> > >   ret = gb_audio_apbridgea_register_cport(data->connection,
> > > - i2s_port, cportid,
> > > + i2s_port, cportid,
> > >   AUDIO_APBRIDGEA_DIRECTION_TX);
> 
> My preferred formatting in this situation is
> 
>   ret = gb_audio_apbridgea_register_cport(
>   data->connection,
>   i2s_port, cportid,
>   AUDIO_APBRIDGEA_DIRECTION_TX);

Odd mixing of spacing and tabs in your example here.

> but checkpatch doesn't like the '(' at the end of the line.
> Do you know why that is?

Generally to avoid function declarations like

static int foo(
int bar,
int baz)
{
...
}

But this also is meant for function calls.

And this obviously does not work well with excessively
long identifiers where a statement or declaration could
not fit in 80 columns.

Perhaps some logic could be added to suggest use of
shorter than some specific longish identifier length.

cheers, Joe

[PATCH v2] regulator: wm8994: Don't use devres for enable GPIOs

[Charles Keepax]

The regulator core takes over managing the lifetime of the enable GPIO
once the regulator is registered. As such we shouldn't register the
enable GPIO using devm, or it will be freed twice.

Reported-by: Marek Szyprowski 
Signed-off-by: Charles Keepax 
---

Again only build tested.

Thanks,
Charles

 drivers/regulator/wm8994-regulator.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/wm8994-regulator.c 
b/drivers/regulator/wm8994-regulator.c
index d7fec533c4032..46e6b4ee1491a 100644
--- a/drivers/regulator/wm8994-regulator.c
+++ b/drivers/regulator/wm8994-regulator.c
@@ -147,11 +147,14 @@ static int wm8994_ldo_probe(struct platform_device *pdev)
config.regmap = wm8994->regmap;
config.init_data = &ldo->init_data;
 
-   /* Look up LDO enable GPIO from the parent device node */
-   gpiod = devm_gpiod_get_optional(pdev->dev.parent,
-   id ? "wlf,ldo2ena" : "wlf,ldo1ena",
-   GPIOD_OUT_LOW |
-   GPIOD_FLAGS_BIT_NONEXCLUSIVE);
+   /*
+* Look up LDO enable GPIO from the parent device node, we don't
+* use devm because the regulator core will free the GPIO
+*/
+   gpiod = gpiod_get_optional(pdev->dev.parent,
+  id ? "wlf,ldo2ena" : "wlf,ldo1ena",
+  GPIOD_OUT_LOW |
+  GPIOD_FLAGS_BIT_NONEXCLUSIVE);
if (IS_ERR(gpiod))
return PTR_ERR(gpiod);
config.ena_gpiod = gpiod;
@@ -184,6 +187,7 @@ static int wm8994_ldo_probe(struct platform_device *pdev)
return 0;
 
 err:
+   gpiod_put(gpiod);
return ret;
 }
 
-- 
2.11.0

[PATCH 1/4] mm, page_alloc: Spread allocations across zones before introducing fragmentation

[Mel Gorman]

The page allocator zone lists are iterated based on the watermarks
of each zone which does not take anti-fragmentation into account. On
x86, node 0 may have multiple zones while other nodes have one zone. A
consequence is that tasks running on node 0 may fragment ZONE_NORMAL even
though ZONE_DMA32 has plenty of free memory. This patch special cases
the allocator fast path such that it'll try an allocation from a lower
local zone before fragmenting a higher zone. In this case, stealing of
pageblocks or orders larger than a pageblock are still allowed in the
fast path as they are uninteresting from a fragmentation point of view.

This was evaluated using a benchmark designed to fragment memory
before attempting THPs.  It's implemented in mmtests as the following
configurations

configs/config-global-dhp__workload_thpfioscale
configs/config-global-dhp__workload_thpfioscale-defrag
configs/config-global-dhp__workload_thpfioscale-madvhugepage

e.g. from mmtests
./run-mmtests.sh --run-monitor --config 
configs/config-global-dhp__workload_thpfioscale test-run-1

The broad details of the workload are as follows;

1. Create an XFS filesystem (not specified in the configuration but done
   as part of the testing for this patch)
2. Start 4 fio threads that write a number of 64K files inefficiently.
   Inefficiently means that files are created on first access and not
   created in advance (fio parameterr create_on_open=1) and fallocate
   is not used (fallocate=none). With multiple IO issuers this creates
   a mix of slab and page cache allocations over time. The total size
   of the files is 150% physical memory so that the slabs and page cache
   pages get mixed
3. Warm up a number of fio read-only threads accessing the same files
   created in step 2. This part runs for the same length of time it
   took to create the files. It'll fault back in old data and further
   interleave slab and page cache allocations. As it's now low on
   memory due to step 2, fragmentation occurs as pageblocks get
   stolen.
4. While step 3 is still running, start a process that tries to allocate
   75% of memory as huge pages with a number of threads. The number of
   threads is based on a (NR_CPUS_SOCKET - NR_FIO_THREADS)/4 to avoid THP
   threads contending with fio, any other threads or forcing cross-NUMA
   scheduling. Note that the test has not been used on a machine with less
   than 8 cores. The benchmark records whether huge pages were allocated
   and what the fault latency was in microseconds
5. Measure the number of events potentially causing external fragmentation,
   the fault latency and the huge page allocation success rate.
6. Cleanup

Note that due to the use of IO and page cache that this benchmark is not
suitable for running on large machines where the time to fragment memory
may be excessive. Also note that while this is one mix that generates
fragmentation that it's not the only mix that generates fragmentation.
Differences in workload that are more slab-intensive or whether SLUB is
used with high-order pages may yield different results.

When the page allocator fragments memory, it records the event using the
mm_page_alloc_extfrag event. If the fallback_order is smaller than a
pageblock order (order-9 on 64-bit x86) then it's considered an event
that may cause external fragmentation issues in the future. Hence, the
primary metric here is the number of external fragmentation events that
occur with order < 9. The secondary metric is allocation latency and huge
page allocation success rates but note that differences in latencies and
what the success rate also can affect the number of external fragmentation
event which is why it's a secondary metric.

1-socket Skylake machine
config-global-dhp__workload_thpfioscale XFS (no special madvise)
4 fio threads, 1 THP allocating thread
--

4.20-rc1 extfrag events < order 9:  1023463
4.20-rc1+patch:  358574 (65% reduction)

thpfioscale Fault Latencies
   4.20.0-rc1 4.20.0-rc1
  vanilla   lowzone-v2r4
Min   fault-base-1  588.00 (   0.00%)  557.00 (   5.27%)
Min   fault-huge-10.00 (   0.00%)0.00 (   0.00%)
Amean fault-base-1  663.58 (   0.00%)  663.65 (  -0.01%)
Amean fault-huge-10.00 (   0.00%)0.00 (   0.00%)

  4.20.0-rc1 4.20.0-rc1
 vanilla   lowzone-v2r4
Percentage huge-10.00 (   0.00%)0.00 (   0.00%)

Fault latencies are reduced while allocation success rates remain at zero
asthis configuration does not make any heavy effort to allocate THP and
fio is heavily active at the time and filling memory.  However, a 65%
reduction of serious fragmentation events reduces the changes of external
fragmentation being a problem in the future.

1-socket Skylake machine
global-dhp__workload

[PATCH 3/4] mm: Reclaim small amounts of memory when an external fragmentation event occurs

[Mel Gorman]

An external fragmentation event was previously described as

When the page allocator fragments memory, it records the event using
the mm_page_alloc_extfrag event. If the fallback_order is smaller
than a pageblock order (order-9 on 64-bit x86) then it's considered
an event that will cause external fragmentation issues in the future.

The kernel reduces the probability of such events by increasing the
watermark sizes by calling set_recommended_min_free_kbytes early in the
lifetime of the system. This works reasonably well in general but if there
are enough sparsely populated pageblocks then the problem can still occur
as enough memory is free overall and kswapd stays asleep.

This patch introduces a watermark_boost_factor sysctl that allows a
zone watermark to be temporarily boosted when an external fragmentation
causing events occurs. The boosting will stall allocations that would
decrease free memory below the boosted low watermark and kswapd is woken
unconditionally to reclaim an amount of memory relative to the size
of the high watermark and the watermark_boost_factor until the boost
is cleared. When kswapd finishes, it wakes kcompactd at the pageblock
order to clean some of the pageblocks that may have been affected by the
fragmentation event. kswapd avoids any writeback or swap from reclaim
context during this operation to avoid excessive system disruption in
the name of fragmentation avoidance. Care is taken so that kswapd will
do normal reclaim work if the system is really low on memory.

This was evaluated using the same workloads as "mm, page_alloc: Spread
allocations across zones before introducing fragmentation".

1-socket Skylake machine
config-global-dhp__workload_thpfioscale XFS (no special madvise)
4 fio threads, 1 THP allocating thread
--

4.20-rc1 extfrag events < order 9:  1023463
4.20-rc1+patch:  358574 (65% reduction)
4.20-rc1+patch1-3:19274 (98% reduction)

   4.20.0-rc1 4.20.0-rc1
 lowzone-v2r4 boost-v2r4
Amean fault-base-1  663.65 (   0.00%)  659.85 *   0.57%*
Amean fault-huge-10.00 (   0.00%)  172.19 * -99.00%*

  4.20.0-rc1 4.20.0-rc1
lowzone-v2r4 boost-v2r4
Percentage huge-10.00 (   0.00%)1.68 ( 100.00%)

Note that external fragmentation causing events are massively reduced
by this path whether in comparison to the previous kernel or the vanilla
kernel. The fault latency for huge pages appears to be increased but that
is only because THP allocations were successful with the patch applied.

1-socket Skylake machine
global-dhp__workload_thpfioscale-madvhugepage-xfs (MADV_HUGEPAGE)
-

4.20-rc1 extfrag events < order 9:  342549
4.20-rc1+patch: 337890 ( 1% reduction)
4.20-rc1+patch1-3:   12801 (96% reduction)

thpfioscale Fault Latencies
thpfioscale Fault Latencies
   4.20.0-rc1 4.20.0-rc1
 lowzone-v2r4 boost-v2r4
Amean fault-base-1 1531.37 (   0.00%) 1578.91 (  -3.10%)
Amean fault-huge-1 1160.95 (   0.00%) 1090.23 *   6.09%*

  4.20.0-rc1 4.20.0-rc1
lowzone-v2r4 boost-v2r4
Percentage huge-1   78.97 (   0.00%)   82.59 (   4.58%)

As before, massive reduction in external fragmentation events, some jitter
on latencies and an increase in THP allocation success rates.

2-socket Haswell machine
config-global-dhp__workload_thpfioscale XFS (no special madvise)
4 fio threads, 5 THP allocating threads


4.20-rc1 extfrag events < order 9:  209820
4.20-rc1+patch: 185923 (11% reduction)
4.20-rc1+patch1-3:   11240 (95% reduction)

   4.20.0-rc1 4.20.0-rc1
 lowzone-v2r4 boost-v2r4
Amean fault-base-5 1334.99 (   0.00%) 1395.28 (  -4.52%)
Amean fault-huge-5 2428.43 (   0.00%)  539.69 (  77.78%)

  4.20.0-rc1 4.20.0-rc1
lowzone-v2r4 boost-v2r4
Percentage huge-51.13 (   0.00%)0.53 ( -52.94%)

This is an illustration of why latencies are not the primary metric.
There is a 95% reduction in fragmentation causing events but the
huge page latencies look fantastic until you account for the fact it
might be because the success rate was lower. Given how low it was
initially, this is partially down to luck.

2-socket Haswell machine
global-dhp__workload_thpfioscale-madvhugepage-xfs (MADV_HUGEPAGE)
-

[PATCH 4/4] mm: Stall movable allocations until kswapd progresses during serious external fragmentation event

[Mel Gorman]

An event that potentially causes external fragmentation problems has
already been described but there are degrees of severity.  A "serious"
event is defined as one that steals a contiguous range of pages of an order
lower than fragment_stall_order (PAGE_ALLOC_COSTLY_ORDER by default). If a
movable allocation request that is allowed to sleep needs to steal a small
block then it schedules until kswapd makes progress or a timeout passes.
The watermarks are also boosted slightly faster so that kswapd makes
greater effort to reclaim enough pages to avoid the fragmentation event.

This stall is not guaranteed to avoid serious fragmentation events.
If memory pressure is high enough, the pages freed by kswapd may be
reallocated or the free pages may not be in pageblocks that contain
only movable pages. Furthermore an allocation request that cannot stall
(e.g. atomic allocations) or unmovable/reclaimable allocations will still
proceed without stalling.

The worst-case scenario for stalling is a combination of both high memory
pressure where kswapd is having trouble keeping free pages over the
pfmemalloc_reserve and movable allocations are fragmenting memory. In this
case, an allocation request may sleep for longer. There are both vmstats
to identify stalls are happening and a tracepoint to quantify what the
stall durations are. Note that the granularity of the stall detection is
a jiffy so the delay accounting is not precise.

1-socket Skylake machine
config-global-dhp__workload_thpfioscale XFS (no special madvise)
4 fio threads, 1 THP allocating thread
--

4.20-rc1 extfrag events < order 9:  1023463
4.20-rc1+patch:  358574 (65% reduction)
4.20-rc1+patch1-3:19274 (98% reduction)
4.20-rc1+patch1-4: 1094 (99.9% reduction)

   4.20.0-rc1 4.20.0-rc1
   boost-v3r1 stall-v3r1
Amean fault-base-1  659.85 (   0.00%)  658.74 (   0.17%)
Amean fault-huge-1  172.19 (   0.00%)  168.00 (   2.43%)

thpfioscale Percentage Faults Huge
  4.20.0-rc1 4.20.0-rc1
  boost-v3r1 stall-v3r1
Percentage huge-11.68 (   0.00%)0.88 ( -47.52%)

Fragmentation events are now reduced to negligible levels.

The latencies and allocation success rates are roughly similar.  Over the
course of 16 minutes, there were 52 stalls due to fragmentation avoidance
with a total stall time of 0.2 seconds.

1-socket Skylake machine
global-dhp__workload_thpfioscale-madvhugepage-xfs (MADV_HUGEPAGE)
-

4.20-rc1 extfrag events < order 9:  342549
4.20-rc1+patch: 337890 ( 1% reduction)
4.20-rc1+patch1-3:   12801 (96% reduction)
4.20-rc1+patch1-4:1112 (99.7% reduction)

   4.20.0-rc1 4.20.0-rc1
   boost-v3r1 stall-v3r1
Amean fault-base-1 1578.91 (   0.00%) 1647.00 (  -4.31%)
Amean fault-huge-1 1090.23 (   0.00%)  559.31 *  48.70%*

  4.20.0-rc1 4.20.0-rc1
  boost-v3r1 stall-v3r1
Percentage huge-1   82.59 (   0.00%)   99.98 (  21.05%)

The fragmentation events were reduced and the latencies are good. This
is a big difference between v2 and v3 of the series as v2 had stalls
that reached the timeout of HZ/10 where as a timeout of HZ/50 has better
latencies without compromising on fragmentation events or allocation success 
rates.

There were 219 stalls over the course of 16 minutes for a total stall
time of roughly 1 second (as opposed to 11 seconds with HZ/10). The
distribution of stalls is as follows

209 4000
  1 8000
  9 2

This shows the majority of stalls were for just one jiffie.

2-socket Haswell machine
config-global-dhp__workload_thpfioscale XFS (no special madvise)
4 fio threads, 5 THP allocating threads


4.20-rc1 extfrag events < order 9:  209820
4.20-rc1+patch: 185923 (11% reduction)
4.20-rc1+patch1-3:   11240 (95% reduction)
4.20-rc1+patch1-4:8709 (96% reduction)

   4.20.0-rc1 4.20.0-rc1
   boost-v3r1 stall-v3r1
Amean fault-base-5 1395.28 (   0.00%) 1335.23 (   4.30%)
Amean fault-huge-5  539.69 (   0.00%)  614.88 * -13.93%*

  4.20.0-rc1 4.20.0-rc1
  boost-v3r1 stall-v3r1
Percentage huge-50.53 (   0.00%)2.16 ( 306.25%)

There is a slight reduction in fragmentation events but it's slight
enough that it may be du

[PATCH 2/4] mm: Move zone watermark accesses behind an accessor

[Mel Gorman]

This is a preparation patch only, no functional change.

Signed-off-by: Mel Gorman 
---
 include/linux/mmzone.h |  9 +
 mm/compaction.c|  2 +-
 mm/page_alloc.c| 12 ++--
 3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 847705a6d0ec..e43e8e79db99 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -269,9 +269,10 @@ enum zone_watermarks {
NR_WMARK
 };
 
-#define min_wmark_pages(z) (z->watermark[WMARK_MIN])
-#define low_wmark_pages(z) (z->watermark[WMARK_LOW])
-#define high_wmark_pages(z) (z->watermark[WMARK_HIGH])
+#define min_wmark_pages(z) (z->_watermark[WMARK_MIN])
+#define low_wmark_pages(z) (z->_watermark[WMARK_LOW])
+#define high_wmark_pages(z) (z->_watermark[WMARK_HIGH])
+#define wmark_pages(z, i) (z->_watermark[i])
 
 struct per_cpu_pages {
int count;  /* number of pages in the list */
@@ -362,7 +363,7 @@ struct zone {
/* Read-mostly fields */
 
/* zone watermarks, access with *_wmark_pages(zone) macros */
-   unsigned long watermark[NR_WMARK];
+   unsigned long _watermark[NR_WMARK];
 
unsigned long nr_reserved_highatomic;
 
diff --git a/mm/compaction.c b/mm/compaction.c
index 7c607479de4a..ef29490b0f46 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1431,7 +1431,7 @@ static enum compact_result __compaction_suitable(struct 
zone *zone, int order,
if (is_via_compact_memory(order))
return COMPACT_CONTINUE;
 
-   watermark = zone->watermark[alloc_flags & ALLOC_WMARK_MASK];
+   watermark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK);
/*
 * If watermarks for high-order allocation are already met, there
 * should be no need for compaction at all.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 828fcccbc5c5..9ea2d828d20c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3370,7 +3370,7 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned int 
order, int alloc_flags,
}
}
 
-   mark = zone->watermark[alloc_flags & ALLOC_WMARK_MASK];
+   mark = wmark_pages(zone, alloc_flags & ALLOC_WMARK_MASK);
if (!zone_watermark_fast(zone, order, mark,
   ac_classzone_idx(ac), alloc_flags)) {
int ret;
@@ -4790,7 +4790,7 @@ long si_mem_available(void)
pages[lru] = global_node_page_state(NR_LRU_BASE + lru);
 
for_each_zone(zone)
-   wmark_low += zone->watermark[WMARK_LOW];
+   wmark_low += low_wmark_pages(zone);
 
/*
 * Estimate the amount of memory available for userspace allocations,
@@ -7416,13 +7416,13 @@ static void __setup_per_zone_wmarks(void)
 
min_pages = zone->managed_pages / 1024;
min_pages = clamp(min_pages, SWAP_CLUSTER_MAX, 128UL);
-   zone->watermark[WMARK_MIN] = min_pages;
+   zone->_watermark[WMARK_MIN] = min_pages;
} else {
/*
 * If it's a lowmem zone, reserve a number of pages
 * proportionate to the zone's size.
 */
-   zone->watermark[WMARK_MIN] = tmp;
+   zone->_watermark[WMARK_MIN] = tmp;
}
 
/*
@@ -7434,8 +7434,8 @@ static void __setup_per_zone_wmarks(void)
mult_frac(zone->managed_pages,
  watermark_scale_factor, 1));
 
-   zone->watermark[WMARK_LOW]  = min_wmark_pages(zone) + tmp;
-   zone->watermark[WMARK_HIGH] = min_wmark_pages(zone) + tmp * 2;
+   zone->_watermark[WMARK_LOW]  = min_wmark_pages(zone) + tmp;
+   zone->_watermark[WMARK_HIGH] = min_wmark_pages(zone) + tmp * 2;
 
spin_unlock_irqrestore(&zone->lock, flags);
}
-- 
2.16.4

[PATCH 0/4] Fragmentation avoidance improvements v4

[Mel Gorman]

No major change from v3 really, mostly resending to see if there is any
review reaction. It's rebased but a partial test indicated that the
behaviour is similar to the previous baseline

Changelog since v3
o Rebase to 4.20-rc3
o Remove a stupid warning from the last patch

Changelog since v2
o Drop patch 5 as it was borderline
o Decrease timeout when stalling on fragmentation events

Changelog since v1
o Rebase to v4.20-rc1 for the THP __GFP_THISNODE patch in particular
o Add tracepoint to record fragmentation stall durations
o Add vmstat event to record that a fragmentation stall occurred
o Stalls now alter watermark boosting
o Stalls occur only when the allocation is about to fail

It has been noted before that fragmentation avoidance (aka
anti-fragmentation) is not perfect. Given sufficient time or an adverse
workload, memory gets fragmented and the long-term success of high-order
allocations degrades. This series defines an adverse workload, a definition
of external fragmentation events (including serious) ones and a series
that reduces the level of those fragmentation events.

The details of the workload and the consequences are described in more
detail in the changelogs. However, from patch 1, this is a high-level
summary of the adverse workload. The exact details are found in the
mmtests implementation.

The broad details of the workload are as follows;

1. Create an XFS filesystem (not specified in the configuration but done
   as part of the testing for this patch)
2. Start 4 fio threads that write a number of 64K files inefficiently.
   Inefficiently means that files are created on first access and not
   created in advance (fio parameterr create_on_open=1) and fallocate
   is not used (fallocate=none). With multiple IO issuers this creates
   a mix of slab and page cache allocations over time. The total size
   of the files is 150% physical memory so that the slabs and page cache
   pages get mixed
3. Warm up a number of fio read-only threads accessing the same files
   created in step 2. This part runs for the same length of time it
   took to create the files. It'll fault back in old data and further
   interleave slab and page cache allocations. As it's now low on
   memory due to step 2, fragmentation occurs as pageblocks get
   stolen.
4. While step 3 is still running, start a process that tries to allocate
   75% of memory as huge pages with a number of threads. The number of
   threads is based on a (NR_CPUS_SOCKET - NR_FIO_THREADS)/4 to avoid THP
   threads contending with fio, any other threads or forcing cross-NUMA
   scheduling. Note that the test has not been used on a machine with less
   than 8 cores. The benchmark records whether huge pages were allocated
   and what the fault latency was in microseconds
5. Measure the number of events potentially causing external fragmentation,
   the fault latency and the huge page allocation success rate.
6. Cleanup

Overall the series reduces external fragmentation causing events by over 95%
on 1 and 2 socket machines, which in turn impacts high-order allocation
success rates over the long term. There are differences in latencies and
high-order allocation success rates. Latencies are a mixed bag as they
are vulnerable to exact system state and whether allocations succeeded so
they are treated as a secondary metric.

Patch 1 uses lower zones if they are populated and have free memory
instead of fragmenting a higher zone. It's special cased to
handle a Normal->DMA32 fallback with the reasons explained
in the changelog.

Patch 2+3 boosts watermarks temporarily when an external fragmentation
event occurs. kswapd wakes to reclaim a small amount of old memory
and then wakes kcompactd on completion to recover the system
slightly. This introduces some overhead in the slowpath. The level
of boosting can be tuned or disabled depending on the tolerance
for fragmentation vs allocation latency.

Patch 4 is more heavy handed. In the event of a movable allocation
request that can stall, it'll wake kswapd as in patch 3.  However,
if the expected fragmentation event is serious then the request
will stall briefly on pfmemalloc_wait until kswapd completes
light reclaim work and retry the allocation without stalling.
This can avoid the fragmentation event entirely in some cases.
The definition of a serious fragmentation event can be tuned
or disabled.

The bulk of the improvement in fragmentation avoidance is from patches
1-3 (94-97% reduction in fragmentation events for an adverse workload on
both a 1-socket and 2-socket machine). The primary benefit of patch 4 is
the increase in THP success rates and the fact it reduces fragmentation
events to almost negligible levels with the option of eliminating them.

 Documentation/sysctl/vm.txt   |  42 
 include/linux/mm.h|   2 +
 include/linux/mmzone.h|  14 ++-
 include/linux

[PATCH 1/3] perf/x86/intel: Move branch tracing setup to intel object

[Jiri Olsa]

Moving branch tracing setup to Intel core object into separate
intel_pmu_bts_config function, because it's Intel specific.

Suggested-by: Peter Zijlstra 
Signed-off-by: Jiri Olsa 
---
 arch/x86/events/core.c   | 20 --
 arch/x86/events/intel/core.c | 41 +++-
 2 files changed, 40 insertions(+), 21 deletions(-)

diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 106911b603bd..374a19712e20 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -438,26 +438,6 @@ int x86_setup_perfctr(struct perf_event *event)
if (config == -1LL)
return -EINVAL;
 
-   /*
-* Branch tracing:
-*/
-   if (attr->config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS &&
-   !attr->freq && hwc->sample_period == 1) {
-   /* BTS is not supported by this architecture. */
-   if (!x86_pmu.bts_active)
-   return -EOPNOTSUPP;
-
-   /* BTS is currently only allowed for user-mode. */
-   if (!attr->exclude_kernel)
-   return -EOPNOTSUPP;
-
-   /* disallow bts if conflicting events are present */
-   if (x86_add_exclusive(x86_lbr_exclusive_lbr))
-   return -EBUSY;
-
-   event->destroy = hw_perf_lbr_event_destroy;
-   }
-
hwc->config |= config;
 
return 0;
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 273c62e81546..8c1efb4d8f47 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3098,10 +3098,49 @@ static unsigned long intel_pmu_large_pebs_flags(struct 
perf_event *event)
return flags;
 }
 
+static int intel_pmu_bts_config(struct perf_event *event)
+{
+   struct perf_event_attr *attr = &event->attr;
+   struct hw_perf_event *hwc = &event->hw;
+
+   if (attr->config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS &&
+   !attr->freq && hwc->sample_period == 1) {
+   /* BTS is not supported by this architecture. */
+   if (!x86_pmu.bts_active)
+   return -EOPNOTSUPP;
+
+   /* BTS is currently only allowed for user-mode. */
+   if (!attr->exclude_kernel)
+   return -EOPNOTSUPP;
+
+   /* disallow bts if conflicting events are present */
+   if (x86_add_exclusive(x86_lbr_exclusive_lbr))
+   return -EBUSY;
+
+   event->destroy = hw_perf_lbr_event_destroy;
+   }
+
+   return 0;
+}
+
+static int core_pmu_hw_config(struct perf_event *event)
+{
+   int ret = x86_pmu_hw_config(event);
+
+   if (ret)
+   return ret;
+
+   return intel_pmu_bts_config(event);
+}
+
 static int intel_pmu_hw_config(struct perf_event *event)
 {
int ret = x86_pmu_hw_config(event);
 
+   if (ret)
+   return ret;
+
+   ret = intel_pmu_bts_config(event);
if (ret)
return ret;
 
@@ -3596,7 +3635,7 @@ static __initconst const struct x86_pmu core_pmu = {
.enable_all = core_pmu_enable_all,
.enable = core_pmu_enable_event,
.disable= x86_pmu_disable_event,
-   .hw_config  = x86_pmu_hw_config,
+   .hw_config  = core_pmu_hw_config,
.schedule_events= x86_schedule_events,
.eventsel   = MSR_ARCH_PERFMON_EVENTSEL0,
.perfctr= MSR_ARCH_PERFMON_PERFCTR0,
-- 
2.17.2

[PATCH 2/3] perf/x86/intel: Add generic branch tracing check to intel_pmu_has_bts

[Jiri Olsa]

Currently we check the branch tracing only by checking for the
PERF_COUNT_HW_BRANCH_INSTRUCTIONS event of PERF_TYPE_HARDWARE
type. But we can define the same event with the PERF_TYPE_RAW
type.

Changing the intel_pmu_has_bts code to check on event's final
hw config value, so both HW types are covered.

Adding unlikely to intel_pmu_has_bts condition calls, because
it was used in the original code in intel_bts_constraints.

Signed-off-by: Jiri Olsa 
---
 arch/x86/events/intel/core.c | 17 +++--
 arch/x86/events/perf_event.h | 13 +
 2 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 8c1efb4d8f47..3fd3842571e8 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -2470,16 +2470,7 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
 static struct event_constraint *
 intel_bts_constraints(struct perf_event *event)
 {
-   struct hw_perf_event *hwc = &event->hw;
-   unsigned int hw_event, bts_event;
-
-   if (event->attr.freq)
-   return NULL;
-
-   hw_event = hwc->config & INTEL_ARCH_EVENT_MASK;
-   bts_event = x86_pmu.event_map(PERF_COUNT_HW_BRANCH_INSTRUCTIONS);
-
-   if (unlikely(hw_event == bts_event && hwc->sample_period == 1))
+   if (unlikely(intel_pmu_has_bts(event)))
return &bts_constraint;
 
return NULL;
@@ -3101,10 +3092,8 @@ static unsigned long intel_pmu_large_pebs_flags(struct 
perf_event *event)
 static int intel_pmu_bts_config(struct perf_event *event)
 {
struct perf_event_attr *attr = &event->attr;
-   struct hw_perf_event *hwc = &event->hw;
 
-   if (attr->config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS &&
-   !attr->freq && hwc->sample_period == 1) {
+   if (unlikely(intel_pmu_has_bts(event))) {
/* BTS is not supported by this architecture. */
if (!x86_pmu.bts_active)
return -EOPNOTSUPP;
@@ -3166,7 +3155,7 @@ static int intel_pmu_hw_config(struct perf_event *event)
/*
 * BTS is set up earlier in this path, so don't account twice
 */
-   if (!intel_pmu_has_bts(event)) {
+   if (!unlikely(intel_pmu_has_bts(event))) {
/* disallow lbr if conflicting events are present */
if (x86_add_exclusive(x86_lbr_exclusive_lbr))
return -EBUSY;
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index adae087cecdd..78d7b7031bfc 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -859,11 +859,16 @@ static inline int amd_pmu_init(void)
 
 static inline bool intel_pmu_has_bts(struct perf_event *event)
 {
-   if (event->attr.config == PERF_COUNT_HW_BRANCH_INSTRUCTIONS &&
-   !event->attr.freq && event->hw.sample_period == 1)
-   return true;
+   struct hw_perf_event *hwc = &event->hw;
+   unsigned int hw_event, bts_event;
+
+   if (event->attr.freq)
+   return false;
+
+   hw_event = hwc->config & INTEL_ARCH_EVENT_MASK;
+   bts_event = x86_pmu.event_map(PERF_COUNT_HW_BRANCH_INSTRUCTIONS);
 
-   return false;
+   return hw_event == bts_event && hwc->sample_period == 1;
 }
 
 int intel_pmu_save_and_restart(struct perf_event *event);
-- 
2.17.2

[PATCH 3/3] perf/x86/intel: Disallow precise_ip on BTS event

[Jiri Olsa]

Vince reported crash in bts flush code when touching the callchain
data, which was supposed to be initialized as an 'early' callchain,
but intel_pmu_drain_bts_buffer does not do that.

  BUG: unable to handle kernel NULL pointer dereference at 
  ...
  Call Trace:
   
   intel_pmu_drain_bts_buffer+0x151/0x220
   ? intel_get_event_constraints+0x219/0x360
   ? perf_assign_events+0xe2/0x2a0
   ? select_idle_sibling+0x22/0x3a0
   ? __update_load_avg_se+0x1ec/0x270
   ? enqueue_task_fair+0x377/0xdd0
   ? cpumask_next_and+0x19/0x20
   ? load_balance+0x134/0x950
   ? check_preempt_curr+0x7a/0x90
   ? ttwu_do_wakeup+0x19/0x140
   x86_pmu_stop+0x3b/0x90
   x86_pmu_del+0x57/0x160
   event_sched_out.isra.106+0x81/0x170
   group_sched_out.part.108+0x51/0xc0
   __perf_event_disable+0x7f/0x160
   event_function+0x8c/0xd0
   remote_function+0x3c/0x50
   flush_smp_call_function_queue+0x35/0xe0
   smp_call_function_single_interrupt+0x3a/0xd0
   call_function_single_interrupt+0xf/0x20
   

It was triggered by fuzzer but can be easily reproduced by:
  # perf record -e cpu/branch-instructions/pu -g -c 1

Peter suggested not to allow branch tracing for precise events:

> Now arguably, this is really stupid behaviour. Who in his right mind
> wants callchain output on BTS entries. And even if they do, BTS +
> precise_ip is nonsensical.
>
> So in my mind disallowing precise_ip on BTS would be the simplest fix.

Suggested-by: Peter Zijlstra 
Fixes: 6cbc304f2f36 ("perf/x86/intel: Fix unwind errors from PEBS entries 
(mk-II)")
Reported-by: Vince Weaver 
Signed-off-by: Jiri Olsa 
---
 arch/x86/events/intel/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 3fd3842571e8..284893373d69 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3102,6 +3102,10 @@ static int intel_pmu_bts_config(struct perf_event *event)
if (!attr->exclude_kernel)
return -EOPNOTSUPP;
 
+   /* BTS is not allowed for precise events. */
+   if (attr->precise_ip)
+   return -EOPNOTSUPP;
+
/* disallow bts if conflicting events are present */
if (x86_add_exclusive(x86_lbr_exclusive_lbr))
return -EBUSY;
-- 
2.17.2

[PATCH] clk: zynq: do not allow kmalloc failure

[Nicholas Mc Guire]

 The kmalloc here is small (< 16 bytes) and occurs during initialization
during system startup here (can not be built as module) thus if this
kmalloc failed it is an indication of something more serious going on
and it is fine to hang the system here rather than cause some harder
to understand error by dereferencing NULL.

 Explicitly checking would not make that much sense here as the only
possible reaction would be would BUG() here anyway.

Signed-off-by: Nicholas Mc Guire 

Problem located with experimental coccinelle script

Patch was compile tested with: multi_v7_defconfig (implies
CONFIG_ARCH_ZYNQ=y)

Patch is against 4.20-rc3 (localversion-next is next-20181121)

---
 drivers/clk/zynq/clkc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
index d7b53ac..014d4a4 100644
--- a/drivers/clk/zynq/clkc.c
+++ b/drivers/clk/zynq/clkc.c
@@ -440,7 +440,7 @@ static void __init zynq_clk_setup(struct device_node *np)
SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock);
 
tmp = strlen("mio_clk_00x");
-   clk_name = kmalloc(tmp, GFP_KERNEL);
+   clk_name = kmalloc(tmp, GFP_KERNEL | __GFP_NOFAIL);
for (i = 0; i < NUM_MIO_PINS; i++) {
int idx;
 
-- 
2.1.4

Re: [PATCH v2 1/3] thermal: tegra: continue if sensor register fails

[Wei Ni]

On 21/11/2018 4:55 PM, Daniel Lezcano wrote:
> On 13/11/2018 11:06, Wei Ni wrote:
>> Don't bail when a sensor fails to register with the
>> thermal zone and allow other sensors to register.
>> This allows other sensors to register with thermal
>> framework even if one sensor fails registration.
> 
> I'm not sure if ignoring the error is really safe. Can you describe the
> real situation you want to overcome ? How do you differentiate critical
> sensors ?

The driver will always try to register 4 thermal zones, including cpu,
gpu, mem and pll, but if the dts file doesn't set the corresponding
sensors, then the register will be failed.
Normally, the dts file will set all 4 sensors, but there may have some
platform doesn't support them all. So we post this patch.

BTW, what do you mean "critical sensors"? We will set critical trip temp
for all sensors.

Wei.

> 
>> Signed-off-by: Wei Ni 
>> ---
>>  drivers/thermal/tegra/soctherm.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/thermal/tegra/soctherm.c 
>> b/drivers/thermal/tegra/soctherm.c
>> index ed28110a3535..a824d2e63af3 100644
>> --- a/drivers/thermal/tegra/soctherm.c
>> +++ b/drivers/thermal/tegra/soctherm.c
>> @@ -1370,9 +1370,9 @@ static int tegra_soctherm_probe(struct platform_device 
>> *pdev)
>>   &tegra_of_thermal_ops);
>>  if (IS_ERR(z)) {
>>  err = PTR_ERR(z);
>> -dev_err(&pdev->dev, "failed to register sensor: %d\n",
>> -err);
>> -goto disable_clocks;
>> +dev_warn(&pdev->dev, "failed to register sensor %s: 
>> %d\n",
>> + soc->ttgs[i]->name, err);
>> +continue;
>>  }
>>  
>>  zone->tz = z;
>> @@ -1434,6 +1434,8 @@ static int __maybe_unused soctherm_resume(struct 
>> device *dev)
>>  struct thermal_zone_device *tz;
>>  
>>  tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
>> +if (!tz)
>> +continue;
>>  err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
>>  if (err) {
>>  dev_err(&pdev->dev,
>>
> 
> 

Re: BUG: unable to handle kernel NULL pointer dereference in write_port

[Dmitry Vyukov]

On Wed, Nov 21, 2018 at 11:11 AM, Kyungtae Kim  wrote:
> Thank you for your reply.
> But I think this kind of crash can occur in real PC as well, and I'm
> just thinking of some way to stop it in the first place (if possible).
> because malicious users can use this, so as to make the whole system
> (kernel) work incorrectly.

If I am not mistaken this program writes to /dev/port. /dev/port is
strictly privileged.

p.s. if you are extending syzkaller to do new things, it can make
sense to send pull requests upstream. Then we can review the changes
and figure out what should be tested, and what does not make sense to
fuzz. E.g. also don't give /dev/mem to syzkaller ;)

Linux 4.19.3

[Greg KH]

I'm announcing the release of the 4.19.3 kernel.

All users of the 4.19 kernel series must upgrade.

The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Documentation/filesystems/overlayfs.txt |6 
 Makefile|2 
 arch/alpha/include/asm/termios.h|8 -
 arch/alpha/include/uapi/asm/ioctls.h|5 
 arch/alpha/include/uapi/asm/termbits.h  |   17 ++
 arch/arm/boot/dts/imx6ull-pinfunc.h |   18 +-
 arch/arm/configs/imx_v6_v7_defconfig|1 
 arch/arm/mm/proc-v7.S   |2 
 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi   |9 +
 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts  |2 
 arch/mips/include/asm/mach-loongson64/irq.h |2 
 arch/mips/kernel/crash.c|3 
 arch/mips/kernel/machine_kexec.c|3 
 arch/mips/loongson64/loongson-3/irq.c   |   56 ---
 arch/mips/pci/pci-legacy.c  |4 
 arch/powerpc/Makefile   |6 
 arch/powerpc/boot/crt0.S|4 
 arch/powerpc/include/asm/mmu-8xx.h  |   34 
 arch/powerpc/kernel/eeh.c   |5 
 arch/powerpc/kernel/head_8xx.S  |   45 +++---
 arch/powerpc/kernel/module_64.c |9 +
 arch/powerpc/kernel/traps.c |9 -
 arch/powerpc/mm/8xx_mmu.c   |2 
 arch/powerpc/mm/dump_linuxpagetables.c  |   12 +
 arch/powerpc/mm/hugetlbpage.c   |3 
 arch/powerpc/mm/slice.c |   21 +-
 arch/powerpc/mm/tlb_nohash.c|3 
 arch/powerpc/platforms/powernv/memtrace.c   |   21 ++
 arch/x86/include/asm/mce.h  |2 
 arch/x86/kernel/cpu/mcheck/mce.c|6 
 arch/x86/kernel/cpu/mshyperv.c  |   11 +
 arch/x86/kernel/cpu/vmware.c|2 
 arch/x86/um/shared/sysdep/ptrace_32.h   |   10 -
 arch/xtensa/boot/Makefile   |2 
 arch/xtensa/include/asm/processor.h |6 
 arch/xtensa/kernel/head.S   |7 
 arch/xtensa/kernel/vmlinux.lds.S|1 
 block/blk-core.c|5 
 crypto/crypto_user.c|   18 +-
 drivers/acpi/acpica/dsopcode.c  |4 
 drivers/acpi/nfit/core.c|4 
 drivers/acpi/nfit/mce.c |8 -
 drivers/ata/libata-core.c   |2 
 drivers/block/zram/zram_drv.c   |   26 ---
 drivers/cdrom/cdrom.c   |2 
 drivers/clk/at91/clk-pll.c  |3 
 drivers/clk/clk-s2mps11.c   |   30 
 drivers/clk/hisilicon/reset.c   |5 
 drivers/clk/meson/axg.c |   13 +
 drivers/clk/meson/gxbb.c|   12 +
 drivers/clk/rockchip/clk-ddr.c  |4 
 drivers/clk/rockchip/clk-rk3328.c   |8 -
 drivers/clk/sunxi-ng/ccu-sun50i-h6.c|8 -
 drivers/clocksource/i8253.c |   14 +
 drivers/cpuidle/cpuidle-arm.c   |   22 +-
 drivers/crypto/hisilicon/sec/sec_algs.c |   31 ++--
 drivers/firmware/efi/libstub/fdt.c  |4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c|   17 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c |3 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c |2 
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |1 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c   |1 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |3 
 drivers/gpu/drm/amd/display/dc/core/dc.c|   19 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c |3 
 drivers/gpu/drm/amd/display/modules/color/color_gamma.c |8 -
 drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c|5 
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c|2 
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c  |2 
 drivers/gpu/drm/amd/powerplay/smumgr/

[PATCH v2 2/3] mmc: sdhci-omap: Add platform specific reset callback

[Faiz Abbas]

The TRM (SPRUIC2C - January 2017 - Revised May 2018 [1]) forbids
assertion of data reset while tuning is happening. Implement a
platform specific callback that takes care of this condition.

[1] http://www.ti.com/lit/pdf/spruic2 Section 25.5.1.2.4

Acked-by: Kishon Vijay Abraham I 
Signed-off-by: Faiz Abbas 
---
 drivers/mmc/host/sdhci-omap.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
index d264391616f9..4fad47926743 100644
--- a/drivers/mmc/host/sdhci-omap.c
+++ b/drivers/mmc/host/sdhci-omap.c
@@ -115,6 +115,7 @@ struct sdhci_omap_host {
 
struct pinctrl  *pinctrl;
struct pinctrl_state**pinctrl_state;
+   boolis_tuning;
 };
 
 static void sdhci_omap_start_clock(struct sdhci_omap_host *omap_host);
@@ -322,6 +323,8 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
dcrc_was_enabled = true;
}
 
+   omap_host->is_tuning = true;
+
while (phase_delay <= MAX_PHASE_DELAY) {
sdhci_omap_set_dll(omap_host, phase_delay);
 
@@ -359,9 +362,12 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
phase_delay = max_window + 4 * (max_len >> 1);
sdhci_omap_set_dll(omap_host, phase_delay);
 
+   omap_host->is_tuning = false;
+
goto ret;
 
 tuning_error:
+   omap_host->is_tuning = false;
dev_err(dev, "Tuning failed\n");
sdhci_omap_disable_tuning(omap_host);
 
@@ -687,6 +693,18 @@ static void sdhci_omap_set_uhs_signaling(struct sdhci_host 
*host,
sdhci_omap_start_clock(omap_host);
 }
 
+void sdhci_omap_reset(struct sdhci_host *host, u8 mask)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+   struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
+
+   /* Don't reset data lines during tuning operation */
+   if (omap_host->is_tuning)
+   mask &= ~SDHCI_RESET_DATA;
+
+   sdhci_reset(host, mask);
+}
+
 static struct sdhci_ops sdhci_omap_ops = {
.set_clock = sdhci_omap_set_clock,
.set_power = sdhci_omap_set_power,
@@ -695,7 +713,7 @@ static struct sdhci_ops sdhci_omap_ops = {
.get_min_clock = sdhci_omap_get_min_clock,
.set_bus_width = sdhci_omap_set_bus_width,
.platform_send_init_74_clocks = sdhci_omap_init_74_clocks,
-   .reset = sdhci_reset,
+   .reset = sdhci_omap_reset,
.set_uhs_signaling = sdhci_omap_set_uhs_signaling,
 };
 
-- 
2.19.1

Linux 4.18.20

[Greg KH]

I'm announcing the release of the 4.18.20 kernel.

All users of the 4.18 kernel series must upgrade.

Note, this is the LAST 4.18.y kernel release.  4.18 is now end-of-life,
please move to 4.19.y at this point in time.

The updated 4.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile|2 
 arch/alpha/include/asm/termios.h|8 ++
 arch/alpha/include/uapi/asm/ioctls.h|5 +
 arch/alpha/include/uapi/asm/termbits.h  |   17 
 arch/arm/boot/dts/imx6ull-pinfunc.h |   18 +++--
 arch/arm/configs/imx_v6_v7_defconfig|1 
 arch/arm/mm/proc-v7.S   |2 
 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi   |9 ++
 arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dts  |2 
 arch/mips/include/asm/mach-loongson64/irq.h |2 
 arch/mips/kernel/crash.c|3 
 arch/mips/kernel/machine_kexec.c|3 
 arch/mips/loongson64/loongson-3/irq.c   |   56 +---
 arch/mips/pci/pci-legacy.c  |4 +
 arch/powerpc/Makefile   |6 +
 arch/powerpc/boot/crt0.S|4 -
 arch/powerpc/include/asm/mmu-8xx.h  |   34 +
 arch/powerpc/kernel/eeh.c   |5 +
 arch/powerpc/kernel/head_8xx.S  |   45 +++-
 arch/powerpc/kernel/module_64.c |9 ++
 arch/powerpc/kernel/traps.c |9 ++
 arch/powerpc/mm/8xx_mmu.c   |2 
 arch/powerpc/mm/dump_linuxpagetables.c  |   12 ++-
 arch/powerpc/mm/hugetlbpage.c   |3 
 arch/powerpc/mm/slice.c |   21 --
 arch/powerpc/mm/tlb_nohash.c|3 
 arch/powerpc/platforms/powernv/memtrace.c   |   21 --
 arch/x86/include/asm/mce.h  |2 
 arch/x86/kernel/cpu/mcheck/mce.c|6 +
 arch/x86/kernel/cpu/mshyperv.c  |   11 +++
 arch/x86/kernel/cpu/vmware.c|2 
 arch/x86/um/shared/sysdep/ptrace_32.h   |   10 --
 arch/xtensa/boot/Makefile   |2 
 arch/xtensa/include/asm/processor.h |6 +
 arch/xtensa/kernel/head.S   |7 +-
 arch/xtensa/kernel/vmlinux.lds.S|1 
 block/blk-core.c|5 -
 crypto/crypto_user.c|   18 ++---
 drivers/acpi/acpica/dsopcode.c  |4 -
 drivers/acpi/nfit/core.c|4 -
 drivers/acpi/nfit/mce.c |8 +-
 drivers/ata/libata-core.c   |2 
 drivers/block/zram/zram_drv.c   |   26 +--
 drivers/cdrom/cdrom.c   |2 
 drivers/clk/at91/clk-pll.c  |3 
 drivers/clk/clk-s2mps11.c   |   30 
 drivers/clk/hisilicon/reset.c   |5 -
 drivers/clk/meson/axg.c |   13 +++
 drivers/clk/meson/gxbb.c|   12 +++
 drivers/clk/rockchip/clk-ddr.c  |4 -
 drivers/clk/rockchip/clk-rk3328.c   |8 +-
 drivers/clk/sunxi-ng/ccu-sun50i-h6.c|8 +-
 drivers/clocksource/i8253.c |   14 +++-
 drivers/firmware/efi/libstub/fdt.c  |4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c |2 
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |1 
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c   |1 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |3 
 drivers/gpu/drm/amd/display/dc/core/dc.c|   19 -
 drivers/gpu/drm/amd/display/modules/color/color_gamma.c |8 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c|5 +
 drivers/gpu/drm/amd/powerplay/smumgr/ci_smumgr.c|2 
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smumgr.c  |2 
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smumgr.c   |2 
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c |2 
 drivers/gpu/drm/amd/powerplay/smumgr/vegam_smumgr.c |2 
 drivers/gpu/drm/drm_dp_mst_topology.c 

[PATCH v2 0/3] Tuning Fixes for sdhci-omap

[Faiz Abbas]

The following patches fix tuning related errors in the
sdhci-omap driver.

v2:
Added Fixes and stable tags for patch 1.
Re-enable DCRC in patch 1 only if it was enabled before
Squashed patches 2 & 3

Faiz Abbas (3):
  mmc: sdhci-omap: Fix DCRC error handling during tuning
  mmc: sdhci-omap: Add platform specific reset callback
  mmc: sdhci-omap: Remove redundant structure assignments

 drivers/mmc/host/sdhci-omap.c | 36 ++-
 1 file changed, 27 insertions(+), 9 deletions(-)

-- 
2.19.1

Linux 4.14.82

[Greg KH]

I'm announcing the release of the 4.14.82 kernel.

All users of the 4.14 kernel series must upgrade.

The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile  |2 
 arch/alpha/include/asm/termios.h  |8 ++-
 arch/alpha/include/uapi/asm/ioctls.h  |5 +
 arch/alpha/include/uapi/asm/termbits.h|   17 ++
 arch/arm/configs/imx_v6_v7_defconfig  |1 
 arch/arm/mm/proc-v7.S |2 
 arch/mips/include/asm/mach-loongson64/irq.h   |2 
 arch/mips/kernel/crash.c  |3 +
 arch/mips/kernel/machine_kexec.c  |3 +
 arch/mips/loongson64/loongson-3/irq.c |   56 ++
 arch/mips/pci/pci-legacy.c|4 +
 arch/powerpc/boot/crt0.S  |4 +
 arch/powerpc/kernel/eeh.c |5 +
 arch/powerpc/kernel/module_64.c   |9 +++
 arch/powerpc/kernel/traps.c   |9 ++-
 arch/powerpc/mm/dump_linuxpagetables.c|   12 +++-
 arch/powerpc/mm/hugetlbpage.c |3 +
 arch/powerpc/mm/tlb_nohash.c  |3 +
 arch/powerpc/platforms/powernv/memtrace.c |   21 ++--
 arch/x86/kernel/cpu/mshyperv.c|   11 
 arch/x86/kernel/cpu/vmware.c  |2 
 arch/x86/um/shared/sysdep/ptrace_32.h |   10 ---
 arch/xtensa/boot/Makefile |2 
 arch/xtensa/include/asm/processor.h   |6 +-
 arch/xtensa/kernel/head.S |7 +-
 arch/xtensa/kernel/vmlinux.lds.S  |1 
 block/blk-core.c  |5 -
 crypto/crypto_user.c  |   18 +++
 drivers/cdrom/cdrom.c |2 
 drivers/clk/at91/clk-pll.c|3 +
 drivers/clk/clk-s2mps11.c |   30 +++
 drivers/clk/hisilicon/reset.c |5 -
 drivers/clk/mvebu/clk-corediv.c   |2 
 drivers/clk/rockchip/clk-ddr.c|4 -
 drivers/clocksource/i8253.c   |   14 -
 drivers/firmware/efi/libstub/fdt.c|4 +
 drivers/gpio/gpio-brcmstb.c   |   21 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c |1 
 drivers/gpu/drm/drm_dp_mst_topology.c |3 +
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c |1 
 drivers/gpu/drm/i915/i915_gem.c   |   12 
 drivers/gpu/drm/i915/i915_gem_gtt.h   |   28 +--
 drivers/gpu/drm/i915/intel_audio.c|   17 ++
 drivers/gpu/drm/i915/intel_display.c  |   23 +
 drivers/gpu/drm/i915/intel_dp_mst.c   |   41 
 drivers/gpu/drm/i915/intel_lpe_audio.c|4 +
 drivers/gpu/drm/i915/intel_lrc.c  |   14 +
 drivers/gpu/drm/nouveau/nouveau_backlight.c   |4 -
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c  |   11 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |6 ++
 drivers/media/i2c/ov7670.c|   30 +++
 drivers/media/i2c/tvp5150.c   |   14 +++--
 drivers/media/pci/cx23885/altera-ci.c |   10 +++
 drivers/media/platform/coda/coda-common.c |3 -
 drivers/mtd/devices/Kconfig   |2 
 drivers/nvme/target/loop.c|9 ---
 drivers/of/of_numa.c  |9 ++-
 drivers/rtc/hctosys.c |4 +
 drivers/scsi/qla2xxx/qla_init.c   |   23 ++---
 drivers/scsi/qla2xxx/qla_iocb.c   |   17 --
 drivers/scsi/qla2xxx/qla_mbx.c|5 -
 drivers/scsi/qla2xxx/qla_target.c |3 -
 drivers/scsi/qla2xxx/tcm_qla2xxx.c|4 -
 drivers/scsi/scsi_lib.c   |8 +++
 drivers/soc/ti/knav_qmss.h|4 -
 drivers/soc/ti/knav_qmss_acc.c|   10 +--
 drivers/soc/ti/knav_qmss_queue.c  |   22 +---
 drivers/staging/iio/adc/ad7606.c  |7 +-
 drivers/thermal/Kconfig   |2 
 drivers/tty/serial/sc16is7xx.c|   19 +--
 drivers/tty/tty_baudrate.c|4 -
 drivers/tty/tty_io.c  |2 
 drivers/vhost/scsi.c  |4 +
 drivers/video/fbdev/aty/mach64_accel.

[PATCH v2 3/3] mmc: sdhci-omap: Remove redundant structure assignments

[Faiz Abbas]

The sdhci_execute_tuning() function has assignment of
private pointers multiple times. Remove the redundant assignment.

Acked-by: Kishon Vijay Abraham I 
Signed-off-by: Faiz Abbas 
---
 drivers/mmc/host/sdhci-omap.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
index 4fad47926743..f588ab679cb0 100644
--- a/drivers/mmc/host/sdhci-omap.c
+++ b/drivers/mmc/host/sdhci-omap.c
@@ -296,10 +296,6 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
int ret = 0;
u32 reg;
 
-   pltfm_host = sdhci_priv(host);
-   omap_host = sdhci_pltfm_priv(pltfm_host);
-   dev = omap_host->dev;
-
/* clock tuning is not needed for upto 52MHz */
if (ios->clock <= 5200)
return 0;
-- 
2.19.1

Re: Linux 4.14.82

[Greg KH]

diff --git a/Makefile b/Makefile
index 2fe1424d61d2..cac5323bc95d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 VERSION = 4
 PATCHLEVEL = 14
-SUBLEVEL = 81
+SUBLEVEL = 82
 EXTRAVERSION =
 NAME = Petit Gorille
 
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termios.h
index 6a8c53dec57e..b7c77bb1bfd2 100644
--- a/arch/alpha/include/asm/termios.h
+++ b/arch/alpha/include/asm/termios.h
@@ -73,9 +73,15 @@
 })
 
 #define user_termios_to_kernel_termios(k, u) \
-   copy_from_user(k, u, sizeof(struct termios))
+   copy_from_user(k, u, sizeof(struct termios2))
 
 #define kernel_termios_to_user_termios(u, k) \
+   copy_to_user(u, k, sizeof(struct termios2))
+
+#define user_termios_to_kernel_termios_1(k, u) \
+   copy_from_user(k, u, sizeof(struct termios))
+
+#define kernel_termios_to_user_termios_1(u, k) \
copy_to_user(u, k, sizeof(struct termios))
 
 #endif /* _ALPHA_TERMIOS_H */
diff --git a/arch/alpha/include/uapi/asm/ioctls.h 
b/arch/alpha/include/uapi/asm/ioctls.h
index 3729d92d3fa8..dc8c20ac7191 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -32,6 +32,11 @@
 #define TCXONC _IO('t', 30)
 #define TCFLSH _IO('t', 31)
 
+#define TCGETS2_IOR('T', 42, struct termios2)
+#define TCSETS2_IOW('T', 43, struct termios2)
+#define TCSETSW2   _IOW('T', 44, struct termios2)
+#define TCSETSF2   _IOW('T', 45, struct termios2)
+
 #define TIOCSWINSZ _IOW('t', 103, struct winsize)
 #define TIOCGWINSZ _IOR('t', 104, struct winsize)
 #defineTIOCSTART   _IO('t', 110)   /* start output, like 
^Q */
diff --git a/arch/alpha/include/uapi/asm/termbits.h 
b/arch/alpha/include/uapi/asm/termbits.h
index 05e0398a83a6..53b3ecff2f50 100644
--- a/arch/alpha/include/uapi/asm/termbits.h
+++ b/arch/alpha/include/uapi/asm/termbits.h
@@ -26,6 +26,19 @@ struct termios {
speed_t c_ospeed;   /* output speed */
 };
 
+/* Alpha has identical termios and termios2 */
+
+struct termios2 {
+   tcflag_t c_iflag;   /* input mode flags */
+   tcflag_t c_oflag;   /* output mode flags */
+   tcflag_t c_cflag;   /* control mode flags */
+   tcflag_t c_lflag;   /* local mode flags */
+   cc_t c_cc[NCCS];/* control characters */
+   cc_t c_line;/* line discipline (== c_cc[19]) */
+   speed_t c_ispeed;   /* input speed */
+   speed_t c_ospeed;   /* output speed */
+};
+
 /* Alpha has matching termios and ktermios */
 
 struct ktermios {
@@ -148,6 +161,7 @@ struct ktermios {
 #define B300  00034
 #define B350  00035
 #define B400  00036
+#define BOTHER00037
 
 #define CSIZE  1400
 #define   CS5  
@@ -165,6 +179,9 @@ struct ktermios {
 #define CMSPAR   0100  /* mark or space (stick) parity */
 #define CRTSCTS  0200  /* flow control */
 
+#define CIBAUD 0760
+#define IBSHIFT16
+
 /* c_lflag bits */
 #define ISIG   0x0080
 #define ICANON 0x0100
diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index 32acac9ab81a..9c795ceedd5b 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -383,6 +383,7 @@ CONFIG_ZISOFS=y
 CONFIG_UDF_FS=m
 CONFIG_MSDOS_FS=m
 CONFIG_VFAT_FS=y
+CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_JFFS2_FS=y
 CONFIG_UBIFS_FS=y
 CONFIG_NFS_FS=y
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 12468d9378d8..d8d90cf65b39 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -112,7 +112,7 @@ ENTRY(cpu_v7_hvc_switch_mm)
hvc #0
ldmfd   sp!, {r0 - r3}
b   cpu_v7_switch_mm
-ENDPROC(cpu_v7_smc_switch_mm)
+ENDPROC(cpu_v7_hvc_switch_mm)
 #endif
 ENTRY(cpu_v7_iciallu_switch_mm)
mov r3, #0
diff --git a/arch/mips/include/asm/mach-loongson64/irq.h 
b/arch/mips/include/asm/mach-loongson64/irq.h
index 3644b68c0ccc..be9f727a9328 100644
--- a/arch/mips/include/asm/mach-loongson64/irq.h
+++ b/arch/mips/include/asm/mach-loongson64/irq.h
@@ -10,7 +10,7 @@
 #define MIPS_CPU_IRQ_BASE 56
 
 #define LOONGSON_UART_IRQ   (MIPS_CPU_IRQ_BASE + 2) /* UART */
-#define LOONGSON_HT1_IRQ(MIPS_CPU_IRQ_BASE + 3) /* HT1 */
+#define LOONGSON_BRIDGE_IRQ (MIPS_CPU_IRQ_BASE + 3) /* CASCADE */
 #define LOONGSON_TIMER_IRQ  (MIPS_CPU_IRQ_BASE + 7) /* CPU Timer */
 
 #define LOONGSON_HT1_CFG_BASE  loongson_sysconf.ht_control_base
diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c
index d455363d51c3..4c07a43a3242 100644
--- a/arch/mips/kernel/crash.c
+++ b/arch/mips/kernel/crash.c
@@ -36,6 +36,9 @@ static void crash_shutdown_secondary(void *passed_regs)
if (!cpu_online(cpu))
return;
 
+   /* We won't be sent IPIs any more. */
+   set_cpu_online(

[PATCH v2 1/3] mmc: sdhci-omap: Fix DCRC error handling during tuning

[Faiz Abbas]

Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
disabled DCRC interrupts during tuning. This write to the interrupt
enable register gets overwritten in sdhci_prepare_data() and the
interrupt is not in fact disabled. Fix this by disabling the interrupt
in the host->ier variable.

Fixes: 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
Cc: 
Signed-off-by: Faiz Abbas 
---
 drivers/mmc/host/sdhci-omap.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
index 88347ce78f23..d264391616f9 100644
--- a/drivers/mmc/host/sdhci-omap.c
+++ b/drivers/mmc/host/sdhci-omap.c
@@ -288,9 +288,9 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
struct device *dev = omap_host->dev;
struct mmc_ios *ios = &mmc->ios;
u32 start_window = 0, max_window = 0;
+   bool dcrc_was_enabled = false;
u8 cur_match, prev_match = 0;
u32 length = 0, max_len = 0;
-   u32 ier = host->ier;
u32 phase_delay = 0;
int ret = 0;
u32 reg;
@@ -317,9 +317,10 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
 * during the tuning procedure. So disable it during the
 * tuning procedure.
 */
-   ier &= ~SDHCI_INT_DATA_CRC;
-   sdhci_writel(host, ier, SDHCI_INT_ENABLE);
-   sdhci_writel(host, ier, SDHCI_SIGNAL_ENABLE);
+   if (host->ier & SDHCI_INT_DATA_CRC) {
+   host->ier &= ~SDHCI_INT_DATA_CRC;
+   dcrc_was_enabled = true;
+   }
 
while (phase_delay <= MAX_PHASE_DELAY) {
sdhci_omap_set_dll(omap_host, phase_delay);
@@ -366,6 +367,9 @@ static int sdhci_omap_execute_tuning(struct mmc_host *mmc, 
u32 opcode)
 
 ret:
sdhci_reset(host, SDHCI_RESET_CMD | SDHCI_RESET_DATA);
+   /* Reenable forbidden interrupt */
+   if (dcrc_was_enabled)
+   host->ier |= SDHCI_INT_DATA_CRC;
sdhci_writel(host, host->ier, SDHCI_INT_ENABLE);
sdhci_writel(host, host->ier, SDHCI_SIGNAL_ENABLE);
return ret;
-- 
2.19.1

Linux 4.4.164

[Greg KH]

I'm announcing the release of the 4.4.164 kernel.

All users of the 4.4 kernel series must upgrade.

The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile   
 |2 
 arch/alpha/include/asm/termios.h   
 |8 -
 arch/alpha/include/uapi/asm/ioctls.h   
 |5 
 arch/alpha/include/uapi/asm/termbits.h 
 |   17 ++
 arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi  
 |2 
 arch/mips/cavium-octeon/executive/cvmx-helper.c
 |2 
 arch/mips/include/asm/mach-loongson64/irq.h
 |2 
 arch/mips/kernel/crash.c   
 |3 
 arch/mips/kernel/machine_kexec.c   
 |3 
 arch/mips/loongson64/loongson-3/irq.c  
 |   56 ---
 arch/parisc/kernel/entry.S 
 |2 
 arch/parisc/kernel/traps.c 
 |3 
 arch/parisc/mm/init.c  
 |8 -
 arch/powerpc/boot/crt0.S   
 |4 
 arch/powerpc/include/asm/mpic.h
 |7 
 arch/powerpc/mm/tlb_nohash.c   
 |3 
 arch/sparc/kernel/perf_event.c 
 |   17 +-
 arch/x86/Kconfig   
 |1 
 arch/x86/boot/tools/build.c
 |7 
 arch/x86/kernel/check.c
 |   15 +
 arch/x86/kernel/fpu/signal.c   
 |1 
 arch/x86/xen/spinlock.c
 |   35 +---
 arch/xtensa/boot/Makefile  
 |2 
 arch/xtensa/include/asm/processor.h
 |6 
 arch/xtensa/kernel/head.S  
 |7 
 arch/xtensa/kernel/vmlinux.lds.S   
 |1 
 crypto/lrw.c   
 |7 
 drivers/acpi/acpi_lpss.c   
 |2 
 drivers/block/ataflop.c
 |   25 +--
 drivers/block/swim.c   
 |   13 +
 drivers/bluetooth/btbcm.c  
 |1 
 drivers/cdrom/cdrom.c  
 |2 
 drivers/char/ipmi/ipmi_ssif.c  
 |   10 -
 drivers/char/tpm/tpm-interface.c   
 |3 
 drivers/char/tpm/xen-tpmfront.c
 |2 
 drivers/clk/clk-s2mps11.c  
 |   30 +++
 drivers/clocksource/i8253.c
 |   14 +
 drivers/dma/dma-jz4780.c   
 |5 
 drivers/dma/ioat/init.c
 |9 +
 drivers/gpu/drm/drm_dp_mst_topology.c  
 |3 
 drivers/gpu/drm/i915/intel_audio.c 
 |   17 ++
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c   
 |   11 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 |6 
 drivers/hid/usbhid/hiddev.c
 |   18 +-
 drivers/hwmon/pmbus/pmbus.c  

Re: Linux 4.4.164

[Greg KH]

diff --git a/Makefile b/Makefile
index 4e3179768eea..9382e7e4e750 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 4
-SUBLEVEL = 163
+SUBLEVEL = 164
 EXTRAVERSION =
 NAME = Blurry Fish Butt
 
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termios.h
index 7fde0f88da88..51ed90be770a 100644
--- a/arch/alpha/include/asm/termios.h
+++ b/arch/alpha/include/asm/termios.h
@@ -72,9 +72,15 @@
 })
 
 #define user_termios_to_kernel_termios(k, u) \
-   copy_from_user(k, u, sizeof(struct termios))
+   copy_from_user(k, u, sizeof(struct termios2))
 
 #define kernel_termios_to_user_termios(u, k) \
+   copy_to_user(u, k, sizeof(struct termios2))
+
+#define user_termios_to_kernel_termios_1(k, u) \
+   copy_from_user(k, u, sizeof(struct termios))
+
+#define kernel_termios_to_user_termios_1(u, k) \
copy_to_user(u, k, sizeof(struct termios))
 
 #endif /* _ALPHA_TERMIOS_H */
diff --git a/arch/alpha/include/uapi/asm/ioctls.h 
b/arch/alpha/include/uapi/asm/ioctls.h
index f30c94ae1bdb..7ee8ab577e11 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -31,6 +31,11 @@
 #define TCXONC _IO('t', 30)
 #define TCFLSH _IO('t', 31)
 
+#define TCGETS2_IOR('T', 42, struct termios2)
+#define TCSETS2_IOW('T', 43, struct termios2)
+#define TCSETSW2   _IOW('T', 44, struct termios2)
+#define TCSETSF2   _IOW('T', 45, struct termios2)
+
 #define TIOCSWINSZ _IOW('t', 103, struct winsize)
 #define TIOCGWINSZ _IOR('t', 104, struct winsize)
 #defineTIOCSTART   _IO('t', 110)   /* start output, like 
^Q */
diff --git a/arch/alpha/include/uapi/asm/termbits.h 
b/arch/alpha/include/uapi/asm/termbits.h
index 879dd3589921..483c7ec2a879 100644
--- a/arch/alpha/include/uapi/asm/termbits.h
+++ b/arch/alpha/include/uapi/asm/termbits.h
@@ -25,6 +25,19 @@ struct termios {
speed_t c_ospeed;   /* output speed */
 };
 
+/* Alpha has identical termios and termios2 */
+
+struct termios2 {
+   tcflag_t c_iflag;   /* input mode flags */
+   tcflag_t c_oflag;   /* output mode flags */
+   tcflag_t c_cflag;   /* control mode flags */
+   tcflag_t c_lflag;   /* local mode flags */
+   cc_t c_cc[NCCS];/* control characters */
+   cc_t c_line;/* line discipline (== c_cc[19]) */
+   speed_t c_ispeed;   /* input speed */
+   speed_t c_ospeed;   /* output speed */
+};
+
 /* Alpha has matching termios and ktermios */
 
 struct ktermios {
@@ -147,6 +160,7 @@ struct ktermios {
 #define B300  00034
 #define B350  00035
 #define B400  00036
+#define BOTHER00037
 
 #define CSIZE  1400
 #define   CS5  
@@ -164,6 +178,9 @@ struct ktermios {
 #define CMSPAR   0100  /* mark or space (stick) parity */
 #define CRTSCTS  0200  /* flow control */
 
+#define CIBAUD 0760
+#define IBSHIFT16
+
 /* c_lflag bits */
 #define ISIG   0x0080
 #define ICANON 0x0100
diff --git a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi 
b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
index 445aa678f914..6a37101344aa 100644
--- a/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
+++ b/arch/arm64/boot/dts/altera/socfpga_stratix10.dtsi
@@ -249,7 +249,7 @@
 
sysmgr: sysmgr@ffd12000 {
compatible = "altr,sys-mgr", "syscon";
-   reg = <0xffd12000 0x1000>;
+   reg = <0xffd12000 0x228>;
};
 
/* Local timer */
diff --git a/arch/mips/cavium-octeon/executive/cvmx-helper.c 
b/arch/mips/cavium-octeon/executive/cvmx-helper.c
index 376701f41cc2..692bbc1c5b79 100644
--- a/arch/mips/cavium-octeon/executive/cvmx-helper.c
+++ b/arch/mips/cavium-octeon/executive/cvmx-helper.c
@@ -67,7 +67,7 @@ void (*cvmx_override_pko_queue_priority) (int pko_port,
 void (*cvmx_override_ipd_port_setup) (int ipd_port);
 
 /* Port count per interface */
-static int interface_port_count[5];
+static int interface_port_count[9];
 
 /* Port last configured link info index by IPD/PKO port */
 static cvmx_helper_link_info_t
diff --git a/arch/mips/include/asm/mach-loongson64/irq.h 
b/arch/mips/include/asm/mach-loongson64/irq.h
index d18c45c7c394..19ff9ce46c02 100644
--- a/arch/mips/include/asm/mach-loongson64/irq.h
+++ b/arch/mips/include/asm/mach-loongson64/irq.h
@@ -9,7 +9,7 @@
 #define MIPS_CPU_IRQ_BASE 56
 
 #define LOONGSON_UART_IRQ   (MIPS_CPU_IRQ_BASE + 2) /* UART */
-#define LOONGSON_HT1_IRQ(MIPS_CPU_IRQ_BASE + 3) /* HT1 */
+#define LOONGSON_BRIDGE_IRQ (MIPS_CPU_IRQ_BASE + 3) /* CASCADE */
 #define LOONGSON_TIMER_IRQ  (MIPS_CPU_IRQ_BASE + 7) /* CPU Timer */
 
 #define LOONGSON_HT1_CFG_BASE  loongson_sysconf.ht_control_base
diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/c

Linux 4.9.138

[Greg KH]

I'm announcing the release of the 4.9.138 kernel.

All users of the 4.9 kernel series must upgrade.

The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary

thanks,

greg k-h



 Makefile |2 
 arch/alpha/include/asm/termios.h |8 ++-
 arch/alpha/include/uapi/asm/ioctls.h |5 +
 arch/alpha/include/uapi/asm/termbits.h   |   17 ++
 arch/arm/configs/imx_v6_v7_defconfig |1 
 arch/arm/kvm/arm.c   |4 -
 arch/mips/include/asm/mach-loongson64/irq.h  |2 
 arch/mips/kernel/crash.c |3 +
 arch/mips/kernel/machine_kexec.c |3 +
 arch/mips/loongson64/loongson-3/irq.c|   56 ++---
 arch/mips/pci/pci-legacy.c   |4 +
 arch/parisc/kernel/hpmc.S|   10 ++-
 arch/powerpc/boot/crt0.S |4 +
 arch/powerpc/kernel/eeh.c|5 +
 arch/powerpc/mm/tlb_nohash.c |3 +
 arch/xtensa/boot/Makefile|2 
 arch/xtensa/include/asm/processor.h  |6 +-
 arch/xtensa/kernel/head.S|7 +-
 arch/xtensa/kernel/vmlinux.lds.S |1 
 drivers/cdrom/cdrom.c|2 
 drivers/clk/at91/clk-pll.c   |3 +
 drivers/clk/clk-s2mps11.c|   30 +++
 drivers/clk/hisilicon/reset.c|5 -
 drivers/clk/rockchip/clk-ddr.c   |4 -
 drivers/clocksource/i8253.c  |   14 -
 drivers/gpu/drm/drm_dp_mst_topology.c|3 +
 drivers/gpu/drm/i915/intel_audio.c   |   17 ++
 drivers/gpu/drm/i915/intel_lrc.c |   14 -
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c |   11 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c  |6 ++
 drivers/media/i2c/tvp5150.c  |   14 +++--
 drivers/media/pci/cx23885/altera-ci.c|   10 +++
 drivers/mtd/devices/Kconfig  |2 
 drivers/net/ethernet/brocade/bna/bnad_ethtool.c  |4 -
 drivers/net/ethernet/intel/e1000/e1000_ethtool.c |9 +--
 drivers/net/ethernet/intel/e1000/e1000_main.c|   11 +++-
 drivers/of/of_numa.c |9 ++-
 drivers/rtc/hctosys.c|4 +
 drivers/scsi/qla2xxx/qla_init.c  |2 
 drivers/scsi/qla2xxx/qla_mbx.c   |5 -
 drivers/tty/serial/sc16is7xx.c   |   19 ---
 drivers/tty/tty_io.c |2 
 drivers/tty/tty_ioctl.c  |4 -
 drivers/vhost/scsi.c |4 +
 drivers/video/fbdev/aty/mach64_accel.c   |   28 --
 fs/9p/vfs_file.c |   16 +-
 fs/btrfs/inode.c |5 -
 fs/btrfs/ioctl.c |   12 +++-
 fs/ceph/inode.c  |8 ++-
 fs/configfs/symlink.c|2 
 fs/ext4/namei.c  |5 +
 fs/ext4/resize.c |   28 ++
 fs/ext4/super.c  |   17 +++---
 fs/ext4/xattr.c  |4 +
 fs/fuse/dev.c|   29 ---
 fs/fuse/file.c   |4 +
 fs/namespace.c   |   22 ++--
 fs/nfsd/nfs4proc.c   |3 +
 fs/ocfs2/dir.c   |3 -
 include/linux/ceph/libceph.h |8 ++-
 include/linux/hugetlb.h  |   14 +
 include/linux/i8253.h|1 
 include/linux/mm.h   |6 ++
 lib/ubsan.c  |3 -
 mm/gup.c |2 
 mm/hugetlb.c |   60 ---
 mm/mempolicy.c   |   32 +++-
 mm/mmap.c|   19 +++
 mm/rmap.c|   56 +
 net/9p/protocol.c|5 +
 net/netfilter/nf_conntrack_core.c|   13 +++-
 net/sunrpc/xdr.c |5 -
 tools/testing/selftests/powerpc/tm/tm-tmspr.c|   27 ++
 73 files changed, 579 insertions(+), 209 deletions(-)

Andrea Arcangeli (1):
 

Re: Linux 4.9.138

[Greg KH]

diff --git a/Makefile b/Makefile
index 41fe3014b712..ccf2602f664d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 4
 PATCHLEVEL = 9
-SUBLEVEL = 137
+SUBLEVEL = 138
 EXTRAVERSION =
 NAME = Roaring Lionus
 
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termios.h
index 7fde0f88da88..51ed90be770a 100644
--- a/arch/alpha/include/asm/termios.h
+++ b/arch/alpha/include/asm/termios.h
@@ -72,9 +72,15 @@
 })
 
 #define user_termios_to_kernel_termios(k, u) \
-   copy_from_user(k, u, sizeof(struct termios))
+   copy_from_user(k, u, sizeof(struct termios2))
 
 #define kernel_termios_to_user_termios(u, k) \
+   copy_to_user(u, k, sizeof(struct termios2))
+
+#define user_termios_to_kernel_termios_1(k, u) \
+   copy_from_user(k, u, sizeof(struct termios))
+
+#define kernel_termios_to_user_termios_1(u, k) \
copy_to_user(u, k, sizeof(struct termios))
 
 #endif /* _ALPHA_TERMIOS_H */
diff --git a/arch/alpha/include/uapi/asm/ioctls.h 
b/arch/alpha/include/uapi/asm/ioctls.h
index f30c94ae1bdb..7ee8ab577e11 100644
--- a/arch/alpha/include/uapi/asm/ioctls.h
+++ b/arch/alpha/include/uapi/asm/ioctls.h
@@ -31,6 +31,11 @@
 #define TCXONC _IO('t', 30)
 #define TCFLSH _IO('t', 31)
 
+#define TCGETS2_IOR('T', 42, struct termios2)
+#define TCSETS2_IOW('T', 43, struct termios2)
+#define TCSETSW2   _IOW('T', 44, struct termios2)
+#define TCSETSF2   _IOW('T', 45, struct termios2)
+
 #define TIOCSWINSZ _IOW('t', 103, struct winsize)
 #define TIOCGWINSZ _IOR('t', 104, struct winsize)
 #defineTIOCSTART   _IO('t', 110)   /* start output, like 
^Q */
diff --git a/arch/alpha/include/uapi/asm/termbits.h 
b/arch/alpha/include/uapi/asm/termbits.h
index 879dd3589921..483c7ec2a879 100644
--- a/arch/alpha/include/uapi/asm/termbits.h
+++ b/arch/alpha/include/uapi/asm/termbits.h
@@ -25,6 +25,19 @@ struct termios {
speed_t c_ospeed;   /* output speed */
 };
 
+/* Alpha has identical termios and termios2 */
+
+struct termios2 {
+   tcflag_t c_iflag;   /* input mode flags */
+   tcflag_t c_oflag;   /* output mode flags */
+   tcflag_t c_cflag;   /* control mode flags */
+   tcflag_t c_lflag;   /* local mode flags */
+   cc_t c_cc[NCCS];/* control characters */
+   cc_t c_line;/* line discipline (== c_cc[19]) */
+   speed_t c_ispeed;   /* input speed */
+   speed_t c_ospeed;   /* output speed */
+};
+
 /* Alpha has matching termios and ktermios */
 
 struct ktermios {
@@ -147,6 +160,7 @@ struct ktermios {
 #define B300  00034
 #define B350  00035
 #define B400  00036
+#define BOTHER00037
 
 #define CSIZE  1400
 #define   CS5  
@@ -164,6 +178,9 @@ struct ktermios {
 #define CMSPAR   0100  /* mark or space (stick) parity */
 #define CRTSCTS  0200  /* flow control */
 
+#define CIBAUD 0760
+#define IBSHIFT16
+
 /* c_lflag bits */
 #define ISIG   0x0080
 #define ICANON 0x0100
diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index 8ec4dbbb50b0..47c3fb8d4313 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -361,6 +361,7 @@ CONFIG_ZISOFS=y
 CONFIG_UDF_FS=m
 CONFIG_MSDOS_FS=m
 CONFIG_VFAT_FS=y
+CONFIG_TMPFS_POSIX_ACL=y
 CONFIG_JFFS2_FS=y
 CONFIG_UBIFS_FS=y
 CONFIG_NFS_FS=y
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 20436972537f..a670c70f4def 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1092,8 +1092,6 @@ static void cpu_init_hyp_mode(void *dummy)
 
__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
__cpu_init_stage2();
-
-   kvm_arm_init_debug();
 }
 
 static void cpu_hyp_reinit(void)
@@ -1108,6 +1106,8 @@ static void cpu_hyp_reinit(void)
if (__hyp_get_vectors() == hyp_default_vectors)
cpu_init_hyp_mode(NULL);
}
+
+   kvm_arm_init_debug();
 }
 
 static void cpu_hyp_reset(void)
diff --git a/arch/mips/include/asm/mach-loongson64/irq.h 
b/arch/mips/include/asm/mach-loongson64/irq.h
index d18c45c7c394..19ff9ce46c02 100644
--- a/arch/mips/include/asm/mach-loongson64/irq.h
+++ b/arch/mips/include/asm/mach-loongson64/irq.h
@@ -9,7 +9,7 @@
 #define MIPS_CPU_IRQ_BASE 56
 
 #define LOONGSON_UART_IRQ   (MIPS_CPU_IRQ_BASE + 2) /* UART */
-#define LOONGSON_HT1_IRQ(MIPS_CPU_IRQ_BASE + 3) /* HT1 */
+#define LOONGSON_BRIDGE_IRQ (MIPS_CPU_IRQ_BASE + 3) /* CASCADE */
 #define LOONGSON_TIMER_IRQ  (MIPS_CPU_IRQ_BASE + 7) /* CPU Timer */
 
 #define LOONGSON_HT1_CFG_BASE  loongson_sysconf.ht_control_base
diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c
index 1723b1762297..e757f36cea6f 100644
--- a/arch/mips/kernel/crash.c
+++ b/arch/mips/kernel/crash.c
@@ -34,6 +34,9 @@ static

Re: [RFC PATCH 0/6] ASoC:Intel:Skylake: Enable HDaudio legacy fallback

[Takashi Iwai]

On Tue, 20 Nov 2018 22:36:38 +0100,
Pierre-Louis Bossart wrote:
> 
> This patchset is provided as an RFC and should not be merged as is
> (Turkey break in the USA and more validation needed). This is however
> a good time to gather comments. This work is the result of multiple
> email discussions to finally provide more flexibility for
> distributions to chose whether to stick with the legacy HDaudio driver
> or to enable the SST/Skylake driver for newer platforms (required
> e.g. for digital microphone support)
> 
> The patches add support for CoffeeLake, simplify the probe for the
> Skylake driver, introduce more compile-time granularity so that
> platforms can be selected individually and last provide a dynamic
> fallback mechanism when two drivers are registered for the same PCI
> ID.
> 
> When the SOF driver is released, the same mechanism will be used to
> enable the SOF-legacy fallback. There will be no plans to enable an
> SOF->SST falback.

This looks like a sensible way to go, thanks for working on this!

While the fallback stuff might need more testing, the other patches
(addition of CFL-S and split of configs) are rather systematic, so we
can merge this at first soonish.

And we may need a bit more comments in Kconfig help for the fallback
behavior.  Or document it properly and refer to it from Kconfig help.
The git commit log isn't present in the released kernel code, after
all.


thanks,

Takashi

> 
> Pierre-Louis Bossart (4):
>   ASoC: Intel: Skylake: stop init/probe if DSP is not present
>   ASoC: Intel: Skylake: remove useless tests on DSP presence
>   ASoC: Intel: Skylake: Add more platform granularity
>   ALSA: hda: add fallback capabilities for SKL+ platforms
> 
> Takashi Iwai (2):
>   ASoC: Intel: Skylake: Add CFL-S support
>   ALSA: hda: Allow fallback binding with legacy HD-audio for Intel SKL+
> 
>  include/sound/hdaudio.h|   6 +
>  sound/pci/hda/Kconfig  |  40 +++
>  sound/pci/hda/hda_controller.h |   2 +-
>  sound/pci/hda/hda_intel.c  |  51 ++--
>  sound/soc/intel/Kconfig|  86 --
>  sound/soc/intel/boards/Kconfig |  16 ++-
>  sound/soc/intel/skylake/skl-messages.c |   8 ++
>  sound/soc/intel/skylake/skl.c  | 154 +++--
>  8 files changed, 311 insertions(+), 52 deletions(-)
> 
> -- 
> 2.17.1
> 

Re: [PATCH 3.18 00/90] 3.18.126-stable review

[Greg Kroah-Hartman]

On Tue, Nov 20, 2018 at 12:38:29PM -0800, Guenter Roeck wrote:
> On Mon, Nov 19, 2018 at 05:28:42PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.126 release.
> > There are 90 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Nov 21 16:25:28 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 138 pass: 134 fail: 4
> Failed builds: 
>   i386:allyesconfig 
>   i386:allmodconfig 
>   sparc64:allmodconfig 
>   sparc64:defconfig 
> Qemu test results:
>   total: 221 pass: 209 fail: 12
> Failed tests: 
>   sparc64:sun4u:smp:initrd 
>   sparc64:sun4u:smp:ata:rootfs 
>   sparc64:sun4u:smp:mmc:rootfs 
>   sparc64:sun4u:smp:nvme:rootfs 
>   sparc64:sun4u:smp:scsi[MEGASAS]:rootfs
>   sparc64:sun4u:smp:usb-xhci:rootfs 
>   sparc64:sun4u:smp:usb-uas-xhci:rootfs 
>   sparc64:sun4u:smp:virtio-pci:rootfs 
>   sparc64:sun4v:smp:ata:rootfs 
>   sparc64:sun4v:smp:nvme:rootfs 
>   sparc64:sun4u:nosmp:ata:rootfs 
>   sparc64:sun4v:nosmp:ata:rootfs
> 
> Details are available at https://kerneltests.org/builders/.

Ok, sorry about that, I think these should now all be fixed.  I've
pushed out a -rc2 with some changes.

thanks,

greg k-h

Re: [PATCH v2] regulator: wm8994: Don't use devres for enable GPIOs

[Marek Szyprowski]

Hi Charles,

On 2018-11-21 11:13, Charles Keepax wrote:
> The regulator core takes over managing the lifetime of the enable GPIO
> once the regulator is registered. As such we shouldn't register the
> enable GPIO using devm, or it will be freed twice.
>
> Reported-by: Marek Szyprowski 
> Signed-off-by: Charles Keepax 
> ---
>
> Again only build tested.

Thanks for the patch. It fixes the observed GPIOlib warning.

Tested-by: Marek Szyprowski 

It might sense to add:

Fixes: 1d2f46814d20 ("regulator: wm8994: Pass descriptor instead of GPIO
number")


Linus, Mark: Similar issue is probably in the other regulator drivers,
which use enable GPIO allocated by devm_gpio_get*(). This driver is
simply the first one, which we observed it. It would be great if one
would take a look into regulator_register() error path, because for some
cases the GPIO will be freed, for the other - not.

> Thanks,
> Charles
>
>  drivers/regulator/wm8994-regulator.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/regulator/wm8994-regulator.c 
> b/drivers/regulator/wm8994-regulator.c
> index d7fec533c4032..46e6b4ee1491a 100644
> --- a/drivers/regulator/wm8994-regulator.c
> +++ b/drivers/regulator/wm8994-regulator.c
> @@ -147,11 +147,14 @@ static int wm8994_ldo_probe(struct platform_device 
> *pdev)
>   config.regmap = wm8994->regmap;
>   config.init_data = &ldo->init_data;
>  
> - /* Look up LDO enable GPIO from the parent device node */
> - gpiod = devm_gpiod_get_optional(pdev->dev.parent,
> - id ? "wlf,ldo2ena" : "wlf,ldo1ena",
> - GPIOD_OUT_LOW |
> - GPIOD_FLAGS_BIT_NONEXCLUSIVE);
> + /*
> +  * Look up LDO enable GPIO from the parent device node, we don't
> +  * use devm because the regulator core will free the GPIO
> +  */
> + gpiod = gpiod_get_optional(pdev->dev.parent,
> +id ? "wlf,ldo2ena" : "wlf,ldo1ena",
> +GPIOD_OUT_LOW |
> +GPIOD_FLAGS_BIT_NONEXCLUSIVE);
>   if (IS_ERR(gpiod))
>   return PTR_ERR(gpiod);
>   config.ena_gpiod = gpiod;
> @@ -184,6 +187,7 @@ static int wm8994_ldo_probe(struct platform_device *pdev)
>   return 0;
>  
>  err:
> + gpiod_put(gpiod);
>   return ret;
>  }
>  

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH v10 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

[Taniya Das]

Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by the hardware engine.

Signed-off-by: Taniya Das 
---
 .../bindings/cpufreq/cpufreq-qcom-hw.txt   | 172 +
 1 file changed, 172 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt 
b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
new file mode 100644
index 000..90e396b
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
@@ -0,0 +1,172 @@
+Qualcomm Technologies, Inc. CPUFREQ Bindings
+
+CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI)
+SoCs to manage frequency in hardware. It is capable of controlling frequency
+for multiple clusters.
+
+Properties:
+- compatible
+   Usage:  required
+   Value type: 
+   Definition: must be "qcom,cpufreq-hw".
+
+- clocks
+   Usage:  required
+   Value type:  From common clock binding.
+   Definition: clock handle for XO clock and GPLL0 clock.
+
+- clock-names
+   Usage:  required
+   Value type:  From common clock binding.
+   Definition: must be "xo", "cpu_clk".
+
+- reg
+   Usage:  required
+   Value type: 
+   Definition: Addresses and sizes for the memory of the HW bases in
+   each frequency domain.
+- reg-names
+   Usage:  Optional
+   Value type: 
+   Definition: Frequency domain name i.e.
+   "freq-domain0", "freq-domain1".
+
+- freq-domain-cells:
+   Usage:  required.
+   Definition: Number of cells in a freqency domain specifier.
+
+* Property qcom,freq-domain
+Devices supporting freq-domain must set their "qcom,freq-domain" property with
+phandle to a cpufreq_hw followed by the Domain ID(0/1) in the CPU DT node.
+
+
+Example:
+
+Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch
+DCVS state together.
+
+/ {
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   CPU0: cpu@0 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   next-level-cache = <&L2_0>;
+   qcom,freq-domain = <&cpufreq_hw 0>;
+   L2_0: l2-cache {
+   compatible = "cache";
+   next-level-cache = <&L3_0>;
+   L3_0: l3-cache {
+ compatible = "cache";
+   };
+   };
+   };
+
+   CPU1: cpu@100 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x100>;
+   enable-method = "psci";
+   next-level-cache = <&L2_100>;
+   qcom,freq-domain = <&cpufreq_hw 0>;
+   L2_100: l2-cache {
+   compatible = "cache";
+   next-level-cache = <&L3_0>;
+   };
+   };
+
+   CPU2: cpu@200 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x200>;
+   enable-method = "psci";
+   next-level-cache = <&L2_200>;
+   qcom,freq-domain = <&cpufreq_hw 0>;
+   L2_200: l2-cache {
+   compatible = "cache";
+   next-level-cache = <&L3_0>;
+   };
+   };
+
+   CPU3: cpu@300 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x300>;
+   enable-method = "psci";
+   next-level-cache = <&L2_300>;
+   qcom,freq-domain = <&cpufreq_hw 0>;
+   L2_300: l2-cache {
+   compatible = "cache";
+   next-level-cache = <&L3_0>;
+   };
+   };
+
+   CPU4: cpu@400 {
+   device_type = "cpu";
+   compatible = "qcom,kryo385";
+   reg = <0x0 0x400>;
+   enable-method = "psci";
+   next-level-cache = <&L2_400>;
+   qcom,freq-domain = <&cpufreq_hw 1>;
+   L2_400: l2-cache {
+   compatible =

[PATCH v10 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

[Taniya Das]

The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
driver interface for this hardware engine.

Signed-off-by: Saravana Kannan 
Signed-off-by: Taniya Das 
---
 drivers/cpufreq/Kconfig.arm   |  11 ++
 drivers/cpufreq/Makefile  |   1 +
 drivers/cpufreq/qcom-cpufreq-hw.c | 346 ++
 3 files changed, 358 insertions(+)
 create mode 100644 drivers/cpufreq/qcom-cpufreq-hw.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 4e1131e..688f102 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -114,6 +114,17 @@ config ARM_QCOM_CPUFREQ_KRYO

  If in doubt, say N.

+config ARM_QCOM_CPUFREQ_HW
+   tristate "QCOM CPUFreq HW driver"
+   depends on ARCH_QCOM || COMPILE_TEST
+   help
+ Support for the CPUFreq HW driver.
+ Some QCOM chipsets have a HW engine to offload the steps
+ necessary for changing the frequency of the CPUs. Firmware loaded
+ in this engine exposes a programming interface to the OS.
+ The driver implements the cpufreq interface for this HW engine.
+ Say Y if you want to support CPUFreq HW.
+
 config ARM_S3C_CPUFREQ
bool
help
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index d5ee456..789b2e0 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)   += omap-cpufreq.o
 obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)   += pxa2xx-cpufreq.o
 obj-$(CONFIG_PXA3xx)   += pxa3xx-cpufreq.o
 obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO)+= qcom-cpufreq-kryo.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)  += qcom-cpufreq-hw.o
 obj-$(CONFIG_ARM_S3C2410_CPUFREQ)  += s3c2410-cpufreq.o
 obj-$(CONFIG_ARM_S3C2412_CPUFREQ)  += s3c2412-cpufreq.o
 obj-$(CONFIG_ARM_S3C2416_CPUFREQ)  += s3c2416-cpufreq.o
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..6390e85
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,346 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE   32
+#define CLK_HW_DIV 2
+
+/* Register offsets */
+#define REG_ENABLE 0x0
+#define REG_LUT_TABLE  0x110
+#define REG_PERF_STATE 0x920
+
+struct cpufreq_qcom {
+   struct cpufreq_frequency_table *table;
+   void __iomem *perf_base;
+   cpumask_t related_cpus;
+   unsigned int max_cores;
+   unsigned long xo_rate;
+   unsigned long cpu_hw_rate;
+};
+
+static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
+
+static int
+qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+unsigned int index)
+{
+   struct cpufreq_qcom *c = policy->driver_data;
+
+   writel_relaxed(index, c->perf_base);
+
+   return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+   struct cpufreq_qcom *c;
+   struct cpufreq_policy *policy;
+   unsigned int index;
+
+   policy = cpufreq_cpu_get_raw(cpu);
+   if (!policy)
+   return 0;
+
+   c = policy->driver_data;
+
+   index = readl_relaxed(c->perf_base);
+   index = min(index, LUT_MAX_ENTRIES - 1);
+
+   return policy->freq_table[index].frequency;
+}
+
+static unsigned int
+qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   struct cpufreq_qcom *c = policy->driver_data;
+   int index;
+
+   index = policy->cached_resolved_idx;
+   if (index < 0)
+   return 0;
+
+   writel_relaxed(index, c->perf_base);
+
+   return policy->freq_table[index].frequency;
+}
+
+static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
+{
+   struct cpufreq_qcom *c;
+
+   c = qcom_freq_domain_map[policy->cpu];
+   if (!c) {
+   pr_err("No scaling support for CPU%d\n", policy->cpu);
+   return -ENODEV;
+   }
+
+   cpumask_copy(policy->cpus, &c->related_cpus);
+
+   policy->fast_switch_possible = true;
+   policy->freq_table = c->table;
+   policy->driver_data = c;
+
+   return 0;
+}
+
+static struct freq_attr *qcom_cpufreq_hw_attr[] = {
+   &cpufreq_freq_attr_scaling_available_freqs,
+   &cpufreq_freq_attr_scaling_boost_freqs,
+   NULL
+};
+
+static struct cpufreq_driver cpufreq_qcom_hw_driver = {
+   .flags  = CPUFREQ_STICKY | CPUFREQ_NEED_INITIAL_FREQ_CHECK |
+ CPUFREQ_HAVE_GOVERNOR_PER_POLICY,
+  

[PATCH v10 0/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

[Taniya Das]

 [v10]
  * Update Documentation binding for cpufreq node.
  * Make the driver 'tristate' instead of 'bool' and update code.
  * Update the clock name to reflect the hardware name.
  * Remove support for varying offset.

 [v9]
  * Update the Documentation binding for freq-domain-cells & cpufreq node.
  * Address comments in Kconfig.arm & Makefile.
  * Remove include file & MODULE_DESCRIPTION not required.
  * Fix the code for 'of_node_put(cpu_np)'.

 [v8]
   * Address comments to update code to take cpufreq_hw phandle and index from
 the CPU nodes.
   * Updated the Documentation for the above change in DT.
   * Updated logic for assigning 'qcom_freq_domain_map' for related CPUs.
   * Clock input to the HW block is taken from DT which has been updated in
 code and Device tree documentation.

 [v7]
   * Updated the logic to check for related CPUs.

 [v6]
   * Renamed match table 'qcom_cpufreq_hw_match'.
   * Renamed 'qcom_read_lut' to 'qcom_cpufreq_hw_read_lut'.
   * Updated the logic to check for related CPUs at the beginning of the
 'qcom_cpu_resources_init'.
   * Use devm_ioremap_resource instead of devm_ioremap.
   * Update the use of of_node_put to handle error conditions.
   * Use policy->cached_resolved_idx in fast switch callback.
   * Keep precalculated offsets 'reg_bases'.
   * XO clock is taken from Device tree.
   * Update documentation binding for clocks/clock-names.
   * Minor comments in Kconfig.arm.
   * Comments to move dev_info to dev_dbg.

 [v5]
   * Remove mapping different register regions of perf/lut/enable,
 instead map the entire HW region.
   * Add reg_offset/cpufreq_qcom_std_offsets to be supplied as device data.
   * Check of src == 0 during lut read.
   * Add of_node_put(cpu_np) in qcom_get_related_cpus
   * Update the qcom_cpu_resources_init for register offset data,
 and cleanup the related cpus to keep a single copy of CPUfreq.
   * Replace FW with HW, update Kconfig, rename filename qcom-cpufreq-hw.c
   * Update the documentation binding to reflect the changes of mapping the
   * entire HW region.

 [v4]
   * Fixed console messages as per comments.
   * Return error from qcom_resources_init()
 in the cases where failed to get frequency domain.
   * Rename cpu_dev to cpu_np in qcom_resources_init,
 qcom_get_related_cpus(). Also use temp variable freq_np in
 qcom_get_related_cpus().
   * Update qcom_cpufreq_fw_get() to use the policy data to incoporate
 the hotplug use case.
   * Update code to use of fast_switching.
   * Check for !c->max_cores instead of cpumask_empty in
 qcom_get_related_cpus().
   * Update the logic of assigning 'c' to qcom_freq_domain_map[cpu].

 [v3]
   * Remove index check from 'qcom_cpufreq_fw_target_index'.
   * Update the Documentation binding to add the platform specific properties in
 the CPU nodes, node name "qcom,freq-domain".
   * Update return value to '0' from -ENODEV from 'qcom_cpufreq_fw_get'.
   * Update the logic for boost frequency to use local variables instead of
 cpufreq driver data in 'qcom_read_lut'.
   * Update the logic in 'qcom_get_related_cpus' to find the related cpus.
   * Update the reg-names to remove "_base" and also update the binding with the
 description of these registers.
   * Update the logic in 'qcom_resources_init' to address the new device tree
 notation of handling the frequency domain phandles.

 [v2]
   * Fixed the alignment issues in "qcom_cpufreq_fw_target_index" for dev_err 
and
 also for "qcom_cpu_resources_init".
   * Removed ret = 0 from qcom_get_related_cpus and added to check for
 cpu_mask_empty to return -ENOENT.
   * Fixes qcom_cpu_resources_init function
   * Remove initialization of 'index'
   * Check for valid 'c'
   * Removed initialization of 'prev_cc' from 'qcom_read_lut'.

Taniya Das (2):
  dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings
  cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

 .../bindings/cpufreq/cpufreq-qcom-hw.txt   | 172 ++
 drivers/cpufreq/Kconfig.arm|  11 +
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/qcom-cpufreq-hw.c  | 346 +
 4 files changed, 530 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
 create mode 100644 drivers/cpufreq/qcom-cpufreq-hw.c

--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the  Linux Foundation.

Re: perf tools: remove option --tail-synthesize ?

[Jiri Olsa]

On Wed, Nov 21, 2018 at 07:45:28AM +, Song Liu wrote:
> Hi,
> 
> I found perf-record --tail-synthesize without --overwrite breaks symbols
> for perf-script, perf-report, etc. For example:
> 
> [root@]# ~/perf record -ag --tail-synthesize -- sleep 1
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 1.129 MB perf.data (3531 samples) ]
> [root@]# ~/perf script | head
> swapper 0 [000] 1250675.051971:  1 cycles:ppp:
> 81009e15 [unknown] ([unknown])
> 81196b19 [unknown] ([unknown])
> 81196579 [unknown] ([unknown])
> 81110ca7 [unknown] ([unknown])
> 81a01f4a [unknown] ([unknown])
> 81a017bf [unknown] ([unknown])
> 8180e17a [unknown] ([unknown])
> 
> perf-record with --overwrite does NOT have this issue.

actualy I think that now it works properly, if you turn on
task and mmap events, you'll see the samples get resolved
right after aux events are processed:

[root@krava perf]# ./perf script --show-info --show-task-events 
--show-mmap-events
...
swapper 0 [007] 620566.187355:  64821 cycles:ppp:
ab0b4d7c [unknown] ([unknown])
aba01b1f [unknown] ([unknown])
ab75d567 [unknown] ([unknown])
ab0e1f56 [unknown] ([unknown])
ab0e216f [unknown] ([unknown])
ab050dc7 [unknown] ([unknown])
abd5 [unknown] ([unknown])

swapper 0 [000] 0.00: PERF_RECORD_MMAP -1/0: 
[0xab00(0x152c8000) @ 0xab00]: x [kernel.kallsyms]_text
swapper 0 [000] 0.00: PERF_RECORD_MMAP -1/0: 
[0xc02c8000(0x4000) @ 0]: x 
/lib/modules/4.18.17-200.fc28.x86_64/kernel/drivers/thermal/int340x_thermal/int3403_thermal.ko.xz
swapper 0 [000] 0.00: PERF_RECORD_MMAP -1/0: 
[0xc02cd000(0x4000) @ 0]: x 
/lib/modules/4.18.17-200.fc28.x86_64/kernel/drivers/thermal/intel_pch_thermal.ko.xz
...
ext4-rsv-conver 0 [000] 0.00: PERF_RECORD_COMM: 
ext4-rsv-conver:989/989
perf 20063 [005] 620566.187438:1056712 cycles:ppp:
ab1f605d filemap_map_pages+0x9d 
(/usr/lib/debug/lib/modules/4.18.17-200.fc28.x86_64/vmlinux)
ab23aaa8 __handle_mm_fault+0x1018 
(/usr/lib/debug/lib/modules/4.18.17-200.fc28.x86_64/vmlinux)
ab23ae7a handle_mm_fault+0xda 
(/usr/lib/debug/lib/modules/4.18.17-200.fc28.x86_64/vmlinux)
ab06ac90 __do_page_fault+0x240 
(/usr/lib/debug/lib/modules/4.18.17-200.fc28.x86_64/vmlinux)
ab06af62 do_page_fault+0x32 
(/usr/lib/debug/lib/modules/4.18.17-200.fc28.x86_64/vmlinux)
aba010ee page_fault+0x1e 
(/usr/lib/debug/lib/modules/4.18.17-200.fc28.x86_64/vmlinux)
...

if you record with --overwrite and --tail-synthesize the aux events
will go to the top of the perf.data, so all's good

> 
> After digging into this, I found this issue is introduced by commit
> a73e24d240bc136619d382b1268f34d75c9d25ce.

right, we got rid of that, because it will store the 'current/live'
server mmaps for report/script, which is not what you want

> Reverting this commit does fix this issue. However, on a second thought,
> I feel it is probably better just drop --tail-synthesize, as it doesn't
> make much sense without --overwrite. All we need is to do tail_synthesize
> when --overwrite is set.
> 
> Thoughts?

maybe we should make --tail-synthesize non optionable for --overwrite,
and get rid of that option completely.. Wang, any idea?

but definitelly not allow that for non overwrite

thanks,
jirka

Re: [PATCH v2] x86/fpu: Disable BH while while loading FPU registers in __fpu__restore_sig()

[Borislav Petkov]

On Wed, Nov 21, 2018 at 11:11:18AM +0500, Victoria Anosova wrote:
> Glad this come to kernel. We've already applied this patch.

The current version, with the bottom half toggling or the original one
with preempt_disable/enable?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v2] regulator: wm8994: Don't use devres for enable GPIOs

[Charles Keepax]

On Wed, Nov 21, 2018 at 11:42:06AM +0100, Marek Szyprowski wrote:
> On 2018-11-21 11:13, Charles Keepax wrote:
> Linus, Mark: Similar issue is probably in the other regulator drivers,
> which use enable GPIO allocated by devm_gpio_get*(). This driver is
> simply the first one, which we observed it. It would be great if one
> would take a look into regulator_register() error path, because for some
> cases the GPIO will be freed, for the other - not.
> 

Yeah I have managed to reproduce the issue on another on of our
boards now, so it definitely affects other drivers we have. Its a
bit sneaky since the GPIO core only seems to warn on the additional
free if you have some additional debug turned on which masks the
issue most of the time.

I will have a bit of a look and see what else might be affected.

Thanks,
Charles

Re: [PATCH] ARM: dts: at91: sama5d2: use the divided clock for SMC

[Alexandre Belloni]

On 20/11/2018 21:40:49+0100, Alexandre Belloni wrote:
> On 20/11/2018 19:01:32+0100, Romain Izard wrote:
> > Le mar. 20 nov. 2018 à 18:16, Alexandre Belloni
> >  a écrit :
> > >
> > > Hello Romain,
> > >
> > > On 20/11/2018 17:57:37+0100, Romain Izard wrote:
> > > > The SAMA5D2 is different from SAMA5D3 and SAMA5D4, as there are two
> > > > different clocks for the peripherals in the SoC. The Static Memory
> > > > controller is connected to the divided master clock.
> > > >
> > > > Unfortunately, the device tree does not correctly show this and uses the
> > > > master clock directly. This clock is then used by the code for the NAND
> > > > controller to calculate the timings for the controller, and we end up 
> > > > with
> > > > slow NAND Flash access.
> > > >
> > > > Fix the device tree, and the performance of Flash access is improved.
> > > >
> > > > Signed-off-by: Romain Izard 
> > > > ---
> > > >  arch/arm/boot/dts/sama5d2.dtsi | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sama5d2.dtsi 
> > > > b/arch/arm/boot/dts/sama5d2.dtsi
> > > > index 61f68e5c48e9..b405992eb601 100644
> > > > --- a/arch/arm/boot/dts/sama5d2.dtsi
> > > > +++ b/arch/arm/boot/dts/sama5d2.dtsi
> > > > @@ -308,7 +308,7 @@
> > > > 0x1 0x0 0x6000 0x1000
> > > > 0x2 0x0 0x7000 0x1000
> > > > 0x3 0x0 0x8000 0x1000>;
> > > > - clocks = <&mck>;
> > > > + clocks = <&h32ck>;
> > >
> > > You will have to rebase on top of at91-dt. And if I'm not mistaken, this
> > > line should be:
> > >
> > > +   clocks = <&pmc PMC_TYPE_CORE PMC_MCK2>;
> > >
> > > >   status = "disabled";
> > > >
> > > >   nand_controller: nand-controller {
> > 
> > I guess you're right but this will only reach mainline in 4.21. I get slow
> > flash access with 4.19 as well...
> >
> 
> Ok, this is super annoying, I'll try to get that as fixes on v4.20 and
> I'll rebase at91-dt on top of that...
> 

So, I did that just now.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com