[PATCH] staging : rtl8188eu : remove void function return

[Surender Polsani]

kernel coding style doesn't allow the return statement
in void function.

Signed-off-by: Surender Polsani 
---
Changes for v2:
corrected subject line as suggested
Changes for v3:
modified from line as suggested by Greg KH
placed a semicolon in label for fixing build error
---
 drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
index d04b7fb..428996e 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
@@ -165,7 +165,7 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter)
 skip_dm:
/*  Check GPIO to determine current RF on/off and Pbc status. */
/*  Check Hardware Radio ON/OFF or not */
-   return;
+   ;
 }
 
 void rtw_hal_dm_init(struct adapter *Adapter)
-- 
1.9.1

[PATCH] staging : rtl8188eu : remove void function return

[Surender Polsani]

kernel coding style doesn't allow the return statement
in void function.

Signed-off-by: Surender Polsani 
---
Changes for v2:
corrected subject line as suggested
Changes for v3:
modified from line as suggested by Greg KH
placed a semicolon in label for fixing build error
---
 drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
index d04b7fb..428996e 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
@@ -165,7 +165,7 @@ void rtw_hal_dm_watchdog(struct adapter *Adapter)
 skip_dm:
/*  Check GPIO to determine current RF on/off and Pbc status. */
/*  Check Hardware Radio ON/OFF or not */
-   return;
+   ;
 }
 
 void rtw_hal_dm_init(struct adapter *Adapter)
-- 
1.9.1

linux-next: Tree for May 3

[Stephen Rothwell]

Hi all,

Please do not add any v4.13 destined material in your linux-next
included branches until after v4.12-rc1 has been released.

Changes since 20170502:

The kbuild tree gained a conflict against Linus' tree.

The metag tree gained a conflict against Linus' tree.

The nfs tree gained a conflict against Linus' tree.

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

I added a supplied build fix patch to the merge of the iommu tree.

