Re: Question about ->head field of rcu_segcblist

[Joel Fernandes]

On Sun, Sep 23, 2018 at 7:54 PM Paul E. McKenney  wrote:
>
> On Sun, Sep 23, 2018 at 07:30:30PM -0400, Joel Fernandes wrote:
> > Hi Paul,
> >
> > I was parsing the Data-Structures document and had a question about
> > the following "Important note" text.
> >
> > Could it be clarified in the below text better why "remaining
> > callbacks are placed back on the RCU_DONE_TAIL segment", is a reason
> > for not depending on ->head for determining if no callbacks are
> > associated with the rcu_segcblist? If callbacks are added back to the
> > DONE_TAIL segment, then I would think rcu_head should be != NULL.
> > Infact the "rsclp->head = *rsclp->tails[RCU_DONE_TAIL];" in
> > rcu_segcblist_extract_done_cbs should set the ->head to  NULL if I
> > understand correctly.
>
> The rcu_segcblist_extract_done_cbs() function will set rsclp->head
> to NULL only if there were no non-done callbacks on the rsclp list.
> Otherwise, if there are non-done callbacks, then rsclp->head will
> be set to the first non-done callback.
>
> Either way, the problem is that the done callbacks can be removed
> and re-added, but the count is not adjusted until the re-add.  So
> you have to look at the count to see if there are callbacks.
>
> Testing rsclp->head fails because it can be temporarily NULL, even
> though there are callbacks hanging off of a pointer in rcu_do_batch()'s
> stack frame.
>
> Or am I misunderstanding your question?

Thanks yes that clears it up, I see what you mean that that ->head
field is temporarily volatile and really the ->len tells the real
story :-)

- Joel

linux-next: manual merge of the staging tree with the jc_docs tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  Documentation/filesystems/00-INDEX

between commit:

  a7ddcea58ae2 ("Drop all 00-INDEX files from Documentation/")

from the jc_docs tree and commit:

  a779df303b05 ("Documentation: filesystems: remove reminiscences of POHMELFS")

from the staging tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpwkHufgWApj.pgp
Description: OpenPGP digital signature

Late UN Sec General Kofi Annan

[Late Kofi Annan]

Dear Well Wishers,
Greetings to all of you and we Thank you, who have work with my late brother 
before in various capacities during his term as the UN Sec General and after, 
once again on behalf of the entire family of Late Kofi Annan, we thank you all 
for all the support and comfort you show to our family during his funeral 
ceremony,we Thank you all and may God bless you all.

I shall be oblige to help you out in any way i can for those of you who still 
have his pending transaction or business with him, am now the head of the 
family with all legal right handed over to me as African traditions demands, i 
shall be in position to help and build further more good relationship as i look 
towards to welcome you home ,

On Behalf of the entire Kofi Annan's Family(Former UN Sec General) we say thank 
you to you all in this time of  our  grievance and tears  

Regards,
Kweku Anna(For the Family)
For the family estate
Accra-Ghana
+233260742368

linux-next: manual merge of the userns tree with the tip tree

[Stephen Rothwell]

Hi Eric,

Today's linux-next merge of the userns tree got a conflict in:

  arch/x86/kernel/traps.c

between commits:

  76dee4a72849 ("x86/kprobes: Inline kprobe_exceptions_notify() into 
do_general_protection()")
  81fd9c18444e ("x86/fault: Plumb error code and fault address through to fault 
handlers")

from the tip tree and commits:

  6ace1098a68c ("signal/x86/traps: Factor out show_signal")
  79e21d654093 ("signal/x86/traps: Move more code into do_trap_no_signal so it 
can be reused")

from the userns tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kernel/traps.c
index 5bd0a997d81e,34a327f35976..
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@@ -202,11 -202,8 +202,8 @@@ do_trap_no_signal(struct task_struct *t
error_code, trapnr))
return 0;
}
-   return -1;
-   }
- 
-   if (!user_mode(regs)) {
+   } else if (!user_mode(regs)) {
 -  if (fixup_exception(regs, trapnr))
 +  if (fixup_exception(regs, trapnr, error_code, 0))
return 0;
  
tsk->thread.error_code = error_code;
@@@ -560,19 -540,9 +544,19 @@@ do_general_protection(struct pt_regs *r
  
tsk->thread.error_code = error_code;
tsk->thread.trap_nr = X86_TRAP_GP;
 +
 +  /*
 +   * To be potentially processing a kprobe fault and to
 +   * trust the result from kprobe_running(), we have to
 +   * be non-preemptible.
 +   */
 +  if (!preemptible() && kprobe_running() &&
 +  kprobe_fault_handler(regs, X86_TRAP_GP))
 +  return;
 +
-   if (notify_die(DIE_GPF, "general protection fault", regs, 
error_code,
+   if (notify_die(DIE_GPF, desc, regs, error_code,
   X86_TRAP_GP, SIGSEGV) != NOTIFY_STOP)
-   die("general protection fault", regs, error_code);
+   die(desc, regs, error_code);
return;
}
  


pgppLdWNwHt8A.pgp
Description: OpenPGP digital signature

Re: linux-next: Tree for Sep 20

[Michael Ellerman]

Rob Herring  writes:
> On Thu, Sep 20, 2018 at 4:18 AM Stephen Rothwell  
> wrote:
>> On Thu, 20 Sep 2018 21:10:08 +1000 Stephen Rothwell  
>> wrote:
>> > On Thu, 20 Sep 2018 20:37:37 +1000 Michael Ellerman  
>> > wrote:
>> > > Oodles of:
>> > >
>> > >   # < make -s -j 48 ARCH=arm64 
>> > > O=/kisskb/build/linux-next_arm64-allnoconfig_arm64 
>> > > CROSS_COMPILE=/opt/cross/kisskb/br-aarch64-glibc-2016.08-613-ge98b4dd/bin/aarch64-linux-
>> > >   allnoconfig
>> > >   # make -s -j 48 ARCH=arm64 
>> > > O=/kisskb/build/linux-next_arm64-allnoconfig_arm64 
>> > > CROSS_COMPILE=/opt/cross/kisskb/br-aarch64-glibc-2016.08-613-ge98b4dd/bin/aarch64-linux-
>> > >   /bin/sh: 1: pkg-config: not found
>>   ^^^
>>
>> > don't have it installed on my build machine either ...  do we have
>> > pkg-config installed in the build images?
>>
>> Duh! ;-)
>>
>> According to the commit message we gained a kconfig dependency on
>> pkg-config in 4.18.  I wonder what else depends on it.
>>
>> Ah:
>>
>> "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 {g,x}config'.  Previously pkg-config was being used but not
>> verified or documented."
>
> Looks like until a recent commit, this also included nconfig and
> menuconfig, but those were dropped after some complaints. I'll rework
> this to make things work with pkg-config.

OK thanks.

I'll install pkg-config in the kisskb builders anyway, so in future at
least that part will work.

cheers

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

[Tom Talpey]

On 9/23/2018 2:24 PM, Stefan Metzmacher wrote:

Hi Tom,


I just tested that setting:

mr->iova &= (PAGE_SIZE - 1);
mr->iova |= 0x;

after the ib_map_mr_sg() and before doing the IB_WR_REG_MR, seems to
work.


Good! As you know, we were concerned about it after seeing that
the ib_dma_map_sg() code was unconditionally setting it to the
dma_mapped address. By salting those 's with varying data,
this should give your FRWR regions stronger integrity in addition
to not leaking kernel "addresses" to the wire.


Just wondering... Isn't the thing we use called FRMR?


They're basically the same concept, it's a subtle difference.

FRMR = Fast Register Memory Region
FRWR = Fast Register Work Request

The memory region is the mr itself, this is created early on.

The work request is built when actually binding the physical
pages to the region, and setting the offset, length, etc, which
is what's happening in the routine that I made the comment on.

So, for this discussion I chose to say FRWR. Sorry for any
confusion!

Tom.

Re: [Patch v7 21/22] CIFS: SMBD: Upper layer performs SMB read via RDMA write through memory registration

[Stefan Metzmacher]

> They're basically the same concept, it's a subtle difference.
> 
> FRMR = Fast Register Memory Region
> FRWR = Fast Register Work Request
> 
> The memory region is the mr itself, this is created early on.
> 
> The work request is built when actually binding the physical
> pages to the region, and setting the offset, length, etc, which
> is what's happening in the routine that I made the comment on.
> 
> So, for this discussion I chose to say FRWR. Sorry for any
> confusion!

Ah, thanks! Confusion resolved:-)

metze




signature.asc
Description: OpenPGP digital signature

[PATCH 2/2] clocksource: Remove obsolete CLOCKSOURCE_OF_DECLARE

[Daniel Lezcano]

The macro CLOCKSOURCE_OF_DECLARE was renamed more TIMER_OF_DECLARE, and we
kept an alias CLOCKSOURCE_OF_DECLARE in order to smooth the transition for
drivers.

This change was done 1.5 year ago, we can reasonably remove this backward
compatible macro as it is no longer used anywhere.

Signed-off-by: Daniel Lezcano 
---
 include/linux/clocksource.h | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index 3089189..4c58c1e 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -257,9 +257,6 @@ extern int clocksource_i8253_init(void);
 #define TIMER_OF_DECLARE(name, compat, fn) \
OF_DECLARE_1_RET(timer, name, compat, fn)
 
-#define CLOCKSOURCE_OF_DECLARE(name, compat, fn) \
-   TIMER_OF_DECLARE(name, compat, fn)
-
 #ifdef CONFIG_TIMER_PROBE
 extern void timer_probe(void);
 #else
-- 
2.7.4

[PATCH] Driver core: add bus_find_device_by_fwnode

[Silesh C V]

Some drivers need to find the device on a bus having a specific firmware
node. Currently, such drivers have their own implementations to do this.
Provide a helper similar to bus_find_device_by_name so that each driver
does not have to reinvent this.

Signed-off-by: Silesh C V 
---
 drivers/base/bus.c | 26 ++
 include/linux/device.h |  3 +++
 2 files changed, 29 insertions(+)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 8bfd27e..148b198 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "base.h"
 #include "power/power.h"
 
@@ -373,6 +374,31 @@ struct device *bus_find_device_by_name(struct bus_type 
*bus,
 }
 EXPORT_SYMBOL_GPL(bus_find_device_by_name);
 
+static int match_fwnode(struct device *dev, void *data)
+{
+   struct fwnode_handle *fwnode = data;
+   struct device_node *of_node = to_of_node(fwnode);
+
+   if (of_node)
+   return dev->of_node == of_node;
+   else
+   return dev->fwnode == fwnode;
+}
+
+/**
+ * bus_find_device_by_fwnode - device iterator for locating a particular device
+ * having a specific firmware node
+ * @bus: bus type
+ * @start: Device to begin with
+ * @fwnode: firmware node of the device to match
+ */
+struct device *bus_find_device_by_fwnode(struct bus_type *bus, struct device 
*start,
+   struct fwnode_handle *fwnode)
+{
+   return bus_find_device(bus, start, (void *)fwnode, match_fwnode);
+}
+EXPORT_SYMBOL_GPL(bus_find_device_by_fwnode);
+
 /**
  * subsys_find_device_by_id - find a device with a specific enumeration number
  * @subsys: subsystem
diff --git a/include/linux/device.h b/include/linux/device.h
index 8f88254..09384f6 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -171,6 +171,9 @@ struct device *bus_find_device(struct bus_type *bus, struct 
device *start,
 struct device *bus_find_device_by_name(struct bus_type *bus,
   struct device *start,
   const char *name);
+struct device *bus_find_device_by_fwnode(struct bus_type *bus,
+  struct device *start,
+  struct fwnode_handle *fwnode);
 struct device *subsys_find_device_by_id(struct bus_type *bus, unsigned int id,
struct device *hint);
 int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
-- 
1.9.1

linux-next: manual merge of the akpm-current tree with the arm64 tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the akpm-current tree got a conflict in:

  arch/arm64/Kconfig

between commit:

  8a695a587333 ("arm64: Kconfig: Remove ARCH_HAS_HOLES_MEMORYMODEL")

from the arm64 tree and commit:

  e1405baa7db1 ("arm: arm64: introduce CONFIG_HAVE_MEMBLOCK_PFN_VALID")

from the akpm-current tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/Kconfig
index da5e6f085561,f8a618a292f4..
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -785,7 -786,8 +785,8 @@@ config ARCH_FLATMEM_ENABL
def_bool !NUMA
  
  config HAVE_ARCH_PFN_VALID
 -  def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
 +  def_bool y
+   select HAVE_MEMBLOCK_PFN_VALID
  
  config HW_PERF_EVENTS
def_bool y


pgpvTx_q_9iGK.pgp
Description: OpenPGP digital signature

[PATCH] MAINTAINERS: Set ARM/LPC18XX architecture orphan

[Daniel Lezcano]

While sending patches around, Joachim Eastwood was Cc'ed but I got an error
its mailbox was full and the mail can not be delivered which makes me think
there is no body at the other end of the line.

After doing some statistics, it appears the latest commit as author/commiter
is:

commit b16ebc017ebf52a81e5e88743ccd68fc25e99ba9
Author: Joachim Eastwood 
Date:   Mon Oct 31 14:45:17 2016 +

Remove the maintainer entry and set the component as orphan.

Signed-off-by: Daniel Lezcano 
Cc: Arnd Bergmann 
---
 MAINTAINERS | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 67e877c..f3612f6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1599,9 +1599,8 @@ L:linux-arm-ker...@lists.infradead.org (moderated 
for non-subscribers)
 S: Maintained
 
 ARM/LPC18XX ARCHITECTURE
-M: Joachim Eastwood 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-S: Maintained
+S: Orphan
 F: arch/arm/boot/dts/lpc43*
 F: drivers/clk/nxp/clk-lpc18xx*
 F: drivers/clocksource/timer-lpc32xx.c
-- 
2.7.4

Re: linux-next: manual merge of the staging tree with the jc_docs tree

[Greg KH]

On Mon, Sep 24, 2018 at 12:50:16PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   Documentation/filesystems/00-INDEX
> 
> between commit:
> 
>   a7ddcea58ae2 ("Drop all 00-INDEX files from Documentation/")
> 
> from the jc_docs tree and commit:
> 
>   a779df303b05 ("Documentation: filesystems: remove reminiscences of 
> POHMELFS")
> 
> from the staging tree.
> 
> I fixed it up (I just removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Resolution looks good, thanks!

greg k-h

Re: [PATCH] Driver core: add bus_find_device_by_fwnode

[Greg Kroah-Hartman]

On Mon, Sep 24, 2018 at 10:05:55AM +0530, Silesh C V wrote:
> Some drivers need to find the device on a bus having a specific firmware
> node. Currently, such drivers have their own implementations to do this.
> Provide a helper similar to bus_find_device_by_name so that each driver
> does not have to reinvent this.

Is there a second patch that uses this function?  We don't add api calls
that are not used.

thanks,

greg k-h

linux-next: Tree for Sep 24

[Stephen Rothwell]

Hi all,

Changes since 20180921:

Dropped trees: xarray, ida (temporarily)

The bpf-next tree gained a conflict against Linus' tree.

The staging tree gained a conflict against the jc_docs tree.

The userns tree gained conflicts against the tip tree.

The akpm-current tree gained a conflict against the arm64 tree.

Non-merge commits (relative to Linus' tree): 5393
 5906 files changed, 269070 insertions(+), 117973 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 288 trees (counting Linus' and 66 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (6bf4ca7fbc85 Linux 4.19-rc5)
Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of 
Linus' tree)
Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain 
not in Clang search path)
Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE 
in arch's Makefile)
Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return 
for binutils 2.29+)
Merging arm64-fixes/for-next/fixes (500dd232449e asm-generic: io: Fix 
ioport_map() for !CONFIG_GENERIC_IOMAP && CONFIG_INDIRECT_PIO)
Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response 
format)
Merging powerpc-fixes/fixes (c716a25b9b70 powerpc/pkeys: Fix reading of ibm, 
processor-storage-keys property)
Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (16fdf8ba9839 rds: Fix build regression.)
Merging bpf/master (fad0c40fab14 Merge branch 'bpf-sockmap-estab-fixes')
Merging ipsec/master (9e1437937807 xfrm: Fix NULL pointer dereference when 
skb_dst_force clears the dst_entry.)
Merging netfilter/master (346fa83d1093 netfilter: conntrack: get rid of double 
sizeof)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (2823c8716c68 b43: fix DMA error related 
regression with proprietary firmware)
Merging mac80211/master (c42055105785 mac80211: fix TX status reporting for 
ieee80211s)
Merging rdma-fixes/for-rc (b4a4957d3d1c IB/hfi1: Fix destroy_qp hang after a 
link down)
Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the 
audio-component completion timeout)
Merging sound-asoc-fixes/for-linus (85adbf9815ab Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4)
Merging regulator-fixes/for-linus (69a3f680261f Merge branch 'regulator-4.19' 
into regulator-linus)
Merging spi-fixes/for-linus (1f6b3b2c1ff4 Merge branch 'spi-4.19' into 
spi-linus)
Merging pci-current/for-linus (9024143e700f PCI: dwc: Fix scheduling while 
atomic issues)
Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4)
Merging tty.current/tty-linus (7e620984b625 serial: imx: restore handshaking 
irq for imx1)
Merging usb.current/usb-linus (3e3b81965cbf usb: typec: mux: Take care of 
driver module reference counting)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (35aecc02b5b6 USB: serial: option: add 
two-endpoints device-id flag)
Merging usb-chipi

[GIT PULL] clocksource fixes for 4.19-rc

[Daniel Lezcano]

Thomas, Ingo,

This pull request for clockevents / clocksource contains two fixes and
is based on tip/timers/urgent:

 - Add the CLOCK_SOURCE_SUSPEND_NONSTOP for non-am43 SoCs (Keerthy)

 - Fix set_next_event handler for the fttmr010 (Tao Ren)


Thanks !

  -- Daniel


The following changes since commit e2c631ba75a7e727e8db0a9d30a06bfd434adb3a:

  clocksource: Revert "Remove kthread" (2018-09-06 23:38:35 +0200)

are available in the git repository at:

  https://git.linaro.org/people/daniel.lezcano/linux.git
clockevents/4.19-fixes

for you to fetch changes up to 4451d3f59f2a6f95e5d205c2d04ea072955d080d:

  clocksource/drivers/fttmr010: Fix set_next_event handler (2018-09-24
06:13:31 +0200)


Keerthy (1):
  clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag
for non-am43 SoCs

Tao Ren (1):
  clocksource/drivers/fttmr010: Fix set_next_event handler

 drivers/clocksource/timer-fttmr010.c | 18 +++---
 drivers/clocksource/timer-ti-32k.c   |  3 +++
 2 files changed, 14 insertions(+), 7 deletions(-)




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

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH 2/2] clocksource/drivers/fttmr010: Fix set_next_event handler

[Daniel Lezcano]

From: Tao Ren 

Currently, the aspeed MATCH1 register is updated to  in set_next_event handler, with the assumption that COUNT
register value is preserved when the timer is disabled and it continues
decrementing after the timer is enabled. But the assumption is wrong:
RELOAD register is loaded into COUNT register when the aspeed timer is
enabled, which means the next event may be delayed because timer
interrupt won't be generated until <0x - current_count +
cycles>.

The problem can be fixed by updating RELOAD register to , and
COUNT register will be re-loaded when the timer is enabled and interrupt
is generated when COUNT register overflows.

The test result on Facebook Backpack-CMM BMC hardware (AST2500) shows
the issue is fixed: without the patch, usleep(100) suspends the process
for several milliseconds (and sometimes even over 40 milliseconds);
after applying the fix, usleep(100) takes averagely 240 microseconds to
return under the same workload level.

Signed-off-by: Tao Ren 
Reviewed-by: Linus Walleij 
Tested-by: Lei YU 
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/timer-fttmr010.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/clocksource/timer-fttmr010.c 
b/drivers/clocksource/timer-fttmr010.c
index c020038..cf93f64 100644
--- a/drivers/clocksource/timer-fttmr010.c
+++ b/drivers/clocksource/timer-fttmr010.c
@@ -130,13 +130,17 @@ static int fttmr010_timer_set_next_event(unsigned long 
cycles,
cr &= ~fttmr010->t1_enable_val;
writel(cr, fttmr010->base + TIMER_CR);
 
-   /* Setup the match register forward/backward in time */
-   cr = readl(fttmr010->base + TIMER1_COUNT);
-   if (fttmr010->count_down)
-   cr -= cycles;
-   else
-   cr += cycles;
-   writel(cr, fttmr010->base + TIMER1_MATCH1);
+   if (fttmr010->count_down) {
+   /*
+* ASPEED Timer Controller will load TIMER1_LOAD register
+* into TIMER1_COUNT register when the timer is re-enabled.
+*/
+   writel(cycles, fttmr010->base + TIMER1_LOAD);
+   } else {
+   /* Setup the match register forward in time */
+   cr = readl(fttmr010->base + TIMER1_COUNT);
+   writel(cr + cycles, fttmr010->base + TIMER1_MATCH1);
+   }
 
/* Start */
cr = readl(fttmr010->base + TIMER_CR);
-- 
2.7.4

[PATCH 1/2] clocksource/drivers/ti-32k: Add CLOCK_SOURCE_SUSPEND_NONSTOP flag for non-am43 SoCs

[Daniel Lezcano]

From: Keerthy 

The 32k clocksource is NONSTOP for non-am43 SoCs. Hence
add the flag for all the other SoCs.

Reported-by: Tony Lindgren 
Signed-off-by: Keerthy 
Acked-by: Tony Lindgren 
Signed-off-by: Daniel Lezcano 
---
 drivers/clocksource/timer-ti-32k.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clocksource/timer-ti-32k.c 
b/drivers/clocksource/timer-ti-32k.c
index 29e2e1a..6949a91 100644
--- a/drivers/clocksource/timer-ti-32k.c
+++ b/drivers/clocksource/timer-ti-32k.c
@@ -97,6 +97,9 @@ static int __init ti_32k_timer_init(struct device_node *np)
return -ENXIO;
}
 
+   if (!of_machine_is_compatible("ti,am43"))
+   ti_32k_timer.cs.flags |= CLOCK_SOURCE_SUSPEND_NONSTOP;
+
ti_32k_timer.counter = ti_32k_timer.base;
 
/*
-- 
2.7.4

Re: AMD Athlon bogus performance value causing RCU stalls?

[Thomas Gleixner]

On Sun, 23 Sep 2018, Rob Prowel wrote:
> On 09/23/18 17:19, Thomas Gleixner wrote:
> > It's in the 4.18.8 stable kernel, which should be available from your
> > fedora repo anytime soon.
> > 
> Will check with the newer kernel when it's available but please do double
> check if this problem might exist on 64 bit architectures as well...and
> of course I'm interested to know whether it is the likely cuprit of my
> RCU problem.

No that thing does not affect 64bit for sure. Can you please provide me a
full dmesg from that machine?

Thanks,

tglx

Re: [PATCH 1/2] iio: adc: at91: fix acking DRDY irq on simple conversions

[Eugen Hristev]

On 22.09.2018 13:31, Jonathan Cameron wrote:

On Thu, 20 Sep 2018 15:40:37 +0300
Eugen Hristev  wrote:


When doing simple conversions, the driver did not acknowledge the DRDY irq.
If this irq is not acked, it will be left pending, and as soon as a trigger
is enabled, the irq handler will be called, it doesn't know why this irq
has occurred because no channel is pending, and then we will have irq loop
and board will hang.

Fixes 0e589d5fb ("ARM: AT91: IIO: Add AT91 ADC driver.")
Cc: Maxime Ripard 
Cc: 
Signed-off-by: Eugen Hristev 
---
  drivers/iio/adc/at91_adc.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 44b5168..e85f859 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -712,6 +712,11 @@ static int at91_adc_read_raw(struct iio_dev *idev,
at91_adc_writel(st, AT91_ADC_CHDR,
AT91_ADC_CH(chan->channel));
at91_adc_writel(st, AT91_ADC_IDR, BIT(chan->channel));
+   /*
+* we need to ack the DRDY irq, otherwise it will be
+* left pending and irq handler will be confused
+*/
+   at91_adc_readl(st, AT91_ADC_LCDR);


I'm curious as to how things were working before.  Does this only occur
if we do a raw_read whilst the buffer is enabled?


No. The situation is that the read raw does not properly cleans itself 
up after it's done.

The DRDY bit is cleared only when LCDR (last converted data ) is being read.
Even if we read the per channel conversion data, the LCDR still needs to 
be read to clear this irq status.
The driver does not use the DRDY irq but this irq status is still being 
set in the status register.




I would have assumed when it's not enabled, the irq would be masked and
never generated in the first place...

It may be that what we actually need to do is to prevent read_raw accesses
when the buffer is enabled (like lots of other drivers do precisely to
avoid this sort of condition). The problem there comes if we have
existing applications doing this combination as we are then breaking
userspace. If that's the case we'll need to be a bit more clever.

Hammering down an irq state in a non irq handling path isn't a good
solution.


Ok, I will move the clearing of the DRDY (LCDR read) in the irq path 
then, and send a v2.





Jonathan

  
  		st->last_value = 0;

st->done = false;

Re: [PATCH 1/2] clocksource/drivers: Unify the names to timer-* format

[Uwe Kleine-König]

On Mon, Sep 24, 2018 at 06:15:17AM +0200, Daniel Lezcano wrote:
> In order to make some housekeeping in the directory, this patch renames
> drivers to the timer-* format in order to unify their names.
> 
> There is no functional changes.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  MAINTAINERS   |  10 +-
>  drivers/clocksource/Makefile  |  26 +-
>  drivers/clocksource/cadence_ttc_timer.c   | 543 
> --
>  drivers/clocksource/fsl_ftm_timer.c   | 376 -
>  drivers/clocksource/owl-timer.c   | 173 --
>  drivers/clocksource/qcom-timer.c  | 258 --
>  drivers/clocksource/time-armada-370-xp.c  | 416 ---
>  drivers/clocksource/time-efm32.c  | 287 
>  drivers/clocksource/time-lpc32xx.c| 314 -
>  drivers/clocksource/time-orion.c  | 192 ---
>  drivers/clocksource/time-pistachio.c  | 218 
>  drivers/clocksource/timer-armada-370-xp.c | 416 +++
>  drivers/clocksource/timer-cadence-ttc.c   | 543 
> ++
>  drivers/clocksource/timer-efm32.c | 287 
>  drivers/clocksource/timer-fsl-ftm.c   | 376 +
>  drivers/clocksource/timer-lpc32xx.c   | 314 +
>  drivers/clocksource/timer-orion.c | 192 +++
>  drivers/clocksource/timer-owl.c   | 173 ++
>  drivers/clocksource/timer-pistachio.c | 218 
>  drivers/clocksource/timer-qcom.c  | 258 ++
>  drivers/clocksource/timer-versatile.c |  44 +++
>  drivers/clocksource/timer-vf-pit.c| 204 +++
>  drivers/clocksource/timer-vt8500.c| 168 +
>  drivers/clocksource/timer-zevio.c | 218 
>  drivers/clocksource/versatile.c   |  44 ---
>  drivers/clocksource/vf_pit_timer.c| 204 ---
>  drivers/clocksource/vt8500_timer.c| 168 -
>  drivers/clocksource/zevio-timer.c | 218 
>  28 files changed, 3429 insertions(+), 3429 deletions(-)

