Re: [PATCH] m68k/mac: Use correct PMU response format

[Geert Uytterhoeven]

Hi Finn,

On Fri, Aug 24, 2018 at 4:02 AM Finn Thain  wrote:
> Now that the 68k Mac port has adopted the via-pmu driver, it must decode
> the PMU response accordingly otherwise the date and time will be wrong.
>
> Signed-off-by: Finn Thain 

Looks good to me, so I will queue as a fix for v4.19.

I guess the proper Fixes tag is:

Fixes: ebd722275f9cfc67 ("macintosh/via-pmu: Replace via-pmu68k driver
with via-pmu driver")

Can you please confirm? Thanks!

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: 32-bit PTI with THP = userspace corruption

[Joerg Roedel]

On Fri, Aug 31, 2018 at 07:12:44AM +0300, Meelis Roos wrote:
> > Thanks for the report! I'll try to reproduce the problem tomorrow and
> > investigate it. Can you please check if any of the kernel configurations
> > that show the bug has CONFIG_X86_PAE set? If not, can you please test
> > if enabling this option still triggers the problem?
> 
> Will check, but out of my memery there were 2 G3 HP Proliants that did 
> not fit into the pattern (problem did not appear). I have more than 4G 
> RAM in those and HIGHMEM_4G there, maybe that's it?

Yeah, I thought a bit about it, and for legacy paging the PMD paging
level is the root-level where we do the mirroring between kernel and
user page-table for PTI. This means we also need to collect A/D bits
from both entries, which we don't do yet.

But that all means it shouldn't happen with CONFIG_X86_PAE=y.

I'll try to reproduce and work on a fix.

Thanks,

Joerg

Re: 32-bit PTI with THP = userspace corruption

[Meelis Roos]

> > I am seeing userland corruption and application crashes on multiple 
> > 32-bit machines with 4.19-rc1+git. The machines vary: PII, PIII, P4. 
> > They are all Intel. AMD Duron/Athlon/AthlonMP have been fine in my tests 
> > so far (may be configuration dependent).
> 
> Thanks for the report! I'll try to reproduce the problem tomorrow and
> investigate it. Can you please check if any of the kernel configurations
> that show the bug has CONFIG_X86_PAE set? If not, can you please test
> if enabling this option still triggers the problem?

PAE was not visible itself, but when I changed HIGHMEM_4G to 
HIGHMEM_64G, X86_PAE was also selected and the resutling kernel works.

Also, I verified that the olid proliants with 6G RAM already have 
HIGHMEM_64G set and they do not exhibit the problem either.

-- 
Meelis Roos (mr...@linux.ee)

Re: [PATCH] m68k/mac: Use correct PMU response format

[Finn Thain]

On Fri, 31 Aug 2018, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Fri, Aug 24, 2018 at 4:02 AM Finn Thain  wrote:
> > Now that the 68k Mac port has adopted the via-pmu driver, it must decode
> > the PMU response accordingly otherwise the date and time will be wrong.
> >
> > Signed-off-by: Finn Thain 
> 
> Looks good to me, so I will queue as a fix for v4.19.
> 

Thanks!

> I guess the proper Fixes tag is:
> 
> Fixes: ebd722275f9cfc67 ("macintosh/via-pmu: Replace via-pmu68k driver
> with via-pmu driver")
> 
> Can you please confirm? Thanks!
> 

If you want to add a 'fixes' tag, that would be it. I omitted the tag 
because a -stable tree isn't needed for this. I don't mind either way.

-- 

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

Re: [PATCH 01/21] staging:rtl8192u: Rename AdvCoding - Style

[Dan Carpenter]

On Thu, Aug 30, 2018 at 10:35:37PM +0100, John Whitmore wrote:
> On Thu, Aug 30, 2018 at 11:26:28AM +0300, Dan Carpenter wrote:
> > On Thu, Aug 30, 2018 at 11:23:05AM +0300, Dan Carpenter wrote:
> > > On Wed, Aug 29, 2018 at 09:35:27PM +0100, John Whitmore wrote:
> > > > Rename the bit field element AdvCoding, as it causes a checkpatch issue
> > > > with CamelCase naming. As the element is not actually used in code it
> > > > has been renamed to 'not_used_adv_coding'.
> > > > 
> > > > The single line of code which initialises the bit has been removed,
> > > > as the  field is unused.
> > > > 
> > > > This is a purely coding style change which should have no impact
> > > > on runtime code execution.
> > > > 
> > > > Signed-off-by: John Whitmore 
> > > > ---
> > > >  drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 2 +-
> > > >  drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 1 -
> > > >  2 files changed, 1 insertion(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
> > > > b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > index 64d5359cf7e2..66a0274077d3 100644
> > > > --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> > > > @@ -39,7 +39,7 @@ enum ht_extension_chan_offset {
> > > >  
> > > >  struct ht_capability_ele {
> > > > //HT capability info
> > > > -   u8  AdvCoding:1;
> > > > +   u8  not_used_adv_coding:1;
> > > 
> > > I can't review any more of this patchset when this is the first line...
> > > 
> > 
> > That email wasn't very clear.  If you think some of your patches are
> > going to be more controversial than others, put them at the very end so
> > we can at least apply part of the patchset.
> > 
> > regards,
> > dan carpenter
> > 
> 
> Thanks for the clarification, I needed it ;)
> 
> I'm not sure I consider any of the patches in the series as being
> controversial. They are all just simple name changes of member
> variables. As a number of the variables are not used in code the names
> have been changed to reflect that fact. If I'd renamed them and left out
> the 'not_used_' prefix would the changes not be controversial? I
> don't think the fact that the members are unused is a biggy.
> 

I didn't like the new name at all.

Quite often when I review these I just use a script to verify that we're
only renaming variables and not doing code changes outside of that.  But
if I review it by hand I would have seen that the variable was not used
and investigated what was going on.

> What might appear to be controversial is that I didn't simply remove
> the members. I haven't done that because I'm not yet satisfied that
> the structure's size is insignificant. As soon as I am happy that the
> size of the structure is not important, to runtime code execution,
> there'll be a patch which removes a number of 'not_used_...' members
> from a structure.
> 
> Alternatively if the size if important there might be a patch which
> renames a number of unused bitfield members to reserved_1, reserved_2,
> reserved_3

That's a good question.  If a struct is part of the use space API or the
network protocol or defined by the hardware then we can't change the
layout.

One thing I look for is if the struct has pointers which aren't tagged
as __user pointers then it's internal to the kernel.  Unfortunately that
doesn't help here.  Network protocol is all endian specific and this
struct is not.  But again that doesn't help much because it could just
be a bug.  If the struct is __packed then obviously the layout matters.

So I don't know.  I think you're right that actually we can't change
the layout.  The code is really a mess, so it's possible I have misread.

regards,
dan carpenter

Re: [PATCH v3 00/38] Tegra SDHCI add support for HS200 and UHS signaling

[Adrian Hunter]

On 30/08/18 18:06, Aapo Vienamo wrote:
> Hi all,
> 
> This series implements support for faster signaling modes on Tegra
> SDHCI controllers. This series consist of several parts: changes
> required for 1.8 V signaling and pad control, pad calibration, and
> tuning. Following earlies patch sets have been merged into this
> larger set: "Tegra PMC pinctrl pad configuration", "Tegra SDHCI enable
> 1.8 V signaling on Tegar210 and Tegra186", "Tegra SDHCI update the
> padautocal procedure". Also the patches for enabling SDHCI tuning
> are added.

For sdhci-related patches 11 thru' 27

Acked-by: Adrian Hunter 


> 
> Changelog:
> v3:
>   - Remove tegra_sdhci_writew() from tegra210_sdhci_ops to prevent
> incorrect access to SDHCI_TRANSFER_MODE on Tegra210.
>   - Drop "mmc: sdhci: Add a quirk to skip clearing the transfer
> mode register on tuning". This is no longer needed since it
> was effectively a workaround to the behavior caused by
> tegra_sdhci_writew() on Tegra210.
>   - Implement disabling of the card clock during issuing of the
> tuning command in tegra210_sdhci_writew().
>   - Drop "mmc: sdhci: Add a quirk to disable card clock during
> tuning". This is now implemented in the sdhci-tegra driver.
>   
> v2:
>   - Fix grammar in PMC device tree bindings docs
>   - Remove a stray line from tegra sdhci bindings
>   - Cosmetic changes to PMC pinctrl driver
>   - Fix a typo in "soc/tegra: pmc: Implement
> tegra_io_pad_is_powered()" commit message
>   - Declare mask and value on the same line in
> tegra_io_pad_is_powered()
>   - Move the call to tegra_sdhci_is_pad_and_regulator_valid() to
> inside the if condition in tegra_sdhci_reset()
>   - Use usleep_range() in tegra_sdhci_configure_cal_pad()
>   - Move sdhci_writel() out of the enable if-else body in
> tegra_sdhci_configure_cal_pad()
>   - Add a delay before starting polling in
> tegra_sdhci_pad_autocalib()
>   - Use usleep_range() in tegra_sdhci_set_tap()
>   - Rename orig_enabled to status in
> tegra_sdhci_configure_card_clk()
>   - Fix if condition wrapping alignment in tegra_sdhci_set_tap()
> 
> v1:
>   - Probe the regulator voltage capabilities to determine whether pinctrl
> is needed in tegra_sdhci_r eset
>   - Don't remove tegra_sdhci_voltage_switch()
>   - Use dev_warn() in tegra_sdhci_init_pinctrl_info()
>   - Don't change start_signal_voltage_switch callback if pinctrl info
> invalid
>   - Only call udelay(1) on enable in tegra_sdhci_configure_cal_pad()
>   - Add nvidia, prefix to pad autocal offset dt props in the example
> 
> See the original patch sets for earlier changelogs.
> 
> 
> Aapo Vienamo (38):
>   dt-bindings: Add Tegra PMC pad configuration bindings
>   dt-bindings: mmc: tegra: Add pad voltage control properties
>   dt-bindings: Add Tegra SDHCI pad pdpu offset bindings
>   dt-bindings: mmc: Add Tegra SDHCI sampling trimmer values
>   soc/tegra: pmc: Fix pad voltage configuration for Tegra186
>   soc/tegra: pmc: Factor out DPD register bit calculation
>   soc/tegra: pmc: Implement tegra_io_pad_is_powered()
>   soc/tegra: pmc: Use X macro to generate IO pad tables
>   soc/tegra: pmc: Remove public pad voltage APIs
>   soc/tegra: pmc: Implement pad configuration via pinctrl
>   mmc: tegra: Reconfigure pad voltages during voltage switching
>   mmc: tegra: Poll for calibration completion
>   mmc: tegra: Set calibration pad voltage reference
>   mmc: tegra: Power on the calibration pad
>   mmc: tegra: Disable card clock during pad calibration
>   mmc: tegra: Program pad autocal offsets from dt
>   mmc: tegra: Perform pad calibration after voltage switch
>   mmc: tegra: Enable pad calibration on Tegra210 and Tegra186
>   mmc: tegra: Add a workaround for tap value change glitch
>   mmc: tegra: Parse default trim and tap from dt
>   mmc: tegra: Configure default tap values
>   mmc: tegra: Configure default trim value on reset
>   mmc: tegra: Use standard SDHCI tuning on Tegra210 and Tegra186
>   mmc: tegra: Remove tegra_sdhci_writew() from tegra210_sdhci_ops
>   mmc: tegra: Disable card clock during tuning cmd on Tegra210
>   mmc: tegra: Enable UHS and HS200 modes for Tegra210
>   mmc: tegra: Enable UHS and HS200 modes for Tegra186
>   arm64: dts: Add Tegra210 sdmmc pinctrl voltage states
>   arm64: dts: Add Tegra186 sdmmc pinctrl voltage states
>   arm64: dts: tegra210-p2180: Allow ldo2 to go down to 1.8 V
>   arm64: dts: tegra210-p2180: Correct sdmmc4 vqmmc-supply
>   arm64: dts: tegra210-p2597: Remove no-1-8-v from sdmmc1
>   arm64: dts: tegra186: Add sdmmc pad auto calibration offsets
>   arm64: dts: tegra210: Add sdmmc pad auto calibration offsets
>   arm64: dts: tegra210: Add SDHCI tap and trim values
>   arm64: dts: tegra186: Add SDHCI tap and trim values
>   arm64: dts: tegra186: Assign clocks for sdmmc1 and sdmmc4
>   arm64: dts: teg

[Question] When should a driver issue STOP condition?

[Masahiro Yamada]

Hi.


A problem was found in my drivers.


Before sending out patches, please let me
ask a question to make sure the right fix.


The problem is, my driver is forcibly setting
STOP condition unless the next message is read.

Please see this line:
https://github.com/torvalds/linux/blob/v4.19-rc1/drivers/i2c/busses/i2c-uniphier-f.c#L405


Obviously, it it disturbing the I2C_RDWR ioctl functionality.

Documentation/i2c/dev-interface says:
ioctl(file, I2C_RDWR, struct i2c_rdwr_ioctl_data *msgset)
  Do combined read/write transaction without stop in between.


So, I want to be sure
what a driver should (or should not) do.

A driver should issue STOP when and only when the I2C_M_STOP flag
is set in msg->flags.

Is this correct?


In other words, do user-space programs need to explicitly set
I2C_M_STOP where the STOP condition is desired?



Then, another question popped up.

User-space programs can send a single transaction
with read() / write().

I2C_M_STOP is not set in this case.


If a driver does not take care of the STOP condition at all,
the I2C bus is never released.
Is this the right thing to do?


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] m68k/mac: Use correct PMU response format

[Geert Uytterhoeven]

Hi Finn,

On Fri, Aug 31, 2018 at 9:12 AM Finn Thain  wrote:
> On Fri, 31 Aug 2018, Geert Uytterhoeven wrote:
> > On Fri, Aug 24, 2018 at 4:02 AM Finn Thain  
> > wrote:
> > > Now that the 68k Mac port has adopted the via-pmu driver, it must decode
> > > the PMU response accordingly otherwise the date and time will be wrong.
> > >
> > > Signed-off-by: Finn Thain 
> >
> > Looks good to me, so I will queue as a fix for v4.19.
> >
>
> Thanks!
>
> > I guess the proper Fixes tag is:
> >
> > Fixes: ebd722275f9cfc67 ("macintosh/via-pmu: Replace via-pmu68k driver
> > with via-pmu driver")
> >
> > Can you please confirm? Thanks!
> >
>
> If you want to add a 'fixes' tag, that would be it. I omitted the tag
> because a -stable tree isn't needed for this. I don't mind either way.

You never know who will backport the original series...

Thanks, applied and queued for v4.19.

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: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[Julian Stecklina]

Hey everyone,

On Mon, 20 Aug 2018 15:27 Linus Torvalds  wrote:
> On Mon, Aug 20, 2018 at 3:02 PM Woodhouse, David  wrote:
>>
>> It's the *kernel* we don't want being able to access those pages,
>> because of the multitude of unfixable cache load gadgets.
>
> Ahh.
> 
> I guess the proof is in the pudding. Did somebody try to forward-port
> that patch set and see what the performance is like?

I've been spending some cycles on the XPFO patch set this week. For the
patch set as it was posted for v4.13, the performance overhead of
compiling a Linux kernel is ~40% on x86_64[1]. The overhead comes almost
completely from TLB flushing. If we can live with stale TLB entries
allowing temporary access (which I think is reasonable), we can remove
all TLB flushing (on x86). This reduces the overhead to 2-3% for
kernel compile.

There were no problems in forward-porting the patch set to master.
You can find the result here, including a patch makes the TLB flushing
configurable:
http://git.infradead.org/users/jsteckli/linux-xpfo.git/shortlog/refs/heads/xpfo-master

It survived some casual stress-ng runs. I can rerun the benchmarks on
this version, but I doubt there is any change.

> It used to be just 500 LOC. Was that because they took horrible
> shortcuts?

The patch is still fairly small. As for the horrible shortcuts, I let
others comment on that.

HTH,
Julian

[1] Measured on my quad-core (8 hyperthreads) Kaby Lake desktop building
Linux 4.18 with the Phoronix Test Suite.

--
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

Re: [PATCH v3] ARM: dts: pxa: add mioa701 board description

[kbuild test robot]

Hi Robert,

I love your patch! Yet something to improve:

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.19-rc1 next-20180831]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Robert-Jarzmik/ARM-dts-pxa-add-mioa701-board-description/20180831-134244
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-keystone_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> Error: arch/arm/boot/dts/mioa701.dts:47.10-11 syntax error
   FATAL ERROR: Unable to parse input tree

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v1 2/5] mm/memory_hotplug: enforce section alignment when onlining/offlining

[David Hildenbrand]

On 31.08.2018 00:14, Pasha Tatashin wrote:
> Hi David,
> 
> I am not sure this is needed, because we already have a stricter checker:
> 
> check_hotplug_memory_range()
> 
> You could call it from online_pages(), if you think there is a reason to
> do it, but other than that it is done from add_memory_resource() and
> from remove_memory().

Hi,

As offline_pages() is called from a different location for ppc (and I
understand why but don't consider this clean) and I used both functions
in a prototype, believing they would work with pageblock_nr_pages, I
really think that we should at least drop the misleading check from
offline_pages() and better also add checks for check_hotplug_memory_range().

Thanks for having a look Pavel!

> 
> Thank you,
> Pavel
> 
> On 8/16/18 6:06 AM, David Hildenbrand wrote:
>> onlining/offlining code works on whole sections, so let's enforce that.
>> Existing code only allows to add memory in memory block size. And only
>> whole memory blocks can be onlined/offlined. Memory blocks are always
>> aligned to sections, so this should not break anything.
>>
>> online_pages/offline_pages will implicitly mark whole sections
>> online/offline, so the code really can only handle such granularities.
>>
>> (especially offlining code cannot deal with pageblock_nr_pages but
>>  theoretically only MAX_ORDER-1)
>>
>> Signed-off-by: David Hildenbrand 
>> ---
>>  mm/memory_hotplug.c | 10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 090cf474de87..30d2fa42b0bb 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -897,6 +897,11 @@ int __ref online_pages(unsigned long pfn, unsigned long 
>> nr_pages, int online_typ
>>  struct memory_notify arg;
>>  struct memory_block *mem;
>>  
>> +if (!IS_ALIGNED(pfn, PAGES_PER_SECTION))
>> +return -EINVAL;
>> +if (!IS_ALIGNED(nr_pages, PAGES_PER_SECTION))
>> +return -EINVAL;
>> +
>>  /*
>>   * We can't use pfn_to_nid() because nid might be stored in struct page
>>   * which is not yet initialized. Instead, we find nid from memory block.
>> @@ -1600,10 +1605,9 @@ int offline_pages(unsigned long start_pfn, unsigned 
>> long nr_pages)
>>  struct zone *zone;
>>  struct memory_notify arg;
>>  
>> -/* at least, alignment against pageblock is necessary */
>> -if (!IS_ALIGNED(start_pfn, pageblock_nr_pages))
>> +if (!IS_ALIGNED(start_pfn, PAGES_PER_SECTION))
>>  return -EINVAL;
>> -if (!IS_ALIGNED(end_pfn, pageblock_nr_pages))
>> +if (!IS_ALIGNED(nr_pages, PAGES_PER_SECTION))
>>  return -EINVAL;
>>  /* This makes hotplug much easier...and readable.
>> we assume this for now. .*/


-- 

Thanks,

David / dhildenb

[PATCH v7 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

This patch adds one new led trigger that LED device can configure
the software or hardware pattern and trigger it.

Consumers can write 'pattern' file to enable the software pattern
which alters the brightness for the specified duration with one
software timer.

Moreover consumers can write 'hw_pattern' file to enable the hardware
pattern for some LED controllers which can autonomously control
brightness over time, according to some preprogrammed hardware
patterns.

Signed-off-by: Raphael Teysseyre 
Signed-off-by: Baolin Wang 
---
Changes from v6:
 - Improve commit message.
 - Optimize the description of the hw_pattern file.
 - Simplify some logics.

Changes from v5:
 - Add one 'hw_pattern' file for hardware patterns.

Changes from v4:
 - Change the repeat file to return the originally written number.
 - Improve comments.
 - Fix some build warnings.

Changes from v3:
 - Reset pattern number to 0 if user provides incorrect pattern string.
 - Support one pattern.

Changes from v2:
 - Remove hardware_pattern boolen.
 - Chnage the pattern string format.

Changes from v1:
 - Use ATTRIBUTE_GROUPS() to define attributes.
 - Introduce hardware_pattern flag to determine if software pattern
 or hardware pattern.
 - Re-implement pattern_trig_store_pattern() function.
 - Remove pattern_get() interface.
 - Improve comments.
 - Other small optimization.
---
 .../ABI/testing/sysfs-class-led-trigger-pattern|   44 +++
 drivers/leds/trigger/Kconfig   |7 +
 drivers/leds/trigger/Makefile  |1 +
 drivers/leds/trigger/ledtrig-pattern.c |  337 
 include/linux/leds.h   |   16 +
 5 files changed, 405 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-pattern
 create mode 100644 drivers/leds/trigger/ledtrig-pattern.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern 
b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
new file mode 100644
index 000..f4749d1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
@@ -0,0 +1,44 @@
+What:  /sys/class/leds//pattern
+Date:  September 2018
+KernelVersion: 4.20
+Description:
+   Specify a software pattern for the LED, that supports altering
+   the brightness for the specified duration with one software
+   timer.
+
+   The pattern is given by a series of tuples, of brightness and
+   duration (ms). The LED is expected to traverse the series and
+   each brightness value for the specified duration. Duration of
+   0 means brightness should immediately change to new value.
+
+   The format of the software pattern values should be:
+   "brightness_1 duration_1 brightness_2 duration_2 brightness_3
+   duration_3 ...".
+
+What:  /sys/class/leds//hw_pattern
+Date:  September 2018
+KernelVersion: 4.20
+Description:
+   Specify a hardware pattern for the LED, for LED hardware that
+   supports autonomously controlling brightness over time, 
according
+   to some preprogrammed hardware patterns.
+
+   Since different LED hardware can have different semantics of
+   hardware patterns, each driver is expected to provide its own
+   description for the hardware patterns as below.
+
+   For Spreadtrum SC27XX LED controller, it only supports 4 
hardware
+   patterns to configure the low time, rise time, high time and 
fall
+   time for the breathing mode, and each stage duration unit is 
125ms.
+   So the format of the hardware pattern values should be:
+   "brightness_1 duration_1 brightness_2 duration_2 brightness_3
+duration_3 brightness_4 duration_4".
+
+What:  /sys/class/leds//repeat
+Date:  September 2018
+KernelVersion: 4.20
+Description:
+   Specify a pattern repeat number. 0 means repeat indefinitely.
+
+   This file will always return the originally written repeat
+   number.
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 4018af7..b76fc3c 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -129,4 +129,11 @@ config LEDS_TRIGGER_NETDEV
  This allows LEDs to be controlled by network device activity.
  If unsure, say Y.
 
+config LEDS_TRIGGER_PATTERN
+   tristate "LED Pattern Trigger"
+   help
+ This allows LEDs to be controlled by a software or hardware pattern
+ which is a series of tuples, of brightness and duration (ms).
+ If unsure, say N
+
 endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index f3cfe19..9bcb64e 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -13

[PATCH v7 2/2] leds: sc27xx: Add pattern_set/clear interfaces for LED controller

[Baolin Wang]

This patch implements the 'pattern_set'and 'pattern_clear'
interfaces to support SC27XX LED breathing mode.

Signed-off-by: Baolin Wang 
---
Changes from v6:
 - None.

Changes from v5:
 - None.

Changes from v4:
 - None.

Changes from v3:
 - None.

Changes from v2:
 - None.

Changes from v1:
 - Remove pattern_get interface.
---
 drivers/leds/leds-sc27xx-bltc.c |   94 +++
 1 file changed, 94 insertions(+)

diff --git a/drivers/leds/leds-sc27xx-bltc.c b/drivers/leds/leds-sc27xx-bltc.c
index 9d9b7aa..297dd43 100644
--- a/drivers/leds/leds-sc27xx-bltc.c
+++ b/drivers/leds/leds-sc27xx-bltc.c
@@ -32,8 +32,13 @@
 #define SC27XX_DUTY_MASK   GENMASK(15, 0)
 #define SC27XX_MOD_MASKGENMASK(7, 0)
 
+#define SC27XX_CURVE_SHIFT 8
+#define SC27XX_CURVE_L_MASKGENMASK(7, 0)
+#define SC27XX_CURVE_H_MASKGENMASK(15, 8)
+
 #define SC27XX_LEDS_OFFSET 0x10
 #define SC27XX_LEDS_MAX3
+#define SC27XX_LEDS_PATTERN_CNT4
 
 struct sc27xx_led {
char name[LED_MAX_NAME_SIZE];
@@ -122,6 +127,91 @@ static int sc27xx_led_set(struct led_classdev *ldev, enum 
led_brightness value)
return err;
 }
 
+static int sc27xx_led_pattern_clear(struct led_classdev *ldev)
+{
+   struct sc27xx_led *leds = to_sc27xx_led(ldev);
+   struct regmap *regmap = leds->priv->regmap;
+   u32 base = sc27xx_led_get_offset(leds);
+   u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+   u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+   int err;
+
+   mutex_lock(&leds->priv->lock);
+
+   /* Reset the rise, high, fall and low time to zero. */
+   regmap_write(regmap, base + SC27XX_LEDS_CURVE0, 0);
+   regmap_write(regmap, base + SC27XX_LEDS_CURVE1, 0);
+
+   err = regmap_update_bits(regmap, ctrl_base,
+   (SC27XX_LED_RUN | SC27XX_LED_TYPE) << ctrl_shift, 0);
+
+   mutex_unlock(&leds->priv->lock);
+
+   return err;
+}
+
+static int sc27xx_led_pattern_set(struct led_classdev *ldev,
+ struct led_pattern *pattern,
+ int len, u32 repeat)
+{
+   struct sc27xx_led *leds = to_sc27xx_led(ldev);
+   u32 base = sc27xx_led_get_offset(leds);
+   u32 ctrl_base = leds->priv->base + SC27XX_LEDS_CTRL;
+   u8 ctrl_shift = SC27XX_CTRL_SHIFT * leds->line;
+   struct regmap *regmap = leds->priv->regmap;
+   int err;
+
+   /*
+* Must contain 4 patterns to configure the rise time, high time, fall
+* time and low time to enable the breathing mode.
+*/
+   if (len != SC27XX_LEDS_PATTERN_CNT)
+   return -EINVAL;
+
+   mutex_lock(&leds->priv->lock);
+
+   err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE0,
+SC27XX_CURVE_L_MASK, pattern[0].delta_t);
+   if (err)
+   goto out;
+
+   err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE1,
+SC27XX_CURVE_L_MASK, pattern[1].delta_t);
+   if (err)
+   goto out;
+
+   err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE0,
+SC27XX_CURVE_H_MASK,
+pattern[2].delta_t << SC27XX_CURVE_SHIFT);
+   if (err)
+   goto out;
+
+
+   err = regmap_update_bits(regmap, base + SC27XX_LEDS_CURVE1,
+SC27XX_CURVE_H_MASK,
+pattern[3].delta_t << SC27XX_CURVE_SHIFT);
+   if (err)
+   goto out;
+
+
+   err = regmap_update_bits(regmap, base + SC27XX_LEDS_DUTY,
+SC27XX_DUTY_MASK,
+(pattern[0].brightness << SC27XX_DUTY_SHIFT) |
+SC27XX_MOD_MASK);
+   if (err)
+   goto out;
+
+   /* Enable the LED breathing mode */
+   err = regmap_update_bits(regmap, ctrl_base,
+SC27XX_LED_RUN << ctrl_shift,
+SC27XX_LED_RUN << ctrl_shift);
+
+out:
+   mutex_unlock(&leds->priv->lock);
+
+   return err;
+}
+
 static int sc27xx_led_register(struct device *dev, struct sc27xx_led_priv 
*priv)
 {
int i, err;
@@ -140,6 +230,9 @@ static int sc27xx_led_register(struct device *dev, struct 
sc27xx_led_priv *priv)
led->priv = priv;
led->ldev.name = led->name;
led->ldev.brightness_set_blocking = sc27xx_led_set;
+   led->ldev.pattern_set = sc27xx_led_pattern_set;
+   led->ldev.pattern_clear = sc27xx_led_pattern_clear;
+   led->ldev.default_trigger = "pattern";
 
err = devm_led_classdev_register(dev, &led->ldev);
if (err)
@@ -241,4 +334,5 @@ static int sc27xx_led_remove(struct platform_device *pdev)
 
 MODULE_DESCRIPTION("Spreadtrum SC27xx breathing light controller driver");
 MODULE_AUTHOR("Xiaot

[PATCH 0/7] Add i.MX6 SoCs mmdc ipg clocks management

[Anson Huang]

i.MX6 SoCs have MMDC driver which will access MMDC registers, and the
register access need to have MMDC IPG clocks enabled, current MMDC
driver does NOT handle the MMDC IPG clocks at all, most of the i.MX6
SoCs clock tree have MMDC0 IPG clock registered and have flag
CLK_IS_CRITICAL set, but some i.MX6 SoCs does NOT register the MMDC IPG
clock at all, it depends on default HW status which is NOT reliable.

To make it more formal, this patch set add all available MMDC IPG clocks
into clock tree, and add optional clocks enable operation in MMDC driver
to make sure IPG clock is enabled before accessing registers, and passing
MMDC IPG clock info from device tree MMDC node.

In order to NOT break old device tree, this patch set does NOT remove
the CLK_IS_CRITIAL flag for MMDC0 IPG clock.

Anson Huang (7):
  ARM: imx: add mmdc ipg clock operation for mmdc
  clk: imx6ul: add mmdc1 ipg clock
  clk: imx6sx: add mmdc1 ipg clock
  clk: imx6sll: add mmdc1 ipg clock
  clk: imx6sl: add mmdc ipg clocks
  clk: imx6q: add mmdc0 ipg clock
  ARM: dts: imx6: add mmdc ipg clock

 arch/arm/boot/dts/imx6qdl.dtsi|  1 +
 arch/arm/boot/dts/imx6sl.dtsi |  1 +
 arch/arm/boot/dts/imx6sll.dtsi|  1 +
 arch/arm/boot/dts/imx6sx.dtsi |  1 +
 arch/arm/boot/dts/imx6ul.dtsi |  1 +
 arch/arm/mach-imx/mmdc.c  | 14 ++
 drivers/clk/imx/clk-imx6q.c   |  1 +
 drivers/clk/imx/clk-imx6sl.c  |  2 ++
 drivers/clk/imx/clk-imx6sll.c |  1 +
 drivers/clk/imx/clk-imx6sx.c  |  1 +
 drivers/clk/imx/clk-imx6ul.c  |  1 +
 include/dt-bindings/clock/imx6qdl-clock.h |  3 ++-
 include/dt-bindings/clock/imx6sl-clock.h  |  4 +++-
 include/dt-bindings/clock/imx6sll-clock.h |  3 ++-
 include/dt-bindings/clock/imx6sx-clock.h  |  3 ++-
 include/dt-bindings/clock/imx6ul-clock.h  |  3 ++-
 16 files changed, 36 insertions(+), 5 deletions(-)

-- 
2.7.4

[PATCH 1/7] ARM: imx: add mmdc ipg clock operation for mmdc

[Anson Huang]

i.MX6 SoCs have MMDC ipg clock for registers access, to make
sure MMDC registers access successfully, add optional clock
enable for MMDC driver.

Signed-off-by: Anson Huang 
---
 arch/arm/mach-imx/mmdc.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
index 04b3bf7..e49e068 100644
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm/mach-imx/mmdc.c
@@ -11,6 +11,7 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -546,7 +547,20 @@ static int imx_mmdc_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
void __iomem *mmdc_base, *reg;
+   struct clk *mmdc_ipg_clk;
u32 val;
+   int err;
+
+   /* the ipg clock is optional */
+   mmdc_ipg_clk = devm_clk_get(&pdev->dev, NULL);
+   if (IS_ERR(mmdc_ipg_clk))
+   mmdc_ipg_clk = NULL;
+
+   err = clk_prepare_enable(mmdc_ipg_clk);
+   if (err) {
+   dev_err(&pdev->dev, "Unable to enable mmdc ipg clock.\n");
+   return err;
+   }
 
mmdc_base = of_iomap(np, 0);
WARN_ON(!mmdc_base);
-- 
2.7.4

[PATCH 2/7] clk: imx6ul: add mmdc1 ipg clock

[Anson Huang]

i.MX6UL has MMDC1 ipg clock in CCM CCGR, add it into
clock tree for clock management.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx6ul.c | 1 +
 include/dt-bindings/clock/imx6ul-clock.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 361b43f..fd60d15 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -408,6 +408,7 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
clks[IMX6UL_CLK_WDOG1]  = imx_clk_gate2("wdog1","ipg",  
base + 0x74,16);
clks[IMX6UL_CLK_MMDC_P0_FAST]   = imx_clk_gate_flags("mmdc_p0_fast", 
"mmdc_podf", base + 0x74,  20, CLK_IS_CRITICAL);
clks[IMX6UL_CLK_MMDC_P0_IPG]= imx_clk_gate2_flags("mmdc_p0_ipg",
"ipg",  base + 0x74,24, CLK_IS_CRITICAL);
+   clks[IMX6UL_CLK_MMDC_P1_IPG]= imx_clk_gate2("mmdc_p1_ipg",  "ipg",  
base + 0x74,26);
clks[IMX6UL_CLK_AXI]= imx_clk_gate_flags("axi", 
"axi_podf", base + 0x74,28, CLK_IS_CRITICAL);
 
/* CCGR4 */
diff --git a/include/dt-bindings/clock/imx6ul-clock.h 
b/include/dt-bindings/clock/imx6ul-clock.h
index f8e0476..f718aac 100644
--- a/include/dt-bindings/clock/imx6ul-clock.h
+++ b/include/dt-bindings/clock/imx6ul-clock.h
@@ -259,7 +259,8 @@
 #define IMX6UL_CLK_GPIO3   246
 #define IMX6UL_CLK_GPIO4   247
 #define IMX6UL_CLK_GPIO5   248
+#define IMX6UL_CLK_MMDC_P1_IPG 249
 
-#define IMX6UL_CLK_END 249
+#define IMX6UL_CLK_END 250
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6UL_H */
-- 
2.7.4

Re: [PATCH v4 09/13] ARM: dts: sun8i: r40: add sata node

[Chen-Yu Tsai]

On Fri, Aug 31, 2018 at 3:56 PM Corentin Labbe
 wrote:
>
> On Fri, Aug 31, 2018 at 09:35:00AM +0200, Maxime Ripard wrote:
> > On Thu, Aug 30, 2018 at 09:01:16PM +0200, Corentin Labbe wrote:
> > > R40 have a sata controller which is the same as A20.
> > > This patch adds a DT node for it.
> > >
> > > Signed-off-by: Icenowy Zheng 
> > > Signed-off-by: Corentin Labbe 
> > > ---
> > >  arch/arm/boot/dts/sun8i-r40.dtsi | 23 +++
> > >  1 file changed, 23 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi 
> > > b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > index 852c2ccc3268..d6b5820da850 100644
> > > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > @@ -550,6 +550,29 @@
> > > #size-cells = <0>;
> > > };
> > >
> > > +   ahci: sata@1c18000 {
> > > +   compatible = "allwinner,sun8i-r40-ahci";
> > > +   reg = <0x01c18000 0x1000>;
> > > +   interrupts = ;
> > > +   clocks = <&ccu CLK_BUS_SATA>, <&ccu CLK_SATA>;
> > > +   resets = <&ccu RST_BUS_SATA>;
> > > +   resets-name = "ahci";
> > > +   #address-cells = <1>;
> > > +   #size-cells = <0>;
> > > +   status = "disabled";
> > > +
> > > +   sata_port: sata-port@0 {
> > > +   reg = <0>;
> > > +   phys = <&sata_phy>;
> > > +   };
> > > +   };
> > > +
> > > +   sata_phy: sata-phy@1c180c0  {
> > > +   compatible = "allwinner,sun8i-r40-sata-phy";
> > > +   reg = <0x1c180c0 0x200>;
> >
> > Overlapping devices in the DTS is not ok.
> >
>
> I do the same than arch/arm/boot/dts/berlin2.dtsi (sata@e9 phy@e900a0)
> But since it is not a good justification, it seems that regmap is my only 
> solution ?

Since you are effectively splitting one device node into two, you should
adjust the original (ahci) device nodes register range.

ChenYu

[PATCH 3/7] clk: imx6sx: add mmdc1 ipg clock

[Anson Huang]

i.MX6SX has MMDC1 ipg clock in CCM CCGR, add it into
clock tree for clock management.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx6sx.c | 1 +
 include/dt-bindings/clock/imx6sx-clock.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index d9f2890..18527a3 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -431,6 +431,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_MLB]  = imx_clk_gate2("mlb",   "ahb",   
base + 0x74, 18);
clks[IMX6SX_CLK_MMDC_P0_FAST] = imx_clk_gate2_flags("mmdc_p0_fast", 
"mmdc_podf", base + 0x74, 20, CLK_IS_CRITICAL);
clks[IMX6SX_CLK_MMDC_P0_IPG]  = imx_clk_gate2_flags("mmdc_p0_ipg", 
"ipg", base + 0x74, 24, CLK_IS_CRITICAL);
+   clks[IMX6SX_CLK_MMDC_P1_IPG]  = imx_clk_gate2("mmdc_p1_ipg", "ipg", 
base + 0x74, 26);
clks[IMX6SX_CLK_OCRAM]= imx_clk_gate2_flags("ocram", 
"ocram_podf", base + 0x74, 28, CLK_IS_CRITICAL);
 
/* CCGR4 */
diff --git a/include/dt-bindings/clock/imx6sx-clock.h 
b/include/dt-bindings/clock/imx6sx-clock.h
index cd2d6c5..fb420c7 100644
--- a/include/dt-bindings/clock/imx6sx-clock.h
+++ b/include/dt-bindings/clock/imx6sx-clock.h
@@ -279,6 +279,7 @@
 #define IMX6SX_CLK_LVDS2_OUT   266
 #define IMX6SX_CLK_LVDS2_IN267
 #define IMX6SX_CLK_ANACLK2 268
-#define IMX6SX_CLK_CLK_END 269
+#define IMX6SX_CLK_MMDC_P1_IPG 269
+#define IMX6SX_CLK_CLK_END 270
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6SX_H */
-- 
2.7.4

[PATCH 5/7] clk: imx6sl: add mmdc ipg clocks

[Anson Huang]

i.MX6SL has MMDC0 and MMDC1 ipg clock in CCM CCGR, add them into
clock tree for clock management.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx6sl.c | 2 ++
 include/dt-bindings/clock/imx6sl-clock.h | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx6sl.c b/drivers/clk/imx/clk-imx6sl.c
index eb6bcbf..6fcfbbd 100644
--- a/drivers/clk/imx/clk-imx6sl.c
+++ b/drivers/clk/imx/clk-imx6sl.c
@@ -386,6 +386,8 @@ static void __init imx6sl_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SL_CLK_LCDIF_AXI]= imx_clk_gate2("lcdif_axi",
"lcdif_axi_podf",base + 0x74, 6);
clks[IMX6SL_CLK_LCDIF_PIX]= imx_clk_gate2("lcdif_pix",
"lcdif_pix_podf",base + 0x74, 8);
clks[IMX6SL_CLK_EPDC_PIX] = imx_clk_gate2("epdc_pix", 
"epdc_pix_podf", base + 0x74, 10);
+   clks[IMX6SL_CLK_MMDC_P0_IPG]  = imx_clk_gate2_flags("mmdc_p0_ipg",  
"ipg", base + 0x74, 24, CLK_IS_CRITICAL);
+   clks[IMX6SL_CLK_MMDC_P1_IPG]  = imx_clk_gate2("mmdc_p1_ipg",  "ipg",
   base + 0x74, 26);
clks[IMX6SL_CLK_OCRAM]= imx_clk_gate2("ocram",
"ocram_podf",base + 0x74, 28);
clks[IMX6SL_CLK_PWM1] = imx_clk_gate2("pwm1", "perclk", 
   base + 0x78, 16);
clks[IMX6SL_CLK_PWM2] = imx_clk_gate2("pwm2", "perclk", 
   base + 0x78, 18);
diff --git a/include/dt-bindings/clock/imx6sl-clock.h 
b/include/dt-bindings/clock/imx6sl-clock.h
index e14573e..cfbfc39 100644
--- a/include/dt-bindings/clock/imx6sl-clock.h
+++ b/include/dt-bindings/clock/imx6sl-clock.h
@@ -175,6 +175,8 @@
 #define IMX6SL_CLK_SSI2_IPG162
 #define IMX6SL_CLK_SSI3_IPG163
 #define IMX6SL_CLK_SPDIF_GCLK  164
-#define IMX6SL_CLK_END 165
+#define IMX6SL_CLK_MMDC_P0_IPG 165
+#define IMX6SL_CLK_MMDC_P1_IPG 166
+#define IMX6SL_CLK_END 167
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6SL_H */
-- 
2.7.4

[PATCH 7/7] ARM: dts: imx6: add mmdc ipg clock

[Anson Huang]

i.MX6 SoCs has MMDC clock gates in CCM CCGR, add
clock property for MMDC driver's clock operation.

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 1 +
 arch/arm/boot/dts/imx6sl.dtsi  | 1 +
 arch/arm/boot/dts/imx6sll.dtsi | 1 +
 arch/arm/boot/dts/imx6sx.dtsi  | 1 +
 arch/arm/boot/dts/imx6ul.dtsi  | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 61d2d26..5d33729 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1115,6 +1115,7 @@
mmdc0: mmdc@21b { /* MMDC0 */
compatible = "fsl,imx6q-mmdc";
reg = <0x021b 0x4000>;
+   clocks = <&clks IMX6QDL_CLK_MMDC_P0_IPG>;
};
 
mmdc1: mmdc@21b4000 { /* MMDC1 */
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 7a4f5da..63a18e1 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -921,6 +921,7 @@
mmdc: mmdc@21b {
compatible = "fsl,imx6sl-mmdc", 
"fsl,imx6q-mmdc";
reg = <0x021b 0x4000>;
+   clocks = <&clks IMX6SL_CLK_MMDC_P0_IPG>;
};
 
rngb: rngb@21b4000 {
diff --git a/arch/arm/boot/dts/imx6sll.dtsi b/arch/arm/boot/dts/imx6sll.dtsi
index ed9a980..e462f76 100644
--- a/arch/arm/boot/dts/imx6sll.dtsi
+++ b/arch/arm/boot/dts/imx6sll.dtsi
@@ -770,6 +770,7 @@
mmdc: memory-controller@21b {
compatible = "fsl,imx6sll-mmdc", 
"fsl,imx6q-mmdc";
reg = <0x021b 0x4000>;
+   clocks = <&clks IMX6SLL_CLK_MMDC_P0_IPG>;
};
 
ocotp: ocotp-ctrl@21bc000 {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 844caa3..ba4ab79 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -1002,6 +1002,7 @@
mmdc: mmdc@21b {
compatible = "fsl,imx6sx-mmdc", 
"fsl,imx6q-mmdc";
reg = <0x021b 0x4000>;
+   clocks = <&clks IMX6SX_CLK_MMDC_P0_IPG>;
};
 
fec2: ethernet@21b4000 {
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 448d765..2019ad5 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -916,6 +916,7 @@
mmdc: mmdc@21b {
compatible = "fsl,imx6ul-mmdc", 
"fsl,imx6q-mmdc";
reg = <0x021b 0x4000>;
+   clocks = <&clks IMX6UL_CLK_MMDC_P0_IPG>;
};
 
weim: weim@21b8000 {
-- 
2.7.4

[PATCH 6/7] clk: imx6q: add mmdc0 ipg clock

[Anson Huang]

i.MX6Q has MMDC0 ipg clock in CCM CCGR, add it into
clock tree for clock management.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx6q.c   | 1 +
 include/dt-bindings/clock/imx6qdl-clock.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index 8c7c2fc..bbe0c60 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -789,6 +789,7 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb","axi",   
base + 0x74, 18);
clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2_flags("mmdc_ch0_axi",  
"mmdc_ch0_axi_podf", base + 0x74, 20, CLK_IS_CRITICAL);
clk[IMX6QDL_CLK_MMDC_CH1_AXI] = imx_clk_gate2("mmdc_ch1_axi",  
"mmdc_ch1_axi_podf", base + 0x74, 22);
+   clk[IMX6QDL_CLK_MMDC_P0_IPG]  = imx_clk_gate2_flags("mmdc_p0_ipg",   
"ipg", base + 0x74, 24, CLK_IS_CRITICAL);
clk[IMX6QDL_CLK_OCRAM]= imx_clk_gate2("ocram", "ahb",   
base + 0x74, 28);
clk[IMX6QDL_CLK_OPENVG_AXI]   = imx_clk_gate2("openvg_axi","axi",   
base + 0x74, 30);
clk[IMX6QDL_CLK_PCIE_AXI] = imx_clk_gate2("pcie_axi",  
"pcie_axi_sel",  base + 0x78, 0);
diff --git a/include/dt-bindings/clock/imx6qdl-clock.h 
b/include/dt-bindings/clock/imx6qdl-clock.h
index 7ad171b..87b068f 100644
--- a/include/dt-bindings/clock/imx6qdl-clock.h
+++ b/include/dt-bindings/clock/imx6qdl-clock.h
@@ -273,6 +273,7 @@
 #define IMX6QDL_CLK_MLB_PODF   260
 #define IMX6QDL_CLK_EPIT1  261
 #define IMX6QDL_CLK_EPIT2  262
-#define IMX6QDL_CLK_END263
+#define IMX6QDL_CLK_MMDC_P0_IPG263
+#define IMX6QDL_CLK_END264
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6QDL_H */
-- 
2.7.4

[PATCH 4/7] clk: imx6sll: add mmdc1 ipg clock

[Anson Huang]

i.MX6SLL has MMDC1 ipg clock in CCM CCGR, add it into
clock tree for clock management.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx6sll.c | 1 +
 include/dt-bindings/clock/imx6sll-clock.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx6sll.c b/drivers/clk/imx/clk-imx6sll.c
index 52379ee..3bd2044 100644
--- a/drivers/clk/imx/clk-imx6sll.c
+++ b/drivers/clk/imx/clk-imx6sll.c
@@ -293,6 +293,7 @@ static void __init imx6sll_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SLL_CLK_WDOG1] = imx_clk_gate2("wdog1","ipg",  
base + 0x74, 16);
clks[IMX6SLL_CLK_MMDC_P0_FAST]  = imx_clk_gate_flags("mmdc_p0_fast", 
"mmdc_podf",  base + 0x74, 20, CLK_IS_CRITICAL);
clks[IMX6SLL_CLK_MMDC_P0_IPG]   = imx_clk_gate2_flags("mmdc_p0_ipg", 
"ipg",base + 0x74, 24, CLK_IS_CRITICAL);
+   clks[IMX6SLL_CLK_MMDC_P1_IPG]   = imx_clk_gate2("mmdc_p1_ipg", "ipg",   
   base + 0x74, 26);
clks[IMX6SLL_CLK_OCRAM] = imx_clk_gate_flags("ocram","ahb", 
   base + 0x74, 28, CLK_IS_CRITICAL);
 
/* CCGR4 */
diff --git a/include/dt-bindings/clock/imx6sll-clock.h 
b/include/dt-bindings/clock/imx6sll-clock.h
index 1036475..f446710 100644
--- a/include/dt-bindings/clock/imx6sll-clock.h
+++ b/include/dt-bindings/clock/imx6sll-clock.h
@@ -203,7 +203,8 @@
 #define IMX6SLL_CLK_GPIO4   176
 #define IMX6SLL_CLK_GPIO5   177
 #define IMX6SLL_CLK_GPIO6   178
+#define IMX6SLL_CLK_MMDC_P1_IPG179
 
-#define IMX6SLL_CLK_END179
+#define IMX6SLL_CLK_END180
 
 #endif /* __DT_BINDINGS_CLOCK_IMX6SLL_H */
-- 
2.7.4

Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array

[Jerome Forissier]

On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> Quoting Peng Fan (2018-08-12 18:15:41)
>> Hi Anson,
>>
> -Original Message-
> From: Anson Huang
> Sent: 2018年8月8日 12:39
> To: shawn...@kernel.org; s.ha...@pengutronix.de;
> ker...@pengutronix.de; Fabio Estevam ;
> mturque...@baylibre.com; sb...@kernel.org;
> linux-arm-ker...@lists.infradead.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: dl-linux-imx 
> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Clock framework will enable those clocks registered with
> CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> clock
 initialization now.

 Will it be more flexible to parse dts saying "critical-clocks = "
 or "init-on-arrary="
 and enable those clocks?
>>>
>>> Parsing the clocks arrays from dtb is another way of enabling critical 
>>> clocks, but
>>> for current i.MX6/7 platforms, we implement it in same way as most of other
>>> SoCs, currently I did NOT see any necessity of putting them in dtb, just 
>>> adding
>>> flag during clock registering is more simple, if there is any special 
>>> requirement
>>> for different clocks set to be enabled, then we can add support to enable 
>>> the
>>> method of parsing critical-clocks from dtb. Just my two cents.
>>
>> Thinking about OP-TEE want to use one device, but it's clocks are registered
>> by Linux, because there is no module in Linux side use it, it will shutdown 
>> the clock,
>> which cause OP-TEE could not access the device.
>>
>> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
>> the clocks are not shutdown by Linux.
>>
>> However adding a new property in clk node and let driver code parse the dts,
>> there is no need to modify clk driver code when OP-TEE needs another device 
>> clock.
>>
> 
> If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
> in Linux probe, acquire clocks, and keep the clks enabled forever?

Sounds reasonable, but how could this be done without introducing
platform-specific stuff in the OP-TEE driver?

> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH] x86/dumpstack: fix address space casting in show_opcodes()

[Borislav Petkov]

On Thu, Aug 30, 2018 at 09:47:36PM +0200, Jann Horn wrote:
> I sloppily passed a kernel-typed pointer to __range_not_ok(), and sparse
> doesn't like that.
> Make `prologue` a __user pointer (to protect against accidental
> dereferences) and force-cast it to a kernel pointer when calling
> probe_kernel_read(), which will then immediately force-cast it back to a
> user pointer.

Yeah, that's some crazy casting.

Can we define a local __user pointer only for the check instead? It is
less casting and looks simpler and actually even easier to understand
what we're doing...

---
diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 605c60b1624f..9c5a15491108 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -97,14 +97,17 @@ void show_opcodes(struct pt_regs *regs, const char *loglvl)
 #define OPCODE_BUFSIZE (PROLOGUE_SIZE + 1 + EPILOGUE_SIZE)
u8 opcodes[OPCODE_BUFSIZE];
u8 *prologue = (u8 *)(regs->ip - PROLOGUE_SIZE);
-   bool bad_ip;
+   bool bad_ip = false;
 
/*
 * Make sure userspace isn't trying to trick us into dumping kernel
 * memory by pointing the userspace instruction pointer at it.
 */
-   bad_ip = user_mode(regs) &&
-   __range_not_ok(prologue, OPCODE_BUFSIZE, TASK_SIZE_MAX);
+   if (user_mode(regs)) {
+   u8 __user *up = (u8 __user *)prologue;
+
+   bad_ip = __range_not_ok(up, OPCODE_BUFSIZE, TASK_SIZE_MAX);
+   }
 
if (bad_ip || probe_kernel_read(opcodes, prologue, OPCODE_BUFSIZE)) {
printk("%sCode: Bad RIP value.\n", loglvl);

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH v1 02/10] dt-bindings: thermal: Fix a typo in documentation

[Daniel Lezcano]

On 25/08/2018 01:24, Eduardo Valentin wrote:
> On Thu, Aug 09, 2018 at 06:02:34PM +0530, Amit Kucheria wrote:
>> c(1) + x(1) was actually meant to be c(1) * x(1).
>>
>> While we're at it, add some brackets to make it nicer to read.
>>
>> Signed-off-by: Amit Kucheria 
>> ---
>>  Documentation/devicetree/bindings/thermal/thermal.txt | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
>> b/Documentation/devicetree/bindings/thermal/thermal.txt
>> index cc553f0952c5..751104213d08 100644
>> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
>> @@ -152,7 +152,7 @@ Optional property:
>>Elem size: one cell   the sensors listed in the thermal-sensors 
>> property.
>>Elem type: signed Coefficients defaults to 1, in case this property
>>  is not specified. A simple linear polynomial is used:
>> -Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
>> +Z = (c0 * x0) + (c1 * x1) + ... + (c(n-1) * x(n-1)) + 
>> cn.
> 
> To be honest, I would prefer if this looks like:
> + Z = c0 * x0 + c1 * x1 + ... + c(n-1) * x(n-1) + cn.
> 
> The extra bracketing seams unnecessary confusion

I agree, the brackets don't change the computation ordering, they are
pointless.


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH v3 0/4] Provide core API for NMIs

[Julien Thierry]

Hi,

This patch series provides a way for irqchips to define some IRQs as NMIs.

For this to be possible, the irqchip must:
- be a root irqchip
- not require bus locking
- have the NMI support flag

Once these conditions are met, interrupt lines can be requested as NMIs.
These lines must not be shared and the IRQ handling must not be threaded.
Callbacks are added to the irqchip in order to set up (clean up) the
necessary resources for NMIs before enabling (before releasing) the
corresponding interrupt line.

I'll soon post a series making use of the API for Arm's GICv3.

Patches 1 & 2 provide functions necessary to request and manage NMIs.
Patches 3 & 4 provide functions for NMI handling.

Changes since v2[1]:
- Fix ARM build error reported by kbuild bot
- Fix documentation warnings reported by kbuild bot

Changes since v1[2]:
- Rebased to v4.19-rc1
- Fix some coding style issues

Changes since RFC[3]:
- Rebased to v4.18-rc6
- Remove disable_nmi, one should call disable_nmi_nosync instead
- Remove code related to affinity balancing from NMI functions
- Require PERCPU configuration for NMIs

[1] https://lkml.org/lkml/2018/8/28/661
[2] https://lkml.org/lkml/2018/7/24/321
[3] https://lkml.org/lkml/2018/7/9/768

Cheers,

Julien

-->

Julien Thierry (4):
  genirq: Provide basic NMI management for interrupt lines
  genirq: Provide NMI management for percpu_devid interrupts
  genirq: Provide NMI handlers
  irqdesc: Add domain handler for NMIs

 include/linux/interrupt.h |  18 +++
 include/linux/irq.h   |  10 ++
 include/linux/irqdesc.h   |   5 +
 kernel/irq/chip.c |  54 +++
 kernel/irq/debugfs.c  |   6 +-
 kernel/irq/internals.h|   2 +
 kernel/irq/irqdesc.c  |  35 +
 kernel/irq/manage.c   | 377 +-
 8 files changed, 504 insertions(+), 3 deletions(-)

--
1.9.1

[PATCH v3 4/4] irqdesc: Add domain handler for NMIs

[Julien Thierry]

NMI handling code should be executed between calls to nmi_enter and
nmi_exit.

Add a separate domain handler to properly setup NMI context when handling
an interrupt requested as NMI.

Signed-off-by: Julien Thierry 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Will Deacon 
Cc: Peter Zijlstra 
---
 include/linux/irqdesc.h |  5 +
 kernel/irq/irqdesc.c| 35 +++
 2 files changed, 40 insertions(+)

diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index dd1e40d..ba05b0d 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -171,6 +171,11 @@ static inline int handle_domain_irq(struct irq_domain 
*domain,
 {
return __handle_domain_irq(domain, hwirq, true, regs);
 }
+
+#ifdef CONFIG_IRQ_DOMAIN
+int handle_domain_nmi(struct irq_domain *domain, unsigned int hwirq,
+ struct pt_regs *regs);
+#endif
 #endif
 
 /* Test to see if a driver has successfully requested an irq */
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 578d0e5..58934ea 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -665,6 +665,41 @@ int __handle_domain_irq(struct irq_domain *domain, 
unsigned int hwirq,
set_irq_regs(old_regs);
return ret;
 }
+
+#ifdef CONFIG_IRQ_DOMAIN
+/**
+ * handle_domain_nmi - Invoke the handler for a HW irq belonging to a domain
+ * @domain:The domain where to perform the lookup
+ * @hwirq: The HW irq number to convert to a logical one
+ * @regs:  Register file coming from the low-level handling code
+ *
+ * Returns:0 on success, or -EINVAL if conversion has failed
+ */
+int handle_domain_nmi(struct irq_domain *domain, unsigned int hwirq,
+ struct pt_regs *regs)
+{
+   struct pt_regs *old_regs = set_irq_regs(regs);
+   unsigned int irq;
+   int ret = 0;
+
+   nmi_enter();
+
+   irq = irq_find_mapping(domain, hwirq);
+
+   /*
+* ack_bad_irq is not NMI-safe, just report
+* an invalid interrupt.
+*/
+   if (likely(irq))
+   generic_handle_irq(irq);
+   else
+   ret = -EINVAL;
+
+   nmi_exit();
+   set_irq_regs(old_regs);
+   return ret;
+}
+#endif
 #endif
 
 /* Dynamic interrupt handling */
-- 
1.9.1

[PATCH v3 2/4] genirq: Provide NMI management for percpu_devid interrupts

[Julien Thierry]

Add support for percpu_devid interrupts treated as NMIs.

Percpu_devid NMIs need to be setup/torn down on each CPU they target.

The same restrictions as for global NMIs still apply for percpu_devid NMIs.

Signed-off-by: Julien Thierry 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Marc Zyngier 
---
 include/linux/interrupt.h |   9 +++
 kernel/irq/manage.c   | 149 ++
 2 files changed, 158 insertions(+)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 3b1a320..59d3877 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -168,10 +168,15 @@ struct irqaction {
devname, percpu_dev_id);
 }
 
+extern int __must_check
+request_percpu_nmi(unsigned int irq, irq_handler_t handler,
+  const char *devname, void __percpu *dev);
+
 extern const void *free_irq(unsigned int, void *);
 extern void free_percpu_irq(unsigned int, void __percpu *);
 
 extern const void *free_nmi(unsigned int irq, void *dev_id);
+extern void free_percpu_nmi(unsigned int irq, void __percpu *percpu_dev_id);
 
 struct device;
 
@@ -224,7 +229,11 @@ struct irqaction {
 extern void irq_wake_thread(unsigned int irq, void *dev_id);
 
 extern void disable_nmi_nosync(unsigned int irq);
+extern void disable_percpu_nmi(unsigned int irq);
 extern void enable_nmi(unsigned int irq);
+extern void enable_percpu_nmi(unsigned int irq, unsigned int type);
+extern int ready_percpu_nmi(unsigned int irq);
+extern void teardown_percpu_nmi(unsigned int irq);
 
 /* The following three functions are for the core kernel use only. */
 extern void suspend_device_irqs(void);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 15ae2ee..697a82b 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -2178,6 +2178,11 @@ void enable_percpu_irq(unsigned int irq, unsigned int 
type)
 }
 EXPORT_SYMBOL_GPL(enable_percpu_irq);
 
+void enable_percpu_nmi(unsigned int irq, unsigned int type)
+{
+   enable_percpu_irq(irq, type);
+}
+
 /**
  * irq_percpu_is_enabled - Check whether the per cpu irq is enabled
  * @irq:   Linux irq number to check for
@@ -2217,6 +,11 @@ void disable_percpu_irq(unsigned int irq)
 }
 EXPORT_SYMBOL_GPL(disable_percpu_irq);
 
+void disable_percpu_nmi(unsigned int irq)
+{
+   disable_percpu_irq(irq);
+}
+
 /*
  * Internal function to unregister a percpu irqaction.
  */
@@ -2248,6 +2258,8 @@ static struct irqaction *__free_percpu_irq(unsigned int 
irq, void __percpu *dev_
/* Found it - now remove it from the list of entries: */
desc->action = NULL;
 
+   desc->istate &= ~IRQS_NMI;
+
raw_spin_unlock_irqrestore(&desc->lock, flags);
 
unregister_handler_proc(irq, action);
@@ -2301,6 +2313,19 @@ void free_percpu_irq(unsigned int irq, void __percpu 
*dev_id)
 }
 EXPORT_SYMBOL_GPL(free_percpu_irq);
 
+void free_percpu_nmi(unsigned int irq, void __percpu *dev_id)
+{
+   struct irq_desc *desc = irq_to_desc(irq);
+
+   if (!desc || !irq_settings_is_per_cpu_devid(desc))
+   return;
+
+   if (WARN_ON(!(desc->istate & IRQS_NMI)))
+   return;
+
+   kfree(__free_percpu_irq(irq, dev_id));
+}
+
 /**
  * setup_percpu_irq - setup a per-cpu interrupt
  * @irq: Interrupt line to setup
@@ -2391,6 +2416,130 @@ int __request_percpu_irq(unsigned int irq, 
irq_handler_t handler,
 EXPORT_SYMBOL_GPL(__request_percpu_irq);
 
 /**
+ * request_percpu_nmi - allocate a percpu interrupt line for NMI delivery
+ * @irq: Interrupt line to allocate
+ * @handler: Function to be called when the IRQ occurs.
+ * @name: An ascii name for the claiming device
+ * @dev_id: A percpu cookie passed back to the handler function
+ *
+ * This call allocates interrupt resources and enables the
+ * interrupt on the local CPU. If the interrupt is supposed to be
+ * enabled on other CPUs, it has to be done on each CPU using
+ * enable_percpu_nmi().
+ *
+ * Dev_id must be globally unique. It is a per-cpu variable, and
+ * the handler gets called with the interrupted CPU's instance of
+ * that variable.
+ *
+ * Interrupt lines requested for NMI delivering should have auto enabling
+ * setting disabled.
+ *
+ * If the interrupt line cannot be used to deliver NMIs, function
+ * will fail returning a negative value.
+ */
+int request_percpu_nmi(unsigned int irq, irq_handler_t handler,
+  const char *name, void __percpu *dev_id)
+{
+   struct irqaction *action;
+   struct irq_desc *desc;
+   unsigned long flags;
+   int retval;
+
+   if (!handler)
+   return -EINVAL;
+
+   desc = irq_to_desc(irq);
+
+   if (!desc || !irq_settings_can_request(desc) ||
+   !irq_settings_is_per_cpu_devid(desc) ||
+   irq_settings_can_autoenable(desc) ||
+   !irq_supports_nmi(desc))
+   return -EINVAL;
+
+   /* 

[PATCH v3 1/4] genirq: Provide basic NMI management for interrupt lines

[Julien Thierry]

Add functionality to allocate interrupt lines that will deliver IRQs
as Non-Maskable Interrupts. These allocations are only successful if
the irqchip provides the necessary support and allows NMI delivery for the
interrupt line.

Interrupt lines allocated for NMI delivery must be enabled/disabled through
enable_nmi/disable_nmi_nosync to keep their state consistent.

To treat a PERCPU IRQ as NMI, the interrupt must not be shared nor threaded,
the irqchip directly managing the IRQ must be the root irqchip and the
irqchip cannot be behind a slow bus.

Signed-off-by: Julien Thierry 
Cc: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Marc Zyngier 
---
 include/linux/interrupt.h |   9 ++
 include/linux/irq.h   |   7 ++
 kernel/irq/debugfs.c  |   6 +-
 kernel/irq/internals.h|   2 +
 kernel/irq/manage.c   | 228 +-
 5 files changed, 249 insertions(+), 3 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index eeceac3..3b1a320 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -156,6 +156,10 @@ struct irqaction {
 unsigned long flags, const char *devname,
 void __percpu *percpu_dev_id);
 
+extern int __must_check
+request_nmi(unsigned int irq, irq_handler_t handler, unsigned long flags,
+   const char *name, void *dev);
+
 static inline int __must_check
 request_percpu_irq(unsigned int irq, irq_handler_t handler,
   const char *devname, void __percpu *percpu_dev_id)
@@ -167,6 +171,8 @@ struct irqaction {
 extern const void *free_irq(unsigned int, void *);
 extern void free_percpu_irq(unsigned int, void __percpu *);
 
+extern const void *free_nmi(unsigned int irq, void *dev_id);
+
 struct device;
 
 extern int __must_check
@@ -217,6 +223,9 @@ struct irqaction {
 extern bool irq_percpu_is_enabled(unsigned int irq);
 extern void irq_wake_thread(unsigned int irq, void *dev_id);
 
+extern void disable_nmi_nosync(unsigned int irq);
+extern void enable_nmi(unsigned int irq);
+
 /* The following three functions are for the core kernel use only. */
 extern void suspend_device_irqs(void);
 extern void resume_device_irqs(void);
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 201de12..0d71f63 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -441,6 +441,8 @@ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data 
*d)
  * @irq_set_vcpu_affinity: optional to target a vCPU in a virtual machine
  * @ipi_send_single:   send a single IPI to destination cpus
  * @ipi_send_mask: send an IPI to destination cpus in cpumask
+ * @irq_nmi_setup: function called from core code before enabling an NMI
+ * @irq_nmi_teardown:  function called from core code after disabling an NMI
  * @flags: chip specific flags
  */
 struct irq_chip {
@@ -489,6 +491,9 @@ struct irq_chip {
void(*ipi_send_single)(struct irq_data *data, unsigned int 
cpu);
void(*ipi_send_mask)(struct irq_data *data, const struct 
cpumask *dest);
 
+   int (*irq_nmi_setup)(struct irq_data *data);
+   void(*irq_nmi_teardown)(struct irq_data *data);
+
unsigned long   flags;
 };
 
@@ -504,6 +509,7 @@ struct irq_chip {
  * IRQCHIP_ONESHOT_SAFE:   One shot does not require mask/unmask
  * IRQCHIP_EOI_THREADED:   Chip requires eoi() on unmask in threaded mode
  * IRQCHIP_SUPPORTS_LEVEL_MSI  Chip can provide two doorbells for Level MSIs
+ * IRQCHIP_SUPPORTS_NMI:   Chip can deliver NMIs, only for root irqchips
  */
 enum {
IRQCHIP_SET_TYPE_MASKED = (1 <<  0),
@@ -514,6 +520,7 @@ enum {
IRQCHIP_ONESHOT_SAFE= (1 <<  5),
IRQCHIP_EOI_THREADED= (1 <<  6),
IRQCHIP_SUPPORTS_LEVEL_MSI  = (1 <<  7),
+   IRQCHIP_SUPPORTS_NMI= (1 <<  8),
 };
 
 #include 
diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
index 6f63613..59a04d2 100644
--- a/kernel/irq/debugfs.c
+++ b/kernel/irq/debugfs.c
@@ -56,6 +56,7 @@ static void irq_debug_show_masks(struct seq_file *m, struct 
irq_desc *desc) { }
BIT_MASK_DESCR(IRQCHIP_ONESHOT_SAFE),
BIT_MASK_DESCR(IRQCHIP_EOI_THREADED),
BIT_MASK_DESCR(IRQCHIP_SUPPORTS_LEVEL_MSI),
+   BIT_MASK_DESCR(IRQCHIP_SUPPORTS_NMI),
 };
 
 static void
@@ -140,6 +141,7 @@ static void irq_debug_show_masks(struct seq_file *m, struct 
irq_desc *desc) { }
BIT_MASK_DESCR(IRQS_WAITING),
BIT_MASK_DESCR(IRQS_PENDING),
BIT_MASK_DESCR(IRQS_SUSPENDED),
+   BIT_MASK_DESCR(IRQS_NMI),
 };
 
 
@@ -203,8 +205,8 @@ static ssize_t irq_debug_write(struct file *file, const 
char __user *user_buf,
chip_bus_lock(desc);
raw_spin_lock_irqsave(&desc->lock, flags);
 
-   if (irq_settings_is_level(desc)) {
-   /* Can't do level, sorry */
+   if (irq_settings_is_level(desc) 

[PATCH v3 3/4] genirq: Provide NMI handlers

[Julien Thierry]

Provide flow handlers that are NMI safe for interrupts and percpu_devid
interrupts.

Signed-off-by: Julien Thierry 
Cc: Thomas Gleixner 
Cc: Marc Zyngier 
Cc: Peter Zijlstra 
---
 include/linux/irq.h |  3 +++
 kernel/irq/chip.c   | 54 +
 2 files changed, 57 insertions(+)

diff --git a/include/linux/irq.h b/include/linux/irq.h
index 0d71f63..88cbad3 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -600,6 +600,9 @@ static inline int irq_set_parent(int irq, int parent_irq)
 extern void handle_bad_irq(struct irq_desc *desc);
 extern void handle_nested_irq(unsigned int irq);
 
+extern void handle_fasteoi_nmi(struct irq_desc *desc);
+extern void handle_percpu_devid_fasteoi_nmi(struct irq_desc *desc);
+
 extern int irq_chip_compose_msi_msg(struct irq_data *data, struct msi_msg 
*msg);
 extern int irq_chip_pm_get(struct irq_data *data);
 extern int irq_chip_pm_put(struct irq_data *data);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index a2b3d9d..c332c17 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -730,6 +730,37 @@ void handle_fasteoi_irq(struct irq_desc *desc)
 EXPORT_SYMBOL_GPL(handle_fasteoi_irq);
 
 /**
+ * handle_fasteoi_nmi - irq handler for NMI interrupt lines
+ * @desc:  the interrupt description structure for this irq
+ *
+ * A simple NMI-safe handler, considering the restrictions
+ * from request_nmi.
+ *
+ * Only a single callback will be issued to the chip: an ->eoi()
+ * call when the interrupt has been serviced. This enables support
+ * for modern forms of interrupt handlers, which handle the flow
+ * details in hardware, transparently.
+ */
+void handle_fasteoi_nmi(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct irqaction *action = desc->action;
+   unsigned int irq = irq_desc_get_irq(desc);
+   irqreturn_t res;
+
+   trace_irq_handler_entry(irq, action);
+   /*
+* NMIs cannot be shared, there is only one action.
+*/
+   res = action->handler(irq, action->dev_id);
+   trace_irq_handler_exit(irq, action, res);
+
+   if (chip->irq_eoi)
+   chip->irq_eoi(&desc->irq_data);
+}
+EXPORT_SYMBOL_GPL(handle_fasteoi_nmi);
+
+/**
  * handle_edge_irq - edge type IRQ handler
  * @desc:  the interrupt description structure for this irq
  *
@@ -908,6 +939,29 @@ void handle_percpu_devid_irq(struct irq_desc *desc)
chip->irq_eoi(&desc->irq_data);
 }
 
+/**
+ * handle_percpu_devid_fasteoi_nmi - Per CPU local NMI handler with per cpu
+ *  dev ids
+ * @desc:  the interrupt description structure for this irq
+ *
+ * Similar to handle_fasteoi_nmi, but handling the dev_id cookie
+ * as a percpu pointer.
+ */
+void handle_percpu_devid_fasteoi_nmi(struct irq_desc *desc)
+{
+   struct irq_chip *chip = irq_desc_get_chip(desc);
+   struct irqaction *action = desc->action;
+   unsigned int irq = irq_desc_get_irq(desc);
+   irqreturn_t res;
+
+   trace_irq_handler_entry(irq, action);
+   res = action->handler(irq, raw_cpu_ptr(action->percpu_dev_id));
+   trace_irq_handler_exit(irq, action, res);
+
+   if (chip->irq_eoi)
+   chip->irq_eoi(&desc->irq_data);
+}
+
 static void
 __irq_do_set_handler(struct irq_desc *desc, irq_flow_handler_t handle,
 int is_chained, const char *name)
-- 
1.9.1

Re: [PATCH] x86/dumpstack: fix address space casting in show_opcodes()

[Luc Van Oostenryck]

On Thu, Aug 30, 2018 at 09:47:36PM +0200, Jann Horn wrote:
> I sloppily passed a kernel-typed pointer to __range_not_ok(), and sparse
> doesn't like that.
> Make `prologue` a __user pointer (to protect against accidental
> dereferences) and force-cast it to a kernel pointer when calling
> probe_kernel_read(), which will then immediately force-cast it back to a
> user pointer.

It's a bit sad to have to do this.
__range_not_ok() explicitly requires a __user pointer (I don't know
if there is a good reason for it) but  the real job is done by
__chk_range_not_ok(). Can't you use this later instead?


-- Luc Van Oostenryck

Re: [tip:smp/urgent] cpu/hotplug: Remove skip_onerr field from cpuhp_step structure

[Peter Zijlstra]

On Thu, Aug 30, 2018 at 04:03:58AM -0700, tip-bot for Mukesh Ojha wrote:
> Commit-ID:  935aad3015fb4afc0b7ef6e6c18175b95461de47
> Gitweb: 
> https://git.kernel.org/tip/935aad3015fb4afc0b7ef6e6c18175b95461de47
> Author: Mukesh Ojha 
> AuthorDate: Tue, 28 Aug 2018 12:24:54 +0530
> Committer:  Thomas Gleixner 
> CommitDate: Thu, 30 Aug 2018 12:59:30 +0200

> @@ -644,12 +637,6 @@ static void cpuhp_thread_fun(unsigned int cpu)
>  
>   WARN_ON_ONCE(!cpuhp_is_ap_state(state));
>  
> - if (st->rollback) {
> - struct cpuhp_step *step = cpuhp_get_step(state);
> - if (step->skip_onerr)
> - goto next;
> - }
> -
>   if (cpuhp_is_atomic_state(state)) {
>   local_irq_disable();
>   st->result = cpuhp_invoke_callback(cpu, state, bringup, 
> st->node, &st->last);


Can you fold this in?

../kernel/cpu.c: In function ‘cpuhp_thread_fun’:
../kernel/cpu.c:663:1: warning: label ‘next’ defined but not used 
[-Wunused-label]

---
 kernel/cpu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index c544baf75e77..aa7fe85ad62e 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -660,7 +660,6 @@ static void cpuhp_thread_fun(unsigned int cpu)
st->should_run = false;
}
 
-next:
cpuhp_lock_release(bringup);
 
if (!st->should_run)

[PATCH v1 1/2] platform/x86: intel_mid_powerbtn: Get rid of custom ICPU() macro

[Andy Shevchenko]

Replace custom grown macro with generic INTEL_CPU_FAM6() one.

No functional change intended.

Signed-off-by: Andy Shevchenko 
---
 drivers/platform/x86/intel_mid_powerbtn.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/platform/x86/intel_mid_powerbtn.c 
b/drivers/platform/x86/intel_mid_powerbtn.c
index d79fbf924b13..c93299002169 100644
--- a/drivers/platform/x86/intel_mid_powerbtn.c
+++ b/drivers/platform/x86/intel_mid_powerbtn.c
@@ -121,12 +121,9 @@ static const struct mid_pb_ddata mrfld_ddata = {
.setup  = mrfld_setup,
 };
 
-#define ICPU(model, ddata) \
-   { X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (kernel_ulong_t)&ddata }
-
 static const struct x86_cpu_id mid_pb_cpu_ids[] = {
-   ICPU(INTEL_FAM6_ATOM_PENWELL,   mfld_ddata),
-   ICPU(INTEL_FAM6_ATOM_MERRIFIELD,mrfld_ddata),
+   INTEL_CPU_FAM6(ATOM_PENWELL,mfld_ddata),
+   INTEL_CPU_FAM6(ATOM_MERRIFIELD, mrfld_ddata),
{}
 };
 
-- 
2.18.0

[PATCH v1 2/2] platform/x86: intel_pmc_core: Get rid of custom ICPU() macro

[Andy Shevchenko]

Replace custom grown macro with generic INTEL_CPU_FAM6() one.

No functional change intended.

Signed-off-by: Andy Shevchenko 
---
 drivers/platform/x86/intel_pmc_core.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c 
b/drivers/platform/x86/intel_pmc_core.c
index 2d272a3e0176..ab904f238a3d 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -33,9 +33,6 @@
 
 #include "intel_pmc_core.h"
 
-#define ICPU(model, data) \
-   { X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (kernel_ulong_t)data }
-
 static struct pmc_dev pmc;
 
 static const struct pmc_bit_map spt_pll_map[] = {
@@ -648,11 +645,11 @@ static inline void pmc_core_dbgfs_unregister(struct 
pmc_dev *pmcdev)
 #endif /* CONFIG_DEBUG_FS */
 
 static const struct x86_cpu_id intel_pmc_core_ids[] = {
-   ICPU(INTEL_FAM6_SKYLAKE_MOBILE, &spt_reg_map),
-   ICPU(INTEL_FAM6_SKYLAKE_DESKTOP, &spt_reg_map),
-   ICPU(INTEL_FAM6_KABYLAKE_MOBILE, &spt_reg_map),
-   ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, &spt_reg_map),
-   ICPU(INTEL_FAM6_CANNONLAKE_MOBILE, &cnp_reg_map),
+   INTEL_CPU_FAM6(SKYLAKE_MOBILE,  spt_reg_map),
+   INTEL_CPU_FAM6(SKYLAKE_DESKTOP, spt_reg_map),
+   INTEL_CPU_FAM6(KABYLAKE_MOBILE, spt_reg_map),
+   INTEL_CPU_FAM6(KABYLAKE_DESKTOP,spt_reg_map),
+   INTEL_CPU_FAM6(CANNONLAKE_MOBILE,   cnp_reg_map),
{}
 };
 
-- 
2.18.0

Re: [PATCH v12 01/12] livepatch: Change void *new_func -> unsigned long new_addr in struct klp_func

[Miroslav Benes]

On Tue, 28 Aug 2018, Petr Mladek wrote:

> The address of the to be patched function and new function is stored
> in struct klp_func as:
> 
>   void *new_func;
>   unsigned long old_addr;
> 
> The different naming scheme and type is derived from the way how
> the addresses are set. @old_addr is assigned at runtime using
> kallsyms-based search. @new_func is statically initialized,
> for example:
> 
>   static struct klp_func funcs[] = {
>   {
>   .old_name = "cmdline_proc_show",
>   .new_func = livepatch_cmdline_proc_show,
>   }, { }
>   };
> 
> This patch changes void *new_func -> unsigned long new_addr. It removes
> some confusion when these address are later used in the code. It is
> motivated by a followup patch that adds special NOP struct klp_func
> where we want to assign func->new_func = func->old_addr respectively
> func->new_addr = func->old_addr.
> 
> This patch does not modify the existing behavior.
> 
> IMPORTANT: This patch modifies ABI. The patches will need to use,
> for example:
> 
>   static struct klp_func funcs[] = {
>   {
>   .old_name = "cmdline_proc_show",
>   .new_addr = (unsigned long)livepatch_cmdline_proc_show,
>   }, { }
>   };
> 
> Suggested-by: Josh Poimboeuf 
> Signed-off-by: Petr Mladek 

I'm not convinced the patch makes things any better. The next patch 
slightly improves it, but still. Is new_func really such a problem?

Thanks,
Miroslav

Re: [PATCH v12 03/12] livepatch: Shuffle klp_enable_patch()/klp_disable_patch() code

[Miroslav Benes]

On Tue, 28 Aug 2018, Petr Mladek wrote:

> We are going to simplify the API and code by removing the registration
> step. This would require calling init/free functions from enable/disable
> ones.
> 
> This patch just moves the code the code to prevent more forward
> declarations.

s/the code the code/the code/
 
> This patch does not change the code except of two forward declarations.
> 
> Signed-off-by: Petr Mladek 

Miroslav

Re: [PATCH v2 1/3] spi: Introduce one new field to set word delay

[Baolin Wang]

On 29 August 2018 at 19:33, Jan Kundrát  wrote:
> On čtvrtek 16. srpna 2018 14:54:49 CEST, Baolin Wang wrote:
>>
>> + * @word_delay: clock cycles to inter word delay after each word size
>> + * (set by bits_per_word) transmission.
>
>
> I need a similar functionality for talking to a SPI device from userspace
> -- see my attempt for implementing this in spi-orion.c at [1]. The device's
> datasheet says that I should wait, e.g., 3µs between each two words. I
> therefore like this patch :).
>
> The description can be improved because it left me wondering what "clock
> this is about. I suppose it's about the SPI clock cycles and not CPU clock
> cycles, right? I'll be hapy to patch this once Baolin confirms that that is
> the intended meaning.

Sorry for confusing. Since our SPI word delay unit is clock cycle of
the SPI clock, so my intention of the word_delay's unit is SPI clock
cycles according to our previous discussion.

>
> It seems that this is only implemented in one newly added driver. I'm
> interested in supporting this in spi-orion.c, but that sounds like
> driver-specific work for something which is pretty generic. How should this
> be implemented? Given that drivers for SPI masters can implement a function
> which transfers several words at once, there are not that many better
> possibilities than adding udelay()s, though. Thoughts?
>
> What is your plan to do with drivers which do not implement this (yet)? If a
> spi_transfer gets queued which asks for a word_delay delay, it is silently
> ignored now, AFAIU.
>
> What about userspace support, spidev and spi_ioc_transfer (that's my target,
> actually)? Is it OK to s/pad/word_delay/ in the spidev code and pass that to
> the generated struct spi_transfer? In my opinion, once we support specifying
> this from userspace, one has to definitely check that the SPI controller is
> ready to honor this request. Do we want a new bit in spi_controller.flags
> for this?
>
> With kind regards,
> Jan
>
> [1] https://patchwork.kernel.org/patch/10221397/



-- 
Baolin Wang
Best Regards

Re: Redoing eXclusive Page Frame Ownership (XPFO) with isolated CPUs in mind (for KVM to isolate its guests per CPU)

[James Bottomley]

On Mon, 2018-08-20 at 21:52 +, Woodhouse, David wrote:
> On Mon, 2018-08-20 at 14:48 -0700, Linus Torvalds wrote:
> > 
> > Of course, after the long (and entirely unrelated) discussion about
> > the TLB flushing bug we had, I'm starting to worry about my own
> > competence, and maybe I'm missing something really fundamental, and
> > the XPFO patches do something else than what I think they do, or my
> > "hey, let's use our Meltdown code" idea has some fundamental
> > weakness
> > that I'm missing.
> 
> The interesting part is taking the user (and other) pages out of the
> kernel's 1:1 physmap.
> 
> It's the *kernel* we don't want being able to access those pages,
> because of the multitude of unfixable cache load gadgets.

A long time ago, I gave a talk about precisely this at OLS (2005 I
think).  On PA-RISC we have a problem with inequivalent aliasing in the
 page cache (same physical page with two different virtual addresses
modulo 4MB) which causes a machine check if it occurs. 
Architecturally, PA can move into the cache any page for which it has a
mapping and the kernel offset map of every page causes an inequivalency
if the same page is in use in user space.  Of course, practically the
caching machinery is too busy moving in and out pages we reference to
have an interest in speculating on other pages it has a mapping for, so
it almost never (the almost being a set of machine checks we see very
occasionally in the latest and most aggressively cached and speculating
CPUs).  If this were implemented, we'd be interested in using it.

James

Re: [RFC PATCH v1 0/3] device property: Support MAC address in VPD

[Srinivas Kandagatla]

Sorry for the delay!! For some reason I missed this email thread totally!

On 31/08/18 02:26, Brian Norris wrote:

Seems to me that nvmem needs to be extended to allow providers to
retrieve and interpret data. Not everything is at some fixed offset and
size. Something like this is valid dts:

nvmem = <&phandle> "a-string";



There has been some discussion on extending nvmem support to MTD and 
non-DT users in https://patchwork.kernel.org/cover/10562365/


One of the thing which we discussed in this thread is adding compatible 
strings to cells mainly to

1> Differentiate between actual cells and partitions for MTD case.

2> Allow provider specific bindings for each cell, in VPD instance key 
string & value length could be one them.


This means that we would endup adding xlate callback support to the 
nvmem_config.


AFAIU, From consumer side old bindings should still work!

From non-dt or ACPI side these cells can be parsed by the provider 
driver and add it to the nvmem_config.


Does this make sense? Or Did I miss anything obvious ?



But that's pretty uncommon (I can't think of a binding that actually
uses that). Perhaps the provider has an array of keys defined and the
consumer just provides the index.

In the case of VPD, all keys are 0-terminated strings (there's also a
length field, but the key is still 0-terminated), so that scheme could
work. (I'm not sure an indexed provider is extremely relevant right now,
although it probably could be supported if I expand the of_nvmem
retrieval to support a generic of_xlate() override anyway.) The
information represented is almost the same as in my proposal, except that:
(a) now I have to give the VPD a phandle -- so far, I've avoided that,
 as it's just an auto-enumerated device underneath the
 /firmware/coreboot device (see drivers/firmware/google/vpd.c)
(b) this is no longer directly useful to ACPI systems -- I'm not
 actually sure how (if at all) nvmem provider/consumer is supposed to
 work there

But maybe this isn't really that useful to ACPI, and it's sufficient to
just have fwnode_get_mac_address() call of_get_nvmem_mac_address() when
we're using DT.


Or we could do '-nvmem = <&phandle>', but parsing that is a bit
more complicated.

That doesn't seem to have much advantage to me.

Re: [PATCH v1 2/2] platform/x86: intel_pmc_core: Get rid of custom ICPU() macro

[Andy Shevchenko]

On Fri, Aug 31, 2018 at 11:50 AM Andy Shevchenko
 wrote:
>
> Replace custom grown macro with generic INTEL_CPU_FAM6() one.
>
> No functional change intended.

Actually there is one, that's why please drop this patch.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] PM / devfreq: stopping the governor before device_unregister()

[Chanwoo Choi]

Hi,

On 2018년 08월 30일 19:02, vincent.donnef...@arm.com wrote:
> From: Vincent Donnefort 
> 
> device_release() is freeing the resources before calling the device
> specific release callback which is, in the case of devfreq, stopping
> the governor.
> 
> It is a problem as some governors are using the device resources. e.g.
> simpleondemand which is using the devfreq deferrable monitoring work. If it
> is not stopped before the resources are freed, it might lead to a use after
> free.
> 
> Signed-off-by: Vincent Donnefort 
> Reviewed-by: John Einar Reitan 
> 
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index 4c49bb1..4e43830 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -534,10 +534,6 @@ static void devfreq_dev_release(struct device *dev)
>   list_del(&devfreq->node);
>   mutex_unlock(&devfreq_list_lock);
>  
> - if (devfreq->governor)
> - devfreq->governor->event_handler(devfreq,
> -  DEVFREQ_GOV_STOP, NULL);
> -
>   if (devfreq->profile->exit)
>   devfreq->profile->exit(devfreq->dev.parent);
>  
> @@ -672,7 +668,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
>   list_del(&devfreq->node);
>   mutex_unlock(&devfreq_list_lock);
>  
> - device_unregister(&devfreq->dev);
> + devfreq_remove_device(devfreq);
>   devfreq = NULL;
>  err_dev:
>   if (devfreq)
> @@ -693,6 +689,9 @@ int devfreq_remove_device(struct devfreq *devfreq)
>   if (!devfreq)
>   return -EINVAL;
>  
> + if (devfreq->governor)
> + devfreq->governor->event_handler(devfreq,
> +  DEVFREQ_GOV_STOP, NULL);
>   device_unregister(&devfreq->dev);
>  
>   return 0;
> 

As description of this patch, if devfreq_wq is executed and then execute
the 'devfreq->governor->get_target_freq' between step1 and step2
after already freed the 'dev' related resource, it might happen the problem
because the registered callback of get_target_freq requires the 'dev' resource.

device_unregister(dev)
step 1. device_del(dev)
<- if devfreq_wq is executed
step 2. put_device(dev)
device_release()
devfreq_dev_release()
stop the governor for specific devfreq instance

It looks good to me. Stop the governor before calling device_unregister().
Reviewed-by: Chanwoo Choi

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] MAINTAINERS: Add me as a keys/trusted maintainer

[Jarkko Sakkinen]

David, what do you think?

/Jarkko

On Tue, Aug 14, 2018 at 05:57:48PM +0300, Jarkko Sakkinen wrote:
> As a TPM maintainer I have to review all these commits. This commit is
> just to make that documented.
> 
> Signed-off-by: Jarkko Sakkinen 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3119bba7971c..4b51c13ae2d8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7928,6 +7928,7 @@ F:  security/keys/encrypted-keys/
>  KEYS-TRUSTED
>  M:   James Bottomley 
>  M:   Mimi Zohar 
> +M:   Jarkko Sakkkinen 
>  L:   linux-integr...@vger.kernel.org
>  L:   keyri...@vger.kernel.org
>  S:   Supported
> -- 
> 2.17.1
> 

Re: [PATCH v5 0/2] tpm: add support for nonblocking operation

[Jarkko Sakkinen]

Are you planning to send v6 soon fixing the minor things in 1/2 (typo
+ change for the commit message)?

/Jarkko

On Mon, Aug 13, 2018 at 01:32:48PM -0700, Tadeusz Struk wrote:
> The TCG SAPI specification [1] defines a set of functions, which allow
> applications to use the TPM device in either blocking or non-blocking fashion.
> Each command defined by the specification has a corresponding
> Tss2_Sys__Prepare() and Tss2_Sys__Complete() call, which
> together with Tss2_Sys_ExecuteAsync() is designed to allow asynchronous
> mode of operation. Currently the TPM driver supports only blocking calls,
> which doesn't allow asynchronous IO operations.
> This patch changes it and adds support for nonblocking write and a new poll
> function to enable applications, which want to take advantage of this feature.
> The new functionality can be tested using standard TPM tools implemented
> in [2], together with modified TCTI from [3], and an example application
> by Philip Tricca [4]. Here is a short description from Philip:
> 
> "The example application `glib-tss2-event` uses a glib main event loop
> to create an RSA 2048 primary key in the TPM2 NULL hierarchy while
> using a glib timer event to time the operation. A GSource object is
> used to generate an event when the FD underlying the tss2 function
> call has data ready. While the application waits for an event indicating
> that the CreatePrimary operation is complete, it counts timer events
> that occur every 100ms. Once the CreatePrimary operation completes the
> number of timer events that occurred is used to make a rough calculation
> of the elapsed time. This value is then printed to the console.
> This takes ~300 lines of C code and requires no management or
> synchronization of threads. The glib GMainContext is "just a poll()
> loop" according to the glib documentation here:
> 
> https://developer.gnome.org/programming-guidelines/stable/main-contexts.html.en
> 
> and so supporting 'poll' is the easiest way to integrate with glib /
> gtk+. This is true of any other event system that relies on 'poll'
> instead of worker threads."
> 
> [1] 
> https://trustedcomputinggroup.org/wp-content/uploads/TSS_SAPI_Version-1.1_Revision-22_review_030918.pdf
> [2] https://github.com/tpm2-software/tpm2-tools
> [3] https://github.com/tstruk/tpm2-tss/tree/async
> [4] https://github.com/flihp/glib-tss2-async-example
> 
> ---
> Changes in v5:
> - Changed the workqueue allocation time back from the first user interface
>   open to module init.
> 
> Changes in v4:
> - Changed the way buffer_mutex is handled in nonblocking mode so that
>   it is not held when write() returns to user space.
> 
> Changes in v3:
> - Fixed problem reported by 0-dey kbuild test robot around __exitcall.
>   It complained because there is a module_exit() in another file already.
> - Added info on example application from Philip
> 
> Changes in v2:
> - Split the change into two separate patches. First patch adds a pointer
>   to the space to the struct file_priv to have access to it from the async 
> job.
>   This is to avoid memory allocations on every write call. Now everything
>   what's needed is in the file_priv struct.
> - Renamed the 'work' member of the timer to avoid confusion.
>   Now there are 'timeout_work' and 'async_work'.
> - Removed the global wait queue and moved it to file_priv.
> - Only creating the work queue when the first file is opened.
> 
> Tadeusz Struk (2):
>   tpm: add ptr to the tpm_space struct to file_priv
>   tpm: add support for nonblocking operation
> 
>  drivers/char/tpm/tpm-dev-common.c |  150 
> +++--
>  drivers/char/tpm/tpm-dev.c|   22 +++--
>  drivers/char/tpm/tpm-dev.h|   19 +++--
>  drivers/char/tpm/tpm-interface.c  |1 
>  drivers/char/tpm/tpm.h|1 
>  drivers/char/tpm/tpmrm-dev.c  |   31 
>  6 files changed, 152 insertions(+), 72 deletions(-)
> 
> --
> TS

Re: [PATCH v5 0/2] tpm: add support for nonblocking operation

[Jarkko Sakkinen]

Just the change to the commit message. Mislooked patchwork, the typo was
in my response :-) I'll do recheck for 2/2. Check those comments before
v6 if there is anything else.

/Jarkko

On Fri, Aug 31, 2018 at 11:57:11AM +0300, Jarkko Sakkinen wrote:
> Are you planning to send v6 soon fixing the minor things in 1/2 (typo
> + change for the commit message)?
> 
> /Jarkko
> 
> On Mon, Aug 13, 2018 at 01:32:48PM -0700, Tadeusz Struk wrote:
> > The TCG SAPI specification [1] defines a set of functions, which allow
> > applications to use the TPM device in either blocking or non-blocking 
> > fashion.
> > Each command defined by the specification has a corresponding
> > Tss2_Sys__Prepare() and Tss2_Sys__Complete() call, which
> > together with Tss2_Sys_ExecuteAsync() is designed to allow asynchronous
> > mode of operation. Currently the TPM driver supports only blocking calls,
> > which doesn't allow asynchronous IO operations.
> > This patch changes it and adds support for nonblocking write and a new poll
> > function to enable applications, which want to take advantage of this 
> > feature.
> > The new functionality can be tested using standard TPM tools implemented
> > in [2], together with modified TCTI from [3], and an example application
> > by Philip Tricca [4]. Here is a short description from Philip:
> > 
> > "The example application `glib-tss2-event` uses a glib main event loop
> > to create an RSA 2048 primary key in the TPM2 NULL hierarchy while
> > using a glib timer event to time the operation. A GSource object is
> > used to generate an event when the FD underlying the tss2 function
> > call has data ready. While the application waits for an event indicating
> > that the CreatePrimary operation is complete, it counts timer events
> > that occur every 100ms. Once the CreatePrimary operation completes the
> > number of timer events that occurred is used to make a rough calculation
> > of the elapsed time. This value is then printed to the console.
> > This takes ~300 lines of C code and requires no management or
> > synchronization of threads. The glib GMainContext is "just a poll()
> > loop" according to the glib documentation here:
> > 
> > https://developer.gnome.org/programming-guidelines/stable/main-contexts.html.en
> > 
> > and so supporting 'poll' is the easiest way to integrate with glib /
> > gtk+. This is true of any other event system that relies on 'poll'
> > instead of worker threads."
> > 
> > [1] 
> > https://trustedcomputinggroup.org/wp-content/uploads/TSS_SAPI_Version-1.1_Revision-22_review_030918.pdf
> > [2] https://github.com/tpm2-software/tpm2-tools
> > [3] https://github.com/tstruk/tpm2-tss/tree/async
> > [4] https://github.com/flihp/glib-tss2-async-example
> > 
> > ---
> > Changes in v5:
> > - Changed the workqueue allocation time back from the first user interface
> >   open to module init.
> > 
> > Changes in v4:
> > - Changed the way buffer_mutex is handled in nonblocking mode so that
> >   it is not held when write() returns to user space.
> > 
> > Changes in v3:
> > - Fixed problem reported by 0-dey kbuild test robot around __exitcall.
> >   It complained because there is a module_exit() in another file already.
> > - Added info on example application from Philip
> > 
> > Changes in v2:
> > - Split the change into two separate patches. First patch adds a pointer
> >   to the space to the struct file_priv to have access to it from the async 
> > job.
> >   This is to avoid memory allocations on every write call. Now everything
> >   what's needed is in the file_priv struct.
> > - Renamed the 'work' member of the timer to avoid confusion.
> >   Now there are 'timeout_work' and 'async_work'.
> > - Removed the global wait queue and moved it to file_priv.
> > - Only creating the work queue when the first file is opened.
> > 
> > Tadeusz Struk (2):
> >   tpm: add ptr to the tpm_space struct to file_priv
> >   tpm: add support for nonblocking operation
> > 
> >  drivers/char/tpm/tpm-dev-common.c |  150 
> > +++--
> >  drivers/char/tpm/tpm-dev.c|   22 +++--
> >  drivers/char/tpm/tpm-dev.h|   19 +++--
> >  drivers/char/tpm/tpm-interface.c  |1 
> >  drivers/char/tpm/tpm.h|1 
> >  drivers/char/tpm/tpmrm-dev.c  |   31 
> >  6 files changed, 152 insertions(+), 72 deletions(-)
> > 
> > --
> > TS

[PATCH 1/2] mtd: spi-nor: add macros related to MICRON flash

[Yogesh Gaur]

Some MICRON related macros in spi-nor domain were ST.
Rename entries related to STMicroelectronics under macro SNOR_MFR_ST.

Added entry of MFR Id for Micron flashes, 0x002C.

Signed-off-by: Yogesh Gaur 
---
 drivers/mtd/spi-nor/spi-nor.c | 9 ++---
 include/linux/mtd/cfi.h   | 1 +
 include/linux/mtd/spi-nor.h   | 3 ++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index f028277..33a55bc 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -271,6 +271,7 @@ static inline int set_4byte(struct spi_nor *nor, const 
struct flash_info *info,
u8 cmd;
 
switch (JEDEC_MFR(info)) {
+   case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
/* Some Micron need WREN command; all will accept it */
need_wren = true;
@@ -1096,7 +1097,7 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t 
ofs, uint64_t len)
{ "mx66l1g45g",  INFO(0xc2201b, 0, 64 * 1024, 2048, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) 
},
 
-   /* Micron */
+   /* Micron <--> ST Micro */
{ "n25q016a",INFO(0x20bb15, 0, 64 * 1024,   32, SECT_4K | 
SPI_NOR_QUAD_READ) },
{ "n25q032", INFO(0x20ba16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) 
},
{ "n25q032a",INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) 
},
@@ -2502,6 +2503,7 @@ static int spi_nor_init_params(struct spi_nor *nor,
params->quad_enable = macronix_quad_enable;
break;
 
+   case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
break;
 
@@ -2876,8 +2878,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
mtd->_resume = spi_nor_resume;
 
/* NOR protection support for STmicro/Micron chips and similar */
-   if (JEDEC_MFR(info) == SNOR_MFR_MICRON ||
-   info->flags & SPI_NOR_HAS_LOCK) {
+   if (JEDEC_MFR(info) == SNOR_MFR_ST ||
+   JEDEC_MFR(info) == SNOR_MFR_MICRON ||
+   info->flags & SPI_NOR_HAS_LOCK) {
nor->flash_lock = stm_lock;
nor->flash_unlock = stm_unlock;
nor->flash_is_locked = stm_is_locked;
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..cbf7716 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -377,6 +377,7 @@ struct cfi_fixup {
 #define CFI_MFR_SHARP  0x00B0
 #define CFI_MFR_SST0x00BF
 #define CFI_MFR_ST 0x0020 /* STMicroelectronics */
+#define CFI_MFR_MICRON 0x002C /* Micron */
 #define CFI_MFR_TOSHIBA0x0098
 #define CFI_MFR_WINBOND0x00DA
 
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index c922e97..f43bfc5 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -23,7 +23,8 @@
 #define SNOR_MFR_ATMEL CFI_MFR_ATMEL
 #define SNOR_MFR_GIGADEVICE0xc8
 #define SNOR_MFR_INTEL CFI_MFR_INTEL
-#define SNOR_MFR_MICRONCFI_MFR_ST /* ST Micro <--> Micron */
+#define SNOR_MFR_STCFI_MFR_ST  /* ST Micro */
+#define SNOR_MFR_MICRONCFI_MFR_MICRON  /* Micron */
 #define SNOR_MFR_MACRONIX  CFI_MFR_MACRONIX
 #define SNOR_MFR_SPANSION  CFI_MFR_AMD
 #define SNOR_MFR_SST   CFI_MFR_SST
-- 
1.9.1

[PATCH 2/2] mtd: spi-nor: add entry for mt35xu512aba flash

[Yogesh Gaur]

Add entry for mt35xu512aba Micron NOR flash.
This flash is having uniform sector erase size of 128KB, have
support of FSR(flag status register), flash size is 64MB and
supports 4-byte commands.

Signed-off-by: Yogesh Gaur 
---
 drivers/mtd/spi-nor/spi-nor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 33a55bc..6042df8 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1113,6 +1113,9 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t 
ofs, uint64_t len)
{ "n25q00a", INFO(0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ "mt25qu02g",   INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
 
+   /* Micron */
+   { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR 
| SPI_NOR_4B_OPCODES) },
+
/* PMC */
{ "pm25lv512",   INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
{ "pm25lv010",   INFO(0,0, 32 * 1024,4, SECT_4K_PMC) },
-- 
1.9.1

[PATCH 0/2] mtd: spi-nor: add entry for mt35xu512aba flash

[Yogesh Gaur]

Add MFR_ID information, 0x002C, related to the Micron flash.
Currently, MFR_ID 0x0020 is being specified as Micron flash ID but
these are actually CFI ID of STMicro flashes.

Rename SNOR_MFR_MICRON to SNOR_MFR_ST and add entry for
SNOR_MFR_MICRON having CFI ID value of Micron flash.
Add entry of mt35xu512aba flash in spi_nor_ids table.

Yogesh Gaur (2):
  mtd: spi-nor: add macros related to MICRON flash
  mtd: spi-nor: add entry for mt35xu512aba flash

 drivers/mtd/spi-nor/spi-nor.c | 12 +---
 include/linux/mtd/cfi.h   |  1 +
 include/linux/mtd/spi-nor.h   |  3 ++-
 3 files changed, 12 insertions(+), 4 deletions(-)

-- 
1.9.1

Re: [PATCH v6 03/14] PM: Introduce an Energy Model management framework

[Patrick Bellasi]

On 29-Aug 14:28, Quentin Perret wrote:
> Hi Patrick,
> 
> On Wednesday 29 Aug 2018 at 11:04:35 (+0100), Patrick Bellasi wrote:
> > In the loop above we use smp_store_release() to propagate the pointer
> > setting in a PER_CPU(em_data), which ultimate goal is to protect
> > em_register_perf_domain() from multiple clients registering the same
> > power domain.
> > 
> > I think there are two possible optimizations there:
> > 
> > 1. use of a single memory barrier
> > 
> >Since we are already em_pd_mutex protected, i.e. there cannot be a
> >concurrent writers, we can use one single memory barrier after the
> >loop, i.e.
> > 
> > for_each_cpu(cpu, span)
> > WRITE_ONCE()
> > smp_wmb()
> > 
> >which should be just enough to ensure that all other CPUs will see
> >the pointer set once we release the mutex
> 
> Right, I'm actually wondering if the memory barrier is needed at all ...
> The mutex lock()/unlock() should already ensure the ordering I want no ?
> 
> WRITE_ONCE() should prevent load/store tearing with concurrent em_cpu_get(),
> and the release/acquire semantics of mutex lock/unlock should be enough to
> serialize the memory accesses of concurrent em_register_perf_domain() calls
> properly ...
> 
> Hmm, let me read memory-barriers.txt again.

Yes, I think it should... but better double check.

> > 2. avoid using PER_CPU variables
> > 
> >Apart from the initialization code, i.e. boot time, the em_data is
> >expected to be read only, isn't it?
> 
> That's right. It's not only read only, it's also not read very often (in
> the use-cases I have in mind at least). The scheduler for example will
> call em_cpu_get() once when sched domains are built, and keep the
> reference instead of calling it again.
> 
> >If that's the case, I think that using PER_CPU variables is not
> >strictly required while it unnecessarily increases the cache pressure.
> > 
> >In the worst case we can end up with one cache line for each CPU to
> >host just an 8B pointer, instead of using that single cache line to host
> >up to 8 pointers if we use just an array, i.e.
> > 
> > struct em_perf_domain *em_data[NR_CPUS]
> > cacheline_aligned_in_smp __read_mostly;
> > 
> >Consider also that: up to 8 pointers in a single cache line means
> >also that single cache line can be enough to access the EM from all
> >the CPUs of almost every modern mobile phone SoC.
> > 
> >Note entirely sure if PER_CPU uses less overall memory in case you
> >have much less CPUs then the compile time defined NR_CPUS.
> >But still, if the above makes sense, you still have a 8x gain
> >factor between number Write allocated .data..percp sections and
> >the value of NR_CPUS. Meaning that in the worst case we allocate
> >the same amount of memory using NR_CPUS=64 (the default on arm64)
> >while running on an 8 CPUs system... but still we should get less
> >cluster caches pressure at run-time with the array approach, 1
> >cache line vs 4.
> 
> Right, using per_cpu() might cause to bring in cache things you don't
> really care about (other non-related per_cpu stuff), but that shouldn't
> waste memory I think. I mean, if my em_data var is the first in a cache
> line, the rest of the cache line will most likely be used by other
> per_cpu variables anyways ...
> 
> As you suggested, the alternative would be to have a simple array. I'm
> fine with this TBH. But I would probably allocate it dynamically using
> nr_cpu_ids instead of using a static NR_CPUS-wide thing though -- the
> registration of perf domains usually happens late enough in the boot
> process.
> 
> What do you think ?

Sound all reasonable to me.

> Thanks
> Quentin

Best Patrick

-- 
#include 

Patrick Bellasi

[PATCH 1/2] mtd: spi-nor: add macros related to MICRON flash

[Yogesh Gaur]

Some MICRON related macros in spi-nor domain were ST.
Rename entries related to STMicroelectronics under macro SNOR_MFR_ST.

Added entry of MFR Id for Micron flashes, 0x002C.

Signed-off-by: Yogesh Gaur 
---
 drivers/mtd/spi-nor/spi-nor.c | 9 ++---
 include/linux/mtd/cfi.h   | 1 +
 include/linux/mtd/spi-nor.h   | 3 ++-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index f028277..33a55bc 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -271,6 +271,7 @@ static inline int set_4byte(struct spi_nor *nor, const 
struct flash_info *info,
u8 cmd;
 
switch (JEDEC_MFR(info)) {
+   case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
/* Some Micron need WREN command; all will accept it */
need_wren = true;
@@ -1096,7 +1097,7 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t 
ofs, uint64_t len)
{ "mx66l1g45g",  INFO(0xc2201b, 0, 64 * 1024, 2048, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ "mx66l1g55g",  INFO(0xc2261b, 0, 64 * 1024, 2048, SPI_NOR_QUAD_READ) 
},
 
-   /* Micron */
+   /* Micron <--> ST Micro */
{ "n25q016a",INFO(0x20bb15, 0, 64 * 1024,   32, SECT_4K | 
SPI_NOR_QUAD_READ) },
{ "n25q032", INFO(0x20ba16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) 
},
{ "n25q032a",INFO(0x20bb16, 0, 64 * 1024,   64, SPI_NOR_QUAD_READ) 
},
@@ -2502,6 +2503,7 @@ static int spi_nor_init_params(struct spi_nor *nor,
params->quad_enable = macronix_quad_enable;
break;
 
+   case SNOR_MFR_ST:
case SNOR_MFR_MICRON:
break;
 
@@ -2876,8 +2878,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
mtd->_resume = spi_nor_resume;
 
/* NOR protection support for STmicro/Micron chips and similar */
-   if (JEDEC_MFR(info) == SNOR_MFR_MICRON ||
-   info->flags & SPI_NOR_HAS_LOCK) {
+   if (JEDEC_MFR(info) == SNOR_MFR_ST ||
+   JEDEC_MFR(info) == SNOR_MFR_MICRON ||
+   info->flags & SPI_NOR_HAS_LOCK) {
nor->flash_lock = stm_lock;
nor->flash_unlock = stm_unlock;
nor->flash_is_locked = stm_is_locked;
diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..cbf7716 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -377,6 +377,7 @@ struct cfi_fixup {
 #define CFI_MFR_SHARP  0x00B0
 #define CFI_MFR_SST0x00BF
 #define CFI_MFR_ST 0x0020 /* STMicroelectronics */
+#define CFI_MFR_MICRON 0x002C /* Micron */
 #define CFI_MFR_TOSHIBA0x0098
 #define CFI_MFR_WINBOND0x00DA
 
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index c922e97..f43bfc5 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -23,7 +23,8 @@
 #define SNOR_MFR_ATMEL CFI_MFR_ATMEL
 #define SNOR_MFR_GIGADEVICE0xc8
 #define SNOR_MFR_INTEL CFI_MFR_INTEL
-#define SNOR_MFR_MICRONCFI_MFR_ST /* ST Micro <--> Micron */
+#define SNOR_MFR_STCFI_MFR_ST  /* ST Micro */
+#define SNOR_MFR_MICRONCFI_MFR_MICRON  /* Micron */
 #define SNOR_MFR_MACRONIX  CFI_MFR_MACRONIX
 #define SNOR_MFR_SPANSION  CFI_MFR_AMD
 #define SNOR_MFR_SST   CFI_MFR_SST
-- 
1.9.1

[PATCH 2/2] mtd: spi-nor: add entry for mt35xu512aba flash

[Yogesh Gaur]

Add entry for mt35xu512aba Micron NOR flash.
This flash is having uniform sector erase size of 128KB, have
support of FSR(flag status register), flash size is 64MB and
supports 4-byte commands.

Signed-off-by: Yogesh Gaur 
---
 drivers/mtd/spi-nor/spi-nor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 33a55bc..6042df8 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -1113,6 +1113,9 @@ static int spi_nor_is_locked(struct mtd_info *mtd, loff_t 
ofs, uint64_t len)
{ "n25q00a", INFO(0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ "mt25qu02g",   INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
 
+   /* Micron */
+   { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR 
| SPI_NOR_4B_OPCODES) },
+
/* PMC */
{ "pm25lv512",   INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
{ "pm25lv010",   INFO(0,0, 32 * 1024,4, SECT_4K_PMC) },
-- 
1.9.1

[PATCH 0/2] mtd: spi-nor: add entry for mt35xu512aba flash

[Yogesh Gaur]

Add MFR_ID information, 0x002C, related to the Micron flash.
Currently, MFR_ID 0x0020 is being specified as Micron flash ID but
these are actually CFI ID of STMicro flashes.

Rename SNOR_MFR_MICRON to SNOR_MFR_ST and add entry for
SNOR_MFR_MICRON having CFI ID value of Micron flash.
Add entry of mt35xu512aba flash in spi_nor_ids table.

Yogesh Gaur (2):
  mtd: spi-nor: add macros related to MICRON flash
  mtd: spi-nor: add entry for mt35xu512aba flash

 drivers/mtd/spi-nor/spi-nor.c | 12 +---
 include/linux/mtd/cfi.h   |  1 +
 include/linux/mtd/spi-nor.h   |  3 ++-
 3 files changed, 12 insertions(+), 4 deletions(-)

-- 
1.9.1

Re: [PATCH v5 2/2] tpm: add support for nonblocking operation

[Jarkko Sakkinen]

Mon, Aug 13, 2018 at 01:32:58PM -0700, Tadeusz Struk wrote:
> Currently the TPM driver only supports blocking calls, which doesn't allow
> asynchronous IO operations to the TPM hardware.
> This patch changes it and adds support for nonblocking write and a new poll
> function to enable applications, which want to take advantage of this.
> 
> Tested-by: Philip Tricca 
> Signed-off-by: Tadeusz Struk 
> ---
>  drivers/char/tpm/tpm-dev-common.c |  142 
> -
>  drivers/char/tpm/tpm-dev.c|1 
>  drivers/char/tpm/tpm-dev.h|   13 ++-
>  drivers/char/tpm/tpm-interface.c  |   24 +-
>  drivers/char/tpm/tpm.h|2 +
>  drivers/char/tpm/tpmrm-dev.c  |1 
>  6 files changed, 138 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-dev-common.c 
> b/drivers/char/tpm/tpm-dev-common.c
> index f0c033b69b62..a7ae0072044b 100644
> --- a/drivers/char/tpm/tpm-dev-common.c
> +++ b/drivers/char/tpm/tpm-dev-common.c
> @@ -17,11 +17,36 @@
>   * License.
>   *
>   */
> +#include 
>  #include 
>  #include 
> +#include 
>  #include "tpm.h"
>  #include "tpm-dev.h"
>  
> +static struct workqueue_struct *tpm_dev_wq;
> +static DEFINE_MUTEX(tpm_dev_wq_lock);
> +
> +static void tpm_async_work(struct work_struct *work)
> +{
> + struct file_priv *priv =
> + container_of(work, struct file_priv, async_work);
> + ssize_t ret;
> +
> + mutex_lock(&priv->buffer_mutex);
> + priv->command_enqueued = false;
> + ret = tpm_transmit(priv->chip, priv->space, priv->data_buffer,
> +sizeof(priv->data_buffer), 0);
> +
> + tpm_put_ops(priv->chip);
> + if (ret > 0) {
> + priv->data_pending = ret;
> + mod_timer(&priv->user_read_timer, jiffies + (120 * HZ));
> + }
> + mutex_unlock(&priv->buffer_mutex);
> + wake_up_interruptible(&priv->async_wait);
> +}
> +
>  static void user_reader_timeout(struct timer_list *t)
>  {
>   struct file_priv *priv = from_timer(priv, t, user_read_timer);
> @@ -29,17 +54,19 @@ static void user_reader_timeout(struct timer_list *t)
>   pr_warn("TPM user space timeout is deprecated (pid=%d)\n",
>   task_tgid_nr(current));
>  
> - schedule_work(&priv->work);
> + schedule_work(&priv->timeout_work);
>  }
>  
> -static void timeout_work(struct work_struct *work)
> +static void tpm_timeout_work(struct work_struct *work)
>  {
> - struct file_priv *priv = container_of(work, struct file_priv, work);
> + struct file_priv *priv = container_of(work, struct file_priv,
> +   timeout_work);
>  
>   mutex_lock(&priv->buffer_mutex);
>   priv->data_pending = 0;
>   memset(priv->data_buffer, 0, sizeof(priv->data_buffer));
>   mutex_unlock(&priv->buffer_mutex);
> + wake_up_interruptible(&priv->async_wait);
>  }
>  
>  void tpm_common_open(struct file *file, struct tpm_chip *chip,
> @@ -50,8 +77,9 @@ void tpm_common_open(struct file *file, struct tpm_chip 
> *chip,
>  
>   mutex_init(&priv->buffer_mutex);
>   timer_setup(&priv->user_read_timer, user_reader_timeout, 0);
> - INIT_WORK(&priv->work, timeout_work);
> -
> + INIT_WORK(&priv->timeout_work, tpm_timeout_work);
> + INIT_WORK(&priv->async_work, tpm_async_work);
> + init_waitqueue_head(&priv->async_wait);
>   file->private_data = priv;
>  }
>  
> @@ -63,15 +91,17 @@ ssize_t tpm_common_read(struct file *file, char __user 
> *buf,
>   int rc;
>  
>   del_singleshot_timer_sync(&priv->user_read_timer);
> - flush_work(&priv->work);
> + flush_work(&priv->timeout_work);
>   mutex_lock(&priv->buffer_mutex);
>  
>   if (priv->data_pending) {
>   ret_size = min_t(ssize_t, size, priv->data_pending);
> - rc = copy_to_user(buf, priv->data_buffer, ret_size);
> - memset(priv->data_buffer, 0, priv->data_pending);
> - if (rc)
> - ret_size = -EFAULT;
> + if (ret_size > 0) {
> + rc = copy_to_user(buf, priv->data_buffer, ret_size);
> + memset(priv->data_buffer, 0, priv->data_pending);
> + if (rc)
> + ret_size = -EFAULT;
> + }
>  
>   priv->data_pending = 0;
>   }
> @@ -84,10 +114,9 @@ ssize_t tpm_common_write(struct file *file, const char 
> __user *buf,
>size_t size, loff_t *off)
>  {
>   struct file_priv *priv = file->private_data;
> - size_t in_size = size;
> - ssize_t out_size;
> + int ret = 0;
>  
> - if (in_size > TPM_BUFSIZE)
> + if (size > TPM_BUFSIZE)
>   return -E2BIG;
>  
>   mutex_lock(&priv->buffer_mutex);
> @@ -96,21 +125,20 @@ ssize_t tpm_common_write(struct file *file, const char 
> __user *buf,
>* tpm_read or a user_read_timer timeout. This also prevents split
>* buffered writes from blocking 

Re: [PATCH 00/11] MAINTAINERS: update of of some Microchip entries

[Alexandre Belloni]

On 29/08/2018 16:31:36+0200, Nicolas Ferre wrote:
> Hi,
> 
> This is an update of most of Microchip MAINTAINERS' entries. I took advantage
> of the addition of Ludovic as co-maintainer to go through some of the entries
> that were outdated.
> 
> There are moves of entries in the 3 last patches of this series. You can drop
> them if they introduce too much headaches while updating this MAINTAINERS
> file.
> 
> Series based on v4.19-rc1.
> 
> Nicolas Ferre (11):
>   MAINTAINERS: ARM: at91: add co-maintainer for ARM/Microchip
>   MAINTAINERS: update entry for Microchip NAND driver support
>   MAINTAINERS: media: change Microchip ISI, ISC maintainers
>   MAINTAINERS: ASoC: change maintainer for Microchip ALSA drivers
>   MAINTAINERS: USB: change maintainer for Microchip USBA gadget driver
>   MAINTAINERS: dmaengine: add files to Microchip dma entry
>   MAINTAINERS: pwm: add entry for Microchip pwm driver
>   MAINTAINERS: iio: add co-maintainer to SAMA5D2-compatible ADC driver
>   MAINTAINERS: remove the / ATMEL string from MICROCHIP entries
>   MAINTAINERS: move former ATMEL entries to proper MICROCHIP location
>   MAINTAINERS: sdhci: move the Microchip entry to proper location
> 
>  MAINTAINERS | 196 
>  1 file changed, 105 insertions(+), 91 deletions(-)
> 

All applied now.

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

Re: [PATCH 3/3] Enable high-resolution scrolling on Logitech mice

[Nestor Lopez Casado]

On Fri, Aug 31, 2018 at 11:11 AM Nestor Lopez Casado
 wrote:
>
>
>
> On Thu, Aug 30, 2018 at 10:38 PM Harry Cutts  wrote:
>>
>> Hi Benjamin,
>>
>> On Thu, 30 Aug 2018 at 00:18, Benjamin Tissoires
>>  wrote:
>> >> On Thu, Aug 30, 2018 at 1:06 AM Harry Cutts  wrote:
>> > > > The conversion input_report_rel(... REL_WHEEL,...) to
>> > > > hid_scroll_counter_handle_scroll() should be dealt in a separate
>> > > > patch.
>> > >
>> > > OK, I'll do that in v2, but might I ask why? I don't see how this
>> > > particular hunk is special.
>> >
>> > I tend to consider that existing code rewrite need to be in their
>> > special commit, especially if the change isn't supposed to change the
>> > behaviour. This is my personal taste in case something goes wrong and
>> > (in this case) a m560 suddenly starts complaining about an issue with
>> > this mouse.
>> > I wouldn't mind too much if you rather keep the
>> > hid_scroll_counter_handle_scroll() introduction to this commit though.
>>
>> Yes, I see the reasoning for that, but this hunk is pretty tied to the
>> main change in that scrolling on the M560 would be 8x too fast without
>> it. I'll keep it in the same one, if you don't mind.
>>
>> > > [snip]
>> > > Yes, it seems to work fine without it (at least for the MX Master 2S).
>> > > Unfortunately, while testing this I encountered a bug with high-res
>> > > scrolling over Bluetooth. (It seems that if you turn off the MX Master
>> > > 2S while it's connected over Bluetooth, we don't detect that and
>> > > remove the input device, meaning that when it reconnects the driver
>> > > thinks it's in high-res mode but the mouse is in low-res.) I'm
>> > > investigating, but in the meantime I'll remove the Bluetooth support
>> > > from v2 and add it back in later.
>> >
>> > As far as I can see, the MX Master 2S is connected over BLE. Bluez
>> > keeps the uhid node opened (and thus the existing bluetooth HID
>> > device) to be able to reconnect faster.
>> > I would suppose you should get notified in the connect event of a
>> > reconnection, but it doesn't seem to be the case.
>> >
>> > Nestor, is there any event emitted by the mouse when it gets
>> > reconnected over BLE or is that a bluez issue?
>>
>> Ah, interesting. The MX Master 2S is indeed using BLE, and testing
>> with another Logitech BLE mouse (the M585) also leaves the input
>> device around. I think this is something Logitech-specific, though, as
>> the Microsoft Surface Precision mouse (also BLE) does have its input
>> device removed when it turns off. I notice that btmon does show
>> "device disconnected" and "device connected" events when I turn the
>> M585 on and off; maybe we need to plumb those through to the driver.
>> We've decided to delay Bluetooth support for high-res scrolling until
>> the Chrome OS Bluetooth stack is more stable.

-Ooops, no html now...
This might be related to how the device disconnects from the host.
Sometimes a disconnection comes from the device not responding anymore
and it is the BT supervision timeout that kicks in (host side). In
some cases (hw support required on the device side) a device will send
a disconnect request when switched off. Maybe these different
disconnect flavors are the root cause behind the input device being
removed or not.
--nestor
>>
>> Harry Cutts
>> Chrome OS Touch/Input team

Re: [PATCH RFC LKMM 1/7] tools/memory-model: Add extra ordering for locks and remove it for ordinary release/acquire

[Andrea Parri]

On Thu, Aug 30, 2018 at 05:31:32PM -0400, Alan Stern wrote:
> On Thu, 30 Aug 2018, Andrea Parri wrote:
> 
> > > All the architectures supported by the Linux kernel (including RISC-V)
> > > do provide this ordering for locks, albeit for varying reasons.
> > > Therefore this patch changes the model in accordance with the
> > > developers' wishes.
> > > 
> > > Signed-off-by: Alan Stern 
> > > Signed-off-by: Paul E. McKenney 
> > > Reviewed-by: Will Deacon 
> > > Acked-by: Peter Zijlstra (Intel) 
> > 
> > Round 2 ;-), I guess...  Let me start from the uncontroversial points:
> > 
> >   1) being able to use the LKMM to reason about generic locking code
> >  is useful and desirable (paraphrasing Peter in [1]);
> > 
> >   2) strengthening the ordering requirements of such code isn't going
> >  to boost performance (that's "real maths").
> > 
> > This patch is taking (1) away from us and it is formalizing (2), with
> > almost _no_ reason (no reason at all, if we stick to the commit msg.).
> 
> That's not quite fair.  Generic code isn't always universally
> applicable; some of it is opt-in -- meant only for the architectures
> that can support it.  In general, the LKMM allows us to reason about
> higher abstractions (such as locking) at a higher level, without
> necessarily being able to verify the architecture-specific details of
> the implementations.

No, generic code is "universally applicable" by definition; see below
for more on this point.


> 
> > In [2], Will wrote:
> > 
> >   "[...] having them [the RMWs] closer to RCsc[/to the semantics of
> >locks] would make it easier to implement and reason about generic
> >locking implementations (i.e. reduce the number of special ordering
> >cases and/or magic barrier macros)"
> > 
> > "magic barrier macros" as in "mmh, if we accept this patch, we _should_
> > be auditing the various implementations/code to decide where to place a
> > 
> >   smp_barrier_promote_ordinary_release_acquire_to_unlock_lock()" ;-)
> > 
> > or the like, and "special ordering cases" as in "arrgh, (otherwise) we
> > are forced to reason on a per-arch basis while looking at generic code".
> 
> Currently the LKMM does not permit architecture-specific reasoning.  It 
> would have to be extended (in a different way for each architecture) 
> first.

Completely agreed; that's why I said that this patch is detrimental to
the applicability of the LKMM...


> 
> For example, one could use herd's POWER model combined with the POWER 
> compilation scheme and the POWER-specific implementation of spinlocks 
> for such reasoning.  The LKMM alone is not sufficient.
> 
> Sure, programming and reasoning about the kernel would be easier if all
> architectures were the same.  Unfortunately, we (and the kernel) have
> to live in the real world.
> 
> > (Remark: ordinary release/acquire are building blocks for code such as
> >  qspinlock, (q)rwlock, mutex, rwsem, ... and what else??).
> 
> But are these building blocks used the same way for all architectures?

The more, the better! (because then we have the LKMM tools) 

We already discussed the "fast path" example: the fast paths of the
above all resemble:

  *_lock(s):  atomic_cmpxchg_acquire(&s->val, UNLOCKED_VAL, LOCKED_VAL) ...
  *_unlock(s): ...  atomic_set_release(&s->val, UNLOCKED_VAL)

When I read this code, I think "Of course." (unless some arch. has
messed the implementation of cmpxchg_* up, which can happen...); but
then I read the subject line of this patch and I think "Wait, what?".

You can argue that this is not generic code, sure; but why on Earth
would you like to do so?!

  Andrea


> 
> > To avoid further repetition, I conclude by confirming all the concerns
> > and my assessment of this patch as pointed out in [3]; the subsequent
> > discussion, although not conclusive, presented several suggestions for
> > improvement (IMO).
> 
> Alan
> 

Re: [PATCH 3/7] mm/rmap: map_pte() was not handling private ZONE_DEVICE page properly v2

[Balbir Singh]

On Thu, Aug 30, 2018 at 10:41:56AM -0400, jgli...@redhat.com wrote:
> From: Ralph Campbell 
> 
> Private ZONE_DEVICE pages use a special pte entry and thus are not
> present. Properly handle this case in map_pte(), it is already handled
> in check_pte(), the map_pte() part was lost in some rebase most probably.
> 
> Without this patch the slow migration path can not migrate back private
> ZONE_DEVICE memory to regular memory. This was found after stress
> testing migration back to system memory. This ultimatly can lead the
> CPU to an infinite page fault loop on the special swap entry.
> 
> Changes since v1:
> - properly lock pte directory in map_pte()
> 
> Signed-off-by: Ralph Campbell 
> Signed-off-by: Jérôme Glisse 
> Cc: Andrew Morton 
> Cc: Kirill A. Shutemov 
> Cc: Balbir Singh 
> Cc: sta...@vger.kernel.org
> ---
>  mm/page_vma_mapped.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
> index ae3c2a35d61b..bd67e23dce33 100644
> --- a/mm/page_vma_mapped.c
> +++ b/mm/page_vma_mapped.c
> @@ -21,7 +21,14 @@ static bool map_pte(struct page_vma_mapped_walk *pvmw)
>   if (!is_swap_pte(*pvmw->pte))
>   return false;
>   } else {
> - if (!pte_present(*pvmw->pte))
> + if (is_swap_pte(*pvmw->pte)) {
> + swp_entry_t entry;
> +
> + /* Handle un-addressable ZONE_DEVICE memory */
> + entry = pte_to_swp_entry(*pvmw->pte);
> + if (!is_device_private_entry(entry))
> + return false;

OK, so we skip this pte from unmap since it's already unmapped? This prevents
try_to_unmap from unmapping it and it gets restored with MIGRATE_PFN_MIGRATE
flag cleared?

Sounds like the right thing, if I understand it correctly

Acked-by: Balbir Singh 

Balbir Singh.

Re: [PATCH v1] MAINTAINERS: Add myself as designated reviewer of Intel PMIC GPIO

[Linus Walleij]

On Thu, Aug 30, 2018 at 6:49 PM Andy Shevchenko
 wrote:

> There are few Intel PMIC GPIO device drivers which I would like
> to review.
>
> Note, Intel MSIC is old system controller that based mostly on PMIC
> integrated in it. Thus, I included it as well.
>
> Signed-off-by: Andy Shevchenko 

Patch applied.

Yours,
Linus Walleij

Re: [PATCH v2 2/2] clk: tegra20: Enable lock-status polling for PLLs

[Peter De Schrijver]

On Thu, Aug 30, 2018 at 09:42:10PM +0300, Dmitry Osipenko wrote:
> Currently all PLL's on Tegra20 use a hardcoded delay despite of having
> a lock-status bit. The lock-status polling was disabled ~7 years ago
> because PLLE was failing to lock and was a suspicion that other PLLs
> might be faulty too. Other PLLs are okay, hence enable the lock-status
> polling for them. This reduces delay of any operation that require PLL
> to lock.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
> 
> Changelog:
> 
> v2:   Don't enable polling for PLLE as it known to not being able to lock.
> 

This isn't correct. The lock bit of PLLE can declare lock too early, but the
PLL itself does lock.

>  drivers/clk/tegra/clk-tegra20.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
> index cc857d4d4a86..cfde3745a0db 100644
> --- a/drivers/clk/tegra/clk-tegra20.c
> +++ b/drivers/clk/tegra/clk-tegra20.c
> @@ -298,7 +298,8 @@ static struct tegra_clk_pll_params pll_c_params = {
>   .lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
>   .lock_delay = 300,
>   .freq_table = pll_c_freq_table,
> - .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
> + .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
> +  TEGRA_PLL_USE_LOCK,
>  };
>  
>  static struct tegra_clk_pll_params pll_m_params = {
> @@ -314,7 +315,8 @@ static struct tegra_clk_pll_params pll_m_params = {
>   .lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
>   .lock_delay = 300,
>   .freq_table = pll_m_freq_table,
> - .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
> + .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
> +  TEGRA_PLL_USE_LOCK,
>  };
>  
>  static struct tegra_clk_pll_params pll_p_params = {
> @@ -331,7 +333,7 @@ static struct tegra_clk_pll_params pll_p_params = {
>   .lock_delay = 300,
>   .freq_table = pll_p_freq_table,
>   .flags = TEGRA_PLL_FIXED | TEGRA_PLL_HAS_CPCON |
> -  TEGRA_PLL_HAS_LOCK_ENABLE,
> +  TEGRA_PLL_HAS_LOCK_ENABLE | TEGRA_PLL_USE_LOCK,
>   .fixed_rate =  21600,
>  };
>  
> @@ -348,7 +350,8 @@ static struct tegra_clk_pll_params pll_a_params = {
>   .lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
>   .lock_delay = 300,
>   .freq_table = pll_a_freq_table,
> - .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
> + .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
> +  TEGRA_PLL_USE_LOCK,
>  };
>  
>  static struct tegra_clk_pll_params pll_d_params = {
> @@ -364,7 +367,8 @@ static struct tegra_clk_pll_params pll_d_params = {
>   .lock_enable_bit_idx = PLLDU_MISC_LOCK_ENABLE,
>   .lock_delay = 1000,
>   .freq_table = pll_d_freq_table,
> - .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
> + .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
> +  TEGRA_PLL_USE_LOCK,
>  };
>  
>  static const struct pdiv_map pllu_p[] = {
> @@ -387,7 +391,8 @@ static struct tegra_clk_pll_params pll_u_params = {
>   .lock_delay = 1000,
>   .pdiv_tohw = pllu_p,
>   .freq_table = pll_u_freq_table,
> - .flags = TEGRA_PLLU | TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
> + .flags = TEGRA_PLLU | TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
> +  TEGRA_PLL_USE_LOCK,
>  };
>  
>  static struct tegra_clk_pll_params pll_x_params = {
> @@ -403,7 +408,8 @@ static struct tegra_clk_pll_params pll_x_params = {
>   .lock_enable_bit_idx = PLL_MISC_LOCK_ENABLE,
>   .lock_delay = 300,
>   .freq_table = pll_x_freq_table,
> - .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE,
> + .flags = TEGRA_PLL_HAS_CPCON | TEGRA_PLL_HAS_LOCK_ENABLE |
> +  TEGRA_PLL_USE_LOCK,
>  };
>  
>  static struct tegra_clk_pll_params pll_e_params = {
> -- 
> 2.18.0
> 

Re: [PATCH 19/23] pinctrl: remove unnecessary unlikely()

[Linus Walleij]

On Fri, Aug 31, 2018 at 12:35 AM Igor Stoppa  wrote:

> WARN_ON() already contains an unlikely(), so it's not necessary to
> wrap it into another.
>
> Signed-off-by: Igor Stoppa 
> Cc: Andrew Jeffery 
> Cc: Linus Walleij 

Patch applied as obviously correct.

Yours,
Linus Walleij

Re: [PATCH] clk: ti: fix OF child-node lookup

[Johan Hovold]

On Thu, Aug 30, 2018 at 10:28:28AM +0300, Tero Kristo wrote:
> On 29/08/18 10:50, Johan Hovold wrote:
> > On Tue, Aug 28, 2018 at 03:32:03PM -0700, Stephen Boyd wrote:
> >> Quoting Johan Hovold (2018-08-22 02:03:19)
> >>> Fix child-node lookup which by using the wrong OF helper was searching
> >>> the whole tree depth-first, something which could end up matching an
> >>> unrelated node.
> >>>
> >>> Also fix the related node-reference leaks.
> >>>
> >>> Fixes: 5b385a45e001 ("clk: ti: add support for clkctrl aliases")
> >>
> >> Found by inspection? Or it's actively causing problems? I'm thinking
> >> it's the former so this can bake in clk-next for a while.
> > 
> > Right, through inspection. I fixed up most of these last year, but this
> > one managed to sneak in since then.
> > 
> > clk-next should be fine.
> 
> The patch looks fine to me also, just had to test this out with my 
> latest development branch as it conflicts with that one a bit.
> 
> Acked-by: Tero Kristo 

Thanks for reviewing.

Johan

[PATCH] Partially revert "HID: generic: create one input report per application type"

[Benjamin Tissoires]

This partially reverts commit f07b3c1da92db108662f99417a212fc1eddc44d1.

It looks like some mice are not correctly treated by
HID_QUIRK_INPUT_PER_APP. Those mice have the following
report descriptor:

0x05, 0x01,// Usage Page (Generic Desktop)0
0x09, 0x02,// Usage (Mouse)   2
0xa1, 0x01,// Collection (Application)4
0x85, 0x01,//  Report ID (1)  6
0x09, 0x01,//  Usage (Pointer)8
0xa1, 0x00,//  Collection (Physical)  10
0x95, 0x05,//   Report Count (5)  12
0x75, 0x01,//   Report Size (1)   14
0x05, 0x09,//   Usage Page (Button)   16
0x19, 0x01,//   Usage Minimum (1) 18
0x29, 0x05,//   Usage Maximum (5) 20
0x15, 0x00,//   Logical Minimum (0)   22
0x25, 0x01,//   Logical Maximum (1)   24
0x81, 0x02,//   Input (Data,Var,Abs)  26
...
0xc0,  //  End Collection 57
0x85, 0x02,//  Report ID (2)  58
0x09, 0x01,//  Usage (Consumer Control)   60
0xa1, 0x00,//  Collection (Physical)  62
0x75, 0x0c,//   Report Size (12)  64
0x95, 0x02,//   Report Count (2)  66
0x05, 0x01,//   Usage Page (Generic Desktop)  68
0x09, 0x30,//   Usage (X) 70
0x09, 0x31,//   Usage (Y) 72
0x16, 0x01, 0xf8,  //   Logical Minimum (-2047)   74
0x26, 0xff, 0x07,  //   Logical Maximum (2047)77
0x81, 0x06,//   Input (Data,Var,Rel)  80
0xc0,  //  End Collection 82
0xc0,  // End Collection  83
...

Both the cursor position and the buttons are located in the
same application collection (Mouse) and the kernel should
only create one input device for those.

However, for an undetermined reason, the kernel splits the
device in 2, making systemd not tagging the second mouse
with the coordinates only as a mouse. And then userspace
ignores it which leads to a mouse where only the buttons
are working.

Until the quirk gets properly fixed, we should probably
revert applying it to all of the generic devices and
re-enable it when the root reason has been found.

link: https://bugzilla.kernel.org/show_bug.cgi?id=200847
link: https://bugzilla.kernel.org/show_bug.cgi?id=200849
link: https://bugs.archlinux.org/task/59699
link: https://github.com/NixOS/nixpkgs/issues/45165

Cc: sta...@vger.kernel.org # v4.18+
Signed-off-by: Benjamin Tissoires 
---
 drivers/hid/hid-generic.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/hid/hid-generic.c b/drivers/hid/hid-generic.c
index 3b6eccbc2519..c25b4718de44 100644
--- a/drivers/hid/hid-generic.c
+++ b/drivers/hid/hid-generic.c
@@ -56,20 +56,6 @@ static bool hid_generic_match(struct hid_device *hdev,
return true;
 }
 
-static int hid_generic_probe(struct hid_device *hdev,
-const struct hid_device_id *id)
-{
-   int ret;
-
-   hdev->quirks |= HID_QUIRK_INPUT_PER_APP;
-
-   ret = hid_parse(hdev);
-   if (ret)
-   return ret;
-
-   return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
-}
-
 static const struct hid_device_id hid_table[] = {
{ HID_DEVICE(HID_BUS_ANY, HID_GROUP_ANY, HID_ANY_ID, HID_ANY_ID) },
{ }
@@ -80,7 +66,6 @@ static struct hid_driver hid_generic = {
.name = "hid-generic",
.id_table = hid_table,
.match = hid_generic_match,
-   .probe = hid_generic_probe,
 };
 module_hid_driver(hid_generic);
 
-- 
2.14.3

[PATCH] kconfig: do not require pkg-config on make {menu,n}config

[Masahiro Yamada]

Meelis Roos reported a {menu,n}config regression:

 "I have libncurses devel package installed in the default system
  location (as do 99%+ on actual developers probably) and in this
  case, pkg-config is useless.  pkg-config is needed only when
  libraries and headers are installed in non-default locations but
  it is bad to require installation of pkg-config on all the machines
  where make menuconfig would be possibly run."

For {menu,n}config, do not use pkg-config if it is not installed.
For {g,x}config, keep checking pkg-config since we really rely on it
for finding the installation paths of the required packages.

Fixes: 4ab3b80159d4 ("kconfig: check for pkg-config on make {menu,n,g,x}config")
Reported-by: Meelis Roos 
Signed-off-by: Masahiro Yamada 
---

 Documentation/process/changes.rst  |  2 +-
 scripts/kconfig/Makefile   |  1 -
 scripts/kconfig/check-pkgconfig.sh |  8 
 scripts/kconfig/gconf-cfg.sh   |  7 +++
 scripts/kconfig/mconf-cfg.sh   | 25 ++---
 scripts/kconfig/nconf-cfg.sh   | 25 ++---
 scripts/kconfig/qconf-cfg.sh   |  7 +++
 7 files changed, 43 insertions(+), 32 deletions(-)
 delete mode 100644 scripts/kconfig/check-pkgconfig.sh

diff --git a/Documentation/process/changes.rst 
b/Documentation/process/changes.rst
index 61f918b..d1bf143 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -86,7 +86,7 @@ pkg-config
 
 The build system, as of 4.18, requires pkg-config to check for installed
 kconfig tools and to determine flags settings for use in
-'make {menu,n,g,x}config'.  Previously pkg-config was being used but not
+'make {g,x}config'.  Previously pkg-config was being used but not
 verified or documented.
 
 Flex
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 4a7bd21..67ed9f6 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -221,7 +221,6 @@ $(obj)/zconf.tab.o: $(obj)/zconf.lex.c
 
 # check if necessary packages are available, and configure build flags
 define filechk_conf_cfg
-   $(CONFIG_SHELL) $(srctree)/scripts/kconfig/check-pkgconfig.sh; \
$(CONFIG_SHELL) $<
 endef
 
diff --git a/scripts/kconfig/check-pkgconfig.sh 
b/scripts/kconfig/check-pkgconfig.sh
deleted file mode 100644
index 7a1c40b..000
--- a/scripts/kconfig/check-pkgconfig.sh
+++ /dev/null
@@ -1,8 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0
-# Check for pkg-config presence
-
-if [ -z $(command -v pkg-config) ]; then
-   echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
-   exit 1
-fi
diff --git a/scripts/kconfig/gconf-cfg.sh b/scripts/kconfig/gconf-cfg.sh
index 533b3d8..480ecd8 100755
--- a/scripts/kconfig/gconf-cfg.sh
+++ b/scripts/kconfig/gconf-cfg.sh
@@ -3,6 +3,13 @@
 
 PKG="gtk+-2.0 gmodule-2.0 libglade-2.0"
 
+if [ -z "$(command -v pkg-config)" ]; then
+   echo >&2 "*"
+   echo >&2 "* 'make gconfig' requires 'pkg-config'. Please install it."
+   echo >&2 "*"
+   exit 1
+fi
+
 if ! pkg-config --exists $PKG; then
echo >&2 "*"
echo >&2 "* Unable to find the GTK+ installation. Please make sure that"
diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
index e6f9fac..c812872d 100755
--- a/scripts/kconfig/mconf-cfg.sh
+++ b/scripts/kconfig/mconf-cfg.sh
@@ -4,20 +4,23 @@
 PKG="ncursesw"
 PKG2="ncurses"
 
-if pkg-config --exists $PKG; then
-   echo cflags=\"$(pkg-config --cflags $PKG)\"
-   echo libs=\"$(pkg-config --libs $PKG)\"
-   exit 0
-fi
+if [ -n "$(command -v pkg-config)" ]; then
+   if pkg-config --exists $PKG; then
+   echo cflags=\"$(pkg-config --cflags $PKG)\"
+   echo libs=\"$(pkg-config --libs $PKG)\"
+   exit 0
+   fi
 
-if pkg-config --exists $PKG2; then
-   echo cflags=\"$(pkg-config --cflags $PKG2)\"
-   echo libs=\"$(pkg-config --libs $PKG2)\"
-   exit 0
+   if pkg-config --exists $PKG2; then
+   echo cflags=\"$(pkg-config --cflags $PKG2)\"
+   echo libs=\"$(pkg-config --libs $PKG2)\"
+   exit 0
+   fi
 fi
 
-# Unfortunately, some distributions (e.g. openSUSE) cannot find ncurses
-# by pkg-config.
+# Check the default paths in case pkg-config is not installed.
+# (Even if it is installed, some distributions such as openSUSE cannot
+# find ncurses by pkg-config.)
 if [ -f /usr/include/ncursesw/ncurses.h ]; then
echo cflags=\"-D_GNU_SOURCE -I/usr/include/ncursesw\"
echo libs=\"-lncursesw\"
diff --git a/scripts/kconfig/nconf-cfg.sh b/scripts/kconfig/nconf-cfg.sh
index 42f5ac7..001559e 100644
--- a/scripts/kconfig/nconf-cfg.sh
+++ b/scripts/kconfig/nconf-cfg.sh
@@ -4,20 +4,23 @@
 PKG="ncursesw menuw panelw"
 PKG2="ncurses menu panel"
 
-if pkg-config --exists $PKG; then
-   echo cflags=\"$(pkg-config --cflags $PKG)\"
-   echo libs=\"$(pkg-config --libs $PKG)\"
-   exit 0
-fi
+if [ -n "$(command -v pkg-confi

Re: make *config regression: pkg-build

[Masahiro Yamada]

Hi.

2018-08-20 0:37 GMT+09:00 Randy Dunlap :
> On 08/19/2018 04:15 AM, Meelis Roos wrote:
>> Just tried to run 'make menuconfig' on v4.18-10568-g08b5fa819970 and
>> found a bad surprise:
>>
>> 'make *config' requires 'pkg-config'. Please install it.
>> make[1]: *** [scripts/kconfig/Makefile:219: scripts/kconfig/.mconf-cfg] 
>> Error 1
>>
>> This is clearly a regression - I have libncurses devele pakcage
>> installed in the default system location (as do 99%+ on actuall
>> develeopers proobably) and in this case, pkg-config is useless.
>> pkg-config is needed only when libraries and headers are installed in
>> non-default locations but it is bad to require installation of
>> pkg-config on all the machines where make menuconfig would be possibly
>> run (for example, I have a aboult 100 machine kernel testbed with
>> self-hosted kernel compilation and machine-specific kernel
>> configurations that ocassionally need tweaking).
>>
>> I notice 4.18 complained it can not find pkg-config but still worked.
>> This is clearly better than now.
>>
>> If we want to support developers with libraries in non-default
>> locations, why not - but the common case of system include path should
>> work without any trouble or warnings. For exaple, test if compilation
>> against ncurses works, and if not retry it with pkg-config (and error
>> out if it does not give working result).
>>
>
> Hi,
> This is due to my patch: 4ab3b80159d4db63b902ef635d4b5e882911b2da.
>
> Yamada-san, any ideas?  Feel free to just revert it.
>

Sorry for delay, I chose a partial revert
because I want to keep checking pkg-config for {g,x}config.

I posted a patch.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH RFC LKMM 3/7] EXP tools/memory-model: Add more LKMM limitations

[Andrea Parri]

> > > + b.  The "unless" RMW operations are not currently modeled:
> > > + atomic_long_add_unless(), atomic_add_unless(),
> > > + atomic_inc_unless_negative(), and
> > > + atomic_dec_unless_positive().  These can be emulated
> > > + in litmus tests, for example, by using atomic_cmpxchg().
> > 
> > There is a prototype atomic_add_unless(): with current herd7,
> > 
> > $ cat atomic_add_unless.litmus
> > C atomic_add_unless
> > 
> > {}
> > 
> > P0(atomic_t *u, atomic_t *v)
> > {
> > int r0;
> > int r1;
> > 
> > r0 = atomic_add_unless(u, 1, 2);
> > r1 = atomic_read(v);
> > }
> > 
> > P1(atomic_t *u, atomic_t *v)
> > {
> > int r0;
> > int r1;
> > 
> > r0 = atomic_add_unless(v, 1, 2);
> > r1 = atomic_read(u);
> > }
> > 
> > exists (0:r1=0 /\ 1:r1=0)
> > 
> > $ herd7 -conf linux-kernel.cfg atomic_add_unless.litmus
> > Test atomic_add_unless Allowed
> > States 3
> > 0:r1=0; 1:r1=1;
> > 0:r1=1; 1:r1=0;
> > 0:r1=1; 1:r1=1;
> > No
> > Witnesses
> > Positive: 0 Negative: 3
> > Condition exists (0:r1=0 /\ 1:r1=0)
> > Observation atomic_add_unless Never 0 3
> > Time atomic_add_unless 0.00
> > Hash=fa37a2359831690299e4cc394e45d966
> > 
> > The last commit in the herdtools7 repo. related to this implementation
> > (AFAICT) is:
> > 
> >   9523c340917b6a ("herd/linux: make atomic_add_unless a primitive, so as to 
> > yield more precise dependencies for the returned boolean.")
> > 
> > but I can only vaguely remember those dependencies issues now :/  ...;
> > maybe we can now solve these issues?  or should we change herd7 to re-
> > turn a warning?  (Notice that this primitive is currently not exported
> > to the linux-kernel.def file.)
> 
> Cool!  It would be good to add this to the .def file once the underlying
> herd7 machinery is ready.  And then I would update the documentation
> accordingly.  Or happily accept a patch updating the documentation,
> as the case might be.  ;-)

Fair enough, ;-)  Please feel free to add:

Reviewed-by: Andrea Parri 

  Andrea

Re: [PATCH] remoteproc: qcom: Rename Hexagon v5 PAS driver

[Niklas Cassel]

On Thu, Aug 30, 2018 at 08:10:53PM -0700, Bjorn Andersson wrote:
> On Wed 29 Aug 02:25 PDT 2018, Niklas Cassel wrote:
> 
> > On Mon, Aug 27, 2018 at 10:12:03PM -0700, Bjorn Andersson wrote:
> > > The Hexagon v5 ADSP driver is used for more than only the ADSP and
> > > there's an upcoming non-PAS ADSP PIL for SDM845, so rename the driver to
> > > qcom_q6v5_pas in order to better suite this.
> > 
> > Hello Bjorn,
> > 
> > so I'm a bit new to this, but after your rename we will have:
> > 
> > QCOM_Q6V5_PIL
> > and
> > QCOM_Q6V5_PAS
> > 
> > that both are PILs.
> > I guess that the difference is that the latter uses TrustZone?
> > 
> > The ADSP for some QCOM SoCs is a Hexagon v5, therefore the
> > QCOM_Q6V5_PAS can also boot certain ADSPs?
> > 
> > But we also have QCOM_Q6V5_WCSS
> > "Qualcomm Hexagon based WCSS Peripheral Image Loader",
> > which also appears to be Hexagon v5 based, but I assume that
> > neither QCOM_Q6V5_PIL nor QCOM_Q6V5_PAS can boot the WCSS?
> > 
> > There is also an upcoming non-PAS ADSP PIL loader for SDM845,
> > but I guess that the ADSP there is not based on Hexagon v5,
> > so the QCOM_Q6V5_PIL will not be able to boot it?
> > 
> > This all seems to be quite confusing, perhaps the help texts
> > could be improved to mitigate this confusion?
> > 
> 
> You're right, as proposed this is confusing.
> 
> The plan is to have QCOM_Q6V5_PAS, which deals with standard Hexagon
> peripherals that relies on the PAS service in TrustZone and then rename
> QCOM_Q6V5_PIL to QCOM_Q6V5_MSA to denote that this is the remoteproc
> driver for the self-authenticating modem.

Ok. It might be a good idea to send both driver renames in a single
patch series, so that it is easier to verify that the renaming is
consistent.

> 
> The QCOM_Q6V5_WCSS then fits into this pattern, of being the non-TZ
> based WCSS remoteproc driver.
> 
> > > 
> > > Cc: Rohit kumar 
> > > Signed-off-by: Bjorn Andersson 
> > > ---
> > >  drivers/remoteproc/Kconfig| 22 +--
> > >  drivers/remoteproc/Makefile   |  2 +-
> > >  .../{qcom_adsp_pil.c => qcom_q6v5_pas.c}  |  4 ++--
> > 
> > You should probably also edit the qcom_defconfig:
> > arch/arm/configs/qcom_defconfig:CONFIG_QCOM_ADSP_PIL=y
> > 
> 
> Yes, this needs to be done as well. But needs to be done in a separate
> patch.

Doing it in the same patch would ensure that we don't break bisectability.



Kind regards,
Niklas

> 
> > >  3 files changed, 14 insertions(+), 14 deletions(-)
> > >  rename drivers/remoteproc/{qcom_adsp_pil.c => qcom_q6v5_pas.c} (98%)
> > > 
> > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > > index 052d4dd347f9..c98c0b2a2237 100644
> > > --- a/drivers/remoteproc/Kconfig
> > > +++ b/drivers/remoteproc/Kconfig
> > > @@ -84,8 +84,16 @@ config KEYSTONE_REMOTEPROC
> > > It's safe to say N here if you're not interested in the Keystone
> > > DSPs or just want to use a bare minimum kernel.
> > >  
> > > -config QCOM_ADSP_PIL
> > > - tristate "Qualcomm ADSP Peripheral Image Loader"
> > > +config QCOM_RPROC_COMMON
> > > + tristate
> > > +
> > > +config QCOM_Q6V5_COMMON
> > > + tristate
> > > + depends on ARCH_QCOM
> > > + depends on QCOM_SMEM
> > > +
> > > +config QCOM_Q6V5_PAS
> > > + tristate "Qualcomm Hexagon v5 Peripheral Authentication Service support"
> > >   depends on OF && ARCH_QCOM
> > >   depends on QCOM_SMEM
> > >   depends on RPMSG_QCOM_SMD || (COMPILE_TEST && RPMSG_QCOM_SMD=n)
> > > @@ -98,15 +106,7 @@ config QCOM_ADSP_PIL
> > >   select QCOM_SCM
> > >   help
> > > Say y here to support the TrustZone based Peripherial Image Loader
> > 
> > Since you are editing this help text, yoy may just as well 
> > s/Peripherial/Peripheral.
> > 
> 
> Thanks, will do.
> 
> Regards,
> Bjorn
> 
> > Kind regards,
> > Niklas
> > 
> > > -   for the Qualcomm ADSP remote processors.
> > > -
> > > -config QCOM_RPROC_COMMON
> > > - tristate
> > > -
> > > -config QCOM_Q6V5_COMMON
> > > - tristate
> > > - depends on ARCH_QCOM
> > > - depends on QCOM_SMEM
> > > +   for the Qualcomm Hexagon v5 based remote processors.
> > >  
> > >  config QCOM_Q6V5_PIL
> > >   tristate "Qualcomm Hexagon V5 Peripherial Image Loader"
> > > diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> > > index 03332fa7e2ee..eb86c8ba5a87 100644
> > > --- a/drivers/remoteproc/Makefile
> > > +++ b/drivers/remoteproc/Makefile
> > > @@ -14,9 +14,9 @@ obj-$(CONFIG_OMAP_REMOTEPROC)   += 
> > > omap_remoteproc.o
> > >  obj-$(CONFIG_WKUP_M3_RPROC)  += wkup_m3_rproc.o
> > >  obj-$(CONFIG_DA8XX_REMOTEPROC)   += da8xx_remoteproc.o
> > >  obj-$(CONFIG_KEYSTONE_REMOTEPROC)+= keystone_remoteproc.o
> > > -obj-$(CONFIG_QCOM_ADSP_PIL)  += qcom_adsp_pil.o
> > >  obj-$(CONFIG_QCOM_RPROC_COMMON)  += qcom_common.o
> > >  obj-$(CONFIG_QCOM_Q6V5_COMMON)   += qcom_q6v5.o
> > > +obj-$(CONFIG_QCOM_Q6V5_PAS)  += qcom_q6v5_pas.o
> > >  obj-$(CONFI

Re: [PATCH v2 2/2] clk: tegra20: Enable lock-status polling for PLLs

[Dmitry Osipenko]

On 8/31/18 12:29 PM, Peter De Schrijver wrote:
> On Thu, Aug 30, 2018 at 09:42:10PM +0300, Dmitry Osipenko wrote:
>> Currently all PLL's on Tegra20 use a hardcoded delay despite of having
>> a lock-status bit. The lock-status polling was disabled ~7 years ago
>> because PLLE was failing to lock and was a suspicion that other PLLs
>> might be faulty too. Other PLLs are okay, hence enable the lock-status
>> polling for them. This reduces delay of any operation that require PLL
>> to lock.
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>
>> Changelog:
>>
>> v2:  Don't enable polling for PLLE as it known to not being able to lock.
>>
> 
> This isn't correct. The lock bit of PLLE can declare lock too early, but the
> PLL itself does lock.

Indeed, it locks but can't be polled for the lock-status as it doesn't have the
lock-status bit.

Do you want me to adjust the commit description or it is fine as is?

It is also a bit odd that PLLE has "lock_delay = 0", is it correct?

Re: [PATCH v3] ARM: dts: pxa: add mioa701 board description

[Marcel Ziswiler]

Hi Robert

On Thu, 2018-08-30 at 21:59 +0200, Robert Jarzmik wrote:
> Add device-tree description of the Mitac MIO A701 board.
> This is aimed at replacing mioa701.c board file, and once stabilized,
> the leftover, such as the suspend resume mechanics will rely on a new
> IPL, and not the legacy Windows CE one.

Cool, I did work on a Colibri PXA270 device tree off and on just never
came around submitting it. Yours is now definitely a good start!

Signed-off-by: Robert Jarzmik 
> ---
> Since v1: fix lcd_supply and lcd_backlight
>   These were depending on my internal tree changes, fit it.
> Since v2: take into account Rob's comments
> 
> This patch deserves some special "love review". As it will probably
> serve for a more broad pxa conversion to devicetree of the other
> boards,
> and because it touches almost all domains for a pxa platform (camera,
> video, audio, i2c, ...), it should be as clean as possible so that
> mistakes are not carried on ...
> 
> Therefore I expect the review of this one to be long (ie. it won't
> land
> for v4.19), until it looks good enough.
> ---
>  arch/arm/boot/dts/Makefile|   2 +
>  arch/arm/boot/dts/mioa701.dts | 558 

Isn't that one supposed to be prefixed by pxa270-?

> ++
>  2 files changed, 560 insertions(+)
>  create mode 100644 arch/arm/boot/dts/mioa701.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b5bd3de87c33..8809f4e2244d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -775,6 +775,8 @@ dtb-$(CONFIG_ARCH_PRIMA2) += \
>  dtb-$(CONFIG_ARCH_OXNAS) += \
>   ox810se-wd-mbwe.dtb \
>   ox820-cloudengines-pogoplug-series-3.dtb
> +dtb-$(CONFIG_ARCH_PXA) += \

Wouldn't it rather make more sense to use CONFIG_MACH_PXA27X_DT
instead?

> + mioa701.dtb
>  dtb-$(CONFIG_ARCH_QCOM) += \
>   qcom-apq8060-dragonboard.dtb \
>   qcom-apq8064-arrow-sd-600eval.dtb \
> diff --git a/arch/arm/boot/dts/mioa701.dts
> b/arch/arm/boot/dts/mioa701.dts
> new file mode 100644
> index ..3791bc69e155
> --- /dev/null
> +++ b/arch/arm/boot/dts/mioa701.dts
> @@ -0,0 +1,558 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + *  Copyright (C) 2018 Robert Jarzmik 
> + *
> + *  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
> + *  publishhed by the Free Software Foundation.
> + */
> +
> +/dts-v1/;
> +#include "pxa27x.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + model = "Mitac Mio A701 Board";
> + compatible = "marvell,pxa270";

Usually, there is also a compatible for the particular board e.g.
"mitac,mioa701", not? You might have to check on the vendor prefix
though.

> + chosen {
> + bootargs = "mtdparts=docg3.0:256k@3456k(barebox)ro,2
> 56k(barebox-logo),128k(barebox-env),4M(kernel),-(root) ubi.mtd=4
> rootfstype=ubifs root=ubi0:linux_root ro";
> + };
> +
> + memory {
> + reg = <0xa000 0x0400>;
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + pstore_region:region@a200 {
> + compatible = "linux,contiguous-
> memory-region";
> + reg = <0xa200 0x10>;
> + };
> + };
> + };
> +
> + cpus {
> + cpu {
> + cpu-supply = <&vcc_core>;
> + };
> + };
> +
> + pxabus {
> + pinctrl: pinctrl@40e0 {
> + status = "okay";
> + pinctrl_ac97_default: ac97-default {
> + PMMUX(hpjack-detect, 12, gpio_in);
> + PMMUX(ac97-bitclk, 28, AC97_BITCLK);
> + PMMUX(ac97-sdata-in-0, 29,
> AC97_SDATA_IN_0);
> + PMMUX(ac97-sdata-out, 30,
> AC97_SDATA_OUT);
> + PMMUX(ac97-sync, 31, AC97_SYNC);
> + PMMUX(ac97-sysclk, 89, AC97_SYSCLK);
> + };
> + pinctrl_btuart_default: btuart-default {
> + PMMUX(btuart-nactivity, 14,
> gpio_in);
> + PMMUX(btuart-rxd, 42, BTRXD);
> + PMMUX(btuart-txd, 43, BTTXD);
> + PMMUX(btuart-cts, 44, BTCTS);
> + PMMUX(btuart-rts, 45, BTRTS);
> + PMMUX_LPM_LOW(bt-on, 83, gpio_out);
> + PMMUX_LPM_HIGH(bt-unknown, 77,
> gpio_out);
> + PMMUX_LPM_HIGH(bt-nreset, 86,
> gpio_out);
> + };
> + pinctrl_ffuart_default: ffuart-default {
> + PMMUX(ffuart-rxd, 34, FFRXD);
> + PMMUX(ffuart-cts, 35, FFCT

Re: [PATCH v3] ARM: dts: pxa: add mioa701 board description

[Marcel Ziswiler]

On Fri, 2018-08-31 at 15:45 +0800, kbuild test robot wrote:
> Hi Robert,
> 
> I love your patch! Yet something to improve:
> 
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.19-rc1 next-20180831]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
> 
> url:https://github.com/0day-ci/linux/commits/Robert-Jarzmik/ARM-d
> ts-pxa-add-mioa701-board-description/20180831-134244
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.gi
> t for-next
> config: arm-keystone_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master
> /sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=arm 
> 
> All errors (new ones prefixed by >>):
> 
> > > Error: arch/arm/boot/dts/mioa701.dts:47.10-11 syntax error
> 
>FATAL ERROR: Unable to parse input tree

I guess it just missed the dependency on the following:

https://lore.kernel.org/lkml/20180830195912.6025-1-robert.jarzmik@free.
fr/

> ---
> 0-DAY kernel test infrastructureOpen Source
> Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel
> Corporation

Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

[Will Deacon]

On Thu, Aug 30, 2018 at 06:04:12PM -0700, Linus Torvalds wrote:
> On Thu, Aug 30, 2018 at 6:01 PM Nicholas Piggin  wrote:
> >
> > Well it would help if powerpc say wanted to start using them without a
> > merge cycle lag. Not a huge issue because powerpc already does
> > reasonably well here and there's other work that can be done.
> 
> Sure. If somebody wants to send the generic changes I can just take
> them directly to make it easier for people to work on this.

Tell you what: how about I stick the following patches (with Nick's and
Peter's acks) on a separate, stable branch:

  asm-generic/tlb: Track which levels of the page tables have been cleared
  asm-generic/tlb: Track freeing of page-table directories in struct mmu_gather
  asm-generic/tlb: Guard with #ifdef CONFIG_MMU

and then anybody who needs them can just pull that in for the merge window?

Also, how would people feel about adding a MAINTAINERS entry for all the
tlb.h files? A big part of the recent "fun" was us figuring out what the
code is actually doing ("It used to do foo() but that may have changed").
and it certainly took me the best part of a day to figure things out again.
If we're trying to do more in the generic code and less in the arch code,
it would help if we're on top of the changes in this area.

Proposal below (omitted Linus because that seems to be the pattern elsewhere
in the file and he's not going to shout at himself when things break :)
Anybody I've missed?

Will

--->8

diff --git a/MAINTAINERS b/MAINTAINERS
index a5b256b25905..7224b5618883 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9681,6 +9681,15 @@ S:   Maintained
 F: arch/arm/boot/dts/mmp*
 F: arch/arm/mach-mmp/
 
+MMU GATHER AND TLB INVALIDATION
+M: Will Deacon 
+M: Nick Piggin 
+M: Peter Zijlstra 
+L: linux-a...@vger.kernel.org
+S: Maintained
+F: include/asm-generic/tlb.h
+F: arch/*/include/asm/tlb.h
+
 MN88472 MEDIA DRIVER
 M: Antti Palosaari 
 L: linux-me...@vger.kernel.org

Re: [Question] When should a driver issue STOP condition?

[Wolfram Sang]

> The problem is, my driver is forcibly setting
> STOP condition unless the next message is read.

This likely is a problem.

In Linux I2C terminology, a transfer is everything between a START and a
STOP. A transfer may consist of multiple messages, connected with
REP_START [1].

So, a STOP should be generated after the last message of a transfer or
of I2C_M_STOP is set in a message. The latter should be super-rare
because mostly you should be able to use multiple transfers with a
regular STOP instead.

[1] Slide 8 illustrates this:
http://events17.linuxfoundation.org/sites/events/files/slides/ELCE17-WSang-I2C-Fault-Injector.pdf


signature.asc
Description: PGP signature

[PATCH] HID: i2c-hid: enforce I2C_HID_QUIRK_RESEND_REPORT_DESCR

[Benjamin Tissoires]

The spec states that the HID devices should allow
the host to query the HID descriptor at any time.

Some devices require the HID descriptor to be set
on resume, or they will fail.

Instead of having a growing list of blacklisted devices
make the call part of the general resume process
so we can remove this list.

Tested on a Dell XPS 9360 and a Surface 3.

link: https://bugzilla.redhat.com/show_bug.cgi?id=1622695

Signed-off-by: Benjamin Tissoires 
---
 drivers/hid/i2c-hid/i2c-hid.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 57126f6837bb..17ec57c62a0b 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -47,7 +47,7 @@
 /* quirks to control the device */
 #define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV   BIT(0)
 #define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET   BIT(1)
-#define I2C_HID_QUIRK_RESEND_REPORT_DESCR  BIT(2)
+/* reserved: I2C_HID_QUIRK_RESEND_REPORT_DESCR BIT(2) */
 
 /* flags */
 #define I2C_HID_STARTED0
@@ -170,12 +170,6 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
{ I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288,
I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
-   { I2C_VENDOR_ID_RAYD, I2C_PRODUCT_ID_RAYD_3118,
-   I2C_HID_QUIRK_RESEND_REPORT_DESCR },
-   { USB_VENDOR_ID_SIS_TOUCH, USB_DEVICE_ID_SIS10FB_TOUCH,
-   I2C_HID_QUIRK_RESEND_REPORT_DESCR },
-   { I2C_VENDOR_ID_RAYD, I2C_PRODUCT_ID_RAYD_4B33,
-   I2C_HID_QUIRK_RESEND_REPORT_DESCR },
{ 0, 0 }
 };
 
@@ -1245,11 +1239,9 @@ static int i2c_hid_resume(struct device *dev)
 * after resume, after this it will be back normal.
 * otherwise it issues too many incomplete reports.
 */
-   if (ihid->quirks & I2C_HID_QUIRK_RESEND_REPORT_DESCR) {
-   ret = i2c_hid_command(client, &hid_report_descr_cmd, NULL, 0);
-   if (ret)
-   return ret;
-   }
+   ret = i2c_hid_command(client, &hid_report_descr_cmd, NULL, 0);
+   if (ret)
+   return ret;
 
if (hid->driver && hid->driver->reset_resume) {
ret = hid->driver->reset_resume(hid);
-- 
2.14.3

Re: [PATCH] HID: i2c-hid: enforce I2C_HID_QUIRK_RESEND_REPORT_DESCR

[Hans de Goede]

Hi,

On 31-08-18 11:54, Benjamin Tissoires wrote:

The spec states that the HID devices should allow
the host to query the HID descriptor at any time.

Some devices require the HID descriptor to be set
on resume, or they will fail.

Instead of having a growing list of blacklisted devices
make the call part of the general resume process
so we can remove this list.

Tested on a Dell XPS 9360 and a Surface 3.

link: https://bugzilla.redhat.com/show_bug.cgi?id=1622695

Signed-off-by: Benjamin Tissoires 


I agree we should just do this everywhere:

Acked-by: Hans de Goede 

Regards,

Hans


---
  drivers/hid/i2c-hid/i2c-hid.c | 16 
  1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index 57126f6837bb..17ec57c62a0b 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -47,7 +47,7 @@
  /* quirks to control the device */
  #define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV  BIT(0)
  #define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET  BIT(1)
-#define I2C_HID_QUIRK_RESEND_REPORT_DESCR  BIT(2)
+/* reserved: I2C_HID_QUIRK_RESEND_REPORT_DESCR BIT(2) */
  
  /* flags */

  #define I2C_HID_STARTED   0
@@ -170,12 +170,6 @@ static const struct i2c_hid_quirks {
I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
{ I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288,
I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
-   { I2C_VENDOR_ID_RAYD, I2C_PRODUCT_ID_RAYD_3118,
-   I2C_HID_QUIRK_RESEND_REPORT_DESCR },
-   { USB_VENDOR_ID_SIS_TOUCH, USB_DEVICE_ID_SIS10FB_TOUCH,
-   I2C_HID_QUIRK_RESEND_REPORT_DESCR },
-   { I2C_VENDOR_ID_RAYD, I2C_PRODUCT_ID_RAYD_4B33,
-   I2C_HID_QUIRK_RESEND_REPORT_DESCR },
{ 0, 0 }
  };
  
@@ -1245,11 +1239,9 @@ static int i2c_hid_resume(struct device *dev)

 * after resume, after this it will be back normal.
 * otherwise it issues too many incomplete reports.
 */
-   if (ihid->quirks & I2C_HID_QUIRK_RESEND_REPORT_DESCR) {
-   ret = i2c_hid_command(client, &hid_report_descr_cmd, NULL, 0);
-   if (ret)
-   return ret;
-   }
+   ret = i2c_hid_command(client, &hid_report_descr_cmd, NULL, 0);
+   if (ret)
+   return ret;
  
  	if (hid->driver && hid->driver->reset_resume) {

ret = hid->driver->reset_resume(hid);

Re: [PATCH] EDAC, ghes: use CPER module handles to locate DIMMs

[tanxiaofei]

On 2018/8/31 0:50, John Garry wrote:
> On 30/08/2018 17:34, James Morse wrote:
> 
> Hi James,
> 
> Zhengqiang no longer works on this topic, so I have cc'ed some more guys who 
> should be able to help.
> 
> John
> 
>> Hi Zhengqiang,
>>
>> On 29/08/18 19:33, Fan Wu wrote:
>>> The current ghes_edac driver does not update per-dimm error
>>> counters when reporting memory errors, because there is no
>>> platform-independent way to find DIMMs based on the error
>>> information provided by firmware. This patch offers a solution
>>> for platforms whose firmwares provide valid module handles
>>> (SMBIOS type 17) in error records. In this case ghes_edac will
>>> use the module handles to locate DIMMs and thus makes per-dimm
>>> error reporting possible.
>>
>> Does your platform set CPER_MEM_VALID_MODULE_HANDLE in GHES Memory errors? If
>> so, any chance you could test this patch on your platform? [0]
>> (original patch: https://lore.kernel.org/patchwork/patch/978928/)
>>

Hi James,

Our platform do not set CPER_MEM_VALID_MODULE_HANDLE in GHES Memory errors.

Thanks,
tanxiaofei

>> Thanks,
>>
>> James
>>
>> [0] https://marc.info/?l=linux-edac&m=152603960002324
>>
>>
>>> diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
>>> index 473aeec..db527f0 100644
>>> --- a/drivers/edac/ghes_edac.c
>>> +++ b/drivers/edac/ghes_edac.c
>>> @@ -81,6 +81,26 @@ static void ghes_edac_count_dimms(const struct 
>>> dmi_header *dh, void *arg)
>>>  (*num_dimm)++;
>>>  }
>>>
>>> +static int ghes_edac_dimm_index(u16 handle)
>>> +{
>>> +struct mem_ctl_info *mci;
>>> +int i;
>>> +
>>> +if (!ghes_pvt)
>>> +return -1;
>>> +
>>> +mci = ghes_pvt->mci;
>>> +
>>> +if (!mci)
>>> +return -1;
>>> +
>>> +for (i = 0; i < mci->tot_dimms; i++) {
>>> +if (mci->dimms[i]->smbios_handle == handle)
>>> +return i;
>>> +}
>>> +return -1;
>>> +}
>>> +
>>>  static void ghes_edac_dmidecode(const struct dmi_header *dh, void *arg)
>>>  {
>>>  struct ghes_edac_dimm_fill *dimm_fill = arg;
>>> @@ -177,6 +197,8 @@ static void ghes_edac_dmidecode(const struct dmi_header 
>>> *dh, void *arg)
>>>  entry->total_width, entry->data_width);
>>>  }
>>>
>>> +dimm->smbios_handle = entry->handle;
>>> +
>>>  dimm_fill->count++;
>>>  }
>>>  }
>>> @@ -327,12 +349,20 @@ void ghes_edac_report_mem_error(int sev, struct 
>>> cper_sec_mem_err *mem_err)
>>>  p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
>>>  if (mem_err->validation_bits & CPER_MEM_VALID_MODULE_HANDLE) {
>>>  const char *bank = NULL, *device = NULL;
>>> +int index = -1;
>>> +
>>>  dmi_memdev_name(mem_err->mem_dev_handle, &bank, &device);
>>> +p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
>>> + mem_err->mem_dev_handle);
>>>  if (bank != NULL && device != NULL)
>>>  p += sprintf(p, "DIMM location:%s %s ", bank, device);
>>> -else
>>> -p += sprintf(p, "DIMM DMI handle: 0x%.4x ",
>>> - mem_err->mem_dev_handle);
>>> +
>>> +index = ghes_edac_dimm_index(mem_err->mem_dev_handle);
>>> +if (index >= 0) {
>>> +e->top_layer = index;
>>> +e->enable_per_layer_report = true;
>>> +}
>>> +
>>>  }
>>>  if (p > e->location)
>>>  *(p - 1) = '\0';
>>> diff --git a/include/linux/edac.h b/include/linux/edac.h
>>> index bffb978..a45ce1f 100644
>>> --- a/include/linux/edac.h
>>> +++ b/include/linux/edac.h
>>> @@ -451,6 +451,8 @@ struct dimm_info {
>>>  u32 nr_pages;/* number of pages on this dimm */
>>>
>>>  unsigned csrow, cschannel;/* Points to the old API data */
>>> +
>>> +u16 smbios_handle;  /* Handle for SMBIOS type 17 */
>>>  };
>>>
>>>  /**
>>>
>>
>>
>> .
>>
> 
> 
> 
> .
> 

-- 
best wishes
 谭小飞

Re: [PATCH V6 4/4] video: simplefb: switch to use clk_bulk API to simplify clock operations

[Hans de Goede]

Hi,

On 31-08-18 06:45, Dong Aisheng wrote:

Switching to use clk_bulk API to simplify clock operations.

Cc: Hans de Goede 
Cc: Bartlomiej Zolnierkiewicz 
Cc: linux-fb...@vger.kernel.org
Cc: Masahiro Yamada 
Cc: Stephen Boyd 
Tested-by: Thor Thayer 
Signed-off-by: Dong Aisheng 
---
v5->v6:
  * address Hans's comments


v6 looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans




v4->v5:
  * fix wrong setting of par->clks_enabled
v3->v4:
  * no changes
v2->v3:
  * fix a build warning on x86 platform due to a wrong
of the prototype of simplefb_clocks_enable
v1->v2:
  * switch to clk_bulk_get_all from of_clk_bulk_get_all
---
  drivers/video/fbdev/simplefb.c | 72 +++---
  1 file changed, 18 insertions(+), 54 deletions(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 9a9d748..89fb1e7 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -181,8 +181,8 @@ struct simplefb_par {
u32 palette[PSEUDO_PALETTE_SIZE];
  #if defined CONFIG_OF && defined CONFIG_COMMON_CLK
bool clks_enabled;
-   unsigned int clk_count;
-   struct clk **clks;
+   int clk_count;
+   struct clk_bulk_data *clks;
  #endif
  #if defined CONFIG_OF && defined CONFIG_REGULATOR
bool regulators_enabled;
@@ -214,37 +214,13 @@ static int simplefb_clocks_get(struct simplefb_par *par,
   struct platform_device *pdev)
  {
struct device_node *np = pdev->dev.of_node;
-   struct clk *clock;
-   int i;
  
  	if (dev_get_platdata(&pdev->dev) || !np)

return 0;
  
-	par->clk_count = of_clk_get_parent_count(np);

-   if (!par->clk_count)
-   return 0;
-
-   par->clks = kcalloc(par->clk_count, sizeof(struct clk *), GFP_KERNEL);
-   if (!par->clks)
-   return -ENOMEM;
-
-   for (i = 0; i < par->clk_count; i++) {
-   clock = of_clk_get(np, i);
-   if (IS_ERR(clock)) {
-   if (PTR_ERR(clock) == -EPROBE_DEFER) {
-   while (--i >= 0) {
-   if (par->clks[i])
-   clk_put(par->clks[i]);
-   }
-   kfree(par->clks);
-   return -EPROBE_DEFER;
-   }
-   dev_err(&pdev->dev, "%s: clock %d not found: %ld\n",
-   __func__, i, PTR_ERR(clock));
-   continue;
-   }
-   par->clks[i] = clock;
-   }
+   par->clk_count = clk_bulk_get_all(&pdev->dev, &par->clks);
+   if (par->clk_count == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
  
  	return 0;

  }
@@ -252,39 +228,27 @@ static int simplefb_clocks_get(struct simplefb_par *par,
  static void simplefb_clocks_enable(struct simplefb_par *par,
   struct platform_device *pdev)
  {
-   int i, ret;
+   int ret;
  
-	for (i = 0; i < par->clk_count; i++) {

-   if (par->clks[i]) {
-   ret = clk_prepare_enable(par->clks[i]);
-   if (ret) {
-   dev_err(&pdev->dev,
-   "%s: failed to enable clock %d: %d\n",
-   __func__, i, ret);
-   clk_put(par->clks[i]);
-   par->clks[i] = NULL;
-   }
-   }
-   }
-   par->clks_enabled = true;
+   if (par->clk_count <= 0)
+   return;
+
+   ret = clk_bulk_prepare_enable(par->clk_count, par->clks);
+   if (ret)
+   dev_warn(&pdev->dev, "failed to enable clocks\n");
+   else
+   par->clks_enabled = true;
  }
  
  static void simplefb_clocks_destroy(struct simplefb_par *par)

  {
-   int i;
-
-   if (!par->clks)
+   if (par->clk_count <= 0)
return;
  
-	for (i = 0; i < par->clk_count; i++) {

-   if (par->clks[i]) {
-   if (par->clks_enabled)
-   clk_disable_unprepare(par->clks[i]);
-   clk_put(par->clks[i]);
-   }
-   }
+   if (par->clks_enabled)
+   clk_bulk_disable_unprepare(par->clk_count, par->clks);
  
-	kfree(par->clks);

+   clk_bulk_put_all(par->clk_count, par->clks);
  }
  #else
  static int simplefb_clocks_get(struct simplefb_par *par,

Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

[Peter Zijlstra]

On Fri, Aug 31, 2018 at 10:54:18AM +0100, Will Deacon wrote:

> Proposal below (omitted Linus because that seems to be the pattern elsewhere
> in the file and he's not going to shout at himself when things break :)
> Anybody I've missed?
> 
> Will
> 
> --->8
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a5b256b25905..7224b5618883 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9681,6 +9681,15 @@ S: Maintained
>  F:   arch/arm/boot/dts/mmp*
>  F:   arch/arm/mach-mmp/
>  
> +MMU GATHER AND TLB INVALIDATION
> +M:   Will Deacon 
> +M:   Nick Piggin 
> +M:   Peter Zijlstra 
> +L:   linux-a...@vger.kernel.org
> +S:   Maintained
> +F:   include/asm-generic/tlb.h
> +F:   arch/*/include/asm/tlb.h
> +
>  MN88472 MEDIA DRIVER
>  M:   Antti Palosaari 
>  L:   linux-me...@vger.kernel.org

If we're going to do that (and I'm not opposed); it might make sense to
do something like the below and add:

 F:  mm/mmu_gather.c

---
 b/mm/mmu_gather.c |  250 ++
 include/asm-generic/tlb.h |2 
 mm/Makefile   |2 
 mm/memory.c   |  247 -
 4 files changed, 253 insertions(+), 248 deletions(-)

--- a/include/asm-generic/tlb.h
+++ b/include/asm-generic/tlb.h
@@ -149,6 +149,8 @@ static inline void tlb_flush_mmu_tlbonly
__tlb_reset_range(tlb);
 }
 
+extern void tlb_flush_mmu_free(struct mmu_gather *tlb);
+
 static inline void tlb_remove_page_size(struct mmu_gather *tlb,
struct page *page, int page_size)
 {
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -22,7 +22,7 @@ KCOV_INSTRUMENT_mmzone.o := n
 KCOV_INSTRUMENT_vmstat.o := n
 
 mmu-y  := nommu.o
-mmu-$(CONFIG_MMU)  := gup.o highmem.o memory.o mincore.o \
+mmu-$(CONFIG_MMU)  := gup.o highmem.o memory.o mmu_gather.o mincore.o \
   mlock.o mmap.o mprotect.o mremap.o msync.o \
   page_vma_mapped.o pagewalk.o pgtable-generic.o \
   rmap.o vmalloc.o
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -186,253 +186,6 @@ static void check_sync_rss_stat(struct t
 
 #endif /* SPLIT_RSS_COUNTING */
 
-#ifdef HAVE_GENERIC_MMU_GATHER
-
-static bool tlb_next_batch(struct mmu_gather *tlb)
-{
-   struct mmu_gather_batch *batch;
-
-   batch = tlb->active;
-   if (batch->next) {
-   tlb->active = batch->next;
-   return true;
-   }
-
-   if (tlb->batch_count == MAX_GATHER_BATCH_COUNT)
-   return false;
-
-   batch = (void *)__get_free_pages(GFP_NOWAIT | __GFP_NOWARN, 0);
-   if (!batch)
-   return false;
-
-   tlb->batch_count++;
-   batch->next = NULL;
-   batch->nr   = 0;
-   batch->max  = MAX_GATHER_BATCH;
-
-   tlb->active->next = batch;
-   tlb->active = batch;
-
-   return true;
-}
-
-void arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
-   unsigned long start, unsigned long end)
-{
-   tlb->mm = mm;
-
-   /* Is it from 0 to ~0? */
-   tlb->fullmm = !(start | (end+1));
-   tlb->need_flush_all = 0;
-   tlb->local.next = NULL;
-   tlb->local.nr   = 0;
-   tlb->local.max  = ARRAY_SIZE(tlb->__pages);
-   tlb->active = &tlb->local;
-   tlb->batch_count = 0;
-
-#ifdef CONFIG_HAVE_RCU_TABLE_FREE
-   tlb->batch = NULL;
-#endif
-   tlb->page_size = 0;
-
-   __tlb_reset_range(tlb);
-}
-
-static void tlb_flush_mmu_free(struct mmu_gather *tlb)
-{
-   struct mmu_gather_batch *batch;
-
-#ifdef CONFIG_HAVE_RCU_TABLE_FREE
-   tlb_table_flush(tlb);
-#endif
-   for (batch = &tlb->local; batch && batch->nr; batch = batch->next) {
-   free_pages_and_swap_cache(batch->pages, batch->nr);
-   batch->nr = 0;
-   }
-   tlb->active = &tlb->local;
-}
-
-void tlb_flush_mmu(struct mmu_gather *tlb)
-{
-   tlb_flush_mmu_tlbonly(tlb);
-   tlb_flush_mmu_free(tlb);
-}
-
-/* tlb_finish_mmu
- * Called at the end of the shootdown operation to free up any resources
- * that were required.
- */
-void arch_tlb_finish_mmu(struct mmu_gather *tlb,
-   unsigned long start, unsigned long end, bool force)
-{
-   struct mmu_gather_batch *batch, *next;
-
-   if (force)
-   __tlb_adjust_range(tlb, start, end - start);
-
-   tlb_flush_mmu(tlb);
-
-   /* keep the page table cache within bounds */
-   check_pgt_cache();
-
-   for (batch = tlb->local.next; batch; batch = next) {
-   next = batch->next;
-   free_pages((unsigned long)batch, 0);
-   }
-   tlb->local.next = NULL;
-}
-
-/* __tlb_remove_page
- * Must perform the equivalent to __free_pte(pte_get_and_clear(ptep)), 
while
- * handling the additional races in SMP caused by other CPUs caching valid
- * mappings in their TLBs. Returns the number of free page slots left.
- * When o

[PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller

[Yogesh Gaur]

- Add a driver for NXP FlexSPI host controller

 FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475,
 which supports two SPI channels and up to 4 external devices.
 Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 
bidirectional data lines)
 i.e. FlexSPI acts as an interface to external devices, maximum 4, each with up 
to 8
 bidirectional data lines.

 FlexSPI controller is similar to the existing Freescale/NXP QuadSPI
 controller with advanced features.

- Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2
 filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS targets.
 LX2160ARDB is having two NOR slave device connected on single bus A
 i.e. A0 and A1 (CS0 and CS1).
 LX2160AQDS is having two NOR slave device connected on separate buses
 one flash on A0 and second on B1 i.e. (CS0 and CS3).
 Verified this driver on following SPI NOR flashes:
Micron, mt35xu512aba[3], [Read - 1 bit mode]
Cypress, s25fl512s, [Read - 1/2/4 bit mode]

Patch 1 adds variable size in spi_device struct, to save the
size of connected slave device.
Patch 2 adds flags for octal I/O data transfer.
Support for octal flash commands and other framework changes would going to be 
done in different
patch set.
Patch 3 adds a driver for the NXP FlexSPI controller, driver is based on
new spi-mem framework.
Patch 4 add binding file for this driver.
Patch 5 add device node property for FlexSPI driver for lx2160 SoC.
Patch 6 enables the config option.
Patch 7 add MAINTAINERS file.

[1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf
[2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=9721
[3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=63445

This series adds below patches:
Yogesh Gaur (7):
  spi: add slave device size in spi_device struct
  spi: add flags for octal I/O data transfer
  spi: spi-mem: Add a driver for NXP FlexSPI controller
  dt-bindings: spi: add binding file for NXP FlexSPI driver
  arm64: dts: lx2160a: add fspi node property
  arm64: defconfig: enable NXP FlexSPI driver
  MAINTAINERS: add maintainers for the NXP FlexSPI driver

 .../devicetree/bindings/spi/spi-nxp-fspi.txt   |   42 +
 MAINTAINERS|6 +
 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts  |   21 +
 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi |   12 +
 arch/arm64/configs/defconfig   |1 +
 drivers/mtd/devices/m25p80.c   |6 +
 drivers/mtd/spi-nor/spi-nor.c  |2 +
 drivers/spi/Kconfig|   10 +
 drivers/spi/Makefile   |1 +
 drivers/spi/spi-nxp-fspi.c | 1242 
 include/linux/spi/spi.h|4 +
 11 files changed, 1347 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
 create mode 100644 drivers/spi/spi-nxp-fspi.c

-- 
2.7.4

[PATCH 2/7] spi: add flags for octal I/O data transfer

[Yogesh Gaur]

Add flags for Octal I/O data transfer
Required for the SPI controller which can do data transfer (TX/RX)
on 8 data lines e.g. NXP FlexSPI controller.
 SPI_TX_OCTAL: transmit with 8 wires
 SPI_RX_OCTAL: receive with 8 wires

Signed-off-by: Yogesh Gaur 
---
 include/linux/spi/spi.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 558aeed..180f277 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -164,6 +164,8 @@ struct spi_device {
 #defineSPI_TX_QUAD 0x200   /* transmit with 4 
wires */
 #defineSPI_RX_DUAL 0x400   /* receive with 2 wires 
*/
 #defineSPI_RX_QUAD 0x800   /* receive with 4 wires 
*/
+#defineSPI_TX_OCTAL0x1000  /* transmit with 8 
wires */
+#defineSPI_RX_OCTAL0x2000  /* receive with 8 wires 
*/
int irq;
void*controller_state;
void*controller_data;
-- 
2.7.4

Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

[Nicholas Piggin]

On Fri, 31 Aug 2018 12:10:14 +0200
Peter Zijlstra  wrote:

> On Fri, Aug 31, 2018 at 10:54:18AM +0100, Will Deacon wrote:
> 
> > Proposal below (omitted Linus because that seems to be the pattern elsewhere
> > in the file and he's not going to shout at himself when things break :)
> > Anybody I've missed?
> > 
> > Will
> >   
> > --->8  
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index a5b256b25905..7224b5618883 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9681,6 +9681,15 @@ S:   Maintained
> >  F: arch/arm/boot/dts/mmp*
> >  F: arch/arm/mach-mmp/
> >  
> > +MMU GATHER AND TLB INVALIDATION
> > +M: Will Deacon 
> > +M: Nick Piggin 

Oh gee, I suppose. powerpc hash is kind of interesting because it's
crazy, Aneesh knows that code a lot better than I do. radix modulo
some minor details of exact instructions is fairly like x86 (he 
wrote a lot of that code too AFAIK).

> > +M: Peter Zijlstra 
> > +L: linux-a...@vger.kernel.org

Maybe put linux-mm as well? Or should there just be one list?

> > +S: Maintained
> > +F: include/asm-generic/tlb.h
> > +F: arch/*/include/asm/tlb.h
> > +
> >  MN88472 MEDIA DRIVER
> >  M: Antti Palosaari 
> >  L: linux-me...@vger.kernel.org  
> 
> If we're going to do that (and I'm not opposed); it might make sense to
> do something like the below and add:
> 
>  F:  mm/mmu_gather.c

I think that is a good idea regardless. How do feel about calling it
tlb.c? Easier to type and autocompletes sooner.

> 
> ---
>  b/mm/mmu_gather.c |  250 
> ++
>  include/asm-generic/tlb.h |2 
>  mm/Makefile   |2 
>  mm/memory.c   |  247 
> -

[PATCH 7/7] MAINTAINERS: add maintainers for the NXP FlexSPI driver

[Yogesh Gaur]

Add maintainers for the NXP FlexSPI driver

Signed-off-by: Yogesh Gaur 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d5eeff..2696898 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10228,6 +10228,12 @@ L: linux-...@lists.01.org (moderated for 
non-subscribers)
 S: Supported
 F: drivers/nfc/nxp-nci
 
+NXP FSPI DRIVER
+M: Yogesh Gaur 
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/spi/spi-nxp-fspi.c
+
 OBJTOOL
 M: Josh Poimboeuf 
 M: Peter Zijlstra 
-- 
2.7.4

[PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller

[Yogesh Gaur]

- Add a driver for NXP FlexSPI host controller

(0) What is the FlexSPI controller?
 FlexSPI is a flexsible SPI host controller which supports two SPI
 channels and up to 4 external devices.
 Each channel supports Single/Dual/Quad/Octal mode data 
 transfer (1/2/4/8 bidirectional data lines) 
 i.e. FlexSPI acts as an interface to external devices,
 maximum 4, each with up to 8 bidirectional data lines.

 It uses new SPI memory interface of the SPI framework to issue flash
 memory operations to up to four connected flash chips (2 buses with
 2 CS each).
 Chipselect for each flash can be selected as per address assigned in
 controller specific registers.

 FlexSPI controller is similar to the existing Freescale/NXP QuadSPI
 controller with advanced features.

(1) The FlexSPI controller is driven by the LUT(Look-up Table)
 registers.
 The LUT registers are a look-up-table for sequences of instructions.
 A valid sequence consists of four LUT registers.
 Maximum 32 LUT sequences can be programmed simultaneously.

(2) The definition of the LUT register shows below:
 ---
 | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 |
 ---

 There are several types of INSTRx, such as:
 CMD : the SPI NOR command.
 ADDR: the address for the SPI NOR command.
 DUMMY   : the dummy cycles needed by the SPI NOR command.
 

 There are several types of PADx, such as:
 PAD1: use a singe I/O line.
 PAD2: use two I/O lines.
 PAD4: use quad I/O lines.
 PAD8: use octal I/O lines.
 

(3) LUTs are being created at run-time based on the commands passed
 from the spi-mem framework. Thus, using single LUT index.

(4) Software triggered Flash read/write access by IP Bus.

(5) Memory mapped read access by AHB Bus.

(6) Tested this driver with the mtd_debug and JFFS2 filesystem utility
 on NXP LX2160ARDB and LX2160AQDS targets.
 LX2160ARDB is having two NOR slave device connected on single bus A
 i.e. A0 and A1 (CS0 and CS1).
 LX2160AQDS is having two NOR slave device connected on separate buses
 one flash on A0 and second on B1 i.e. (CS0 and CS3).
 Verified this driver on following SPI NOR flashes:
Micron, mt35xu512ab, [Read - 1 bit mode]
Cypress, s25fl512s, [Read - 1/2/4 bit mode]

- Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver.

- Add entry in the 'spi-nor/Makefile'.

Signed-off-by: Yogesh Gaur 
---
 drivers/spi/Kconfig|   10 +
 drivers/spi/Makefile   |1 +
 drivers/spi/spi-nxp-fspi.c | 1242 
 3 files changed, 1253 insertions(+)
 create mode 100644 drivers/spi/spi-nxp-fspi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ad5d68e..68da874 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -251,6 +251,16 @@ config SPI_FSL_LPSPI
help
  This enables Freescale i.MX LPSPI controllers in master mode.
 
+config SPI_NXP_FLEXSPI
+   tristate "NXP Flex SPI controller"
+   depends on ARCH_LAYERSCAPE || HAS_IOMEM
+   help
+ This enables support for the Flex SPI controller in master mode.
+ Up to four slave devices can be connected on two buses with two
+ chipselects each.
+ This controller does not support generic SPI messages and only
+ supports the high-level SPI memory interface.
+
 config SPI_GPIO
tristate "GPIO-based bitbanging SPI Master"
depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index cb1f437..52c9f18 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi-mpc52xx.o
 obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o
 obj-$(CONFIG_SPI_MXS)  += spi-mxs.o
 obj-$(CONFIG_SPI_NUC900)   += spi-nuc900.o
+obj-$(CONFIG_SPI_NXP_FLEXSPI)  += spi-nxp-fspi.o
 obj-$(CONFIG_SPI_OC_TINY)  += spi-oc-tiny.o
 spi-octeon-objs:= spi-cavium.o 
spi-cavium-octeon.o
 obj-$(CONFIG_SPI_OCTEON)   += spi-octeon.o
diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
new file mode 100644
index 000..677401b
--- /dev/null
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -0,0 +1,1242 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * NXP FlexSPI(FSPI) controller driver.
+ *
+ * Copyright 2018 NXP
+ *
+ * Based on SPI MEM interface:
+ * Author:
+ * Yogesh Gaur 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+ * The driver only uses one single LUT entry, that is updated on
+ * each call of exec_op(). Index 0 is preset at boot with a basic
+ * read operation, so let's use the last entry (31).
+ */
+#defineSEQID_LUT   31
+
+/* Registers used by t

[PATCH 5/7] arm64: dts: lx2160a: add fspi node property

[Yogesh Gaur]

Add fspi node property for LX2160A SoC for FlexSPI driver.
Property added for the FlexSPI controller and for the connected
slave device for the LX2160ARDB target.
This is having two SPI-NOR flash device, mt35xu512aba, connected
at CS0 and CS1.

Signed-off-by: Yogesh Gaur 
---
 arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 +
 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi| 12 
 2 files changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts 
b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 70fad20..3646315 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -32,6 +32,27 @@
status = "okay";
 };
 
+&fspi {
+   status = "okay";
+   flash0: mt35xu512aba@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "m25p80";
+   m25p,fast-read;
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   };
+
+   flash1: mt35xu512aba@1 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "m25p80";
+   m25p,fast-read;
+   spi-max-frequency = <2000>;
+   reg = <1>;
+   };
+};
+
 &i2c0 {
status = "okay";
pca9547@77 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index e35e494..031eb26 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -568,5 +568,17 @@
timeout-sec = <30>;
};
 
+   fspi: flexspi@20c {
+   status = "disabled";
+   compatible = "nxp,lx2160a-fspi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0 0x20c 0x0 0x1>,
+   <0x0 0x2000 0x0 0x1000>;
+   reg-names = "fspi_base", "fspi_mmap";
+   interrupts = <0 25 0x4>; /* Level high type */
+   clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+   clock-names = "fspi_en", "fspi";
+   };
};
 };
-- 
2.7.4

[PATCH 1/7] spi: add slave device size in spi_device struct

[Yogesh Gaur]

Add 'size' data variable in spi_device struct.
This is to save the size of the connected slave device.

After slave device scan, spi_nor_scan, size being assigned to this
from MTD layer.

SFDP read is being requested before completion of spi_nor_scan()
routine, thus populate device size before making read request
to the SPI controller.

Signed-off-by: Yogesh Gaur 
---
 drivers/mtd/devices/m25p80.c  | 6 ++
 drivers/mtd/spi-nor/spi-nor.c | 2 ++
 include/linux/spi/spi.h   | 2 ++
 3 files changed, 10 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index fe260cc..6c7ad86 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t 
from, size_t len,
/* convert the dummy cycles to the number of bytes */
op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
 
+   /* for case of SFDP header read commands, populate spi device size */
+   if (flash->spimem->spi->size == 0)
+   flash->spimem->spi->size = nor->mtd.size;
+
while (remaining) {
op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
ret = spi_mem_adjust_op_size(flash->spimem, &op);
@@ -215,6 +219,8 @@ static int m25p_probe(struct spi_mem *spimem)
if (ret)
return ret;
 
+   spi->size = nor->mtd.size;
+
return mtd_device_register(&nor->mtd, data ? data->parts : NULL,
   data ? data->nr_parts : 0);
 }
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 6042df8..b066bed 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -2864,6 +2864,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
if (info->flags & SPI_S3AN)
nor->flags |=  SNOR_F_READY_XSR_RDY;
 
+   mtd->size = info->sector_size * info->n_sectors;
+
/* Parse the Serial Flash Discoverable Parameters table. */
ret = spi_nor_init_params(nor, info, ¶ms);
if (ret)
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index a64235e..558aeed 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -127,6 +127,7 @@ void spi_statistics_add_transfer_stats(struct 
spi_statistics *stats,
  * for driver coldplugging, and in uevents used for hotplugging
  * @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when
  * not using a GPIO line)
+ * @size: size of the connected slave device
  *
  * @statistics: statistics for the spi_device
  *
@@ -168,6 +169,7 @@ struct spi_device {
void*controller_data;
charmodalias[SPI_NAME_SIZE];
int cs_gpio;/* chip select gpio */
+   u32 size;   /* size of slave device */
 
/* the statistics */
struct spi_statistics   statistics;
-- 
2.7.4

[PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver

[Yogesh Gaur]

Add binding file for NXP FlexSPI driver.

Signed-off-by: Yogesh Gaur 
---
 .../devicetree/bindings/spi/spi-nxp-fspi.txt   | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt 
b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
new file mode 100644
index 000..9f07116
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
@@ -0,0 +1,42 @@
+* NXP Flex Serial Peripheral Interface (FSPI)
+
+Required properties:
+  - compatible : Should be "nxp,lx2160a-fspi"
+  - reg :First contains the register location and length,
+ Second contains the memory mapping address and length
+  - reg-names :  Should contain the resource reg names:
+ - fspi_base: iconfiguration register address space
+ - fspi_mmap: memory mapped address space
+  - interrupts : Should contain the interrupt for the device
+
+Optional properties:
+  - big-endian : See common-properties.txt.
+
+Required SPI slave node properties:
+  - reg :There are two buses (A and B) with two chip selects each.
+ This encodes to which bus and CS the flash is connected:
+ - <0>: Bus A, CS 0
+ - <1>: Bus A, CS 1
+ - <2>: Bus B, CS 0
+ - <3>: Bus B, CS 1
+
+Example showing the usage of two SPI NOR slave devices on bus A:
+
+fspi0: flexspi@20c {
+   compatible = "nxp,lx2160a-fspi";
+   reg = <0x0 0x20c 0x0 0x1>, <0x0 0x2000 0x0 0x1000>;
+   reg-names = "fspi_base", "fspi_mmap";
+   interrupts = <0 25 0x4>; /* Level high type */
+   clocks = <&clockgen 4 3>, <&clockgen 4 3>;
+   clock-names = "fspi_en", "fspi";
+
+   flash0: mt35xu512aba@0 {
+   reg = <0>;
+   
+   };
+
+   flash1: mt35xu512aba@1 {
+   reg = <1>;
+   
+   };
+};
-- 
2.7.4

[PATCH 6/7] arm64: defconfig: enable NXP FlexSPI driver

[Yogesh Gaur]

Enable driver support of NXP FlexSPI controller.

Signed-off-by: Yogesh Gaur 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 3cfa8ca..75ceddf 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -335,6 +335,7 @@ CONFIG_SPI_QUP=y
 CONFIG_SPI_ROCKCHIP=y
 CONFIG_SPI_S3C64XX=y
 CONFIG_SPI_SPIDEV=m
+CONFIG_SPI_NXP_FLEXSPI=y
 CONFIG_SPMI=y
 CONFIG_PINCTRL_IPQ8074=y
 CONFIG_PINCTRL_SINGLE=y
-- 
2.7.4

Re: [PATCH v12 04/12] livepatch: Consolidate klp_free functions

[Miroslav Benes]

On Tue, 28 Aug 2018, Petr Mladek wrote:

> The code for freeing livepatch structures is a bit scattered and tricky:
> 
>   + direct calls to klp_free_*_limited() and kobject_put() are
> used to release partially initialized objects
> 
>   + klp_free_patch() removes the patch from the public list
> and releases all objects except for patch->kobj
> 
>   + object_put(&patch->kobj) and the related wait_for_completion()
> are called directly outside klp_mutex; this code is duplicated;
> 
> Now, we are going to remove the registration stage to simplify the API
> and the code. This would require handling more situations in
> klp_enable_patch() error paths.
> 
> More importantly, we are going to add a feature called atomic replace.
> It will need to dynamically create func and object structures. We will
> want to reuse the existing init() and free() functions. This would
> create even more error path scenarios.
> 
> This patch implements a more clever free functions:
> 
>   + checks kobj.state_initialized instead of @limit
> 
>   + initializes patch->list early so that the check for empty list
> always works
> 
>   + The action(s) that has to be done outside klp_mutex are done
> in separate klp_free_patch_end() function. It waits only
> when patch->kobj was really released via the _begin() part.
> 
> Note that it is safe to put patch->kobj under klp_mutex. It calls
> the release callback only when the reference count reaches zero.
> Therefore it does not block any related sysfs operation that took
> a reference and might eventually wait for klp_mutex.

This seems to be the reason of the issue which lockdep reported. The patch 
moved kobject_put(&patch->kobj) under klp_mutex. Perhaps I cannot read 
kernfs code properly today, but I fail to understand why it is supposed to 
be safe.

Indeed, if it is safe, lockdep report is false positive.

> Note that __klp_free_patch() is split because it will be later
> used in a _nowait() variant. Also klp_free_patch_end() makes
> sense because it will later get more complicated.

There are no _begin() and _end() functions in the patch.
 
> This patch does not change the existing behavior.
> 
> Signed-off-by: Petr Mladek 
> Cc: Josh Poimboeuf 
> Cc: Jessica Yu 
> Cc: Jiri Kosina 
> Cc: Jason Baron 
> Acked-by: Miroslav Benes 

My Acked-by here is a bit premature.

> ---
>  include/linux/livepatch.h |  2 ++
>  kernel/livepatch/core.c   | 92 
> +--
>  2 files changed, 59 insertions(+), 35 deletions(-)
> 
> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> index 1163742b27c0..22e0767d64b0 100644
> --- a/include/linux/livepatch.h
> +++ b/include/linux/livepatch.h
> @@ -138,6 +138,7 @@ struct klp_object {
>   * @list:list node for global list of registered patches
>   * @kobj:kobject for sysfs resources
>   * @enabled: the patch is enabled (but operation may be incomplete)
> + * @wait_free:   wait until the patch is freed
>   * @finish:  for waiting till it is safe to remove the patch module
>   */
>  struct klp_patch {
> @@ -149,6 +150,7 @@ struct klp_patch {
>   struct list_head list;
>   struct kobject kobj;
>   bool enabled;
> + bool wait_free;
>   struct completion finish;
>  };
>  
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index b3956cce239e..3ca404545150 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -465,17 +465,15 @@ static struct kobj_type klp_ktype_func = {
>   .sysfs_ops = &kobj_sysfs_ops,
>  };
>  
> -/*
> - * Free all functions' kobjects in the array up to some limit. When limit is
> - * NULL, all kobjects are freed.
> - */
> -static void klp_free_funcs_limited(struct klp_object *obj,
> -struct klp_func *limit)
> +static void klp_free_funcs(struct klp_object *obj)
>  {
>   struct klp_func *func;
>  
> - for (func = obj->funcs; func->old_name && func != limit; func++)
> - kobject_put(&func->kobj);
> + klp_for_each_func(obj, func) {
> + /* Might be called from klp_init_patch() error path. */
> + if (func->kobj.state_initialized)
> + kobject_put(&func->kobj);
> + }
>  }

Just for the record, it is a slightly suboptimal because now we iterate 
through the whole list. We could add break to else branch, I think, but 
it's not necessary.
  
>  /* Clean up when a patched object is unloaded */
> @@ -489,26 +487,59 @@ static void klp_free_object_loaded(struct klp_object 
> *obj)
>   func->old_addr = 0;
>  }
>  
> -/*
> - * Free all objects' kobjects in the array up to some limit. When limit is
> - * NULL, all kobjects are freed.
> - */
> -static void klp_free_objects_limited(struct klp_patch *patch,
> -  struct klp_object *limit)
> +static void klp_free_objects(struct klp_patch *patch)
>  {
>   struct klp_object *obj;
>  
> - for (obj = patch->objs; obj

Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

[Peter Zijlstra]

On Fri, Aug 31, 2018 at 08:32:34PM +1000, Nicholas Piggin wrote:
> Oh gee, I suppose. powerpc hash is kind of interesting because it's
> crazy, Aneesh knows that code a lot better than I do. radix modulo
> some minor details of exact instructions is fairly like x86 

The whole TLB broadcast vs explicit IPIs is a fairly big difference in
my book.

Anyway, have you guys tried the explicit IPI approach? Depending on how
IPIs are routed vs broadcasts it might save a little bus traffic. No
point in getting all CPUs to process the TLBI when there's only a hand
full that really need it.

OTOH, I suppose the broadcast thing has been optimized to death on the
hardware side, so who knows..

Re: [PATCH v13 07/13] x86/sgx: Add data structures for tracking the EPC pages

[Jarkko Sakkinen]

On Tue, Aug 28, 2018 at 09:53:11AM -0700, Dave Hansen wrote:
> >>>  extern bool sgx_enabled;
> >>>  extern bool sgx_lc_enabled;
> >>> +extern struct sgx_epc_bank sgx_epc_banks[SGX_MAX_EPC_BANKS];
> >>> +
> >>> +/*
> >>> + * enum sgx_epc_page_desc - defines bits and masks for an EPC page's desc
> >>
> >> Why are you bothering packing these bits?  This seems a rather
> >> convoluted way to store two integers.
> > 
> > To keep struct sgx_epc_page 64 bytes.
> 
> It's a list_head and a ulong now.  That doesn't add up to 64.

Ah, there used to be one more variable in it.

> If you properly describe the bounds and limits of banks we can possibly
> help you find a nice solution.  As it stands, they are totally opaque
> and we have no idea what is going on.

Great, I see what I can do. I understand now better what you are looking
for. Thanks Dave.

/Jarkko

Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

[Will Deacon]

On Fri, Aug 31, 2018 at 12:49:45PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 31, 2018 at 08:32:34PM +1000, Nicholas Piggin wrote:
> > Oh gee, I suppose. powerpc hash is kind of interesting because it's
> > crazy, Aneesh knows that code a lot better than I do. radix modulo
> > some minor details of exact instructions is fairly like x86 
> 
> The whole TLB broadcast vs explicit IPIs is a fairly big difference in
> my book.
> 
> Anyway, have you guys tried the explicit IPI approach? Depending on how
> IPIs are routed vs broadcasts it might save a little bus traffic. No
> point in getting all CPUs to process the TLBI when there's only a hand
> full that really need it.
> 
> OTOH, I suppose the broadcast thing has been optimized to death on the
> hardware side, so who knows..

You also can't IPI an IOMMU or a GPU ;)

Will

Re: [PATCH v13 07/13] x86/sgx: Add data structures for tracking the EPC pages

[Jarkko Sakkinen]

On Tue, Aug 28, 2018 at 02:34:32PM -0700, Sean Christopherson wrote:
> On Tue, Aug 28, 2018 at 09:53:11AM -0700, Dave Hansen wrote:
> > >>> +   sgx_nr_epc_banks++;
> > >>> +   }
> > >>> +
> > >>> +   if (!sgx_nr_epc_banks) {
> > >>> +   pr_err("There are zero EPC banks.\n");
> > >>> +   return -ENODEV;
> > >>> +   }
> > >>> +
> > >>> +   return 0;
> > >>> +}
> > >>
> > >> Does this support hot-addition of a bank?  If not, why not?
> > ...
> > > I'm not aware that we would have an ACPI specification for SGX so this
> > > is all I have at the moment (does not show any ACPI event for
> > > hotplugging).
> > 
> > So you're saying the one platform you looked at don't support hotplug.
> > I was looking for a more broad statement about SGX.
> 
> Hardware doesn't support hotplug of EPC as the EPC size and location
> is locked during activation of SGX.  And IIRC, activation of SGX must
> be synchronized across all CPUs in a multi-socket platform, e.g. you
> can't late-enable SGX on a socket and due hotplugging that way.

Makes me wonder how on a multisocket platform would this work anyway
given that they have different fused keys?

> In a virtualized environment there are no such restrictions.  I am not
> aware of any explicit requirements or use cases for supporting hotplug
> of EPC, but that's probably only because virtualization of SGX is
> fairly nascent.

/Jarkko

Re: [PATCH 2/4] tty: Hold tty_ldisc_lock() during tty_reopen()

[Tetsuo Handa]

On 2018/08/31 15:51, Jiri Slaby wrote:
> On 08/29/2018, 05:19 PM, Tetsuo Handa wrote:
>> On 2018/08/29 11:23, Dmitry Safonov wrote:
>>> tty_ldisc_reinit() doesn't race with neither tty_ldisc_hangup()
>>> nor set_ldisc() nor tty_ldisc_release() as they use tty lock.
>>> But it races with anyone who expects line discipline to be the same
>>> after hoding read semaphore in tty_ldisc_ref().
>>>
>>> We've seen the following crash on v4.9.108 stable:
>>>
>>> BUG: unable to handle kernel paging request at 2260
>>> IP: [..] n_tty_receive_buf_common+0x5f/0x86d
>>> Workqueue: events_unbound flush_to_ldisc
>>> Call Trace:
>>>  [..] n_tty_receive_buf2
>>>  [..] tty_ldisc_receive_buf
>>>  [..] flush_to_ldisc
>>>  [..] process_one_work
>>>  [..] worker_thread
>>>  [..] kthread
>>>  [..] ret_from_fork
>>>
>>> I think, tty_ldisc_reinit() should be called with ldisc_sem hold for
>>> writing, which will protect any reader against line discipline changes.
>>>
>>> Note: I failed to reproduce the described crash, so obiviously can't
>>> guarantee that this is the place where line discipline was switched.
>>
>> This will be same with a report at
>> https://syzkaller.appspot.com/bug?id=f08670354701fa64cc0dd3c0128a491bdb16adcc
>>  .
>>
>> syzbot is now testing a patch from Jiri Slaby.
> 
> Yes, my patch passed, so could you add:
> Reported-by: syzbot+3aa9784721dfb90e9...@syzkaller.appspotmail.com
> 
> (not adding tested-by as this particular patch was not tested, but
> shoiuld work the same way.)
> 
> thanks,
> 

Tested with all 4 patches applied using syzbot-provided reproducer and
my simplified reproducer. No crashes and no lockdep warnings.
Also, noisy messages like

  pts pts4033: tty_release: tty->count(10529) != (#fd's(7) + #kopen's(0))

are gone. Very nice. Thank you.

Re: [GIT PULL] Char/Misc driver patches for 4.19-rc1

[Pavel Machek]

Hi!

>   - gnss, finally an in-kernel GPS subsystem to try to tame all of
> the crazy out-of-tree drivers that have been floating around
> for years, combined with some really hacky userspace
> implementations.  This is only for GNSS receivers, but you
> have to start somewhere, and this is great to see.

Yes, it  is labeled as a GPS subsystem, but there's nothing GPS
specific in there; it does not understand the data, it just passes
around bytes.

Which would not be a problem, except that it takes /dev/gnssX
namespace, so when we need to introduce hardware abstraction for
GPS, we will not have suitable names available.

I believe this should be fixed before we are stuck with bad ABI
forever.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

[Peter Zijlstra]

On Fri, Aug 31, 2018 at 12:12:48PM +0100, Will Deacon wrote:
> On Fri, Aug 31, 2018 at 12:49:45PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 31, 2018 at 08:32:34PM +1000, Nicholas Piggin wrote:
> > > Oh gee, I suppose. powerpc hash is kind of interesting because it's
> > > crazy, Aneesh knows that code a lot better than I do. radix modulo
> > > some minor details of exact instructions is fairly like x86 
> > 
> > The whole TLB broadcast vs explicit IPIs is a fairly big difference in
> > my book.
> > 
> > Anyway, have you guys tried the explicit IPI approach? Depending on how
> > IPIs are routed vs broadcasts it might save a little bus traffic. No
> > point in getting all CPUs to process the TLBI when there's only a hand
> > full that really need it.
> > 
> > OTOH, I suppose the broadcast thing has been optimized to death on the
> > hardware side, so who knows..
> 
> You also can't IPI an IOMMU or a GPU ;)

Oh, right you are. I suppose that is why x86-iommu is using those mmu_notifiers.

Re: [PATCH 2/4] tty: Hold tty_ldisc_lock() during tty_reopen()

[Jiri Slaby]

On 08/31/2018, 01:17 PM, Tetsuo Handa wrote:
> Also, noisy messages like
> 
>   pts pts4033: tty_release: tty->count(10529) != (#fd's(7) + #kopen's(0))
> 
> are gone.

fwiw, thanks to 1/4…

Dmitry, could you note the message above to the commit log of 1/4, so
that we know the patch fixed that and downstream can pick it up...

-- 
js
suse labs

Re: [PATCH v13 09/13] x86/sgx: Enclave Page Cache (EPC) memory manager

[Jarkko Sakkinen]

On Tue, Aug 28, 2018 at 02:22:44PM -0700, Sean Christopherson wrote:
> On Tue, Aug 28, 2018 at 07:07:33AM -0700, Dave Hansen wrote:
> > On 08/28/2018 01:35 AM, Jarkko Sakkinen wrote:
> > > On Mon, Aug 27, 2018 at 02:15:34PM -0700, Dave Hansen wrote:
> > >> On 08/27/2018 11:53 AM, Jarkko Sakkinen wrote:
> > >>> +struct sgx_epc_page_ops {
> > >>> +   bool (*get)(struct sgx_epc_page *epc_page);
> > >>> +   void (*put)(struct sgx_epc_page *epc_page);
> > >>> +   bool (*reclaim)(struct sgx_epc_page *epc_page);
> > >>> +   void (*block)(struct sgx_epc_page *epc_page);
> > >>> +   void (*write)(struct sgx_epc_page *epc_page);
> > >>> +};
> > >> Why do we need a fancy, slow (retpoline'd) set of function pointers when
> > >> we only have one user of these (the SGX driver)?
> > > KVM has its own implementation for these operations.
> > 
> > That belongs in the changelog.
> > 
> > Also, where is the implementation?  How can we assess this code that was
> > built to create an abstraction without both of the users?
> 
> I can provide an early preview of the KVM reclaim code, but honestly
> I think that would do more harm than good.  The VMX architecture for
> EPC reclaim is complex, even for SGX standards.  Opening that can of
> worms would likely derail this discussion.  That being said, this
> abstraction isn't exactly what KVM will need, but it's pretty close
> and gives us something to build on.
> 
> Regardless, this layer of indirection is justifiable even with a
> single implementation.  Reclaiming an EPC page is not a simple matter
> of copying the data somewhere else and marking the page not present.
> Actual eviction requires a reference to the Secure Enclave Control
> Structure (SECS) of the enclave that owns the page.  Software needs
> to ensure it doesn't violate the hardware-enforced access rules, e.g.
> most reclaim activites need to be done under a per-enclave lock.
> Not all pages have the same reclaim rules, e.g. an SECS can only
> be reclaimed after all its child pages have reclaimed, a VA page
> doesn't need to be blocked, etc...  And the list goes on...

To simplify a bit what Sean said about the key difference to a standard
page is that in SGX a page is part of a hierarchical structure. EPC
pages have hardware enforced dependencies to each other.

Examples: 

1. You cannot delete or swap SECS before its children have been deleted or
   swapped. You get SGX_CHILD_PRESENT erro from EREMOVE.
2. In order to swap or fault a page you need to have an EPC page that
   holds a version number for the page you want to swap. These are
   called Version Array (VA) pages.

/Jarkko

Re: [PATCH] x86, mm: Reserver some memory for bootmem allocator for NO_BOOTMEM

[Thomas Gleixner]

On Fri, 31 Aug 2018, Feng Tang wrote:
> On Thu, Aug 30, 2018 at 03:25:42PM +0200, Thomas Gleixner wrote:
> This panic happens as the earlycon's fixmap address has no
> pmd/pte ready, and __set_fixmap will try to allocate memory to
> setup the page table, and trigger panic due to no memory.
> 
> x86 kernel actually prepares the page table for fixmap in head_64.S:
> 
>   NEXT_PAGE(level2_fixmap_pgt)
>   .fill   506,8,0
>   .quad   level1_fixmap_pgt - __START_KERNEL_map + 
> _PAGE_TABLE_NOENC
>   /* 8MB reserved for vsyscalls + a 2MB hole = 4 + 1 entries */
>   .fill   5,8,0
> 
> and it expects the fixmap address is in [-12M, -10M] range, but
> current code in fixmap.h will break the expectation when
> X86_VSYSCALL_EMULATION=n
> 
>   #ifdef CONFIG_X86_VSYSCALL_EMULATION
>   VSYSCALL_PAGE = (FIXADDR_TOP - VSYSCALL_ADDR) >> PAGE_SHIFT,
>   #endif
> 
> So removing the "#ifdef" will make the fixmap address space stable in
> [-12M, -10M] and fix the issue.

Why on earth are you not fixing the damned PTE setup which is the obvious
and correct thing to do?

Thanks,

tglx

Re: [PATCH 1/7] spi: add slave device size in spi_device struct

[Geert Uytterhoeven]

Hi Yogesh,

Thanks for your patch!

On Fri, Aug 31, 2018 at 12:33 PM Yogesh Gaur  wrote:
> Add 'size' data variable in spi_device struct.
> This is to save the size of the connected slave device.

What is the "size" of an SPI slave device?

> After slave device scan, spi_nor_scan, size being assigned to this
> from MTD layer.

Ah, this is MTD specific?

> SFDP read is being requested before completion of spi_nor_scan()
> routine, thus populate device size before making read request
> to the SPI controller.
>
> Signed-off-by: Yogesh Gaur 

> --- a/include/linux/spi/spi.h
> +++ b/include/linux/spi/spi.h
> @@ -127,6 +127,7 @@ void spi_statistics_add_transfer_stats(struct 
> spi_statistics *stats,
>   * for driver coldplugging, and in uevents used for hotplugging
>   * @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when
>   * not using a GPIO line)
> + * @size: size of the connected slave device

Please document what is the meaning of "size".

>   *
>   * @statistics: statistics for the spi_device
>   *
> @@ -168,6 +169,7 @@ struct spi_device {
> void*controller_data;
> charmodalias[SPI_NAME_SIZE];
> int cs_gpio;/* chip select gpio */
> +   u32 size;   /* size of slave device */
>
> /* the statistics */
> struct spi_statistics   statistics;

Gr{oetje,eeting}s,

Geert

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

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

[PATCH] spi: dw-mmio: avoid hardcoded field mask

[Alexandre Belloni]

Define a mask for the IF_SI_OWNER field.

Signed-off-by: Alexandre Belloni 
---
 drivers/spi/spi-dw-mmio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
index 351f49976161..a768461614a0 100644
--- a/drivers/spi/spi-dw-mmio.c
+++ b/drivers/spi/spi-dw-mmio.c
@@ -36,6 +36,7 @@ struct dw_spi_mmio {
 #define MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL  0x24
 #define OCELOT_IF_SI_OWNER_OFFSET  4
 #define JAGUAR2_IF_SI_OWNER_OFFSET 6
+#define MSCC_IF_SI_OWNER_MASK  GENMASK(1, 0)
 #define MSCC_IF_SI_OWNER_SISL  0
 #define MSCC_IF_SI_OWNER_SIBM  1
 #define MSCC_IF_SI_OWNER_SIMC  2
@@ -102,7 +103,7 @@ static int dw_spi_mscc_init(struct platform_device *pdev,
 
/* Select the owner of the SI interface */
regmap_update_bits(dwsmscc->syscon, MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL,
-  0x3 << if_si_owner_offset,
+  MSCC_IF_SI_OWNER_MASK << if_si_owner_offset,
   MSCC_IF_SI_OWNER_SIMC << if_si_owner_offset);
 
dwsmmio->dws.set_cs = dw_spi_mscc_set_cs;
-- 
2.19.0.rc1

Re: [PATCH 00/12] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

[Nicholas Piggin]

On Fri, 31 Aug 2018 12:49:45 +0200
Peter Zijlstra  wrote:

> On Fri, Aug 31, 2018 at 08:32:34PM +1000, Nicholas Piggin wrote:
> > Oh gee, I suppose. powerpc hash is kind of interesting because it's
> > crazy, Aneesh knows that code a lot better than I do. radix modulo
> > some minor details of exact instructions is fairly like x86   
> 
> The whole TLB broadcast vs explicit IPIs is a fairly big difference in
> my book.

That's true I guess. Maybe arm64 is closer.

> Anyway, have you guys tried the explicit IPI approach? Depending on how
> IPIs are routed vs broadcasts it might save a little bus traffic. No
> point in getting all CPUs to process the TLBI when there's only a hand
> full that really need it.

It has been looked at now and again there's a lot of variables to
weigh. And things are also sized and speced to cover various
hypervisors, OSes, hash and radix, etc. This is something we need to
evaluate on radix a bit better.

> 
> OTOH, I suppose the broadcast thing has been optimized to death on the
> hardware side, so who knows..

There are some advantages of doing it in hardware. Also some of doing
IPIs though. The "problem" is actually Linux is well optimised and it
can be hard to notice much impact until you get to big systems. At
least I don't know of any problem workloads outside micro benchmarks or
stress tests.

Thanks,
Nick

Re: [PATCH] spi: dw-mmio: avoid hardcoded field mask

[Andy Shevchenko]

On Fri, Aug 31, 2018 at 01:40:46PM +0200, Alexandre Belloni wrote:
> Define a mask for the IF_SI_OWNER field.
> 

Thanks!

Acked-by: Andy Shevchenko 

> Signed-off-by: Alexandre Belloni 
> ---
>  drivers/spi/spi-dw-mmio.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-dw-mmio.c b/drivers/spi/spi-dw-mmio.c
> index 351f49976161..a768461614a0 100644
> --- a/drivers/spi/spi-dw-mmio.c
> +++ b/drivers/spi/spi-dw-mmio.c
> @@ -36,6 +36,7 @@ struct dw_spi_mmio {
>  #define MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL0x24
>  #define OCELOT_IF_SI_OWNER_OFFSET4
>  #define JAGUAR2_IF_SI_OWNER_OFFSET   6
> +#define MSCC_IF_SI_OWNER_MASKGENMASK(1, 0)
>  #define MSCC_IF_SI_OWNER_SISL0
>  #define MSCC_IF_SI_OWNER_SIBM1
>  #define MSCC_IF_SI_OWNER_SIMC2
> @@ -102,7 +103,7 @@ static int dw_spi_mscc_init(struct platform_device *pdev,
>  
>   /* Select the owner of the SI interface */
>   regmap_update_bits(dwsmscc->syscon, MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL,
> -0x3 << if_si_owner_offset,
> +MSCC_IF_SI_OWNER_MASK << if_si_owner_offset,
>  MSCC_IF_SI_OWNER_SIMC << if_si_owner_offset);
>  
>   dwsmmio->dws.set_cs = dw_spi_mscc_set_cs;
> -- 
> 2.19.0.rc1
> 

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 1/4] tty: Drop tty->count on tty_reopen() failure

[Dmitry Safonov]

On Fri, 2018-08-31 at 08:47 +0200, Jiri Slaby wrote:
> On 08/29/2018, 06:13 PM, Dmitry Safonov wrote:
> > > I would just do:
> > >   if (!retval)
> > > tty->count++;
> > > here. Nobody from ldiscs should rely on tty->count.
> > 
> > I thought about that and probably should have described in commit
> > message why I haven't done that: I prefer to keep it as was as I
> > did Cc
> > stable tree - to keep the chance of regression to minimum.
> > 
> > I agree that your way is cleaner, but probably it may be done as
> > cleanup on top for linux-next..
> 
> Agreed, so care to cook it up as 5/4 in this series :)?

Sure, will resend v2 with that and all tested-by.

-- 
Thanks,
 Dmitry