Non-merge commits (relative to Linus' tree): 10894
 9725 files changed, 1182075 insertions(+), 200900 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 and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) 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.

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 37 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 (204f144c9fca Merge branch 'work.compat' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (36b5a5152119 arc: axs10x: Fix ARC PGU default 
clock frequency)
Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector 
table around v7m_invalidate_l1 call)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (f83246089ca0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (0060e79a1f52 Merge tag 'clk-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux)
Merging ipsec/master (cfcf99f987ba xfrm: fix GRO for !CONFIG_NETFILTER)
Merging netfilter/master (1519fccb3437 netfilter: update MAINTAINERS file)
Merging ipvs/master (c8d6c6b496dc ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (a351e9b9fc24 Linux 4.11)
Merging sound-current/for-linus (a5c3b32a1146 Merge tag 'asoc-v4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding 
(hisi-pcie-almost-ecam))
Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6)
Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (0337966d121e Merge branch 'next' into 
for-linus)
CONFLICT (content): Merge conflict in Documentation/input/ff.rst
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF mo

linux-next: Tree for May 3

[Stephen Rothwell]

Hi all,

Please do not add any v4.13 destined material in your linux-next
included branches until after v4.12-rc1 has been released.

Changes since 20170502:

The kbuild tree gained a conflict against Linus' tree.

The metag tree gained a conflict against Linus' tree.

The nfs tree gained a conflict against Linus' tree.

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

I added a supplied build fix patch to the merge of the iommu tree.

Non-merge commits (relative to Linus' tree): 10894
 9725 files changed, 1182075 insertions(+), 200900 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 and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) 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.

Below is a summary of the state of the merge.

I am currently merging 258 trees (counting Linus' and 37 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 (204f144c9fca Merge branch 'work.compat' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging fixes/master (97da3854c526 Linux 4.11-rc3)
Merging kbuild-current/fixes (9be3213b14d4 gconfig: remove misleading 
parentheses around a condition)
Merging arc-current/for-curr (36b5a5152119 arc: axs10x: Fix ARC PGU default 
clock frequency)
Merging arm-current/fixes (6d8059493691 ARM: 8670/1: V7M: Do not corrupt vector 
table around v7m_invalidate_l1 call)
Merging m68k-current/for-linus (f6ab4d59a5fe nubus: Add MVC and VSC video card 
definitions)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (be5c5e843c4a powerpc/64: Fix HMI exception on LE 
with CONFIG_RELOCATABLE=y)
Merging sparc/master (f83246089ca0 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (0060e79a1f52 Merge tag 'clk-fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux)
Merging ipsec/master (cfcf99f987ba xfrm: fix GRO for !CONFIG_NETFILTER)
Merging netfilter/master (1519fccb3437 netfilter: update MAINTAINERS file)
Merging ipvs/master (c8d6c6b496dc ipvs: SNAT packet replies only for NATed 
connections)
Merging wireless-drivers/master (d77facb88448 brcmfmac: use local iftype 
avoiding use-after-free of virtual interface)
Merging mac80211/master (a351e9b9fc24 Linux 4.11)
Merging sound-current/for-linus (a5c3b32a1146 Merge tag 'asoc-v4.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (b9c1153f7a9c PCI: hisi: Fix DT binding 
(hisi-pcie-almost-ecam))
Merging driver-core.current/driver-core-linus (39da7c509acf Linux 4.11-rc6)
Merging tty.current/tty-linus (4f7d029b9bf0 Linux 4.11-rc7)
Merging usb.current/usb-linus (a71c9a1c779f Linux 4.11-rc5)
Merging usb-gadget-fixes/fixes (25cd9721c2b1 usb: gadget: f_hid: fix: Don't 
access hidg->req without spinlock held)
Merging usb-serial-fixes/usb-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (1a09b6a7c10e phy: qcom-usb-hs: Add depends on EXTCON)
Merging staging.current/staging-linus (39da7c509acf Linux 4.11-rc6)
Merging char-misc.current/char-misc-linus (c02ed2e75ef4 Linux 4.11-rc4)
Merging input-current/for-linus (0337966d121e Merge branch 'next' into 
for-linus)
CONFLICT (content): Merge conflict in Documentation/input/ff.rst
Merging crypto-current/master (929562b14478 crypto: stm32 - Fix OF mo

Re: linux-next: build warning after merge of the devicetree tree

[Stephen Rothwell]

Hi Rob,

On Fri, 28 Apr 2017 12:45:03 +1000 Stephen Rothwell  
wrote:
>
> After merging the devicetree tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/of/unittest.c: In function 'of_unittest':
> drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>last_sibling->sibling = overlay_base_root->child;
>  ^
> drivers/of/unittest.c:2122:22: note: 'last_sibling' was declared here
>   struct device_node *last_sibling;
>   ^
> 
> Introduced by commit
> 
>   81d0848fc8d2 ("of: Add unit tests for applying overlays")

Ping?
-- 
Cheers,
Stephen Rothwell

Re: linux-next: build warning after merge of the devicetree tree

[Stephen Rothwell]

Hi Rob,

On Fri, 28 Apr 2017 12:45:03 +1000 Stephen Rothwell  
wrote:
>
> After merging the devicetree tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
> 
> drivers/of/unittest.c: In function 'of_unittest':
> drivers/of/unittest.c:2199:25: warning: 'last_sibling' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>last_sibling->sibling = overlay_base_root->child;
>  ^
> drivers/of/unittest.c:2122:22: note: 'last_sibling' was declared here
>   struct device_node *last_sibling;
>   ^
> 
> Introduced by commit
> 
>   81d0848fc8d2 ("of: Add unit tests for applying overlays")

Ping?
-- 
Cheers,
Stephen Rothwell

Re: [RFC PATCH 8/9] debugfs: defer debugfs_fsdata allocation to first usage

[Johannes Berg]

On Tue, 2017-05-02 at 22:05 +0200, Nicolai Stange wrote:

> > So either you could return some valid ops (perhaps
> > debugfs_noop_file_operations although those don't have .name or
> > .poll, so it doesn't cover everything), or you can just BUG_ON()
> > here directly, saving the incomprehensible crash later.
> 
> The purpose of that WARN_ON() there was to turn a potentially
> incomprehensible crash into a comprehensible one ;)
> 
> In order to avoid a new BUG_ON(), what about keeping the WARN_ON() as
> is and returning NULL instead of the garbage? That would crash
> current on first access and the earlier warning would hopefully give
> some clue?

Yeah, I guess that might work. Probably less harmful to the system than
a BUG_ON(), but I still operate under the assumption that there might
actually be something mapped at NULL - not sure if that's still true.

johannes

Re: [RFC PATCH 8/9] debugfs: defer debugfs_fsdata allocation to first usage

[Johannes Berg]

On Tue, 2017-05-02 at 22:05 +0200, Nicolai Stange wrote:

> > So either you could return some valid ops (perhaps
> > debugfs_noop_file_operations although those don't have .name or
> > .poll, so it doesn't cover everything), or you can just BUG_ON()
> > here directly, saving the incomprehensible crash later.
> 
> The purpose of that WARN_ON() there was to turn a potentially
> incomprehensible crash into a comprehensible one ;)
> 
> In order to avoid a new BUG_ON(), what about keeping the WARN_ON() as
> is and returning NULL instead of the garbage? That would crash
> current on first access and the earlier warning would hopefully give
> some clue?

Yeah, I guess that might work. Probably less harmful to the system than
a BUG_ON(), but I still operate under the assumption that there might
actually be something mapped at NULL - not sure if that's still true.

johannes

Re: [PATCH v2] iio: adc: Add support for TI ADC1x8s102

[Jan Kiszka]

On 2017-05-02 22:53, Andy Shevchenko wrote:
> On Tue, May 2, 2017 at 11:02 PM, Jan Kiszka  wrote:
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>>
>> Original author: Bogdan Pricop 
>> Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel:
>> Todor Minchev .
> 
> There are several nitpicks, and one concern about regulator.
> After addressing at least the latter
> 
> Reviewed-by: Andy Shevchenko 
> 
>> +#include 
> 
>> +#include 
> 
> Redundant I beleive.
> 
>> +static int adc108s102_update_scan_mode(struct iio_dev *indio_dev,
>> +   unsigned long const *active_scan_mask)
>> +{
>> +   struct adc108s102_state *st;
>> +   unsigned int bit, cmds;
> 
>> +
>> +   st = iio_priv(indio_dev);
>> +
> 
> I think it's a quite good pattern to assign such variables above at
> definition block.
> This also would be done in several functions below (except ->probe() call)
> 
>> +   /*
>> +* Fill in the first x shorts of tx_buf with the number of channels
>> +* enabled for sampling by the triggered buffer
>> +*/
> 
> Usually in multiline comments even for one sentence we use period at the end.
> 
>> +   cmds = 0;
>> +   for_each_set_bit(bit, active_scan_mask, ADC108S102_MAX_CHANNELS)
>> +   st->tx_buf[cmds++] = cpu_to_be16(ADC108S102_CMD(bit));
>> +
>> +   /* One dummy command added, to clock in the last response */
>> +   st->tx_buf[cmds++] = 0x00;
>> +
>> +   /* build SPI ring message */
> 
>> +   st->ring_xfer.tx_buf = >tx_buf[0];
>> +   st->ring_xfer.rx_buf = >rx_buf[0];
> 
> [0] -> pointer

This is following patterns in other drivers, expressing you want the
first element here. I'll keep it.

> 
>> +   st->ring_xfer.len = cmds * sizeof(st->tx_buf[0]);
>> +
>> +   spi_message_init_with_transfers(>ring_msg, >ring_xfer, 1);
>> +
>> +   return 0;
>> +}
>> +
>> +static irqreturn_t adc108s102_trigger_handler(int irq, void *p)
>> +{
>> +   struct iio_poll_func *pf = p;
>> +   struct iio_dev *indio_dev;
>> +   struct adc108s102_state *st;
>> +   int ret;
>> +
> 
>> +   indio_dev = pf->indio_dev;
>> +   st = iio_priv(indio_dev);
> 
> Assign them above.
> 
>> +out:
> 
> I would name it out_notify.
> 
>> +   iio_trigger_notify_done(indio_dev->trig);
>> +
>> +   return IRQ_HANDLED;
>> +}
> 
>> +static int adc108s102_read_raw(struct iio_dev *indio_dev,
>> +  struct iio_chan_spec const *chan,
>> +  int *val, int *val2, long m)
>> +{
> 
>> +   int ret;
>> +   struct adc108s102_state *st;
> 
> Reversed tree order.
> 
>> +
>> +   st = iio_priv(indio_dev);
>> +
> 
> Assign it above.
> 
>> +   switch (m) {
>> +   case IIO_CHAN_INFO_RAW:
>> +   ret = iio_device_claim_direct_mode(indio_dev);
>> +   if (ret)
>> +   return ret;
>> +
>> +   ret = adc108s102_scan_direct(st, chan->address);
>> +
>> +   iio_device_release_direct_mode(indio_dev);
>> +
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   *val = ADC108S102_RES_DATA(ret);
>> +
>> +   return IIO_VAL_INT;
>> +   case IIO_CHAN_INFO_SCALE:
>> +   switch (chan->type) {
>> +   case IIO_VOLTAGE:
>> +   if (st->reg)
>> +   *val = regulator_get_voltage(st->reg) / 1000;
>> +   else
>> +   *val = st->ext_vin_mv;
>> +
>> +   *val2 = chan->scan_type.realbits;
>> +   return IIO_VAL_FRACTIONAL_LOG2;
> 
>> +   default:
>> +   return -EINVAL;
> 
> Switch-case for one case? Are you expecting more in the future?
> Here I have no strong opinion, so, leave what you / maintainers prefer.

I've no expectations on the code as I didn't write it in the first
place. There are both patterns around, but let's got for the more
compact if-else.

> 
>> +   }
>> +   default:
>> +   return -EINVAL;
>> +   }
>> +}
> 
>> +static int adc108s102_probe(struct spi_device *spi)
>> +{
>> +   struct adc108s102_state *st;
>> +   struct iio_dev *indio_dev;
>> +   u32 val;
>> +   int ret;
>> +
>> +   indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
>> +   if (!indio_dev)
>> +   return -ENOMEM;
>> +
>> +   st = iio_priv(indio_dev);
>> +
> 
>> +   ret = device_property_read_u32(>dev, "ext-vin-microvolt", );
> 
> Why not to read u16 here?
> 

Can I read a property with arbitrary width? Then this would simplify
things. Or do I have to follow how it was 

Re: [PATCH v2] iio: adc: Add support for TI ADC1x8s102

[Jan Kiszka]

On 2017-05-02 22:53, Andy Shevchenko wrote:
> On Tue, May 2, 2017 at 11:02 PM, Jan Kiszka  wrote:
>> This is an upstream port of an IIO driver for the TI ADC108S102 and
>> ADC128S102. The former can be found on the Intel Galileo Gen2 and the
>> Siemens SIMATIC IOT2000. For those boards, ACPI-based enumeration is
>> included.
>>
>> Original author: Bogdan Pricop 
>> Ported from Intel Galileo Gen2 BSP to Intel Yocto kernel:
>> Todor Minchev .
> 
> There are several nitpicks, and one concern about regulator.
> After addressing at least the latter
> 
> Reviewed-by: Andy Shevchenko 
> 
>> +#include 
> 
>> +#include 
> 
> Redundant I beleive.
> 
>> +static int adc108s102_update_scan_mode(struct iio_dev *indio_dev,
>> +   unsigned long const *active_scan_mask)
>> +{
>> +   struct adc108s102_state *st;
>> +   unsigned int bit, cmds;
> 
>> +
>> +   st = iio_priv(indio_dev);
>> +
> 
> I think it's a quite good pattern to assign such variables above at
> definition block.
> This also would be done in several functions below (except ->probe() call)
> 
>> +   /*
>> +* Fill in the first x shorts of tx_buf with the number of channels
>> +* enabled for sampling by the triggered buffer
>> +*/
> 
> Usually in multiline comments even for one sentence we use period at the end.
> 
>> +   cmds = 0;
>> +   for_each_set_bit(bit, active_scan_mask, ADC108S102_MAX_CHANNELS)
>> +   st->tx_buf[cmds++] = cpu_to_be16(ADC108S102_CMD(bit));
>> +
>> +   /* One dummy command added, to clock in the last response */
>> +   st->tx_buf[cmds++] = 0x00;
>> +
>> +   /* build SPI ring message */
> 
>> +   st->ring_xfer.tx_buf = >tx_buf[0];
>> +   st->ring_xfer.rx_buf = >rx_buf[0];
> 
> [0] -> pointer

This is following patterns in other drivers, expressing you want the
first element here. I'll keep it.

> 
>> +   st->ring_xfer.len = cmds * sizeof(st->tx_buf[0]);
>> +
>> +   spi_message_init_with_transfers(>ring_msg, >ring_xfer, 1);
>> +
>> +   return 0;
>> +}
>> +
>> +static irqreturn_t adc108s102_trigger_handler(int irq, void *p)
>> +{
>> +   struct iio_poll_func *pf = p;
>> +   struct iio_dev *indio_dev;
>> +   struct adc108s102_state *st;
>> +   int ret;
>> +
> 
>> +   indio_dev = pf->indio_dev;
>> +   st = iio_priv(indio_dev);
> 
> Assign them above.
> 
>> +out:
> 
> I would name it out_notify.
> 
>> +   iio_trigger_notify_done(indio_dev->trig);
>> +
>> +   return IRQ_HANDLED;
>> +}
> 
>> +static int adc108s102_read_raw(struct iio_dev *indio_dev,
>> +  struct iio_chan_spec const *chan,
>> +  int *val, int *val2, long m)
>> +{
> 
>> +   int ret;
>> +   struct adc108s102_state *st;
> 
> Reversed tree order.
> 
>> +
>> +   st = iio_priv(indio_dev);
>> +
> 
> Assign it above.
> 
>> +   switch (m) {
>> +   case IIO_CHAN_INFO_RAW:
>> +   ret = iio_device_claim_direct_mode(indio_dev);
>> +   if (ret)
>> +   return ret;
>> +
>> +   ret = adc108s102_scan_direct(st, chan->address);
>> +
>> +   iio_device_release_direct_mode(indio_dev);
>> +
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   *val = ADC108S102_RES_DATA(ret);
>> +
>> +   return IIO_VAL_INT;
>> +   case IIO_CHAN_INFO_SCALE:
>> +   switch (chan->type) {
>> +   case IIO_VOLTAGE:
>> +   if (st->reg)
>> +   *val = regulator_get_voltage(st->reg) / 1000;
>> +   else
>> +   *val = st->ext_vin_mv;
>> +
>> +   *val2 = chan->scan_type.realbits;
>> +   return IIO_VAL_FRACTIONAL_LOG2;
> 
>> +   default:
>> +   return -EINVAL;
> 
> Switch-case for one case? Are you expecting more in the future?
> Here I have no strong opinion, so, leave what you / maintainers prefer.

I've no expectations on the code as I didn't write it in the first
place. There are both patterns around, but let's got for the more
compact if-else.

> 
>> +   }
>> +   default:
>> +   return -EINVAL;
>> +   }
>> +}
> 
>> +static int adc108s102_probe(struct spi_device *spi)
>> +{
>> +   struct adc108s102_state *st;
>> +   struct iio_dev *indio_dev;
>> +   u32 val;
>> +   int ret;
>> +
>> +   indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
>> +   if (!indio_dev)
>> +   return -ENOMEM;
>> +
>> +   st = iio_priv(indio_dev);
>> +
> 
>> +   ret = device_property_read_u32(>dev, "ext-vin-microvolt", );
> 
> Why not to read u16 here?
> 

Can I read a property with arbitrary width? Then this would simplify
things. Or do I have to follow how it was defined in the ACPI or device
tree world?

> 
>> +   if (ret < 0) {
>> +   

[PATCH v3 4/4] rpmsg: Introduce Qualcomm RPM glink driver

[Bjorn Andersson]

This introduces a basic driver for communicating over "native glink"
with the RPM found in Qualcomm platforms.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Replace syscon with apcs_ipc doorbell implementation

Changes since v1:
- Depend on HAS_IOMEM, for UM build failure
- Wrap read/write indices on >= size, to keep the values valid when message
  aligns with end of fifo.

 drivers/rpmsg/Kconfig  |   10 +
 drivers/rpmsg/Makefile |1 +
 drivers/rpmsg/qcom_glink_rpm.c | 1225 
 3 files changed, 1236 insertions(+)
 create mode 100644 drivers/rpmsg/qcom_glink_rpm.c

diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index f12ac0b28263..449d43511c92 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -13,6 +13,16 @@ config RPMSG_CHAR
  in /dev. They make it possible for user-space programs to send and
  receive rpmsg packets.
 
+config RPMSG_QCOM_GLINK_RPM
+   tristate "Qualcomm RPM Glink driver"
+   select RPMSG
+   depends on HAS_IOMEM
+   depends on QCOM_APCS_IPC
+   help
+ Say y here to enable support for the GLINK RPM communication driver,
+ which serves as a channel for communication with the RPM in GLINK
+ enabled systems.
+
 config RPMSG_QCOM_SMD
tristate "Qualcomm Shared Memory Driver (SMD)"
depends on QCOM_SMEM
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index fae9a6d548fb..28cc19088cc0 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_RPMSG)+= rpmsg_core.o
 obj-$(CONFIG_RPMSG_CHAR)   += rpmsg_char.o
+obj-$(CONFIG_RPMSG_QCOM_GLINK_RPM) += qcom_glink_rpm.o
 obj-$(CONFIG_RPMSG_QCOM_SMD)   += qcom_smd.o
 obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
diff --git a/drivers/rpmsg/qcom_glink_rpm.c b/drivers/rpmsg/qcom_glink_rpm.c
new file mode 100644
index ..d3a4951e0b78
--- /dev/null
+++ b/drivers/rpmsg/qcom_glink_rpm.c
@@ -0,0 +1,1225 @@
+/*
+ * Copyright (c) 2016-2017, Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rpmsg_internal.h"
+
+#define RPM_TOC_SIZE   256
+#define RPM_TOC_MAGIC  0x67727430 /* grt0 */
+#define RPM_TOC_MAX_ENTRIES((RPM_TOC_SIZE - sizeof(struct rpm_toc)) / \
+sizeof(struct rpm_toc_entry))
+
+#define RPM_TX_FIFO_ID 0x61703272 /* ap2r */
+#define RPM_RX_FIFO_ID 0x72326170 /* r2ap */
+
+#define GLINK_NAME_SIZE32
+
+#define RPM_GLINK_CID_MIN  1
+#define RPM_GLINK_CID_MAX  65536
+
+struct rpm_toc_entry {
+   __le32 id;
+   __le32 offset;
+   __le32 size;
+} __packed;
+
+struct rpm_toc {
+   __le32 magic;
+   __le32 count;
+
+   struct rpm_toc_entry entries[];
+} __packed;
+
+struct glink_msg {
+   __le16 cmd;
+   __le16 param1;
+   __le32 param2;
+   u8 data[];
+} __packed;
+
+struct glink_rpm_pipe {
+   void __iomem *tail;
+   void __iomem *head;
+
+   void __iomem *fifo;
+
+   size_t length;
+};
+
+/**
+ * struct glink_defer_cmd - deferred incoming control message
+ * @node:  list node
+ * @msg:   message header
+ * data:   payload of the message
+ *
+ * Copy of a received control message, to be added to @rx_queue and processed
+ * by @rx_work of @glink_rpm.
+ */
+struct glink_defer_cmd {
+   struct list_head node;
+
+   struct glink_msg msg;
+   u8 data[];
+};
+
+/**
+ * struct glink_rpm - driver context, relates to one remote subsystem
+ * @dev:   reference to the associated struct device
+ * @doorbell:  "rpm_hlos" ipc doorbell
+ * @rx_pipe:   pipe object for receive FIFO
+ * @tx_pipe:   pipe object for transmit FIFO
+ * @irq:   IRQ for signaling incoming events
+ * @rx_work:   worker for handling received control messages
+ * @rx_lock:   protects the @rx_queue
+ * @rx_queue:  queue of received control messages to be processed in @rx_work
+ * @tx_lock:   synchronizes operations on the tx fifo
+ * @idr_lock:  synchronizes @lcids and @rcids modifications
+ * @lcids: idr of all channels with a known local channel id
+ * @rcids: idr of all channels with a known remote channel id
+ */
+struct glink_rpm {
+   struct device *dev;
+
+   struct qcom_apcs_ipc_bell *doorbell;
+
+   struct glink_rpm_pipe rx_pipe;
+  

[PATCH v3 3/4] soc: qcom: Add device tree binding for GLINK RPM

[Bjorn Andersson]

Add device tree binding documentation for the Qualcomm GLINK RPM, used
for communication with the Resource Power Management subsystem in
various Qualcomm SoCs.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Replace qcom,ipc syscon with a "doorbell"

Changes since v1:
- None

 .../devicetree/bindings/soc/qcom/qcom,glink.txt| 73 ++
 1 file changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
new file mode 100644
index ..4c8983f0dcb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
@@ -0,0 +1,73 @@
+Qualcomm RPM GLINK binding
+
+This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
+communication with the Resource Power Management system on various Qualcomm
+platforms.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,glink-rpm"
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the IRQ used by the remote processor to
+   signal this processor about communication related events
+
+- qcom,rpm-msg-ram:
+   Usage: required
+   Value type: 
+   Definition: handle to RPM message memory resource
+
+- doorbells:
+   Usage: required
+   Value type: 
+   Definition: reference to the "rpm_hlos" doorbell in APCS, as described
+   in doorbell.txt
+
+= GLINK DEVICES
+Each subnode of the GLINK node represent function tied to a virtual
+communication channel. The name of the nodes are not important. The properties
+of these nodes are defined by the individual bindings for the specific function
+- but must contain the following property:
+
+- qcom,glink-channels:
+   Usage: required
+   Value type: 
+   Definition: a list of channels tied to this function, used for matching
+   the function to a set of virtual channels
+
+= EXAMPLE
+The following example represents the GLINK RPM node on a MSM8996 device, with
+the function for the "rpm_request" channel defined, which is used for
+regualtors and root clocks.
+
+   apcs_glb: apcs-glb@982 {
+   compatible = "qcom,msm8996-apcs-hmss-global";
+   reg = <0x982 0x1000>;
+
+   #doorbell-cells = <1>;
+   };
+
+   rpm_msg_ram: memory@68000 {
+   compatible = "qcom,rpm-msg-ram";
+   reg = <0x68000 0x6000>;
+   };
+
+rpm-glink {
+   compatible = "qcom,glink-rpm";
+
+   interrupts = ;
+
+   qcom,rpm-msg-ram = <_msg_ram>;
+
+   doorbells = <_glb 0>;
+
+   rpm-requests {
+   compatible = "qcom,rpm-msm8996";
+   qcom,glink-channels = "rpm_requests";
+
+   ...
+   };
+   };
-- 
2.12.0

[PATCH v3 3/4] soc: qcom: Add device tree binding for GLINK RPM

[Bjorn Andersson]

Add device tree binding documentation for the Qualcomm GLINK RPM, used
for communication with the Resource Power Management subsystem in
various Qualcomm SoCs.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Replace qcom,ipc syscon with a "doorbell"

Changes since v1:
- None

 .../devicetree/bindings/soc/qcom/qcom,glink.txt| 73 ++
 1 file changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
new file mode 100644
index ..4c8983f0dcb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
@@ -0,0 +1,73 @@
+Qualcomm RPM GLINK binding
+
+This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
+communication with the Resource Power Management system on various Qualcomm
+platforms.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,glink-rpm"
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the IRQ used by the remote processor to
+   signal this processor about communication related events
+
+- qcom,rpm-msg-ram:
+   Usage: required
+   Value type: 
+   Definition: handle to RPM message memory resource
+
+- doorbells:
+   Usage: required
+   Value type: 
+   Definition: reference to the "rpm_hlos" doorbell in APCS, as described
+   in doorbell.txt
+
+= GLINK DEVICES
+Each subnode of the GLINK node represent function tied to a virtual
+communication channel. The name of the nodes are not important. The properties
+of these nodes are defined by the individual bindings for the specific function
+- but must contain the following property:
+
+- qcom,glink-channels:
+   Usage: required
+   Value type: 
+   Definition: a list of channels tied to this function, used for matching
+   the function to a set of virtual channels
+
+= EXAMPLE
+The following example represents the GLINK RPM node on a MSM8996 device, with
+the function for the "rpm_request" channel defined, which is used for
+regualtors and root clocks.
+
+   apcs_glb: apcs-glb@982 {
+   compatible = "qcom,msm8996-apcs-hmss-global";
+   reg = <0x982 0x1000>;
+
+   #doorbell-cells = <1>;
+   };
+
+   rpm_msg_ram: memory@68000 {
+   compatible = "qcom,rpm-msg-ram";
+   reg = <0x68000 0x6000>;
+   };
+
+rpm-glink {
+   compatible = "qcom,glink-rpm";
+
+   interrupts = ;
+
+   qcom,rpm-msg-ram = <_msg_ram>;
+
+   doorbells = <_glb 0>;
+
+   rpm-requests {
+   compatible = "qcom,rpm-msm8996";
+   qcom,glink-channels = "rpm_requests";
+
+   ...
+   };
+   };
-- 
2.12.0

[PATCH v3 4/4] rpmsg: Introduce Qualcomm RPM glink driver

[Bjorn Andersson]

This introduces a basic driver for communicating over "native glink"
with the RPM found in Qualcomm platforms.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- Replace syscon with apcs_ipc doorbell implementation

Changes since v1:
- Depend on HAS_IOMEM, for UM build failure
- Wrap read/write indices on >= size, to keep the values valid when message
  aligns with end of fifo.

 drivers/rpmsg/Kconfig  |   10 +
 drivers/rpmsg/Makefile |1 +
 drivers/rpmsg/qcom_glink_rpm.c | 1225 
 3 files changed, 1236 insertions(+)
 create mode 100644 drivers/rpmsg/qcom_glink_rpm.c

diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
index f12ac0b28263..449d43511c92 100644
--- a/drivers/rpmsg/Kconfig
+++ b/drivers/rpmsg/Kconfig
@@ -13,6 +13,16 @@ config RPMSG_CHAR
  in /dev. They make it possible for user-space programs to send and
  receive rpmsg packets.
 
+config RPMSG_QCOM_GLINK_RPM
+   tristate "Qualcomm RPM Glink driver"
+   select RPMSG
+   depends on HAS_IOMEM
+   depends on QCOM_APCS_IPC
+   help
+ Say y here to enable support for the GLINK RPM communication driver,
+ which serves as a channel for communication with the RPM in GLINK
+ enabled systems.
+
 config RPMSG_QCOM_SMD
tristate "Qualcomm Shared Memory Driver (SMD)"
depends on QCOM_SMEM
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index fae9a6d548fb..28cc19088cc0 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,4 +1,5 @@
 obj-$(CONFIG_RPMSG)+= rpmsg_core.o
 obj-$(CONFIG_RPMSG_CHAR)   += rpmsg_char.o
+obj-$(CONFIG_RPMSG_QCOM_GLINK_RPM) += qcom_glink_rpm.o
 obj-$(CONFIG_RPMSG_QCOM_SMD)   += qcom_smd.o
 obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
diff --git a/drivers/rpmsg/qcom_glink_rpm.c b/drivers/rpmsg/qcom_glink_rpm.c
new file mode 100644
index ..d3a4951e0b78
--- /dev/null
+++ b/drivers/rpmsg/qcom_glink_rpm.c
@@ -0,0 +1,1225 @@
+/*
+ * Copyright (c) 2016-2017, Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rpmsg_internal.h"
+
+#define RPM_TOC_SIZE   256
+#define RPM_TOC_MAGIC  0x67727430 /* grt0 */
+#define RPM_TOC_MAX_ENTRIES((RPM_TOC_SIZE - sizeof(struct rpm_toc)) / \
+sizeof(struct rpm_toc_entry))
+
+#define RPM_TX_FIFO_ID 0x61703272 /* ap2r */
+#define RPM_RX_FIFO_ID 0x72326170 /* r2ap */
+
+#define GLINK_NAME_SIZE32
+
+#define RPM_GLINK_CID_MIN  1
+#define RPM_GLINK_CID_MAX  65536
+
+struct rpm_toc_entry {
+   __le32 id;
+   __le32 offset;
+   __le32 size;
+} __packed;
+
+struct rpm_toc {
+   __le32 magic;
+   __le32 count;
+
+   struct rpm_toc_entry entries[];
+} __packed;
+
+struct glink_msg {
+   __le16 cmd;
+   __le16 param1;
+   __le32 param2;
+   u8 data[];
+} __packed;
+
+struct glink_rpm_pipe {
+   void __iomem *tail;
+   void __iomem *head;
+
+   void __iomem *fifo;
+
+   size_t length;
+};
+
+/**
+ * struct glink_defer_cmd - deferred incoming control message
+ * @node:  list node
+ * @msg:   message header
+ * data:   payload of the message
+ *
+ * Copy of a received control message, to be added to @rx_queue and processed
+ * by @rx_work of @glink_rpm.
+ */
+struct glink_defer_cmd {
+   struct list_head node;
+
+   struct glink_msg msg;
+   u8 data[];
+};
+
+/**
+ * struct glink_rpm - driver context, relates to one remote subsystem
+ * @dev:   reference to the associated struct device
+ * @doorbell:  "rpm_hlos" ipc doorbell
+ * @rx_pipe:   pipe object for receive FIFO
+ * @tx_pipe:   pipe object for transmit FIFO
+ * @irq:   IRQ for signaling incoming events
+ * @rx_work:   worker for handling received control messages
+ * @rx_lock:   protects the @rx_queue
+ * @rx_queue:  queue of received control messages to be processed in @rx_work
+ * @tx_lock:   synchronizes operations on the tx fifo
+ * @idr_lock:  synchronizes @lcids and @rcids modifications
+ * @lcids: idr of all channels with a known local channel id
+ * @rcids: idr of all channels with a known remote channel id
+ */
+struct glink_rpm {
+   struct device *dev;
+
+   struct qcom_apcs_ipc_bell *doorbell;
+
+   struct glink_rpm_pipe rx_pipe;
+   struct glink_rpm_pipe 

[PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver

[Bjorn Andersson]

This implements a driver that exposes the IPC bits found in the APCS
Global block in various Qualcomm platforms. The bits are used to signal
inter-processor communication signals from the application CPU to other
masters.

The driver implements the "doorbell" binding and could be used as basis
for a new Linux framework, if found useful outside Qualcomm.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New driver

 drivers/soc/qcom/Kconfig  |   8 ++
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/apcs-ipc.c   | 182 ++
 include/linux/soc/qcom/apcs_ipc.h |  26 ++
 4 files changed, 217 insertions(+)
 create mode 100644 drivers/soc/qcom/apcs-ipc.c
 create mode 100644 include/linux/soc/qcom/apcs_ipc.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 78b1bb7bcf20..4113da81d18b 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -1,6 +1,14 @@
 #
 # QCOM Soc drivers
 #
+config QCOM_APCS_IPC
+   tristate "Qualcomm APCS IPC driver"
+   depends on ARCH_QCOM
+   help
+ Say y here to enable support for the APCS IPC doorbell driver,
+ providing an interface for invoking the inter-process communication
+ signals from the application processor to other masters.
+
 config QCOM_GSBI
 tristate "QCOM General Serial Bus Interface"
 depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 1f30260b06b8..e15b33e5a630 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_QCOM_APCS_IPC) += apcs-ipc.o
 obj-$(CONFIG_QCOM_GSBI)+=  qcom_gsbi.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += mdt_loader.o
 obj-$(CONFIG_QCOM_PM)  +=  spm.o
diff --git a/drivers/soc/qcom/apcs-ipc.c b/drivers/soc/qcom/apcs-ipc.c
new file mode 100644
index ..ea835cb08657
--- /dev/null
+++ b/drivers/soc/qcom/apcs-ipc.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (c) 2017, Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct platform_driver qcom_apcs_ipc_driver;
+
+struct qcom_apcs_ipc {
+   struct device *dev;
+
+   void __iomem *base;
+   unsigned long offset;
+};
+
+struct qcom_apcs_ipc_bell {
+   struct qcom_apcs_ipc *apcs;
+   unsigned int bit;
+};
+
+static void qcom_apcs_ipc_release(struct device *dev, void *res)
+{
+   struct qcom_apcs_ipc_bell *bell = res;
+   struct qcom_apcs_ipc *apcs = bell->apcs;
+
+   put_device(apcs->dev);
+}
+
+/**
+ * qcom_apcs_ipc_get() - acquire a handle to a doorbell
+ * @dev:   client device handle
+ * @id:identifier of the doorbell
+ *
+ * Returns a doorbell reference, or negative errno on failure.
+ */
+struct qcom_apcs_ipc_bell *devm_qcom_apcs_ipc_get(struct device *dev,
+ const char *id)
+{
+   struct qcom_apcs_ipc_bell *bell;
+   struct platform_device *pdev;
+   struct of_phandle_args args;
+   int index = 0;
+   int ret;
+
+   if (id) {
+   index = of_property_match_string(dev->of_node,
+"doorbell-names", id);
+   if (index < 0)
+   return ERR_PTR(index);
+   }
+
+   ret = of_parse_phandle_with_args(dev->of_node, "doorbells",
+"#doorbell-cells", index, );
+   if (ret) {
+   dev_err(dev, "unable to resolve doorbell\n");
+   return ERR_PTR(-ENODEV);
+   }
+
+   pdev = of_find_device_by_node(args.np);
+   of_node_put(args.np);
+
+   if (!pdev)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   if (args.args[0] >= 32) {
+   dev_err(dev, "invalid doorbell requested\n");
+   ret = -EINVAL;
+   goto release_device;
+   }
+
+   if (pdev->dev.driver != _apcs_ipc_driver.driver) {
+   dev_err(dev, "failed to acquire apcs ipc driver\n");
+   ret = -EINVAL;
+   goto release_device;
+   }
+
+   bell = devres_alloc(qcom_apcs_ipc_release, sizeof(*bell), GFP_KERNEL);
+   if (!bell) {
+   ret = -ENOMEM;
+   goto release_device;
+   }
+
+   bell->apcs = platform_get_drvdata(pdev);
+   bell->bit = args.args[0];
+
+   devres_add(dev, bell);
+
+   return bell;
+
+release_device:
+   

[PATCH v3 2/4] soc: qcom: Introduce APCS IPC driver

[Bjorn Andersson]

This implements a driver that exposes the IPC bits found in the APCS
Global block in various Qualcomm platforms. The bits are used to signal
inter-processor communication signals from the application CPU to other
masters.

The driver implements the "doorbell" binding and could be used as basis
for a new Linux framework, if found useful outside Qualcomm.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New driver

 drivers/soc/qcom/Kconfig  |   8 ++
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/apcs-ipc.c   | 182 ++
 include/linux/soc/qcom/apcs_ipc.h |  26 ++
 4 files changed, 217 insertions(+)
 create mode 100644 drivers/soc/qcom/apcs-ipc.c
 create mode 100644 include/linux/soc/qcom/apcs_ipc.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 78b1bb7bcf20..4113da81d18b 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -1,6 +1,14 @@
 #
 # QCOM Soc drivers
 #
+config QCOM_APCS_IPC
+   tristate "Qualcomm APCS IPC driver"
+   depends on ARCH_QCOM
+   help
+ Say y here to enable support for the APCS IPC doorbell driver,
+ providing an interface for invoking the inter-process communication
+ signals from the application processor to other masters.
+
 config QCOM_GSBI
 tristate "QCOM General Serial Bus Interface"
 depends on ARCH_QCOM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 1f30260b06b8..e15b33e5a630 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_QCOM_APCS_IPC) += apcs-ipc.o
 obj-$(CONFIG_QCOM_GSBI)+=  qcom_gsbi.o
 obj-$(CONFIG_QCOM_MDT_LOADER)  += mdt_loader.o
 obj-$(CONFIG_QCOM_PM)  +=  spm.o
diff --git a/drivers/soc/qcom/apcs-ipc.c b/drivers/soc/qcom/apcs-ipc.c
new file mode 100644
index ..ea835cb08657
--- /dev/null
+++ b/drivers/soc/qcom/apcs-ipc.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (c) 2017, Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct platform_driver qcom_apcs_ipc_driver;
+
+struct qcom_apcs_ipc {
+   struct device *dev;
+
+   void __iomem *base;
+   unsigned long offset;
+};
+
+struct qcom_apcs_ipc_bell {
+   struct qcom_apcs_ipc *apcs;
+   unsigned int bit;
+};
+
+static void qcom_apcs_ipc_release(struct device *dev, void *res)
+{
+   struct qcom_apcs_ipc_bell *bell = res;
+   struct qcom_apcs_ipc *apcs = bell->apcs;
+
+   put_device(apcs->dev);
+}
+
+/**
+ * qcom_apcs_ipc_get() - acquire a handle to a doorbell
+ * @dev:   client device handle
+ * @id:identifier of the doorbell
+ *
+ * Returns a doorbell reference, or negative errno on failure.
+ */
+struct qcom_apcs_ipc_bell *devm_qcom_apcs_ipc_get(struct device *dev,
+ const char *id)
+{
+   struct qcom_apcs_ipc_bell *bell;
+   struct platform_device *pdev;
+   struct of_phandle_args args;
+   int index = 0;
+   int ret;
+
+   if (id) {
+   index = of_property_match_string(dev->of_node,
+"doorbell-names", id);
+   if (index < 0)
+   return ERR_PTR(index);
+   }
+
+   ret = of_parse_phandle_with_args(dev->of_node, "doorbells",
+"#doorbell-cells", index, );
+   if (ret) {
+   dev_err(dev, "unable to resolve doorbell\n");
+   return ERR_PTR(-ENODEV);
+   }
+
+   pdev = of_find_device_by_node(args.np);
+   of_node_put(args.np);
+
+   if (!pdev)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   if (args.args[0] >= 32) {
+   dev_err(dev, "invalid doorbell requested\n");
+   ret = -EINVAL;
+   goto release_device;
+   }
+
+   if (pdev->dev.driver != _apcs_ipc_driver.driver) {
+   dev_err(dev, "failed to acquire apcs ipc driver\n");
+   ret = -EINVAL;
+   goto release_device;
+   }
+
+   bell = devres_alloc(qcom_apcs_ipc_release, sizeof(*bell), GFP_KERNEL);
+   if (!bell) {
+   ret = -ENOMEM;
+   goto release_device;
+   }
+
+   bell->apcs = platform_get_drvdata(pdev);
+   bell->bit = args.args[0];
+
+   devres_add(dev, bell);
+
+   return bell;
+
+release_device:
+   put_device(>dev);
+
+   return 

[PATCH v3 1/4] dt-bindings: Introduce doorbell binding

[Bjorn Andersson]

Introduce the generic doorbell binding as well as a binding for the
Qualcomm APCS Global block. This is used to expose doorbell-like devices
in the system.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New binding

 .../devicetree/bindings/doorbell/doorbell.txt  | 31 +++
 .../bindings/doorbell/qcom,apcs-kpss-global.txt| 45 ++
 2 files changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/doorbell/doorbell.txt
 create mode 100644 
Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt

diff --git a/Documentation/devicetree/bindings/doorbell/doorbell.txt 
b/Documentation/devicetree/bindings/doorbell/doorbell.txt
new file mode 100644
index ..8fd814898c3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/doorbell/doorbell.txt
@@ -0,0 +1,31 @@
+Doorbell binding
+
+
+The doorbell binding is used to describe a set of doorbells for client blocks
+to ring.
+
+1) Doorbell controller
+--
+
+A doorbell controller is a device that exposes a number of doorbells, that can
+client devices can ring to signal some event to some piece of hardware.
+
+- #doorbell-cells:
+   Usage: required
+   Value type: 
+   Definition: should be 0 for single-doorbell controllers and 1 for
+   multi-doorbell controllers
+
+2) Doorbell user
+
+
+- doorbells:
+   Usage: required
+   Value type: 
+   Definition: list of doorbell references
+
+- doorbell-names:
+   Usage: optional
+   Value type: 
+   Definition: list of strings identifying each entry in the doorbells
+   property
diff --git 
a/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt 
b/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt
new file mode 100644
index ..6320e1a355cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt
@@ -0,0 +1,45 @@
+Binding for the Qualcomm APCS global block
+==
+
+This binding describes the APCS "global" block found in various Qualcomm
+platforms.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,msm8916-apcs-kpss-global",
+   "qcom,msm8996-apcs-hmss-global"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: must specify the base address and size of the global block
+
+- #doorbell-cells:
+   Usage: required
+   Value type: 
+   Definition: as described in doorbell.txt, must be 1
+
+
+= EXAMPLE
+The following example describes the APCS HMSS found in MSM8996 and part of the
+GLINK RPM referencing the "rpm_hlos" doorbell therein.
+
+   apcs_glb: apcs-glb@982 {
+   compatible = "qcom,msm8996-apcs-hmss-global";
+   reg = <0x982 0x1000>;
+
+   #doorbell-cells = <1>;
+   };
+
+rpm-glink {
+compatible = "qcom,glink-rpm";
+
+interrupts = ;
+
+qcom,rpm-msg-ram = <_msg_ram>;
+
+   doorbells = <_glb 0>;
+   };
+
-- 
2.12.0

[PATCH v3 1/4] dt-bindings: Introduce doorbell binding

[Bjorn Andersson]

Introduce the generic doorbell binding as well as a binding for the
Qualcomm APCS Global block. This is used to expose doorbell-like devices
in the system.

Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- New binding

 .../devicetree/bindings/doorbell/doorbell.txt  | 31 +++
 .../bindings/doorbell/qcom,apcs-kpss-global.txt| 45 ++
 2 files changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/doorbell/doorbell.txt
 create mode 100644 
Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt

diff --git a/Documentation/devicetree/bindings/doorbell/doorbell.txt 
b/Documentation/devicetree/bindings/doorbell/doorbell.txt
new file mode 100644
index ..8fd814898c3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/doorbell/doorbell.txt
@@ -0,0 +1,31 @@
+Doorbell binding
+
+
+The doorbell binding is used to describe a set of doorbells for client blocks
+to ring.
+
+1) Doorbell controller
+--
+
+A doorbell controller is a device that exposes a number of doorbells, that can
+client devices can ring to signal some event to some piece of hardware.
+
+- #doorbell-cells:
+   Usage: required
+   Value type: 
+   Definition: should be 0 for single-doorbell controllers and 1 for
+   multi-doorbell controllers
+
+2) Doorbell user
+
+
+- doorbells:
+   Usage: required
+   Value type: 
+   Definition: list of doorbell references
+
+- doorbell-names:
+   Usage: optional
+   Value type: 
+   Definition: list of strings identifying each entry in the doorbells
+   property
diff --git 
a/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt 
b/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt
new file mode 100644
index ..6320e1a355cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/doorbell/qcom,apcs-kpss-global.txt
@@ -0,0 +1,45 @@
+Binding for the Qualcomm APCS global block
+==
+
+This binding describes the APCS "global" block found in various Qualcomm
+platforms.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,msm8916-apcs-kpss-global",
+   "qcom,msm8996-apcs-hmss-global"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: must specify the base address and size of the global block
+
+- #doorbell-cells:
+   Usage: required
+   Value type: 
+   Definition: as described in doorbell.txt, must be 1
+
+
+= EXAMPLE
+The following example describes the APCS HMSS found in MSM8996 and part of the
+GLINK RPM referencing the "rpm_hlos" doorbell therein.
+
+   apcs_glb: apcs-glb@982 {
+   compatible = "qcom,msm8996-apcs-hmss-global";
+   reg = <0x982 0x1000>;
+
+   #doorbell-cells = <1>;
+   };
+
+rpm-glink {
+compatible = "qcom,glink-rpm";
+
+interrupts = ;
+
+qcom,rpm-msg-ram = <_msg_ram>;
+
+   doorbells = <_glb 0>;
+   };
+
-- 
2.12.0

Re: [PATCH] ia64: beatify build log for gate.so and gate-syms.o

[Masahiro Yamada]

2017-04-12 8:36 GMT+09:00 Masahiro Yamada :
> Currently, the object path is not aligned in the build log:
>
>   LDS arch/ia64/kernel/gate.lds
>   AS  arch/ia64/kernel/gate.o
>   GATE arch/ia64/kernel/gate.so
>   AS  arch/ia64/kernel/gate-data.o
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/ia64/kernel/Makefile.gate | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/ia64/kernel/Makefile.gate b/arch/ia64/kernel/Makefile.gate
> index ceeffc5..a32903a 100644
> --- a/arch/ia64/kernel/Makefile.gate
> +++ b/arch/ia64/kernel/Makefile.gate
> @@ -6,7 +6,7 @@ extra-y += gate.so gate-syms.o gate.lds gate.o
>
>  CPPFLAGS_gate.lds := -P -C -U$(ARCH)
>
> -quiet_cmd_gate = GATE $@
> +quiet_cmd_gate = GATE$@
>cmd_gate = $(CC) -nostdlib $(GATECFLAGS_$(@F)) -Wl,-T,$(filter-out 
> FORCE,$^) -o $@
>
>  GATECFLAGS_gate.so = -shared -s -Wl,-soname=linux-gate.so.1 \
> --
> 2.7.4
>

I got no response from the ia64 maintainers,
but this patch is trivial enough to be applied to kbuild tree.

Applied to linux-kbuild/kbuild.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] ia64: beatify build log for gate.so and gate-syms.o

[Masahiro Yamada]

2017-04-12 8:36 GMT+09:00 Masahiro Yamada :
> Currently, the object path is not aligned in the build log:
>
>   LDS arch/ia64/kernel/gate.lds
>   AS  arch/ia64/kernel/gate.o
>   GATE arch/ia64/kernel/gate.so
>   AS  arch/ia64/kernel/gate-data.o
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  arch/ia64/kernel/Makefile.gate | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/ia64/kernel/Makefile.gate b/arch/ia64/kernel/Makefile.gate
> index ceeffc5..a32903a 100644
> --- a/arch/ia64/kernel/Makefile.gate
> +++ b/arch/ia64/kernel/Makefile.gate
> @@ -6,7 +6,7 @@ extra-y += gate.so gate-syms.o gate.lds gate.o
>
>  CPPFLAGS_gate.lds := -P -C -U$(ARCH)
>
> -quiet_cmd_gate = GATE $@
> +quiet_cmd_gate = GATE$@
>cmd_gate = $(CC) -nostdlib $(GATECFLAGS_$(@F)) -Wl,-T,$(filter-out 
> FORCE,$^) -o $@
>
>  GATECFLAGS_gate.so = -shared -s -Wl,-soname=linux-gate.so.1 \
> --
> 2.7.4
>

I got no response from the ia64 maintainers,
but this patch is trivial enough to be applied to kbuild tree.

Applied to linux-kbuild/kbuild.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 0/3] alpha: improvements of arch/alpha/lib/Makefile

[Masahiro Yamada]

2016-09-11 16:42 GMT+09:00 Masahiro Yamada :
> While building for Alpha architecture, I noticed ugly long log
> for division routines.  So, I took a look at the Makefile.
> Here is a series of build rule cleanups.
>
>
> Masahiro Yamada (3):
>   alpha: add $(src)/ rather than $(obj)/ to make source file path
>   alpha: merge build rules of division routines
>   alpha: make short build log available for division routines
>
>  arch/alpha/lib/Makefile | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
>

No response for a long time
(probably because the maintainer status is Odd Fixes.)

Applied to linux-kbuild.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 0/3] alpha: improvements of arch/alpha/lib/Makefile

[Masahiro Yamada]

2016-09-11 16:42 GMT+09:00 Masahiro Yamada :
> While building for Alpha architecture, I noticed ugly long log
> for division routines.  So, I took a look at the Makefile.
> Here is a series of build rule cleanups.
>
>
> Masahiro Yamada (3):
>   alpha: add $(src)/ rather than $(obj)/ to make source file path
>   alpha: merge build rules of division routines
>   alpha: make short build log available for division routines
>
>  arch/alpha/lib/Makefile | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
>

No response for a long time
(probably because the maintainer status is Odd Fixes.)

Applied to linux-kbuild.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] hexagon: Use raw_copy_to_user

[Al Viro]

On Tue, May 02, 2017 at 08:52:48PM -0700, Guenter Roeck wrote:
> Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced
> __copy_to_user_hexagon() with raw_copy_to_user(), but did not catch
> all callers, resulting in the following build error.
> 
> arch/hexagon/mm/uaccess.c: In function '__clear_user_hexagon':
> arch/hexagon/mm/uaccess.c:40:3: error:
>   implicit declaration of function '__copy_to_user_hexagon'
> 
> Fixes: ac4691fac8ad ("hexagon: switch to RAW_COPY_USER")
> Cc: Al Viro 
> Signed-off-by: Guenter Roeck 

Acked-by: Al Viro 

Re: [PATCH] hexagon: Use raw_copy_to_user

[Al Viro]

On Tue, May 02, 2017 at 08:52:48PM -0700, Guenter Roeck wrote:
> Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced
> __copy_to_user_hexagon() with raw_copy_to_user(), but did not catch
> all callers, resulting in the following build error.
> 
> arch/hexagon/mm/uaccess.c: In function '__clear_user_hexagon':
> arch/hexagon/mm/uaccess.c:40:3: error:
>   implicit declaration of function '__copy_to_user_hexagon'
> 
> Fixes: ac4691fac8ad ("hexagon: switch to RAW_COPY_USER")
> Cc: Al Viro 
> Signed-off-by: Guenter Roeck 

Acked-by: Al Viro 

Re: [PATCH v6 0/4] Broadcom SBA RAID support

[Anup Patel]

On Wed, May 3, 2017 at 10:29 AM, Vinod Koul  wrote:
> On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote:
>> Hi Vinod,
>>
>> The Broadcom FlexRM patchset have been
>> merged in v4.11.
>>
>> I think you now can take this patchset in next
>> merge window. Right??
>
> Sure, please rebase and resend after -rc1 is out

Sure, I will do that.

Regards,
Anup

Re: [PATCH v6 0/4] Broadcom SBA RAID support

[Anup Patel]

On Wed, May 3, 2017 at 10:29 AM, Vinod Koul  wrote:
> On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote:
>> Hi Vinod,
>>
>> The Broadcom FlexRM patchset have been
>> merged in v4.11.
>>
>> I think you now can take this patchset in next
>> merge window. Right??
>
> Sure, please rebase and resend after -rc1 is out

Sure, I will do that.

Regards,
Anup

Re: [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

[Oza Oza]

I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.

Regards,
Oza

Re: [PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

[Oza Oza]

I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.

Regards,
Oza

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Oza]

I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.

Regards,
Oza

Re: [PATCH 2/3] iommu/pci: reserve iova for PCI masters

[Oza Oza]

I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.

Regards,
Oza

Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Oza]

I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.

Regards,
Oza

Re: [PATCH 2/3] iommu/pci: reserve iova for PCI masters

[Oza Oza]

I will send v2 after removing GERRIT details from
commit message. My apologies for the noise.

Regards,
Oza

Re: [PATCH v6 0/4] Broadcom SBA RAID support

[Vinod Koul]

On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote:
> Hi Vinod,
> 
> The Broadcom FlexRM patchset have been
> merged in v4.11.
> 
> I think you now can take this patchset in next
> merge window. Right??

Sure, please rebase and resend after -rc1 is out

-- 
~Vinod

Re: [PATCH v6 0/4] Broadcom SBA RAID support

[Vinod Koul]

On Wed, May 03, 2017 at 09:15:20AM +0530, Anup Patel wrote:
> Hi Vinod,
> 
> The Broadcom FlexRM patchset have been
> merged in v4.11.
> 
> I think you now can take this patchset in next
> merge window. Right??

Sure, please rebase and resend after -rc1 is out

-- 
~Vinod

Re: I'd like to donate a MacBook Pro

[Alex Henrie]

2017-05-01 3:03 GMT-06:00 Lukas Wunner :
> On Mon, 1 May 2017 00:27:41 -0600, Alex Henrie wrote:
>> I am confident that this is a common problem because I have found
>> various other users complaining about it:
>>
>> https://bbs.archlinux.org/viewtopic.php?pid=1613363#p1613363
>> https://bbs.archlinux.org/viewtopic.php?pid=1451053#p1451053
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668105
>> https://bugzilla.kernel.org/show_bug.cgi?id=115741
>
> Briefly looking over those links I notice some people are reporting
> the same issue on macOS.  This could indicate an EFI firmware bug
> or hardware issue.  Have you tried updating the firmware?  Has this
> issue always been present?

Everything worked fine when I first installed Linux last October. I
updated the firmware immediately before installing Linux. I think it
was a couple of months before the boot problems showed up.

2017-05-01 4:06 GMT-06:00 Greg KH :
> You are not saying what kernel version you are using here, newer ones
> have fixed issues like this.  Have you tried 4.10?  4.11?

I am currently using 4.10. I tried 4.11 yesterday and the keyboard did
not work at all. The error messages changed to:

[0.453518] ACPI Error: Needed type [Reference], found [Integer] 88045bce
3798 (20170119/exresop-103)
[0.453525] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
 [OpcodeName unavailable] (20170119/dswexec-461)
[0.453530] ACPI Error: Method parse/execution failed [\_PR.CPU0._PDC] (Node
88045e0ee320), AE_AML_OPERAND_TYPE (20170119/psparse-543)
starting version 232

A password is required to access the cryptroot volume:
Enter passphrase for /dev/sda4: [7.950202] xhci_hcd :00:14.0:
Command completion event does not match command
[   10.290329] usb 2-3: device not accepting address 2, error -62
[   20.537740] xhci_hcd :00:14:0: Command completion event does
not match command
[   35.045403] xhci_hcd :00:14.0: Error while assigning device slot ID
[   35.045659] xhci_hcd :00:14.0: Max number of devices this xHCI
host supports is 32.
[   35.045934] usb usb2-port3: couldn't allocate usb_device
[   47.419601] usb 1-3: hub failed to enable device, error -62
[   59.793777] xhci_hcd :00:14.0: Error while assigning device slot ID
[   59.794032] xhci_hcd :00:14.0: Max number of devices this xHCI
host supports is 32.
[   59.794307] usb usb1-port3: couldn't allocate usb_device
[   72.167966] xhci_hcd :00:14.0: Error while assigning device slot ID
[   72.168218] xhci_hcd :00:14.0: Max number of devices this xHCI
host supports is 32.
[   72.168493] usb usb1-port5: couldn't allocate usb_device

Today I ran a regression test to determine which commit made the
keyboard stop working entirely. The last commit that worked for me was
c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long
series of commits where the screen stays black, and after that, I
start getting errors like the one above.

Thanks for the information you've sent so far. Any ideas on how to fix
this new and serious problem with 4.11?

-Alex

Re: I'd like to donate a MacBook Pro

[Alex Henrie]

2017-05-01 3:03 GMT-06:00 Lukas Wunner :
> On Mon, 1 May 2017 00:27:41 -0600, Alex Henrie wrote:
>> I am confident that this is a common problem because I have found
>> various other users complaining about it:
>>
>> https://bbs.archlinux.org/viewtopic.php?pid=1613363#p1613363
>> https://bbs.archlinux.org/viewtopic.php?pid=1451053#p1451053
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1668105
>> https://bugzilla.kernel.org/show_bug.cgi?id=115741
>
> Briefly looking over those links I notice some people are reporting
> the same issue on macOS.  This could indicate an EFI firmware bug
> or hardware issue.  Have you tried updating the firmware?  Has this
> issue always been present?

Everything worked fine when I first installed Linux last October. I
updated the firmware immediately before installing Linux. I think it
was a couple of months before the boot problems showed up.

2017-05-01 4:06 GMT-06:00 Greg KH :
> You are not saying what kernel version you are using here, newer ones
> have fixed issues like this.  Have you tried 4.10?  4.11?

I am currently using 4.10. I tried 4.11 yesterday and the keyboard did
not work at all. The error messages changed to:

[0.453518] ACPI Error: Needed type [Reference], found [Integer] 88045bce
3798 (20170119/exresop-103)
[0.453525] ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
 [OpcodeName unavailable] (20170119/dswexec-461)
[0.453530] ACPI Error: Method parse/execution failed [\_PR.CPU0._PDC] (Node
88045e0ee320), AE_AML_OPERAND_TYPE (20170119/psparse-543)
starting version 232

A password is required to access the cryptroot volume:
Enter passphrase for /dev/sda4: [7.950202] xhci_hcd :00:14.0:
Command completion event does not match command
[   10.290329] usb 2-3: device not accepting address 2, error -62
[   20.537740] xhci_hcd :00:14:0: Command completion event does
not match command
[   35.045403] xhci_hcd :00:14.0: Error while assigning device slot ID
[   35.045659] xhci_hcd :00:14.0: Max number of devices this xHCI
host supports is 32.
[   35.045934] usb usb2-port3: couldn't allocate usb_device
[   47.419601] usb 1-3: hub failed to enable device, error -62
[   59.793777] xhci_hcd :00:14.0: Error while assigning device slot ID
[   59.794032] xhci_hcd :00:14.0: Max number of devices this xHCI
host supports is 32.
[   59.794307] usb usb1-port3: couldn't allocate usb_device
[   72.167966] xhci_hcd :00:14.0: Error while assigning device slot ID
[   72.168218] xhci_hcd :00:14.0: Max number of devices this xHCI
host supports is 32.
[   72.168493] usb usb1-port5: couldn't allocate usb_device

Today I ran a regression test to determine which commit made the
keyboard stop working entirely. The last commit that worked for me was
c09e22d5370739e16463c113525df51b5980b1d5. After that, there is a long
series of commits where the screen stays black, and after that, I
start getting errors like the one above.

Thanks for the information you've sent so far. Any ideas on how to fix
this new and serious problem with 4.11?

-Alex

Re: [RFC PATH] of/pci/dma: fix DMA configruation for PCI masters

[Oza Oza]

On Mon, Apr 24, 2017 at 7:50 PM, Rob Herring  wrote:
> On Sat, Apr 22, 2017 at 3:08 AM, Oza Pawandeep  wrote:
>> current device frmework and of framework integration assumes dma-ranges
>> in a way where memory-mapped devices define their dma-ranges.
>> dma-ranges: (child-bus-address, parent-bus-address, length).
>>
>> but iproc based SOCs and other SOCs(suc as rcar) have PCI world dma-ranges.
>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>>
>> of_dma_configure is specifically witten to take care of memory mapped 
>> devices.
>> but no implementation exists for pci to take care of pcie based memory 
>> ranges.
>> in fact pci world doesnt seem to define standard dma-ranges
>>
>> this patch served following purposes
>>
>> 1) exposes intrface to the pci host driver for thir inbound memory ranges
>>
>> 2) provide an interface to callers such as of_dma_get_ranges.
>> so then the returned size get best possible (largest) dma_mask.
>> for e.g.
>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>> we should get dev->coherent_dma_mask=0x7f.
>>
>> 3) this patch handles multiple inbound windows and dma-ranges.
>> it is left to the caller, how it wants to use them.
>> the new function returns the resources in a standard and unform way
>>
>> 4) this way the callers of of_dma_get_ranges does not need to change.
>> and
>>
>> 5) leaves scope of adding PCI flag handling for inbound memory
>> by the new function.
>>
>> Signed-off-by: Oza Pawandeep 
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..ec21191 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -6,6 +6,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -829,10 +830,30 @@ int of_dma_get_range(struct device_node *np, u64 
>> *dma_addr, u64 *paddr, u64 *siz
>> int len, naddr, nsize, pna;
>> int ret = 0;
>> u64 dmaaddr;
>> +   struct resource_entry *window;
>> +   LIST_HEAD(res);
>>
>> if (!node)
>> return -EINVAL;
>>
>> +   if (strcmp(np->name, "pci")) {
>
> Using the name is not reliable though I did recently add a dtc check
> for this. Of course, 'pcie' is valid too (and probably should be used
> for what you are testing). type is what you want to use here. We
> already have bus matching function and bus specific handlers in
> address.c. Whatever solution you come up with should be integrated
> with the existing bus specific handlers.
>
> Rob

Hi Rob,

I have addressed your comments.

now I have pushed 3 patchsets, which completely solves the problem for our SOC.

[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters.

Regards,
Oza.

Re: [RFC PATH] of/pci/dma: fix DMA configruation for PCI masters

[Oza Oza]

On Mon, Apr 24, 2017 at 7:50 PM, Rob Herring  wrote:
> On Sat, Apr 22, 2017 at 3:08 AM, Oza Pawandeep  wrote:
>> current device frmework and of framework integration assumes dma-ranges
>> in a way where memory-mapped devices define their dma-ranges.
>> dma-ranges: (child-bus-address, parent-bus-address, length).
>>
>> but iproc based SOCs and other SOCs(suc as rcar) have PCI world dma-ranges.
>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>>
>> of_dma_configure is specifically witten to take care of memory mapped 
>> devices.
>> but no implementation exists for pci to take care of pcie based memory 
>> ranges.
>> in fact pci world doesnt seem to define standard dma-ranges
>>
>> this patch served following purposes
>>
>> 1) exposes intrface to the pci host driver for thir inbound memory ranges
>>
>> 2) provide an interface to callers such as of_dma_get_ranges.
>> so then the returned size get best possible (largest) dma_mask.
>> for e.g.
>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>> we should get dev->coherent_dma_mask=0x7f.
>>
>> 3) this patch handles multiple inbound windows and dma-ranges.
>> it is left to the caller, how it wants to use them.
>> the new function returns the resources in a standard and unform way
>>
>> 4) this way the callers of of_dma_get_ranges does not need to change.
>> and
>>
>> 5) leaves scope of adding PCI flag handling for inbound memory
>> by the new function.
>>
>> Signed-off-by: Oza Pawandeep 
>>
>> diff --git a/drivers/of/address.c b/drivers/of/address.c
>> index 02b2903..ec21191 100644
>> --- a/drivers/of/address.c
>> +++ b/drivers/of/address.c
>> @@ -6,6 +6,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -829,10 +830,30 @@ int of_dma_get_range(struct device_node *np, u64 
>> *dma_addr, u64 *paddr, u64 *siz
>> int len, naddr, nsize, pna;
>> int ret = 0;
>> u64 dmaaddr;
>> +   struct resource_entry *window;
>> +   LIST_HEAD(res);
>>
>> if (!node)
>> return -EINVAL;
>>
>> +   if (strcmp(np->name, "pci")) {
>
> Using the name is not reliable though I did recently add a dtc check
> for this. Of course, 'pcie' is valid too (and probably should be used
> for what you are testing). type is what you want to use here. We
> already have bus matching function and bus specific handlers in
> address.c. Whatever solution you come up with should be integrated
> with the existing bus specific handlers.
>
> Rob

Hi Rob,

I have addressed your comments.

now I have pushed 3 patchsets, which completely solves the problem for our SOC.

[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters.

Regards,
Oza.

Re: [PATCH] Makefile: evaluate LDFLAGS_BUILD_ID only once

[Masahiro Yamada]

2017-05-01 1:16 GMT+09:00 Rabin Vincent :
> Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only
> once instead of over and over.
>
> This provides a ~20% reduction in null build time with x86 allnoconfig:
>
> $ make allnoconfig && make -j8
> $ perf stat -r5 -e sched:sched_process_exec make -j8
> -   2 119  sched:sched_process_exec
> +   1 878  sched:sched_process_exec
>
> -   1,238817018 seconds time elapsed
> +   0,971020553 seconds time elapsed
>
> Signed-off-by: Rabin Vincent 


Applied to linux-kbuild/kbuild.  Thanks!


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] Makefile: evaluate LDFLAGS_BUILD_ID only once

[Masahiro Yamada]

2017-05-01 1:16 GMT+09:00 Rabin Vincent :
> Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only
> once instead of over and over.
>
> This provides a ~20% reduction in null build time with x86 allnoconfig:
>
> $ make allnoconfig && make -j8
> $ perf stat -r5 -e sched:sched_process_exec make -j8
> -   2 119  sched:sched_process_exec
> +   1 878  sched:sched_process_exec
>
> -   1,238817018 seconds time elapsed
> +   0,971020553 seconds time elapsed
>
> Signed-off-by: Rabin Vincent 


Applied to linux-kbuild/kbuild.  Thanks!


-- 
Best Regards
Masahiro Yamada

Re: [PATCH] vmscan: scan pages until it founds eligible pages

[Minchan Kim]

On Tue, May 02, 2017 at 05:14:36PM +0200, Michal Hocko wrote:
> On Tue 02-05-17 23:51:50, Minchan Kim wrote:
> > Hi Michal,
> > 
> > On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote:
> > > On Tue 02-05-17 14:14:52, Minchan Kim wrote:
> > > > Oops, forgot to add lkml and linux-mm.
> > > > Sorry for that.
> > > > Send it again.
> > > > 
> > > > >From 8ddf1c8aa15baf085bc6e8c62ce705459d57ea4c Mon Sep 17 00:00:00 2001
> > > > From: Minchan Kim 
> > > > Date: Tue, 2 May 2017 12:34:05 +0900
> > > > Subject: [PATCH] vmscan: scan pages until it founds eligible pages
> > > > 
> > > > On Tue, May 02, 2017 at 01:40:38PM +0900, Minchan Kim wrote:
> > > > There are premature OOM happening. Although there are a ton of free
> > > > swap and anonymous LRU list of elgible zones, OOM happened.
> > > > 
> > > > With investigation, skipping page of isolate_lru_pages makes reclaim
> > > > void because it returns zero nr_taken easily so LRU shrinking is
> > > > effectively nothing and just increases priority aggressively.
> > > > Finally, OOM happens.
> > > 
> > > I am not really sure I understand the problem you are facing. Could you
> > > be more specific please? What is your configuration etc...
> > 
> > Sure, KVM guest on x86_64, It has 2G memory and 1G swap and configured
> > movablecore=1G to simulate highmem zone.
> > Workload is a process consumes 2.2G memory and then random touch the
> > address space so it makes lots of swap in/out.
> > 
> > > 
> > > > balloon invoked oom-killer: 
> > > > gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), 
> > > > nodemask=(null),  order=0, oom_score_adj=0
> > > [...]
> > > > Node 0 active_anon:1698864kB inactive_anon:261256kB active_file:208kB 
> > > > inactive_file:184kB unevictable:0kB isolated(anon):0kB 
> > > > isolated(file):0kB mapped:532kB dirty:108kB writeback:0kB shmem:172kB 
> > > > writeback_tmp:0kB unstable:0kB all_unreclaimable? no
> > > > DMA free:7316kB min:32kB low:44kB high:56kB active_anon:8064kB 
> > > > inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
> > > > writepending:0kB present:15992kB managed:15908kB mlocked:0kB 
> > > > slab_reclaimable:464kB slab_unreclaimable:40kB kernel_stack:0kB 
> > > > pagetables:24kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > > > lowmem_reserve[]: 0 992 992 1952
> > > > DMA32 free:9088kB min:2048kB low:3064kB high:4080kB 
> > > > active_anon:952176kB inactive_anon:0kB active_file:36kB 
> > > > inactive_file:0kB unevictable:0kB writepending:88kB present:1032192kB 
> > > > managed:1019388kB mlocked:0kB slab_reclaimable:13532kB 
> > > > slab_unreclaimable:16460kB kernel_stack:3552kB pagetables:6672kB 
> > > > bounce:0kB free_pcp:56kB local_pcp:24kB free_cma:0kB
> > > > lowmem_reserve[]: 0 0 0 959
> > > 
> > > Hmm DMA32 has sufficient free memory to allow this order-0 request.
> > > Inactive anon lru is basically empty. Why do not we rotate a really
> > > large active anon list? Isn't this the primary problem?
> > 
> > It's a side effect by skipping page logic in isolate_lru_pages
> > I mentioned above in changelog.
> > 
> > The problem is a lot of anonymous memory in movable zone(ie, highmem)
> > and non-small memory in DMA32 zone.
> 
> Such a configuration is questionable on its own. But let't keep this
> part alone.

It seems you are misunderstood. It's really common on 32bit.
Think of 2G DRAM system on 32bit. Normally, it's 1G normal:1G highmem.
It's almost same with one I configured.

> 
> > In heavy memory pressure,
> > requesting a page in GFP_KERNEL triggers reclaim. VM knows inactive list
> > is low so it tries to deactivate pages. For it, first of all, it tries
> > to isolate pages from active list but there are lots of anonymous pages
> > from movable zone so skipping logic in isolate_lru_pages works. With
> > the result, isolate_lru_pages cannot isolate any eligible pages so
> > reclaim trial is effectively void. It continues to meet OOM.
> 
> But skipped pages should be rotated and we should eventually hit pages
> from the right zone(s). Moreover we should scan the full LRU at priority
> 0 so why exactly we hit the OOM killer?

Yes, full scan in priority 0 but keep it in mind that the number of full
LRU pages to scan is one of eligible pages, not all pages of the node.
And isolate_lru_pages have accounted skipped pages as scan count so that
VM cannot isolate any pages of eligible pages in LRU if non-eligible pages
are a lot in the LRU.

> 
> Anyway [1] has changed this behavior. Are you seeing the issue with this
> patch dropped?

Good point. Before the patch, it didn't increase scan count with skipped
pages so with reverting [1], I guess it might work but worry about
isolating lots of skipped pages into temporal pages_skipped list which
might causes premate OOM. Anyway, I will test it when I returns at
office after vacation.

Thanks.

> 
> [1] 
> 

Re: [PATCH] vmscan: scan pages until it founds eligible pages

[Minchan Kim]

On Tue, May 02, 2017 at 05:14:36PM +0200, Michal Hocko wrote:
> On Tue 02-05-17 23:51:50, Minchan Kim wrote:
> > Hi Michal,
> > 
> > On Tue, May 02, 2017 at 09:54:32AM +0200, Michal Hocko wrote:
> > > On Tue 02-05-17 14:14:52, Minchan Kim wrote:
> > > > Oops, forgot to add lkml and linux-mm.
> > > > Sorry for that.
> > > > Send it again.
> > > > 
> > > > >From 8ddf1c8aa15baf085bc6e8c62ce705459d57ea4c Mon Sep 17 00:00:00 2001
> > > > From: Minchan Kim 
> > > > Date: Tue, 2 May 2017 12:34:05 +0900
> > > > Subject: [PATCH] vmscan: scan pages until it founds eligible pages
> > > > 
> > > > On Tue, May 02, 2017 at 01:40:38PM +0900, Minchan Kim wrote:
> > > > There are premature OOM happening. Although there are a ton of free
> > > > swap and anonymous LRU list of elgible zones, OOM happened.
> > > > 
> > > > With investigation, skipping page of isolate_lru_pages makes reclaim
> > > > void because it returns zero nr_taken easily so LRU shrinking is
> > > > effectively nothing and just increases priority aggressively.
> > > > Finally, OOM happens.
> > > 
> > > I am not really sure I understand the problem you are facing. Could you
> > > be more specific please? What is your configuration etc...
> > 
> > Sure, KVM guest on x86_64, It has 2G memory and 1G swap and configured
> > movablecore=1G to simulate highmem zone.
> > Workload is a process consumes 2.2G memory and then random touch the
> > address space so it makes lots of swap in/out.
> > 
> > > 
> > > > balloon invoked oom-killer: 
> > > > gfp_mask=0x17080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), 
> > > > nodemask=(null),  order=0, oom_score_adj=0
> > > [...]
> > > > Node 0 active_anon:1698864kB inactive_anon:261256kB active_file:208kB 
> > > > inactive_file:184kB unevictable:0kB isolated(anon):0kB 
> > > > isolated(file):0kB mapped:532kB dirty:108kB writeback:0kB shmem:172kB 
> > > > writeback_tmp:0kB unstable:0kB all_unreclaimable? no
> > > > DMA free:7316kB min:32kB low:44kB high:56kB active_anon:8064kB 
> > > > inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB 
> > > > writepending:0kB present:15992kB managed:15908kB mlocked:0kB 
> > > > slab_reclaimable:464kB slab_unreclaimable:40kB kernel_stack:0kB 
> > > > pagetables:24kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> > > > lowmem_reserve[]: 0 992 992 1952
> > > > DMA32 free:9088kB min:2048kB low:3064kB high:4080kB 
> > > > active_anon:952176kB inactive_anon:0kB active_file:36kB 
> > > > inactive_file:0kB unevictable:0kB writepending:88kB present:1032192kB 
> > > > managed:1019388kB mlocked:0kB slab_reclaimable:13532kB 
> > > > slab_unreclaimable:16460kB kernel_stack:3552kB pagetables:6672kB 
> > > > bounce:0kB free_pcp:56kB local_pcp:24kB free_cma:0kB
> > > > lowmem_reserve[]: 0 0 0 959
> > > 
> > > Hmm DMA32 has sufficient free memory to allow this order-0 request.
> > > Inactive anon lru is basically empty. Why do not we rotate a really
> > > large active anon list? Isn't this the primary problem?
> > 
> > It's a side effect by skipping page logic in isolate_lru_pages
> > I mentioned above in changelog.
> > 
> > The problem is a lot of anonymous memory in movable zone(ie, highmem)
> > and non-small memory in DMA32 zone.
> 
> Such a configuration is questionable on its own. But let't keep this
> part alone.