Wow, with git format-patch -M this should look much smaller and so
easier to review.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

Re: [PATCH 1/2] clocksource/drivers: Unify the names to timer-* format

[Daniel Lezcano]

On 24/09/2018 08:28, Uwe Kleine-König wrote:
> On Mon, Sep 24, 2018 at 06:15:17AM +0200, Daniel Lezcano wrote:
>> In order to make some housekeeping in the directory, this patch renames
>> drivers to the timer-* format in order to unify their names.
>>
>> There is no functional changes.
>>
>> Signed-off-by: Daniel Lezcano 
>> ---
>>  MAINTAINERS   |  10 +-
>>  drivers/clocksource/Makefile  |  26 +-
>>  drivers/clocksource/cadence_ttc_timer.c   | 543 
>> --
>>  drivers/clocksource/fsl_ftm_timer.c   | 376 -
>>  drivers/clocksource/owl-timer.c   | 173 --
>>  drivers/clocksource/qcom-timer.c  | 258 --
>>  drivers/clocksource/time-armada-370-xp.c  | 416 ---
>>  drivers/clocksource/time-efm32.c  | 287 
>>  drivers/clocksource/time-lpc32xx.c| 314 -
>>  drivers/clocksource/time-orion.c  | 192 ---
>>  drivers/clocksource/time-pistachio.c  | 218 
>>  drivers/clocksource/timer-armada-370-xp.c | 416 +++
>>  drivers/clocksource/timer-cadence-ttc.c   | 543 
>> ++
>>  drivers/clocksource/timer-efm32.c | 287 
>>  drivers/clocksource/timer-fsl-ftm.c   | 376 +
>>  drivers/clocksource/timer-lpc32xx.c   | 314 +
>>  drivers/clocksource/timer-orion.c | 192 +++
>>  drivers/clocksource/timer-owl.c   | 173 ++
>>  drivers/clocksource/timer-pistachio.c | 218 
>>  drivers/clocksource/timer-qcom.c  | 258 ++
>>  drivers/clocksource/timer-versatile.c |  44 +++
>>  drivers/clocksource/timer-vf-pit.c| 204 +++
>>  drivers/clocksource/timer-vt8500.c| 168 +
>>  drivers/clocksource/timer-zevio.c | 218 
>>  drivers/clocksource/versatile.c   |  44 ---
>>  drivers/clocksource/vf_pit_timer.c| 204 ---
>>  drivers/clocksource/vt8500_timer.c| 168 -
>>  drivers/clocksource/zevio-timer.c | 218 
>>  28 files changed, 3429 insertions(+), 3429 deletions(-)
> 
> Wow, with git format-patch -M this should look much smaller and so
> easier to review.

Yes, I forgot the option :/


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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 4.9 069/101] ubi: fastmap: Correctly handle interrupted erasures in EBA

[Richard Weinberger]

Lars,

Am Sonntag, 23. September 2018, 15:49:42 CEST schrieb Lars Persson:
> Hi Richard
> 
> Sorry, I assumed this omission from -stable was a mistake.
> 
> The timing for our boot increased from 45 seconds to 55 seconds on one
> chip and 42 seconds to 48 seconds on another chip. The regression was
> completely fixed by applying the extra patches. The way I see it the
> first patch is a significant slow-down so the second patch is required
> to restore performance.

okay, this is not good. Let's put the performance patch also into -stable
to get rid of that regression.
Usually I'm rather conservative with adding non-trivial material to -stable.
As history has shown, Fastmap is special. ;-)

Out of interest, what flashes are these? I'm interested in page vs. erase size.
Did you give UBIFS bulk-read try?

Greg, I'll send another mail which will state what patches are needed.

Thanks,
//richard

Re: [PATCH] Driver core: add bus_find_device_by_fwnode

[Silesh C V]

Hello Greg,
On Mon, Sep 24, 2018 at 10:48 AM Greg Kroah-Hartman
 wrote:
>
> On Mon, Sep 24, 2018 at 10:05:55AM +0530, Silesh C V wrote:
> > Some drivers need to find the device on a bus having a specific firmware
> > node. Currently, such drivers have their own implementations to do this.
> > Provide a helper similar to bus_find_device_by_name so that each driver
> > does not have to reinvent this.
>
> Is there a second patch that uses this function?  We don't add api calls
> that are not used.

OK. If I change, say, of_find_i2c_device_by_node,
of_find_i2c_adapter_by_node, of_phy_find_device and
of_find_spi_device_by_node to use this API, will that be good enough?
If that is OK, I will send this as a series in v2.
Thanks.

Regards,
Silesh

Re: [PATCH v8 4/5] clk: imx: add imx composite clock

[Sascha Hauer]

Hi Abel,

On Fri, Sep 21, 2018 at 03:11:33PM +0300, Abel Vesa wrote:
> Since a lot of clocks on imx8 are formed by a mux, gate, predivider and
> divider, the idea here is to combine all of those into one composite clock,
> but we need to deal with both predivider and divider at the same time and
> therefore we add the imx_clk_composite_divider_ops and register the composite
> clock with those.
> 
> Signed-off-by: Abel Vesa 
> Suggested-by: Sascha Hauer 
> ---
>  drivers/clk/imx/Makefile|   1 +
>  drivers/clk/imx/clk-composite.c | 156 
> 
>  drivers/clk/imx/clk.h   |  14 
>  3 files changed, 171 insertions(+)
>  create mode 100644 drivers/clk/imx/clk-composite.c
> 
> +static int imx_clk_composite_divider_set_rate(struct clk_hw *hw,
> + unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct clk_divider *divider = to_clk_divider(hw);
> + unsigned long prediv_rate;
> + unsigned long flags = 0;
> + int prediv_value;
> + int div_value;
> + u32 val;
> +
> + prediv_value = divider_get_val(rate, parent_rate, NULL,
> + PCG_PREDIV_WIDTH, CLK_DIVIDER_ROUND_CLOSEST);
> + if (prediv_value < 0)
> + return prediv_value;
> +
> + prediv_rate = DIV_ROUND_UP_ULL((u64)parent_rate, prediv_value + 1);
> +
> + div_value = divider_get_val(rate, prediv_rate, NULL,
> + PCG_DIV_WIDTH, CLK_DIVIDER_ROUND_CLOSEST);
> + if (div_value < 0)
> + return div_value;

Does this work with expected accuracy? Consider the best divider you are
looking for is 9. With the above you'll end up with a predivider of 8
and a postdivider of 1 instead of the optimum divider values of 3 and 3.

I think you have to iterate over all possible divider combinations and
then use the best one found. The original divider code does this, albeit
a little obfuscated.

You have to do the same in round_rate aswell.

Sorry, I missed that when I last looked at it in v6.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v3 2/2] remoteproc: qcom: Introduce Non-PAS ADSP PIL driver

[Rohit Kumar]

Thanks Sibi for reviewing.


On 9/22/2018 1:11 AM, Sibi Sankar wrote:

Hi Rohit,

On 2018-09-03 17:22, Rohit kumar wrote:

This adds Non PAS ADSP PIL driver for Qualcomm
Technologies Inc SoCs.
Added initial support for SDM845 with ADSP bootup and
shutdown operation handled from Application Processor
SubSystem(APSS).

Signed-off-by: Rohit kumar 
---



+    select QCOM_MDT_LOADER
+    select QCOM_Q6V5_COMMON
+    select QCOM_RPROC_COMMON
+    help
+  Say y here to support the Peripherial Image Loader


replace Peripherial/Peripheral.


sure



+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+


The headers should be in alphabetical order.



ok, will do



+    struct reset_control *pdc_sync_reset;
+    struct reset_control *cc_lpass_restart;
+
+    struct regmap *halt_map;
+    unsigned int  halt_lpass;


remove the double spaces above.


ok



+    if (ret || val)
+    goto reset;
+
+    regmap_write(adsp->halt_map,
+    adsp->halt_lpass + LPASS_HALTREQ_REG, 1);
+
+    /*  Wait for halt ACK from QDSP6 */


Minor nit, please remove the double spaces in the comment above.


ok



+    timeout = jiffies + msecs_to_jiffies(ACK_TIMEOUT);
+    for (;;) {
+    ret = regmap_read(adsp->halt_map,
+    adsp->halt_lpass + LPASS_HALTACK_REG, &val);
+    if (ret || val || time_after(jiffies, timeout))
+    break;
+
+    udelay(1000);


According to Documentation/timers/timers-howto.txt please use 
usleep_range()

when the delay range is between(10us - 20ms).


okay, will update in next spin.



+    }
+
+    ret = regmap_read(adsp->halt_map,
+    adsp->halt_lpass + LPASS_MASTER_IDLE_REG, &val);



+    /* wait after asserting subsystem restart from AOSS */
+    udelay(200);


ditto


ok



+
+    /* Clear the halt request for the AXIM and AHBM for Q6 */
+    regmap_write(adsp->halt_map, adsp->halt_lpass + 
LPASS_HALTREQ_REG, 0);

+
+    /* De-assert the LPASS PDC Reset */
+    reset_control_deassert(adsp->pdc_sync_reset);
+    /* Remove the LPASS reset */
+    reset_control_deassert(adsp->cc_lpass_restart);
+    /* wait after de-asserting subsystem restart from AOSS */
+    udelay(200);


ditto


+
+    return 0;
+}