It seems you are misunderstood. It's really common on 32bit.
Think of 2G DRAM system on 32bit. Normally, it's 1G normal:1G highmem.
It's almost same with one I configured.

> 
> > In heavy memory pressure,
> > requesting a page in GFP_KERNEL triggers reclaim. VM knows inactive list
> > is low so it tries to deactivate pages. For it, first of all, it tries
> > to isolate pages from active list but there are lots of anonymous pages
> > from movable zone so skipping logic in isolate_lru_pages works. With
> > the result, isolate_lru_pages cannot isolate any eligible pages so
> > reclaim trial is effectively void. It continues to meet OOM.
> 
> But skipped pages should be rotated and we should eventually hit pages
> from the right zone(s). Moreover we should scan the full LRU at priority
> 0 so why exactly we hit the OOM killer?

Yes, full scan in priority 0 but keep it in mind that the number of full
LRU pages to scan is one of eligible pages, not all pages of the node.
And isolate_lru_pages have accounted skipped pages as scan count so that
VM cannot isolate any pages of eligible pages in LRU if non-eligible pages
are a lot in the LRU.

> 
> Anyway [1] has changed this behavior. Are you seeing the issue with this
> patch dropped?

Good point. Before the patch, it didn't increase scan count with skipped
pages so with reverting [1], I guess it might work but worry about
isolating lots of skipped pages into temporal pages_skipped list which
might causes premate OOM. Anyway, I will test it when I returns at
office after vacation.

Thanks.

> 
> [1] 
> http://www.ozlabs.org/~akpm/mmotm/broken-out/revert-mm-vmscan-account-for-skipped-pages-as-a-partial-scan.patch
> -- 
> 

Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

[Juergen Gross]

On 02/05/17 19:23, Boris Ostrovsky wrote:
> Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and
> 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c.
> Since guest-type-neutral code refers to this variable this causes
> build failures when CONFIG_XEN_PVHVM is not defined.
> 
> Moving xen_have_vector_callback definition to enlighten.c resolves
> this issue.
> 
> Signed-off-by: Boris Ostrovsky 
> Reported-by: Randy Dunlap 

Pushed to xen/tip for-linus-4.12b


Thanks,

Juergen

Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

[Juergen Gross]

On 02/05/17 19:23, Boris Ostrovsky wrote:
> Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and
> 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c.
> Since guest-type-neutral code refers to this variable this causes
> build failures when CONFIG_XEN_PVHVM is not defined.
> 
> Moving xen_have_vector_callback definition to enlighten.c resolves
> this issue.
> 
> Signed-off-by: Boris Ostrovsky 
> Reported-by: Randy Dunlap 

Pushed to xen/tip for-linus-4.12b


Thanks,

Juergen

[PATCH 2/3] iommu/pci: reserve iova for PCI masters

[Oza Pawandeep]

this patch reserves the iova for PCI masters.
ARM64 based SOCs may have scattered memory banks.
such as iproc based SOC has

<0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
<0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */
<0x0090 0x 0x4 0x>, /* 16G @ 576G */
<0x00a0 0x 0x4 0x>; /* 16G @ 640G */

but incoming PCI transcation addressing capability is limited
by host bridge, for example if max incoming window capability
is 512 GB, then 0x0090 and 0x00a0 will fall beyond it.

to address this problem, iommu has to avoid allocating iovas which
are reserved. which inturn does not allocate iova if it falls into hole.

Bug: SOC-5216
Change-Id: Icbfc99a045d730be143fef427098c937b9d46353
Signed-off-by: Oza Pawandeep 
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40760
Reviewed-by: vpx_checkpatch status 
Reviewed-by: CCXSW 
Tested-by: vpx_autobuild status 
Tested-by: vpx_smoketest status 
Tested-by: CCXSW 
Reviewed-by: Scott Branden 

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 48d36ce..08764b0 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,8 +172,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
struct iova_domain *iovad)
 {
struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
+   struct device_node *np = bridge->dev.parent->of_node;
struct resource_entry *window;
unsigned long lo, hi;
+   int ret;
+   dma_addr_t tmp_dma_addr = 0, dma_addr;
+   LIST_HEAD(res);
 
resource_list_for_each_entry(window, >windows) {
if (resource_type(window->res) != IORESOURCE_MEM &&
@@ -183,6 +188,36 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+   /* PCI inbound memory reservation. */
+   ret = of_pci_get_dma_ranges(np, );
+   if (!ret) {
+   resource_list_for_each_entry(window, ) {
+   struct resource *res_dma = window->res;
+
+   dma_addr = res_dma->start - window->offset;
+   if (tmp_dma_addr > dma_addr) {
+   pr_warn("PCI: failed to reserve iovas; ranges 
should be sorted\n");
+   return;
+   }
+   if (tmp_dma_addr != dma_addr) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad, dma_addr - 1);
+   reserve_iova(iovad, lo, hi);
+   }
+   tmp_dma_addr = window->res->end - window->offset;
+   }
+   /*
+* the last dma-range should honour based on the
+* 32/64-bit dma addresses.
+*/
+   if (tmp_dma_addr < DMA_BIT_MASK(sizeof(dma_addr_t) * 8)) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad,
+ DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1);
+   reserve_iova(iovad, lo, hi);
+   }
+   }
 }
 
 /**
-- 
1.9.1

[PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

[Oza Pawandeep]

current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch fixes this patch fixes the bug in of_dma_get_range,
which with as is, parses the PCI memory ranges and return wrong
size as 0.

in order to get largest possible dma_mask. this patch also
retuns the largest possible size based on dma-ranges,

for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.

based on which iova allocation space will honour PCI host
bridge limitations.

Bug: SOC-5216
Change-Id: I4c534bdd17e70c6b27327d39d1656e8ed0cf56d6
Signed-off-by: Oza Pawandeep 
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40762
Reviewed-by: vpx_checkpatch status 
Reviewed-by: CCXSW 
Reviewed-by: Scott Branden 
Tested-by: vpx_autobuild status 
Tested-by: vpx_smoketest status 

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..f7734fc 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -830,6 +831,54 @@ int of_dma_get_range(struct device_node *np, u64 
*dma_addr, u64 *paddr, u64 *siz
int ret = 0;
u64 dmaaddr;
 
+#ifdef CONFIG_PCI
+   struct resource_entry *window;
+   LIST_HEAD(res);
+
+   if (!node)
+   return -EINVAL;
+
+   if (of_bus_pci_match(np)) {
+   *size = 0;
+   /*
+* PCI dma-ranges is not mandatory property.
+* many devices do no need to have it, since
+* host bridge does not require inbound memory
+* configuration or rather have design limitations.
+* so we look for dma-ranges, if missing we
+* just return the caller full size, and also
+* no dma-ranges suggests that, host bridge allows
+* whatever comes in, so we set dma_addr to 0.
+*/
+   ret = of_pci_get_dma_ranges(np, );
+   if (!ret) {
+   resource_list_for_each_entry(window, ) {
+   struct resource *res_dma = window->res;
+
+   if (*size < resource_size(res_dma)) {
+   *dma_addr = res_dma->start - window->offset;
+   *paddr = res_dma->start;
+   *size = resource_size(res_dma);
+   }
+   }
+   }
+   pci_free_resource_list();
+
+   /* ignore the empty ranges. */
+   if (*size == 0) {
+   pr_debug("empty/zero size dma-ranges found for 
node(%s)\n",
+   np->full_name);
+   *size = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
+   *dma_addr = *paddr = 0;
+   ret = 0;
+   }
+
+   pr_err("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+*dma_addr, *paddr, *size);
+   goto out;
+   }
+#endif
+
if (!node)
return -EINVAL;
 
-- 
1.9.1

[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Pawandeep]

current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch serves following:

1) exposes interface to the pci host driver for their
inbound memory ranges

2) provide an interface to callers such as of_dma_get_ranges.
so then the returned size get best possible (largest) dma_mask.
because PCI RC drivers do not call APIs such as
dma_set_coherent_mask() and hence rather it shows its addressing
capabilities based on dma-ranges.
for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.

3) this patch handles multiple inbound windows and dma-ranges.
it is left to the caller, how it wants to use them.
the new function returns the resources in a standard and unform way

4) this way the callers of for e.g. of_dma_get_ranges
does not need to change.

5) leaves scope of adding PCI flag handling for inbound memory
by the new function.