+static int adsp_start(struct rproc *rproc)
+{
+    struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
+    int ret;
+    unsigned int val;
+
+    qcom_q6v5_prepare(&adsp->q6v5);
+
+    ret = clk_prepare_enable(adsp->xo);
+    if (ret)
+    return ret;


please call qcom_q6v5_unprepare on clk_prepare_enable failure to 
disable_irqs




sure, will do that

+
+    dev_pm_genpd_set_performance_state(adsp->dev, INT_MAX);
+    ret = pm_runtime_get_sync(adsp->dev);
+    if (ret)
+    goto disable_xo_clk;
+



+static int adsp_init_reset(struct qcom_adsp *adsp)
+{
+    adsp->pdc_sync_reset = devm_reset_control_get_exclusive(adsp->dev,
+    "pdc_sync");
+    if (IS_ERR(adsp->pdc_sync_reset)) {
+    dev_err(adsp->dev, "failed to acquire pdc_sync reset\n");
+    return PTR_ERR(adsp->pdc_sync_reset);
+    }


Bjorn, should we return EPROBE_DEFER here since PDC global reset 
controller can be a module?




devm_reset_control_get_exclusive itself returns EPROBE_DEFER until PDC 
reset driver is probed.

return PTR_ERR(adsp->pdc_sync_reset) handles this case.


+
+    adsp->cc_lpass_restart = 
devm_reset_control_get_exclusive(adsp->dev,

+    "cc_lpass");
+    if (IS_ERR(adsp->cc_lpass_restart)) {
+    dev_err(adsp->dev, "failed to acquire cc_lpass restart\n");
+    return PTR_ERR(adsp->cc_lpass_restart);
+    }
+
+    return 0;



+static int adsp_remove(struct platform_device *pdev)
+{
+    struct qcom_adsp *adsp = platform_get_drvdata(pdev);
+
+    rproc_del(adsp->rproc);
+
+    qcom_remove_glink_subdev(adsp->rproc, &adsp->glink_subdev);
+    qcom_remove_sysmon_subdev(adsp->sysmon);
+    qcom_remove_ssr_subdev(adsp->rproc, &adsp->ssr_subdev);
+    rproc_free(adsp->rproc);
+    pm_runtime_disable(adsp->dev);
+


rmmod of the driver resulted in the following kernel panic:
having a pm_runtime_disable after rproc_free seems to be the cause of 
the kernel panic.

Please call pm_runtime_disable before rproc_free.



Thanks for pointing out, will update.

do_raw_spin_lock+0x28/0x118
__raw_spin_lock_irq+0x30/0x3c
__pm_runtime_disable+0x28/0xf4
adsp_remove+0x4c/0x5c [qcom_adsp_pil]
platform_drv_remove+0x28/0x50
device_release_driver_internal+0x124/0x1c8
driver_detach+0x44/0x80
bus_remove_driver+0x78/0x9c
driver_unregister+0x34/0x54
platform_driver_unregister+0x1c/0x28
cleanup_module+0x14/0x6bc [qcom_adsp_pil]
SyS_delete_module+0x1c4/0x214


+    return 0;
+}
+
+static const struct adsp_pil_data adsp_resource_init = {
+    .crash_reason_smem = 423,
+    .firmware_name = "adsp.mdt",
+    .ssr_name = "lpass",
+    .sysmon_name = 

Re: [PATCH 5/6] fsmount: do not use legacy MS_ flags

[David Howells]

Christian Brauner  wrote:

> Ok, understood. What about passing the different attrs as a struct?
> 
> struct mount_attr {
> unsigned int attr_cmd,
> unsigned int attr_values,
> unsigned int attr_mask,
> 
> };
> 
> mount_setattr(int dfd, const char *path, unsigned int atflags,
>   struct mount_attr *attr);
> 
> I find that to be a little cleaner in all honesty.
> One could also add a version argument similar to what we currently do
> for vfs fcaps so that kernel and userspace can easily navigate
> compabitility when a new member gets added or removed in later releases.

Yeah, we could do that - it's not like I expect mount_setattr() to have to be
particularly performant in the user interface.  I would put the attr_cmd in
the argument list, probably, so that you can use that to vary the struct in
future (say we run out of attribute bits).

David

net build error

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:474ff2600889 net-ethtool: ETHTOOL_GUFO did not and should ..
git tree:   net
console output: https://syzkaller.appspot.com/x/log.txt?x=164c405940
kernel config:  https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
dashboard link: https://syzkaller.appspot.com/bug?extid=a72ba31e3224309179d4
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a72ba31e322430917...@syzkaller.appspotmail.com



---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.

[PATCH -next] x86/hyper-v: Remove unused including

[YueHaibing]

Remove including  that don't need it.

Signed-off-by: YueHaibing 
---
 arch/x86/hyperv/hv_apic.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 2c43e30..8eb6fbee 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -20,7 +20,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 

Re: [PATCH TRIVIAL] Punctuation fixes

[Richard Weinberger]

On Sun, Sep 23, 2018 at 3:00 AM Miguel Ojeda
 wrote:
>
> Hi Diego,
>
> A few things, since it looks like this is your first patch.

git log...

> On Sat, Sep 22, 2018 at 5:56 PM, Diego Viola  wrote:
> > On Wed, Sep 12, 2018 at 12:54 AM Diego Viola  wrote:
> >>
> >> Signed-off-by: Diego Viola 
> >> ---
> >>  CREDITS | 2 +-
> >>  MAINTAINERS | 2 +-
> >>  Makefile| 2 +-
> >>  3 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/CREDITS b/CREDITS
> >> index 5befd2d71..b82efb36d 100644
> >> --- a/CREDITS
> >> +++ b/CREDITS
> >> @@ -1473,7 +1473,7 @@ W: http://www.linux-ide.org/
> >>  W: http://www.linuxdiskcert.org/
> >>  D: Random SMP kernel hacker...
> >>  D: Uniform Multi-Platform E-IDE driver
> >> -D: Active-ATA-Chipset maddness..
> >> +D: Active-ATA-Chipset maddness...
>
> I think the extra dots is what was intended here :)

Diego, I know you can do better. :-)
How about running linux-next and hunting down regressions?
I think we suggested this already on IRC.

-- 
Thanks,
//richard

[PATCH] staging: rtl8188eu, rtl8723bs: fix spelling mistake "evet" -> "event"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in RT_TRACE message

Signed-off-by: Colin Ian King 
---
 drivers/staging/rtl8188eu/core/rtw_mlme.c | 2 +-
 drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index ef8a7dc4bd34..9a3532de6523 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -540,7 +540,7 @@ static int rtw_is_desired_network(struct adapter *adapter, 
struct wlan_network *
 /* TODO: Perry: For Power Management */
 void rtw_atimdone_event_callback(struct adapter *adapter, u8 *pbuf)
 {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("receive 
atimdone_evet\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("receive 
atimdone_event\n"));
 }
 
 void rtw_survey_event_callback(struct adapter  *adapter, u8 *pbuf)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index f9392b8db49b..4c5d5cf9dfe0 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -802,7 +802,7 @@ int rtw_is_desired_network(struct adapter *adapter, struct 
wlan_network *pnetwor
 /* TODO: Perry : For Power Management */
 void rtw_atimdone_event_callback(struct adapter*adapter, u8 *pbuf)
 {
-   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("receive 
atimdone_evet\n"));
+   RT_TRACE(_module_rtl871x_mlme_c_, _drv_err_, ("receive 
atimdone_event\n"));
 }
 
 
-- 
2.17.1

[PATCH v8 01/16] x86/cpu: Create Hygon Dhyana architecture support file

[Pu Wen]

Add x86 architecture support for a new processor: Hygon Dhyana Family
18h. Carve out initialization code needed by Dhyana into a separate
compilation unit.

To identify Hygon Dhyana CPU, add a new vendor type X86_VENDOR_HYGON
for system recognition.

Since Dhyana uses AMD functionality to a large degree, select
CPU_SUP_AMD which provides that functionality.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 MAINTAINERS  |   6 +
 arch/x86/Kconfig.cpu |  14 ++
 arch/x86/include/asm/processor.h |   3 +-
 arch/x86/kernel/cpu/Makefile |   1 +
 arch/x86/kernel/cpu/hygon.c  | 408 +++
 5 files changed, 431 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/kernel/cpu/hygon.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4ece30f..c028e1d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6762,6 +6762,12 @@ S:   Maintained
 F: mm/memory-failure.c
 F: mm/hwpoison-inject.c
 
+HYGON PROCESSOR SUPPORT
+M: Pu Wen 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: arch/x86/kernel/cpu/hygon.c
+
 Hyper-V CORE AND DRIVERS
 M: "K. Y. Srinivasan" 
 M: Haiyang Zhang 
diff --git a/arch/x86/Kconfig.cpu b/arch/x86/Kconfig.cpu
index 638411f..6adce15 100644
--- a/arch/x86/Kconfig.cpu
+++ b/arch/x86/Kconfig.cpu
@@ -426,6 +426,20 @@ config CPU_SUP_AMD
 
  If unsure, say N.
 
+config CPU_SUP_HYGON
+   default y
+   bool "Support Hygon processors" if PROCESSOR_SELECT
+   select CPU_SUP_AMD
+   help
+ This enables detection, tunings and quirks for Hygon processors
+
+ You need this enabled if you want your kernel to run on an
+ Hygon CPU. Disabling this option on other types of CPUs
+ makes the kernel a tiny bit smaller. Disabling it on an Hygon
+ CPU might render the kernel unbootable.
+
+ If unsure, say N.
+
 config CPU_SUP_CENTAUR
default y
bool "Support Centaur processors" if PROCESSOR_SELECT
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index d53c54b..d4dfd02 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -155,7 +155,8 @@ enum cpuid_regs_idx {
 #define X86_VENDOR_CENTAUR 5
 #define X86_VENDOR_TRANSMETA   7
 #define X86_VENDOR_NSC 8
-#define X86_VENDOR_NUM 9
+#define X86_VENDOR_HYGON   9
+#define X86_VENDOR_NUM 10
 
 #define X86_VENDOR_UNKNOWN 0xff
 
diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 347137e..1f5d229 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
 
 obj-$(CONFIG_CPU_SUP_INTEL)+= intel.o intel_pconfig.o
 obj-$(CONFIG_CPU_SUP_AMD)  += amd.o
+obj-$(CONFIG_CPU_SUP_HYGON)+= hygon.o
 obj-$(CONFIG_CPU_SUP_CYRIX_32) += cyrix.o
 obj-$(CONFIG_CPU_SUP_CENTAUR)  += centaur.o
 obj-$(CONFIG_CPU_SUP_TRANSMETA_32) += transmeta.o
diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c
new file mode 100644
index 000..9f5679e
--- /dev/null
+++ b/arch/x86/kernel/cpu/hygon.c
@@ -0,0 +1,408 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hygon Processor Support for Linux
+ *
+ * Copyright (C) 2018 Chengdu Haiguang IC Design Co., Ltd.
+ *
+ * Author: Pu Wen 
+ *
+ * This file is licensed under the terms of the GNU General
+ * License v2.0 or later. See file COPYING for details.
+ */
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#ifdef CONFIG_X86_64
+# include 
+#endif
+
+#include "cpu.h"
+
+/*
+ * nodes_per_socket: Stores the number of nodes per socket.
+ * Refer to CPUID Fn8000_001E_ECX Node Identifiers[10:8]
+ */
+static u32 nodes_per_socket = 1;
+
+#ifdef CONFIG_NUMA
+/*
+ * To workaround broken NUMA config.  Read the comment in
+ * srat_detect_node().
+ */
+static int nearby_node(int apicid)
+{
+   int i, node;
+
+   for (i = apicid - 1; i >= 0; i--) {
+   node = __apicid_to_node[i];
+   if (node != NUMA_NO_NODE && node_online(node))
+   return node;
+   }
+   for (i = apicid + 1; i < MAX_LOCAL_APIC; i++) {
+   node = __apicid_to_node[i];
+   if (node != NUMA_NO_NODE && node_online(node))
+   return node;
+   }
+   return first_node(node_online_map); /* Shouldn't happen */
+}
+#endif
+
+static void hygon_get_topology_early(struct cpuinfo_x86 *c)
+{
+   if (cpu_has(c, X86_FEATURE_TOPOEXT))
+   smp_num_siblings = ((cpuid_ebx(0x801e) >> 8) & 0xff) + 1;
+}
+
+/*
+ * Fixup core topology information for
+ * (1) Hygon multi-node processors
+ * Assumption: Number of cores in each internal node is the same.
+ * (2) Hygon processors supporting compute units
+ */
+static void hygon_get_topology(struct cpuinfo_x86 *c)
+{
+   u8 node_id;
+   int cpu = smp_pro

[PATCH v8 03/16] x86/cpu/mtrr: Support TOP_MEM2 and get MTRR number

[Pu Wen]

The Hygon Dhyana CPU has a special magic MSR way to force WB for
memory >4GB, and support TOP_MEM2. Therefore, it is necessary to
add Hygon Dhyana support in amd_special_default_mtrr().

The number of variable MTRRs for Hygon is 2 as AMD's.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/kernel/cpu/mtrr/cleanup.c | 3 ++-
 arch/x86/kernel/cpu/mtrr/mtrr.c| 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c 
b/arch/x86/kernel/cpu/mtrr/cleanup.c
index 765afd5..3668c5d 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -831,7 +831,8 @@ int __init amd_special_default_mtrr(void)
 {
u32 l, h;
 
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
return 0;
if (boot_cpu_data.x86 < 0xf)
return 0;
diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
index 9a19c80..507039c 100644
--- a/arch/x86/kernel/cpu/mtrr/mtrr.c
+++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
@@ -127,7 +127,7 @@ static void __init set_num_var_ranges(void)
 
if (use_intel())
rdmsr(MSR_MTRRcap, config, dummy);
-   else if (is_cpu(AMD))
+   else if (is_cpu(AMD) || is_cpu(HYGON))
config = 2;
else if (is_cpu(CYRIX) || is_cpu(CENTAUR))
config = 8;
-- 
2.7.4

[PATCH v8 02/16] x86/cpu: Get cache info and setup cache cpumap for Hygon Dhyana

[Pu Wen]

The Hygon Dhyana CPU has topology extensions bit in CPUID. With this
bit, the kernel can get the cache information. So add support in
cpuid4_cache_lookup_regs() to get the correct cache size.

The Hygon Dhyana CPU also discovers num_cache_leaves via CPUID leaf
0x801d, so add support to it in find_num_cache_leaves().

Also add cacheinfo_hygon_init_llc_id() and init_hygon_cacheinfo()
functions to initialize Dhyana cache info. Setup cache cpumap in
the same way as AMD does.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/include/asm/cacheinfo.h |  1 +
 arch/x86/kernel/cpu/cacheinfo.c  | 31 +--
 arch/x86/kernel/cpu/cpu.h|  1 +
 arch/x86/kernel/cpu/hygon.c  |  3 +++
 4 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/cacheinfo.h b/arch/x86/include/asm/cacheinfo.h
index e958e28..86b63c7 100644
--- a/arch/x86/include/asm/cacheinfo.h
+++ b/arch/x86/include/asm/cacheinfo.h
@@ -3,5 +3,6 @@
 #define _ASM_X86_CACHEINFO_H
 
 void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id);
+void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id);
 
 #endif /* _ASM_X86_CACHEINFO_H */
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 0c5fcbd..dc1b934 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch/x86/kernel/cpu/cacheinfo.c
@@ -602,6 +602,10 @@ cpuid4_cache_lookup_regs(int index, struct 
_cpuid4_info_regs *this_leaf)
else
amd_cpuid4(index, &eax, &ebx, &ecx);
amd_init_l3_cache(this_leaf, index);
+   } else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
+   cpuid_count(0x801d, index, &eax.full,
+   &ebx.full, &ecx.full, &edx);
+   amd_init_l3_cache(this_leaf, index);
} else {
cpuid_count(4, index, &eax.full, &ebx.full, &ecx.full, &edx);
}
@@ -625,7 +629,8 @@ static int find_num_cache_leaves(struct cpuinfo_x86 *c)
union _cpuid4_leaf_eax  cache_eax;
int i = -1;
 
-   if (c->x86_vendor == X86_VENDOR_AMD)
+   if (c->x86_vendor == X86_VENDOR_AMD ||
+   c->x86_vendor == X86_VENDOR_HYGON)
op = 0x801d;
else
op = 4;
@@ -678,6 +683,22 @@ void cacheinfo_amd_init_llc_id(struct cpuinfo_x86 *c, int 
cpu, u8 node_id)
}
 }
 
+void cacheinfo_hygon_init_llc_id(struct cpuinfo_x86 *c, int cpu, u8 node_id)
+{
+   /*
+* We may have multiple LLCs if L3 caches exist, so check if we
+* have an L3 cache by looking at the L3 cache CPUID leaf.
+*/
+   if (!cpuid_edx(0x8006))
+   return;
+
+   /*
+* LLC is at the core complex level.
+* Core complex ID is ApicId[3] for these processors.
+*/
+   per_cpu(cpu_llc_id, cpu) = c->apicid >> 3;
+}
+
 void init_amd_cacheinfo(struct cpuinfo_x86 *c)
 {
 
@@ -691,6 +712,11 @@ void init_amd_cacheinfo(struct cpuinfo_x86 *c)
}
 }
 
+void init_hygon_cacheinfo(struct cpuinfo_x86 *c)
+{
+   num_cache_leaves = find_num_cache_leaves(c);
+}
+
 void init_intel_cacheinfo(struct cpuinfo_x86 *c)
 {
/* Cache sizes */
@@ -913,7 +939,8 @@ static void __cache_cpumap_setup(unsigned int cpu, int 
index,
int index_msb, i;
struct cpuinfo_x86 *c = &cpu_data(cpu);
 
-   if (c->x86_vendor == X86_VENDOR_AMD) {
+   if (c->x86_vendor == X86_VENDOR_AMD ||
+   c->x86_vendor == X86_VENDOR_HYGON) {
if (__cache_amd_cpumap_setup(cpu, index, base))
return;
}
diff --git a/arch/x86/kernel/cpu/cpu.h b/arch/x86/kernel/cpu/cpu.h
index 7b229af..da5446a 100644
--- a/arch/x86/kernel/cpu/cpu.h
+++ b/arch/x86/kernel/cpu/cpu.h
@@ -54,6 +54,7 @@ extern u32 get_scattered_cpuid_leaf(unsigned int level,
enum cpuid_regs_idx reg);
 extern void init_intel_cacheinfo(struct cpuinfo_x86 *c);
 extern void init_amd_cacheinfo(struct cpuinfo_x86 *c);
+extern void init_hygon_cacheinfo(struct cpuinfo_x86 *c);
 
 extern void detect_num_cpu_cores(struct cpuinfo_x86 *c);
 extern int detect_extended_topology_early(struct cpuinfo_x86 *c);
diff --git a/arch/x86/kernel/cpu/hygon.c b/arch/x86/kernel/cpu/hygon.c
index 9f5679e..ac70997 100644
--- a/arch/x86/kernel/cpu/hygon.c
+++ b/arch/x86/kernel/cpu/hygon.c
@@ -90,6 +90,7 @@ static void hygon_get_topology(struct cpuinfo_x86 *c)
if (!err)
c->x86_coreid_bits = get_count_order(c->x86_max_cores);
 
+   cacheinfo_hygon_init_llc_id(c, cpu, node_id);
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;
 
@@ -324,6 +325,8 @@ static void init_hygon(struct cpuinfo_x86 *c)
hygon_get_topology(c);
srat_detect_node(c);
 
+   init_hygon_cacheinfo(c);
+
if (cpu_has(c, X86_FEATURE_XMM2)) {
unsig

[PATCH v8 04/16] x86/smpboot: SMP init no delay and not flush caches before sleep

[Pu Wen]

The Hygon Dhyana CPU uses no delay in smp_quirk_init_udelay(),
and returns in mwait_play_dead() as AMD does.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/kernel/smpboot.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index f02ecaf..5369d7f 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -676,6 +676,7 @@ static void __init smp_quirk_init_udelay(void)
 
/* if modern processor, use no delay */
if (((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && 
(boot_cpu_data.x86 == 6)) ||
+   ((boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) && 
(boot_cpu_data.x86 >= 0x18)) ||
((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && (boot_cpu_data.x86 
>= 0xF))) {
init_udelay = 0;
return;
@@ -1592,7 +1593,8 @@ static inline void mwait_play_dead(void)
void *mwait_ptr;
int i;
 
-   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+   boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
return;
if (!this_cpu_has(X86_FEATURE_MWAIT))
return;
-- 
2.7.4

Re: [PATCH] staging: mt7621-mmc: Remove do {} while (0) loop for single statement macro

[Nishad Kamdar]

On Tue, Sep 18, 2018 at 01:27:11PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Sep 15, 2018 at 06:47:51PM +0530, Nishad Kamdar wrote:
> > This patch removes do {} while (0) loop for single statement macros.
> > Issue found by checkpatch.
> > 
> > Signed-off-by: Nishad Kamdar 
> > ---
> >  drivers/staging/mt7621-mmc/sd.c | 28 +++-
> >  1 file changed, 7 insertions(+), 21 deletions(-)
> > 
> > diff --git a/drivers/staging/mt7621-mmc/sd.c 
> > b/drivers/staging/mt7621-mmc/sd.c
> > index 7474f9ed7b5b..ec12a3a5a926 100644
> > --- a/drivers/staging/mt7621-mmc/sd.c
> > +++ b/drivers/staging/mt7621-mmc/sd.c
> > @@ -104,14 +104,10 @@ static int cd_active_low = 1;
> >  /* gate means clock power down */
> >  static int g_clk_gate = 0;
> >  #define msdc_gate_clock(id) \
> > -   do {   \
> > -   g_clk_gate &= ~(1 << ((id) + PERI_MSDC0_PDN));  \
> > -   } while (0)
> > +   (g_clk_gate &= ~(1 << ((id) + PERI_MSDC0_PDN)))
> 
> This should become an inline function, right?
> 
> 
> >  /* not like power down register. 1 means clock on. */
> >  #define msdc_ungate_clock(id) \
> > -   do {\
> > -   g_clk_gate |= 1 << ((id) + PERI_MSDC0_PDN); \
> > -   } while (0)
> > +   (g_clk_gate |= 1 << ((id) + PERI_MSDC0_PDN))
> 
> Same here.
> 
> >  
> >  // do we need sync object or not
> >  void msdc_clk_status(int *status)
> > @@ -170,9 +166,7 @@ static void msdc_clr_fifo(struct msdc_host *host)
> > } while (0)
> >  
> >  #define msdc_irq_restore(val) \
> > -   do {\
> > -   sdr_set_bits(host->base + MSDC_INTEN, val); \
> > -   } while (0)
> > +   (sdr_set_bits(host->base + MSDC_INTEN, val))
> 
> Just call the one function where this is used and delete this #define.
> 
> Same type of changes for the rest of these as well.
> 
> thanks,
> 
> greg k-h

Ok. I'll do that.

Thanks for the review.

regards,
nishad

[PATCH v8 07/16] x86/pci: Add Hygon Dhyana support to PCI and north bridge

[Pu Wen]

As Hygon registered its PCI Vendor ID as a new one 0x1d94, and there
are PCI Devices 0x1450/0x1463/0x1464 for Host bridge on Hygon Dhyana
platform, so add Hygon Dhyana support to the PCI and north bridge
subsystem by using the code path of AMD family 17h.

To prevent further checking PCI device ids which cannot happen both on
Hygon and Intel platform, the function amd_gart_present should return
if it's not a AMD CPU.

Signed-off-by: Pu Wen 
Acked-by: Bjorn Helgaas# pci_ids.h
Reviewed-by: Borislav Petkov 
---
 arch/x86/include/asm/amd_nb.h |  3 +++
 arch/x86/kernel/amd_nb.c  | 47 +--
 arch/x86/pci/amd_bus.c|  6 --
 include/linux/pci_ids.h   |  2 ++
 4 files changed, 50 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/amd_nb.h b/arch/x86/include/asm/amd_nb.h
index fddb6d2..1ae4e57 100644
--- a/arch/x86/include/asm/amd_nb.h
+++ b/arch/x86/include/asm/amd_nb.h
@@ -103,6 +103,9 @@ static inline u16 amd_pci_dev_to_node_id(struct pci_dev 
*pdev)
 
 static inline bool amd_gart_present(void)
 {
+   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+   return false;
+
/* GART present only on Fam15h, upto model 0fh */
if (boot_cpu_data.x86 == 0xf || boot_cpu_data.x86 == 0x10 ||
(boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model < 0x10))
diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
index b481b95..dcc4130 100644
--- a/arch/x86/kernel/amd_nb.c
+++ b/arch/x86/kernel/amd_nb.c
@@ -61,6 +61,21 @@ static const struct pci_device_id amd_nb_link_ids[] = {
{}
 };
 
+static const struct pci_device_id hygon_root_ids[] = {
+   { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_AMD_17H_ROOT) },
+   {}
+};
+
+const struct pci_device_id hygon_nb_misc_ids[] = {
+   { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_AMD_17H_DF_F3) },
+   {}
+};
+
+static const struct pci_device_id hygon_nb_link_ids[] = {
+   { PCI_DEVICE(PCI_VENDOR_ID_HYGON, PCI_DEVICE_ID_AMD_17H_DF_F4) },
+   {}
+};
+
 const struct amd_nb_bus_dev_range amd_nb_bus_dev_ranges[] __initconst = {
{ 0x00, 0x18, 0x20 },
{ 0xff, 0x00, 0x20 },
@@ -197,12 +212,25 @@ int amd_cache_northbridges(void)
u16 i = 0;
struct amd_northbridge *nb;
struct pci_dev *root, *misc, *link;
+   const struct pci_device_id *root_ids = NULL;
+   const struct pci_device_id *misc_ids = NULL;
+   const struct pci_device_id *link_ids = NULL;
+
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
+   root_ids = hygon_root_ids;
+   misc_ids = hygon_nb_misc_ids;
+   link_ids = hygon_nb_link_ids;
+   } else {
+   root_ids = amd_root_ids;
+   misc_ids = amd_nb_misc_ids;
+   link_ids = amd_nb_link_ids;
+   }
 
if (amd_northbridges.num)
return 0;
 
misc = NULL;
-   while ((misc = next_northbridge(misc, amd_nb_misc_ids)) != NULL)
+   while ((misc = next_northbridge(misc, misc_ids)) != NULL)
i++;
 
if (!i)
@@ -218,11 +246,11 @@ int amd_cache_northbridges(void)
link = misc = root = NULL;
for (i = 0; i != amd_northbridges.num; i++) {
node_to_amd_nb(i)->root = root =
-   next_northbridge(root, amd_root_ids);
+   next_northbridge(root, root_ids);
node_to_amd_nb(i)->misc = misc =
-   next_northbridge(misc, amd_nb_misc_ids);
+   next_northbridge(misc, misc_ids);
node_to_amd_nb(i)->link = link =
-   next_northbridge(link, amd_nb_link_ids);
+   next_northbridge(link, link_ids);
}
 
if (amd_gart_present())
@@ -263,9 +291,15 @@ bool __init early_is_amd_nb(u32 device)
 {
const struct pci_device_id *id;
u32 vendor = device & 0x;
+   const struct pci_device_id *misc_ids = NULL;
+
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+   misc_ids = hygon_nb_misc_ids;
+   else
+   misc_ids = amd_nb_misc_ids;
 
device >>= 16;
-   for (id = amd_nb_misc_ids; id->vendor; id++)
+   for (id = misc_ids; id->vendor; id++)
if (vendor == id->vendor && device == id->device)
return true;
return false;
@@ -277,7 +311,8 @@ struct resource *amd_get_mmconfig_range(struct resource 
*res)
u64 base, msr;
unsigned int segn_busn_bits;
 
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
return NULL;
 
/* assume all cpus from fam10h have mmconfig */
diff --git a/arch/x86/pci/amd_bus.c b/arch/x86/pci/amd_bus.c
index 649bdde..bfa50e6 100644
--- a/arch/x86/pci/amd_bus.c
+++ b/arch/x86/pci/amd_bus.c
@@ -93,7 +93,8 

[PATCH v8 06/16] x86/alternative: Init ideal_nops for Hygon Dhyana

[Pu Wen]

The ideal_nops for Hygon Dhyana CPU should be p6_nops.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/kernel/alternative.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index b9d5e7c..184e9a0 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -222,6 +222,10 @@ void __init arch_init_ideal_nops(void)
}
break;
 
+   case X86_VENDOR_HYGON:
+   ideal_nops = p6_nops;
+   return;
+
case X86_VENDOR_AMD:
if (boot_cpu_data.x86 > 0xf) {
ideal_nops = p6_nops;
-- 
2.7.4

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

[Taniya Das]

Hello Stephen,


On 8/24/2018 12:08 AM, Stephen Boyd wrote:

Quoting Taniya Das (2018-08-08 03:15:26)



On 8/8/2018 11:52 AM, Stephen Boyd wrote:


Binding describes hardware controllable by the OS. That's the reality.
Let's not add mandatory clock bindings for clocks that the OS can't do
anything about.



It seems that you believe clks should only be used to turn on/off and
control rates. That is not the whole truth. Sometimes clks are there
just to express the clk frequencies that are present in the design so
that drivers can figure out what to do.



Stephen,

As this clock is not configurable by linux clock drivers and we really
do not care the parent src(as mentioned by Saravana) to generate the
300MHz, would it be good to define a fixed rate clock so as to express
the HW connectivity & frequency?



As a hack that works great, but why do we need to workaround problems by
adding a fixed rate clk to DT for this PLL? The PLL is provided by GCC
node so it should be connected to the GCC node.



Please help with review the next patch series which would take the PLL 
phandle from DT.


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

--

[PATCH v8 08/16] x86/apic: Add Hygon Dhyana support to APIC

[Pu Wen]

Add Hygon Dhyana support to the APIC subsystem as it uses modern APIC.
When running on 32 bit mode, bigsmp should be enabled if there are
more than 8 cores online.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/kernel/apic/apic.c | 7 +++
 arch/x86/kernel/apic/probe_32.c | 1 +
 2 files changed, 8 insertions(+)

diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 84132ed..ab731ab 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -224,6 +224,11 @@ static int modern_apic(void)
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
boot_cpu_data.x86 >= 0xf)
return 1;
+
+   /* Hygon systems use modern APIC */
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+   return 1;
+
return lapic_get_version() >= 0x14;
 }
 
@@ -1912,6 +1917,8 @@ static int __init detect_init_APIC(void)
(boot_cpu_data.x86 >= 15))
break;
goto no_apic;
+   case X86_VENDOR_HYGON:
+   break;
case X86_VENDOR_INTEL:
if (boot_cpu_data.x86 == 6 || boot_cpu_data.x86 == 15 ||
(boot_cpu_data.x86 == 5 && boot_cpu_has(X86_FEATURE_APIC)))
diff --git a/arch/x86/kernel/apic/probe_32.c b/arch/x86/kernel/apic/probe_32.c
index 02e8acb..47ff297 100644
--- a/arch/x86/kernel/apic/probe_32.c
+++ b/arch/x86/kernel/apic/probe_32.c
@@ -185,6 +185,7 @@ void __init default_setup_apic_routing(void)
break;
}
/* If P4 and above fall through */
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
def_to_bigsmp = 1;
}
-- 
2.7.4

[PATCH v8 05/16] perf/x86: Add Hygon Dhyana support to PMU infrastructure

[Pu Wen]

The PMU architecture for Hygon Dhyana CPU is similar to the AMD Family
17h one. To support Hygon Dhyana PMU, call amd_pmu_init() to share
AMD PMU initialization flow, and change the PMU name to "HYGON".

The Hygon Dhyana CPU supports both legacy and extension PMC MSRs(perf
counter registers and event selection registers), so add Hygon Dhyana
support in the similar way as AMD does.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/events/amd/core.c |  4 
 arch/x86/events/amd/uncore.c   | 20 +---
 arch/x86/events/core.c |  4 
 arch/x86/kernel/cpu/perfctr-watchdog.c |  2 ++
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index c84584b..7d2d7c8 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -669,6 +669,10 @@ static int __init amd_core_pmu_init(void)
 * We fallback to using default amd_get_event_constraints.
 */
break;
+   case 0x18:
+   pr_cont("Fam18h ");
+   /* Using default amd_get_event_constraints. */
+   break;
default:
pr_err("core perfctr but no constraints; unknown hardware!\n");
return -ENODEV;
diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
index 981ba5e..c7d745b 100644
--- a/arch/x86/events/amd/uncore.c
+++ b/arch/x86/events/amd/uncore.c
@@ -507,17 +507,19 @@ static int __init amd_uncore_init(void)
 {
int ret = -ENODEV;
 
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_HYGON)
return -ENODEV;
 
if (!boot_cpu_has(X86_FEATURE_TOPOEXT))
return -ENODEV;
 
-   if (boot_cpu_data.x86 == 0x17) {
+   if (boot_cpu_data.x86 == 0x17 || boot_cpu_data.x86 == 0x18) {
/*
-* For F17h, the Northbridge counters are repurposed as Data
-* Fabric counters. Also, L3 counters are supported too. The 
PMUs
-* are exported based on  family as either L2 or L3 and NB or 
DF.
+* For F17h or F18h, the Northbridge counters are
+* repurposed as Data Fabric counters. Also, L3
+* counters are supported too. The PMUs are exported
+* based on family as either L2 or L3 and NB or DF.
 */
num_counters_nb   = NUM_COUNTERS_NB;
num_counters_llc  = NUM_COUNTERS_L3;
@@ -547,7 +549,9 @@ static int __init amd_uncore_init(void)
if (ret)
goto fail_nb;
 
-   pr_info("AMD NB counters detected\n");
+   pr_info("%s NB counters detected\n",
+   boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ?
+   "HYGON" : "AMD");
ret = 0;
}
 
@@ -561,7 +565,9 @@ static int __init amd_uncore_init(void)
if (ret)
goto fail_llc;
 
-   pr_info("AMD LLC counters detected\n");
+   pr_info("%s LLC counters detected\n",
+   boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ?
+   "HYGON" : "AMD");
ret = 0;
}
 
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index dfb2f7c..9c562f5 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -1776,6 +1776,10 @@ static int __init init_hw_perf_events(void)
case X86_VENDOR_AMD:
err = amd_pmu_init();
break;
+   case X86_VENDOR_HYGON:
+   err = amd_pmu_init();
+   x86_pmu.name = "HYGON";
+   break;
default:
err = -ENOTSUPP;
}
diff --git a/arch/x86/kernel/cpu/perfctr-watchdog.c 
b/arch/x86/kernel/cpu/perfctr-watchdog.c
index d389083..9556930 100644
--- a/arch/x86/kernel/cpu/perfctr-watchdog.c
+++ b/arch/x86/kernel/cpu/perfctr-watchdog.c
@@ -46,6 +46,7 @@ static inline unsigned int nmi_perfctr_msr_to_bit(unsigned 
int msr)
 {
/* returns the bit offset of the performance counter register */
switch (boot_cpu_data.x86_vendor) {
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
if (msr >= MSR_F15H_PERF_CTR)
return (msr - MSR_F15H_PERF_CTR) >> 1;
@@ -74,6 +75,7 @@ static inline unsigned int nmi_evntsel_msr_to_bit(unsigned 
int msr)
 {
/* returns the bit offset of the event selection register */
switch (boot_cpu_data.x86_vendor) {
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
if (msr >= MSR_F15H_PERF_CTL)
return (msr - MSR_F15H_PERF_CTL) >> 1;
-- 
2.7.4

[PATCH v8 09/16] x86/bugs: Add mitigation to spectre and no meltdown for Hygon Dhyana

[Pu Wen]

The Hygon Dhyana CPU has the same speculative execution as AMD family
17h, so share AMD spectre mitigation code for Hygon Dhyana.

Also Hygon Dhyana is not affected by meltdown vulnerability, so add
exception for it.

Signed-off-by: Pu Wen 
---
 arch/x86/kernel/cpu/bugs.c   | 4 +++-
 arch/x86/kernel/cpu/common.c | 1 +
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index 40bdaea..b810cc2 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -312,6 +312,7 @@ static enum spectre_v2_mitigation_cmd __init 
spectre_v2_parse_cmdline(void)
}
 
if (cmd == SPECTRE_V2_CMD_RETPOLINE_AMD &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_HYGON &&
boot_cpu_data.x86_vendor != X86_VENDOR_AMD) {
pr_err("retpoline,amd selected but CPU is not AMD. Switching to 
AUTO select\n");
return SPECTRE_V2_CMD_AUTO;
@@ -371,7 +372,8 @@ static void __init spectre_v2_select_mitigation(void)
return;
 
 retpoline_auto:
-   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+   boot_cpu_data.x86_vendor == X86_VENDOR_HYGON) {
retpoline_amd:
if (!boot_cpu_has(X86_FEATURE_LFENCE_RDTSC)) {
pr_err("Spectre mitigation: LFENCE not serializing, 
switching to generic retpoline\n");
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 44c4ef3..851cbe7 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -963,6 +963,7 @@ static const __initconst struct x86_cpu_id 
cpu_no_speculation[] = {
 
 static const __initconst struct x86_cpu_id cpu_no_meltdown[] = {
{ X86_VENDOR_AMD },
+   { X86_VENDOR_HYGON },
{}
 };
 
-- 
2.7.4

[PATCH v8 10/16] x86/mce: Add Hygon Dhyana support to MCE infrastructure

[Pu Wen]

The machine check architecture for Hygon Dhyana CPU is similar to the
AMD family 17h one. To make MCE working on Hygon platform, add vendor
checking for Hygon Dhyana to share the code path of AMD family 17h.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/include/asm/mce.h|  2 ++
 arch/x86/kernel/cpu/mcheck/mce-severity.c |  3 ++-
 arch/x86/kernel/cpu/mcheck/mce.c  | 20 +++-
 3 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 3a17107..550f2c9 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -214,6 +214,8 @@ static inline void mce_amd_feature_init(struct cpuinfo_x86 
*c) { }
 static inline int umc_normaddr_to_sysaddr(u64 norm_addr, u16 nid, u8 umc, u64 
*sys_addr) { return -EINVAL; };
 #endif
 
+static inline void mce_hygon_feature_init(struct cpuinfo_x86 *c) { return 
mce_amd_feature_init(c); }
+
 int mce_available(struct cpuinfo_x86 *c);
 bool mce_is_memory_error(struct mce *m);
 
diff --git a/arch/x86/kernel/cpu/mcheck/mce-severity.c 
b/arch/x86/kernel/cpu/mcheck/mce-severity.c
index f34d89c..44396d5 100644
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -336,7 +336,8 @@ int (*mce_severity)(struct mce *m, int tolerant, char 
**msg, bool is_excp) =
 
 void __init mcheck_vendor_init_severity(void)
 {
-   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD ||
+   boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
mce_severity = mce_severity_amd;
 }
 
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 953b3ce..909f1d7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -270,7 +270,7 @@ static void print_mce(struct mce *m)
 {
__print_mce(m);
 
-   if (m->cpuvendor != X86_VENDOR_AMD)
+   if (m->cpuvendor != X86_VENDOR_AMD && m->cpuvendor != X86_VENDOR_HYGON)
pr_emerg_ratelimited(HW_ERR "Run the above through 'mcelog 
--ascii'\n");
 }
 
@@ -508,9 +508,9 @@ static int mce_usable_address(struct mce *m)
 
 bool mce_is_memory_error(struct mce *m)
 {
-   if (m->cpuvendor == X86_VENDOR_AMD) {
+   if (m->cpuvendor == X86_VENDOR_AMD ||
+   m->cpuvendor == X86_VENDOR_HYGON) {
return amd_mce_is_memory_error(m);
-
} else if (m->cpuvendor == X86_VENDOR_INTEL) {
/*
 * Intel SDM Volume 3B - 15.9.2 Compound Error Codes
@@ -539,6 +539,9 @@ static bool mce_is_correctable(struct mce *m)
if (m->cpuvendor == X86_VENDOR_AMD && m->status & MCI_STATUS_DEFERRED)
return false;
 
+   if (m->cpuvendor == X86_VENDOR_HYGON && m->status & MCI_STATUS_DEFERRED)
+   return false;
+
if (m->status & MCI_STATUS_UC)
return false;
 
@@ -1705,7 +1708,7 @@ static int __mcheck_cpu_ancient_init(struct cpuinfo_x86 
*c)
  */
 static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
 {
-   if (c->x86_vendor == X86_VENDOR_AMD) {
+   if (c->x86_vendor == X86_VENDOR_AMD || c->x86_vendor == 
X86_VENDOR_HYGON) {
mce_flags.overflow_recov = !!cpu_has(c, 
X86_FEATURE_OVERFLOW_RECOV);
mce_flags.succor = !!cpu_has(c, X86_FEATURE_SUCCOR);
mce_flags.smca   = !!cpu_has(c, X86_FEATURE_SMCA);
@@ -1746,6 +1749,11 @@ static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 
*c)
mce_amd_feature_init(c);
break;
}
+
+   case X86_VENDOR_HYGON:
+   mce_hygon_feature_init(c);
+   break;
+
case X86_VENDOR_CENTAUR:
mce_centaur_feature_init(c);
break;
@@ -1971,12 +1979,14 @@ static void mce_disable_error_reporting(void)
 static void vendor_disable_error_reporting(void)
 {
/*
-* Don't clear on Intel or AMD CPUs. Some of these MSRs are socket-wide.
+* Don't clear on Intel or AMD or Hygon CPUs. Some of these MSRs
+* are socket-wide.
 * Disabling them for just a single offlined CPU is bad, since it will
 * inhibit reporting for all shared resources on the socket like the
 * last level cache (LLC), the integrated memory controller (iMC), etc.
 */
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
+   boot_cpu_data.x86_vendor == X86_VENDOR_HYGON ||
boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
return;
 
-- 
2.7.4

[PATCH v8 11/16] x86/kvm: Add Hygon Dhyana support to KVM infrastructure

[Pu Wen]

The Hygon Dhyana CPU has the SVM feature as AMD family 17h does.
So enable the KVM infrastructure support to it.

Signed-off-by: Pu Wen 
Reviewed-by: Borislav Petkov 
---
 arch/x86/include/asm/kvm_emulate.h |  4 
 arch/x86/include/asm/virtext.h |  5 +++--
 arch/x86/kvm/emulate.c | 11 ++-
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/kvm_emulate.h 
b/arch/x86/include/asm/kvm_emulate.h
index 0f82cd9..93c4bf5 100644
--- a/arch/x86/include/asm/kvm_emulate.h
+++ b/arch/x86/include/asm/kvm_emulate.h
@@ -364,6 +364,10 @@ struct x86_emulate_ctxt {
 #define X86EMUL_CPUID_VENDOR_AMDisbetterI_ecx 0x21726574
 #define X86EMUL_CPUID_VENDOR_AMDisbetterI_edx 0x74656273
 
+#define X86EMUL_CPUID_VENDOR_HygonGenuine_ebx 0x6f677948
+#define X86EMUL_CPUID_VENDOR_HygonGenuine_ecx 0x656e6975
+#define X86EMUL_CPUID_VENDOR_HygonGenuine_edx 0x6e65476e
+
 #define X86EMUL_CPUID_VENDOR_GenuineIntel_ebx 0x756e6547
 #define X86EMUL_CPUID_VENDOR_GenuineIntel_ecx 0x6c65746e
 #define X86EMUL_CPUID_VENDOR_GenuineIntel_edx 0x49656e69
diff --git a/arch/x86/include/asm/virtext.h b/arch/x86/include/asm/virtext.h
index 0116b2e..e05e0d3 100644
--- a/arch/x86/include/asm/virtext.h
+++ b/arch/x86/include/asm/virtext.h
@@ -83,9 +83,10 @@ static inline void cpu_emergency_vmxoff(void)
  */
 static inline int cpu_has_svm(const char **msg)
 {
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD) {
+   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) {
if (msg)
-   *msg = "not amd";
+   *msg = "not amd or hygon";
return 0;
}
 
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 106482d..34edf19 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -2711,7 +2711,16 @@ static bool em_syscall_is_enabled(struct 
x86_emulate_ctxt *ctxt)
edx == X86EMUL_CPUID_VENDOR_AMDisbetterI_edx)
return true;
 
-   /* default: (not Intel, not AMD), apply Intel's stricter rules... */
+   /* Hygon ("HygonGenuine") */
+   if (ebx == X86EMUL_CPUID_VENDOR_HygonGenuine_ebx &&
+   ecx == X86EMUL_CPUID_VENDOR_HygonGenuine_ecx &&
+   edx == X86EMUL_CPUID_VENDOR_HygonGenuine_edx)
+   return true;
+
+   /*
+* default: (not Intel, not AMD, not Hygon), apply Intel's
+* stricter rules...
+*/
return false;
 }
 
-- 
2.7.4

[PATCH v8 13/16] ACPI, x86: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana CPU has NONSTOP TSC feature, so enable the ACPI
driver support to it.

Signed-off-by: Pu Wen 
Acked-by: Rafael J. Wysocki 
---
 drivers/acpi/acpi_pad.c   | 1 +
 drivers/acpi/processor_idle.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index 552c1f7..a47676a 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -70,6 +70,7 @@ static void power_saving_mwait_init(void)
 
 #if defined(CONFIG_X86)
switch (boot_cpu_data.x86_vendor) {
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
/*
diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index abb559c..b2131c4 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -205,6 +205,7 @@ static void lapic_timer_state_broadcast(struct 
acpi_processor *pr,
 static void tsc_check_state(int state)
 {
switch (boot_cpu_data.x86_vendor) {
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
case X86_VENDOR_INTEL:
case X86_VENDOR_CENTAUR:
-- 
2.7.4

[PATCH v8 16/16] cpupower, x86: Add Hygon Dhyana support

[Pu Wen]

Tool cpupower is useful to get CPU frequency information and monitor
power stats on Hygon Dhyana platform. So add Hygon Dhyana support to
it by checking vendor and family to share the code path of AMD family
17h.

Signed-off-by: Pu Wen 
---
 tools/power/cpupower/utils/cpufreq-info.c   | 6 --
 tools/power/cpupower/utils/helpers/amd.c| 4 ++--
 tools/power/cpupower/utils/helpers/cpuid.c  | 8 +---
 tools/power/cpupower/utils/helpers/helpers.h| 2 +-
 tools/power/cpupower/utils/helpers/misc.c   | 2 +-
 tools/power/cpupower/utils/idle_monitor/mperf_monitor.c | 3 ++-
 6 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/tools/power/cpupower/utils/cpufreq-info.c 
b/tools/power/cpupower/utils/cpufreq-info.c
index df43cd4..56e54ea 100644
--- a/tools/power/cpupower/utils/cpufreq-info.c
+++ b/tools/power/cpupower/utils/cpufreq-info.c
@@ -170,6 +170,7 @@ static int get_boost_mode(unsigned int cpu)
unsigned long pstates[MAX_HW_PSTATES] = {0,};
 
if (cpupower_cpu_info.vendor != X86_VENDOR_AMD &&
+   cpupower_cpu_info.vendor != X86_VENDOR_HYGON &&
cpupower_cpu_info.vendor != X86_VENDOR_INTEL)
return 0;
 
@@ -190,8 +191,9 @@ static int get_boost_mode(unsigned int cpu)
printf(_("Supported: %s\n"), support ? _("yes") : _("no"));
printf(_("Active: %s\n"), active ? _("yes") : _("no"));
 
-   if (cpupower_cpu_info.vendor == X86_VENDOR_AMD &&
-   cpupower_cpu_info.family >= 0x10) {
+   if ((cpupower_cpu_info.vendor == X86_VENDOR_AMD &&
+cpupower_cpu_info.family >= 0x10) ||
+cpupower_cpu_info.vendor == X86_VENDOR_HYGON) {
ret = decode_pstates(cpu, cpupower_cpu_info.family, b_states,
 pstates, &pstate_no);
if (ret)
diff --git a/tools/power/cpupower/utils/helpers/amd.c 
b/tools/power/cpupower/utils/helpers/amd.c
index bb41cdd..65beaee 100644
--- a/tools/power/cpupower/utils/helpers/amd.c
+++ b/tools/power/cpupower/utils/helpers/amd.c
@@ -45,7 +45,7 @@ static int get_did(int family, union msr_pstate pstate)
 
if (family == 0x12)
t = pstate.val & 0xf;
-   else if (family == 0x17)
+   else if (family == 0x17 || family == 0x18)
t = pstate.fam17h_bits.did;
else
t = pstate.bits.did;
@@ -59,7 +59,7 @@ static int get_cof(int family, union msr_pstate pstate)
int fid, did, cof;
 
did = get_did(family, pstate);
-   if (family == 0x17) {
+   if (family == 0x17 || family == 0x18) {
fid = pstate.fam17h_bits.fid;
cof = 200 * fid / did;
} else {
diff --git a/tools/power/cpupower/utils/helpers/cpuid.c 
b/tools/power/cpupower/utils/helpers/cpuid.c
index 732b0b4..5cc39d4 100644
--- a/tools/power/cpupower/utils/helpers/cpuid.c
+++ b/tools/power/cpupower/utils/helpers/cpuid.c
@@ -8,7 +8,7 @@
 #include "helpers/helpers.h"
 
 static const char *cpu_vendor_table[X86_VENDOR_MAX] = {
-   "Unknown", "GenuineIntel", "AuthenticAMD",
+   "Unknown", "GenuineIntel", "AuthenticAMD", "HygonGenuine",
 };
 
 #if defined(__i386__) || defined(__x86_64__)
@@ -109,6 +109,7 @@ int get_cpu_info(struct cpupower_cpu_info *cpu_info)
fclose(fp);
/* Get some useful CPU capabilities from cpuid */
if (cpu_info->vendor != X86_VENDOR_AMD &&
+   cpu_info->vendor != X86_VENDOR_HYGON &&
cpu_info->vendor != X86_VENDOR_INTEL)
return ret;
 
@@ -124,8 +125,9 @@ int get_cpu_info(struct cpupower_cpu_info *cpu_info)
if (cpuid_level >= 6 && (cpuid_ecx(6) & 0x1))
cpu_info->caps |= CPUPOWER_CAP_APERF;
 
-   /* AMD Boost state enable/disable register */
-   if (cpu_info->vendor == X86_VENDOR_AMD) {
+   /* AMD or Hygon Boost state enable/disable register */
+   if (cpu_info->vendor == X86_VENDOR_AMD ||
+   cpu_info->vendor == X86_VENDOR_HYGON) {
if (ext_cpuid_level >= 0x8007 &&
(cpuid_edx(0x8007) & (1 << 9)))
cpu_info->caps |= CPUPOWER_CAP_AMD_CBP;
diff --git a/tools/power/cpupower/utils/helpers/helpers.h 
b/tools/power/cpupower/utils/helpers/helpers.h
index 41da392..9021396 100644
--- a/tools/power/cpupower/utils/helpers/helpers.h
+++ b/tools/power/cpupower/utils/helpers/helpers.h
@@ -61,7 +61,7 @@ extern int be_verbose;
 
 /* cpuid and cpuinfo helpers  **/
 enum cpupower_cpu_vendor {X86_VENDOR_UNKNOWN = 0, X86_VENDOR_INTEL,
- X86_VENDOR_AMD, X86_VENDOR_MAX};
+ X86_VENDOR_AMD, X86_VENDOR_HYGON, X86_VENDOR_MAX};
 
 #define CPUPOWER_CAP_INV_TSC   0x0001
 #define CPUPOWER_CAP_APERF 0x0002
diff --git a/tools/power/cpupower/utils/helpers/misc.c 
b/tools/power/cpupower/utils/helpers/misc.c
index 80fdf55..f406adc 100644
--- a/to

[PATCH v2] staging: mt7621-mmc: Fix single statement macros in sd.c

[Nishad Kamdar]

This patch fixes a few single statement macros in sd.c.
It converts two macros to inline functions. It removes
five other macros and replaces their usages with calls to
the function being called in the macro definition.
Issue found by checkpatch.

Signed-off-by: Nishad Kamdar 
---
Changes in v2:
  - Convert msdc_gate_clk() and msdc_ungate_clk() to inline functions.
  - Delete msdc_irq_restore(), msdc_vcore_on(), msdc_vcore_off(),
msdc_vdd_on() and msdc_vdd_off() and replace their usages directly
with calls to the function being called by these macros.
---
 drivers/staging/mt7621-mmc/sd.c | 61 +++--
 1 file changed, 13 insertions(+), 48 deletions(-)

diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 7474f9ed7b5b..c36884e33a50 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -103,15 +103,15 @@ static int cd_active_low = 1;
 #if 0 /* --- by chhung */
 /* gate means clock power down */
 static int g_clk_gate = 0;
-#define msdc_gate_clock(id) \
-   do {   \
-   g_clk_gate &= ~(1 << ((id) + PERI_MSDC0_PDN));  \
-   } while (0)
+static inline void msdc_gate_clock(int id)
+{
+   g_clk_gate &= ~(1 << ((id) + PERI_MSDC0_PDN));
+}
 /* not like power down register. 1 means clock on. */
-#define msdc_ungate_clock(id) \
-   do {\
-   g_clk_gate |= 1 << ((id) + PERI_MSDC0_PDN); \
-   } while (0)
+static inline void msdc_ungate_clock(int id)
+{
+   g_clk_gate |= 1 << ((id) + PERI_MSDC0_PDN);
+}
 
 // do we need sync object or not
 void msdc_clk_status(int *status)
@@ -169,11 +169,6 @@ static void msdc_clr_fifo(struct msdc_host *host)
sdr_clr_bits(host->base + MSDC_INTEN, val); \
} while (0)
 
-#define msdc_irq_restore(val) \
-   do {\
-   sdr_set_bits(host->base + MSDC_INTEN, val); \
-   } while (0)
-
 /* clock source for host: global */
 #if defined(CONFIG_SOC_MT7620)
 static u32 hclks[] = {4800}; /* +/- by chhung */
@@ -181,32 +176,6 @@ static u32 hclks[] = {4800}; /* +/- by chhung */
 static u32 hclks[] = {5000}; /* +/- by chhung */
 #endif
 
-//
-// the power for msdc host controller: global
-//always keep the VMC on.
-//
-#define msdc_vcore_on(host) \
-   do {\
-   (void)hwPowerOn(MT65XX_POWER_LDO_VMC, VOL_3300, "SD");  \
-   } while (0)
-#define msdc_vcore_off(host) \
-   do {\
-   (void)hwPowerDown(MT65XX_POWER_LDO_VMC, "SD");  \
-   } while (0)
-
-//
-// the vdd output for card: global
-//   always keep the VMCH on.
-//
-#define msdc_vdd_on(host) \
-   do {\
-   (void)hwPowerOn(MT65XX_POWER_LDO_VMCH, VOL_3300, "SD"); \
-   } while (0)
-#define msdc_vdd_off(host) \
-   do {\
-   (void)hwPowerDown(MT65XX_POWER_LDO_VMCH, "SD"); \
-   } while (0)
-
 #define sdc_is_busy()  (readl(host->base + SDC_STS) & SDC_STS_SDCBUSY)
 #define sdc_is_cmd_busy()  (readl(host->base + SDC_STS) & SDC_STS_CMDBUSY)
 
@@ -364,7 +333,7 @@ static void msdc_set_mclk(struct msdc_host *host, int ddr, 
unsigned int hz)
host->mclk = hz;
msdc_set_timeout(host, host->timeout_ns, host->timeout_clks); // need?
 
-   msdc_irq_restore(flags);
+   sdr_set_bits(host->base + MSDC_INTEN, flags);
 }
 
 /* Fix me. when need to abort */
@@ -453,11 +422,11 @@ void msdc_pin_reset(struct msdc_host *host, int mode)
 static void msdc_core_power(struct msdc_host *host, int on)
 {
if (on && host->core_power == 0) {
-   msdc_vcore_on(host);
+   (void)hwPowerOn(MT65XX_POWER_LDO_VMC, VOL_3300, "SD");
host->core_power = 1;
msleep(1);
} else if (!on && host->core_power == 1) {
-   msdc_vcore_off(host);
+   (void)hwPowerDown(MT65XX_POWER_LDO_VMC, "SD");
host->core_power = 0;
msleep(1);
}
@@ -478,10 +447,8 @@ static void msdc_card_power(struct msdc_host *host, int on)
 {
if (on) {
msdc_pin_config(host, MSDC_PIN_PULL_UP);
-   //msdc_vdd_on(host);  // need todo card detection.
msleep(1);
} else {
-   //msdc_vdd_off(host);
msdc_pin_config(host, MSDC_PIN_PULL_DOWN);
msleep(1);
}
@@ -1750,7 +1717,6 @@ static void msdc_enable_cd_irq(struct msdc_host *host, 
int enable)
 * shoul

[PATCH v8 15/16] EDAC, amd64: Add Hygon Dhyana support

[Pu Wen]

To make AMD64 EDAC and MCE drivers working on Hygon platform, add
support for Hygon Dhyana CPU by using the code path of AMD family
17h.

Signed-off-by: Pu Wen 
---
 drivers/edac/amd64_edac.c | 8 +++-
 drivers/edac/mce_amd.c| 4 +++-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 18aeabb..bf3314b 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -211,7 +211,7 @@ static int __set_scrub_rate(struct amd64_pvt *pvt, u32 
new_bw, u32 min_rate)
 
scrubval = scrubrates[i].scrubval;
 
-   if (pvt->fam == 0x17) {
+   if (pvt->fam == 0x17 || pvt->fam == 0x18) {
__f17h_set_scrubval(pvt, scrubval);
} else if (pvt->fam == 0x15 && pvt->model == 0x60) {
f15h_select_dct(pvt, 0);
@@ -264,6 +264,7 @@ static int get_scrub_rate(struct mem_ctl_info *mci)
break;
 
case 0x17:
+   case 0x18:
amd64_read_pci_cfg(pvt->F6, F17H_SCR_BASE_ADDR, &scrubval);
if (scrubval & BIT(0)) {
amd64_read_pci_cfg(pvt->F6, F17H_SCR_LIMIT_ADDR, 
&scrubval);
@@ -1044,6 +1045,7 @@ static void determine_memory_type(struct amd64_pvt *pvt)
goto ddr3;
 
case 0x17:
+   case 0x18:
if ((pvt->umc[0].dimm_cfg | pvt->umc[1].dimm_cfg) & BIT(5))
pvt->dram_type = MEM_LRDDR4;
else if ((pvt->umc[0].dimm_cfg | pvt->umc[1].dimm_cfg) & BIT(4))
@@ -3188,8 +3190,11 @@ static struct amd64_family_type *per_family_init(struct 
amd64_pvt *pvt)
break;
 
case 0x17:
+   case 0x18:
fam_type= &family_types[F17_CPUS];
pvt->ops= &family_types[F17_CPUS].ops;
+   if (pvt->fam == 0x18)
+   family_types[F17_CPUS].ctl_name = "F18h";
break;
 
default:
@@ -3428,6 +3433,7 @@ static const struct x86_cpu_id amd64_cpuids[] = {
{ X86_VENDOR_AMD, 0x15, X86_MODEL_ANY,  X86_FEATURE_ANY, 0 },
{ X86_VENDOR_AMD, 0x16, X86_MODEL_ANY,  X86_FEATURE_ANY, 0 },
{ X86_VENDOR_AMD, 0x17, X86_MODEL_ANY,  X86_FEATURE_ANY, 0 },
+   { X86_VENDOR_HYGON, 0x18, X86_MODEL_ANY, X86_FEATURE_ANY, 0 },
{ }
 };
 MODULE_DEVICE_TABLE(x86cpu, amd64_cpuids);
diff --git a/drivers/edac/mce_amd.c b/drivers/edac/mce_amd.c
index 2ab4d61..c605089 100644
--- a/drivers/edac/mce_amd.c
+++ b/drivers/edac/mce_amd.c
@@ -1059,7 +1059,8 @@ static int __init mce_amd_init(void)
 {
struct cpuinfo_x86 *c = &boot_cpu_data;
 
-   if (c->x86_vendor != X86_VENDOR_AMD)
+   if (c->x86_vendor != X86_VENDOR_AMD &&
+   c->x86_vendor != X86_VENDOR_HYGON)
return -ENODEV;
 
fam_ops = kzalloc(sizeof(struct amd_decoder_ops), GFP_KERNEL);
@@ -1113,6 +1114,7 @@ static int __init mce_amd_init(void)
break;
 
case 0x17:
+   case 0x18:
xec_mask = 0x3f;
if (!boot_cpu_has(X86_FEATURE_SMCA)) {
printk(KERN_WARNING "Decoding supported only on 
Scalable MCA processors.\n");
-- 
2.7.4

[PATCH v8 14/16] cpufreq, x86: Add Hygon Dhyana support

[Pu Wen]

The Hygon Dhyana CPU supports ACPI P-States feature, and there is
SMBus device(PCI device ID 0x790b) on Hygon platform, so add Hygon
Dhyana support to the cpufreq driver by using the code path of AMD
family 17h.

Signed-off-by: Pu Wen 
Acked-by: Rafael J. Wysocki 
---
 drivers/cpufreq/acpi-cpufreq.c | 5 +
 drivers/cpufreq/amd_freq_sensitivity.c | 9 +++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index b61f4ec..d62fd37 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -61,6 +61,7 @@ enum {
 
 #define INTEL_MSR_RANGE(0x)
 #define AMD_MSR_RANGE  (0x7)
+#define HYGON_MSR_RANGE(0x7)
 
 #define MSR_K7_HWCR_CPB_DIS(1ULL << 25)
 
@@ -95,6 +96,7 @@ static bool boost_state(unsigned int cpu)
rdmsr_on_cpu(cpu, MSR_IA32_MISC_ENABLE, &lo, &hi);
msr = lo | ((u64)hi << 32);
return !(msr & MSR_IA32_MISC_ENABLE_TURBO_DISABLE);
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
rdmsr_on_cpu(cpu, MSR_K7_HWCR, &lo, &hi);
msr = lo | ((u64)hi << 32);
@@ -113,6 +115,7 @@ static int boost_set_msr(bool enable)
msr_addr = MSR_IA32_MISC_ENABLE;
msr_mask = MSR_IA32_MISC_ENABLE_TURBO_DISABLE;
break;
+   case X86_VENDOR_HYGON:
case X86_VENDOR_AMD:
msr_addr = MSR_K7_HWCR;
msr_mask = MSR_K7_HWCR_CPB_DIS;
@@ -225,6 +228,8 @@ static unsigned extract_msr(struct cpufreq_policy *policy, 
u32 msr)
 
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
msr &= AMD_MSR_RANGE;
+   else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+   msr &= HYGON_MSR_RANGE;
else
msr &= INTEL_MSR_RANGE;
 
diff --git a/drivers/cpufreq/amd_freq_sensitivity.c 
b/drivers/cpufreq/amd_freq_sensitivity.c
index be926d9..4ac7c3c 100644
--- a/drivers/cpufreq/amd_freq_sensitivity.c
+++ b/drivers/cpufreq/amd_freq_sensitivity.c
@@ -111,11 +111,16 @@ static int __init amd_freq_sensitivity_init(void)
 {
u64 val;
struct pci_dev *pcidev;
+   unsigned int pci_vendor;
 
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD)
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
+   pci_vendor = PCI_VENDOR_ID_AMD;
+   else if (boot_cpu_data.x86_vendor == X86_VENDOR_HYGON)
+   pci_vendor = PCI_VENDOR_ID_HYGON;
+   else
return -ENODEV;
 
-   pcidev = pci_get_device(PCI_VENDOR_ID_AMD,
+   pcidev = pci_get_device(pci_vendor,
PCI_DEVICE_ID_AMD_KERNCZ_SMBUS, NULL);
 
if (!pcidev) {
-- 
2.7.4

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

[Taniya Das]

Hello Matthias,

Thanks for your review comments.

On 8/29/2018 11:31 PM, Matthias Kaehlcke wrote:

Hi Taniya,

On Tue, Jul 24, 2018 at 04:12:50PM +0530, Taniya Das wrote:

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

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

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0cd8eb7..93a9d72 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -298,3 +298,14 @@ config ARM_PXA2xx_CPUFREQ
  This add the CPUFreq driver support for Intel PXA2xx SOCs.

  If in doubt, say N.
+
+config ARM_QCOM_CPUFREQ_HW
+   bool "QCOM CPUFreq HW driver"
+   depends on ARCH_QCOM
+   help
+Support for the CPUFreq HW driver.
+Some QCOM chipsets have a HW engine to offload the steps
+necessary for changing the frequency of the CPUs. Firmware loaded
+in this engine exposes a programming interface to the OS.
+The driver implements the cpufreq interface for this HW engine.
+Say Y if you want to support CPUFreq HW.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index c1ffeab..ca48a1d 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)+= tegra124-cpufreq.o
  obj-$(CONFIG_ARM_TEGRA186_CPUFREQ)+= tegra186-cpufreq.o
  obj-$(CONFIG_ARM_TI_CPUFREQ)  += ti-cpufreq.o
  obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ)+= vexpress-spc-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)  += qcom-cpufreq-hw.o


  
##
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..ea8f7d1
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INIT_RATE  3UL
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE   32
+
+enum {
+   REG_ENABLE,
+   REG_LUT_TABLE,
+   REG_PERF_STATE,
+
+   REG_ARRAY_SIZE,
+};
+
+struct cpufreq_qcom {
+   struct cpufreq_frequency_table *table;
+   struct device *dev;


'dev' is not used and can be removed.



Thanks, would remove in the next patch.


...

+static int qcom_cpu_resources_init(struct platform_device *pdev,
+  struct device_node *np, unsigned int cpu,
+  unsigned long xo_rate)
+{
+   struct cpufreq_qcom *c;
+   struct resource res;
+   struct device *dev = &pdev->dev;
+   const u16 *offsets;
+   int ret, i, cpu_first, cpu_r;
+   void __iomem *base;
+
+   if (qcom_freq_domain_map[cpu])
+   return 0;
+
+   c = devm_kzalloc(dev, sizeof(*c), GFP_KERNEL);
+   if (!c)
+   return -ENOMEM;
+
+   offsets = of_device_get_match_data(&pdev->dev);
+   if (!offsets)
+   return -EINVAL;
+
+   if (of_address_to_resource(np, 0, &res))
+   return -ENOMEM;
+
+   base = devm_ioremap_resource(dev, &res);
+   if (!base)
+   return -ENOMEM;
+
+   for (i = REG_ENABLE; i < REG_ARRAY_SIZE; i++)
+   c->reg_bases[i] = base + offsets[i];
+
+   /* HW should be in enabled state to proceed */
+   if (!(readl_relaxed(c->reg_bases[REG_ENABLE]) & 0x1)) {
+   dev_err(dev, "%s cpufreq hardware not enabled\n", np->name);
+   return -ENODEV;
+   }
+
+   ret = qcom_get_related_cpus(np, &c->related_cpus);
+   if (ret) {
+   dev_err(dev, "%s failed to get related CPUs\n", np->name);
+   return ret;
+   }
+
+   c->max_cores = cpumask_weight(&c->related_cpus);
+   if (!c->max_cores)
+   return -ENOENT;
+
+   c->xo_rate = xo_rate;
+
+   ret = qcom_cpufreq_hw_read_lut(pdev, c);
+   if (ret) {
+   dev_err(dev, "%s failed to read LUT\n", np->name);
+   return ret;
+   }
+
+   qcom_freq_domain_map[cpu] = c;
+
+   /* Related CPUs */
+   cpu_first = cpumask_first(&c->related_cpus);
+
+   for_each_cpu(cpu_r, &c->related_cpus) {
+   if (cpu_r != cpu_first)
+   qcom_freq_domain_map[cpu_r] =
+   

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

[Taniya Das]

Hi Amit,

On 9/9/2018 8:04 PM, Amit Kucheria wrote:

Hi Taniya,

How much have you stressed this driver?

I tried it on top of an integration branch based on 4.19-rc2 that we
maintain[1] and was able to get the board to reboot fairly easily with
just a few "yes > /dev/null &" instances running in the background.

I even tried with interconnect framework disabled to be sure, and it
still reboots.



The driver is being tested with 4.14 kernel version and I have not yet 
got any reports of reboots. Though I would also try to check with teams 
internally.



I'll continue trying to pinpoint the source of the problem, but it
would be nice to know what tree you're testing against.

Regards,
Amit
[1] 
https://git.linaro.org/people/amit.kucheria/kernel.git/log/?h=integration/qcomlt-automerge-result

On Tue, Jul 24, 2018 at 4:12 PM, Taniya Das  wrote:

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

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

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0cd8eb7..93a9d72 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -298,3 +298,14 @@ config ARM_PXA2xx_CPUFREQ
   This add the CPUFreq driver support for Intel PXA2xx SOCs.

   If in doubt, say N.
+
+config ARM_QCOM_CPUFREQ_HW
+   bool "QCOM CPUFreq HW driver"
+   depends on ARCH_QCOM
+   help
+Support for the CPUFreq HW driver.
+Some QCOM chipsets have a HW engine to offload the steps
+necessary for changing the frequency of the CPUs. Firmware loaded
+in this engine exposes a programming interface to the OS.
+The driver implements the cpufreq interface for this HW engine.
+Say Y if you want to support CPUFreq HW.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index c1ffeab..ca48a1d 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)+= tegra124-cpufreq.o
  obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o
  obj-$(CONFIG_ARM_TI_CPUFREQ)   += ti-cpufreq.o
  obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)  += qcom-cpufreq-hw.o


  
##
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..ea8f7d1
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INIT_RATE  3UL
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE   32
+
+enum {
+   REG_ENABLE,
+   REG_LUT_TABLE,
+   REG_PERF_STATE,
+
+   REG_ARRAY_SIZE,
+};
+
+struct cpufreq_qcom {
+   struct cpufreq_frequency_table *table;
+   struct device *dev;
+   void __iomem *reg_bases[REG_ARRAY_SIZE];
+   cpumask_t related_cpus;
+   unsigned int max_cores;
+   unsigned long xo_rate;
+};
+
+static const u16 cpufreq_qcom_std_offsets[REG_ARRAY_SIZE] = {
+   [REG_ENABLE]= 0x0,
+   [REG_LUT_TABLE] = 0x110,
+   [REG_PERF_STATE]= 0x920,
+};
+
+static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
+
+static int
+qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+unsigned int index)
+{
+   struct cpufreq_qcom *c = policy->driver_data;
+
+   writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+   return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+   struct cpufreq_qcom *c;
+   struct cpufreq_policy *policy;
+   unsigned int index;
+
+   policy = cpufreq_cpu_get_raw(cpu);
+   if (!policy)
+   return 0;
+
+   c = policy->driver_data;
+
+   index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
+   index = min(index, LUT_MAX_ENTRIES - 1);
+
+   return policy->freq_table[index].frequency;
+}
+
+static unsigned int
+qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   struct cpufreq_qcom *c = policy->driver_data;
+   int index;
+
+   index = policy->cached_resolved_idx;
+   if (index < 0)
+   return 0;
+
+  

Re: [PATCH v3 3/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend

[Marc Zyngier]

On Sat, 22 Sep 2018 18:09:09 +0100,
Lina Iyer  wrote:
> 
> On Sat, Sep 22 2018 at 10:29 -0600, Marc Zyngier wrote:
> > Hi Lina,
> > 
> > On Tue, 04 Sep 2018 22:18:08 +0100,
> > Lina Iyer  wrote:
> >> 
> >> During suspend the system may power down some of the system rails. As a
> >> result, the TLMM hw block may not be operational anymore and wakeup
> >> capable GPIOs will not be detected. The PDC however will be operational
> >> and the GPIOs that are routed to the PDC as IRQs can wake the system up.
> >> 
> >> To avoid being interrupted twice (for TLMM and once for PDC IRQ) when a
> >> GPIO trips, use TLMM for active and switch to PDC for suspend. When
> >> entering suspend, disable the TLMM wakeup interrupt and instead enable
> >> the PDC IRQ and revert upon resume.
> >> 
> >> Signed-off-by: Lina Iyer 
> >> ---
> >> Changes in v3:
> >>- Enable PDC-IRQ swap only for edge interrupts
> >> Changes in v2:
> >>- Fix PDC IRQ max port, 126 is the max supported in h/w
> >>- Use PDC hwirq in bitmap, linux numbers could be large
> >>- Setup DISABLE_UNLAZY for both TLMM and PDC IRQs
> >> ---
> [...]
> 
> >> +int __maybe_unused msm_pinctrl_suspend_late(struct device *dev)
> >> +{
> >> +  struct msm_pinctrl *pctrl = dev_get_drvdata(dev);
> >> +  struct irq_data *irqd;
> >> +  unsigned int irq;
> >> +  int i;
> >> +
> >> +  in_suspend = true;
> >> +  for_each_set_bit(i, pctrl->pdc_hwirqs, MAX_PDC_HWIRQ) {
> >> +  irq = irq_find_mapping(pctrl->pdc_irq_domain, i);
> >> +  irqd = irq_get_handler_data(irq);
> >> +  /*
> >> +   * We don't know if the TLMM will be functional
> >> +   * or not, during the suspend. If its functional,
> >> +   * we do not want duplicate interrupts from PDC.
> >> +   * Hence disable the GPIO IRQ and enable PDC IRQ
> >> +   * for edge interrupt only.
> >> +   */
> >> +  if (irqd_is_wakeup_set(irqd) && !irqd_is_level_type(irqd)) {
> >> +  disable_irq_wake(irqd->irq);
> > 
> > There is something I don't quite get here. If the PDC is used to wake
> > up the platform, why is the TLMM interrupt configured as a wakeup
> > source the first place? Or is it just to keep things simple and not
> > have to track it in the TLMM driver itself?
> > 
> True, it need not be. I could just avoid setting the wakeup on the TLMM
> and just use the PDC interrupt as wakeup.
> 
> Also, I am exploring an option that was suggested by Stephen [1] to just
> use the PDC interrupt as a parent of the GPIO IRQ and use a different
> irqchip for the PDC interrupt. I ran into some issue with accessing
> irqchip and irqdata of the PDC interrupt, since the irqchip was not in
> hierarchy with the GPIO's irqchip. I haven't been able to find time to
> resolve the issue that the set_parent_ functions, because of the
> hierarchy.
> 
> Essentially, we have two different mechanisms for GPIO IRQs based on
> whether they can be woken up by the PDC interrupt.
> 
>   GPIO-IRQ --> PDC --> GIC
> 
>   GPIO-IRQ --> TLMM SUMMARY --> GIC
> 
> Do you think the idea is feasible? It would avoid doing all this
> enable/disable at every suspend and even during idle, when the TLMM
> could be powered off.

[me tries to page it all in again]

You could have the PDC as part of the GPIO hierarchy:

GPIO -> PDC -> TLMM -> GIC

and always configure the PDC as a wake-up source. I just wonder if you
can do that without setting up a parallel hierarchy between the PDC
and the GIC. We already have similar things in the tree (see OMAP's
wakeupgen), and it may be worth having a look. The lack of interrupt
replaying on the PDC is quite annoying (I have much stronger words in
mind though), and I'm not sure we can easily fix that one without this
parallel interrupt hack (you need something to inject edge interrupts
in the TLMM).

> 
> 
> >> +  disable_irq(irqd->irq);
> >> +  enable_irq(irq);
> >> +  }
> >> +  }
> > 
> > Given that you're changing in_suspend and parsing the bitmap,
> > shouldn't take the pdc spinlock?
> > 
> Since we are the the only CPU running and suspend/resume (and even idle)
> would be serialized I didn't see a reason for needing a lock.

In that case, what is the purpose of 'in_suspend' if
msm_gpio_irq_set_wake cannot happen during the suspend/resume phases?
It all seems a bit inconsistent.

Thanks,

N,

-- 
Jazz is not dead, it just smell funny.

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

[Taniya Das]

On 9/11/2018 1:00 AM, Matthias Kaehlcke wrote:

On Tue, Jul 24, 2018 at 04:12:50PM +0530, Taniya Das wrote:

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

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

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0cd8eb7..93a9d72 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -298,3 +298,14 @@ config ARM_PXA2xx_CPUFREQ
  This add the CPUFreq driver support for Intel PXA2xx SOCs.

  If in doubt, say N.
+
+config ARM_QCOM_CPUFREQ_HW
+   bool "QCOM CPUFreq HW driver"
+   depends on ARCH_QCOM
+   help
+Support for the CPUFreq HW driver.
+Some QCOM chipsets have a HW engine to offload the steps
+necessary for changing the frequency of the CPUs. Firmware loaded
+in this engine exposes a programming interface to the OS.
+The driver implements the cpufreq interface for this HW engine.
+Say Y if you want to support CPUFreq HW.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index c1ffeab..ca48a1d 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)+= tegra124-cpufreq.o
  obj-$(CONFIG_ARM_TEGRA186_CPUFREQ)+= tegra186-cpufreq.o
  obj-$(CONFIG_ARM_TI_CPUFREQ)  += ti-cpufreq.o
  obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ)+= vexpress-spc-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)  += qcom-cpufreq-hw.o


  
##
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..ea8f7d1
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INIT_RATE  3UL
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE   32
+
+enum {
+   REG_ENABLE,
+   REG_LUT_TABLE,
+   REG_PERF_STATE,
+
+   REG_ARRAY_SIZE,
+};
+
+struct cpufreq_qcom {
+   struct cpufreq_frequency_table *table;
+   struct device *dev;
+   void __iomem *reg_bases[REG_ARRAY_SIZE];
+   cpumask_t related_cpus;
+   unsigned int max_cores;
+   unsigned long xo_rate;
+};
+
+static const u16 cpufreq_qcom_std_offsets[REG_ARRAY_SIZE] = {
+   [REG_ENABLE]= 0x0,
+   [REG_LUT_TABLE] = 0x110,
+   [REG_PERF_STATE]= 0x920,
+};
+
+static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
+
+static int
+qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+unsigned int index)
+{
+   struct cpufreq_qcom *c = policy->driver_data;
+
+   writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+   return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+   struct cpufreq_qcom *c;
+   struct cpufreq_policy *policy;
+   unsigned int index;
+
+   policy = cpufreq_cpu_get_raw(cpu);
+   if (!policy)
+   return 0;
+
+   c = policy->driver_data;
+
+   index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
+   index = min(index, LUT_MAX_ENTRIES - 1);
+
+   return policy->freq_table[index].frequency;
+}
+
+static unsigned int
+qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   struct cpufreq_qcom *c = policy->driver_data;
+   int index;
+
+   index = policy->cached_resolved_idx;
+   if (index < 0)
+   return 0;
+
+   writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+   return policy->freq_table[index].frequency;
+}
+
+static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
+{
+   struct cpufreq_qcom *c;
+
+   c = qcom_freq_domain_map[policy->cpu];
+   if (!c) {
+   pr_err("No scaling support for CPU%d\n", policy->cpu);
+   return -ENODEV;
+   }
+
+   cpumask_copy(policy->cpus, &c->related_cpus);
+
+   policy->fast_switch_possible = true;
+   policy->freq_table = c->table;
+   policy->driver_data = c;
+
+   return 0;
+}
+
+static struct freq_attr *qcom_cpufreq_hw_attr[] = {
+   &cpufreq_freq_attr_scaling_available_freqs,
+   &cpufreq_freq_attr_scaling_bo

Re: [LKP] [x86/pci] 7ffb31888c: PANIC:early_exception

[Pu Wen]

On 2018/9/20 17:39, Thomas Gleixner wrote:

I reproduced the PANIC by running lkp-tests with a Intel machine.

The reason is that the function early_is_amd_nb is called even if
running on Intel machine. At this case the misc_ids is NULL so the
PANIC occur.

I'll rework a patch to solve this problem, either restore the default
value of misc_ids with the original AMD one or not call early_is_amd_nb
on Intel platform.


Return when !AMD and !HYGON is the right thing to do. No point in checking
device ids which cannot happen in the first place.


All right, I reworked a new reversion which will return if it's Intel.

Thanks,
Pu Wen

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

[Taniya Das]

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

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

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

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

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

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

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

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

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

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

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

[Taniya Das]

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

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

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0cd8eb7..93a9d72 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -298,3 +298,14 @@ config ARM_PXA2xx_CPUFREQ
  This add the CPUFreq driver support for Intel PXA2xx SOCs.

  If in doubt, say N.
+
+config ARM_QCOM_CPUFREQ_HW
+   bool "QCOM CPUFreq HW driver"
+   depends on ARCH_QCOM
+   help
+Support for the CPUFreq HW driver.
+Some QCOM chipsets have a HW engine to offload the steps
+necessary for changing the frequency of the CPUs. Firmware loaded
+in this engine exposes a programming interface to the OS.
+The driver implements the cpufreq interface for this HW engine.
+Say Y if you want to support CPUFreq HW.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index c1ffeab..ca48a1d 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)+= tegra124-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA186_CPUFREQ) += tegra186-cpufreq.o
 obj-$(CONFIG_ARM_TI_CPUFREQ)   += ti-cpufreq.o
 obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
+obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)  += qcom-cpufreq-hw.o


 
##
diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c 
b/drivers/cpufreq/qcom-cpufreq-hw.c
new file mode 100644
index 000..43107ab
--- /dev/null
+++ b/drivers/cpufreq/qcom-cpufreq-hw.c
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LUT_MAX_ENTRIES40U
+#define CORE_COUNT_VAL(val)(((val) & (GENMASK(18, 16))) >> 16)
+#define LUT_ROW_SIZE   32
+#define CLK_HW_DIV 2
+
+enum {
+   REG_ENABLE,
+   REG_LUT_TABLE,
+   REG_PERF_STATE,
+
+   REG_ARRAY_SIZE,
+};
+
+struct cpufreq_qcom {
+   struct cpufreq_frequency_table *table;
+   void __iomem *reg_bases[REG_ARRAY_SIZE];
+   cpumask_t related_cpus;
+   unsigned int max_cores;
+   unsigned long xo_rate;
+   unsigned long cpu_hw_rate;
+};
+
+static const u16 cpufreq_qcom_std_offsets[REG_ARRAY_SIZE] = {
+   [REG_ENABLE]= 0x0,
+   [REG_LUT_TABLE] = 0x110,
+   [REG_PERF_STATE]= 0x920,
+};
+
+static struct cpufreq_qcom *qcom_freq_domain_map[NR_CPUS];
+
+static int
+qcom_cpufreq_hw_target_index(struct cpufreq_policy *policy,
+unsigned int index)
+{
+   struct cpufreq_qcom *c = policy->driver_data;
+
+   writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+   return 0;
+}
+
+static unsigned int qcom_cpufreq_hw_get(unsigned int cpu)
+{
+   struct cpufreq_qcom *c;
+   struct cpufreq_policy *policy;
+   unsigned int index;
+
+   policy = cpufreq_cpu_get_raw(cpu);
+   if (!policy)
+   return 0;
+
+   c = policy->driver_data;
+
+   index = readl_relaxed(c->reg_bases[REG_PERF_STATE]);
+   index = min(index, LUT_MAX_ENTRIES - 1);
+
+   return policy->freq_table[index].frequency;
+}
+
+static unsigned int
+qcom_cpufreq_hw_fast_switch(struct cpufreq_policy *policy,
+   unsigned int target_freq)
+{
+   struct cpufreq_qcom *c = policy->driver_data;
+   int index;
+
+   index = policy->cached_resolved_idx;
+   if (index < 0)
+   return 0;
+
+   writel_relaxed(index, c->reg_bases[REG_PERF_STATE]);
+
+   return policy->freq_table[index].frequency;
+}
+
+static int qcom_cpufreq_hw_cpu_init(struct cpufreq_policy *policy)
+{
+   struct cpufreq_qcom *c;
+
+   c = qcom_freq_domain_map[policy->cpu];
+   if (!c) {
+   pr_err("No scaling support for CPU%d\n", policy->cpu);
+   return -ENODEV;
+   }
+
+   cpumask_copy(policy->cpus, &c->related_cpus);
+
+   policy->fast_switch_possible = true;
+   policy->freq_table = c->table;
+   policy->driver_data = c;
+
+   return 0;
+}
+
+static struct freq_attr *qcom_cpufreq_hw_attr[] = {
+   &cpufreq_freq_attr_scaling_available_freqs,
+   &cpufreq_freq_attr_scaling_boost_freqs,
+   NULL
+};
+
+static struct cpufreq_driver cpufreq_qcom_hw_driver = {
+   .flags  = CPUFREQ_STICKY | 

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

[Taniya Das]

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

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

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

Re: [PATCH] mtd: rawnand: denali: add DT property to specify skipped bytes in OOB

[Masahiro Yamada]

2018-09-22 4:11 GMT-04:00 Boris Brezillon :
> On Sat, 22 Sep 2018 09:41:11 +0200
> Miquel Raynal  wrote:
>
>> Hi Masahiro,
>>
>> Masahiro Yamada  wrote on Sat, 8 Sep
>> 2018 01:10:25 +0900:
>>
>> > Hi Boris,
>> >
>> > 2018-09-07 23:53 GMT+09:00 Boris Brezillon :
>> > > On Fri, 7 Sep 2018 23:42:53 +0900
>> > > Masahiro Yamada  wrote:
>> > >
>> > >> Hi Boris,
>> > >>
>> > >> 2018-09-07 23:08 GMT+09:00 Boris Brezillon 
>> > >> :
>> > >> > Hi Masahiro,
>> > >> >
>> > >> > On Fri,  7 Sep 2018 19:56:23 +0900
>> > >> > Masahiro Yamada  wrote:
>> > >> >
>> > >> >> NAND devices need additional data area (OOB) for error correction,
>> > >> >> but it is also used for Bad Block Marker (BBM).  In many cases, the
>> > >> >> first byte in OOB is used for BBM, but the location actually depends
>> > >> >> on chip vendors.  The NAND controller should preserve the precious
>> > >> >> BBM to keep track of bad blocks.
>> > >> >>
>> > >> >> In Denali IP, the SPARE_AREA_SKIP_BYTES register is used to specify
>> > >> >> the number of bytes to skip from the start of OOB.  The ECC engine
>> > >> >> will automatically skip the specified number of bytes when it gets
>> > >> >> access to OOB area.
>> > >> >>
>> > >> >> The same value for SPARE_AREA_SKIP_BYTES should be used between
>> > >> >> firmware and the operating system if you intend to use the NAND
>> > >> >> device across the control hand-off.
>> > >> >>
>> > >> >> In fact, the current denali.c code expects firmware to have already
>> > >> >> set the SPARE_AREA_SKIP_BYTES register, then reads the value out.
>> > >> >>
>> > >> >> If no firmware (or bootloader) has initialized the controller, the
>> > >> >> register value is zero, which is the default after power-on-reset.
>> > >> >>
>> > >> >> In other words, the Linux driver cannot initialize the controller
>> > >> >> by itself.  You cannot support the reset control either because
>> > >> >> resetting the controller will get register values lost.
>> > >> >>
>> > >> >> This commit adds a way to specify it via DT.  If the property
>> > >> >> "denali,oob-skip-bytes" exists, the value will be set to the 
>> > >> >> register.
>> > >> >
>> > >> > Hm, do we really need to make this config customizable? I mean, either
>> > >> > you have a large-page NAND (page > 512 bytes) and the 2 first bytes
>> > >> > must be reserved for the BBM or you have a small-page NAND and the BBM
>> > >> > is at position 4 and 5. Are you sure people configure that 
>> > >> > differently?
>> > >> > Don't you always have SPARE_AREA_SKIP_BYTES set to 6 or 2?
>> > >>
>> > >>
>> > >> As I said in the patch description,
>> > >> I need to use the same SPARE_AREA_SKIP_BYTES value
>> > >> across firmware, boot-loader, Linux, and whatever.
>> > >>
>> > >> I want to set the value to 8 for my platform
>> > >> because the on-chip boot ROM expects 8.
>> > >> I cannot change it since the boot ROM is hard-wired.
>> > >>
>> > >>
>> > >> The boot ROM skips 8 bytes in OOB
>> > >> when it loads images from the on-board NAND device.
>> > >>
>> > >> So, when I update the image from U-Boot or Linux,
>> > >> I need to make sure to set the register to 8.
>> > >>
>> > >> If I update the image with a different value,
>> > >> the Boot ROM fails to boot.
>> > >>
>> > >>
>> > >>
>> > >> When the system has booted from NAND,
>> > >> the register is already set to 8.  It works.
>> > >>
>> > >> However, when the system has booted from eMMC,
>> > >> the register is not initialized by anyone.
>> > >> I am searching for a way to set the register to 8
>> > >> in this case.
>
> Maybe there's a solution which does not involve attaching a per-compat
> value or adding a DT prop. If the FW/bootloader has not initialized this
> register the value is 0, right? Why not testing the value and
> assigning it to the default (8) if it's not been initialized by the
> bootloader. That shouldn't break existing platforms since I don't think
> 0 is a valid value anyway.
>
> denali->oob_skip_bytes = ioread32(denali->reg +
>   SPARE_AREA_SKIP_BYTES);
> if (!denali->oob_skip_bytes) {
> denali->oob_skip_bytes = DEFAULT_OOB_SKIP_BYTES;
> iowrite32(denali->oob_skip_bytes,
>   denali->reg + SPARE_AREA_SKIP_BYTES);
> }
>


I prefer per-compatible values to a fixed default.


I'd like to set the register to 8 unless set otherwise
because the boot ROM on my platform (Socionext UniPhier SoCs)
uses that value.

Other platforms like Altera SOCFPGA may want to use a different value
(at least, I do not know what is the preferred value).



-- 
Best Regards
Masahiro Yamada

Acknowledge the receipt of this message

[Col. Hussein Harmush]

Please i need your assistance my dear,

I am Col. Hussein Harmush, An Army officer from Syria but now living
with the United Nations on asylum. I want to seek your assistance in
the following ways:

1. To assist me look for a profitable business opportunity in your
country where I can invest  to sustain my living until the ongoing
civil war and political crisis in my country (Syria) is over.

2. To assist me purchase a living home in your country, I have a sum
of $5,000,000.00 USD (Five Million United States Dollars Only) with a
financial institution.

I will compensate you greatly for this help,i hope your Government
will grant me a Residence Permit after the funds hits your Bank
account. Reply me now !

Thanks and Regards,
Col. Hussein Harmush.

Re: [PATCH] iio: magnetometer: Add support for PNI RM3100 9-axis magnetometer

[Dan Carpenter]

Hi Song,

I love your patch! Perhaps something to improve:

url:
https://github.com/0day-ci/linux/commits/Song-Qiang/iio-magnetometer-Add-support-for-PNI-RM3100-9-axis-magnetometer/20180920-215124
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg

smatch warnings:
drivers/iio/magnetometer/rm3100-core.c:235 rm3100_set_samp_freq() warn: 
inconsistent returns 'mutex:&data->lock'.
  Locked on:   line 206
  Unlocked on: line 194
drivers/iio/magnetometer/rm3100-core.c:319 rm3100_trigger_handler() warn: 
inconsistent returns 'mutex:&data->lock'.
  Locked on:   line 310
  Unlocked on: line 319

# 
https://github.com/0day-ci/linux/commit/0345472c15bab336397b25a25eb76a9f8586faf0
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 0345472c15bab336397b25a25eb76a9f8586faf0
vim +235 drivers/iio/magnetometer/rm3100-core.c

0345472c Song Qiang 2018-09-20  183  
0345472c Song Qiang 2018-09-20  184  static int rm3100_set_samp_freq(struct 
rm3100_data *data, int val, int val2)
0345472c Song Qiang 2018-09-20  185  {
0345472c Song Qiang 2018-09-20  186 struct regmap *regmap = data->regmap;
0345472c Song Qiang 2018-09-20  187 int cycle_count;
0345472c Song Qiang 2018-09-20  188 int ret;
0345472c Song Qiang 2018-09-20  189 int i;
0345472c Song Qiang 2018-09-20  190  
0345472c Song Qiang 2018-09-20  191 /* All cycle count registers use the 
same value. */
0345472c Song Qiang 2018-09-20  192 ret = regmap_read(regmap, RM_REG_CCXL, 
&cycle_count);
0345472c Song Qiang 2018-09-20  193 if (cycle_count < 0)
0345472c Song Qiang 2018-09-20  194 return cycle_count;
0345472c Song Qiang 2018-09-20  195  
0345472c Song Qiang 2018-09-20  196 for (i = 0; i < RM_SAMP_NUM; i++) {
0345472c Song Qiang 2018-09-20  197 if (val == 
rm3100_samp_rates[i][0] &&
0345472c Song Qiang 2018-09-20  198 val2 == 
rm3100_samp_rates[i][1])
0345472c Song Qiang 2018-09-20  199 break;
0345472c Song Qiang 2018-09-20  200 }
0345472c Song Qiang 2018-09-20  201  
0345472c Song Qiang 2018-09-20  202 if (i != RM_SAMP_NUM) {
0345472c Song Qiang 2018-09-20  203 mutex_lock(&data->lock);
^^^
0345472c Song Qiang 2018-09-20  204 ret = regmap_write(regmap, 
RM_REG_TMRC, i + RM_TMRC_OFFSET);
0345472c Song Qiang 2018-09-20  205 if (ret < 0)
0345472c Song Qiang 2018-09-20  206 return ret;
^^
goto unlock;  there are a bunch of these.

0345472c Song Qiang 2018-09-20  207  
0345472c Song Qiang 2018-09-20  208 /* Checking if cycle count 
registers need changing. */
0345472c Song Qiang 2018-09-20  209 if (val == 600 && cycle_count 
== 200) {
0345472c Song Qiang 2018-09-20  210 for (i = 0; i < 3; i++) 
{
0345472c Song Qiang 2018-09-20  211 
regmap_write(regmap, RM_REG_CCXL + 2 * i, 100);
0345472c Song Qiang 2018-09-20  212 if (ret < 0)
0345472c Song Qiang 2018-09-20  213 return 
ret;
0345472c Song Qiang 2018-09-20  214 }
0345472c Song Qiang 2018-09-20  215 } else if (val != 600 && 
cycle_count == 100) {
0345472c Song Qiang 2018-09-20  216 for (i = 0; i < 3; i++) 
{
0345472c Song Qiang 2018-09-20  217 
regmap_write(regmap, RM_REG_CCXL + 2 * i, 200);
0345472c Song Qiang 2018-09-20  218 if (ret < 0)
0345472c Song Qiang 2018-09-20  219 return 
ret;
0345472c Song Qiang 2018-09-20  220 }
0345472c Song Qiang 2018-09-20  221 }
0345472c Song Qiang 2018-09-20  222 /* Writing TMRC registers 
requires CMM reset. */
0345472c Song Qiang 2018-09-20  223 ret = regmap_write(regmap, 
RM_REG_CMM, 0);
0345472c Song Qiang 2018-09-20  224 if (ret < 0)
0345472c Song Qiang 2018-09-20  225 return ret;
0345472c Song Qiang 2018-09-20  226 ret = regmap_write(regmap, 
RM_REG_CMM, RM_CMM_PMX |
0345472c Song Qiang 2018-09-20  227 RM_CMM_PMY | RM_CMM_PMZ 
| RM_CMM_START);
0345472c Song Qiang 2018-09-20  228 if (ret < 0)
0345472c Song Qiang 2018-09-20  229 return ret;
0345472c Song Qiang 2018-09-20  230 mutex_unlock(&data->lock);
0345472c Song Qiang 2018-09-20  231  
0345472c Song Qiang 2018-09-20  232 data->conversion_time = 
rm3100_samp_rates[i][2] + 3000;
0345472c Song Qiang 2018-09-20  233 return 0;
0345472c Song Qiang 2018-09-20  234 }
0345472c Song Qiang 2018-09-20 @235 return -EINVAL;
0345472c Song Qiang 2018-09-20  236  }
0345472c Song Qiang 2018-09-20  237  
0345472c Song Qian

Re: [PATCH v8 07/16] x86/pci: Add Hygon Dhyana support to PCI and north bridge

[Borislav Petkov]

On Sun, Sep 23, 2018 at 05:35:13PM +0800, Pu Wen wrote:
> As Hygon registered its PCI Vendor ID as a new one 0x1d94, and there
> are PCI Devices 0x1450/0x1463/0x1464 for Host bridge on Hygon Dhyana
> platform, so add Hygon Dhyana support to the PCI and north bridge
> subsystem by using the code path of AMD family 17h.
> 
> To prevent further checking PCI device ids which cannot happen both on
> Hygon and Intel platform, the function amd_gart_present should return
> if it's not a AMD CPU.
> 
> Signed-off-by: Pu Wen 
> Acked-by: Bjorn Helgaas  # pci_ids.h
> Reviewed-by: Borislav Petkov 

A note for your future submissions: if you rework a patch in a
non-trivial way, you *must* drop Reviewed-by/Acked-by tags because they
are not valid anymore.

In this case I guess Bjorn's tag can stay because he's acking the
pci_ids.h addition but mine definitely must go.

Thx.

-- 
Regards/Gruss,
Boris.

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

[PATCH] gpio: mockup: use device properties instead of platform_data

[Bartosz Golaszewski]

Some users want to introduce device tree support to the mockup driver.
Let's make it easier by switching to using generic device properties.
The driver stays compatible with previous use cases and after this
conversion there'll be no need to change the way probing of mockup
GPIO chips works.

Tested with libgpiod test suite.

Signed-off-by: Bartosz Golaszewski 
---
 drivers/gpio/gpio-mockup.c | 82 --
 1 file changed, 51 insertions(+), 31 deletions(-)

diff --git a/drivers/gpio/gpio-mockup.c b/drivers/gpio/gpio-mockup.c
index d66b7a768ecd..4e66bd83b76c 100644
--- a/drivers/gpio/gpio-mockup.c
+++ b/drivers/gpio/gpio-mockup.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "gpiolib.h"
 
@@ -28,6 +29,8 @@
  * of GPIO lines.
  */
 #define GPIO_MOCKUP_MAX_RANGES (GPIO_MOCKUP_MAX_GC * 2)
+/* Maximum of three properties + the sentinel. */
+#define GPIO_MOCKUP_MAX_PROP   4
 
 #define gpio_mockup_err(...)   pr_err(GPIO_MOCKUP_NAME ": " __VA_ARGS__)
 
@@ -59,13 +62,6 @@ struct gpio_mockup_dbgfs_private {
int offset;
 };
 
-struct gpio_mockup_platform_data {
-   int base;
-   int ngpio;
-   int index;
-   bool named_lines;
-};
-
 static int gpio_mockup_ranges[GPIO_MOCKUP_MAX_RANGES];
 static int gpio_mockup_num_ranges;
 module_param_array(gpio_mockup_ranges, int, &gpio_mockup_num_ranges, 0400);
@@ -255,26 +251,37 @@ static int gpio_mockup_name_lines(struct device *dev,
 
 static int gpio_mockup_probe(struct platform_device *pdev)
 {
-   struct gpio_mockup_platform_data *pdata;
struct gpio_mockup_chip *chip;
struct gpio_chip *gc;
-   int rv, base, ngpio;
struct device *dev;
-   char *name;
+   const char *name;
+   int rv, base;
+   u16 ngpio;
 
dev = &pdev->dev;
-   pdata = dev_get_platdata(dev);
-   base = pdata->base;
-   ngpio = pdata->ngpio;
+
+   rv = device_property_read_u32(dev, "gpio-base", &base);
+   if (rv && rv == -ENOENT)
+   base = -1;
+
+   rv = device_property_read_u16(dev, "nr-gpios", &ngpio);
+   if (rv)
+   return rv;
+
+   rv = device_property_read_string(dev, "chip-name", &name);
+   if (rv)
+   name = NULL;
 
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
return -ENOMEM;
 
-   name = devm_kasprintf(dev, GFP_KERNEL, "%s-%c",
- pdev->name, pdata->index);
-   if (!name)
-   return -ENOMEM;
+   if (!name) {
+   name = devm_kasprintf(dev, GFP_KERNEL,
+ "%s-%c", pdev->name, pdev->id + 'A');
+   if (!name)
+   return -ENOMEM;
+   }
 
gc = &chip->gc;
gc->base = base;
@@ -295,7 +302,7 @@ static int gpio_mockup_probe(struct platform_device *pdev)
if (!chip->lines)
return -ENOMEM;
 
-   if (pdata->named_lines) {
+   if (device_property_read_bool(dev, "named-gpio-lines")) {
rv = gpio_mockup_name_lines(dev, chip);
if (rv)
return rv;
@@ -339,9 +346,11 @@ static void gpio_mockup_unregister_pdevs(void)
 
 static int __init gpio_mockup_init(void)
 {
-   int i, num_chips, err = 0, index = 'A';
-   struct gpio_mockup_platform_data pdata;
+   struct property_entry properties[GPIO_MOCKUP_MAX_PROP];
+   int i, prop, num_chips, err = 0, base;
+   struct platform_device_info pdevinfo;
struct platform_device *pdev;
+   u16 ngpio;
 
if ((gpio_mockup_num_ranges < 2) ||
(gpio_mockup_num_ranges % 2) ||
@@ -371,17 +380,28 @@ static int __init gpio_mockup_init(void)
}
 
for (i = 0; i < num_chips; i++) {
-   pdata.index = index++;
-   pdata.base = gpio_mockup_range_base(i);
-   pdata.ngpio = pdata.base < 0
-   ? gpio_mockup_range_ngpio(i)
-   : gpio_mockup_range_ngpio(i) - pdata.base;
-   pdata.named_lines = gpio_mockup_named_lines;
-
-   pdev = platform_device_register_resndata(NULL,
-GPIO_MOCKUP_NAME,
-i, NULL, 0, &pdata,
-sizeof(pdata));
+   memset(properties, 0, sizeof(properties));
+   memset(&pdevinfo, 0, sizeof(pdevinfo));
+   prop = 0;
+
+   base = gpio_mockup_range_base(i);
+   if (base >= 0)
+   properties[prop++] = PROPERTY_ENTRY_U32("gpio-base",
+   base);
+
+   ngpio = base < 0 ? gpio_mockup_range_ngpio(i)
+: gpio_mockup_range_ngpio(i) - base;
+   properties[prop++] = PROPERTY_ENTRY_U

Re: [PATCH TRIVIAL] Punctuation fixes

[Miguel Ojeda]

Hi Richard,

On Sun, Sep 23, 2018 at 10:59 AM, Richard Weinberger
 wrote:
> On Sun, Sep 23, 2018 at 3:00 AM Miguel Ojeda
>  wrote:
>>
>> Hi Diego,
>>
>> A few things, since it looks like this is your first patch.
>
> git log...

Oops! I guess I mistyped the search string, sorry Diego!

Cheers,
Miguel

Re: [PATCH 2/3] mtd: rawnand: stm32_fmc2: add STM32 FMC2 NAND flash controller driver

[Miquel Raynal]

Hi Christophe,

 wrote on Mon, 17 Sep 2018 17:47:39 +0200:

> From: Christophe Kerello 
> 
> The driver adds the support for the STMicroelectronics FMC2 NAND
> Controller found on STM32MP SOCs.
> 
> This patch is based on FMC2 command sequencer.
> The purpose of the command sequencer is to facilitate the programming
> and the reading of NAND flash pages with the ECC and to free the CPU
> of sequencing tasks.
> It requires one DMA channel for write and two DMA channels for read
> operations.
> 
> Only NAND_ECC_HW mode is actually supported.
> The driver supports a maximum 8k page size.
> The following ECC strength and step size are currently supported:
>  - nand-ecc-strength = <8>, nand-ecc-step-size = <512> (BCH8)
>  - nand-ecc-strength = <4>, nand-ecc-step-size = <512> (BCH4)
>  - nand-ecc-strength = <1>, nand-ecc-step-size = <512> (Extended ecc
>based on HAMMING)
> 
> This patch has been tested on Micron MT29F8G08ABACAH4 and
> MT29F8G16ABACAH4
> 
> Signed-off-by: Christophe Kerello 
> ---


[...]

> +/* NAND callbacks setup */
> +static void stm32_fmc2_nand_callbacks_setup(struct stm32_fmc2 *fmc2)
> +{
> + struct nand_chip *chip = &fmc2->chip;
> +
> + /* Specific callbacks to read/write a page */
> + chip->ecc.correct = stm32_fmc2_ham_correct;
> + chip->ecc.write_page = stm32_fmc2_sequencer_write_page;
> + chip->ecc.read_page = stm32_fmc2_sequencer_read_page;
> + chip->ecc.write_page_raw = stm32_fmc2_sequencer_write_page_raw;
> + chip->ecc.read_page_raw = stm32_fmc2_sequencer_read_page_raw;

Are you sure all the tests in mtd-utils are successful?


Thanks,
Miquèl

Re: [PATCH v5] mtd: rawnand: ams-delta: use GPIO lookup table

[Miquel Raynal]

Hi Janusz,

Janusz Krzysztofik  wrote on Thu, 20 Sep 2018
00:17:29 +0200:

> Now as Amstrad Delta board - the only user of this driver - provides
> GPIO lookup tables, switch from GPIO numbers to GPIO descriptors and
> use the table to locate required GPIO pins.
> 
> Declare static variables for storing GPIO descriptors and replace
> gpio_ function calls with their gpiod_ equivalents.
> 
> Pin naming used by the driver should be followed while respective GPIO
> lookup table is initialized by a board init code.
> 
> Signed-off-by: Janusz Krzysztofik 
> Acked-by: Boris Brezillon 
> Acked-by: Miquel Raynal 

Applied on nand/next.

Thanks,
Miquèl

Re: [PATCH v5 0/3] mtd: rawnand: ams-delta: Cleanups and optimizations

[Miquel Raynal]

Hi Janusz,

Janusz Krzysztofik  wrote on Thu, 20 Sep 2018
00:52:52 +0200:

> This series consist of possibly ready to apply patches extracted from
> a former one titled "mtd: rawnand:  ams-delta: Use GPIO API for data I/O".
> Remaining patches implementing conversion of data I/O to GPIO have been
> postponed until gpiolib is optimized to ensure sufficient performance.
> 
> 
> Janusz Krzysztofik (3):
>   mtd: rawnand: ams-delta: show parent device in sysfs
>   mtd: rawnand: ams-delta: Use private structure
>   mtd: rawnand: ams-delta: Set port direction when needed
> 
> 

Series applied on nand/next.

Thanks,
Miquèl

Re: [PATCH] mtd: rawnand: Use proper enum for flctl_dma_fifo0_transfer

[Miquel Raynal]

Hi Nathan,

Nathan Chancellor  wrote on Thu, 20 Sep 2018
16:30:25 -0700:

> Clang warns when one enumerated type is converted implicitly to another:
> 
> drivers/mtd/nand/raw/sh_flctl.c:483:46: warning: implicit conversion
> from enumeration type 'enum dma_transfer_direction' to different
> enumeration type 'enum dma_data_direction' [-Wenum-conversion]
> flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_DEV_TO_MEM) > 
> 0)
> ^~
> drivers/mtd/nand/raw/sh_flctl.c:542:46: warning: implicit conversion
> from enumeration type 'enum dma_transfer_direction' to different
> enumeration type 'enum dma_data_direction' [-Wenum-conversion]
> flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_MEM_TO_DEV) > 
> 0)
> ^~
> 2 warnings generated.
> 
> Use the proper enums from dma_data_direction to satisfy Clang.
> 
> DMA_MEM_TO_DEV = DMA_TO_DEVICE = 1
> DMA_DEV_TO_MEM = DMA_FROM_DEVICE = 2
> 
> Reported-by: Nick Desaulniers 
> Signed-off-by: Nathan Chancellor 
> ---
>  drivers/mtd/nand/raw/sh_flctl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/sh_flctl.c b/drivers/mtd/nand/raw/sh_flctl.c
> index c0c0798f268f..4d20d033de7b 100644
> --- a/drivers/mtd/nand/raw/sh_flctl.c
> +++ b/drivers/mtd/nand/raw/sh_flctl.c
> @@ -480,7 +480,7 @@ static void read_fiforeg(struct sh_flctl *flctl, int 
> rlen, int offset)
>  
>   /* initiate DMA transfer */
>   if (flctl->chan_fifo0_rx && rlen >= 32 &&
> - flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_DEV_TO_MEM) > 0)
> + flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_FROM_DEVICE) > 0)
>   goto convert;   /* DMA success */
>  
>   /* do polling transfer */
> @@ -539,7 +539,7 @@ static void write_ec_fiforeg(struct sh_flctl *flctl, int 
> rlen,
>  
>   /* initiate DMA transfer */
>   if (flctl->chan_fifo0_tx && rlen >= 32 &&
> - flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_MEM_TO_DEV) > 0)
> + flctl_dma_fifo0_transfer(flctl, buf, rlen, DMA_TO_DEVICE) > 0)
>   return; /* DMA success */
>  
>   /* do polling transfer */


Applied on nand/next with the subject prefix changed to

mtd: rawnand: sh_flctl:


Thanks,
Miquèl

Re: [PATCH] mtd: rawnand: denali: add DT property to specify skipped bytes in OOB

[Miquel Raynal]

Hi Masahiro,

Masahiro Yamada  wrote on Sun, 23 Sep
2018 06:38:40 -0400:

> 2018-09-22 4:11 GMT-04:00 Boris Brezillon :
> > On Sat, 22 Sep 2018 09:41:11 +0200
> > Miquel Raynal  wrote:
> >  
> >> Hi Masahiro,
> >>
> >> Masahiro Yamada  wrote on Sat, 8 Sep
> >> 2018 01:10:25 +0900:
> >>  
> >> > Hi Boris,
> >> >
> >> > 2018-09-07 23:53 GMT+09:00 Boris Brezillon 
> >> > :  
> >> > > On Fri, 7 Sep 2018 23:42:53 +0900
> >> > > Masahiro Yamada  wrote:
> >> > >  
> >> > >> Hi Boris,
> >> > >>
> >> > >> 2018-09-07 23:08 GMT+09:00 Boris Brezillon 
> >> > >> :  
> >> > >> > Hi Masahiro,
> >> > >> >
> >> > >> > On Fri,  7 Sep 2018 19:56:23 +0900
> >> > >> > Masahiro Yamada  wrote:
> >> > >> >  
> >> > >> >> NAND devices need additional data area (OOB) for error correction,
> >> > >> >> but it is also used for Bad Block Marker (BBM).  In many cases, the
> >> > >> >> first byte in OOB is used for BBM, but the location actually 
> >> > >> >> depends
> >> > >> >> on chip vendors.  The NAND controller should preserve the precious
> >> > >> >> BBM to keep track of bad blocks.
> >> > >> >>
> >> > >> >> In Denali IP, the SPARE_AREA_SKIP_BYTES register is used to specify
> >> > >> >> the number of bytes to skip from the start of OOB.  The ECC engine
> >> > >> >> will automatically skip the specified number of bytes when it gets
> >> > >> >> access to OOB area.
> >> > >> >>
> >> > >> >> The same value for SPARE_AREA_SKIP_BYTES should be used between
> >> > >> >> firmware and the operating system if you intend to use the NAND
> >> > >> >> device across the control hand-off.
> >> > >> >>
> >> > >> >> In fact, the current denali.c code expects firmware to have already
> >> > >> >> set the SPARE_AREA_SKIP_BYTES register, then reads the value out.
> >> > >> >>
> >> > >> >> If no firmware (or bootloader) has initialized the controller, the
> >> > >> >> register value is zero, which is the default after power-on-reset.
> >> > >> >>
> >> > >> >> In other words, the Linux driver cannot initialize the controller
> >> > >> >> by itself.  You cannot support the reset control either because
> >> > >> >> resetting the controller will get register values lost.
> >> > >> >>
> >> > >> >> This commit adds a way to specify it via DT.  If the property
> >> > >> >> "denali,oob-skip-bytes" exists, the value will be set to the 
> >> > >> >> register.  
> >> > >> >
> >> > >> > Hm, do we really need to make this config customizable? I mean, 
> >> > >> > either
> >> > >> > you have a large-page NAND (page > 512 bytes) and the 2 first bytes
> >> > >> > must be reserved for the BBM or you have a small-page NAND and the 
> >> > >> > BBM
> >> > >> > is at position 4 and 5. Are you sure people configure that 
> >> > >> > differently?
> >> > >> > Don't you always have SPARE_AREA_SKIP_BYTES set to 6 or 2?  
> >> > >>
> >> > >>
> >> > >> As I said in the patch description,
> >> > >> I need to use the same SPARE_AREA_SKIP_BYTES value
> >> > >> across firmware, boot-loader, Linux, and whatever.
> >> > >>
> >> > >> I want to set the value to 8 for my platform
> >> > >> because the on-chip boot ROM expects 8.
> >> > >> I cannot change it since the boot ROM is hard-wired.
> >> > >>
> >> > >>
> >> > >> The boot ROM skips 8 bytes in OOB
> >> > >> when it loads images from the on-board NAND device.
> >> > >>
> >> > >> So, when I update the image from U-Boot or Linux,
> >> > >> I need to make sure to set the register to 8.
> >> > >>
> >> > >> If I update the image with a different value,
> >> > >> the Boot ROM fails to boot.
> >> > >>
> >> > >>
> >> > >>
> >> > >> When the system has booted from NAND,
> >> > >> the register is already set to 8.  It works.
> >> > >>
> >> > >> However, when the system has booted from eMMC,
> >> > >> the register is not initialized by anyone.
> >> > >> I am searching for a way to set the register to 8
> >> > >> in this case.  
> >
> > Maybe there's a solution which does not involve attaching a per-compat
> > value or adding a DT prop. If the FW/bootloader has not initialized this
> > register the value is 0, right? Why not testing the value and
> > assigning it to the default (8) if it's not been initialized by the
> > bootloader. That shouldn't break existing platforms since I don't think
> > 0 is a valid value anyway.
> >
> > denali->oob_skip_bytes = ioread32(denali->reg +
> >   SPARE_AREA_SKIP_BYTES);
> > if (!denali->oob_skip_bytes) {
> > denali->oob_skip_bytes = DEFAULT_OOB_SKIP_BYTES;
> > iowrite32(denali->oob_skip_bytes,
> >   denali->reg + SPARE_AREA_SKIP_BYTES);
> > }
> >  
> 
> 
> I prefer per-compatible values to a fixed default.
> 
> 
> I'd like to set the register to 8 unless set otherwise
> because the boot ROM on my platform (Socionext UniPhier SoCs)
> uses that value.
> 
> Other platforms like Altera SOCFPGA may want to use a different value
> (at least, I do not know what is the preferred value).
> 
> 

[PATCH -next] ring-buffer: Fix ring buffer size in rb_write_something

[YueHaibing]

'cnt' should be used to calculate ring buffer size rather than data->cnt

Signed-off-by: YueHaibing 
---
 kernel/trace/ring_buffer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 65bd461..53538c3 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -4924,7 +4924,7 @@ static __init int rb_write_something(struct rb_test_data 
*data, bool nested)
cnt = data->cnt + (nested ? 27 : 0);
 
/* Multiply cnt by ~e, to make some unique increment */
-   size = (data->cnt * 68 / 25) % (sizeof(rb_string) - 1);
+   size = (cnt * 68 / 25) % (sizeof(rb_string) - 1);
 
len = size + sizeof(struct rb_item);
 

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

[Jacek Anaszewski]

On 09/22/2018 09:44 PM, Pavel Machek wrote:
> On Sat 2018-09-22 00:18:13, Pavel Machek wrote:
>> On Sat 2018-09-22 00:11:29, Jacek Anaszewski wrote:
>>> On 09/21/2018 11:17 PM, Pavel Machek wrote:
 On Fri 2018-09-21 22:59:40, Jacek Anaszewski wrote:
> Hi Baolin,
>
> On 09/21/2018 05:31 AM, Baolin Wang wrote:
>> Hi Jacek and Pavel,
>>
>> On 11 September 2018 at 10:47, Baolin Wang  
>> wrote:
>>> 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 

>> Do you have any comments for the v12 patch set? Thanks.
>
> We will probably have to remove hw_pattern from ledtrig-pattern
> since we are unable to come up with generic interface for it.
> Unless thread [0] will end up with some brilliant ideas. So far
> we're waiting for Pavel's reply.
>
> [0] https://lkml.org/lkml/2018/9/13/1216

 To paint a picture:

 brightness

rise hold  lower   hold down
   ^XXX
   |   X   XX
   |  X  XX
   | X XX
   +---> time

 This is what Baolin's hardware can do, right?

 This is also what pattern trigger can do, right?

 So all we need to do is match the two interfaces, so that hw_pattern
 returns -EINVAL on patterns hardware can not actually do.

 I believe I described code to do that in [0] above.
>>>
>>> You said that we should get the same effect by writing the
>>> same series of tuples to either pattern or hw_pattern file.
>>>
>>> Below command consists of four tuples (marked with brackets
>>> to highlight), and it will activate breathing mode in Baolin's
>>> hw_pattern:
>>>
>>> "[0 rise_duration] [brightness high_duration] [brightness fall_duration]
>>> [0   low_duration]"
>>>
>>> Now, I can't see how these four tuples could force the software
>>> fallback to produce breathing effect you depicted.
>>
>> I really should get some sleep now. But my intention was that software
>> fallback produces just that with those four tuples. (If it does not,
>> we can fix the software fallback to do just that).
> 
> And you are right, v12 1/2 seems to do the wrong thing.
> 
> My "brilliant idea" is to something closer to the original version I
> posted here. I'm attaching it for reference.
> 
> I'm also attaching the original documentation. It was clearly designed
> to do smooth transitions, too. (But pattern is written in slightly
> different way there, AFAICT).
> 
> Clearly, having same semantics for pattern and hw_pattern is possible.

Thank you for the attachment. The documentation part makes everything
clear. Comparing the patch from the attachment and the Baolin's patch
there is one vital part missing, from the original
pattern_trig_update():

if (data->next->brightness == data->curr->brightness) {
[...]
} else {
/* Gradual dimming */
led_set_brightness(data->led_cdev, compute_brightness(data));
data->delta_t += UPDATE_INTERVAL;
mod_timer(&data->timer, jiffies
+ msecs_to_jiffies(UPDATE_INTERVAL));
}

And the compute_brightness() implementation:

static int compute_brightness(struct pattern_trig_data *data)
{
if (data->delta_t == 0)
return data->curr->brightness;

if (data->curr->delta_t == 0)
return data->next->brightness;

return data->curr->brightness + data->delta_t
* (data->next->brightness - data->curr->brightness)
/ data->curr->delta_t;
}

With the above the linear gradual dimming is indeed feasible.
And for non-linear dimming like breathing mode the hw_pattern will do.

There is also vital discrepancy between the documentation and the
proposed ledtrig-pattern implementation. The doc says:

"Duration of 0 means brightness should immediately change to new value"

This syntax seems to be not supported in the Baolin's patch.

With all the above covered we will be almost there.

Now, only the issues raised by Bjorn need a clarification:

On 09/08/2018 07:02 AM, Bjorn Andersson wrote:
[...]
> The controls for my hardware is:
> * a list of brightness values
> * the rate of the pattern

The two can be described using [brightness delta_t] tuples.

> * a flag to indicate that the pattern should be played from start
>   to end, end

Re: [PATCH 4.9 069/101] ubi: fastmap: Correctly handle interrupted erasures in EBA

[Lars Persson]

On Sun, Jul 1, 2018 at 6:27 PM Greg Kroah-Hartman
 wrote:
>
> 4.9-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Richard Weinberger 
>
> commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
>
> Fastmap cannot track the LEB unmap operation, therefore it can
> happen that after an interrupted erasure the mapping still looks
> good from Fastmap's point of view, while reading from the PEB will
> cause an ECC error and confuses the upper layer.
>
> Instead of teaching users of UBI how to deal with that, we read back
> the VID header and check for errors. If the PEB is empty or shows ECC
> errors we fixup the mapping and schedule the PEB for erasure.
>
> Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
> Cc: 
> Reported-by: martin bayern 
> Signed-off-by: Richard Weinberger 
> Signed-off-by: Greg Kroah-Hartman 
>
>
Hi Greg

This commit belongs to a series of 3 commits that are intended to be
used together. Currently the stable branches have only the first
commit from the series and we get a UBI speed regression because an
extra NAND page read is always performed for each access to a UBI LEB.

3e5e4335cc0ffd668054564b113fb3c9c97badb8 ubi: fastmap: Detect EBA
mismatches on-the-fly
34653fd8c46e771585fce5975e4243f8fd401914 ubi: fastmap: Check each
mapping only once
781932375ffc6411713ee0926ccae8596ed0261c ubi: fastmap: Correctly
handle interrupted erasures in EBA

This will in turn require also this follow-up patch:
25677478474a91fa1b46f19a4a591a9848bca6fb ubi: Initialize Fastmap
checkmapping correctly


BR,
 Lars Persson

Re: [PATCH v8 07/16] x86/pci: Add Hygon Dhyana support to PCI and north bridge

[Pu Wen]

On 2018/9/23 19:10, Borislav Petkov wrote:

Signed-off-by: Pu Wen 
Acked-by: Bjorn Helgaas  # pci_ids.h
Reviewed-by: Borislav Petkov 


A note for your future submissions: if you rework a patch in a
non-trivial way, you *must* drop Reviewed-by/Acked-by tags because they
are not valid anymore.

In this case I guess Bjorn's tag can stay because he's acking the
pci_ids.h addition but mine definitely must go.


Thanks for the note. I'm sorry for not removing the Reviewed-by tag.
Is this revision still OK by you? :)

--
Regards,
Pu Wen

Re: [PATCH 4.9 069/101] ubi: fastmap: Correctly handle interrupted erasures in EBA

[Richard Weinberger]

Lars,

Am Sonntag, 23. September 2018, 14:49:23 CEST schrieb Lars Persson:
> On Sun, Jul 1, 2018 at 6:27 PM Greg Kroah-Hartman
>  wrote:
> >
> > 4.9-stable review patch.  If anyone has any objections, please let me know.
> >
> > --
> >
> > From: Richard Weinberger 
> >
> > commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
> >
> > Fastmap cannot track the LEB unmap operation, therefore it can
> > happen that after an interrupted erasure the mapping still looks
> > good from Fastmap's point of view, while reading from the PEB will
> > cause an ECC error and confuses the upper layer.
> >
> > Instead of teaching users of UBI how to deal with that, we read back
> > the VID header and check for errors. If the PEB is empty or shows ECC
> > errors we fixup the mapping and schedule the PEB for erasure.
> >
> > Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
> > Cc: 
> > Reported-by: martin bayern 
> > Signed-off-by: Richard Weinberger 
> > Signed-off-by: Greg Kroah-Hartman 
> >
> >
> Hi Greg
> 
> This commit belongs to a series of 3 commits that are intended to be
> used together. Currently the stable branches have only the first
> commit from the series and we get a UBI speed regression because an
> extra NAND page read is always performed for each access to a UBI LEB.
> 
> 3e5e4335cc0ffd668054564b113fb3c9c97badb8 ubi: fastmap: Detect EBA
> mismatches on-the-fly
> 34653fd8c46e771585fce5975e4243f8fd401914 ubi: fastmap: Check each
> mapping only once
> 781932375ffc6411713ee0926ccae8596ed0261c ubi: fastmap: Correctly
> handle interrupted erasures in EBA
> 
> This will in turn require also this follow-up patch:
> 25677478474a91fa1b46f19a4a591a9848bca6fb ubi: Initialize Fastmap
> checkmapping correctly

Wait.
Commit 34653fd8c46e771585fce5975e4243f8fd401914 was not scheduled for stable
on purpose.
It is just an optimization. How much is the performance regression you see?
Commit 3e5e4335cc0ffd668054564b113fb3c9c97badb8 does not fix anything, all it
does is adding another paranoia check to UBI.

I'd appreciate if you would come up with regression reports on linux-mtd first
before asking Greg to pick patches up...

Thanks,
//richard

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

[Anup Patel]

On Mon, Sep 17, 2018 at 7:40 PM Christoph Hellwig  wrote:
>
> On Wed, Sep 12, 2018 at 09:47:55AM -0700, Atish Patra wrote:
> > The extra hart information will not be parsed by lscpu which will make the
> > cpu information inconsistent between lscpu & /proc/cpuinfo.
> >
> > Should we patch lscpu as well to show correct hart id as well ?
>
> It would be good to follow whatever prescedent other architectures
> with different logical vs physical cpuids have set.

Most architectures (x86, ARM, ARM64), display logical CPU id as
"processor" attribute. I think we should use same name for logical
CPU id.

Other attributes in /proc/cpuinfo are very different accros architectures.
For e.g. x86 shows physical CPU id as "core id"

I will revise this patch to use "processor" attribute name for
logical CPU id.

Regards,
Anup

Re: [GIT PULL] fixes for soc/fsl drivers for v4.19

[Olof Johansson]

Hi Li,

On Thu, Sep 20, 2018 at 11:56:56AM -0500, Li Yang wrote:
> Hi arm-soc maintainers,
> 
> Please merge the following fixes for soc/fsl drivers.
> 
> Regards,
> Leo
> 
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> 
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git 
> tags/soc-fsl-fixes-for-4.19
> 
> for you to fetch changes up to 3cb31b634052ed458922e0c8e2b4b093d7fb60b9:
> 
>   soc: fsl: qe: Fix copy/paste bug in ucc_get_tdm_sync_shift() (2018-09-17 
> 16:01:46 -0500)
> 
> 
> soc/fsl fixes for 4.19

Please spend a bit of effort on writing up the tag for all pull requests, even
fixes. For fixes in particular, just as with the patch descriptions we want the
pull request to contain some brief information to what the bug is and why the
fix is needed.

Care to give this another go with a new tag description, please?


Thanks,

Olof

Re: [GIT PULL] soc/fsl drivers updates for next(v4.20)

[Olof Johansson]

On Thu, Sep 20, 2018 at 12:06:34PM -0500, Li Yang wrote:
> Hi arm-soc maintainers,
> 
> Please merge the following updates for soc/fsl drivers.
> 
> Regards,
> Leo
> 
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> 
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/leo/linux.git 
> tags/soc-fsl-for-next-4.20
> 
> for you to fetch changes up to afa86d264a7ce62ba214bc7c6012e2129141421e:
> 
>   soc: fsl: dpio: remove redundant pointer 'priv' (2018-08-30 12:19:02 -0500)
> 
> 
> soc/fsl for next

Hi,

My feedback here is the same as for the fixes pull request; please provide
another level of detail of what is in the pull request.

(Not merged, please respin with new tag description).

Thanks!


-Olof

Re: [PATCH] MAINTAINERS: update the Annapurna Labs maintainer email

[Olof Johansson]

On Wed, Sep 19, 2018 at 08:58:02AM +0200, Antoine Tenart wrote:
> Free Electrons became Bootlin. Update my email accordingly.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.


-Olof

[PATCH 3/5] staging: vc04_services: Add spaces after commas

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: space required after that ','

in the interface/vchi directory

Signed-off-by: Aymen Qader 
---
 drivers/staging/vc04_services/interface/vchi/vchi.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index cb2582a4eb6a..d8e660240a44 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -92,14 +92,14 @@ typedef struct vchi_msg_vector_ex {
 } VCHI_MSG_VECTOR_EX_T;
 
 // Construct an entry in a msg vector for a pointer (p) of length (l)
-#define VCHI_VEC_POINTER(p,l)  VCHI_VEC_POINTER, { { (VCHI_MEM_HANDLE_T)(p), 
(l) } }
+#define VCHI_VEC_POINTER(p, l)  VCHI_VEC_POINTER, { { (VCHI_MEM_HANDLE_T)(p), 
(l) } }
 
 // Construct an entry in a msg vector for a message handle (h), starting at 
offset (o) of length (l)
-#define VCHI_VEC_HANDLE(h,o,l) VCHI_VEC_HANDLE,  { { (h), (o), (l) } }
+#define VCHI_VEC_HANDLE(h, o, l) VCHI_VEC_HANDLE,  { { (h), (o), (l) } }
 
 // Macros to manipulate 'FOURCC' values
 #define MAKE_FOURCC(x) ((int32_t)((x[0] << 24) | (x[1] << 16) | (x[2] << 8) | 
x[3]))
-#define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF,(x >> 16) & 0xFF,(x >> 8) & 0xFF, x 
& 0xFF
+#define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF, (x >> 16) & 0xFF, (x >> 8) & 0xFF, 
x & 0xFF
 
 // Opaque service information
 struct opaque_vchi_service_t;
-- 
2.17.1

[PATCH 1/5] staging: vc04_services: Fix "space prohibited"

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: space prohibited after/before that open/closed parenthesis

in the interface/vchi directory.

Signed-off-by: Aymen Qader 
---
 .../vc04_services/interface/vchi/vchi.h   | 106 +-
 .../vc04_services/interface/vchi/vchi_cfg.h   |   2 +-
 2 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 66a3a060fad2..ffb8caaacaea 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -98,7 +98,7 @@ typedef struct vchi_msg_vector_ex {
 #define VCHI_VEC_HANDLE(h,o,l) VCHI_VEC_HANDLE,  { { (h), (o), (l) } }
 
 // Macros to manipulate 'FOURCC' values
-#define MAKE_FOURCC(x) ((int32_t)( (x[0] << 24) | (x[1] << 16) | (x[2] << 8) | 
x[3] ))
+#define MAKE_FOURCC(x) ((int32_t)((x[0] << 24) | (x[1] << 16) | (x[2] << 8) | 
x[3]))
 #define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF,(x >> 16) & 0xFF,(x >> 8) & 0xFF, x 
& 0xFF
 
 // Opaque service information
@@ -154,25 +154,25 @@ typedef struct service_info_tag {
 extern "C" {
 #endif
 
-extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection( const 
VCHI_CONNECTION_API_T * function_table,
+extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection(const 
VCHI_CONNECTION_API_T * function_table,
const VCHI_MESSAGE_DRIVER_T 
* low_level);
 
 // Routine used to initialise the vchi on both local + remote connections
-extern int32_t vchi_initialise( VCHI_INSTANCE_T *instance_handle );
+extern int32_t vchi_initialise(VCHI_INSTANCE_T *instance_handle);
 
-extern int32_t vchi_exit( void );
+extern int32_t vchi_exit(void);
 
-extern int32_t vchi_connect( VCHI_CONNECTION_T **connections,
+extern int32_t vchi_connect(VCHI_CONNECTION_T **connections,
  const uint32_t num_connections,
- VCHI_INSTANCE_T instance_handle );
+ VCHI_INSTANCE_T instance_handle);
 
 //When this is called, ensure that all services have no data pending.
 //Bulk transfers can remain 'queued'
-extern int32_t vchi_disconnect( VCHI_INSTANCE_T instance_handle );
+extern int32_t vchi_disconnect(VCHI_INSTANCE_T instance_handle);
 
 // Global control over bulk CRC checking
-extern int32_t vchi_crc_control( VCHI_CONNECTION_T *connection,
- VCHI_CRC_CONTROL_T control );
+extern int32_t vchi_crc_control(VCHI_CONNECTION_T *connection,
+ VCHI_CRC_CONTROL_T control);
 
 // helper functions
 extern void * vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t 
*length);
@@ -183,32 +183,32 @@ extern uint32_t vchi_current_time(VCHI_INSTANCE_T 
instance_handle);
  Global service API
  */
 // Routine to create a named service
-extern int32_t vchi_service_create( VCHI_INSTANCE_T instance_handle,
+extern int32_t vchi_service_create(VCHI_INSTANCE_T instance_handle,
 SERVICE_CREATION_T *setup,
-VCHI_SERVICE_HANDLE_T *handle );
+VCHI_SERVICE_HANDLE_T *handle);
 
 // Routine to destroy a service
-extern int32_t vchi_service_destroy( const VCHI_SERVICE_HANDLE_T handle );
+extern int32_t vchi_service_destroy(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to open a named service
-extern int32_t vchi_service_open( VCHI_INSTANCE_T instance_handle,
+extern int32_t vchi_service_open(VCHI_INSTANCE_T instance_handle,
   SERVICE_CREATION_T *setup,
   VCHI_SERVICE_HANDLE_T *handle);
 
-extern int32_t vchi_get_peer_version( const VCHI_SERVICE_HANDLE_T handle,
-  short *peer_version );
+extern int32_t vchi_get_peer_version(const VCHI_SERVICE_HANDLE_T handle,
+  short *peer_version);
 
 // Routine to close a named service
-extern int32_t vchi_service_close( const VCHI_SERVICE_HANDLE_T handle );
+extern int32_t vchi_service_close(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to increment ref count on a named service
-extern int32_t vchi_service_use( const VCHI_SERVICE_HANDLE_T handle );
+extern int32_t vchi_service_use(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to decrement ref count on a named service
-extern int32_t vchi_service_release( const VCHI_SERVICE_HANDLE_T handle );
+extern int32_t vchi_service_release(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to set a control option for a named service
-extern int32_t vchi_service_set_option( const VCHI_SERVICE_HANDLE_T handle,
+extern int32_t vchi_service_set_option(const VCHI_SERVICE_HANDLE_T handle,
VCHI_SERVICE_OPTION_T option,
   

[PATCH 4/5] staging: vc04_services: Surround complex macros

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: Macros with complex values should be enclosed in parentheses

in the interface/vchi directory

Signed-off-by: Aymen Qader 
---
 drivers/staging/vc04_services/interface/vchi/vchi.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index d8e660240a44..f818cf2e27e1 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -92,14 +92,14 @@ typedef struct vchi_msg_vector_ex {
 } VCHI_MSG_VECTOR_EX_T;
 
 // Construct an entry in a msg vector for a pointer (p) of length (l)
-#define VCHI_VEC_POINTER(p, l)  VCHI_VEC_POINTER, { { (VCHI_MEM_HANDLE_T)(p), 
(l) } }
+#define VCHI_VEC_POINTER(p, l)  (VCHI_VEC_POINTER, { { (VCHI_MEM_HANDLE_T)(p), 
(l) } })
 
 // Construct an entry in a msg vector for a message handle (h), starting at 
offset (o) of length (l)
-#define VCHI_VEC_HANDLE(h, o, l) VCHI_VEC_HANDLE,  { { (h), (o), (l) } }
+#define VCHI_VEC_HANDLE(h, o, l) (VCHI_VEC_HANDLE,  { { (h), (o), (l) } })
 
 // Macros to manipulate 'FOURCC' values
 #define MAKE_FOURCC(x) ((int32_t)((x[0] << 24) | (x[1] << 16) | (x[2] << 8) | 
x[3]))
-#define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF, (x >> 16) & 0xFF, (x >> 8) & 0xFF, 
x & 0xFF
+#define FOURCC_TO_CHAR(x) ((x >> 24) & 0xFF, (x >> 16) & 0xFF, (x >> 8) & 
0xFF, x & 0xFF)
 
 // Opaque service information
 struct opaque_vchi_service_t;
-- 
2.17.1

[PATCH 2/5] staging: vc04_services: Use tabs instead of spaces

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: code indent should use tabs where possible

in the interface/vchi directory

Signed-off-by: Aymen Qader 
---
 .../vc04_services/interface/vchi/vchi.h   | 116 +-
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index ffb8caaacaea..cb2582a4eb6a 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -71,23 +71,23 @@ typedef struct vchi_msg_vector_ex {
VCHI_MSG_VECTOR_TYPE_T type;
union {
   // a memory handle
-  struct {
- VCHI_MEM_HANDLE_T handle;
- uint32_t offset;
- int32_t vec_len;
-  } handle;
+   struct {
+   VCHI_MEM_HANDLE_T handle;
+   uint32_t offset;
+   int32_t vec_len;
+   } handle;
 
   // an ordinary data pointer
-  struct {
- const void *vec_base;
- int32_t vec_len;
+   struct {
+   const void *vec_base;
+   int32_t vec_len;
   } ptr;
 
   // a nested vector list
-  struct {
- struct vchi_msg_vector_ex *vec;
- uint32_t vec_len;
-  } list;
+   struct {
+   struct vchi_msg_vector_ex *vec;
+   uint32_t vec_len;
+   } list;
} u;
 } VCHI_MSG_VECTOR_EX_T;
 
@@ -155,7 +155,7 @@ extern "C" {
 #endif
 
 extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection(const 
VCHI_CONNECTION_API_T * function_table,
-   const VCHI_MESSAGE_DRIVER_T 
* low_level);
+const 
VCHI_MESSAGE_DRIVER_T * low_level);
 
 // Routine used to initialise the vchi on both local + remote connections
 extern int32_t vchi_initialise(VCHI_INSTANCE_T *instance_handle);
@@ -163,8 +163,8 @@ extern int32_t vchi_initialise(VCHI_INSTANCE_T 
*instance_handle);
 extern int32_t vchi_exit(void);
 
 extern int32_t vchi_connect(VCHI_CONNECTION_T **connections,
- const uint32_t num_connections,
- VCHI_INSTANCE_T instance_handle);
+   const uint32_t num_connections,
+   VCHI_INSTANCE_T instance_handle);
 
 //When this is called, ensure that all services have no data pending.
 //Bulk transfers can remain 'queued'
@@ -172,7 +172,7 @@ extern int32_t vchi_disconnect(VCHI_INSTANCE_T 
instance_handle);
 
 // Global control over bulk CRC checking
 extern int32_t vchi_crc_control(VCHI_CONNECTION_T *connection,
- VCHI_CRC_CONTROL_T control);
+   VCHI_CRC_CONTROL_T control);
 
 // helper functions
 extern void * vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t 
*length);
@@ -184,19 +184,19 @@ extern uint32_t vchi_current_time(VCHI_INSTANCE_T 
instance_handle);
  */
 // Routine to create a named service
 extern int32_t vchi_service_create(VCHI_INSTANCE_T instance_handle,
-SERVICE_CREATION_T *setup,
-VCHI_SERVICE_HANDLE_T *handle);
+  SERVICE_CREATION_T *setup,
+  VCHI_SERVICE_HANDLE_T *handle);
 
 // Routine to destroy a service
 extern int32_t vchi_service_destroy(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to open a named service
 extern int32_t vchi_service_open(VCHI_INSTANCE_T instance_handle,
-  SERVICE_CREATION_T *setup,
-  VCHI_SERVICE_HANDLE_T *handle);
+SERVICE_CREATION_T *setup,
+VCHI_SERVICE_HANDLE_T *handle);
 
 extern int32_t vchi_get_peer_version(const VCHI_SERVICE_HANDLE_T handle,
-  short *peer_version);
+short *peer_version);
 
 // Routine to close a named service
 extern int32_t vchi_service_close(const VCHI_SERVICE_HANDLE_T handle);
@@ -227,18 +227,18 @@ vchi_queue_user_message(VCHI_SERVICE_HANDLE_T handle,
 // Routine to receive a msg from a service
 // Dequeue is equivalent to hold, copy into client buffer, release
 extern int32_t vchi_msg_dequeue(VCHI_SERVICE_HANDLE_T handle,
- void *data,
- uint32_t max_data_size_to_read,
- uint32_t *actual_msg_size,
- VCHI_FLAGS_T flags);
+   void *data,
+   uint32_t max_data_size_to_read,
+   uint32_t *actual_msg_size,
+   VCHI_FLAGS_T flags);
 
 // Routine to look at a message in place.
 // The message

[PATCH 5/5] staging: vc04_services: Remove spaces after '*'

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: "foo * bar" should be "foo* bar"

in the interface/vchi directory

Signed-off-by: Aymen Qader 
---
 drivers/staging/vc04_services/interface/vchi/vchi.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index f818cf2e27e1..77bf92018165 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -154,7 +154,7 @@ typedef struct service_info_tag {
 extern "C" {
 #endif
 
-extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection(const 
VCHI_CONNECTION_API_T * function_table,
+extern /*@observer@*/ VCHI_CONNECTION_T *vchi_create_connection(const 
VCHI_CONNECTION_API_T * function_table,
 const 
VCHI_MESSAGE_DRIVER_T * low_level);
 
 // Routine used to initialise the vchi on both local + remote connections
@@ -175,7 +175,7 @@ extern int32_t vchi_crc_control(VCHI_CONNECTION_T 
*connection,
VCHI_CRC_CONTROL_T control);
 
 // helper functions
-extern void * vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t 
*length);
+extern void *vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t 
*length);
 extern void vchi_free_buffer(VCHI_SERVICE_HANDLE_T handle, void *address);
 extern uint32_t vchi_current_time(VCHI_INSTANCE_T instance_handle);
 
-- 
2.17.1

Re: [PATCH v11 03/11] firmware: xilinx: Add zynqmp IOCTL API for device control

[Olof Johansson]

Hi,

Apologies for the slow responses here, I meant to follow up on this sooner.

On Tue, Sep 11, 2018 at 8:20 PM, Jolly Shah  wrote:
> Hi Sudeep and Olof,
>
> Clock driver from same patch set uses ioctl API along with other clock eemi 
> APIs. As clock patches' final review is pending by Stephen, Michal only 
> created pull request for rest of the patches and that doesn't require ioctl 
> api. I will remove it and submit new patch set.
>
> For future patches which requires ioctl api, would like to understand your 
> suggestion so I can make required changes. For zynqmp, EEMI interface allows 
> clock, reset, power etc management through firmware but apart from those 
> there are some operations which needs secure access through firmware. 
> Examples are accessing some storage registers for inter agent communication, 
> configuring another agent(RPU) mode, setting PLL parameters, boot device 
> configuration etc. Those operations are covered as ioctls as they are very 
> platform specific. Do you suggest to handle them with individual EEMI APIs 
> instead of ioctl API?

I'm personally less worried about whether the calls are through an
ioctl API or an EEMI one, but if it is through ioctl, I'd prefer if it
wasn't wide-open pass-through. I.e. that the ioctls you actually use
are documented, and only those who are whitelisted are passed through
(and not in general exported to userspace).

Does that make sense?


-Olof

Re: [PATCH v12 0/6] drivers: Introduce firmware driver for ZynqMP core

[Olof Johansson]

On Thu, Sep 20, 2018 at 5:46 PM, Jolly Shah  wrote:
> Hi Olof,
>
> As suggested, this patchset is generated without ioctl interface. Please 
> review. If you are ok, Michal can create a pull request for merge.

Hi,

I replied on the other thread as well; it sounds like you will need
something _like_ the ioctl interface for some of the dependent
drivers. For those, would it be possible to only expose some of the
ioctls through the interface, and not just pass through any call? I
think that'd probably take care of my concern.

But yeah, go ahead and stage these in a pull request for now, that way
we can take care of these and merge them as the rest are getting
ready. I don't want to hold you up more than needed; the patch set is
already up to a very high version number and it's not fair to make you
rework it completely yet again.



-Olof

Re: [PATCH V2 1/8] dt-bindings: mfd: document stpmic1

[Lee Jones]

On Fri, 07 Sep 2018, Pascal PAILLET-LME wrote:

> From: pascal paillet 
> 
> stpmic1 is a pmic from STMicroelectronics. The stpmic1 integrates 10
> regulators and 3 switches with various capabilities.
> 
> Signed-off-by: pascal paillet 
> ---
> changes in v2:
> * the hardware component has been renamed from stpmu1 to stpmic1 !
> * replace _ with - in properties name
> * fix node names in example
> * remove regulator compatibles in example
> * add st,stpmic1.h to the patch
> 
> Rob, I did not change the usage of the properties because it would lead to a 
> lot
> of st properties; for example st,main-control-register would be replaced by:
>   st,power_cycling_on_turn_off
>   st,pwrctrl_enabled
>   st,pwrctrl_active_high
> should I go this way ?
> 
> Rob, I did not found the standard property for st,onkey-press-seconds = <10>;
> 
>  .../devicetree/bindings/mfd/st,stpmic1.txt | 137 
> +
>  include/dt-bindings/mfd/st,stpmic1.h   |  46 +++
>  2 files changed, 183 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
>  create mode 100644 include/dt-bindings/mfd/st,stpmic1.h
> 
> diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.txt 
> b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> new file mode 100644
> index 000..9f2c516
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> @@ -0,0 +1,137 @@
> +* STMicroelectronics STPMIC1 Power Management IC
> +
> +Required parent device properties:
> +- compatible: "st,stpmic1"
> +- reg: the I2C slave address for the stpmic1 chip
> +- interrupts-extended: interrupt lines to use: second irq is for wakeup.
> +- #interrupt-cells: should be 2.
> +- interrupt-controller: describes the STPMIC1 as an interrupt

I always find these are easier to read when they are tab aligned.
While we're at it, let's throw some capital letters in there and
remove the '.', as it's only used on one of the lines:

- compatible:   "st,stpmic1"
- reg:  The I2C slave address for the STPIC1 chip
- interrupts-extended:  Interrupt lines to use: second IRQ is for wakeup.
- #interrupt-cells: Should be 2
- interrupt-controller: Describes the STPMIC1 as an interrupt

Better, no?

> +  controller (has its own domain). interrupt number are the following:

Capital letters usually follow a '.'

> + /* Interrupt Register 1 (0x50 for latch) */
> + IT_SWOUT_R=0
> + IT_SWOUT_F=1
> + IT_VBUS_OTG_R=2
> + IT_VBUS_OTG_F=3
> + IT_WAKEUP_R=4
> + IT_WAKEUP_F=5
> + IT_PONKEY_R=6
> + IT_PONKEY_F=7
> + /* Interrupt Register 2 (0x51 for latch) */
> + IT_OVP_BOOST=8
> + IT_OCP_BOOST=9
> + IT_OCP_SWOUT=10
> + IT_OCP_OTG=11
> + IT_CURLIM_BUCK4=12
> + IT_CURLIM_BUCK3=13
> + IT_CURLIM_BUCK2=14
> + IT_CURLIM_BUCK1=15
> + /* Interrupt Register 3 (0x52 for latch) */
> + IT_SHORT_SWOUT=16
> + IT_SHORT_SWOTG=17
> + IT_CURLIM_LDO6=18
> + IT_CURLIM_LDO5=19
> + IT_CURLIM_LDO4=20
> + IT_CURLIM_LDO3=21
> + IT_CURLIM_LDO2=22
> + IT_CURLIM_LDO1=23
> + /* Interrupt Register 3 (0x52 for latch) */
> + IT_SWIN_R=24
> + IT_SWIN_F=25
> + IT_RESERVED_1=26
> + IT_RESERVED_2=27
> + IT_VINLOW_R=28
> + IT_VINLOW_F=29
> + IT_TWARN_R=30
> + IT_TWARN_F=31
> +
> +Optional parent device properties:
> +- st,main-control-register:
> + -bit 1: Power cycling will be performed on turn OFF condition
> + -bit 2: PWRCTRL is functional
> + -bit 3: PWRCTRL active high
> +- st,pads-pull-register:
> + -bit 1: WAKEUP pull down is not active
> + -bit 2: PWRCTRL pull up is active
> + -bit 3: PWRCTRL pull down is active
> + -bit 4: WAKEUP detector is disabled
> +- st,vin-control-register:
> + -bit 0: VINLOW monitoring is enabled
> + -bit [1...3]: VINLOW rising threshold
> + 000 VINOK_f + 50mV
> + 001 VINOK_f + 100mV
> + 010 VINOK_f + 150mV
> + 011 VINOK_f + 200mV
> + 100 VINOK_f + 250mV
> + 101 VINOK_f + 300mV
> + 110 VINOK_f + 350mV
> + 111 VINOK_f + 400mV
> + -bit [4...5]: VINLOW hyst
> + 00 100mV
> + 01 200mV
> + 10 300mV
> + 11 400mV
> + -bit 6: SW_OUT detector is disabled
> + -bit 7: SW_IN detector is enabled.
> +- st,usb-control-register:
> + -bit 3: SW_OUT current limit
> + 0: 600mA
> + 1: 1.1A
> + -bit 4: VBUS_OTG discharge is enabled
> + -bit 5: SW_OUT discharge is enabled
> + -bit 6: VBUS_OTG detection is enabled
> + -bit 7: BOOST_OVP is disabled
> +
> +

Did you mean to add a double line space here?

> +stpmic1 consists is a varied group of sub-devices:

Should be STPMIC1, no?

> +DeviceDescription
> +--   
> +st,stpmic1-onkey : On key

Please describe this a "Power on 

[PATCH 0/5] staging: vc04_services: Fix checkpatch.pl errors

[Aymen Qader]

This patchset fixes the following checkpatch.pl errors in the
interface/vchi directory:

ERROR: space prohibited after/before that open/closed parenthesis
ERROR: code indent should use tabs where possible
ERROR: space required after that ','
ERROR: Macros with complex values should be enclosed in parentheses
ERROR: Macros with complex values should be enclosed in parenthese



Aymen Qader (5):
  staging: vc04_services: Fix "space prohibited"
  staging: vc04_services: Use tabs instead of spaces
  staging: vc04_services: Add spaces after commas
  staging: vc04_services: Surround complex macros
  staging: vc04_services: Remove spaces after '*'

 .../vc04_services/interface/vchi/vchi.h   | 200 +-
 .../vc04_services/interface/vchi/vchi_cfg.h   |   2 +-
 2 files changed, 101 insertions(+), 101 deletions(-)

-- 
2.17.1

Re: [PATCH v2] staging: mt7621-mmc: Fix single statement macros in sd.c

[Joe Perches]

On Sun, 2018-09-23 at 15:08 +0530, Nishad Kamdar wrote:
> This patch fixes a few single statement macros in sd.c.
> It converts two macros to inline functions. It removes
> five other macros and replaces their usages with calls to
> the function being called in the macro definition.
> Issue found by checkpatch.
> 
> Signed-off-by: Nishad Kamdar 
> ---
> Changes in v2:
>   - Convert msdc_gate_clk() and msdc_ungate_clk() to inline functions.
>   - Delete msdc_irq_restore(), msdc_vcore_on(), msdc_vcore_off(),
> msdc_vdd_on() and msdc_vdd_off() and replace their usages directly
> with calls to the function being called by these macros.

Nishad, do please look again for uses of these functions
you are changing.

Please try removing all the #if 0 blocks instead, and then
see if there are also now unused functions from those removed
blocks that could also be removed.

And Greg, if you look at this, look at the odd license of
these files.

It's possible the license is incompatible with the GPL.

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

[Anup Patel]

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

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

processor   : 1
hart: 0
isa : rv64imafdc
mmu : sv48

processor   : 2
hart: 2
isa : rv64imafdc
mmu : sv48

processor   : 3
hart: 3
isa : rv64imafdc
mmu : sv48

Signed-off-by: Anup Patel 
---

Changes since v1:
 - Show logical CPU ID as "processor" attribute in /proc/cpuinfo

 arch/riscv/kernel/cpu.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 36b6ddb19b4d..392c7c19c4a3 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -81,7 +81,7 @@ static void print_isa(struct seq_file *f, const char 
*orig_isa)
 #endif
 
/* Print the base ISA, as we already know it's legal. */
-   seq_puts(f, "isa\t: ");
+   seq_puts(f, "isa\t\t: ");
seq_write(f, isa, 5);
isa += 5;
 
@@ -96,6 +96,7 @@ static void print_isa(struct seq_file *f, const char 
*orig_isa)
isa++;
}
}
+   seq_puts(f, "\n");
 
/*
 * If we were given an unsupported ISA in the device tree then print
@@ -116,7 +117,7 @@ static void print_mmu(struct seq_file *f, const char 
*mmu_type)
return;
 #endif
 
-   seq_printf(f, "mmu\t: %s\n", mmu_type+6);
+   seq_printf(f, "mmu\t\t: %s\n", mmu_type+6);
 }
 
 static void *c_start(struct seq_file *m, loff_t *pos)
@@ -144,14 +145,15 @@ static int c_show(struct seq_file *m, void *v)
   NULL);
const char *compat, *isa, *mmu;
 
-   seq_printf(m, "hart\t: %lu\n", cpu_id);
+   seq_printf(m, "processor\t: %lu\n", cpu_id);
+   seq_printf(m, "hart\t\t: %lu\n", cpuid_to_hardid_map(cpu_id));
if (!of_property_read_string(node, "riscv,isa", &isa))
print_isa(m, isa);
if (!of_property_read_string(node, "mmu-type", &mmu))
print_mmu(m, mmu);
if (!of_property_read_string(node, "compatible", &compat)
&& strcmp(compat, "riscv"))
-   seq_printf(m, "uarch\t: %s\n", compat);
+   seq_printf(m, "uarch\t\t: %s\n", compat);
seq_puts(m, "\n");
 
return 0;
-- 
2.17.1

Re: [PATCH v3] dt-bindings: arm: Explicitly mark Samsung Exynos SoC as unstable

[Olof Johansson]

On Thu, Aug 30, 2018 at 7:02 PM, Krzysztof Kozlowski  wrote:
> Samsung Exynos SoCs and boards related bindings evolved since the initial
> introduction, but initially the bindings were minimal and a bit incomplete
> (they never described all the hardware modules available in the SoCs).
> Since then some significant (not fully compatible) changes have been
> already committed a few times (like gpio replaced by pinctrl, display ddc,
> mfc reserved memory, some core clocks added to various hardware modules,
> added more required nodes).
>
> On the other side there are no boards which have device tree embedded in
> the bootloader. Device tree blob is always compiled from the kernel tree
> and updated together with the kernel image.
>
> Thus to avoid further adding a bunch of workarounds for old/missing
> bindings, make development of new platforms easier and allow to make
> cleanup of the existing code and device tree files, lets mark some
> Samsung Exynos SoC platform bindings as unstable. This means that
> bindings can may change at any time and users should use the dtb file
> compiled from the same kernel source tree as the kernel image.

I have to admit that I don't really like this approach, and I missed
the patch when originally posted (I did notice it in the pull request
it came in with though).

The main concern for me is that with a blanket "everything is always
unstable" we discard the notion that we should strive for bindings to
be stable and backwards compatible.

Questions that come to mind are:

 - When do they stop being unstable?
 - Is there a way to note in the binding itself that it's still
unstable with an anticipation of when it will be settled in?
 - Is there a better way to version the bindings to avoid complete
backwards compatibility?

Pointing out a couple of cases where it has been painful to stay
backwards compatible could also be useful for understanding (even
though you run the risk of each case being explained away with
suggestions of how it can be handled).


-Olof

Re: [PATCH 4.9 069/101] ubi: fastmap: Correctly handle interrupted erasures in EBA

[Lars Persson]

On Sun, Sep 23, 2018 at 2:58 PM Richard Weinberger  wrote:
>
> Lars,
>
> Am Sonntag, 23. September 2018, 14:49:23 CEST schrieb Lars Persson:
> > On Sun, Jul 1, 2018 at 6:27 PM Greg Kroah-Hartman
> >  wrote:
> > >
> > > 4.9-stable review patch.  If anyone has any objections, please let me 
> > > know.
> > >
> > > --
> > >
> > > From: Richard Weinberger 
> > >
> > > commit 781932375ffc6411713ee0926ccae8596ed0261c upstream.
> > >
> > > Fastmap cannot track the LEB unmap operation, therefore it can
> > > happen that after an interrupted erasure the mapping still looks
> > > good from Fastmap's point of view, while reading from the PEB will
> > > cause an ECC error and confuses the upper layer.
> > >
> > > Instead of teaching users of UBI how to deal with that, we read back
> > > the VID header and check for errors. If the PEB is empty or shows ECC
> > > errors we fixup the mapping and schedule the PEB for erasure.
> > >
> > > Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
> > > Cc: 
> > > Reported-by: martin bayern 
> > > Signed-off-by: Richard Weinberger 
> > > Signed-off-by: Greg Kroah-Hartman 
> > >
> > >
> > Hi Greg
> >
> > This commit belongs to a series of 3 commits that are intended to be
> > used together. Currently the stable branches have only the first
> > commit from the series and we get a UBI speed regression because an
> > extra NAND page read is always performed for each access to a UBI LEB.
> >
> > 3e5e4335cc0ffd668054564b113fb3c9c97badb8 ubi: fastmap: Detect EBA
> > mismatches on-the-fly
> > 34653fd8c46e771585fce5975e4243f8fd401914 ubi: fastmap: Check each
> > mapping only once
> > 781932375ffc6411713ee0926ccae8596ed0261c ubi: fastmap: Correctly
> > handle interrupted erasures in EBA
> >
> > This will in turn require also this follow-up patch:
> > 25677478474a91fa1b46f19a4a591a9848bca6fb ubi: Initialize Fastmap
> > checkmapping correctly
>
> Wait.
> Commit 34653fd8c46e771585fce5975e4243f8fd401914 was not scheduled for stable
> on purpose.
> It is just an optimization. How much is the performance regression you see?
> Commit 3e5e4335cc0ffd668054564b113fb3c9c97badb8 does not fix anything, all it
> does is adding another paranoia check to UBI.
>
> I'd appreciate if you would come up with regression reports on linux-mtd first
> before asking Greg to pick patches up...
>

Hi Richard

Sorry, I assumed this omission from -stable was a mistake.

The timing for our boot increased from 45 seconds to 55 seconds on one
chip and 42 seconds to 48 seconds on another chip. The regression was
completely fixed by applying the extra patches. The way I see it the
first patch is a significant slow-down so the second patch is required
to restore performance.

- Lars

[PATCH] watchdog: w83627hf_wdt: Support NCT6796D, NCT6797D, NCT6798D

[Guenter Roeck]

The watchdog controller on NCT6796D, NCT6797D, and NCT6798D is compatible
with the wtachdog controller on other Nuvoton chips.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/w83627hf_wdt.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/w83627hf_wdt.c b/drivers/watchdog/w83627hf_wdt.c
index 7817836bff55..4b9365d4de7a 100644
--- a/drivers/watchdog/w83627hf_wdt.c
+++ b/drivers/watchdog/w83627hf_wdt.c
@@ -50,7 +50,7 @@ static int cr_wdt_csr;/* WDT control & status 
register */
 enum chips { w83627hf, w83627s, w83697hf, w83697ug, w83637hf, w83627thf,
 w83687thf, w83627ehf, w83627dhg, w83627uhg, w83667hg, w83627dhg_p,
 w83667hg_b, nct6775, nct6776, nct6779, nct6791, nct6792, nct6793,
-nct6795, nct6102 };
+nct6795, nct6796, nct6102 };
 
 static int timeout;/* in seconds */
 module_param(timeout, int, 0);
@@ -100,6 +100,7 @@ MODULE_PARM_DESC(early_disable, "Disable watchdog at boot 
time (default=0)");
 #define NCT6792_ID 0xc9
 #define NCT6793_ID 0xd1
 #define NCT6795_ID 0xd3
+#define NCT6796_ID 0xd4/* also NCT9697D, NCT9698D */
 
 #define W83627HF_WDT_TIMEOUT   0xf6
 #define W83697HF_WDT_TIMEOUT   0xf4
@@ -209,6 +210,7 @@ static int w83627hf_init(struct watchdog_device *wdog, enum 
chips chip)
case nct6792:
case nct6793:
case nct6795:
+   case nct6796:
case nct6102:
/*
 * These chips have a fixed WDTO# output pin (W83627UHG),
@@ -407,6 +409,9 @@ static int wdt_find(int addr)
case NCT6795_ID:
ret = nct6795;
break;
+   case NCT6796_ID:
+   ret = nct6796;
+   break;
case NCT6102_ID:
ret = nct6102;
cr_wdt_timeout = NCT6102D_WDT_TIMEOUT;
@@ -450,6 +455,7 @@ static int __init wdt_init(void)
"NCT6792",
"NCT6793",
"NCT6795",
+   "NCT6796",
"NCT6102",
};
 
-- 
2.7.4

Re: [GIT PULL 2/2] ARM: dts: exynos: DT for v4.20 (or 5.0)

[Olof Johansson]

Hi,

On Fri, Sep 21, 2018 at 07:45:19PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> Nothing special, description in tag.

Hmm. Point 12 is special, I'd say.

I commented on the patch, and I don't want to hold everything else up so it
might make sense to separate that out and send a fresh pull request with the
base material while that part is discussed a bit more.


-Olof

Re: [GIT PULL 1/2] ARM: exynos: mach/soc for v4.20 (or 5.0)

[Olof Johansson]

On Fri, Sep 21, 2018 at 07:45:20PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> Nothing special, description in tag.
> 
> 
> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
> 
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git 
> tags/samsung-soc-4.20
> 
> for you to fetch changes up to f30858439e7db9ce9847eaedf440635fc6349c6e:
> 
>   ARM: s3c24xx: Restore proper usage of pr_info/pr_cont (2018-09-19 19:11:17 
> +0200)
> 
> 
> Samsung mach/soc changes for v4.20
> 
> 1. Fix imprecise abort during Odroid XU3-family suspend to RAM (but it
>is not end of work needed for suspend).
> 2. Cleanup and fix of SD card write protect on MINI2440.

Merged, thanks!

-Olof

[PATCH v2 0/5] staging: vc04_services: Fix checkpatch.pl errors

[Aymen Qader]

This patchset fixes the following checkpatch.pl errors in the
interface/vchi directory:

ERROR: space prohibited after/before that open/closed parenthesis
ERROR: code indent should use tabs where possible
ERROR: space required after that ','
ERROR: Macros with complex values should be enclosed in parentheses
ERROR: "foo * bar" should be "foo* bar"

Aymen Qader (5):
  staging: vc04_services: Fix "space prohibited"
  staging: vc04_services: Use tabs instead of spaces
  staging: vc04_services: Add spaces after commas
  staging: vc04_services: Surround complex macros
  staging: vc04_services: Remove spaces after '*'

v2: Added cover letter correctly

 .../vc04_services/interface/vchi/vchi.h   | 200 +-
 .../vc04_services/interface/vchi/vchi_cfg.h   |   2 +-
 2 files changed, 101 insertions(+), 101 deletions(-)

-- 
2.17.1

[PATCH v2 2/5] staging: vc04_services: Use tabs instead of spaces

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: code indent should use tabs where possible

in the interface/vchi directory

Signed-off-by: Aymen Qader 
---
 .../vc04_services/interface/vchi/vchi.h   | 116 +-
 1 file changed, 58 insertions(+), 58 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index ffb8caaacaea..cb2582a4eb6a 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -71,23 +71,23 @@ typedef struct vchi_msg_vector_ex {
VCHI_MSG_VECTOR_TYPE_T type;
union {
   // a memory handle
-  struct {
- VCHI_MEM_HANDLE_T handle;
- uint32_t offset;
- int32_t vec_len;
-  } handle;
+   struct {
+   VCHI_MEM_HANDLE_T handle;
+   uint32_t offset;
+   int32_t vec_len;
+   } handle;
 
   // an ordinary data pointer
-  struct {
- const void *vec_base;
- int32_t vec_len;
+   struct {
+   const void *vec_base;
+   int32_t vec_len;
   } ptr;
 
   // a nested vector list
-  struct {
- struct vchi_msg_vector_ex *vec;
- uint32_t vec_len;
-  } list;
+   struct {
+   struct vchi_msg_vector_ex *vec;
+   uint32_t vec_len;
+   } list;
} u;
 } VCHI_MSG_VECTOR_EX_T;
 
@@ -155,7 +155,7 @@ extern "C" {
 #endif
 
 extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection(const 
VCHI_CONNECTION_API_T * function_table,
-   const VCHI_MESSAGE_DRIVER_T 
* low_level);
+const 
VCHI_MESSAGE_DRIVER_T * low_level);
 
 // Routine used to initialise the vchi on both local + remote connections
 extern int32_t vchi_initialise(VCHI_INSTANCE_T *instance_handle);
@@ -163,8 +163,8 @@ extern int32_t vchi_initialise(VCHI_INSTANCE_T 
*instance_handle);
 extern int32_t vchi_exit(void);
 
 extern int32_t vchi_connect(VCHI_CONNECTION_T **connections,
- const uint32_t num_connections,
- VCHI_INSTANCE_T instance_handle);
+   const uint32_t num_connections,
+   VCHI_INSTANCE_T instance_handle);
 
 //When this is called, ensure that all services have no data pending.
 //Bulk transfers can remain 'queued'
@@ -172,7 +172,7 @@ extern int32_t vchi_disconnect(VCHI_INSTANCE_T 
instance_handle);
 
 // Global control over bulk CRC checking
 extern int32_t vchi_crc_control(VCHI_CONNECTION_T *connection,
- VCHI_CRC_CONTROL_T control);
+   VCHI_CRC_CONTROL_T control);
 
 // helper functions
 extern void * vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t 
*length);
@@ -184,19 +184,19 @@ extern uint32_t vchi_current_time(VCHI_INSTANCE_T 
instance_handle);
  */
 // Routine to create a named service
 extern int32_t vchi_service_create(VCHI_INSTANCE_T instance_handle,
-SERVICE_CREATION_T *setup,
-VCHI_SERVICE_HANDLE_T *handle);
+  SERVICE_CREATION_T *setup,
+  VCHI_SERVICE_HANDLE_T *handle);
 
 // Routine to destroy a service
 extern int32_t vchi_service_destroy(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to open a named service
 extern int32_t vchi_service_open(VCHI_INSTANCE_T instance_handle,
-  SERVICE_CREATION_T *setup,
-  VCHI_SERVICE_HANDLE_T *handle);
+SERVICE_CREATION_T *setup,
+VCHI_SERVICE_HANDLE_T *handle);
 
 extern int32_t vchi_get_peer_version(const VCHI_SERVICE_HANDLE_T handle,
-  short *peer_version);
+short *peer_version);
 
 // Routine to close a named service
 extern int32_t vchi_service_close(const VCHI_SERVICE_HANDLE_T handle);
@@ -227,18 +227,18 @@ vchi_queue_user_message(VCHI_SERVICE_HANDLE_T handle,
 // Routine to receive a msg from a service
 // Dequeue is equivalent to hold, copy into client buffer, release
 extern int32_t vchi_msg_dequeue(VCHI_SERVICE_HANDLE_T handle,
- void *data,
- uint32_t max_data_size_to_read,
- uint32_t *actual_msg_size,
- VCHI_FLAGS_T flags);
+   void *data,
+   uint32_t max_data_size_to_read,
+   uint32_t *actual_msg_size,
+   VCHI_FLAGS_T flags);
 
 // Routine to look at a message in place.
 // The message

[PATCH v2 5/5] staging: vc04_services: Remove spaces after '*'

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: "foo * bar" should be "foo* bar"

in the interface/vchi directory

Signed-off-by: Aymen Qader 
---
 drivers/staging/vc04_services/interface/vchi/vchi.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index f818cf2e27e1..77bf92018165 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -154,7 +154,7 @@ typedef struct service_info_tag {
 extern "C" {
 #endif
 
-extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection(const 
VCHI_CONNECTION_API_T * function_table,
+extern /*@observer@*/ VCHI_CONNECTION_T *vchi_create_connection(const 
VCHI_CONNECTION_API_T * function_table,
 const 
VCHI_MESSAGE_DRIVER_T * low_level);
 
 // Routine used to initialise the vchi on both local + remote connections
@@ -175,7 +175,7 @@ extern int32_t vchi_crc_control(VCHI_CONNECTION_T 
*connection,
VCHI_CRC_CONTROL_T control);
 
 // helper functions
-extern void * vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t 
*length);
+extern void *vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t 
*length);
 extern void vchi_free_buffer(VCHI_SERVICE_HANDLE_T handle, void *address);
 extern uint32_t vchi_current_time(VCHI_INSTANCE_T instance_handle);
 
-- 
2.17.1

[PATCH v2 4/5] staging: vc04_services: Surround complex macros

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: Macros with complex values should be enclosed in parentheses

in the interface/vchi directory

Signed-off-by: Aymen Qader 
---
 drivers/staging/vc04_services/interface/vchi/vchi.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index d8e660240a44..f818cf2e27e1 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -92,14 +92,14 @@ typedef struct vchi_msg_vector_ex {
 } VCHI_MSG_VECTOR_EX_T;
 
 // Construct an entry in a msg vector for a pointer (p) of length (l)
-#define VCHI_VEC_POINTER(p, l)  VCHI_VEC_POINTER, { { (VCHI_MEM_HANDLE_T)(p), 
(l) } }
+#define VCHI_VEC_POINTER(p, l)  (VCHI_VEC_POINTER, { { (VCHI_MEM_HANDLE_T)(p), 
(l) } })
 
 // Construct an entry in a msg vector for a message handle (h), starting at 