Bug: SOC-5216
Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e
Signed-off-by: Oza Pawandeep 
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428
Reviewed-by: vpx_checkpatch status 
Reviewed-by: CCXSW 
Reviewed-by: Ray Jui 
Tested-by: vpx_autobuild status 
Tested-by: vpx_smoketest status 
Tested-by: CCXSW 
Reviewed-by: Scott Branden 

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..ed6e69a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -283,6 +283,83 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
return err;
 }
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
+ * @np: device node of the host bridge having the dma-ranges property
+ * @resources: list where the range of resources will be added after DT parsing
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "dma-ranges" property of a
+ * PCI host bridge device node and setup the resource mapping based
+ * on its content.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources)
+{
+   struct device_node *node = of_node_get(np);
+   int rlen;
+   int ret = 0;
+   const int na = 3, ns = 2;
+   struct resource *res;
+   struct of_pci_range_parser parser;
+   struct of_pci_range range;
+
+   if (!node)
+   return -EINVAL;
+
+   parser.node = node;
+   parser.pna = of_n_addr_cells(node);
+   parser.np = parser.pna + na + ns;
+
+   parser.range = of_get_property(node, "dma-ranges", );
+
+   if (!parser.range) {
+   pr_debug("pcie device has no dma-ranges defined for node(%s)\n",
+ np->full_name);
+   ret = -EINVAL;
+   goto out;
+   }
+
+   parser.end = parser.range + rlen / sizeof(__be32);
+
+   for_each_of_pci_range(, ) {
+   /*
+* If we failed translation or got a zero-sized region
+* then skip this range
+*/
+   if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+   continue;
+
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+   if (!res) {
+   ret = -ENOMEM;
+   goto parse_failed;
+   }
+
+   ret = of_pci_range_to_resource(, np, res);
+   if (ret) {
+   kfree(res);
+   continue;
+   }
+
+   pci_add_resource_offset(resources, res,
+   res->start - range.pci_addr);
+   }
+
+   return ret;
+
+parse_failed:
+   pci_free_resource_list(resources);
+out:
+   of_node_put(node);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_dma_ranges);
 #endif /* CONFIG_OF_ADDRESS */
 
 #ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 0e0974e..617b90d 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -76,6 +76,7 @@ static inline void of_pci_check_probe_only(void) { }
 int of_pci_get_host_bridge_resources(struct device_node *dev,
unsigned char busno, unsigned char bus_max,
struct 

[PATCH 2/3] iommu/pci: reserve iova for PCI masters

[Oza Pawandeep]

this patch reserves the iova for PCI masters.
ARM64 based SOCs may have scattered memory banks.
such as iproc based SOC has

<0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
<0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */
<0x0090 0x 0x4 0x>, /* 16G @ 576G */
<0x00a0 0x 0x4 0x>; /* 16G @ 640G */

but incoming PCI transcation addressing capability is limited
by host bridge, for example if max incoming window capability
is 512 GB, then 0x0090 and 0x00a0 will fall beyond it.

to address this problem, iommu has to avoid allocating iovas which
are reserved. which inturn does not allocate iova if it falls into hole.

Bug: SOC-5216
Change-Id: Icbfc99a045d730be143fef427098c937b9d46353
Signed-off-by: Oza Pawandeep 
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40760
Reviewed-by: vpx_checkpatch status 
Reviewed-by: CCXSW 
Tested-by: vpx_autobuild status 
Tested-by: vpx_smoketest status 
Tested-by: CCXSW 
Reviewed-by: Scott Branden 

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 48d36ce..08764b0 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -171,8 +172,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
struct iova_domain *iovad)
 {
struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
+   struct device_node *np = bridge->dev.parent->of_node;
struct resource_entry *window;
unsigned long lo, hi;
+   int ret;
+   dma_addr_t tmp_dma_addr = 0, dma_addr;
+   LIST_HEAD(res);
 
resource_list_for_each_entry(window, >windows) {
if (resource_type(window->res) != IORESOURCE_MEM &&
@@ -183,6 +188,36 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+   /* PCI inbound memory reservation. */
+   ret = of_pci_get_dma_ranges(np, );
+   if (!ret) {
+   resource_list_for_each_entry(window, ) {
+   struct resource *res_dma = window->res;
+
+   dma_addr = res_dma->start - window->offset;
+   if (tmp_dma_addr > dma_addr) {
+   pr_warn("PCI: failed to reserve iovas; ranges 
should be sorted\n");
+   return;
+   }
+   if (tmp_dma_addr != dma_addr) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad, dma_addr - 1);
+   reserve_iova(iovad, lo, hi);
+   }
+   tmp_dma_addr = window->res->end - window->offset;
+   }
+   /*
+* the last dma-range should honour based on the
+* 32/64-bit dma addresses.
+*/
+   if (tmp_dma_addr < DMA_BIT_MASK(sizeof(dma_addr_t) * 8)) {
+   lo = iova_pfn(iovad, tmp_dma_addr);
+   hi = iova_pfn(iovad,
+ DMA_BIT_MASK(sizeof(dma_addr_t) * 8) - 1);
+   reserve_iova(iovad, lo, hi);
+   }
+   }
 }
 
 /**
-- 
1.9.1

[PATCH 3/3] PCI/of fix of_dma_get_range; get PCI specific dma-ranges

[Oza Pawandeep]

current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch fixes this patch fixes the bug in of_dma_get_range,
which with as is, parses the PCI memory ranges and return wrong
size as 0.

in order to get largest possible dma_mask. this patch also
retuns the largest possible size based on dma-ranges,

for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.

based on which iova allocation space will honour PCI host
bridge limitations.

Bug: SOC-5216
Change-Id: I4c534bdd17e70c6b27327d39d1656e8ed0cf56d6
Signed-off-by: Oza Pawandeep 
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40762
Reviewed-by: vpx_checkpatch status 
Reviewed-by: CCXSW 
Reviewed-by: Scott Branden 
Tested-by: vpx_autobuild status 
Tested-by: vpx_smoketest status 

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..f7734fc 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -830,6 +831,54 @@ int of_dma_get_range(struct device_node *np, u64 
*dma_addr, u64 *paddr, u64 *siz
int ret = 0;
u64 dmaaddr;
 
+#ifdef CONFIG_PCI
+   struct resource_entry *window;
+   LIST_HEAD(res);
+
+   if (!node)
+   return -EINVAL;
+
+   if (of_bus_pci_match(np)) {
+   *size = 0;
+   /*
+* PCI dma-ranges is not mandatory property.
+* many devices do no need to have it, since
+* host bridge does not require inbound memory
+* configuration or rather have design limitations.
+* so we look for dma-ranges, if missing we
+* just return the caller full size, and also
+* no dma-ranges suggests that, host bridge allows
+* whatever comes in, so we set dma_addr to 0.
+*/
+   ret = of_pci_get_dma_ranges(np, );
+   if (!ret) {
+   resource_list_for_each_entry(window, ) {
+   struct resource *res_dma = window->res;
+
+   if (*size < resource_size(res_dma)) {
+   *dma_addr = res_dma->start - window->offset;
+   *paddr = res_dma->start;
+   *size = resource_size(res_dma);
+   }
+   }
+   }
+   pci_free_resource_list();
+
+   /* ignore the empty ranges. */
+   if (*size == 0) {
+   pr_debug("empty/zero size dma-ranges found for 
node(%s)\n",
+   np->full_name);
+   *size = DMA_BIT_MASK(sizeof(dma_addr_t) * 8);
+   *dma_addr = *paddr = 0;
+   ret = 0;
+   }
+
+   pr_err("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
+*dma_addr, *paddr, *size);
+   goto out;
+   }
+#endif
+
if (!node)
return -EINVAL;
 
-- 
1.9.1

[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters

[Oza Pawandeep]

current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).

of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.

for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;

this patch serves following:

1) exposes interface to the pci host driver for their
inbound memory ranges

2) provide an interface to callers such as of_dma_get_ranges.
so then the returned size get best possible (largest) dma_mask.
because PCI RC drivers do not call APIs such as
dma_set_coherent_mask() and hence rather it shows its addressing
capabilities based on dma-ranges.
for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.

3) this patch handles multiple inbound windows and dma-ranges.
it is left to the caller, how it wants to use them.
the new function returns the resources in a standard and unform way

4) this way the callers of for e.g. of_dma_get_ranges
does not need to change.

5) leaves scope of adding PCI flag handling for inbound memory
by the new function.

Bug: SOC-5216
Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e
Signed-off-by: Oza Pawandeep 
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428
Reviewed-by: vpx_checkpatch status 
Reviewed-by: CCXSW 
Reviewed-by: Ray Jui 
Tested-by: vpx_autobuild status 
Tested-by: vpx_smoketest status 
Tested-by: CCXSW 
Reviewed-by: Scott Branden 

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..ed6e69a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -283,6 +283,83 @@ int of_pci_get_host_bridge_resources(struct device_node 
*dev,
return err;
 }
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
+ * @np: device node of the host bridge having the dma-ranges property
+ * @resources: list where the range of resources will be added after DT parsing
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "dma-ranges" property of a
+ * PCI host bridge device node and setup the resource mapping based
+ * on its content.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources)
+{
+   struct device_node *node = of_node_get(np);
+   int rlen;
+   int ret = 0;
+   const int na = 3, ns = 2;
+   struct resource *res;
+   struct of_pci_range_parser parser;
+   struct of_pci_range range;
+
+   if (!node)
+   return -EINVAL;
+
+   parser.node = node;
+   parser.pna = of_n_addr_cells(node);
+   parser.np = parser.pna + na + ns;
+
+   parser.range = of_get_property(node, "dma-ranges", );
+
+   if (!parser.range) {
+   pr_debug("pcie device has no dma-ranges defined for node(%s)\n",
+ np->full_name);
+   ret = -EINVAL;
+   goto out;
+   }
+
+   parser.end = parser.range + rlen / sizeof(__be32);
+
+   for_each_of_pci_range(, ) {
+   /*
+* If we failed translation or got a zero-sized region
+* then skip this range
+*/
+   if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+   continue;
+
+   res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+   if (!res) {
+   ret = -ENOMEM;
+   goto parse_failed;
+   }
+
+   ret = of_pci_range_to_resource(, np, res);
+   if (ret) {
+   kfree(res);
+   continue;
+   }
+
+   pci_add_resource_offset(resources, res,
+   res->start - range.pci_addr);
+   }
+
+   return ret;
+
+parse_failed:
+   pci_free_resource_list(resources);
+out:
+   of_node_put(node);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_dma_ranges);
 #endif /* CONFIG_OF_ADDRESS */
 
 #ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 0e0974e..617b90d 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -76,6 +76,7 @@ static inline void of_pci_check_probe_only(void) { }
 int of_pci_get_host_bridge_resources(struct device_node *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources);
 #else
 static inline int of_pci_get_host_bridge_resources(struct device_node 

Re: [PATCH 1/1] objtool: make it visible in make V=1 output

[Masahiro Yamada]

2017-04-22 0:16 GMT+09:00 Jiri Slaby :
> It is currently impossible to see what is going on with objtool when
> building, so call echo-cmd to see the actions:
>   gcc -Wp,-MD,arch/x86/entry/.entry_64.o.d  -nostdinc -isystem ...
>   ./tools/objtool/objtool check "arch/x86/entry/entry_64.o";
>
> Signed-off-by: Jiri Slaby 
> Cc: Masahiro Yamada 
> Cc: Michal Marek 
> Cc: linux-kbu...@vger.kernel.org
> Cc: Josh Poimboeuf 
> ---


Applied to linux-kbuild/kbuild.  Thanks!


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 1/1] objtool: make it visible in make V=1 output

[Masahiro Yamada]

2017-04-22 0:16 GMT+09:00 Jiri Slaby :
> It is currently impossible to see what is going on with objtool when
> building, so call echo-cmd to see the actions:
>   gcc -Wp,-MD,arch/x86/entry/.entry_64.o.d  -nostdinc -isystem ...
>   ./tools/objtool/objtool check "arch/x86/entry/entry_64.o";
>
> Signed-off-by: Jiri Slaby 
> Cc: Masahiro Yamada 
> Cc: Michal Marek 
> Cc: linux-kbu...@vger.kernel.org
> Cc: Josh Poimboeuf 
> ---


Applied to linux-kbuild/kbuild.  Thanks!


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 1/2] kbuild: cleanup signing keys with mrproper

[Masahiro Yamada]

+CC David Woodhouse
+CC David Howells


2017-04-15 6:54 GMT+09:00 Stephen Hemminger :
> When 'make mrproper' is run it was supposed to remove the signing
> keys in the certs directory, but only the filename is given
> rather than the pathanme which is necessary to cause cleanup.
>
> Signed-off-by: Stephen Hemminger 
> ---
>  Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index efa267a92ba6..04ca211552f7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1274,9 +1274,9 @@ MRPROPER_DIRS  += include/config usr/include 
> include/generated  \
>   arch/*/include/generated .tmp_objdiff
>  MRPROPER_FILES += .config .config.old .version .old_version \
>   Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
> - signing_key.pem signing_key.priv signing_key.x509 \
> - x509.genkey extra_certificates signing_key.x509.keyid \
> - signing_key.x509.signer vmlinux-gdb.py
> + certs/signing_key.pem certs/signing_key.priv 
> certs/signing_key.x509   \
> + certs/x509.genkey certs/extra_certificates 
> certs/signing_key.x509.keyid \
> + certs/signing_key.x509.signer vmlinux-gdb.py
>

The logic seems quite simple,
but I am not quite sure which file is still valid?


[1] signing_key.pem - OK, this should be certs/signing_key.pem
 and removed by 'make mrproper'

[2] signing_key.priv - deprecated by commit fb1179499134 ?

[3] signing_key.x509 - OK, this should be certs/signing_key.x509
 and removed by 'make mrproper'

[4] x509.genkey - this is an intermediate file for generating signing_key.pem,
  but unneeded for installing external modules.
  Does it make more sense to delete this by 'make clean'?

[5] extra_certificates - I am not sure where this is generated, and used

[6] siging_key.x509.keyid - same as [5]

[7] signing_key.x509.signer - same as [5]






-- 
Best Regards
Masahiro Yamada

Re: [PATCH 1/2] kbuild: cleanup signing keys with mrproper

[Masahiro Yamada]

+CC David Woodhouse
+CC David Howells


2017-04-15 6:54 GMT+09:00 Stephen Hemminger :
> When 'make mrproper' is run it was supposed to remove the signing
> keys in the certs directory, but only the filename is given
> rather than the pathanme which is necessary to cause cleanup.
>
> Signed-off-by: Stephen Hemminger 
> ---
>  Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index efa267a92ba6..04ca211552f7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1274,9 +1274,9 @@ MRPROPER_DIRS  += include/config usr/include 
> include/generated  \
>   arch/*/include/generated .tmp_objdiff
>  MRPROPER_FILES += .config .config.old .version .old_version \
>   Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
> - signing_key.pem signing_key.priv signing_key.x509 \
> - x509.genkey extra_certificates signing_key.x509.keyid \
> - signing_key.x509.signer vmlinux-gdb.py
> + certs/signing_key.pem certs/signing_key.priv 
> certs/signing_key.x509   \
> + certs/x509.genkey certs/extra_certificates 
> certs/signing_key.x509.keyid \
> + certs/signing_key.x509.signer vmlinux-gdb.py
>

The logic seems quite simple,
but I am not quite sure which file is still valid?


[1] signing_key.pem - OK, this should be certs/signing_key.pem
 and removed by 'make mrproper'

[2] signing_key.priv - deprecated by commit fb1179499134 ?

[3] signing_key.x509 - OK, this should be certs/signing_key.x509
 and removed by 'make mrproper'

[4] x509.genkey - this is an intermediate file for generating signing_key.pem,
  but unneeded for installing external modules.
  Does it make more sense to delete this by 'make clean'?

[5] extra_certificates - I am not sure where this is generated, and used

[6] siging_key.x509.keyid - same as [5]

[7] signing_key.x509.signer - same as [5]






-- 
Best Regards
Masahiro Yamada

Re: [PATCH 2/2] kbuild: remove initramfs cpio with mrproper

[Masahiro Yamada]

Hi Stephen,


2017-04-15 6:54 GMT+09:00 Stephen Hemminger :
> When 'make mrproper' is done, it should also remove the initramfs cpio
> file. I ran into this while doing test build on one machine, followed
> by make mrproper and rsync to a target machine. The build on the target
> machine would succeed but be unbootable because of the bad initramfs.


I think initramfs_data.cpio.* is unneeded for external modules.

So, shouldn't it removed by 'make clean', instead of 'make mrproper'?




> Signed-off-by: Stephen Hemminger 
> ---
>  Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 04ca211552f7..954292695bf6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1276,7 +1276,8 @@ MRPROPER_FILES += .config .config.old .version 
> .old_version \
>   Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
>   certs/signing_key.pem certs/signing_key.priv 
> certs/signing_key.x509   \
>   certs/x509.genkey certs/extra_certificates 
> certs/signing_key.x509.keyid \
> - certs/signing_key.x509.signer vmlinux-gdb.py
> + certs/signing_key.x509.signer vmlinux-gdb.py \
> + usr/initramfs_data.cpio.gz
>

As you see usr/Makefile,
datafile_y = initramfs_data.cpio$(suffix_y)

The suffix could be .gz, .bz2, .xz, etc.


Why only initramfs_data.cpio.gz?



-- 
Best Regards
Masahiro Yamada

Re: [PATCH 2/2] kbuild: remove initramfs cpio with mrproper

[Masahiro Yamada]

Hi Stephen,


2017-04-15 6:54 GMT+09:00 Stephen Hemminger :
> When 'make mrproper' is done, it should also remove the initramfs cpio
> file. I ran into this while doing test build on one machine, followed
> by make mrproper and rsync to a target machine. The build on the target
> machine would succeed but be unbootable because of the bad initramfs.


I think initramfs_data.cpio.* is unneeded for external modules.

So, shouldn't it removed by 'make clean', instead of 'make mrproper'?




> Signed-off-by: Stephen Hemminger 
> ---
>  Makefile | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 04ca211552f7..954292695bf6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1276,7 +1276,8 @@ MRPROPER_FILES += .config .config.old .version 
> .old_version \
>   Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
>   certs/signing_key.pem certs/signing_key.priv 
> certs/signing_key.x509   \
>   certs/x509.genkey certs/extra_certificates 
> certs/signing_key.x509.keyid \
> - certs/signing_key.x509.signer vmlinux-gdb.py
> + certs/signing_key.x509.signer vmlinux-gdb.py \
> + usr/initramfs_data.cpio.gz
>

As you see usr/Makefile,
datafile_y = initramfs_data.cpio$(suffix_y)

The suffix could be .gz, .bz2, .xz, etc.


Why only initramfs_data.cpio.gz?



-- 
Best Regards
Masahiro Yamada

Re: linux-next: manual merge of the net-next tree with Linus' tree

[David Miller]

From: Stephen Rothwell 
Date: Wed, 3 May 2017 11:07:03 +1000

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   arch/avr32/include/uapi/asm/socket.h
> 
> between commit:
> 
>   26202873bb51 ("avr32: remove support for AVR32 architecture")
> 
> from Linus' tree and commits:
> 
>   a2d133b1d465 ("sock: introduce SO_MEMINFO getsockopt")
>   6d4339028b35 ("net: Introduce SO_INCOMING_NAPI_ID"
>   5daab9db7b65 ("New getsockopt option to get socket cookie")
> 
> from the net-next tree.
> 
> I fixed it up (I 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.

Duly noted in the pull request I sent to Linus, and now that he took
net-next in it is resolved in his tree.

Thanks!

Re: linux-next: manual merge of the net-next tree with Linus' tree

[David Miller]

From: Stephen Rothwell 
Date: Wed, 3 May 2017 11:07:03 +1000

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   arch/avr32/include/uapi/asm/socket.h
> 
> between commit:
> 
>   26202873bb51 ("avr32: remove support for AVR32 architecture")
> 
> from Linus' tree and commits:
> 
>   a2d133b1d465 ("sock: introduce SO_MEMINFO getsockopt")
>   6d4339028b35 ("net: Introduce SO_INCOMING_NAPI_ID"
>   5daab9db7b65 ("New getsockopt option to get socket cookie")
> 
> from the net-next tree.
> 
> I fixed it up (I 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.

Duly noted in the pull request I sent to Linus, and now that he took
net-next in it is resolved in his tree.

Thanks!

Re: [PATCH 2/7] perf config: Check list empty before showing configs

[Taeung Song]

Hi Arnaldo,

On 05/03/2017 12:12 AM, Arnaldo Carvalho de Melo wrote:

Em Wed, Apr 26, 2017 at 09:21:03PM +0900, Taeung Song escreveu:

If existent config files contains nothing,
the sections list in config_set can be empty.

So check not only NULL pointer of config_set but
also the list in config_set.



+++ b/tools/perf/builtin-config.c
@@ -75,7 +75,7 @@ static int show_spec_config(struct perf_config_set *set, 
const char *var)
struct perf_config_section *section;
struct perf_config_item *item;

-   if (set == NULL)
+   if (set == NULL || list_empty(>sections))
return -1;


But should we consider an error to have an empty config file? I don't
think so :-\

- Arnaldo


I think if we do, when a config file is not only not exist but also empty,
user can see the error message
(e.g. "Nothing configured, please check your ~/.perfconfig").
And IMHO, it seems better.

But if you don't think so, I got it.

Thanks,
Taeung

Re: [PATCH 2/7] perf config: Check list empty before showing configs

[Taeung Song]

Hi Arnaldo,

On 05/03/2017 12:12 AM, Arnaldo Carvalho de Melo wrote:

Em Wed, Apr 26, 2017 at 09:21:03PM +0900, Taeung Song escreveu:

If existent config files contains nothing,
the sections list in config_set can be empty.

So check not only NULL pointer of config_set but
also the list in config_set.



+++ b/tools/perf/builtin-config.c
@@ -75,7 +75,7 @@ static int show_spec_config(struct perf_config_set *set, 
const char *var)
struct perf_config_section *section;
struct perf_config_item *item;

-   if (set == NULL)
+   if (set == NULL || list_empty(>sections))
return -1;


But should we consider an error to have an empty config file? I don't
think so :-\

- Arnaldo


I think if we do, when a config file is not only not exist but also empty,
user can see the error message
(e.g. "Nothing configured, please check your ~/.perfconfig").
And IMHO, it seems better.

But if you don't think so, I got it.

Thanks,
Taeung

[PATCH] drivers/crypto/ccp: return NULL instead of 0

[Pushkar Jambhlekar]

This change is to handle sparse warning. Return type of function is a pointer 
to the structure and
it returns 0. Instead it should return NULL.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/crypto/ccp/ccp-platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-platform.c 
b/drivers/crypto/ccp/ccp-platform.c
index 351f28d8..e26969e 100644
--- a/drivers/crypto/ccp/ccp-platform.c
+++ b/drivers/crypto/ccp/ccp-platform.c
@@ -44,7 +44,7 @@ static struct ccp_vdata *ccp_get_of_version(struct 
platform_device *pdev)
if (match && match->data)
return (struct ccp_vdata *)match->data;
 #endif
-   return 0;
+   return NULL;
 }
 
 static struct ccp_vdata *ccp_get_acpi_version(struct platform_device *pdev)
@@ -56,7 +56,7 @@ static struct ccp_vdata *ccp_get_acpi_version(struct 
platform_device *pdev)
if (match && match->driver_data)
return (struct ccp_vdata *)match->driver_data;
 #endif
-   return 0;
+   return NULL;
 }
 
 static int ccp_get_irq(struct ccp_device *ccp)
-- 
2.7.4

[PATCH] drivers/crypto/ccp: return NULL instead of 0

[Pushkar Jambhlekar]

This change is to handle sparse warning. Return type of function is a pointer 
to the structure and
it returns 0. Instead it should return NULL.

Signed-off-by: Pushkar Jambhlekar 
---
 drivers/crypto/ccp/ccp-platform.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-platform.c 
b/drivers/crypto/ccp/ccp-platform.c
index 351f28d8..e26969e 100644
--- a/drivers/crypto/ccp/ccp-platform.c
+++ b/drivers/crypto/ccp/ccp-platform.c
@@ -44,7 +44,7 @@ static struct ccp_vdata *ccp_get_of_version(struct 
platform_device *pdev)
if (match && match->data)
return (struct ccp_vdata *)match->data;
 #endif
-   return 0;
+   return NULL;
 }
 
 static struct ccp_vdata *ccp_get_acpi_version(struct platform_device *pdev)
@@ -56,7 +56,7 @@ static struct ccp_vdata *ccp_get_acpi_version(struct 
platform_device *pdev)
if (match && match->driver_data)
return (struct ccp_vdata *)match->driver_data;
 #endif
-   return 0;
+   return NULL;
 }
 
 static int ccp_get_irq(struct ccp_device *ccp)
-- 
2.7.4

Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

[Juergen Gross]

On 02/05/17 19:23, Boris Ostrovsky wrote:
> Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and
> 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c.
> Since guest-type-neutral code refers to this variable this causes
> build failures when CONFIG_XEN_PVHVM is not defined.
> 
> Moving xen_have_vector_callback definition to enlighten.c resolves
> this issue.
> 
> Signed-off-by: Boris Ostrovsky 
> Reported-by: Randy Dunlap 

Reviewed-by: Juergen Gross 


Thanks,

Juergen

Re: [PATCH] xen: Move xen_have_vector_callback definition to enlighten.c

[Juergen Gross]

On 02/05/17 19:23, Boris Ostrovsky wrote:
> Commit 84d582d236dc ("xen: Revert commits da72ff5bfcb0 and
> 72a9b186292d") defined xen_have_vector_callback in enlighten_hvm.c.
> Since guest-type-neutral code refers to this variable this causes
> build failures when CONFIG_XEN_PVHVM is not defined.
> 
> Moving xen_have_vector_callback definition to enlighten.c resolves
> this issue.
> 
> Signed-off-by: Boris Ostrovsky 
> Reported-by: Randy Dunlap 

Reviewed-by: Juergen Gross 


Thanks,

Juergen

[PATCH] hexagon: Use raw_copy_to_user

[Guenter Roeck]

Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced
__copy_to_user_hexagon() with raw_copy_to_user(), but did not catch
all callers, resulting in the following build error.

arch/hexagon/mm/uaccess.c: In function '__clear_user_hexagon':
arch/hexagon/mm/uaccess.c:40:3: error:
implicit declaration of function '__copy_to_user_hexagon'

Fixes: ac4691fac8ad ("hexagon: switch to RAW_COPY_USER")
Cc: Al Viro 
Signed-off-by: Guenter Roeck 
---
 arch/hexagon/mm/uaccess.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/hexagon/mm/uaccess.c b/arch/hexagon/mm/uaccess.c
index ec90afdb3ad0..c599eb126c9e 100644
--- a/arch/hexagon/mm/uaccess.c
+++ b/arch/hexagon/mm/uaccess.c
@@ -37,15 +37,14 @@ __kernel_size_t __clear_user_hexagon(void __user *dest, 
unsigned long count)
long uncleared;
 
while (count > PAGE_SIZE) {
-   uncleared = __copy_to_user_hexagon(dest, _zero_page,
-   PAGE_SIZE);
+   uncleared = raw_copy_to_user(dest, _zero_page, PAGE_SIZE);
if (uncleared)
return count - (PAGE_SIZE - uncleared);
count -= PAGE_SIZE;
dest += PAGE_SIZE;
}
if (count)
-   count = __copy_to_user_hexagon(dest, _zero_page, count);
+   count = raw_copy_to_user(dest, _zero_page, count);
 
return count;
 }
-- 
2.7.4

[PATCH] hexagon: Use raw_copy_to_user

[Guenter Roeck]

Commit ac4691fac8ad ("hexagon: switch to RAW_COPY_USER") replaced
__copy_to_user_hexagon() with raw_copy_to_user(), but did not catch
all callers, resulting in the following build error.

arch/hexagon/mm/uaccess.c: In function '__clear_user_hexagon':
arch/hexagon/mm/uaccess.c:40:3: error:
implicit declaration of function '__copy_to_user_hexagon'

Fixes: ac4691fac8ad ("hexagon: switch to RAW_COPY_USER")
Cc: Al Viro 
Signed-off-by: Guenter Roeck 
---
 arch/hexagon/mm/uaccess.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/hexagon/mm/uaccess.c b/arch/hexagon/mm/uaccess.c
index ec90afdb3ad0..c599eb126c9e 100644
--- a/arch/hexagon/mm/uaccess.c
+++ b/arch/hexagon/mm/uaccess.c
@@ -37,15 +37,14 @@ __kernel_size_t __clear_user_hexagon(void __user *dest, 
unsigned long count)
long uncleared;
 
while (count > PAGE_SIZE) {
-   uncleared = __copy_to_user_hexagon(dest, _zero_page,
-   PAGE_SIZE);
+   uncleared = raw_copy_to_user(dest, _zero_page, PAGE_SIZE);
if (uncleared)
return count - (PAGE_SIZE - uncleared);
count -= PAGE_SIZE;
dest += PAGE_SIZE;
}
if (count)
-   count = __copy_to_user_hexagon(dest, _zero_page, count);
+   count = raw_copy_to_user(dest, _zero_page, count);
 
return count;
 }
-- 
2.7.4

RE: [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors

[A.S. Dong]

> -Original Message-
> From: Leonard Crestez [mailto:leonard.cres...@nxp.com]
> Sent: Tuesday, May 02, 2017 10:46 PM
> To: Shawn Guo
> Cc: Leonard Crestez; Sascha Hauer; Jagan Teki; Fabio Estevam; Dong Aisheng;
> linux-arm-ker...@lists.infradead.org; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors
> 
> Enable more common cpufreq governors in imx defconfig because this is very
> useful for testing. In particular you can't use cpufreq-set -f $FREQ
> without explicitly defining CONFIG_CPU_FREQ_GOV_USERSPACE=y.
> 
> Signed-off-by: Leonard Crestez 

Well, I think we do need this.
So:
Acked-by: Dong Aisheng 

Regards
Dong Aisheng

> 
> ---
> 
> It might make sense for all governors to be enabled by default from
> drivers/cpufreq/Kconfig and allow defconfigs to be shorter.
> Right now the descriptions for some of them includes a line that says "If
> in doubt, say Y" but the config options don't have actually have a default
> value defined and they effectively default to N.
> 
> Cycling via savedefconfig on shawnguo/for-next also generates some
> reordering for some newly added options CONFIG_TOUCHSCREEN_MAX11801=y and
> CONFIG_HID_MULTITOUCH=y. Those were not included but it's strange that
> this happens. Maybe those options were inserted manually, or otherwise
> there is an annoying bug in kconfig?
> 
>  arch/arm/configs/imx_v6_v7_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index bb6fa56..bf1e7e3 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -55,6 +55,9 @@ CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
>  CONFIG_KEXEC=y
>  CONFIG_CPU_FREQ=y
>  CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
>  CONFIG_ARM_IMX6Q_CPUFREQ=y
>  CONFIG_CPU_IDLE=y
>  CONFIG_VFP=y
> --
> 2.7.4

RE: [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors

[A.S. Dong]

> -Original Message-
> From: Leonard Crestez [mailto:leonard.cres...@nxp.com]
> Sent: Tuesday, May 02, 2017 10:46 PM
> To: Shawn Guo
> Cc: Leonard Crestez; Sascha Hauer; Jagan Teki; Fabio Estevam; Dong Aisheng;
> linux-arm-ker...@lists.infradead.org; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] ARM: imx_v6_v7_defconfig: Enable cpufreq governors
> 
> Enable more common cpufreq governors in imx defconfig because this is very
> useful for testing. In particular you can't use cpufreq-set -f $FREQ
> without explicitly defining CONFIG_CPU_FREQ_GOV_USERSPACE=y.
> 
> Signed-off-by: Leonard Crestez 

Well, I think we do need this.
So:
Acked-by: Dong Aisheng 

Regards
Dong Aisheng

> 
> ---
> 
> It might make sense for all governors to be enabled by default from
> drivers/cpufreq/Kconfig and allow defconfigs to be shorter.
> Right now the descriptions for some of them includes a line that says "If
> in doubt, say Y" but the config options don't have actually have a default
> value defined and they effectively default to N.
> 
> Cycling via savedefconfig on shawnguo/for-next also generates some
> reordering for some newly added options CONFIG_TOUCHSCREEN_MAX11801=y and
> CONFIG_HID_MULTITOUCH=y. Those were not included but it's strange that
> this happens. Maybe those options were inserted manually, or otherwise
> there is an annoying bug in kconfig?
> 
>  arch/arm/configs/imx_v6_v7_defconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/configs/imx_v6_v7_defconfig
> b/arch/arm/configs/imx_v6_v7_defconfig
> index bb6fa56..bf1e7e3 100644
> --- a/arch/arm/configs/imx_v6_v7_defconfig
> +++ b/arch/arm/configs/imx_v6_v7_defconfig
> @@ -55,6 +55,9 @@ CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
>  CONFIG_KEXEC=y
>  CONFIG_CPU_FREQ=y
>  CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> +CONFIG_CPU_FREQ_GOV_POWERSAVE=y
> +CONFIG_CPU_FREQ_GOV_USERSPACE=y
> +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
>  CONFIG_ARM_IMX6Q_CPUFREQ=y
>  CONFIG_CPU_IDLE=y
>  CONFIG_VFP=y
> --
> 2.7.4

Re: [PATCH v6 0/4] Broadcom SBA RAID support

[Anup Patel]

Hi Vinod,

The Broadcom FlexRM patchset have been
merged in v4.11.

I think you now can take this patchset in next
merge window. Right??

Regards,
Anup

Re: [PATCH v6 0/4] Broadcom SBA RAID support

[Anup Patel]

Hi Vinod,

The Broadcom FlexRM patchset have been
merged in v4.11.

I think you now can take this patchset in next
merge window. Right??

Regards,
Anup

Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

[Nicholas A. Bellinger]

On Tue, 2017-05-02 at 21:06 -0500, Mike Christie wrote:
> On 05/02/2017 02:54 AM, lixi...@cmss.chinamobile.com wrote:
> > From: Xiubo Li 
> > 
> > For the "struct tcmu_cmd_entry" in cmd area, the minimum size
> > will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And it could
> > fill about (sizeof(struct rsp) - sizeof(struct req)) /
> > sizeof(struct iovec) == 68 / 16 ~= 4 data regions(iov[4]) by
> > default.
> > 
> > For most tcmu_cmds, the data block indexes allocated from the
> > data area will be continuous. And for the continuous blocks they
> > will be merged into the same region using only one iovec. For
> > the current code, it will always allocates the same number of
> > iovecs with blocks for each tcmu_cmd, and it will wastes much
> > memories.
> > 
> > For example, when the block size is 4K and the DATA_OUT buffer
> > size is 64K, and the regions needed is less than 5(on my
> > environment is almost 99.7%). The current code will allocate
> > about 16 iovecs, and there will be (16 - 4) * sizeof(struct
> > iovec) = 192 Bytes cmd area memories wasted.
> > 
> > Here adds two helpers to calculate the base size and full size
> > of the tcmu_cmd. And will recalculate them again when it make sure
> > how many iovs is needed before insert it to cmd area.
> > 
> > Signed-off-by: Xiubo Li 
> 
> Looks ok to me. Thanks.
> 
> Acked-by: Mike Christie 

Applied.  Thanks Xiubo + MNC.

Re: [PATCH] tcmu: Recalculate the tcmu_cmd size to save cmd area memories

[Nicholas A. Bellinger]

On Tue, 2017-05-02 at 21:06 -0500, Mike Christie wrote:
> On 05/02/2017 02:54 AM, lixi...@cmss.chinamobile.com wrote:
> > From: Xiubo Li 
> > 
> > For the "struct tcmu_cmd_entry" in cmd area, the minimum size
> > will be sizeof(struct tcmu_cmd_entry) == 112 Bytes. And it could
> > fill about (sizeof(struct rsp) - sizeof(struct req)) /
> > sizeof(struct iovec) == 68 / 16 ~= 4 data regions(iov[4]) by
> > default.
> > 
> > For most tcmu_cmds, the data block indexes allocated from the
> > data area will be continuous. And for the continuous blocks they
> > will be merged into the same region using only one iovec. For
> > the current code, it will always allocates the same number of
> > iovecs with blocks for each tcmu_cmd, and it will wastes much
> > memories.
> > 
> > For example, when the block size is 4K and the DATA_OUT buffer
> > size is 64K, and the regions needed is less than 5(on my
> > environment is almost 99.7%). The current code will allocate
> > about 16 iovecs, and there will be (16 - 4) * sizeof(struct
> > iovec) = 192 Bytes cmd area memories wasted.
> > 
> > Here adds two helpers to calculate the base size and full size
> > of the tcmu_cmd. And will recalculate them again when it make sure
> > how many iovs is needed before insert it to cmd area.
> > 
> > Signed-off-by: Xiubo Li 
> 
> Looks ok to me. Thanks.
> 
> Acked-by: Mike Christie 

Applied.  Thanks Xiubo + MNC.

Re: [PATCH] x86/intel_rdt: Fix two typos in Documentation

[Shen, Xiaochen]

Sorry, please ignore this patch.

The first typo in this patch has been already fixed by:
a9cad3d4f046 ("Documentation, x86: Intel Memory bandwidth allocation")

A new patch is submitted to address the other typo left over:
https://lkml.org/lkml/2017/5/2/595

Best regards
Xiaochen Shen


On 2017/4/7 1:09, Xiaochen Shen wrote:
> Both typos are in example 3.
>
> Because cache id 0 is the only cache id, the ";" is redundant in
> "# echo "L3:0=ffc00;" > p0/schemata".
>
> And "C0" in "# echo C0 > p0/cpus" is wrong because it specifies core
> 6-7 instead of wanted core 4-7.
>
> Correct the typos to avoid confusion.
>
> Signed-off-by: Xiaochen Shen 
> Signed-off-by: Fenghua Yu 
> ---
>  Documentation/x86/intel_rdt_ui.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/x86/intel_rdt_ui.txt 
> b/Documentation/x86/intel_rdt_ui.txt
> index 51cf6fa..cd752c1 100644
> --- a/Documentation/x86/intel_rdt_ui.txt
> +++ b/Documentation/x86/intel_rdt_ui.txt
> @@ -206,12 +206,12 @@ Next we make a resource group for our real time cores 
> and give
>  it access to the "top" 50% of the cache on socket 0.
>  
>  # mkdir p0
> -# echo "L3:0=ffc00;" > p0/schemata
> +# echo "L3:0=ffc00" > p0/schemata
>  
>  Finally we move core 4-7 over to the new group and make sure that the
>  kernel and the tasks running there get 50% of the cache.
>  
> -# echo C0 > p0/cpus
> +# echo F0 > p0/cpus
>  
>  4) Locking between applications
>  

Re: [PATCH] x86/intel_rdt: Fix two typos in Documentation

[Shen, Xiaochen]

Sorry, please ignore this patch.

The first typo in this patch has been already fixed by:
a9cad3d4f046 ("Documentation, x86: Intel Memory bandwidth allocation")

A new patch is submitted to address the other typo left over:
https://lkml.org/lkml/2017/5/2/595

Best regards
Xiaochen Shen


On 2017/4/7 1:09, Xiaochen Shen wrote:
> Both typos are in example 3.
>
> Because cache id 0 is the only cache id, the ";" is redundant in
> "# echo "L3:0=ffc00;" > p0/schemata".
>
> And "C0" in "# echo C0 > p0/cpus" is wrong because it specifies core
> 6-7 instead of wanted core 4-7.
>
> Correct the typos to avoid confusion.
>
> Signed-off-by: Xiaochen Shen 
> Signed-off-by: Fenghua Yu 
> ---
>  Documentation/x86/intel_rdt_ui.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/x86/intel_rdt_ui.txt 
> b/Documentation/x86/intel_rdt_ui.txt
> index 51cf6fa..cd752c1 100644
> --- a/Documentation/x86/intel_rdt_ui.txt
> +++ b/Documentation/x86/intel_rdt_ui.txt
> @@ -206,12 +206,12 @@ Next we make a resource group for our real time cores 
> and give
>  it access to the "top" 50% of the cache on socket 0.
>  
>  # mkdir p0
> -# echo "L3:0=ffc00;" > p0/schemata
> +# echo "L3:0=ffc00" > p0/schemata
>  
>  Finally we move core 4-7 over to the new group and make sure that the
>  kernel and the tasks running there get 50% of the cache.
>  
> -# echo C0 > p0/cpus
> +# echo F0 > p0/cpus
>  
>  4) Locking between applications
>  

[PATCH] staging: unisys: Solve sparse warning

[Marcos Paulo de Souza]

The following commit fixes the following sparse report:

drivers/staging//unisys/visorhba/visorhba_main.c:660:29: warning: cast to 
restricted __le64

by casting readq (which is unsigned long on x86) to u64, as expected by the 
seq_printf call.

Signed-off-by: Marcos Paulo de Souza 
---
 Just compiled tested on x86_64.

 drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 6997b16..46d33e6 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -657,7 +657,7 @@ static int info_debugfs_show(struct seq_file *seq, void *v)
seq_printf(seq, "phys_flags_addr = 0x%016llx\n",
   phys_flags_addr);
seq_printf(seq, "FeatureFlags = %llu\n",
-  (__le64)readq(devdata->flags_addr));
+  (u64)readq(devdata->flags_addr));
}
seq_printf(seq, "acquire_failed_cnt = %llu\n",
   devdata->acquire_failed_cnt);
-- 
2.9.3

[PATCH] staging: unisys: Solve sparse warning

[Marcos Paulo de Souza]

The following commit fixes the following sparse report:

drivers/staging//unisys/visorhba/visorhba_main.c:660:29: warning: cast to 
restricted __le64

by casting readq (which is unsigned long on x86) to u64, as expected by the 
seq_printf call.

Signed-off-by: Marcos Paulo de Souza 
---
 Just compiled tested on x86_64.

 drivers/staging/unisys/visorhba/visorhba_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c 
b/drivers/staging/unisys/visorhba/visorhba_main.c
index 6997b16..46d33e6 100644
--- a/drivers/staging/unisys/visorhba/visorhba_main.c
+++ b/drivers/staging/unisys/visorhba/visorhba_main.c
@@ -657,7 +657,7 @@ static int info_debugfs_show(struct seq_file *seq, void *v)
seq_printf(seq, "phys_flags_addr = 0x%016llx\n",
   phys_flags_addr);
seq_printf(seq, "FeatureFlags = %llu\n",
-  (__le64)readq(devdata->flags_addr));
+  (u64)readq(devdata->flags_addr));
}
seq_printf(seq, "acquire_failed_cnt = %llu\n",
   devdata->acquire_failed_cnt);
-- 
2.9.3

Re: [PATCH 6/15] dt-bindings: display: sun4i: Add HDMI display bindings

[Chen-Yu Tsai]

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
 wrote:
> One of the possible output of the display pipeline, on the SoCs that have
> it, is the HDMI controller.
>
> Add a binding for it.
>
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 21 +++-
>  1 file changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index b82c00449468..4b280672658e 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -4,6 +4,27 @@ Allwinner A10 Display Pipeline
>  The Allwinner A10 Display pipeline is composed of several components
>  that are going to be documented below:
>
> +HDMI Encoder
> +
> +
> +The HDMI Encoder supports the HDMI video and audio outputs, and does
> +CEC. It is one end of the pipeline.
> +
> +Required properties:
> +  - compatible: value must be one of:
> +* allwinner,sun5i-a10s-hdmi
> +  - reg: base address and size of memory-mapped region
> +  - clocks: phandles to the clocks feeding the HDMI encoder
> +* ahb: the HDMI interface clock
> +* mod: the HDMI module clock
> +* pll-0: the first video PLL
> +* pll-1: the second video PLL
> +  - clock-names: the clock names mentioned above

The audio part needs a DMA handle. May we add this from day one?

Thanks
ChenYu

> +
> +  - ports: A ports node with endpoint definitions as defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +first port should be the input endpoint.
> +
>  TV Encoder
>  --
>
> --
> git-series 0.8.11

Re: [PATCH 6/15] dt-bindings: display: sun4i: Add HDMI display bindings

[Chen-Yu Tsai]

On Tue, Mar 7, 2017 at 4:56 PM, Maxime Ripard
 wrote:
> One of the possible output of the display pipeline, on the SoCs that have
> it, is the HDMI controller.
>
> Add a binding for it.
>
> Signed-off-by: Maxime Ripard 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 21 +++-
>  1 file changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt 
> b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> index b82c00449468..4b280672658e 100644
> --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> @@ -4,6 +4,27 @@ Allwinner A10 Display Pipeline
>  The Allwinner A10 Display pipeline is composed of several components
>  that are going to be documented below:
>
> +HDMI Encoder
> +
> +
> +The HDMI Encoder supports the HDMI video and audio outputs, and does
> +CEC. It is one end of the pipeline.
> +
> +Required properties:
> +  - compatible: value must be one of:
> +* allwinner,sun5i-a10s-hdmi
> +  - reg: base address and size of memory-mapped region
> +  - clocks: phandles to the clocks feeding the HDMI encoder
> +* ahb: the HDMI interface clock
> +* mod: the HDMI module clock
> +* pll-0: the first video PLL
> +* pll-1: the second video PLL
> +  - clock-names: the clock names mentioned above

The audio part needs a DMA handle. May we add this from day one?

Thanks
ChenYu

> +
> +  - ports: A ports node with endpoint definitions as defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt. The
> +first port should be the input endpoint.
> +
>  TV Encoder
>  --
>
> --
> git-series 0.8.11

Re: [PATCH 03/13 V2] blk: make the bioset rescue_workqueue optional.

[Ming Lei]

On Wed, May 3, 2017 at 6:34 AM, NeilBrown  wrote:
> From 09017acf74ec4df674b78ca66f0924187f10d8a4 Mon Sep 17 00:00:00 2001
> From: NeilBrown 
> Date: Fri, 10 Mar 2017 13:59:50 +1100
> Subject: [PATCH] blk: make the bioset rescue_workqueue optional.
>
> This patch converts bioset_create() to not create a workqueue by
> default, so alloctions will never trigger punt_bios_to_rescuer().  It
> also introduces a new flag BIOSET_NEED_RESCUER() which tells
> bioset_create() to preserve the old behavior.
>
> All callers of bioset_create() that are inside block device drivers,
> are given the BIOSET_NEED_RESCUER().
>
> biosets used by filesystems or other top-level users do not
> need rescuing as the bio can never be queued behind other
> bios.  This includes fs_bio_set, blkdev_dio_pool,
> btrfs_bioset, xfs_ioend_bioset, and one allocated by
> target_core_iblock.c.
>
> biosets used by md/raid do not need rescuing as
> their usage was recently audited and revised to never
> risk deadlock.
>
> It is hoped that most, if not all, of the remaining biosets
> can end up being the non-rescued version.
>
> Reviewed-by: Christoph Hellwig 
> Credit-to: Ming Lei  (minor fixes)
> Signed-off-by: NeilBrown 

Reviewed-by: Ming Lei 


Thanks,
Ming

Re: [PATCH 03/13 V2] blk: make the bioset rescue_workqueue optional.

[Ming Lei]