offset (o) of length (l)
-#define VCHI_VEC_HANDLE(h, o, l) VCHI_VEC_HANDLE,  { { (h), (o), (l) } }
+#define VCHI_VEC_HANDLE(h, o, l) (VCHI_VEC_HANDLE,  { { (h), (o), (l) } })
 
 // Macros to manipulate 'FOURCC' values
 #define MAKE_FOURCC(x) ((int32_t)((x[0] << 24) | (x[1] << 16) | (x[2] << 8) | 
x[3]))
-#define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF, (x >> 16) & 0xFF, (x >> 8) & 0xFF, 
x & 0xFF
+#define FOURCC_TO_CHAR(x) ((x >> 24) & 0xFF, (x >> 16) & 0xFF, (x >> 8) & 
0xFF, x & 0xFF)
 
 // Opaque service information
 struct opaque_vchi_service_t;
-- 
2.17.1

[PATCH v2 1/5] staging: vc04_services: Fix "space prohibited"

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: space prohibited after/before that open/closed parenthesis

in the interface/vchi directory.

Signed-off-by: Aymen Qader 
---
 .../vc04_services/interface/vchi/vchi.h   | 106 +-
 .../vc04_services/interface/vchi/vchi_cfg.h   |   2 +-
 2 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 66a3a060fad2..ffb8caaacaea 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -98,7 +98,7 @@ typedef struct vchi_msg_vector_ex {
 #define VCHI_VEC_HANDLE(h,o,l) VCHI_VEC_HANDLE,  { { (h), (o), (l) } }
 
 // Macros to manipulate 'FOURCC' values
-#define MAKE_FOURCC(x) ((int32_t)( (x[0] << 24) | (x[1] << 16) | (x[2] << 8) | 
x[3] ))
+#define MAKE_FOURCC(x) ((int32_t)((x[0] << 24) | (x[1] << 16) | (x[2] << 8) | 
x[3]))
 #define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF,(x >> 16) & 0xFF,(x >> 8) & 0xFF, x 