On Wed, May 3, 2017 at 6:34 AM, NeilBrown  wrote:
> From 09017acf74ec4df674b78ca66f0924187f10d8a4 Mon Sep 17 00:00:00 2001
> From: NeilBrown 
> Date: Fri, 10 Mar 2017 13:59:50 +1100
> Subject: [PATCH] blk: make the bioset rescue_workqueue optional.
>
> This patch converts bioset_create() to not create a workqueue by
> default, so alloctions will never trigger punt_bios_to_rescuer().  It
> also introduces a new flag BIOSET_NEED_RESCUER() which tells
> bioset_create() to preserve the old behavior.
>
> All callers of bioset_create() that are inside block device drivers,
> are given the BIOSET_NEED_RESCUER().
>
> biosets used by filesystems or other top-level users do not
> need rescuing as the bio can never be queued behind other
> bios.  This includes fs_bio_set, blkdev_dio_pool,
> btrfs_bioset, xfs_ioend_bioset, and one allocated by
> target_core_iblock.c.
>
> biosets used by md/raid do not need rescuing as
> their usage was recently audited and revised to never
> risk deadlock.
>
> It is hoped that most, if not all, of the remaining biosets
> can end up being the non-rescued version.
>
> Reviewed-by: Christoph Hellwig 
> Credit-to: Ming Lei  (minor fixes)
> Signed-off-by: NeilBrown 

Reviewed-by: Ming Lei 


Thanks,
Ming

[PATCH] powerpc/powernv: Fix TCE kill on NVLink2

[Alistair Popple]

Commit 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on
NVLink2") forced all TCE kills to go via the OPAL call for
NVLink2. However the PHB3 implementation of TCE kill was still being
called directly from some functions which in some circumstances caused
a machine check.

This patch adds an equivalent IODA2 version of the function which uses
the correct invalidation method depending on PHB model and changes all
external callers to use it instead.

Fixes: 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2")
Signed-off-by: Alistair Popple 
Cc: sta...@vger.kernel.org
---
 arch/powerpc/platforms/powernv/npu-dma.c  |  8 
 arch/powerpc/platforms/powernv/pci-ioda.c | 10 +-
 arch/powerpc/platforms/powernv/pci.h  |  2 +-
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
b/arch/powerpc/platforms/powernv/npu-dma.c
index 4c88c3e..067defe 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -203,7 +203,7 @@ long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
pe_err(npe, "Failed to configure TCE table, err %lld\n", rc);
return rc;
}
-   pnv_pci_phb3_tce_invalidate_entire(phb, false);
+   pnv_pci_ioda2_tce_invalidate_entire(phb, false);
 
/* Add the table to the list so its TCE cache will get invalidated */
pnv_pci_link_table_and_group(phb->hose->node, num,
@@ -227,7 +227,7 @@ long pnv_npu_unset_window(struct pnv_ioda_pe *npe, int num)
pe_err(npe, "Unmapping failed, ret = %lld\n", rc);
return rc;
}
-   pnv_pci_phb3_tce_invalidate_entire(phb, false);
+   pnv_pci_ioda2_tce_invalidate_entire(phb, false);
 
pnv_pci_unlink_table_and_group(npe->table_group.tables[num],
>table_group);
@@ -293,7 +293,7 @@ static int pnv_npu_dma_set_bypass(struct pnv_ioda_pe *npe)
0 /* bypass base */, top);
 
if (rc == OPAL_SUCCESS)
-   pnv_pci_phb3_tce_invalidate_entire(phb, false);
+   pnv_pci_ioda2_tce_invalidate_entire(phb, false);
 
return rc;
 }
@@ -357,7 +357,7 @@ void pnv_npu_take_ownership(struct pnv_ioda_pe *npe)
pe_err(npe, "Failed to disable bypass, err %lld\n", rc);
return;
}
-   pnv_pci_phb3_tce_invalidate_entire(npe->phb, false);
+   pnv_pci_ioda2_tce_invalidate_entire(npe->phb, false);
 }
 
 struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct pnv_ioda_pe *npe)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 93ce3f9..dfbc94a 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1895,7 +1895,7 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
 #define PHB3_TCE_KILL_INVAL_PE PPC_BIT(1)
 #define PHB3_TCE_KILL_INVAL_ONEPPC_BIT(2)
 
-void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+static void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
 {
__be64 __iomem *invalidate = pnv_ioda_get_inval_reg(phb, rm);
const unsigned long val = PHB3_TCE_KILL_INVAL_ALL;
@@ -1991,6 +1991,14 @@ static void pnv_pci_ioda2_tce_invalidate(struct 
iommu_table *tbl,
}
 }
 
+void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+{
+   if (phb->model == PNV_PHB_MODEL_NPU || phb->model == PNV_PHB_MODEL_PHB3)
+   pnv_pci_phb3_tce_invalidate_entire(phb, rm);
+   else
+   opal_pci_tce_kill(phb->opal_id, OPAL_PCI_TCE_KILL, 0, 0, 0, 0);
+}
+
 static int pnv_ioda2_tce_build(struct iommu_table *tbl, long index,
long npages, unsigned long uaddr,
enum dma_data_direction direction,
diff --git a/arch/powerpc/platforms/powernv/pci.h 
b/arch/powerpc/platforms/powernv/pci.h
index 4eab713..18c8a2f 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -242,7 +242,7 @@ extern void pe_level_printk(const struct pnv_ioda_pe *pe, 
const char *level,
 
 /* Nvlink functions */
 extern void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev, bool bypass);
-extern void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm);
+extern void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm);
 extern struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct pnv_ioda_pe *npe);
 extern long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
struct iommu_table *tbl);
-- 
2.1.4

[PATCH] powerpc/powernv: Fix TCE kill on NVLink2

[Alistair Popple]

Commit 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on
NVLink2") forced all TCE kills to go via the OPAL call for
NVLink2. However the PHB3 implementation of TCE kill was still being
called directly from some functions which in some circumstances caused
a machine check.

This patch adds an equivalent IODA2 version of the function which uses
the correct invalidation method depending on PHB model and changes all
external callers to use it instead.

Fixes: 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2")
Signed-off-by: Alistair Popple 
Cc: sta...@vger.kernel.org
---
 arch/powerpc/platforms/powernv/npu-dma.c  |  8 
 arch/powerpc/platforms/powernv/pci-ioda.c | 10 +-
 arch/powerpc/platforms/powernv/pci.h  |  2 +-
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/npu-dma.c 
b/arch/powerpc/platforms/powernv/npu-dma.c
index 4c88c3e..067defe 100644
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -203,7 +203,7 @@ long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
pe_err(npe, "Failed to configure TCE table, err %lld\n", rc);
return rc;
}
-   pnv_pci_phb3_tce_invalidate_entire(phb, false);
+   pnv_pci_ioda2_tce_invalidate_entire(phb, false);
 
/* Add the table to the list so its TCE cache will get invalidated */
pnv_pci_link_table_and_group(phb->hose->node, num,
@@ -227,7 +227,7 @@ long pnv_npu_unset_window(struct pnv_ioda_pe *npe, int num)
pe_err(npe, "Unmapping failed, ret = %lld\n", rc);
return rc;
}
-   pnv_pci_phb3_tce_invalidate_entire(phb, false);
+   pnv_pci_ioda2_tce_invalidate_entire(phb, false);
 
pnv_pci_unlink_table_and_group(npe->table_group.tables[num],
>table_group);
@@ -293,7 +293,7 @@ static int pnv_npu_dma_set_bypass(struct pnv_ioda_pe *npe)
0 /* bypass base */, top);
 
if (rc == OPAL_SUCCESS)
-   pnv_pci_phb3_tce_invalidate_entire(phb, false);
+   pnv_pci_ioda2_tce_invalidate_entire(phb, false);
 
return rc;
 }
@@ -357,7 +357,7 @@ void pnv_npu_take_ownership(struct pnv_ioda_pe *npe)
pe_err(npe, "Failed to disable bypass, err %lld\n", rc);
return;
}
-   pnv_pci_phb3_tce_invalidate_entire(npe->phb, false);
+   pnv_pci_ioda2_tce_invalidate_entire(npe->phb, false);
 }
 
 struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct pnv_ioda_pe *npe)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 93ce3f9..dfbc94a 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1895,7 +1895,7 @@ static struct iommu_table_ops pnv_ioda1_iommu_ops = {
 #define PHB3_TCE_KILL_INVAL_PE PPC_BIT(1)
 #define PHB3_TCE_KILL_INVAL_ONEPPC_BIT(2)
 
-void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+static void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
 {
__be64 __iomem *invalidate = pnv_ioda_get_inval_reg(phb, rm);
const unsigned long val = PHB3_TCE_KILL_INVAL_ALL;
@@ -1991,6 +1991,14 @@ static void pnv_pci_ioda2_tce_invalidate(struct 
iommu_table *tbl,
}
 }
 
+void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+{
+   if (phb->model == PNV_PHB_MODEL_NPU || phb->model == PNV_PHB_MODEL_PHB3)
+   pnv_pci_phb3_tce_invalidate_entire(phb, rm);
+   else
+   opal_pci_tce_kill(phb->opal_id, OPAL_PCI_TCE_KILL, 0, 0, 0, 0);
+}
+
 static int pnv_ioda2_tce_build(struct iommu_table *tbl, long index,
long npages, unsigned long uaddr,
enum dma_data_direction direction,
diff --git a/arch/powerpc/platforms/powernv/pci.h 
b/arch/powerpc/platforms/powernv/pci.h
index 4eab713..18c8a2f 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -242,7 +242,7 @@ extern void pe_level_printk(const struct pnv_ioda_pe *pe, 
const char *level,
 
 /* Nvlink functions */
 extern void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev, bool bypass);
-extern void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm);
+extern void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm);
 extern struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct pnv_ioda_pe *npe);
 extern long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
struct iommu_table *tbl);
-- 
2.1.4

[PATCH v2 1/8] dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU

[Chen-Yu Tsai]

The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.

Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt 
b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
index e9c5a1d9834a..34b2a9249a94 100644
--- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
@@ -6,6 +6,7 @@ Required properties :
- "allwinner,sun6i-a31-ccu"
- "allwinner,sun8i-a23-ccu"
- "allwinner,sun8i-a33-ccu"
+   - "allwinner,sun8i-a83t-ccu"
- "allwinner,sun8i-h3-ccu"
- "allwinner,sun8i-h3-r-ccu"
- "allwinner,sun8i-v3s-ccu"
@@ -18,6 +19,7 @@ Required properties :
 - clocks: phandle to the oscillators feeding the CCU. Two are needed:
   - "hosc": the high frequency oscillator (usually at 24MHz)
   - "losc": the low frequency oscillator (usually at 32kHz)
+   On the A83T, this is the internal 16MHz oscillator divided by 512
 - clock-names: Must contain the clock names described just above
 - #clock-cells : must contain 1
 - #reset-cells : must contain 1
-- 
2.11.0

[PATCH v2 6/8] ARM: sun8i: a83t: Add CCU device nodes

[Chen-Yu Tsai]

Now that we have support for the A83T CCU, add a device node for it,
and replace any existing placeholder clock phandles with the correct
ones.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c0a1e4f74b89..c9a5d07b2ada 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -162,13 +162,23 @@
#size-cells = <1>;
ranges;
 
+   ccu: clock@1c2 {
+   compatible = "allwinner,sun8i-a83t-ccu";
+   reg = <0x01c2 0x400>;
+   clocks = <>, <>;
+   clock-names = "hosc", "losc";
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
pio: pinctrl@1c20800 {
compatible = "allwinner,sun8i-a83t-pinctrl";
interrupts = ,
 ,
 ;
reg = <0x01c20800 0x400>;
-   clocks = <>;
+   clocks = < 45>, <>, <>;
+   clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
#interrupt-cells = <3>;
@@ -214,7 +224,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = <>;
+   clocks = < 53>;
+   resets = < 40>;
status = "disabled";
};
 
-- 
2.11.0

[PATCH v2 6/8] ARM: sun8i: a83t: Add CCU device nodes

[Chen-Yu Tsai]

Now that we have support for the A83T CCU, add a device node for it,
and replace any existing placeholder clock phandles with the correct
ones.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c0a1e4f74b89..c9a5d07b2ada 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -162,13 +162,23 @@
#size-cells = <1>;
ranges;
 
+   ccu: clock@1c2 {
+   compatible = "allwinner,sun8i-a83t-ccu";
+   reg = <0x01c2 0x400>;
+   clocks = <>, <>;
+   clock-names = "hosc", "losc";
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
pio: pinctrl@1c20800 {
compatible = "allwinner,sun8i-a83t-pinctrl";
interrupts = ,
 ,
 ;
reg = <0x01c20800 0x400>;
-   clocks = <>;
+   clocks = < 45>, <>, <>;
+   clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
#interrupt-cells = <3>;
@@ -214,7 +224,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = <>;
+   clocks = < 53>;
+   resets = < 40>;
status = "disabled";
};
 
-- 
2.11.0

[PATCH v2 1/8] dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU

[Chen-Yu Tsai]

The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.

Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt 
b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
index e9c5a1d9834a..34b2a9249a94 100644
--- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
@@ -6,6 +6,7 @@ Required properties :
- "allwinner,sun6i-a31-ccu"
- "allwinner,sun8i-a23-ccu"
- "allwinner,sun8i-a33-ccu"
+   - "allwinner,sun8i-a83t-ccu"
- "allwinner,sun8i-h3-ccu"
- "allwinner,sun8i-h3-r-ccu"
- "allwinner,sun8i-v3s-ccu"
@@ -18,6 +19,7 @@ Required properties :
 - clocks: phandle to the oscillators feeding the CCU. Two are needed:
   - "hosc": the high frequency oscillator (usually at 24MHz)
   - "losc": the low frequency oscillator (usually at 32kHz)
+   On the A83T, this is the internal 16MHz oscillator divided by 512
 - clock-names: Must contain the clock names described just above
 - #clock-cells : must contain 1
 - #reset-cells : must contain 1
-- 
2.11.0

Re: [PATCH 0/6] mailbox: arm_mhu: add support for subchannels

[Jassi Brar]

Hi Sudeep,

On Tue, May 2, 2017 at 7:25 PM, Sudeep Holla  wrote:
> Hi Jassi,
>
> This series adds subchannel support to ARM MHU mailbox controller
> driver. Since SCPI never used second slot, we were able to use the
> existing driver as is. However, that's changing soon and the new
> SCMI protocol under development needs subchannel support. If you
> recall when you initially added this driver, I was pushing for some
> of these changes like threaded irq. This patch series adds support
> for the subchannels on ARM MHU controllers.
>
  There are really no "sub-channels" in the ARM MHU controller. There
are exactly three channels that work on 32bit registers. The SET/CLEAR
registers are there to prevent races between local and remote
firmware, and not to emulate virtual channels operating on single
bits. Please remember all 32-bits work together to generate one
signal.

 You arrived at the "sub-channel" idea only because your protocol uses
1-bit messages. This patchset seems rather regressive - reduce from
2^32 possible signals to mere 32, by bloating the MHU driver.

 If it's difficult to see how your protocol can be implemented over
existing controller driver, please let me know.

Thanks.

Re: [PATCH 0/6] mailbox: arm_mhu: add support for subchannels

[Jassi Brar]

Hi Sudeep,

On Tue, May 2, 2017 at 7:25 PM, Sudeep Holla  wrote:
> Hi Jassi,
>
> This series adds subchannel support to ARM MHU mailbox controller
> driver. Since SCPI never used second slot, we were able to use the
> existing driver as is. However, that's changing soon and the new
> SCMI protocol under development needs subchannel support. If you
> recall when you initially added this driver, I was pushing for some
> of these changes like threaded irq. This patch series adds support
> for the subchannels on ARM MHU controllers.
>
  There are really no "sub-channels" in the ARM MHU controller. There
are exactly three channels that work on 32bit registers. The SET/CLEAR
registers are there to prevent races between local and remote
firmware, and not to emulate virtual channels operating on single
bits. Please remember all 32-bits work together to generate one
signal.

 You arrived at the "sub-channel" idea only because your protocol uses
1-bit messages. This patchset seems rather regressive - reduce from
2^32 possible signals to mere 32, by bloating the MHU driver.

 If it's difficult to see how your protocol can be implemented over
existing controller driver, please let me know.

Thanks.

[PATCH v2 8/8] ARM: sun8i: a83t: Switch to CCU device tree binding macros

[Chen-Yu Tsai]

Now that the CCU device tree binding headers have been merged, we can
use the properly named macros in the device tree, instead of raw
numbers.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e12dd7170b8f..050d3e347740 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -44,6 +44,9 @@
 
 #include 
 
+#include 
+#include 
+
 / {
interrupt-parent = <>;
#address-cells = <1>;
@@ -178,7 +181,7 @@
 ,
 ;
reg = <0x01c20800 0x400>;
-   clocks = < 45>, <>, <>;
+   clocks = < CLK_BUS_PIO>, <>, <>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
@@ -225,8 +228,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = < 53>;
-   resets = < 40>;
+   clocks = < CLK_BUS_UART0>;
+   resets = < RST_BUS_UART0>;
status = "disabled";
};
 
-- 
2.11.0

[PATCH v2 7/8] ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator

[Chen-Yu Tsai]

The datasheets for Allwinner SoCs set strict requirements on the
stability of the external crystal oscillators. Add the accuracy
for the main 24MHz oscillator to the device tree.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c9a5d07b2ada..e12dd7170b8f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -126,6 +126,7 @@
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <2400>;
+   clock-accuracy = <5>;
clock-output-names = "osc24M";
};
 
-- 
2.11.0

[PATCH v2 5/8] clk: sunxi-ng: Add driver for A83T CCU

[Chen-Yu Tsai]

The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.

Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.

Also, the MMC2 module clock supports switching to a "new timing" mode.
This mode divides the clock output by half, and disables the CCU based
clock delays. The MMC controller must be configure to the same mode,
and then use its internal clock delays.

This driver does not support runtime switching of the timing modes.
Instead, the new timing mode is enforced at probe time. Consumers can
check which mode is active by trying to get the current phase delay
of the MMC2 phase clocks, which will return -ENOTSUPP if the new
timing mode is active.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/Kconfig   |  10 +
 drivers/clk/sunxi-ng/Makefile  |   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c  | 911 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h  |  64 ++
 include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 +
 include/dt-bindings/reset/sun8i-a83t-ccu.h |  98 
 6 files changed, 1224 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h
 create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 64088e599404..8bee22563909 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -116,6 +116,16 @@ config SUN8I_A33_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
 
+config SUN8I_A83T_CCU
+   bool "Support for the Allwinner A83T CCU"
+   select SUNXI_CCU_DIV
+   select SUNXI_CCU_GATE
+   select SUNXI_CCU_NKMP
+   select SUNXI_CCU_NM
+   select SUNXI_CCU_MP
+   select SUNXI_CCU_PHASE
+   default MACH_SUN8I
+
 config SUN8I_H3_CCU
bool "Support for the Allwinner H3 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0ec02fe14c50..78028c8f5fa9 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SUN5I_CCU)   += ccu-sun5i.o
 obj-$(CONFIG_SUN6I_A31_CCU)+= ccu-sun6i-a31.o
 obj-$(CONFIG_SUN8I_A23_CCU)+= ccu-sun8i-a23.o
 obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
+obj-$(CONFIG_SUN8I_A83T_CCU)   += ccu-sun8i-a83t.o
 obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
 obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
 obj-$(CONFIG_SUN8I_R_CCU)  += ccu-sun8i-r.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
new file mode 100644
index ..e32ef2cac568
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -0,0 +1,911 @@
+/*
+ * Copyright (c) 2017 Chen-Yu Tsai. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sun8i-a83t.h"
+
+#define CCU_SUN8I_A83T_LOCK_REG0x208
+
+static struct clk_div_table pll_cpux_p_div_table[] = {
+   { .val = 0, .div = 1 },
+   { .val = 1, .div = 4 },
+   { /* Sentinel */ },
+};
+
+/*
+ * The CPU PLLs are actually NP clocks, but P is /1 or /4, so here we
+ * use the NM clocks with a divider table for M.
+ */
+static struct ccu_nm pll_c0cpux_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(0),
+   .n  = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(8, 8, 0, 12, 0),
+   .m  = _SUNXI_CCU_DIV_TABLE(16, 1, pll_cpux_p_div_table),
+   .common = {
+   .reg= 0x000,
+   .lock_reg   = CCU_SUN8I_A83T_LOCK_REG,
+   .features   = CCU_FEATURE_LOCK_REG,
+   .hw.init= CLK_HW_INIT("pll-c0cpux", "osc24M",
+ _nm_ops, CLK_SET_RATE_UNGATE),
+   },
+};
+
+static struct ccu_nm pll_c1cpux_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(1),
+   .n   

[PATCH v2 8/8] ARM: sun8i: a83t: Switch to CCU device tree binding macros

[Chen-Yu Tsai]

Now that the CCU device tree binding headers have been merged, we can
use the properly named macros in the device tree, instead of raw
numbers.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index e12dd7170b8f..050d3e347740 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -44,6 +44,9 @@
 
 #include 
 
+#include 
+#include 
+
 / {
interrupt-parent = <>;
#address-cells = <1>;
@@ -178,7 +181,7 @@
 ,
 ;
reg = <0x01c20800 0x400>;
-   clocks = < 45>, <>, <>;
+   clocks = < CLK_BUS_PIO>, <>, <>;
clock-names = "apb", "hosc", "losc";
gpio-controller;
interrupt-controller;
@@ -225,8 +228,8 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clocks = < 53>;
-   resets = < 40>;
+   clocks = < CLK_BUS_UART0>;
+   resets = < RST_BUS_UART0>;
status = "disabled";
};
 
-- 
2.11.0

[PATCH v2 7/8] ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator

[Chen-Yu Tsai]

The datasheets for Allwinner SoCs set strict requirements on the
stability of the external crystal oscillators. Add the accuracy
for the main 24MHz oscillator to the device tree.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a83t.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi 
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index c9a5d07b2ada..e12dd7170b8f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -126,6 +126,7 @@
#clock-cells = <0>;
compatible = "fixed-clock";
clock-frequency = <2400>;
+   clock-accuracy = <5>;
clock-output-names = "osc24M";
};
 
-- 
2.11.0

[PATCH v2 5/8] clk: sunxi-ng: Add driver for A83T CCU

[Chen-Yu Tsai]

The A83T clock control unit is a hybrid of some new style clock designs
from the A80, and old style layout from the other Allwinner SoCs.

Like the A80, the SoC does not have a low speed 32.768 kHz oscillator.
Unlike the A80, there is no clock input either. The only low speed clock
available is the internal oscillator which runs at around 16 MHz,
divided by 512, yielding a low speed clock around 31.250 kHz.

Also, the MMC2 module clock supports switching to a "new timing" mode.
This mode divides the clock output by half, and disables the CCU based
clock delays. The MMC controller must be configure to the same mode,
and then use its internal clock delays.

This driver does not support runtime switching of the timing modes.
Instead, the new timing mode is enforced at probe time. Consumers can
check which mode is active by trying to get the current phase delay
of the MMC2 phase clocks, which will return -ENOTSUPP if the new
timing mode is active.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/Kconfig   |  10 +
 drivers/clk/sunxi-ng/Makefile  |   1 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c  | 911 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h  |  64 ++
 include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 +
 include/dt-bindings/reset/sun8i-a83t-ccu.h |  98 
 6 files changed, 1224 insertions(+)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h
 create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h

diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index 64088e599404..8bee22563909 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -116,6 +116,16 @@ config SUN8I_A33_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
 
+config SUN8I_A83T_CCU
+   bool "Support for the Allwinner A83T CCU"
+   select SUNXI_CCU_DIV
+   select SUNXI_CCU_GATE
+   select SUNXI_CCU_NKMP
+   select SUNXI_CCU_NM
+   select SUNXI_CCU_MP
+   select SUNXI_CCU_PHASE
+   default MACH_SUN8I
+
 config SUN8I_H3_CCU
bool "Support for the Allwinner H3 CCU"
select SUNXI_CCU_DIV
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 0ec02fe14c50..78028c8f5fa9 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_SUN5I_CCU)   += ccu-sun5i.o
 obj-$(CONFIG_SUN6I_A31_CCU)+= ccu-sun6i-a31.o
 obj-$(CONFIG_SUN8I_A23_CCU)+= ccu-sun8i-a23.o
 obj-$(CONFIG_SUN8I_A33_CCU)+= ccu-sun8i-a33.o
+obj-$(CONFIG_SUN8I_A83T_CCU)   += ccu-sun8i-a83t.o
 obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
 obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
 obj-$(CONFIG_SUN8I_R_CCU)  += ccu-sun8i-r.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
new file mode 100644
index ..e32ef2cac568
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
@@ -0,0 +1,911 @@
+/*
+ * Copyright (c) 2017 Chen-Yu Tsai. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+#include "ccu_phase.h"
+
+#include "ccu-sun8i-a83t.h"
+
+#define CCU_SUN8I_A83T_LOCK_REG0x208
+
+static struct clk_div_table pll_cpux_p_div_table[] = {
+   { .val = 0, .div = 1 },
+   { .val = 1, .div = 4 },
+   { /* Sentinel */ },
+};
+
+/*
+ * The CPU PLLs are actually NP clocks, but P is /1 or /4, so here we
+ * use the NM clocks with a divider table for M.
+ */
+static struct ccu_nm pll_c0cpux_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(0),
+   .n  = _SUNXI_CCU_MULT_OFFSET_MIN_MAX(8, 8, 0, 12, 0),
+   .m  = _SUNXI_CCU_DIV_TABLE(16, 1, pll_cpux_p_div_table),
+   .common = {
+   .reg= 0x000,
+   .lock_reg   = CCU_SUN8I_A83T_LOCK_REG,
+   .features   = CCU_FEATURE_LOCK_REG,
+   .hw.init= CLK_HW_INIT("pll-c0cpux", "osc24M",
+ _nm_ops, CLK_SET_RATE_UNGATE),
+   },
+};
+
+static struct ccu_nm pll_c1cpux_clk = {
+   .enable = BIT(31),
+   .lock   = BIT(1),
+   .n  = 

[PATCH v2 4/8] clk: sunxi-ng: Support multiple variable pre-dividers

[Chen-Yu Tsai]

On the A83T, the AHB1 clock has a shared pre-divider on the two
PLL-PERIPH clock parents. To support such instances of shared
pre-dividers, this patch extends the mux clock type to support
multiple variable pre-dividers.

As the pre-dividers are only used to calculate the rate, but
do not participate in the factorization process, this is fairly
straightforward.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 +-
 drivers/clk/sunxi-ng/ccu-sun6i-a31.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a23.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a33.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c   | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-r.c| 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-v3s.c  | 10 +-
 drivers/clk/sunxi-ng/ccu_mux.c| 15 ---
 drivers/clk/sunxi-ng/ccu_mux.h| 13 -
 9 files changed, 51 insertions(+), 47 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index f54114c607df..2bb4cabf802f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -211,6 +211,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi", "pll-periph0" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -218,11 +221,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c 
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index 89e68d29bf45..bc9f2ca19233 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -195,6 +195,9 @@ static SUNXI_CCU_DIV_TABLE(axi_clk, "axi", "cpu",
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi", "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -203,11 +206,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index 5c6d37bdf247..8a753ed0426d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -169,6 +169,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -176,11 +179,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 8d38e6510e29..10b38dc46f75 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -180,6 +180,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -187,11 +190,8 @@ static struct ccu_div ahb1_clk = {
 

[PATCH v2 4/8] clk: sunxi-ng: Support multiple variable pre-dividers

[Chen-Yu Tsai]

On the A83T, the AHB1 clock has a shared pre-divider on the two
PLL-PERIPH clock parents. To support such instances of shared
pre-dividers, this patch extends the mux clock type to support
multiple variable pre-dividers.

As the pre-dividers are only used to calculate the rate, but
do not participate in the factorization process, this is fairly
straightforward.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 10 +-
 drivers/clk/sunxi-ng/ccu-sun6i-a31.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a23.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a33.c  | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c   | 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-r.c| 10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-v3s.c  | 10 +-
 drivers/clk/sunxi-ng/ccu_mux.c| 15 ---
 drivers/clk/sunxi-ng/ccu_mux.h| 13 -
 9 files changed, 51 insertions(+), 47 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index f54114c607df..2bb4cabf802f 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -211,6 +211,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi", "pll-periph0" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -218,11 +221,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c 
b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
index 89e68d29bf45..bc9f2ca19233 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -195,6 +195,9 @@ static SUNXI_CCU_DIV_TABLE(axi_clk, "axi", "cpu",
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi", "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
@@ -203,11 +206,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index 5c6d37bdf247..8a753ed0426d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -169,6 +169,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -176,11 +179,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 12,
.width  = 2,
 
-   .variable_prediv= {
-   .index  = 3,
-   .shift  = 6,
-   .width  = 2,
-   },
+   .var_predivs= ahb1_predivs,
+   .n_var_predivs  = ARRAY_SIZE(ahb1_predivs),
},
 
.common = {
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 8d38e6510e29..10b38dc46f75 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -180,6 +180,9 @@ static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
 
 static const char * const ahb1_parents[] = { "osc32k", "osc24M",
 "axi" , "pll-periph" };
+static const struct ccu_mux_var_prediv ahb1_predivs[] = {
+   { .index = 3, .shift = 6, .width = 2 },
+};
 static struct ccu_div ahb1_clk = {
.div= _SUNXI_CCU_DIV_FLAGS(4, 2, CLK_DIVIDER_POWER_OF_TWO),
 
@@ -187,11 +190,8 @@ static struct ccu_div ahb1_clk = {
.shift  = 

[PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes

[Chen-Yu Tsai]

The MMC clocks on newer SoCs, such as the A83T and H3, support the
"new timing mode". Under this mode, the output of the clock is divided
by 2, and the clock delays no longer apply.

Due to how the clock tree is modeled and setup, we need to model
this function in two places, the master mmc clock and the two
child phase clocks. In the mmc clock, we can easily model the
mode bit as an extra variable post-divider. In the phase clocks,
we check the bit and return -ENOTSUPP if the bit is set, signaling
that the phase clocks are not to be used.

This patch introduces a class of phase clocks that checks the
timing mode bit.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu_phase.c | 47 
 drivers/clk/sunxi-ng/ccu_phase.h | 16 ++
 2 files changed, 63 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_phase.c b/drivers/clk/sunxi-ng/ccu_phase.c
index 400c58ad72fd..e6ff7551c855 100644
--- a/drivers/clk/sunxi-ng/ccu_phase.c
+++ b/drivers/clk/sunxi-ng/ccu_phase.c
@@ -8,6 +8,7 @@
  * the License, or (at your option) any later version.
  */
 
+#include 
 #include 
 #include 
 
@@ -124,3 +125,49 @@ const struct clk_ops ccu_phase_ops = {
.get_phase  = ccu_phase_get_phase,
.set_phase  = ccu_phase_set_phase,
 };
+
+/*
+ * The MMC clocks on newer SoCs support the "new timing mode". Under
+ * this mode, the output of the clock is divided by 2, and the clock
+ * delays no longer apply.
+ *
+ * Due to how the clock tree is modeled and setup, we need to model
+ * this function in two places, the master mmc clock and the two
+ * child phase clocks. In the mmc clock, we can easily model the
+ * mode bit as an extra variable post-divider. In the phase clocks,
+ * we check the bit and return -ENOTSUPP if the bit is set, signaling
+ * that the phase clocks are not to be used.
+ *
+ * We do not support runtime configuration of the modes. Instead a
+ * mode is enforced at CCU probe time.
+ */
+#define CCU_MMC_NEW_TIMING_MODEBIT(30)
+
+static int ccu_phase_mmc_new_timing_get_phase(struct clk_hw *hw)
+{
+   struct ccu_phase *phase = hw_to_ccu_phase(hw);
+   u32 reg;
+
+   reg = readl(phase->common.base + phase->common.reg);
+   if (reg & CCU_MMC_NEW_TIMING_MODE)
+   return -ENOTSUPP;
+
+   return ccu_phase_get_phase(hw);
+}
+
+static int ccu_phase_mmc_new_timing_set_phase(struct clk_hw *hw, int degrees)
+{
+   struct ccu_phase *phase = hw_to_ccu_phase(hw);
+   u32 reg;
+
+   reg = readl(phase->common.base + phase->common.reg);
+   if (reg & CCU_MMC_NEW_TIMING_MODE)
+   return -ENOTSUPP;
+
+   return ccu_phase_set_phase(hw, degrees);
+}
+
+const struct clk_ops ccu_phase_mmc_new_timing_ops = {
+   .get_phase  = ccu_phase_mmc_new_timing_get_phase,
+   .set_phase  = ccu_phase_mmc_new_timing_set_phase,
+};
diff --git a/drivers/clk/sunxi-ng/ccu_phase.h b/drivers/clk/sunxi-ng/ccu_phase.h
index 75a091a4c565..c514d1798cdd 100644
--- a/drivers/clk/sunxi-ng/ccu_phase.h
+++ b/drivers/clk/sunxi-ng/ccu_phase.h
@@ -38,6 +38,20 @@ struct ccu_phase {
}   \
}
 
+#define SUNXI_CCU_PHASE_MMC_NEW_TIMING(_struct, _name, _parent, _reg,  \
+  _shift, _width, _flags)  \
+   struct ccu_phase _struct = {\
+   .shift  = _shift,   \
+   .width  = _width,   \
+   .common = { \
+   .reg= _reg, \
+   .hw.init= CLK_HW_INIT(_name,\
+ _parent,  \
+ 
_phase_mmc_new_timing_ops, \
+ _flags),  \
+   }   \
+   }
+
 static inline struct ccu_phase *hw_to_ccu_phase(struct clk_hw *hw)
 {
struct ccu_common *common = hw_to_ccu_common(hw);
@@ -47,4 +61,6 @@ static inline struct ccu_phase *hw_to_ccu_phase(struct clk_hw 
*hw)
 
 extern const struct clk_ops ccu_phase_ops;
 
+extern const struct clk_ops ccu_phase_mmc_new_timing_ops;
+
 #endif /* _CCU_PHASE_H_ */
-- 
2.11.0

[PATCH v2 3/8] clk: sunxi-ng: Add class of phase clocks supporting MMC new timing modes

[Chen-Yu Tsai]

The MMC clocks on newer SoCs, such as the A83T and H3, support the
"new timing mode". Under this mode, the output of the clock is divided
by 2, and the clock delays no longer apply.

Due to how the clock tree is modeled and setup, we need to model
this function in two places, the master mmc clock and the two
child phase clocks. In the mmc clock, we can easily model the
mode bit as an extra variable post-divider. In the phase clocks,
we check the bit and return -ENOTSUPP if the bit is set, signaling
that the phase clocks are not to be used.

This patch introduces a class of phase clocks that checks the
timing mode bit.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/sunxi-ng/ccu_phase.c | 47 
 drivers/clk/sunxi-ng/ccu_phase.h | 16 ++
 2 files changed, 63 insertions(+)

diff --git a/drivers/clk/sunxi-ng/ccu_phase.c b/drivers/clk/sunxi-ng/ccu_phase.c
index 400c58ad72fd..e6ff7551c855 100644
--- a/drivers/clk/sunxi-ng/ccu_phase.c
+++ b/drivers/clk/sunxi-ng/ccu_phase.c
@@ -8,6 +8,7 @@
  * the License, or (at your option) any later version.
  */
 
+#include 
 #include 
 #include 
 
@@ -124,3 +125,49 @@ const struct clk_ops ccu_phase_ops = {
.get_phase  = ccu_phase_get_phase,
.set_phase  = ccu_phase_set_phase,
 };
+
+/*
+ * The MMC clocks on newer SoCs support the "new timing mode". Under
+ * this mode, the output of the clock is divided by 2, and the clock
+ * delays no longer apply.
+ *
+ * Due to how the clock tree is modeled and setup, we need to model
+ * this function in two places, the master mmc clock and the two
+ * child phase clocks. In the mmc clock, we can easily model the
+ * mode bit as an extra variable post-divider. In the phase clocks,
+ * we check the bit and return -ENOTSUPP if the bit is set, signaling
+ * that the phase clocks are not to be used.
+ *
+ * We do not support runtime configuration of the modes. Instead a
+ * mode is enforced at CCU probe time.
+ */
+#define CCU_MMC_NEW_TIMING_MODEBIT(30)
+
+static int ccu_phase_mmc_new_timing_get_phase(struct clk_hw *hw)
+{
+   struct ccu_phase *phase = hw_to_ccu_phase(hw);
+   u32 reg;
+
+   reg = readl(phase->common.base + phase->common.reg);
+   if (reg & CCU_MMC_NEW_TIMING_MODE)
+   return -ENOTSUPP;
+
+   return ccu_phase_get_phase(hw);
+}
+
+static int ccu_phase_mmc_new_timing_set_phase(struct clk_hw *hw, int degrees)
+{
+   struct ccu_phase *phase = hw_to_ccu_phase(hw);
+   u32 reg;
+
+   reg = readl(phase->common.base + phase->common.reg);
+   if (reg & CCU_MMC_NEW_TIMING_MODE)
+   return -ENOTSUPP;
+
+   return ccu_phase_set_phase(hw, degrees);
+}
+
+const struct clk_ops ccu_phase_mmc_new_timing_ops = {
+   .get_phase  = ccu_phase_mmc_new_timing_get_phase,
+   .set_phase  = ccu_phase_mmc_new_timing_set_phase,
+};
diff --git a/drivers/clk/sunxi-ng/ccu_phase.h b/drivers/clk/sunxi-ng/ccu_phase.h
index 75a091a4c565..c514d1798cdd 100644
--- a/drivers/clk/sunxi-ng/ccu_phase.h
+++ b/drivers/clk/sunxi-ng/ccu_phase.h
@@ -38,6 +38,20 @@ struct ccu_phase {
}   \
}
 
+#define SUNXI_CCU_PHASE_MMC_NEW_TIMING(_struct, _name, _parent, _reg,  \
+  _shift, _width, _flags)  \
+   struct ccu_phase _struct = {\
+   .shift  = _shift,   \
+   .width  = _width,   \
+   .common = { \
+   .reg= _reg, \
+   .hw.init= CLK_HW_INIT(_name,\
+ _parent,  \
+ 
_phase_mmc_new_timing_ops, \
+ _flags),  \
+   }   \
+   }
+
 static inline struct ccu_phase *hw_to_ccu_phase(struct clk_hw *hw)
 {
struct ccu_common *common = hw_to_ccu_common(hw);
@@ -47,4 +61,6 @@ static inline struct ccu_phase *hw_to_ccu_phase(struct clk_hw 
*hw)
 
 extern const struct clk_ops ccu_phase_ops;
 
+extern const struct clk_ops ccu_phase_mmc_new_timing_ops;
+
 #endif /* _CCU_PHASE_H_ */
-- 
2.11.0

[PATCH v2 2/8] clk: Provide option to query hardware for clk phase

[Chen-Yu Tsai]

On some hardware, the clk phase is tied to the parent clk's
rate and some clk delay programmed into the hardware. As the
parent clk rate changes, so does the clk phase.

Add a clk flag specifying not to use the cached clk phase,
but always query the hardware for it.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/clk/clk.c| 6 +-
 include/linux/clk-provider.h | 1 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 67201f67a14a..05e2481c1340 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1929,7 +1929,11 @@ static int clk_core_get_phase(struct clk_core *core)
int ret;
 
clk_prepare_lock();
-   ret = core->phase;
+   if (core && (core->flags & CLK_GET_PHASE_NOCACHE) &&
+   core->ops->get_phase)
+   ret = core->ops->get_phase(core->hw);
+   else
+   ret = core->phase;
clk_prepare_unlock();
 
return ret;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index a428aec36ace..e2e856b1a81f 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -35,6 +35,7 @@
 #define CLK_IS_CRITICALBIT(11) /* do not gate, ever */
 /* parents need enable during gate/ungate, set rate and re-parent */
 #define CLK_OPS_PARENT_ENABLE  BIT(12)
+#define CLK_GET_PHASE_NOCACHE  BIT(13) /* do not use the cached clk phase */
 
 struct clk;
 struct clk_hw;
-- 
2.11.0

[PATCH v2 0/8] clk: sunxi-ng: Add support for A83T CCU

[Chen-Yu Tsai]

Hi everyone,

(Resent with devicetree mailing list CC-ed.)
This is v2 of my A83T CCU series. This is for 4.13.

Changes since v1:

  - Dropped two patches that were merged

  - Added clk core flag to disable caching of clock phases

  - Added support for multiple variable pre-dividers

  - Merged "pll-periph-ahb1" pre-divider clock into "ahb1" clock
with multiple variable pre-dividers

  - Introduced new class of phase clocks that return -ENOTSUPP
when the clock is in new timing mode

  - Force mmc2 clock to new timing mode

  - Added back mmc2 output and sample clocks

  - Fixed bit ops for forcing audio PLL configuration

  - Added requirement for "losc" clock in device tree binding

  - Stripped leading 0 in device node name

  - Updated subject prefixes for various patches

Patch 1 adds a compatible string for the A83T CCU to the sunxi-ccu
bindings.

Patch 2 adds a CLK_GET_PHASE_NOCACHE flag to the clk core, asking it
not to cache clock phase values. This is similar to CLK_GET_RATE_NOCACHE.
Patch 5 has a compile time dependency on this patch, for the flag value.

Patch 3 adds a new class of phase clocks that check the new timing mode
bit, and returns an error if it is set, which indicates the phase delays
no longer apply. This is a clean way to signal which timing mode the mmc
clock is in, without using any custom functions or callbacks. We don't
support runtime switching of modes.

Patch 4 adds support for multiple variable pre-dividers to the sunxi-ng
mux class.

Patch 5 adds the driver for the A83T CCU.

Patch 6 adds the CCU device nodes, and fixes up any existing clock
phandles in the dtsi, without using the macros.

Patch 7 sets the clock accuracy for the main oscillator.

Patch 8 is for the next -rc2, switch the clock indices from raw numbers
to macros we introduced with the driver. This will be updated if more
peripherals are introduced in the same cycle.

Let me know what you think.

Cover letter excerpt from v1:

This is yet another series that adds support for the A83T CCU.
The A83T CCU has a mix of new styled (like the A80) clocks at
old (like A3x) offsets. Some differences include:

  - D1/D2 style PLL clocks
  - divisible audio module clocks
  - new timing mode for mmc2 module clock


Regards
ChenYu

Chen-Yu Tsai (8):
  dt-bindings: clock: sunxi-ccu: Add compatible string for A83T CCU
  clk: Provide option to query hardware for clk phase
  clk: sunxi-ng: Add class of phase clocks supporting MMC new timing
modes
  clk: sunxi-ng: Support multiple variable pre-dividers
  clk: sunxi-ng: Add driver for A83T CCU
  ARM: sun8i: a83t: Add CCU device nodes
  ARM: sun8i: a83t: Set clock accuracy for 24MHz oscillator
  ARM: sun8i: a83t: Switch to CCU device tree binding macros

 .../devicetree/bindings/clock/sunxi-ccu.txt|   2 +
 arch/arm/boot/dts/sun8i-a83t.dtsi  |  19 +-
 drivers/clk/clk.c  |   6 +-
 drivers/clk/sunxi-ng/Kconfig   |  10 +
 drivers/clk/sunxi-ng/Makefile  |   1 +
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c  |  10 +-
 drivers/clk/sunxi-ng/ccu-sun6i-a31.c   |  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a23.c   |  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a33.c   |  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c  | 911 +
 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h  |  64 ++
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c|  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-r.c |  10 +-
 drivers/clk/sunxi-ng/ccu-sun8i-v3s.c   |  10 +-
 drivers/clk/sunxi-ng/ccu_mux.c |  15 +-
 drivers/clk/sunxi-ng/ccu_mux.h |  13 +-
 drivers/clk/sunxi-ng/ccu_phase.c   |  47 ++
 drivers/clk/sunxi-ng/ccu_phase.h   |  16 +
 include/dt-bindings/clock/sun8i-a83t-ccu.h | 140 
 include/dt-bindings/reset/sun8i-a83t-ccu.h |  98 +++
 include/linux/clk-provider.h   |   1 +
 21 files changed, 1363 insertions(+), 50 deletions(-)
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.c
 create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-a83t.h
 create mode 100644 include/dt-bindings/clock/sun8i-a83t-ccu.h
 create mode 100644 include/dt-bindings/reset/sun8i-a83t-ccu.h

-- 
2.11.0