& 0xFF
 
 // Opaque service information
@@ -154,25 +154,25 @@ typedef struct service_info_tag {
 extern "C" {
 #endif
 
-extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection( const 
VCHI_CONNECTION_API_T * function_table,
+extern /*@observer@*/ VCHI_CONNECTION_T * vchi_create_connection(const 
VCHI_CONNECTION_API_T * function_table,
const VCHI_MESSAGE_DRIVER_T 
* low_level);
 
 // Routine used to initialise the vchi on both local + remote connections
-extern int32_t vchi_initialise( VCHI_INSTANCE_T *instance_handle );
+extern int32_t vchi_initialise(VCHI_INSTANCE_T *instance_handle);
 
-extern int32_t vchi_exit( void );
+extern int32_t vchi_exit(void);
 
-extern int32_t vchi_connect( VCHI_CONNECTION_T **connections,
+extern int32_t vchi_connect(VCHI_CONNECTION_T **connections,
  const uint32_t num_connections,
- VCHI_INSTANCE_T instance_handle );
+ VCHI_INSTANCE_T instance_handle);
 
 //When this is called, ensure that all services have no data pending.
 //Bulk transfers can remain 'queued'
-extern int32_t vchi_disconnect( VCHI_INSTANCE_T instance_handle );
+extern int32_t vchi_disconnect(VCHI_INSTANCE_T instance_handle);
 
 // Global control over bulk CRC checking
-extern int32_t vchi_crc_control( VCHI_CONNECTION_T *connection,
- VCHI_CRC_CONTROL_T control );
+extern int32_t vchi_crc_control(VCHI_CONNECTION_T *connection,
+ VCHI_CRC_CONTROL_T control);
 
 // helper functions
 extern void * vchi_allocate_buffer(VCHI_SERVICE_HANDLE_T handle, uint32_t 
*length);
@@ -183,32 +183,32 @@ extern uint32_t vchi_current_time(VCHI_INSTANCE_T 
instance_handle);
  Global service API
  */
 // Routine to create a named service
-extern int32_t vchi_service_create( VCHI_INSTANCE_T instance_handle,
+extern int32_t vchi_service_create(VCHI_INSTANCE_T instance_handle,
 SERVICE_CREATION_T *setup,
-VCHI_SERVICE_HANDLE_T *handle );
+VCHI_SERVICE_HANDLE_T *handle);
 
 // Routine to destroy a service
-extern int32_t vchi_service_destroy( const VCHI_SERVICE_HANDLE_T handle );
+extern int32_t vchi_service_destroy(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to open a named service
-extern int32_t vchi_service_open( VCHI_INSTANCE_T instance_handle,
+extern int32_t vchi_service_open(VCHI_INSTANCE_T instance_handle,
   SERVICE_CREATION_T *setup,
   VCHI_SERVICE_HANDLE_T *handle);
 
-extern int32_t vchi_get_peer_version( const VCHI_SERVICE_HANDLE_T handle,
-  short *peer_version );
+extern int32_t vchi_get_peer_version(const VCHI_SERVICE_HANDLE_T handle,
+  short *peer_version);
 
 // Routine to close a named service
-extern int32_t vchi_service_close( const VCHI_SERVICE_HANDLE_T handle );
+extern int32_t vchi_service_close(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to increment ref count on a named service
-extern int32_t vchi_service_use( const VCHI_SERVICE_HANDLE_T handle );
+extern int32_t vchi_service_use(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to decrement ref count on a named service
-extern int32_t vchi_service_release( const VCHI_SERVICE_HANDLE_T handle );
+extern int32_t vchi_service_release(const VCHI_SERVICE_HANDLE_T handle);
 
 // Routine to set a control option for a named service
-extern int32_t vchi_service_set_option( const VCHI_SERVICE_HANDLE_T handle,
+extern int32_t vchi_service_set_option(const VCHI_SERVICE_HANDLE_T handle,
VCHI_SERVICE_OPTION_T option,
   

[PATCH v2 3/5] staging: vc04_services: Add spaces after commas

[Aymen Qader]

This patch fixes the checkpatch.pl error:

ERROR: space required after that ','

in the interface/vchi directory

Signed-off-by: Aymen Qader 
---
 drivers/staging/vc04_services/interface/vchi/vchi.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h 
b/drivers/staging/vc04_services/interface/vchi/vchi.h
index cb2582a4eb6a..d8e660240a44 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -92,14 +92,14 @@ typedef struct vchi_msg_vector_ex {
 } VCHI_MSG_VECTOR_EX_T;
 
 // Construct an entry in a msg vector for a pointer (p) of length (l)
-#define VCHI_VEC_POINTER(p,l)  VCHI_VEC_POINTER, { { (VCHI_MEM_HANDLE_T)(p), 
(l) } }
+#define VCHI_VEC_POINTER(p, l)  VCHI_VEC_POINTER, { { (VCHI_MEM_HANDLE_T)(p), 
(l) } }
 
 // Construct an entry in a msg vector for a message handle (h), starting at 
offset (o) of length (l)
-#define VCHI_VEC_HANDLE(h,o,l) VCHI_VEC_HANDLE,  { { (h), (o), (l) } }
+#define VCHI_VEC_HANDLE(h, o, l) VCHI_VEC_HANDLE,  { { (h), (o), (l) } }
 
 // Macros to manipulate 'FOURCC' values
 #define MAKE_FOURCC(x) ((int32_t)((x[0] << 24) | (x[1] << 16) | (x[2] << 8) | 
x[3]))
-#define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF,(x >> 16) & 0xFF,(x >> 8) & 0xFF, x 
& 0xFF
+#define FOURCC_TO_CHAR(x) (x >> 24) & 0xFF, (x >> 16) & 0xFF, (x >> 8) & 0xFF, 
x & 0xFF
 
 // Opaque service information
 struct opaque_vchi_service_t;
-- 
2.17.1

RE: [PATCH] RDMA/i40iw: Fix incorrect iterator type

[Saleem, Shiraz]

>Subject: [PATCH] RDMA/i40iw: Fix incorrect iterator type
>
>Commit f27b4746f378 ("i40iw: add connection management code") uses an
>incorrect rcu iterator, whilst holding the rtnl_lock. Since the critical 
>region invokes
>i40iw_manage_qhash(), which is a sleeping function, the rcu locking and
>traversal cannot be used.
>
>Signed-off-by: Håkon Bugge 
>---
> drivers/infiniband/hw/i40iw/i40iw_cm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)

Thanks doing this Hakon!

Acked-by: Shiraz Saleem 

Re: [PATCH] ARM: dts: Add support for Liebherr's BK4 device (vf610 based)

[Fabio Estevam]

On Fri, Sep 21, 2018 at 12:27 PM, Lukasz Majewski  wrote:
> This commit adds DTS support for BK4 device from Liebherr. It
> uses vf610 SoC from NXP.
>
> Signed-off-by: Lukasz Majewski 
> ---
>  arch/arm/boot/dts/Makefile  |   1 +
>  arch/arm/boot/dts/vf610-bk4.dts | 504 
> 
>  2 files changed, 505 insertions(+)
>  create mode 100644 arch/arm/boot/dts/vf610-bk4.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index b5bd3de87c33..e6f159895fa9 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -577,6 +577,7 @@ dtb-$(CONFIG_SOC_LS1021A) += \
> ls1021a-twr.dtb
>  dtb-$(CONFIG_SOC_VF610) += \
> vf500-colibri-eval-v3.dtb \
> +   vf610-bk4.dtb \
> vf610-colibri-eval-v3.dtb \
> vf610m4-colibri.dtb \
> vf610-cosmic.dtb \
> diff --git a/arch/arm/boot/dts/vf610-bk4.dts b/arch/arm/boot/dts/vf610-bk4.dts
> new file mode 100644
> index ..4ad7e739a0ad
> --- /dev/null
> +++ b/arch/arm/boot/dts/vf610-bk4.dts
> @@ -0,0 +1,504 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2018
> + * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
> + */
> +
> +/dts-v1/;
> +#include "vf610.dtsi"
> +
> +/ {
> +   model = "Liebherr BK4 controller";
> +   compatible = "lwn,bk4", "fsl,vf610";
> +
> +   chosen {
> +   bootargs = "console=ttyLP1,115200";

You could pass stdout-path instead.

> +   };
> +
> +   memory@8000 {
> +   reg = <0x8000 0x800>;
> +   };
> +
> +   audio_ext: mclk_osc {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <24576000>;
> +   };

This seems to be unused.

> +
> +   enet_ext: eth_osc {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0>;
> +   clock-frequency = <5000>;
> +   };
> +
> +   leds {
> +   compatible = "gpio-leds";
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&pinctrl_gpio_leds>;
> +
> +   /* LED D5 */
> +   led0: heartbeat {
> +   label = "heartbeat";
> +   gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
> +   default-state = "on";
> +   linux,default-trigger = "heartbeat";
> +   };
> +   };
> +
> +   regulators {
> +   compatible = "simple-bus";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   reg_3p3v: regulator@0 {

Please move all regulators outside of the simple-bus container and use
this naming convention:

reg_3p3v: regulator-3p3v {

> +&dspi3 {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <&pinctrl_dspi3>;
> +   bus-num = <3>;
> +   status = "okay";
> +
> +   spidev3@0 {
> +   compatible = "fsl,vf610-dspi";
> +   spi-max-frequency = <3000>;
> +   reg = <0>;
> +   fsl,spi-slave-mode;

Such property does not exist.

I also thought that spidev nodes in dt were not recommended.

> +&iomuxc {

Like Stefan mentioned it is common practice on imx dts files to place
the iomuxc node as the last one.


> +   pinctrl-names = "default";
> +   pinctrl-0 = <&pinctrl_bk4_common>;

This seems to be not called from any driver.

We usually use a hog group for such purpose.

> +
> +   pinctrl_bk4_common: commongrp {
> +   fsl,pins = <
> +   /* One_Wire_PSU_EN */
> +   VF610_PAD_PTC29__GPIO_102   0x1183
> +   /* SPI */
> +   VF610_PAD_PTB26__GPIO_960x1183
> +   VF610_PAD_PTE14__GPIO_119   0x1183
> +   VF610_PAD_PTE4__GPIO_1090x1181
> +   /* Feedback_Lines */
> +   VF610_PAD_PTC31__GPIO_104   0x1181
> +   VF610_PAD_PTA7__GPIO_1340x1181
> +   VF610_PAD_PTD9__GPIO_88 0x1181
> +   VF610_PAD_PTE1__GPIO_1060x1183
> +   VF610_PAD_PTB2__GPIO_24 0x1181
> +   VF610_PAD_PTB3__GPIO_25 0x1181
> +   VF610_PAD_PTB1__GPIO_23 0x1181
> +   /* SDHC */
> +   VF610_PAD_PTE19__GPIO_124   0x1183
> +   VF610_PAD_PTB23__GPIO_930x1181

If they are related to SDHC they should be better placed under the sdhc nodes.


> +   /* GPI */
> +   VF610_PAD_PTE2__GPIO_1070x1181
> +   VF610_PAD_PTE3__GPIO_1080x1181
> +   VF610_PAD_PTE5__GPIO_110