Re: [PATCH 01/10] staging: lustre: LNet drop rule implementation

[kbuild test robot]

Hi Liang,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.5-rc6 next-20160304]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/James-Simmons/Last-batch-of-fixes-for-LNet/20160305-101431
config: m68k-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

>> ERROR: "__umoddi3" [drivers/staging/lustre/lnet/lnet/lnet.ko] undefined!

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


.config.gz
Description: Binary data

Re: [PATCH 01/10] staging: lustre: LNet drop rule implementation

[kbuild test robot]

Hi Liang,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.5-rc6 next-20160304]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/James-Simmons/Last-batch-of-fixes-for-LNet/20160305-101431
config: m68k-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

>> ERROR: "__umoddi3" [drivers/staging/lustre/lnet/lnet/lnet.ko] undefined!

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


.config.gz
Description: Binary data

[TRIVIAL PATCH] treewide: Remove unnecessary 0x prefixes before %pa extension uses

[Joe Perches]

Since commit 3cab1e711297 ("lib/vsprintf: refactor duplicate code
to special_hex_number()") %pa uses have been ouput with a 0x prefix.

These 0x prefixes in the formats are unnecessary.

Signed-off-by: Joe Perches 
---
 drivers/dma/at_hdmac_regs.h  | 2 +-
 drivers/media/platform/ti-vpe/cal.c  | 2 +-
 drivers/nvdimm/pmem.c| 2 +-
 drivers/rapidio/devices/rio_mport_cdev.c | 4 ++--
 drivers/rapidio/devices/tsi721.c | 8 
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index 7f58f06..0474e4a 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -385,7 +385,7 @@ static void vdbg_dump_regs(struct at_dma_chan *atchan) {}
 static void atc_dump_lli(struct at_dma_chan *atchan, struct at_lli *lli)
 {
dev_crit(chan2dev(>chan_common),
-"  desc: s%pad d%pad ctrl0x%x:0x%x l0x%pad\n",
+"  desc: s%pad d%pad ctrl0x%x:0x%x l%pad\n",
 >saddr, >daddr,
 lli->ctrla, lli->ctrlb, >dscr);
 }
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index 82001e6..7dce489 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -498,7 +498,7 @@ static inline void cal_runtime_put(struct cal_dev *dev)
 
 static void cal_quickdump_regs(struct cal_dev *dev)
 {
-   cal_info(dev, "CAL Registers @ 0x%pa:\n", >res->start);
+   cal_info(dev, "CAL Registers @ %pa:\n", >res->start);
print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 4,
   (__force const void *)dev->base,
   resource_size(dev->res), false);
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 8d0b546..eb619d1 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -172,7 +172,7 @@ static struct pmem_device *pmem_alloc(struct device *dev,
 
if (!devm_request_mem_region(dev, pmem->phys_addr, pmem->size,
dev_name(dev))) {
-   dev_warn(dev, "could not reserve region [0x%pa:0x%zx]\n",
+   dev_warn(dev, "could not reserve region [%pa:0x%zx]\n",
>phys_addr, pmem->size);
return ERR_PTR(-EBUSY);
}
diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
b/drivers/rapidio/devices/rio_mport_cdev.c
index a3369d1..211a67d 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -2223,7 +2223,7 @@ static void mport_mm_open(struct vm_area_struct *vma)
 {
struct rio_mport_mapping *map = vma->vm_private_data;
 
-rmcd_debug(MMAP, "0x%pad", >phys_addr);
+   rmcd_debug(MMAP, "%pad", >phys_addr);
kref_get(>ref);
 }
 
@@ -2231,7 +2231,7 @@ static void mport_mm_close(struct vm_area_struct *vma)
 {
struct rio_mport_mapping *map = vma->vm_private_data;
 
-rmcd_debug(MMAP, "0x%pad", >phys_addr);
+   rmcd_debug(MMAP, "%pad", >phys_addr);
mutex_lock(>md->buf_mutex);
kref_put(>ref, mport_release_mapping);
mutex_unlock(>md->buf_mutex);
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index b5b4556..4c20e99 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -1101,7 +1101,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
*mport, dma_addr_t lstart,
ibw_start = lstart & ~(ibw_size - 1);
 
tsi_debug(IBW, >pdev->dev,
-   "Direct (RIO_0x%llx -> PCIe_0x%pad), size=0x%x, 
ibw_start = 0x%llx",
+   "Direct (RIO_0x%llx -> PCIe_%pad), size=0x%x, ibw_start 
= 0x%llx",
rstart, , size, ibw_start);
 
while ((lstart + size) > (ibw_start + ibw_size)) {
@@ -1120,7 +1120,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
*mport, dma_addr_t lstart,
 
} else {
tsi_debug(IBW, >pdev->dev,
-   "Translated (RIO_0x%llx -> PCIe_0x%pad), size=0x%x",
+   "Translated (RIO_0x%llx -> PCIe_%pad), size=0x%x",
rstart, , size);
 
if (!is_power_of_2(size) || size < 0x1000 ||
@@ -1215,7 +1215,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
*mport, dma_addr_t lstart,
priv->ibwin_cnt--;
 
tsi_debug(IBW, >pdev->dev,
-   "Configured IBWIN%d (RIO_0x%llx -> PCIe_0x%pad), size=0x%llx",
+   "Configured IBWIN%d (RIO_0x%llx -> PCIe_%pad), size=0x%llx",
i, ibw_start, _start, ibw_size);
 
return 0;
@@ -1237,7 +1237,7 @@ static void tsi721_rio_unmap_inb_mem(struct rio_mport 
*mport,
int i;
 
tsi_debug(IBW, >pdev->dev,
-   "Unmap IBW mapped to PCIe_0x%pad", );
+   "Unmap IBW mapped to PCIe_%pad", );
 
/* Search for matching active inbound translation window */
 

[TRIVIAL PATCH] treewide: Remove unnecessary 0x prefixes before %pa extension uses

[Joe Perches]

Since commit 3cab1e711297 ("lib/vsprintf: refactor duplicate code
to special_hex_number()") %pa uses have been ouput with a 0x prefix.

These 0x prefixes in the formats are unnecessary.

Signed-off-by: Joe Perches 
---
 drivers/dma/at_hdmac_regs.h  | 2 +-
 drivers/media/platform/ti-vpe/cal.c  | 2 +-
 drivers/nvdimm/pmem.c| 2 +-
 drivers/rapidio/devices/rio_mport_cdev.c | 4 ++--
 drivers/rapidio/devices/tsi721.c | 8 
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/dma/at_hdmac_regs.h b/drivers/dma/at_hdmac_regs.h
index 7f58f06..0474e4a 100644
--- a/drivers/dma/at_hdmac_regs.h
+++ b/drivers/dma/at_hdmac_regs.h
@@ -385,7 +385,7 @@ static void vdbg_dump_regs(struct at_dma_chan *atchan) {}
 static void atc_dump_lli(struct at_dma_chan *atchan, struct at_lli *lli)
 {
dev_crit(chan2dev(>chan_common),
-"  desc: s%pad d%pad ctrl0x%x:0x%x l0x%pad\n",
+"  desc: s%pad d%pad ctrl0x%x:0x%x l%pad\n",
 >saddr, >daddr,
 lli->ctrla, lli->ctrlb, >dscr);
 }
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
index 82001e6..7dce489 100644
--- a/drivers/media/platform/ti-vpe/cal.c
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -498,7 +498,7 @@ static inline void cal_runtime_put(struct cal_dev *dev)
 
 static void cal_quickdump_regs(struct cal_dev *dev)
 {
-   cal_info(dev, "CAL Registers @ 0x%pa:\n", >res->start);
+   cal_info(dev, "CAL Registers @ %pa:\n", >res->start);
print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 4,
   (__force const void *)dev->base,
   resource_size(dev->res), false);
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 8d0b546..eb619d1 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -172,7 +172,7 @@ static struct pmem_device *pmem_alloc(struct device *dev,
 
if (!devm_request_mem_region(dev, pmem->phys_addr, pmem->size,
dev_name(dev))) {
-   dev_warn(dev, "could not reserve region [0x%pa:0x%zx]\n",
+   dev_warn(dev, "could not reserve region [%pa:0x%zx]\n",
>phys_addr, pmem->size);
return ERR_PTR(-EBUSY);
}
diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
b/drivers/rapidio/devices/rio_mport_cdev.c
index a3369d1..211a67d 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -2223,7 +2223,7 @@ static void mport_mm_open(struct vm_area_struct *vma)
 {
struct rio_mport_mapping *map = vma->vm_private_data;
 
-rmcd_debug(MMAP, "0x%pad", >phys_addr);
+   rmcd_debug(MMAP, "%pad", >phys_addr);
kref_get(>ref);
 }
 
@@ -2231,7 +2231,7 @@ static void mport_mm_close(struct vm_area_struct *vma)
 {
struct rio_mport_mapping *map = vma->vm_private_data;
 
-rmcd_debug(MMAP, "0x%pad", >phys_addr);
+   rmcd_debug(MMAP, "%pad", >phys_addr);
mutex_lock(>md->buf_mutex);
kref_put(>ref, mport_release_mapping);
mutex_unlock(>md->buf_mutex);
diff --git a/drivers/rapidio/devices/tsi721.c b/drivers/rapidio/devices/tsi721.c
index b5b4556..4c20e99 100644
--- a/drivers/rapidio/devices/tsi721.c
+++ b/drivers/rapidio/devices/tsi721.c
@@ -1101,7 +1101,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
*mport, dma_addr_t lstart,
ibw_start = lstart & ~(ibw_size - 1);
 
tsi_debug(IBW, >pdev->dev,
-   "Direct (RIO_0x%llx -> PCIe_0x%pad), size=0x%x, 
ibw_start = 0x%llx",
+   "Direct (RIO_0x%llx -> PCIe_%pad), size=0x%x, ibw_start 
= 0x%llx",
rstart, , size, ibw_start);
 
while ((lstart + size) > (ibw_start + ibw_size)) {
@@ -1120,7 +1120,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
*mport, dma_addr_t lstart,
 
} else {
tsi_debug(IBW, >pdev->dev,
-   "Translated (RIO_0x%llx -> PCIe_0x%pad), size=0x%x",
+   "Translated (RIO_0x%llx -> PCIe_%pad), size=0x%x",
rstart, , size);
 
if (!is_power_of_2(size) || size < 0x1000 ||
@@ -1215,7 +1215,7 @@ static int tsi721_rio_map_inb_mem(struct rio_mport 
*mport, dma_addr_t lstart,
priv->ibwin_cnt--;
 
tsi_debug(IBW, >pdev->dev,
-   "Configured IBWIN%d (RIO_0x%llx -> PCIe_0x%pad), size=0x%llx",
+   "Configured IBWIN%d (RIO_0x%llx -> PCIe_%pad), size=0x%llx",
i, ibw_start, _start, ibw_size);
 
return 0;
@@ -1237,7 +1237,7 @@ static void tsi721_rio_unmap_inb_mem(struct rio_mport 
*mport,
int i;
 
tsi_debug(IBW, >pdev->dev,
-   "Unmap IBW mapped to PCIe_0x%pad", );
+   "Unmap IBW mapped to PCIe_%pad", );
 
/* Search for matching active inbound translation window */
for (i = 

Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag

[Stas Sergeev]

05.03.2016 10:39, Stas Sergeev пишет:

05.03.2016 01:22, Andy Lutomirski пишет:

On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev  wrote:

This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will be disabled when entering
the signal handler; more precisely, after saving sas to uc_stack.
When leaving the signal handler, the sigaltstack is restored by
uc_stack.
When this flag is used, it is safe to switch from sighandler with
swapcontext(). Without this flag, the subsequent signal will corrupt
the state of the switched-away sighandler.


This looks reasonable to me with one exception: how does a user
program detect the presence of this feature?

Compile-time detection:
#ifdef SS_AUTODISARM
  # I have this feature
  ...
#endif

Run-time detection:
int err = sigaltstack(SS_ONSTACK | SS_AUTODISARM);
if (err == EINVAL) {

I guess I mean here
if (err && errno == EINVAL)

Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag

[Stas Sergeev]

05.03.2016 10:39, Stas Sergeev пишет:

05.03.2016 01:22, Andy Lutomirski пишет:

On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev  wrote:

This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will be disabled when entering
the signal handler; more precisely, after saving sas to uc_stack.
When leaving the signal handler, the sigaltstack is restored by
uc_stack.
When this flag is used, it is safe to switch from sighandler with
swapcontext(). Without this flag, the subsequent signal will corrupt
the state of the switched-away sighandler.


This looks reasonable to me with one exception: how does a user
program detect the presence of this feature?

Compile-time detection:
#ifdef SS_AUTODISARM
  # I have this feature
  ...
#endif

Run-time detection:
int err = sigaltstack(SS_ONSTACK | SS_AUTODISARM);
if (err == EINVAL) {

I guess I mean here
if (err && errno == EINVAL)

Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag

[Stas Sergeev]

05.03.2016 01:22, Andy Lutomirski пишет:

On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev  wrote:

This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will be disabled when entering
the signal handler; more precisely, after saving sas to uc_stack.
When leaving the signal handler, the sigaltstack is restored by
uc_stack.
When this flag is used, it is safe to switch from sighandler with
swapcontext(). Without this flag, the subsequent signal will corrupt
the state of the switched-away sighandler.


This looks reasonable to me with one exception: how does a user
program detect the presence of this feature?

Compile-time detection:
#ifdef SS_AUTODISARM
  # I have this feature
  ...
#endif

Run-time detection:
int err = sigaltstack(SS_ONSTACK | SS_AUTODISARM);
if (err == EINVAL) {
  i_dont_have_this_feature = 1;
  err = sigaltstack(SS_ONSTACK);
}

Note: if you want to keep such detection for the future
additions, the mask can be enlarged to, say, ((1 << 24) - 1),
and whenever someone adds a new flag, he can lower the
mask by one bit.
But I think this would be an overkill in that particular case.

Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag

[Stas Sergeev]

05.03.2016 01:22, Andy Lutomirski пишет:

On Mon, Feb 29, 2016 at 1:29 PM, Stas Sergeev  wrote:

This patch implements the SS_AUTODISARM flag that can be ORed with
SS_ONSTACK when forming ss_flags.
When this flag is set, sigaltstack will be disabled when entering
the signal handler; more precisely, after saving sas to uc_stack.
When leaving the signal handler, the sigaltstack is restored by
uc_stack.
When this flag is used, it is safe to switch from sighandler with
swapcontext(). Without this flag, the subsequent signal will corrupt
the state of the switched-away sighandler.


This looks reasonable to me with one exception: how does a user
program detect the presence of this feature?

Compile-time detection:
#ifdef SS_AUTODISARM
  # I have this feature
  ...
#endif

Run-time detection:
int err = sigaltstack(SS_ONSTACK | SS_AUTODISARM);
if (err == EINVAL) {
  i_dont_have_this_feature = 1;
  err = sigaltstack(SS_ONSTACK);
}

Note: if you want to keep such detection for the future
additions, the mask can be enlarged to, say, ((1 << 24) - 1),
and whenever someone adds a new flag, he can lower the
mask by one bit.
But I think this would be an overkill in that particular case.

Re: [patch] sbp-target: checking for NULL instead of IS_ERR

[Nicholas A. Bellinger]

Hi Dan + BootC,

On Wed, 2016-03-02 at 13:09 +0300, Dan Carpenter wrote:
> We changed this from kzalloc to sbp_mgt_get_req() so we need to change
> from checking for NULL to check for error pointers.
> 
> Fixes: c064b2a78989 ('sbp-target: Conversion to percpu_ida tag 
> pre-allocation')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/target/sbp/sbp_target.c b/drivers/target/sbp/sbp_target.c
> index 251d532..a04b0605f 100644
> --- a/drivers/target/sbp/sbp_target.c
> +++ b/drivers/target/sbp/sbp_target.c
> @@ -951,7 +951,7 @@ static void tgt_agent_fetch_work(struct work_struct *work)
>  
>   while (next_orb && tgt_agent_check_active(agent)) {
>   req = sbp_mgt_get_req(sess, sess->card, next_orb);
> - if (!req) {
> + if (IS_ERR(req)) {
>   spin_lock_bh(>lock);
>   agent->state = AGENT_STATE_DEAD;
>   spin_unlock_bh(>lock);

Fixed + folded into the original patch.

Thanks Dan.

Chris, would you be so kind to review the original changes here:

sbp-target: Conversion to percpu_ida tag pre-allocation
http://www.spinics.net/lists/target-devel/msg11778.html

 sbp-target: Convert to TARGET_SCF_ACK_KREF I/O krefs
http://www.spinics.net/lists/target-devel/msg11780.html

and verify on your local IEEE1394 target setup..?

Re: [patch] sbp-target: checking for NULL instead of IS_ERR

[Nicholas A. Bellinger]

Hi Dan + BootC,

On Wed, 2016-03-02 at 13:09 +0300, Dan Carpenter wrote:
> We changed this from kzalloc to sbp_mgt_get_req() so we need to change
> from checking for NULL to check for error pointers.
> 
> Fixes: c064b2a78989 ('sbp-target: Conversion to percpu_ida tag 
> pre-allocation')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/target/sbp/sbp_target.c b/drivers/target/sbp/sbp_target.c
> index 251d532..a04b0605f 100644
> --- a/drivers/target/sbp/sbp_target.c
> +++ b/drivers/target/sbp/sbp_target.c
> @@ -951,7 +951,7 @@ static void tgt_agent_fetch_work(struct work_struct *work)
>  
>   while (next_orb && tgt_agent_check_active(agent)) {
>   req = sbp_mgt_get_req(sess, sess->card, next_orb);
> - if (!req) {
> + if (IS_ERR(req)) {
>   spin_lock_bh(>lock);
>   agent->state = AGENT_STATE_DEAD;
>   spin_unlock_bh(>lock);

Fixed + folded into the original patch.

Thanks Dan.

Chris, would you be so kind to review the original changes here:

sbp-target: Conversion to percpu_ida tag pre-allocation
http://www.spinics.net/lists/target-devel/msg11778.html

 sbp-target: Convert to TARGET_SCF_ACK_KREF I/O krefs
http://www.spinics.net/lists/target-devel/msg11780.html

and verify on your local IEEE1394 target setup..?

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

Hi Felipe + usb-gadget folks,

On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote:
> Dan Carpenter  writes:
> > We need to move the kfree() down a line so we don't dereference a freed
> > variable.
> >
> > Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> > target_alloc_session')
> > Signed-off-by: Dan Carpenter 
> 
> It's okay to take this via target:
> 
> Signed-off-by: Felipe Balbi 
> 

Note this specific patch is only a mechanical change, and we still need
reviews for the more interesting conversions:

usb-gadget/tcm: Conversion to percpu_ida tag pre-allocation
http://www.spinics.net/lists/target-devel/msg11777.html

usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs
http://www.spinics.net/lists/target-devel/msg11782.html

Felipe, Sebastian, & Andrezj, would you be so kind to review and test
usb-gadget using target-pending/for-next code..?

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

Hi Felipe + usb-gadget folks,

On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote:
> Dan Carpenter  writes:
> > We need to move the kfree() down a line so we don't dereference a freed
> > variable.
> >
> > Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> > target_alloc_session')
> > Signed-off-by: Dan Carpenter 
> 
> It's okay to take this via target:
> 
> Signed-off-by: Felipe Balbi 
> 

Note this specific patch is only a mechanical change, and we still need
reviews for the more interesting conversions:

usb-gadget/tcm: Conversion to percpu_ida tag pre-allocation
http://www.spinics.net/lists/target-devel/msg11777.html

usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs
http://www.spinics.net/lists/target-devel/msg11782.html

Felipe, Sebastian, & Andrezj, would you be so kind to review and test
usb-gadget using target-pending/for-next code..?

Re: [patch] tcm_loop: use after free on error

[Nicholas A. Bellinger]

On Wed, 2016-03-02 at 13:09 +0300, Dan Carpenter wrote:
> We dereference "tl_nexus" to get the error code.
> 
> Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> target_alloc_session')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/target/loopback/tcm_loop.c 
> b/drivers/target/loopback/tcm_loop.c
> index 0216c75..e0ffb03 100644
> --- a/drivers/target/loopback/tcm_loop.c
> +++ b/drivers/target/loopback/tcm_loop.c
> @@ -808,6 +808,7 @@ static int tcm_loop_make_nexus(
>  {
>   struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba;
>   struct tcm_loop_nexus *tl_nexus;
> + int ret;
>  
>   if (tl_tpg->tl_nexus) {
>   pr_debug("tl_tpg->tl_nexus already exists\n");
> @@ -824,8 +825,9 @@ static int tcm_loop_make_nexus(
>   TARGET_PROT_DIN_PASS | 
> TARGET_PROT_DOUT_PASS,
>   name, tl_nexus, NULL);
>   if (IS_ERR(tl_nexus->se_sess)) {
> + ret = PTR_ERR(tl_nexus->se_sess);
>   kfree(tl_nexus);
> - return PTR_ERR(tl_nexus->se_sess);
> + return ret;
>   }
>  
>   tl_tpg->tl_nexus = tl_nexus;

Also fixed + squashed into HCH's original patch.

Re: [patch] tcm_loop: use after free on error

[Nicholas A. Bellinger]

On Wed, 2016-03-02 at 13:09 +0300, Dan Carpenter wrote:
> We dereference "tl_nexus" to get the error code.
> 
> Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> target_alloc_session')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/target/loopback/tcm_loop.c 
> b/drivers/target/loopback/tcm_loop.c
> index 0216c75..e0ffb03 100644
> --- a/drivers/target/loopback/tcm_loop.c
> +++ b/drivers/target/loopback/tcm_loop.c
> @@ -808,6 +808,7 @@ static int tcm_loop_make_nexus(
>  {
>   struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba;
>   struct tcm_loop_nexus *tl_nexus;
> + int ret;
>  
>   if (tl_tpg->tl_nexus) {
>   pr_debug("tl_tpg->tl_nexus already exists\n");
> @@ -824,8 +825,9 @@ static int tcm_loop_make_nexus(
>   TARGET_PROT_DIN_PASS | 
> TARGET_PROT_DOUT_PASS,
>   name, tl_nexus, NULL);
>   if (IS_ERR(tl_nexus->se_sess)) {
> + ret = PTR_ERR(tl_nexus->se_sess);
>   kfree(tl_nexus);
> - return PTR_ERR(tl_nexus->se_sess);
> + return ret;
>   }
>  
>   tl_tpg->tl_nexus = tl_nexus;

Also fixed + squashed into HCH's original patch.

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

On Wed, 2016-03-02 at 13:08 +0300, Dan Carpenter wrote:
> We need to move the kfree() down a line so we don't dereference a freed
> variable.
> 
> Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> target_alloc_session')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/usb/gadget/function/f_tcm.c 
> b/drivers/usb/gadget/function/f_tcm.c
> index 7276a73..e352a31 100644
> --- a/drivers/usb/gadget/function/f_tcm.c
> +++ b/drivers/usb/gadget/function/f_tcm.c
> @@ -1596,8 +1596,8 @@ static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, 
> char *name)
>  #define MAKE_NEXUS_MSG "core_tpg_check_initiator_node_acl() failed for %s\n"
>   pr_debug(MAKE_NEXUS_MSG, name);
>  #undef MAKE_NEXUS_MSG
> - kfree(tv_nexus);
>   ret = PTR_ERR(tv_nexus->tvn_se_sess);
> + kfree(tv_nexus);
>   }
>  
>  out_unlock:

Fixed + squashed into the original patch.

Thanks Dan.

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

On Wed, 2016-03-02 at 13:08 +0300, Dan Carpenter wrote:
> We need to move the kfree() down a line so we don't dereference a freed
> variable.
> 
> Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> target_alloc_session')
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/usb/gadget/function/f_tcm.c 
> b/drivers/usb/gadget/function/f_tcm.c
> index 7276a73..e352a31 100644
> --- a/drivers/usb/gadget/function/f_tcm.c
> +++ b/drivers/usb/gadget/function/f_tcm.c
> @@ -1596,8 +1596,8 @@ static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, 
> char *name)
>  #define MAKE_NEXUS_MSG "core_tpg_check_initiator_node_acl() failed for %s\n"
>   pr_debug(MAKE_NEXUS_MSG, name);
>  #undef MAKE_NEXUS_MSG
> - kfree(tv_nexus);
>   ret = PTR_ERR(tv_nexus->tvn_se_sess);
> + kfree(tv_nexus);
>   }
>  
>  out_unlock:

Fixed + squashed into the original patch.

Thanks Dan.

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

[Michal Marek]

On Fri, Mar 04, 2016 at 11:53:53PM +0100, Michal Marek wrote:
> Dne 4.3.2016 v 23:51 Michal Marek napsal(a):
> > Dne 4.3.2016 v 06:40 Nicolas Pitre napsal(a):
> >> +cmd_and_fixdep =  
> >>\
> >> +  $(echo-cmd) $(cmd_$(1)); \
> >> +  $(ksym_dep_filter) | \
> >> +  scripts/basic/fixdep -e $(depfile) $@ '$(make-cmd)'  \
> >> +  > $(dot-target).tmp; \
> >> +  rm -f $(depfile);\
> >> +  mv -f $(dot-target).tmp $(dot-target).cmd;
> > 
> > While trying this, I got a SIGBUS from fixdep once. My theory is that
> > the depfile is mmap()ed by fixdep and modified by the preprocesor run at
> > the same time. I could not reproduce this so far (still trying). But if
> > it's really this race, the fix would be to disable dependency generation
> > in the preprocessor by passing -Wp,MD,/dev/null or somesuch. But we
> > never had this problem with genksyms, which is weird. It could as well
> > be that my build machine's memory is faulty :(.
> 
> Actually, genksyms does not ran in parallel. neither before nor after
  run
> this patch.

I reproduced the SIGBUS after a few iterations, and it crashes in
parse_dep_file(). I'm now testing this

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 0be7e09ba381..4fdd8348acf6 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -270,10 +270,12 @@ else
 
 # Filter out exported kernel symbol names from the preprocessor output.
 # See also __KSYM_DEPS__ in include/linux/export.h.
+# We disable the depfile generation here, so as not to overwrite the existing
+# depfile while fixdep is parsing it
 ksym_dep_filter =\
case "$(1)" in   \
-   cc_*_c) $(CPP) $(c_flags) -D__KSYM_DEPS__ $< ;;  \
-   as_*_S) $(CPP) $(a_flags) -D__KSYM_DEPS__ $< ;;  \
+   cc_*_c) $(CPP) $(filter-out -Wp$(comma)-M%, $(c_flags)) -D__KSYM_DEPS__ 
$< ;; \
+   as_*_S) $(CPP) $(filter-out -Wp$(comma)-M%, $(a_flags)) -D__KSYM_DEPS__ 
$< ;; \
cpp_lds_S) : ;;  \
*) echo "Don't know how to preprocess $(1)"; false ;;\
esac | sed -rn 's/^.*=== __KSYM_(.*) ===.*$$/KSYM_\1/p'

Michal

Re: [PATCH v5 5/8] kbuild: add fine grained build dependencies for exported symbols

[Michal Marek]

On Fri, Mar 04, 2016 at 11:53:53PM +0100, Michal Marek wrote:
> Dne 4.3.2016 v 23:51 Michal Marek napsal(a):
> > Dne 4.3.2016 v 06:40 Nicolas Pitre napsal(a):
> >> +cmd_and_fixdep =  
> >>\
> >> +  $(echo-cmd) $(cmd_$(1)); \
> >> +  $(ksym_dep_filter) | \
> >> +  scripts/basic/fixdep -e $(depfile) $@ '$(make-cmd)'  \
> >> +  > $(dot-target).tmp; \
> >> +  rm -f $(depfile);\
> >> +  mv -f $(dot-target).tmp $(dot-target).cmd;
> > 
> > While trying this, I got a SIGBUS from fixdep once. My theory is that
> > the depfile is mmap()ed by fixdep and modified by the preprocesor run at
> > the same time. I could not reproduce this so far (still trying). But if
> > it's really this race, the fix would be to disable dependency generation
> > in the preprocessor by passing -Wp,MD,/dev/null or somesuch. But we
> > never had this problem with genksyms, which is weird. It could as well
> > be that my build machine's memory is faulty :(.
> 
> Actually, genksyms does not ran in parallel. neither before nor after
  run
> this patch.

I reproduced the SIGBUS after a few iterations, and it crashes in
parse_dep_file(). I'm now testing this

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 0be7e09ba381..4fdd8348acf6 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -270,10 +270,12 @@ else
 
 # Filter out exported kernel symbol names from the preprocessor output.
 # See also __KSYM_DEPS__ in include/linux/export.h.
+# We disable the depfile generation here, so as not to overwrite the existing
+# depfile while fixdep is parsing it
 ksym_dep_filter =\
case "$(1)" in   \
-   cc_*_c) $(CPP) $(c_flags) -D__KSYM_DEPS__ $< ;;  \
-   as_*_S) $(CPP) $(a_flags) -D__KSYM_DEPS__ $< ;;  \
+   cc_*_c) $(CPP) $(filter-out -Wp$(comma)-M%, $(c_flags)) -D__KSYM_DEPS__ 
$< ;; \
+   as_*_S) $(CPP) $(filter-out -Wp$(comma)-M%, $(a_flags)) -D__KSYM_DEPS__ 
$< ;; \
cpp_lds_S) : ;;  \
*) echo "Don't know how to preprocess $(1)"; false ;;\
esac | sed -rn 's/^.*=== __KSYM_(.*) ===.*$$/KSYM_\1/p'

Michal

Re: [PATCH 4/5] ARM: socfpga: Enable Arria10 L2 cache ECC on startup

[Dinh Nguyen]

On Tue, 1 Mar 2016, ttha...@opensource.altera.com wrote:

> From: Thor Thayer 
> 
> Enable ECC for Arria10 L2 cache on machine startup. The ECC has to be
> enabled before data is stored in memory otherwise the ECC will fail
> on reads.
> 
> Signed-off-by: Thor Thayer 
> ---
>  arch/arm/mach-socfpga/l2_cache.c |   42 
> ++
>  1 file changed, 38 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/l2_cache.c 
> b/arch/arm/mach-socfpga/l2_cache.c
> index e3907ab..b197218 100644
> --- a/arch/arm/mach-socfpga/l2_cache.c
> +++ b/arch/arm/mach-socfpga/l2_cache.c
> @@ -17,14 +17,31 @@
>  #include 
>  #include 
>  
> +#include "core.h"
> +
> +/* A10 System Manager ECC interrupt mask control registers */
> +#define A10_L2_ECC_CTRL_OFST0x0
> +
> +#define A10_SYSMGR_ECC_INTMASK_CLR_OFST 0x98
> +#define A10_L2_ECC_INT_CLR_OFST 0xA8
> +
> +#define A10_MPU_CTRL_L2_ECC_EN  BIT(0)
> +#define A10_ECC_INTMASK_CLR_EN  BIT(0)
> +#define A10_ECC_INT_CLR (BIT(31) | BIT(15))
> +
>  void socfpga_init_l2_ecc(void)
>  {
>   struct device_node *np;
>   void __iomem *mapped_l2_edac_addr;
> + const char *compat = "altr,socfpga-l2-ecc";
>  
> - np = of_find_compatible_node(NULL, NULL, "altr,socfpga-l2-ecc");
> + if (of_machine_is_compatible("altr,socfpga-arria10"))
> + compat = "altr,socfpga-a10-l2-ecc";

The ARM maintainers have made comment to me about about trying to not sprinkle
these of_machine_is_compatible() all over the place. You should make the
decision during the initial probe of the machine. Please look at how the
.restart is differentiate between the 2 platforms.


> +
> + /* Find the L2 EDAC device tree node */
> + np = of_find_compatible_node(NULL, NULL, compat);
>   if (!np) {
> - pr_err("Unable to find socfpga-l2-ecc in dtb\n");
> + pr_err("Unable to find %s in dtb\n", compat);
>   return;
>   }
>  
> @@ -35,7 +52,24 @@ void socfpga_init_l2_ecc(void)
>   return;
>   }
>  
> - /* Enable ECC */
> - writel(0x01, mapped_l2_edac_addr);
> + if (of_machine_is_compatible("altr,socfpga-arria10")) {

Same comment as above here.

BR,
Dinh

Re: [PATCH 4/5] ARM: socfpga: Enable Arria10 L2 cache ECC on startup

[Dinh Nguyen]

On Tue, 1 Mar 2016, ttha...@opensource.altera.com wrote:

> From: Thor Thayer 
> 
> Enable ECC for Arria10 L2 cache on machine startup. The ECC has to be
> enabled before data is stored in memory otherwise the ECC will fail
> on reads.
> 
> Signed-off-by: Thor Thayer 
> ---
>  arch/arm/mach-socfpga/l2_cache.c |   42 
> ++
>  1 file changed, 38 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/l2_cache.c 
> b/arch/arm/mach-socfpga/l2_cache.c
> index e3907ab..b197218 100644
> --- a/arch/arm/mach-socfpga/l2_cache.c
> +++ b/arch/arm/mach-socfpga/l2_cache.c
> @@ -17,14 +17,31 @@
>  #include 
>  #include 
>  
> +#include "core.h"
> +
> +/* A10 System Manager ECC interrupt mask control registers */
> +#define A10_L2_ECC_CTRL_OFST0x0
> +
> +#define A10_SYSMGR_ECC_INTMASK_CLR_OFST 0x98
> +#define A10_L2_ECC_INT_CLR_OFST 0xA8
> +
> +#define A10_MPU_CTRL_L2_ECC_EN  BIT(0)
> +#define A10_ECC_INTMASK_CLR_EN  BIT(0)
> +#define A10_ECC_INT_CLR (BIT(31) | BIT(15))
> +
>  void socfpga_init_l2_ecc(void)
>  {
>   struct device_node *np;
>   void __iomem *mapped_l2_edac_addr;
> + const char *compat = "altr,socfpga-l2-ecc";
>  
> - np = of_find_compatible_node(NULL, NULL, "altr,socfpga-l2-ecc");
> + if (of_machine_is_compatible("altr,socfpga-arria10"))
> + compat = "altr,socfpga-a10-l2-ecc";

The ARM maintainers have made comment to me about about trying to not sprinkle
these of_machine_is_compatible() all over the place. You should make the
decision during the initial probe of the machine. Please look at how the
.restart is differentiate between the 2 platforms.


> +
> + /* Find the L2 EDAC device tree node */
> + np = of_find_compatible_node(NULL, NULL, compat);
>   if (!np) {
> - pr_err("Unable to find socfpga-l2-ecc in dtb\n");
> + pr_err("Unable to find %s in dtb\n", compat);
>   return;
>   }
>  
> @@ -35,7 +52,24 @@ void socfpga_init_l2_ecc(void)
>   return;
>   }
>  
> - /* Enable ECC */
> - writel(0x01, mapped_l2_edac_addr);
> + if (of_machine_is_compatible("altr,socfpga-arria10")) {

Same comment as above here.

BR,
Dinh

Re: [PATCH v2 2/2] spi: spi-pic32: Add PIC32 SPI master driver

[kbuild test robot]

Hi Purna,

[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.5-rc6 next-20160304]
[cannot apply to spi/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Purna-Chandra-Mandal/dt-bindings-Add-bindings-for-PIC32-SPI-peripheral/20160304-214814
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: sparc64-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/dmaengine.h:20:0,
from drivers/spi/spi-pic32.c:20:
   drivers/spi/spi-pic32.c: In function 'pic32_spi_dma_transfer':
>> drivers/spi/spi-pic32.c:392:18: warning: cast to pointer from integer of 
>> different size [-Wint-to-pointer-cast]
   xfer->tx_buf, (void *)xfer->tx_dma,
 ^
   include/linux/device.h:1286:41: note: in definition of macro 'dev_vdbg'
  dev_printk(KERN_DEBUG, dev, format, ##arg); \
^
   drivers/spi/spi-pic32.c:393:18: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
   xfer->rx_buf, (void *)xfer->rx_dma);
 ^
   include/linux/device.h:1286:41: note: in definition of macro 'dev_vdbg'
  dev_printk(KERN_DEBUG, dev, format, ##arg); \
^

vim +392 drivers/spi/spi-pic32.c

   376  ret = -EINVAL;
   377  goto err_dma;
   378  }
   379  
   380  desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
   381xfer->tx_sg.sgl,
   382xfer->tx_sg.nents,
   383DMA_TO_DEVICE,
   384DMA_PREP_INTERRUPT | 
DMA_CTRL_ACK);
   385  if (!desc_tx) {
   386  ret = -EINVAL;
   387  goto err_dma;
   388  }
   389  
   390  dev_vdbg(>dev, "dma_xfer %p: len %u, tx %p(%p), rx 
%p(%p)\n",
   391   xfer, xfer->len,
 > 392   xfer->tx_buf, (void *)xfer->tx_dma,
   393   xfer->rx_buf, (void *)xfer->rx_dma);
   394  
   395  /* Put callback on the RX transfer, that should finish last */
   396  desc_rx->callback = pic32_spi_dma_rx_notify;
   397  desc_rx->callback_param = pic32s;
   398  
   399  cookie = dmaengine_submit(desc_rx);
   400  ret = dma_submit_error(cookie);

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


.config.gz
Description: Binary data

Re: [PATCH v2 2/2] spi: spi-pic32: Add PIC32 SPI master driver

[kbuild test robot]

Hi Purna,

[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.5-rc6 next-20160304]
[cannot apply to spi/for-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Purna-Chandra-Mandal/dt-bindings-Add-bindings-for-PIC32-SPI-peripheral/20160304-214814
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux for-next
config: sparc64-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/dmaengine.h:20:0,
from drivers/spi/spi-pic32.c:20:
   drivers/spi/spi-pic32.c: In function 'pic32_spi_dma_transfer':
>> drivers/spi/spi-pic32.c:392:18: warning: cast to pointer from integer of 
>> different size [-Wint-to-pointer-cast]
   xfer->tx_buf, (void *)xfer->tx_dma,
 ^
   include/linux/device.h:1286:41: note: in definition of macro 'dev_vdbg'
  dev_printk(KERN_DEBUG, dev, format, ##arg); \
^
   drivers/spi/spi-pic32.c:393:18: warning: cast to pointer from integer of 
different size [-Wint-to-pointer-cast]
   xfer->rx_buf, (void *)xfer->rx_dma);
 ^
   include/linux/device.h:1286:41: note: in definition of macro 'dev_vdbg'
  dev_printk(KERN_DEBUG, dev, format, ##arg); \
^

vim +392 drivers/spi/spi-pic32.c

   376  ret = -EINVAL;
   377  goto err_dma;
   378  }
   379  
   380  desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
   381xfer->tx_sg.sgl,
   382xfer->tx_sg.nents,
   383DMA_TO_DEVICE,
   384DMA_PREP_INTERRUPT | 
DMA_CTRL_ACK);
   385  if (!desc_tx) {
   386  ret = -EINVAL;
   387  goto err_dma;
   388  }
   389  
   390  dev_vdbg(>dev, "dma_xfer %p: len %u, tx %p(%p), rx 
%p(%p)\n",
   391   xfer, xfer->len,
 > 392   xfer->tx_buf, (void *)xfer->tx_dma,
   393   xfer->rx_buf, (void *)xfer->rx_dma);
   394  
   395  /* Put callback on the RX transfer, that should finish last */
   396  desc_rx->callback = pic32_spi_dma_rx_notify;
   397  desc_rx->callback_param = pic32s;
   398  
   399  cookie = dmaengine_submit(desc_rx);
   400  ret = dma_submit_error(cookie);

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


.config.gz
Description: Binary data

Re: [RFC PATCH 0/2] percpu_counter: Enable switching to global counter

[Dave Chinner]

On Fri, Mar 04, 2016 at 09:51:37PM -0500, Waiman Long wrote:
> This patchset allows the degeneration of per-cpu counters back to
> global counters when:
> 
>  1) The number of CPUs in the system is large, hence a high cost for
> calling percpu_counter_sum().
>  2) The initial count value is small so that it has a high chance of
> excessive percpu_counter_sum() calls.
> 
> When the above 2 conditions are true, this patchset allows the user of
> per-cpu counters to selectively degenerate them into global counters
> with lock. This is done by calling the new percpu_counter_set_limit()
> API after percpu_counter_set(). Without this call, there is no change
> in the behavior of the per-cpu counters.
> 
> Patch 1 implements the new percpu_counter_set_limit() API.
> 
> Patch 2 modifies XFS to call the new API for the m_ifree and m_fdblocks
> per-cpu counters.
> 
> Waiman Long (2):
>   percpu_counter: Allow falling back to global counter on large system
>   xfs: Allow degeneration of m_fdblocks/m_ifree to global counters

NACK.

This change to turns off per-counter free block counters for 32p for
the XFS free block counters.  We proved 10 years ago that a global
lock for these counters was a massive scalability limitation for
concurrent buffered writes on 16p machines.

IOWs, this change is going to cause fast path concurrent sequential
write regressions for just about everyone, even on empty
filesystems.

The behaviour you are seeing only occurs when the filesystem is near
to ENOSPC. As i asked you last time - if you want to make this
problem go away, please increase the size of the filesystem you are
running your massively concurrent benchmarks on.

IOWs, please stop trying to optimise a filesystem slow path that:

a) 99.9% of production workloads never execute,
b) where we expect performance to degrade as allocation gets
   computationally expensive as we close in on ENOSPC,
c) we start to execute blocking data flush operations that
   slow everything down massively, and
d) is indicative that the workload is about to suffer
   from a fatal, unrecoverable error (i.e. ENOSPC)

Cheers,

Dave.
-- 
Dave Chinner
dchin...@redhat.com

Re: [RFC PATCH 0/2] percpu_counter: Enable switching to global counter

[Dave Chinner]

On Fri, Mar 04, 2016 at 09:51:37PM -0500, Waiman Long wrote:
> This patchset allows the degeneration of per-cpu counters back to
> global counters when:
> 
>  1) The number of CPUs in the system is large, hence a high cost for
> calling percpu_counter_sum().
>  2) The initial count value is small so that it has a high chance of
> excessive percpu_counter_sum() calls.
> 
> When the above 2 conditions are true, this patchset allows the user of
> per-cpu counters to selectively degenerate them into global counters
> with lock. This is done by calling the new percpu_counter_set_limit()
> API after percpu_counter_set(). Without this call, there is no change
> in the behavior of the per-cpu counters.
> 
> Patch 1 implements the new percpu_counter_set_limit() API.
> 
> Patch 2 modifies XFS to call the new API for the m_ifree and m_fdblocks
> per-cpu counters.
> 
> Waiman Long (2):
>   percpu_counter: Allow falling back to global counter on large system
>   xfs: Allow degeneration of m_fdblocks/m_ifree to global counters

NACK.

This change to turns off per-counter free block counters for 32p for
the XFS free block counters.  We proved 10 years ago that a global
lock for these counters was a massive scalability limitation for
concurrent buffered writes on 16p machines.

IOWs, this change is going to cause fast path concurrent sequential
write regressions for just about everyone, even on empty
filesystems.

The behaviour you are seeing only occurs when the filesystem is near
to ENOSPC. As i asked you last time - if you want to make this
problem go away, please increase the size of the filesystem you are
running your massively concurrent benchmarks on.

IOWs, please stop trying to optimise a filesystem slow path that:

a) 99.9% of production workloads never execute,
b) where we expect performance to degrade as allocation gets
   computationally expensive as we close in on ENOSPC,
c) we start to execute blocking data flush operations that
   slow everything down massively, and
d) is indicative that the workload is about to suffer
   from a fatal, unrecoverable error (i.e. ENOSPC)

Cheers,

Dave.
-- 
Dave Chinner
dchin...@redhat.com

Re: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding

[pankaj.dubey]

Hi

On Wednesday 02 March 2016 11:23 PM, Rob Herring wrote:
> On Thu, Feb 25, 2016 at 02:03:37PM +0530, Pankaj Dubey wrote:
>> This patch adds exynos-srom binding information for SROM Controller
>> driver on Exynos SoCs.
>>
>> CC: Rob Herring 
>> CC: Mark Rutland 
>> CC: Ian Campbell 
>> CC: devicet...@vger.kernel.org
>> Signed-off-by: Pankaj Dubey 
>> Reviewed-by: Krzysztof Kozlowski 
>> Signed-off-by: Kukjin Kim 
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  .../devicetree/bindings/memory-controllers/exynos-srom.txt   | 12 
>> 
>>  1 file changed, 12 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt 
>> b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> new file mode 100644
>> index 000..33886d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> @@ -0,0 +1,12 @@
>> +SAMSUNG Exynos SoCs SROM Controller driver.
>> +
>> +Required properties:
>> +- compatible : Should contain "samsung,exynos-srom".
> 
> There should be SoC specific compatible strings in addition to this.
> 

I do not understood need of additional SoC specific compatible here. As
of now all SoCs having SROM can work with exynos specific common
compatible. Do you see any issues if we do not have SoC specific
compatible here.

>> +
>> +- reg: offset and length of the register set
>> +
>> +Example:
>> +sromc@1257 {
> 
> This should be memory-controller@...
> 
>> +compatible = "samsung,exynos-srom";
>> +reg = <0x1257 0x10>;
> 
> The next patch changes the size to 0x14?
> 
> BTW, you could just combine both patches. I guess you didn't to maintain 
> authorship?
> 

OK. Will squash both of these patches, unless Pavel do not have any
objections to this.

Thanks,
Pankaj Dubey

> Rob
> 
> 

Re: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding

[pankaj.dubey]

Hi

On Wednesday 02 March 2016 11:23 PM, Rob Herring wrote:
> On Thu, Feb 25, 2016 at 02:03:37PM +0530, Pankaj Dubey wrote:
>> This patch adds exynos-srom binding information for SROM Controller
>> driver on Exynos SoCs.
>>
>> CC: Rob Herring 
>> CC: Mark Rutland 
>> CC: Ian Campbell 
>> CC: devicet...@vger.kernel.org
>> Signed-off-by: Pankaj Dubey 
>> Reviewed-by: Krzysztof Kozlowski 
>> Signed-off-by: Kukjin Kim 
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  .../devicetree/bindings/memory-controllers/exynos-srom.txt   | 12 
>> 
>>  1 file changed, 12 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt 
>> b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> new file mode 100644
>> index 000..33886d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> @@ -0,0 +1,12 @@
>> +SAMSUNG Exynos SoCs SROM Controller driver.
>> +
>> +Required properties:
>> +- compatible : Should contain "samsung,exynos-srom".
> 
> There should be SoC specific compatible strings in addition to this.
> 

I do not understood need of additional SoC specific compatible here. As
of now all SoCs having SROM can work with exynos specific common
compatible. Do you see any issues if we do not have SoC specific
compatible here.

>> +
>> +- reg: offset and length of the register set
>> +
>> +Example:
>> +sromc@1257 {
> 
> This should be memory-controller@...
> 
>> +compatible = "samsung,exynos-srom";
>> +reg = <0x1257 0x10>;
> 
> The next patch changes the size to 0x14?
> 
> BTW, you could just combine both patches. I guess you didn't to maintain 
> authorship?
> 

OK. Will squash both of these patches, unless Pavel do not have any
objections to this.

Thanks,
Pankaj Dubey

> Rob
> 
> 

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

[David Rivshin (Allworx)]

On Fri, 04 Mar 2016 16:38:01 +0100
Jacek Anaszewski  wrote:

> On 03/04/2016 03:27 PM, David Rivshin (Allworx) wrote:
> > (Stefan, sorry for the duplicate, I just realized that I originally
> > replied only to you by accident).
> >
> > On Thu, 3 Mar 2016 19:13:03 +0100 (CET)
> > Stefan Wahren  wrote:
> >  
> >> Hi David,
> >>
> >> i will test the driver on weekend. Some comments below  
> >
> > Great, thanks very much.
> >  
> >>> "David Rivshin (Allworx)"  hat am 3. März 
> >>> 2016 um
> >>> 04:01 geschrieben:
> >>>
> >>>
> >>> From: David Rivshin 
> >>>
> >>> The IS31FL32xx family of LED controllers are I2C devices with multiple
> >>> constant-current channels, each with independent 256-level PWM control.
> >>>
> >>> Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
> >>>
> >>> This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
> >>> (TI am335x) platform.
> >>>
> >>> The programming paradigm of these devices is similar in the following
> >>> ways:
> >>> - All registers are 8 bit
> >>> - All LED control registers are write-only
> >>> - Each LED channel has a PWM register (0-255)
> >>> - PWM register writes are shadowed until an Update register is poked
> >>> - All have a concept of Software Shutdown, which disables output
> >>>
> >>> However, there are some differences in devices:
> >>> - 3236/3235 have a separate Control register for each LED,
> >>> (3218/3216 pack the enable bits into fewer registers)
> >>> - 3236/3235 have a per-channel current divisor setting
> >>> - 3236/3235 have a Global Control register that can turn off all LEDs
> >>> - 3216 is unique in a number of ways
> >>> - OUT9-OUT16 can be configured as GPIOs instead of LED controls
> >>> - LEDs can be programmed with an 8-frame animation, with
> >>> programmable delay between frames
> >>> - LEDs can be modulated by an input audio signal
> >>> - Max output current can be adjusted from 1/4 to 2x globally
> >>> - Has a Configuration register instead of a Shutdown register
> >>>
> >>> This driver currently only supports the base PWM control function
> >>> of these devices. The following features of these devices are not
> >>> implemented, although it should be possible to add them in the future:
> >>> - All devices are capable of going into a lower-power "software
> >>> shutdown" mode.
> >>> - The is31fl3236 and is31fl3235 can reduce the max output current
> >>> per-channel with a divisor of 1, 2, 3, or 4.
> >>> - The is31fl3216 can use some LED channels as GPIOs instead.
> >>> - The is31fl3216 can animate LEDs in hardware.
> >>> - The is31fl3216 can modulate LEDs according to an audio input.
> >>> - The is31fl3216 can reduce/increase max output current globally.
> >>>
> >>> Signed-off-by: David Rivshin 
> >>> ---
> >>>
> >>> You may see two instances of this warning:
> >>> "passing argument 1 of 'of_property_read_string' discards 'const'
> >>> qualifier from pointer target type"
> >>> That is a result of of_property_read_string() taking a non-const
> >>> struct device_node pointer parameter. I have separately submitted a
> >>> patch to fix that [1], and a few related functions which had the same
> >>> issue. I'm hoping that will get into linux-next before this does, so
> >>> that the warnings never show up there.
> >>>
> >>> Changes from RFC:
> >>> - Removed max-brightness DT property.
> >>> - Refer to these devices as "LED controllers" in Kconfig.
> >>> - Removed redundant last sentence from Kconfig entry
> >>> - Removed unnecessary debug code.
> >>> - Do not set led_classdev.brightness to 0 explicitly, as it is
> >>> already initialized to 0 by devm_kzalloc().
> >>> - Used of_property_read_string() instead of of_get_property().
> >>> - Fail immediately on DT parsing error in a child node, rather than
> >>> continuing on with the non-faulty ones.
> >>> - Added additional comments for some things that might be non-obvious.
> >>> - Added constants for the location of the SSD bit in the SHUTDOWN
> >>> register, and the 3216's CONFIG register.
> >>> - Added special sw_shutdown_func for the 3216 device, as that bit
> >>> is in a different register, at a different position, and has reverse
> >>> polarity compared to all the other devices.
> >>> - Refactored is31fl32xx_init_regs() to separate out some logic into
> >>> is31fl32xx_reset_regs() and is31fl32xx_software_shutdown().
> >>>
> >>> [1] https://lkml.org/lkml/2016/3/2/746
> >>>
> >>> drivers/leds/Kconfig | 8 +
> >>> drivers/leds/Makefile | 1 +
> >>> drivers/leds/leds-is31fl32xx.c | 505 
> >>> +
> >>> 3 files changed, 514 insertions(+)
> >>> create mode 100644 drivers/leds/leds-is31fl32xx.c
> >>>
> >>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> >>> index 1034696..9c63ba4 100644
> >>> --- a/drivers/leds/Kconfig
> >>> +++ b/drivers/leds/Kconfig
> >>> @@ -580,6 +580,14 @@ config 

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

[David Rivshin (Allworx)]

On Fri, 04 Mar 2016 16:38:01 +0100
Jacek Anaszewski  wrote:

> On 03/04/2016 03:27 PM, David Rivshin (Allworx) wrote:
> > (Stefan, sorry for the duplicate, I just realized that I originally
> > replied only to you by accident).
> >
> > On Thu, 3 Mar 2016 19:13:03 +0100 (CET)
> > Stefan Wahren  wrote:
> >  
> >> Hi David,
> >>
> >> i will test the driver on weekend. Some comments below  
> >
> > Great, thanks very much.
> >  
> >>> "David Rivshin (Allworx)"  hat am 3. März 
> >>> 2016 um
> >>> 04:01 geschrieben:
> >>>
> >>>
> >>> From: David Rivshin 
> >>>
> >>> The IS31FL32xx family of LED controllers are I2C devices with multiple
> >>> constant-current channels, each with independent 256-level PWM control.
> >>>
> >>> Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
> >>>
> >>> This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
> >>> (TI am335x) platform.
> >>>
> >>> The programming paradigm of these devices is similar in the following
> >>> ways:
> >>> - All registers are 8 bit
> >>> - All LED control registers are write-only
> >>> - Each LED channel has a PWM register (0-255)
> >>> - PWM register writes are shadowed until an Update register is poked
> >>> - All have a concept of Software Shutdown, which disables output
> >>>
> >>> However, there are some differences in devices:
> >>> - 3236/3235 have a separate Control register for each LED,
> >>> (3218/3216 pack the enable bits into fewer registers)
> >>> - 3236/3235 have a per-channel current divisor setting
> >>> - 3236/3235 have a Global Control register that can turn off all LEDs
> >>> - 3216 is unique in a number of ways
> >>> - OUT9-OUT16 can be configured as GPIOs instead of LED controls
> >>> - LEDs can be programmed with an 8-frame animation, with
> >>> programmable delay between frames
> >>> - LEDs can be modulated by an input audio signal
> >>> - Max output current can be adjusted from 1/4 to 2x globally
> >>> - Has a Configuration register instead of a Shutdown register
> >>>
> >>> This driver currently only supports the base PWM control function
> >>> of these devices. The following features of these devices are not
> >>> implemented, although it should be possible to add them in the future:
> >>> - All devices are capable of going into a lower-power "software
> >>> shutdown" mode.
> >>> - The is31fl3236 and is31fl3235 can reduce the max output current
> >>> per-channel with a divisor of 1, 2, 3, or 4.
> >>> - The is31fl3216 can use some LED channels as GPIOs instead.
> >>> - The is31fl3216 can animate LEDs in hardware.
> >>> - The is31fl3216 can modulate LEDs according to an audio input.
> >>> - The is31fl3216 can reduce/increase max output current globally.
> >>>
> >>> Signed-off-by: David Rivshin 
> >>> ---
> >>>
> >>> You may see two instances of this warning:
> >>> "passing argument 1 of 'of_property_read_string' discards 'const'
> >>> qualifier from pointer target type"
> >>> That is a result of of_property_read_string() taking a non-const
> >>> struct device_node pointer parameter. I have separately submitted a
> >>> patch to fix that [1], and a few related functions which had the same
> >>> issue. I'm hoping that will get into linux-next before this does, so
> >>> that the warnings never show up there.
> >>>
> >>> Changes from RFC:
> >>> - Removed max-brightness DT property.
> >>> - Refer to these devices as "LED controllers" in Kconfig.
> >>> - Removed redundant last sentence from Kconfig entry
> >>> - Removed unnecessary debug code.
> >>> - Do not set led_classdev.brightness to 0 explicitly, as it is
> >>> already initialized to 0 by devm_kzalloc().
> >>> - Used of_property_read_string() instead of of_get_property().
> >>> - Fail immediately on DT parsing error in a child node, rather than
> >>> continuing on with the non-faulty ones.
> >>> - Added additional comments for some things that might be non-obvious.
> >>> - Added constants for the location of the SSD bit in the SHUTDOWN
> >>> register, and the 3216's CONFIG register.
> >>> - Added special sw_shutdown_func for the 3216 device, as that bit
> >>> is in a different register, at a different position, and has reverse
> >>> polarity compared to all the other devices.
> >>> - Refactored is31fl32xx_init_regs() to separate out some logic into
> >>> is31fl32xx_reset_regs() and is31fl32xx_software_shutdown().
> >>>
> >>> [1] https://lkml.org/lkml/2016/3/2/746
> >>>
> >>> drivers/leds/Kconfig | 8 +
> >>> drivers/leds/Makefile | 1 +
> >>> drivers/leds/leds-is31fl32xx.c | 505 
> >>> +
> >>> 3 files changed, 514 insertions(+)
> >>> create mode 100644 drivers/leds/leds-is31fl32xx.c
> >>>
> >>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> >>> index 1034696..9c63ba4 100644
> >>> --- a/drivers/leds/Kconfig
> >>> +++ b/drivers/leds/Kconfig
> >>> @@ -580,6 +580,14 @@ config LEDS_SN3218
> >>> This driver can also be built as a module. If so the module
> >>> will be called leds-sn3218.
> >>>
> >>> +config 

[PATCH v2 net] net: hns: fix the bug about loopback

[Kejian Yan]

It will always be passed if the soc is tested the loopback cases. This
patch will fix this bug.

Signed-off-by: Kejian Yan 
---
change log:
PATCH v2:
 - This patch fixes the comments provided by Andy Shevchenko 

PATCH v1:
 - first submit

 Link: https://lkml.org/lkml/2016/3/3/266
---
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c  |  8 +
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 37 ++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |  1 +
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |  5 +++
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c   | 15 -
 5 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index a0070d0..d4f92ed 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -675,8 +675,12 @@ static int hns_ae_config_loopback(struct hnae_handle 
*handle,
 {
int ret;
struct hnae_vf_cb *vf_cb = hns_ae_get_vf_cb(handle);
+   struct hns_mac_cb *mac_cb = hns_get_mac_cb(handle);
 
switch (loop) {
+   case MAC_INTERNALLOOP_PHY:
+   ret = 0;
+   break;
case MAC_INTERNALLOOP_SERDES:
ret = hns_mac_config_sds_loopback(vf_cb->mac_cb, en);
break;
@@ -686,6 +690,10 @@ static int hns_ae_config_loopback(struct hnae_handle 
*handle,
default:
ret = -EINVAL;
}
+
+   if (!ret)
+   hns_dsaf_set_inner_lb(mac_cb->dsaf_dev, mac_cb->mac_id, en);
+
return ret;
 }
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 9439f04..38fc5be 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -230,6 +230,30 @@ static void hns_dsaf_mix_def_qid_cfg(struct dsaf_device 
*dsaf_dev)
}
 }
 
+static void hns_dsaf_inner_qid_cfg(struct dsaf_device *dsaf_dev)
+{
+   u16 max_q_per_vf, max_vfn;
+   u32 q_id, q_num_per_port;
+   u32 mac_id;
+
+   if (AE_IS_VER1(dsaf_dev->dsaf_ver))
+   return;
+
+   hns_rcb_get_queue_mode(dsaf_dev->dsaf_mode,
+  HNS_DSAF_COMM_SERVICE_NW_IDX,
+  _vfn, _q_per_vf);
+   q_num_per_port = max_vfn * max_q_per_vf;
+
+   for (mac_id = 0, q_id = 0; mac_id < DSAF_SERVICE_NW_NUM; mac_id++) {
+   dsaf_set_dev_field(dsaf_dev,
+  DSAFV2_SERDES_LBK_0_REG + 4 * mac_id,
+  DSAFV2_SERDES_LBK_QID_M,
+  DSAFV2_SERDES_LBK_QID_S,
+  q_id);
+   q_id += q_num_per_port;
+   }
+}
+
 /**
  * hns_dsaf_sw_port_type_cfg - cfg sw type
  * @dsaf_id: dsa fabric id
@@ -691,6 +715,16 @@ void hns_dsaf_set_promisc_mode(struct dsaf_device 
*dsaf_dev, u32 en)
dsaf_set_dev_bit(dsaf_dev, DSAF_CFG_0_REG, DSAF_CFG_MIX_MODE_S, !!en);
 }
 
+void hns_dsaf_set_inner_lb(struct dsaf_device *dsaf_dev, u32 mac_id, u32 en)
+{
+   if (AE_IS_VER1(dsaf_dev->dsaf_ver) ||
+   dsaf_dev->mac_cb[mac_id].mac_type == HNAE_PORT_DEBUG)
+   return;
+
+   dsaf_set_dev_bit(dsaf_dev, DSAFV2_SERDES_LBK_0_REG + 4 * mac_id,
+DSAFV2_SERDES_LBK_EN_B, !!en);
+}
+
 /**
  * hns_dsaf_tbl_stat_en - tbl
  * @dsaf_id: dsa fabric id
@@ -1022,6 +1056,9 @@ static void hns_dsaf_comm_init(struct dsaf_device 
*dsaf_dev)
/* set promisc def queue id */
hns_dsaf_mix_def_qid_cfg(dsaf_dev);
 
+   /* set inner loopback queue id */
+   hns_dsaf_inner_qid_cfg(dsaf_dev);
+
/* in non switch mode, set all port to access mode */
hns_dsaf_sw_port_type_cfg(dsaf_dev, DSAF_SW_PORT_TYPE_NON_VLAN);
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index 40205b9..5fea226 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -417,5 +417,6 @@ void hns_dsaf_get_strings(int stringset, u8 *data, int 
port);
 void hns_dsaf_get_regs(struct dsaf_device *ddev, u32 port, void *data);
 int hns_dsaf_get_regs_count(void);
 void hns_dsaf_set_promisc_mode(struct dsaf_device *dsaf_dev, u32 en);
+void hns_dsaf_set_inner_lb(struct dsaf_device *dsaf_dev, u32 mac_id, u32 en);
 
 #endif /* __HNS_DSAF_MAIN_H__ */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index f0c4f9b..60d695d 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -134,6 +134,7 @@
 #define DSAF_XGE_INT_STS_0_REG 0x1C0
 #define DSAF_PPE_INT_STS_0_REG 0x1E0
 #define 

[PATCH v2 net] net: hns: fix the bug about loopback

[Kejian Yan]

It will always be passed if the soc is tested the loopback cases. This
patch will fix this bug.

Signed-off-by: Kejian Yan 
---
change log:
PATCH v2:
 - This patch fixes the comments provided by Andy Shevchenko 

PATCH v1:
 - first submit

 Link: https://lkml.org/lkml/2016/3/3/266
---
 drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c  |  8 +
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 37 ++
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h |  1 +
 drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h  |  5 +++
 drivers/net/ethernet/hisilicon/hns/hns_ethtool.c   | 15 -
 5 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c 
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index a0070d0..d4f92ed 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -675,8 +675,12 @@ static int hns_ae_config_loopback(struct hnae_handle 
*handle,
 {
int ret;
struct hnae_vf_cb *vf_cb = hns_ae_get_vf_cb(handle);
+   struct hns_mac_cb *mac_cb = hns_get_mac_cb(handle);
 
switch (loop) {
+   case MAC_INTERNALLOOP_PHY:
+   ret = 0;
+   break;
case MAC_INTERNALLOOP_SERDES:
ret = hns_mac_config_sds_loopback(vf_cb->mac_cb, en);
break;
@@ -686,6 +690,10 @@ static int hns_ae_config_loopback(struct hnae_handle 
*handle,
default:
ret = -EINVAL;
}
+
+   if (!ret)
+   hns_dsaf_set_inner_lb(mac_cb->dsaf_dev, mac_cb->mac_id, en);
+
return ret;
 }
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 9439f04..38fc5be 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -230,6 +230,30 @@ static void hns_dsaf_mix_def_qid_cfg(struct dsaf_device 
*dsaf_dev)
}
 }
 
+static void hns_dsaf_inner_qid_cfg(struct dsaf_device *dsaf_dev)
+{
+   u16 max_q_per_vf, max_vfn;
+   u32 q_id, q_num_per_port;
+   u32 mac_id;
+
+   if (AE_IS_VER1(dsaf_dev->dsaf_ver))
+   return;
+
+   hns_rcb_get_queue_mode(dsaf_dev->dsaf_mode,
+  HNS_DSAF_COMM_SERVICE_NW_IDX,
+  _vfn, _q_per_vf);
+   q_num_per_port = max_vfn * max_q_per_vf;
+
+   for (mac_id = 0, q_id = 0; mac_id < DSAF_SERVICE_NW_NUM; mac_id++) {
+   dsaf_set_dev_field(dsaf_dev,
+  DSAFV2_SERDES_LBK_0_REG + 4 * mac_id,
+  DSAFV2_SERDES_LBK_QID_M,
+  DSAFV2_SERDES_LBK_QID_S,
+  q_id);
+   q_id += q_num_per_port;
+   }
+}
+
 /**
  * hns_dsaf_sw_port_type_cfg - cfg sw type
  * @dsaf_id: dsa fabric id
@@ -691,6 +715,16 @@ void hns_dsaf_set_promisc_mode(struct dsaf_device 
*dsaf_dev, u32 en)
dsaf_set_dev_bit(dsaf_dev, DSAF_CFG_0_REG, DSAF_CFG_MIX_MODE_S, !!en);
 }
 
+void hns_dsaf_set_inner_lb(struct dsaf_device *dsaf_dev, u32 mac_id, u32 en)
+{
+   if (AE_IS_VER1(dsaf_dev->dsaf_ver) ||
+   dsaf_dev->mac_cb[mac_id].mac_type == HNAE_PORT_DEBUG)
+   return;
+
+   dsaf_set_dev_bit(dsaf_dev, DSAFV2_SERDES_LBK_0_REG + 4 * mac_id,
+DSAFV2_SERDES_LBK_EN_B, !!en);
+}
+
 /**
  * hns_dsaf_tbl_stat_en - tbl
  * @dsaf_id: dsa fabric id
@@ -1022,6 +1056,9 @@ static void hns_dsaf_comm_init(struct dsaf_device 
*dsaf_dev)
/* set promisc def queue id */
hns_dsaf_mix_def_qid_cfg(dsaf_dev);
 
+   /* set inner loopback queue id */
+   hns_dsaf_inner_qid_cfg(dsaf_dev);
+
/* in non switch mode, set all port to access mode */
hns_dsaf_sw_port_type_cfg(dsaf_dev, DSAF_SW_PORT_TYPE_NON_VLAN);
 
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
index 40205b9..5fea226 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h
@@ -417,5 +417,6 @@ void hns_dsaf_get_strings(int stringset, u8 *data, int 
port);
 void hns_dsaf_get_regs(struct dsaf_device *ddev, u32 port, void *data);
 int hns_dsaf_get_regs_count(void);
 void hns_dsaf_set_promisc_mode(struct dsaf_device *dsaf_dev, u32 en);
+void hns_dsaf_set_inner_lb(struct dsaf_device *dsaf_dev, u32 mac_id, u32 en);
 
 #endif /* __HNS_DSAF_MAIN_H__ */
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h 
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
index f0c4f9b..60d695d 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_reg.h
@@ -134,6 +134,7 @@
 #define DSAF_XGE_INT_STS_0_REG 0x1C0
 #define DSAF_PPE_INT_STS_0_REG 0x1E0
 #define DSAF_ROCEE_INT_STS_0_REG   0x200

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

[David Rivshin (Allworx)]

On Thu, 03 Mar 2016 15:51:36 +0100
Jacek Anaszewski  wrote:

> Hi David,
> 
> I'll wait for Tested-by from Stefan before applying this patch.
> If Stefan will have managed to test your driver with his hardware
> by the end of this cycle, it will suffice for this patch to contain
> only leds-is31fl32xx extension part.
> 
> leds-sn3218 hasn't been merged to mainline yet, so I'd rather
> remove it when I get Tested-by from Stefan.
> 
> Otherwise, I will send leds-sn3218 to Linus, and this patch
> will be applied after being tested, during 4.7 cycle.

Since Stefan has given his Tested-by, do I understand correctly
that you would prefer to:
 - revert sn3218 patches 2 and 3 yourself
 - have me provide v2 patches that would apply ontop of that

If so, should I do as Rob suggests and fold the sn3216/3218 bits into 
the earlier patches, or leave it as a 4th patch? I'd probably prefer 
the former as being an easier workflow (less "rebase -i"ing).

And should I base off v4.5-rc6 at that point, or your for-next minus 
those patches? The only difference should be a 1-line offset in the 
vendor-prefixes.txt hunk. Either way is equally easy for me.

> 
> Thanks,
> Jacek Anaszewski
> 
> On 03/03/2016 04:01 AM, David Rivshin (Allworx) wrote:
> > From: David Rivshin 
> >
> > Si-En Technology was acquired by ISSI in 2011, and it appears that
> > the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
> > As the IS31FL32XX driver already handles the *3218 devices, there
> > is no longer a need for the dedicated SN3218 driver.
> >
> > Add the "sn,sn3218" and "sn,sn3216" compatible strings into the
> > IS31FL32XX driver and binding documentation, and remove the
> > leds-sn3218 driver.
> >
> > Datasheets:
> >  IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
> >  SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf
> >
> >  IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
> >  SN3216; http://www.si-en.com/uploadpdf/SN3216201152410148.pdf
> >
> > Signed-off-by: David Rivshin 
> > ---
> >
> > Note that the leds-sn3218 binding use a 0-based 'reg' property, while
> > the leds-is31fl32xx binding uses a 1-based 'reg' property. This seemed
> > to be the preferred binding based on [1]. Since leds-sn3216 has not been
> > in a released kernel, there is are no backwards-compatibility concerns.
> >
> > Changes from RFC:
> >   new
> >
> > [1] http://www.spinics.net/lists/linux-leds/msg05589.html
> >
> >   .../devicetree/bindings/leds/leds-is31fl32xx.txt   |   9 +-
> >   .../devicetree/bindings/leds/leds-sn3218.txt   |  41 ---
> >   drivers/leds/Kconfig   |  18 +-
> >   drivers/leds/Makefile  |   1 -
> >   drivers/leds/leds-is31fl32xx.c |   6 +-
> >   drivers/leds/leds-sn3218.c | 306 
> > -
> >   6 files changed, 14 insertions(+), 367 deletions(-)
> >   delete mode 100644 Documentation/devicetree/bindings/leds/leds-sn3218.txt
> >   delete mode 100644 drivers/leds/leds-sn3218.c
> >
> > diff --git a/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt 
> > b/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> > index 539df2e..c59eb1a 100644
> > --- a/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> > +++ b/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> > @@ -1,6 +1,6 @@
> > -Binding for ISSI IS31FL32xx LED Drivers
> > +Binding for ISSI IS31FL32xx and Si-En SN32xx LED Drivers
> >
> > -The IS31FL32xx family of LED drivers are I2C devices with multiple
> > +The IS31FL32xx/SN32xx family of LED drivers are I2C devices with multiple
> >   constant-current channels, each with independent 256-level PWM control.
> >   Each LED is represented as a sub-node of the device.
> >
> > @@ -10,6 +10,8 @@ Required properties:
> > issi,is31fl3235
> > issi,is31fl3218
> > issi,is31fl3216
> > +   si-en,sn3218
> > +   si-en,sn3216
> >   - reg: I2C slave address
> >   - address-cells : must be 1
> >   - size-cells : must be 0
> > @@ -45,5 +47,6 @@ leds: is31fl3236@3c {
> > };
> >   };
> >
> > -For more product information please see the link below:
> > +For more product information please see the links below:
> >   http://www.issi.com/US/product-analog-fxled-driver.shtml
> > +http://www.si-en.com/product.asp?parentid=890
> > diff --git a/Documentation/devicetree/bindings/leds/leds-sn3218.txt 
> > b/Documentation/devicetree/bindings/leds/leds-sn3218.txt
> > deleted file mode 100644
> > index 19cbf57..000
> > --- a/Documentation/devicetree/bindings/leds/leds-sn3218.txt
> > +++ /dev/null
> > @@ -1,41 +0,0 @@
> > -* Si-En Technology - SN3218 18-Channel LED Driver
> > -
> > -Required properties:
> > -- compatible :
> > -   "si-en,sn3218"
> > -- address-cells : must be 1
> > -- size-cells : must be 0
> > -- reg : I2C slave address, typically 0x54
> > -
> > -There must be at 

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

[David Rivshin (Allworx)]

On Thu, 03 Mar 2016 15:51:36 +0100
Jacek Anaszewski  wrote:

> Hi David,
> 
> I'll wait for Tested-by from Stefan before applying this patch.
> If Stefan will have managed to test your driver with his hardware
> by the end of this cycle, it will suffice for this patch to contain
> only leds-is31fl32xx extension part.
> 
> leds-sn3218 hasn't been merged to mainline yet, so I'd rather
> remove it when I get Tested-by from Stefan.
> 
> Otherwise, I will send leds-sn3218 to Linus, and this patch
> will be applied after being tested, during 4.7 cycle.

Since Stefan has given his Tested-by, do I understand correctly
that you would prefer to:
 - revert sn3218 patches 2 and 3 yourself
 - have me provide v2 patches that would apply ontop of that

If so, should I do as Rob suggests and fold the sn3216/3218 bits into 
the earlier patches, or leave it as a 4th patch? I'd probably prefer 
the former as being an easier workflow (less "rebase -i"ing).

And should I base off v4.5-rc6 at that point, or your for-next minus 
those patches? The only difference should be a 1-line offset in the 
vendor-prefixes.txt hunk. Either way is equally easy for me.

> 
> Thanks,
> Jacek Anaszewski
> 
> On 03/03/2016 04:01 AM, David Rivshin (Allworx) wrote:
> > From: David Rivshin 
> >
> > Si-En Technology was acquired by ISSI in 2011, and it appears that
> > the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
> > As the IS31FL32XX driver already handles the *3218 devices, there
> > is no longer a need for the dedicated SN3218 driver.
> >
> > Add the "sn,sn3218" and "sn,sn3216" compatible strings into the
> > IS31FL32XX driver and binding documentation, and remove the
> > leds-sn3218 driver.
> >
> > Datasheets:
> >  IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
> >  SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf
> >
> >  IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
> >  SN3216; http://www.si-en.com/uploadpdf/SN3216201152410148.pdf
> >
> > Signed-off-by: David Rivshin 
> > ---
> >
> > Note that the leds-sn3218 binding use a 0-based 'reg' property, while
> > the leds-is31fl32xx binding uses a 1-based 'reg' property. This seemed
> > to be the preferred binding based on [1]. Since leds-sn3216 has not been
> > in a released kernel, there is are no backwards-compatibility concerns.
> >
> > Changes from RFC:
> >   new
> >
> > [1] http://www.spinics.net/lists/linux-leds/msg05589.html
> >
> >   .../devicetree/bindings/leds/leds-is31fl32xx.txt   |   9 +-
> >   .../devicetree/bindings/leds/leds-sn3218.txt   |  41 ---
> >   drivers/leds/Kconfig   |  18 +-
> >   drivers/leds/Makefile  |   1 -
> >   drivers/leds/leds-is31fl32xx.c |   6 +-
> >   drivers/leds/leds-sn3218.c | 306 
> > -
> >   6 files changed, 14 insertions(+), 367 deletions(-)
> >   delete mode 100644 Documentation/devicetree/bindings/leds/leds-sn3218.txt
> >   delete mode 100644 drivers/leds/leds-sn3218.c
> >
> > diff --git a/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt 
> > b/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> > index 539df2e..c59eb1a 100644
> > --- a/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> > +++ b/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> > @@ -1,6 +1,6 @@
> > -Binding for ISSI IS31FL32xx LED Drivers
> > +Binding for ISSI IS31FL32xx and Si-En SN32xx LED Drivers
> >
> > -The IS31FL32xx family of LED drivers are I2C devices with multiple
> > +The IS31FL32xx/SN32xx family of LED drivers are I2C devices with multiple
> >   constant-current channels, each with independent 256-level PWM control.
> >   Each LED is represented as a sub-node of the device.
> >
> > @@ -10,6 +10,8 @@ Required properties:
> > issi,is31fl3235
> > issi,is31fl3218
> > issi,is31fl3216
> > +   si-en,sn3218
> > +   si-en,sn3216
> >   - reg: I2C slave address
> >   - address-cells : must be 1
> >   - size-cells : must be 0
> > @@ -45,5 +47,6 @@ leds: is31fl3236@3c {
> > };
> >   };
> >
> > -For more product information please see the link below:
> > +For more product information please see the links below:
> >   http://www.issi.com/US/product-analog-fxled-driver.shtml
> > +http://www.si-en.com/product.asp?parentid=890
> > diff --git a/Documentation/devicetree/bindings/leds/leds-sn3218.txt 
> > b/Documentation/devicetree/bindings/leds/leds-sn3218.txt
> > deleted file mode 100644
> > index 19cbf57..000
> > --- a/Documentation/devicetree/bindings/leds/leds-sn3218.txt
> > +++ /dev/null
> > @@ -1,41 +0,0 @@
> > -* Si-En Technology - SN3218 18-Channel LED Driver
> > -
> > -Required properties:
> > -- compatible :
> > -   "si-en,sn3218"
> > -- address-cells : must be 1
> > -- size-cells : must be 0
> > -- reg : I2C slave address, typically 0x54
> > -
> > -There must be at least 1 LED which is represented as a sub-node
> > -of the sn3218 device.

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

[David Rivshin (Allworx)]

On Fri, 4 Mar 2016 22:39:06 +0100
Jacek Anaszewski  wrote:

> On 03/04/2016 08:02 PM, David Rivshin (Allworx) wrote:
> > On Fri, 04 Mar 2016 17:01:52 +0100
> > Jacek Anaszewski  wrote:
> >  
> >> On 03/04/2016 04:05 PM, David Rivshin (Allworx) wrote:  
> >>> On Fri, 04 Mar 2016 08:54:02 +0100
> >>> Jacek Anaszewski  wrote:
> >>>  
>  On 03/04/2016 01:45 AM, David Rivshin (Allworx) wrote:  
> > On Thu, 03 Mar 2016 15:51:32 +0100
> > Jacek Anaszewski  wrote:
> >  
> >> Hi David,
> >>
> >> Thanks for the update. Two remarks in the code.
> >>
> >> On 03/03/2016 04:01 AM, David Rivshin (Allworx) wrote:  
> >>> From: David Rivshin 
> >>>
> >>> The IS31FL32xx family of LED controllers are I2C devices with multiple
> >>> constant-current channels, each with independent 256-level PWM 
> >>> control.
> >>>
> >>> Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
> >>>
> >>> This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
> >>> (TI am335x) platform.
> >>>
> >>> The programming paradigm of these devices is similar in the following
> >>> ways:
> >>>  - All registers are 8 bit
> >>>  - All LED control registers are write-only
> >>>  - Each LED channel has a PWM register (0-255)
> >>>  - PWM register writes are shadowed until an Update register is 
> >>> poked
> >>>  - All have a concept of Software Shutdown, which disables output
> >>>
> >>> However, there are some differences in devices:
> >>>  - 3236/3235 have a separate Control register for each LED,
> >>>(3218/3216 pack the enable bits into fewer registers)
> >>>  - 3236/3235 have a per-channel current divisor setting
> >>>  - 3236/3235 have a Global Control register that can turn off all 
> >>> LEDs
> >>>  - 3216 is unique in a number of ways
> >>> - OUT9-OUT16 can be configured as GPIOs instead of LED 
> >>> controls
> >>> - LEDs can be programmed with an 8-frame animation, with
> >>>   programmable delay between frames
> >>> - LEDs can be modulated by an input audio signal
> >>> - Max output current can be adjusted from 1/4 to 2x globally
> >>> - Has a Configuration register instead of a Shutdown register
> >>>
> >>> This driver currently only supports the base PWM control function
> >>> of these devices. The following features of these devices are not
> >>> implemented, although it should be possible to add them in the future:
> >>>  - All devices are capable of going into a lower-power "software
> >>>shutdown" mode.
> >>>  - The is31fl3236 and is31fl3235 can reduce the max output current
> >>>per-channel with a divisor of 1, 2, 3, or 4.
> >>>  - The is31fl3216 can use some LED channels as GPIOs instead.
> >>>  - The is31fl3216 can animate LEDs in hardware.
> >>>  - The is31fl3216 can modulate LEDs according to an audio input.
> >>>  - The is31fl3216 can reduce/increase max output current globally.
> >>>
> >>> Signed-off-by: David Rivshin 
> >>> ---
> >>>
> >>> You may see two instances of this warning:
> >>>   "passing argument 1 of 'of_property_read_string' discards 
> >>> 'const'
> >>>qualifier from pointer target type"
> >>> That is a result of of_property_read_string() taking a non-const
> >>> struct device_node pointer parameter. I have separately submitted a
> >>> patch to fix that [1], and a few related functions which had the same
> >>> issue. I'm hoping that will get into linux-next before this does, so
> >>> that the warnings never show up there.  
> >>
> >> Please adjust the patch so that it compiles without warnings on
> >> current linux-next. Your patch for DT API hasn't been reviewed yet
> >> AFICS, and I can imagine that there will be some resistance against.  
> >
> > Since the DT API patch was just accepted by Rob [1], would it be OK
> > to wait for the results of Stefan's testing (and any other reviews)
> > before making a decision on this? From Stefan's note, it won't be
> > until this weekend that he will have a chance to test, and I'm
> > guessing the DT API patch will make its way through Rob's tree to
> > linux-next by then.  
> 
>  OK.
>   
> > FYI, the warning workaround would be to make the second parameter to
> > is31fl32xx_parse_child_dt() non-const.
> >
> > [1] https://lkml.org/lkml/2016/3/3/924
> >  
> >>> Changes from RFC:
> >>>  - Removed max-brightness DT property.
> >>>  - Refer to these devices as "LED controllers" in Kconfig.
> >>>  

Re: [PATCH 3/4] leds: Add driver for the ISSI IS31FL32xx family of LED controllers

[David Rivshin (Allworx)]

On Fri, 4 Mar 2016 22:39:06 +0100
Jacek Anaszewski  wrote:

> On 03/04/2016 08:02 PM, David Rivshin (Allworx) wrote:
> > On Fri, 04 Mar 2016 17:01:52 +0100
> > Jacek Anaszewski  wrote:
> >  
> >> On 03/04/2016 04:05 PM, David Rivshin (Allworx) wrote:  
> >>> On Fri, 04 Mar 2016 08:54:02 +0100
> >>> Jacek Anaszewski  wrote:
> >>>  
>  On 03/04/2016 01:45 AM, David Rivshin (Allworx) wrote:  
> > On Thu, 03 Mar 2016 15:51:32 +0100
> > Jacek Anaszewski  wrote:
> >  
> >> Hi David,
> >>
> >> Thanks for the update. Two remarks in the code.
> >>
> >> On 03/03/2016 04:01 AM, David Rivshin (Allworx) wrote:  
> >>> From: David Rivshin 
> >>>
> >>> The IS31FL32xx family of LED controllers are I2C devices with multiple
> >>> constant-current channels, each with independent 256-level PWM 
> >>> control.
> >>>
> >>> Datasheets: http://www.issi.com/US/product-analog-fxled-driver.shtml
> >>>
> >>> This has been tested on the IS31FL3236 and IS31FL3216, on an ARM
> >>> (TI am335x) platform.
> >>>
> >>> The programming paradigm of these devices is similar in the following
> >>> ways:
> >>>  - All registers are 8 bit
> >>>  - All LED control registers are write-only
> >>>  - Each LED channel has a PWM register (0-255)
> >>>  - PWM register writes are shadowed until an Update register is 
> >>> poked
> >>>  - All have a concept of Software Shutdown, which disables output
> >>>
> >>> However, there are some differences in devices:
> >>>  - 3236/3235 have a separate Control register for each LED,
> >>>(3218/3216 pack the enable bits into fewer registers)
> >>>  - 3236/3235 have a per-channel current divisor setting
> >>>  - 3236/3235 have a Global Control register that can turn off all 
> >>> LEDs
> >>>  - 3216 is unique in a number of ways
> >>> - OUT9-OUT16 can be configured as GPIOs instead of LED 
> >>> controls
> >>> - LEDs can be programmed with an 8-frame animation, with
> >>>   programmable delay between frames
> >>> - LEDs can be modulated by an input audio signal
> >>> - Max output current can be adjusted from 1/4 to 2x globally
> >>> - Has a Configuration register instead of a Shutdown register
> >>>
> >>> This driver currently only supports the base PWM control function
> >>> of these devices. The following features of these devices are not
> >>> implemented, although it should be possible to add them in the future:
> >>>  - All devices are capable of going into a lower-power "software
> >>>shutdown" mode.
> >>>  - The is31fl3236 and is31fl3235 can reduce the max output current
> >>>per-channel with a divisor of 1, 2, 3, or 4.
> >>>  - The is31fl3216 can use some LED channels as GPIOs instead.
> >>>  - The is31fl3216 can animate LEDs in hardware.
> >>>  - The is31fl3216 can modulate LEDs according to an audio input.
> >>>  - The is31fl3216 can reduce/increase max output current globally.
> >>>
> >>> Signed-off-by: David Rivshin 
> >>> ---
> >>>
> >>> You may see two instances of this warning:
> >>>   "passing argument 1 of 'of_property_read_string' discards 
> >>> 'const'
> >>>qualifier from pointer target type"
> >>> That is a result of of_property_read_string() taking a non-const
> >>> struct device_node pointer parameter. I have separately submitted a
> >>> patch to fix that [1], and a few related functions which had the same
> >>> issue. I'm hoping that will get into linux-next before this does, so
> >>> that the warnings never show up there.  
> >>
> >> Please adjust the patch so that it compiles without warnings on
> >> current linux-next. Your patch for DT API hasn't been reviewed yet
> >> AFICS, and I can imagine that there will be some resistance against.  
> >
> > Since the DT API patch was just accepted by Rob [1], would it be OK
> > to wait for the results of Stefan's testing (and any other reviews)
> > before making a decision on this? From Stefan's note, it won't be
> > until this weekend that he will have a chance to test, and I'm
> > guessing the DT API patch will make its way through Rob's tree to
> > linux-next by then.  
> 
>  OK.
>   
> > FYI, the warning workaround would be to make the second parameter to
> > is31fl32xx_parse_child_dt() non-const.
> >
> > [1] https://lkml.org/lkml/2016/3/3/924
> >  
> >>> Changes from RFC:
> >>>  - Removed max-brightness DT property.
> >>>  - Refer to these devices as "LED controllers" in Kconfig.
> >>>  - Removed redundant last sentence from Kconfig entry
> >>>  - Removed unnecessary debug code.
> >>>  - Do not set 

Re: [9/9] powerpc: optimise csum_partial() call when len is constant

[Scott Wood]

On Tue, Sep 22, 2015 at 04:34:36PM +0200, Christophe Leroy wrote:
> +/*
> + * computes the checksum of a memory block at buff, length len,
> + * and adds in "sum" (32-bit)
> + *
> + * returns a 32-bit number suitable for feeding into itself
> + * or csum_tcpudp_magic
> + *
> + * this function must be called with even lengths, except
> + * for the last fragment, which may be odd
> + *
> + * it's best to have buff aligned on a 32-bit boundary
> + */
> +__wsum __csum_partial(const void *buff, int len, __wsum sum);
> +
> +static inline __wsum csum_partial(const void *buff, int len, __wsum sum)
> +{
> + if (__builtin_constant_p(len) && len == 0)
> + return sum;
> +
> + if (__builtin_constant_p(len) && len <= 16 && (len & 1) == 0) {
> + __wsum sum1;
> +
> + if (len == 2)
> + sum1 = (__force u32)*(u16 *)buff;
> + if (len >= 4)
> + sum1 = *(u32 *)buff;
> + if (len == 6)
> + sum1 = csum_add(sum1, (__force u32)*(u16 *)(buff + 4));
> + if (len >= 8)
> + sum1 = csum_add(sum1, *(u32 *)(buff + 4));
> + if (len == 10)
> + sum1 = csum_add(sum1, (__force u32)*(u16 *)(buff + 8));
> + if (len >= 12)
> + sum1 = csum_add(sum1, *(u32 *)(buff + 8));
> + if (len == 14)
> + sum1 = csum_add(sum1, (__force u32)*(u16 *)(buff + 12));
> + if (len >= 16)
> + sum1 = csum_add(sum1, *(u32 *)(buff + 12));
> +
> + sum = csum_add(sum1, sum);

Why the final csum_add instead of s/sum1/sum/ and putting csum_add in the
"len == 2" and "len >= 4" cases?

The (__force u32) casts are unnecessary.  Or rather, it should be
(__force __wsum) -- on all of them, not just the 16-bit ones.

The pointer casts should be const.

> + } else if (__builtin_constant_p(len) && (len & 3) == 0) {
> + sum = csum_add(ip_fast_csum_nofold(buff, len >> 2), sum);

It may not make a functional difference, but based on the csum_add()
argument names and other csum_add() usage, sum should come first
and the new content second.

-Scott

Re: [9/9] powerpc: optimise csum_partial() call when len is constant

[Scott Wood]

On Tue, Sep 22, 2015 at 04:34:36PM +0200, Christophe Leroy wrote:
> +/*
> + * computes the checksum of a memory block at buff, length len,
> + * and adds in "sum" (32-bit)
> + *
> + * returns a 32-bit number suitable for feeding into itself
> + * or csum_tcpudp_magic
> + *
> + * this function must be called with even lengths, except
> + * for the last fragment, which may be odd
> + *
> + * it's best to have buff aligned on a 32-bit boundary
> + */
> +__wsum __csum_partial(const void *buff, int len, __wsum sum);
> +
> +static inline __wsum csum_partial(const void *buff, int len, __wsum sum)
> +{
> + if (__builtin_constant_p(len) && len == 0)
> + return sum;
> +
> + if (__builtin_constant_p(len) && len <= 16 && (len & 1) == 0) {
> + __wsum sum1;
> +
> + if (len == 2)
> + sum1 = (__force u32)*(u16 *)buff;
> + if (len >= 4)
> + sum1 = *(u32 *)buff;
> + if (len == 6)
> + sum1 = csum_add(sum1, (__force u32)*(u16 *)(buff + 4));
> + if (len >= 8)
> + sum1 = csum_add(sum1, *(u32 *)(buff + 4));
> + if (len == 10)
> + sum1 = csum_add(sum1, (__force u32)*(u16 *)(buff + 8));
> + if (len >= 12)
> + sum1 = csum_add(sum1, *(u32 *)(buff + 8));
> + if (len == 14)
> + sum1 = csum_add(sum1, (__force u32)*(u16 *)(buff + 12));
> + if (len >= 16)
> + sum1 = csum_add(sum1, *(u32 *)(buff + 12));
> +
> + sum = csum_add(sum1, sum);

Why the final csum_add instead of s/sum1/sum/ and putting csum_add in the
"len == 2" and "len >= 4" cases?

The (__force u32) casts are unnecessary.  Or rather, it should be
(__force __wsum) -- on all of them, not just the 16-bit ones.

The pointer casts should be const.

> + } else if (__builtin_constant_p(len) && (len & 3) == 0) {
> + sum = csum_add(ip_fast_csum_nofold(buff, len >> 2), sum);

It may not make a functional difference, but based on the csum_add()
argument names and other csum_add() usage, sum should come first
and the new content second.

-Scott

[PATCH] checkpatch: Warn on bare unsigned or signed declarations without int

[Joe Perches]

Kernel style prefers "unsigned int " over "unsigned "
and "signed int " over "signed ".

Emit a warning for these simple signed/unsigned  declarations.
Fix it too if desired.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 20 
 1 file changed, 20 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 874132b..c48b658 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3240,6 +3240,26 @@ sub process {
 #ignore lines not being added
next if ($line =~ /^[^\+]/);
 
+# check for declarations of signed or unsigned without int
+   while ($line =~ m{($Declare++)\s*($Ident)\s*[=,;\[\)]}g) {
+   my $type = $1;
+   my $var = $2;
+   if ($type =~ /^((?:un)?signed)((?:\s*\*)*)\s*$/) {
+   my $sign = $1;
+   my $pointer = $2;
+
+   $pointer = "" if (!defined $pointer);
+
+   if (WARN("UNSPECIFIED_INT",
+"Prefer '" . trim($sign) . " int" . 
rtrim($pointer) . "' to bare use of '$sign" . rtrim($pointer) . "'\n" . 
$herecurr) &&
+   $fix) {
+   my $decl = trim($sign) . " int ";
+   $decl .= trim($pointer) if 
(rtrim($pointer) ne "");
+   $fixed[$fixlinenr] =~ 
s@\b\Q$type\E\s*$var\b@$decl$var@;
+   }
+   }
+   }
+
 # TEST: allow direct testing of the type matcher.
if ($dbg_type) {
if ($line =~ /^.\s*$Declare\s*$/) {
-- 
2.6.3.368.gf34be46

[PATCH] checkpatch: Warn on bare unsigned or signed declarations without int

[Joe Perches]

Kernel style prefers "unsigned int " over "unsigned "
and "signed int " over "signed ".

Emit a warning for these simple signed/unsigned  declarations.
Fix it too if desired.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 20 
 1 file changed, 20 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 874132b..c48b658 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3240,6 +3240,26 @@ sub process {
 #ignore lines not being added
next if ($line =~ /^[^\+]/);
 
+# check for declarations of signed or unsigned without int
+   while ($line =~ m{($Declare++)\s*($Ident)\s*[=,;\[\)]}g) {
+   my $type = $1;
+   my $var = $2;
+   if ($type =~ /^((?:un)?signed)((?:\s*\*)*)\s*$/) {
+   my $sign = $1;
+   my $pointer = $2;
+
+   $pointer = "" if (!defined $pointer);
+
+   if (WARN("UNSPECIFIED_INT",
+"Prefer '" . trim($sign) . " int" . 
rtrim($pointer) . "' to bare use of '$sign" . rtrim($pointer) . "'\n" . 
$herecurr) &&
+   $fix) {
+   my $decl = trim($sign) . " int ";
+   $decl .= trim($pointer) if 
(rtrim($pointer) ne "");
+   $fixed[$fixlinenr] =~ 
s@\b\Q$type\E\s*$var\b@$decl$var@;
+   }
+   }
+   }
+
 # TEST: allow direct testing of the type matcher.
if ($dbg_type) {
if ($line =~ /^.\s*$Declare\s*$/) {
-- 
2.6.3.368.gf34be46

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

[David Rivshin (Allworx)]

On Fri, 4 Mar 2016 22:14:27 +0100 (CET)
Stefan Wahren  wrote:

> Hi David,
> 
> > "David Rivshin (Allworx)"  hat am 3. März 2016 
> > um
> > 04:01 geschrieben:
> >
> >
> > From: David Rivshin 
> >
> > Si-En Technology was acquired by ISSI in 2011, and it appears that
> > the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
> > As the IS31FL32XX driver already handles the *3218 devices, there
> > is no longer a need for the dedicated SN3218 driver.
> >
> > Add the "sn,sn3218" and "sn,sn3216" compatible strings into the
> > IS31FL32XX driver and binding documentation, and remove the
> > leds-sn3218 driver.
> >
> > Datasheets:
> > IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
> > SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf
> >
> > IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
> > SN3216; http://www.si-en.com/uploadpdf/SN3216201152410148.pdf
> >
> > Signed-off-by: David Rivshin   
> 
> i tested this patch successfully with a Raspberry Pi and a PiGlow (SN3218).
> 
> Tested-by: Stefan Wahren 

Thanks very much for testing!

The PiGlow looks interesting, if I had known about it I might have just
ordered one for testing myself. Looks rather easier to hook up than the 
ISSI 3216 eval board.

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

[David Rivshin (Allworx)]

On Fri, 4 Mar 2016 22:14:27 +0100 (CET)
Stefan Wahren  wrote:

> Hi David,
> 
> > "David Rivshin (Allworx)"  hat am 3. März 2016 
> > um
> > 04:01 geschrieben:
> >
> >
> > From: David Rivshin 
> >
> > Si-En Technology was acquired by ISSI in 2011, and it appears that
> > the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
> > As the IS31FL32XX driver already handles the *3218 devices, there
> > is no longer a need for the dedicated SN3218 driver.
> >
> > Add the "sn,sn3218" and "sn,sn3216" compatible strings into the
> > IS31FL32XX driver and binding documentation, and remove the
> > leds-sn3218 driver.
> >
> > Datasheets:
> > IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
> > SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf
> >
> > IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
> > SN3216; http://www.si-en.com/uploadpdf/SN3216201152410148.pdf
> >
> > Signed-off-by: David Rivshin   
> 
> i tested this patch successfully with a Raspberry Pi and a PiGlow (SN3218).
> 
> Tested-by: Stefan Wahren 

Thanks very much for testing!

The PiGlow looks interesting, if I had known about it I might have just
ordered one for testing myself. Looks rather easier to hook up than the 
ISSI 3216 eval board.

Re: [RESPIN 5/6] dt-bindings: EXYNOS: Describe SROMc configuration

[pankaj.dubey]

Hi,

On Wednesday 02 March 2016 11:27 PM, Rob Herring wrote:
> On Thu, Feb 25, 2016 at 02:03:41PM +0530, Pankaj Dubey wrote:
>> From: Pavel Fedin 
>>
>> Add documentation for new subnode properties, allowing bank configuration.
>> Based on u-boot implementation, but heavily reworked.
>>
>> Also, fix size of SROMc mapping in the example.
> 
> Fix it in the previous patch.

OK.

> 
>> CC: devicet...@vger.kernel.org
>> Signed-off-by: Pavel Fedin 
>> Signed-off-by: Pankaj Dubey 
>> Reviewed-by: Krzysztof Kozlowski 
>> Acked-by: Rob Herring 
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  .../bindings/memory-controllers/exynos-srom.txt| 73 
>> +-
>>  1 file changed, 71 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt 
>> b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> index 33886d5..e5c18df 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> @@ -5,8 +5,77 @@ Required properties:
>>  
>>  - reg: offset and length of the register set
>>  
>> -Example:
>> +Optional properties:
>> +The SROM controller can be used to attach external peripherals. In this case
>> +extra properties, describing the bus behind it, should be specified as 
>> below:
>> +
>> +- #address-cells: Must be set to 2 to allow device address translation.
>> +  Address is specified as (bank#, offset).
>> +
>> +- #size-cells: Must be set to 1 to allow device size passing
>> +
>> +- ranges: Must be set up to reflect the memory layout with four integer 
>> values
>> +  per bank:
>> + 0  
>> +
>> +Sub-nodes:
>> +The actual device nodes should be added as subnodes to the SROMc node. These
>> +subnodes, except regular device specification, should contain the following
> 
> s/except/in addition to/
> 

OK. Will update this description as suggested.

>> +properties, describing configuration of the relevant SROM bank:
>> +
>> +Required properties:
>> +- reg: bank number, base address (relative to start of the bank) and size of
>> +   the memory mapped for the device. Note that base address will be
>> +   typically 0 as this is the start of the bank.
>> +
>> +- samsung,srom-timing : array of 6 integers, specifying bank timings in the
>> +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
>> +Each value is specified in cycles and has the 
>> following
>> +meaning and valid range:
>> +Tacp : Page mode access cycle at Page mode (0 - 15)
>> +Tcah : Address holding time after CSn (0 - 15)
>> +Tcoh : Chip selection hold on OEn (0 - 15)
>> +Tacc : Access cycle (0 - 31, the actual time is N + 
>> 1)
>> +Tcos : Chip selection set-up before OEn (0 - 15)
>> +Tacs : Address set-up before CSn (0 - 15)
>> +
>> +Optional properties:
>> +- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is 
>> used.
>> +
>> +- samsung,srom-page-mode : page mode configuration for the bank:
>> +   0 - normal (one data)
>> +   1 - four data
>> +   If omitted, default of 0 is used.
> 
> Make this a bool instead.
> 

I do not have strong objections to change this, but I can see doing so
will increase two or three lines in driver, as such this property is not
being used as bool in driver.


Sorry to say this but I do not understand why these comments are coming
now? Whereas you had given your "Acked-by" to the same patch when it was
posted previously by Pavel and we were keeping this driver under
"drivers/soc/samsung". Is it just because we are moving to
"drivers/memory" and it needs to be consistent with other memory
controller drivers?

Thanks,
Pankaj Dubey
> Rob
> 
> 

Re: [RESPIN 5/6] dt-bindings: EXYNOS: Describe SROMc configuration

[pankaj.dubey]

Hi,

On Wednesday 02 March 2016 11:27 PM, Rob Herring wrote:
> On Thu, Feb 25, 2016 at 02:03:41PM +0530, Pankaj Dubey wrote:
>> From: Pavel Fedin 
>>
>> Add documentation for new subnode properties, allowing bank configuration.
>> Based on u-boot implementation, but heavily reworked.
>>
>> Also, fix size of SROMc mapping in the example.
> 
> Fix it in the previous patch.

OK.

> 
>> CC: devicet...@vger.kernel.org
>> Signed-off-by: Pavel Fedin 
>> Signed-off-by: Pankaj Dubey 
>> Reviewed-by: Krzysztof Kozlowski 
>> Acked-by: Rob Herring 
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  .../bindings/memory-controllers/exynos-srom.txt| 73 
>> +-
>>  1 file changed, 71 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt 
>> b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> index 33886d5..e5c18df 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> @@ -5,8 +5,77 @@ Required properties:
>>  
>>  - reg: offset and length of the register set
>>  
>> -Example:
>> +Optional properties:
>> +The SROM controller can be used to attach external peripherals. In this case
>> +extra properties, describing the bus behind it, should be specified as 
>> below:
>> +
>> +- #address-cells: Must be set to 2 to allow device address translation.
>> +  Address is specified as (bank#, offset).
>> +
>> +- #size-cells: Must be set to 1 to allow device size passing
>> +
>> +- ranges: Must be set up to reflect the memory layout with four integer 
>> values
>> +  per bank:
>> + 0  
>> +
>> +Sub-nodes:
>> +The actual device nodes should be added as subnodes to the SROMc node. These
>> +subnodes, except regular device specification, should contain the following
> 
> s/except/in addition to/
> 

OK. Will update this description as suggested.

>> +properties, describing configuration of the relevant SROM bank:
>> +
>> +Required properties:
>> +- reg: bank number, base address (relative to start of the bank) and size of
>> +   the memory mapped for the device. Note that base address will be
>> +   typically 0 as this is the start of the bank.
>> +
>> +- samsung,srom-timing : array of 6 integers, specifying bank timings in the
>> +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
>> +Each value is specified in cycles and has the 
>> following
>> +meaning and valid range:
>> +Tacp : Page mode access cycle at Page mode (0 - 15)
>> +Tcah : Address holding time after CSn (0 - 15)
>> +Tcoh : Chip selection hold on OEn (0 - 15)
>> +Tacc : Access cycle (0 - 31, the actual time is N + 
>> 1)
>> +Tcos : Chip selection set-up before OEn (0 - 15)
>> +Tacs : Address set-up before CSn (0 - 15)
>> +
>> +Optional properties:
>> +- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is 
>> used.
>> +
>> +- samsung,srom-page-mode : page mode configuration for the bank:
>> +   0 - normal (one data)
>> +   1 - four data
>> +   If omitted, default of 0 is used.
> 
> Make this a bool instead.
> 

I do not have strong objections to change this, but I can see doing so
will increase two or three lines in driver, as such this property is not
being used as bool in driver.


Sorry to say this but I do not understand why these comments are coming
now? Whereas you had given your "Acked-by" to the same patch when it was
posted previously by Pavel and we were keeping this driver under
"drivers/soc/samsung". Is it just because we are moving to
"drivers/memory" and it needs to be consistent with other memory
controller drivers?

Thanks,
Pankaj Dubey
> Rob
> 
> 

Re: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding

[pankaj.dubey]

Hi,

On Wednesday 02 March 2016 11:23 PM, Rob Herring wrote:
> On Thu, Feb 25, 2016 at 02:03:37PM +0530, Pankaj Dubey wrote:
>> This patch adds exynos-srom binding information for SROM Controller
>> driver on Exynos SoCs.
>>
>> CC: Rob Herring 
>> CC: Mark Rutland 
>> CC: Ian Campbell 
>> CC: devicet...@vger.kernel.org
>> Signed-off-by: Pankaj Dubey 
>> Reviewed-by: Krzysztof Kozlowski 
>> Signed-off-by: Kukjin Kim 
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  .../devicetree/bindings/memory-controllers/exynos-srom.txt   | 12 
>> 
>>  1 file changed, 12 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt 
>> b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> new file mode 100644
>> index 000..33886d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> @@ -0,0 +1,12 @@
>> +SAMSUNG Exynos SoCs SROM Controller driver.
>> +
>> +Required properties:
>> +- compatible : Should contain "samsung,exynos-srom".
> 
> There should be SoC specific compatible strings in addition to this.
> 

I do not understood need to additional need to SoC specific compatible,
as of now all SoCs having SROM can work with exynos specific common
compatible. Will you see any issues in this?

>> +
>> +- reg: offset and length of the register set
>> +
>> +Example:
>> +sromc@1257 {
> 
> This should be memory-controller@...
> 
>> +compatible = "samsung,exynos-srom";
>> +reg = <0x1257 0x10>;
> 
> The next patch changes the size to 0x14?
> 
> BTW, you could just combine both patches. I guess you didn't to maintain 
> authorship?

OK. Will squash both of these patches, unless Pavel do not any objections.

Thanks,
Pankaj Dubey
> 
> Rob
> 
> 

Re: [RESPIN 1/6] dt-bindings: EXYNOS: Add exynos-srom device tree binding

[pankaj.dubey]

Hi,

On Wednesday 02 March 2016 11:23 PM, Rob Herring wrote:
> On Thu, Feb 25, 2016 at 02:03:37PM +0530, Pankaj Dubey wrote:
>> This patch adds exynos-srom binding information for SROM Controller
>> driver on Exynos SoCs.
>>
>> CC: Rob Herring 
>> CC: Mark Rutland 
>> CC: Ian Campbell 
>> CC: devicet...@vger.kernel.org
>> Signed-off-by: Pankaj Dubey 
>> Reviewed-by: Krzysztof Kozlowski 
>> Signed-off-by: Kukjin Kim 
>> Signed-off-by: Krzysztof Kozlowski 
>> ---
>>  .../devicetree/bindings/memory-controllers/exynos-srom.txt   | 12 
>> 
>>  1 file changed, 12 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt 
>> b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> new file mode 100644
>> index 000..33886d5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/memory-controllers/exynos-srom.txt
>> @@ -0,0 +1,12 @@
>> +SAMSUNG Exynos SoCs SROM Controller driver.
>> +
>> +Required properties:
>> +- compatible : Should contain "samsung,exynos-srom".
> 
> There should be SoC specific compatible strings in addition to this.
> 

I do not understood need to additional need to SoC specific compatible,
as of now all SoCs having SROM can work with exynos specific common
compatible. Will you see any issues in this?

>> +
>> +- reg: offset and length of the register set
>> +
>> +Example:
>> +sromc@1257 {
> 
> This should be memory-controller@...
> 
>> +compatible = "samsung,exynos-srom";
>> +reg = <0x1257 0x10>;
> 
> The next patch changes the size to 0x14?
> 
> BTW, you could just combine both patches. I guess you didn't to maintain 
> authorship?

OK. Will squash both of these patches, unless Pavel do not any objections.

Thanks,
Pankaj Dubey
> 
> Rob
> 
> 

RE: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> Sent: Friday, March 04, 2016 4:45 PM
> Subject: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on
> PAT / non-PAT systems"
...
> +MMIO and another PCI BAR for write-combing, if needed.

typo: combining

RE: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on PAT / non-PAT systems"

[Elliott, Robert (Persistent Memory)]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Luis R. Rodriguez
> Sent: Friday, March 04, 2016 4:45 PM
> Subject: [PATCH v2] x86: PAT: Documentation: rewrite "MTRR effects on
> PAT / non-PAT systems"
...
> +MMIO and another PCI BAR for write-combing, if needed.

typo: combining

Re: [PATCH v17 2/6] ARM: socfpga: add bindings document for fpga bridge drivers

[Rob Herring]

On Thu, Feb 25, 2016 at 05:25:07PM -0600, Alan Tull wrote:
> Add bindings documentation for Altera SOCFPGA bridges:
>  * fpga2sdram
>  * fpga2hps
>  * hps2fpga
>  * lwhps2fpga
> 
> Signed-off-by: Alan Tull 
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Dinh Nguyen 
> ---
> v2:  separate into 2 documents for the 2 drivers
> v12: bump version to line up with simple-fpga-bus version
>  remove Linux specific notes such as references to sysfs
>  move non-DT specific documentation elsewhere
>  remove bindings that would have been used to pass configuration
>  clean up formatting
> v13: Remove 'label' property
>  Change property from init-val to bridge-enable
>  Fix email address
> v14: Add resets
>  Change order of bridges to put lw bridge (controlling bridge) first
> v15: No change in this patch for v15 of this patch set
> v16: Added regs property, cleaned up unit addresses
> v17: No change to this patch in v17 of patch set
> ---
>  .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +++
>  .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 
> 
>  2 files changed, 62 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

Just a few minor things.

> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> new file mode 100644
> index 000..4479a79
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> @@ -0,0 +1,15 @@
> +Altera FPGA To SDRAM Bridge Driver
> +
> +Required properties:
> +- compatible : Should contain "altr,socfpga-fpga2sdram-bridge"
> +
> +Optional properties:
> +- bridge-enable  : 0 if driver should disable bridge at startup
> +   1 if driver should enable bridge at startup
> +   Default is to leave bridge in current state.
> +
> +Example:
> + fpga2sdram_br {

fpga-bridge@??

> + compatible = "altr,socfpga-fpga2sdram-bridge";
> + bridge-enable = <0>;
> + };
> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> new file mode 100644
> index 000..e6b7474
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> @@ -0,0 +1,47 @@
> +Altera FPGA/HPS Bridge Driver
> +
> +Required properties:
> +- regs   : base address and size for AXI bridge module
> +- compatible : Should contain one of:
> +   "altr,socfpga-lwhps2fpga-bridge",
> +   "altr,socfpga-hps2fpga-bridge", or
> +   "altr,socfpga-fpga2hps-bridge"
> +- reset-names: Should contain one of:
> +   "lwhps2fpga",
> +   "hps2fpga", or
> +   "fpga2hps"

Names should be the input signal names. Do you need names with only one?

> +- resets : Phandle and reset specifier for the reset listed in
> +   reset-names
> +- clocks : Clocks used by this module.
> +
> +Optional properties:
> +- bridge-enable  : 0 if driver should disable bridge at startup.
> +   1 if driver should enable bridge at startup.
> +   Default is to leave bridge in its current state.
> +
> +Example:
> + hps_fpgabridge0: fpgabridge@ff40 {

No underscores.

fpga-bridge@...

> + compatible = "altr,socfpga-lwhps2fpga-bridge";
> + reg = <0xff40 0x10>;
> + resets = < LWHPS2FPGA_RESET>;
> + reset-names = "lwhps2fpga";
> + clocks = <_main_clk>;
> + bridge-enable = <0>;
> + };
> +
> + hps_fpgabridge1: fpgabridge@ff50 {
> + compatible = "altr,socfpga-hps2fpga-bridge";
> + reg = <0xff50 0x1>;
> + resets = < HPS2FPGA_RESET>;
> + reset-names = "hps2fpga";
> + clocks = <_main_clk>;
> + bridge-enable = <1>;
> + };
> +
> + hps_fpgabridge2: fpgabridge@ff60 {
> + compatible = "altr,socfpga-fpga2hps-bridge";
> + reg = <0xff60 0x10>;
> + resets = < FPGA2HPS_RESET>;
> + reset-names = "fpga2hps";
> + clocks = <_main_clk>;
> + };
> -- 
> 1.7.9.5
> 

Re: [PATCH 0/2] [media] exynos4-is: Trivial fixes for DT port/endpoint parse logic

[Krzysztof Kozlowski]

2016-03-05 5:20 GMT+09:00 Javier Martinez Canillas :
> Hello,
>
> This series have two trivial fixes for issues that I noticed while
> reading as a reference the driver's functions that parse the graph
> port and endpoints nodes.
>
> It was only compile tested because I don't have access to a Exynos4
> hardware to test the DT parsing, but the patches are very simple.

Not directly related, but similar: my previous two patches for missing
of_node_put [0] are unfortunately still waiting. Although I have
Exynos4 boards, but I don't have infrastructure/scripts to test it.

Best regards,
Krzysztof

[0] https://patchwork.linuxtv.org/patch/32707/

Re: [PATCH v17 2/6] ARM: socfpga: add bindings document for fpga bridge drivers

[Rob Herring]

On Thu, Feb 25, 2016 at 05:25:07PM -0600, Alan Tull wrote:
> Add bindings documentation for Altera SOCFPGA bridges:
>  * fpga2sdram
>  * fpga2hps
>  * hps2fpga
>  * lwhps2fpga
> 
> Signed-off-by: Alan Tull 
> Signed-off-by: Matthew Gerlach 
> Signed-off-by: Dinh Nguyen 
> ---
> v2:  separate into 2 documents for the 2 drivers
> v12: bump version to line up with simple-fpga-bus version
>  remove Linux specific notes such as references to sysfs
>  move non-DT specific documentation elsewhere
>  remove bindings that would have been used to pass configuration
>  clean up formatting
> v13: Remove 'label' property
>  Change property from init-val to bridge-enable
>  Fix email address
> v14: Add resets
>  Change order of bridges to put lw bridge (controlling bridge) first
> v15: No change in this patch for v15 of this patch set
> v16: Added regs property, cleaned up unit addresses
> v17: No change to this patch in v17 of patch set
> ---
>  .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +++
>  .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 
> 
>  2 files changed, 62 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

Just a few minor things.

> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> new file mode 100644
> index 000..4479a79
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> @@ -0,0 +1,15 @@
> +Altera FPGA To SDRAM Bridge Driver
> +
> +Required properties:
> +- compatible : Should contain "altr,socfpga-fpga2sdram-bridge"
> +
> +Optional properties:
> +- bridge-enable  : 0 if driver should disable bridge at startup
> +   1 if driver should enable bridge at startup
> +   Default is to leave bridge in current state.
> +
> +Example:
> + fpga2sdram_br {

fpga-bridge@??

> + compatible = "altr,socfpga-fpga2sdram-bridge";
> + bridge-enable = <0>;
> + };
> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> new file mode 100644
> index 000..e6b7474
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> @@ -0,0 +1,47 @@
> +Altera FPGA/HPS Bridge Driver
> +
> +Required properties:
> +- regs   : base address and size for AXI bridge module
> +- compatible : Should contain one of:
> +   "altr,socfpga-lwhps2fpga-bridge",
> +   "altr,socfpga-hps2fpga-bridge", or
> +   "altr,socfpga-fpga2hps-bridge"
> +- reset-names: Should contain one of:
> +   "lwhps2fpga",
> +   "hps2fpga", or
> +   "fpga2hps"

Names should be the input signal names. Do you need names with only one?

> +- resets : Phandle and reset specifier for the reset listed in
> +   reset-names
> +- clocks : Clocks used by this module.
> +
> +Optional properties:
> +- bridge-enable  : 0 if driver should disable bridge at startup.
> +   1 if driver should enable bridge at startup.
> +   Default is to leave bridge in its current state.
> +
> +Example:
> + hps_fpgabridge0: fpgabridge@ff40 {

No underscores.

fpga-bridge@...

> + compatible = "altr,socfpga-lwhps2fpga-bridge";
> + reg = <0xff40 0x10>;
> + resets = < LWHPS2FPGA_RESET>;
> + reset-names = "lwhps2fpga";
> + clocks = <_main_clk>;
> + bridge-enable = <0>;
> + };
> +
> + hps_fpgabridge1: fpgabridge@ff50 {
> + compatible = "altr,socfpga-hps2fpga-bridge";
> + reg = <0xff50 0x1>;
> + resets = < HPS2FPGA_RESET>;
> + reset-names = "hps2fpga";
> + clocks = <_main_clk>;
> + bridge-enable = <1>;
> + };
> +
> + hps_fpgabridge2: fpgabridge@ff60 {
> + compatible = "altr,socfpga-fpga2hps-bridge";
> + reg = <0xff60 0x10>;
> + resets = < FPGA2HPS_RESET>;
> + reset-names = "fpga2hps";
> + clocks = <_main_clk>;
> + };
> -- 
> 1.7.9.5
> 

Re: [PATCH 0/2] [media] exynos4-is: Trivial fixes for DT port/endpoint parse logic

[Krzysztof Kozlowski]

2016-03-05 5:20 GMT+09:00 Javier Martinez Canillas :
> Hello,
>
> This series have two trivial fixes for issues that I noticed while
> reading as a reference the driver's functions that parse the graph
> port and endpoints nodes.
>
> It was only compile tested because I don't have access to a Exynos4
> hardware to test the DT parsing, but the patches are very simple.

Not directly related, but similar: my previous two patches for missing
of_node_put [0] are unfortunately still waiting. Although I have
Exynos4 boards, but I don't have infrastructure/scripts to test it.

Best regards,
Krzysztof

[0] https://patchwork.linuxtv.org/patch/32707/

Re: [PATCH v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

[Rob Herring]

On Fri, Mar 04, 2016 at 05:19:32PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> This is an old version of the binding that isn't flexible enough to
> describe all aspects of the XUSB pad controller. Specifically with the
> addition of XUSB support (for SuperSpeed USB) the existing binding is
> no longer suitable.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt  | 1 
> +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Rob Herring]

On Fri, Mar 04, 2016 at 05:19:31PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
> set of lanes that are used for PCIe, SATA and USB.
> 
> Signed-off-by: Thierry Reding 
> ---
> Changes in v10:
> - clarify that the hardware documentation means something different when
>   referring to a "port" (intra-SoC connectivity)
> 
> Changes in v9:
> - rename UTMI -> USB2 to match hardware documentation
> - reword according to suggestions by Stephen Warren
> - make Tegra132 compatible string list consistent
> - remove mailbox support
> 
>  .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   | 376 
> +
>  .../pinctrl/nvidia,tegra124-xusb-padctl.txt|   5 +
>  2 files changed, 381 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt

Without really understanding the h/w here, looks okay to me.

Acked-by: Rob Herring 

> +SoC include:
> +
> + padctl@0,7009f000 {

Drop the comma. Commas should only be used if there are distinct fields.

If I get my dtc patch done, these are going to start warning, so you 
might want to go fix dts files (assuming that's where this is coming 
from).

Rob

Re: [PATCH v10 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding

[Rob Herring]

On Fri, Mar 04, 2016 at 05:19:31PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a
> set of lanes that are used for PCIe, SATA and USB.
> 
> Signed-off-by: Thierry Reding 
> ---
> Changes in v10:
> - clarify that the hardware documentation means something different when
>   referring to a "port" (intra-SoC connectivity)
> 
> Changes in v9:
> - rename UTMI -> USB2 to match hardware documentation
> - reword according to suggestions by Stephen Warren
> - make Tegra132 compatible string list consistent
> - remove mailbox support
> 
>  .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   | 376 
> +
>  .../pinctrl/nvidia,tegra124-xusb-padctl.txt|   5 +
>  2 files changed, 381 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/nvidia,tegra124-xusb-padctl.txt

Without really understanding the h/w here, looks okay to me.

Acked-by: Rob Herring 

> +SoC include:
> +
> + padctl@0,7009f000 {

Drop the comma. Commas should only be used if there are distinct fields.

If I get my dtc patch done, these are going to start warning, so you 
might want to go fix dts files (assuming that's where this is coming 
from).

Rob

Re: [PATCH v10 2/9] dt-bindings: pinctrl: Deprecate Tegra XUSB pad controller binding

[Rob Herring]

On Fri, Mar 04, 2016 at 05:19:32PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> This is an old version of the binding that isn't flexible enough to
> describe all aspects of the XUSB pad controller. Specifically with the
> addition of XUSB support (for SuperSpeed USB) the existing binding is
> no longer suitable.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt  | 1 
> +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v2 1/2] dt/bindings: Add bindings for PIC32 SPI peripheral

[Rob Herring]

On Fri, Mar 04, 2016 at 07:14:41PM +0530, Purna Chandra Mandal wrote:
> Signed-off-by: Purna Chandra Mandal 
> 
> ---
> 
> Changes in v2:
>  - fix indentation
>  - add space after comma
>  - moved 'cs-gpios' section under 'required' properties.
> 
>  .../bindings/spi/microchip,spi-pic32.txt   | 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt

Acked-by: Rob Herring 

Re: [PATCH v4 2/4] Documentation: Bindings: Add STM32 DWMAC glue

[Rob Herring]

On Fri, Mar 04, 2016 at 04:58:04PM +0100, Alexandre TORGUE wrote:
> Signed-off-by: Alexandre TORGUE 
> 
> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt 
> b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
> new file mode 100644
> index 000..fd3566f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
> @@ -0,0 +1,35 @@
> +STMicroelectronics STM32 / MCU DWMAC glue layer controller
> +
> +This file documents platform glue layer for stmmac.
> +Please see stmmac.txt for the other unchanged properties.
> +
> +The device node has following properties.
> +
> +Required properties:

> +- compatible:  Should be "st,stm32-dwmac" to select glue, and
> +"snps,dwmac-3.50a" to select IP vesrion.
> +- clocks: Should contain the GMAC main clock, and tx clock

> +- compatible:  Should be "st,stm32-dwmac" to select glue and
> +"snps,dwmac-3.50a" to select IP version.
> +- clocks: Must contain an entry for each entry in clock-names.

???

> +- clock-names: Should be "stmmaceth" for the host clock.
> +Should be "tx-clk" for the MAC TX clock.
> +Should be "rx-clk" for the MAC RX clock.
> +- st,syscon : Should be phandle/offset pair. The phandle to the syscon node 
> which
> +   encompases the glue register, and the offset of the control 
> register.
> +Example:
> +
> + ethernet0: dwmac@40028000 {
> + compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
> + status = "disabled";
> + reg = <0x40028000 0x8000>;
> + reg-names = "stmmaceth";
> + interrupts = <0 61 0>, <0 62 0>;
> + interrupt-names = "macirq", "eth_wake_irq";
> + clock-names = "stmmaceth", "tx-clk", "rx-clk";
> + clocks = < 0 25>, < 0 26>, < 0 27>;
> + st,syscon = < 0x4>;
> + snps,pbl = <8>;
> + snps,mixed-burst;
> + dma-ranges;
> + };
> -- 
> 1.9.1
> 

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Rob Herring]

On Fri, Mar 04, 2016 at 05:19:33PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Extend the binding to cover the set of feature found in Tegra210.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   | 327 
> +
>  1 file changed, 327 insertions(+)

Acked-by: Rob Herring 

> +Tegra210:
> +-
> +
> +SoC include:
> +
> + padctl@0,7009f000 {

Drop the comma.

Re: [PATCH v2 1/2] dt/bindings: Add bindings for PIC32 SPI peripheral

[Rob Herring]

On Fri, Mar 04, 2016 at 07:14:41PM +0530, Purna Chandra Mandal wrote:
> Signed-off-by: Purna Chandra Mandal 
> 
> ---
> 
> Changes in v2:
>  - fix indentation
>  - add space after comma
>  - moved 'cs-gpios' section under 'required' properties.
> 
>  .../bindings/spi/microchip,spi-pic32.txt   | 34 
> ++
>  1 file changed, 34 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/spi/microchip,spi-pic32.txt

Acked-by: Rob Herring 

Re: [PATCH v4 2/4] Documentation: Bindings: Add STM32 DWMAC glue

[Rob Herring]

On Fri, Mar 04, 2016 at 04:58:04PM +0100, Alexandre TORGUE wrote:
> Signed-off-by: Alexandre TORGUE 
> 
> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt 
> b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
> new file mode 100644
> index 000..fd3566f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
> @@ -0,0 +1,35 @@
> +STMicroelectronics STM32 / MCU DWMAC glue layer controller
> +
> +This file documents platform glue layer for stmmac.
> +Please see stmmac.txt for the other unchanged properties.
> +
> +The device node has following properties.
> +
> +Required properties:

> +- compatible:  Should be "st,stm32-dwmac" to select glue, and
> +"snps,dwmac-3.50a" to select IP vesrion.
> +- clocks: Should contain the GMAC main clock, and tx clock

> +- compatible:  Should be "st,stm32-dwmac" to select glue and
> +"snps,dwmac-3.50a" to select IP version.
> +- clocks: Must contain an entry for each entry in clock-names.

???

> +- clock-names: Should be "stmmaceth" for the host clock.
> +Should be "tx-clk" for the MAC TX clock.
> +Should be "rx-clk" for the MAC RX clock.
> +- st,syscon : Should be phandle/offset pair. The phandle to the syscon node 
> which
> +   encompases the glue register, and the offset of the control 
> register.
> +Example:
> +
> + ethernet0: dwmac@40028000 {
> + compatible = "st,stm32-dwmac", "snps,dwmac-3.50a";
> + status = "disabled";
> + reg = <0x40028000 0x8000>;
> + reg-names = "stmmaceth";
> + interrupts = <0 61 0>, <0 62 0>;
> + interrupt-names = "macirq", "eth_wake_irq";
> + clock-names = "stmmaceth", "tx-clk", "rx-clk";
> + clocks = < 0 25>, < 0 26>, < 0 27>;
> + st,syscon = < 0x4>;
> + snps,pbl = <8>;
> + snps,mixed-burst;
> + dma-ranges;
> + };
> -- 
> 1.9.1
> 

Re: [PATCH v10 3/9] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support

[Rob Herring]

On Fri, Mar 04, 2016 at 05:19:33PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Extend the binding to cover the set of feature found in Tegra210.
> 
> Signed-off-by: Thierry Reding 
> ---
>  .../bindings/phy/nvidia,tegra124-xusb-padctl.txt   | 327 
> +
>  1 file changed, 327 insertions(+)

Acked-by: Rob Herring 

> +Tegra210:
> +-
> +
> +SoC include:
> +
> + padctl@0,7009f000 {

Drop the comma.

Re: [PATCH 16/17] dt-bindings: Add Western Digital to vendor prefixes

[Rob Herring]

On Thu, Mar 03, 2016 at 12:40:09PM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH 2/4 v2] drm: Add DT bindings documentation for ARC PGU display controller

[Rob Herring]

On Thu, Mar 03, 2016 at 05:39:14PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> ---
> 
> Changes v1 -> v2:
>  * Clean-up

Not really useful. What we like to see is what changed. Maintainers have 
short memories and don't remember what they said previously (unless 
comments are ignored).

> 
>  .../devicetree/bindings/display/snps,arcpgu.txt| 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt 
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..57f3bc8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,33 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> +  - compatible: "snps,arcpgu"
> +  - reg: Physical base address and length of the controller's registers.
> +  - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> +  - clock-names: A list of clock names. For ARC PGU it should contain:
> +  - "pxlclk" for the clock feeding the output PLL of the controller.
> +
> +Required sub-nodes:
> +  - port: The PGU connection to an encoder chip. The connection is modelled
> +using the OF graph bindings specified in
> +Documentation/devicetree/bindings/graph.txt.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@ {
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <_node>;
> + clock-names = "pxlclk";

Where's the port? Didn't you previously say it was optional?

> + };
> +
> + ...
> +};
> -- 
> 2.5.0
> 

Re: [PATCH 1/3] pinctrl: Broadcom Northstar2 pinctrl device tree bindings

[Rob Herring]

On Thu, Mar 03, 2016 at 06:41:41AM -0500, Yendapally Reddy Dhananjaya Reddy 
wrote:
> Device tree binding documentation for Broadcom NS2 IOMUX
> 
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
> 
> ---
>  .../bindings/pinctrl/brcm,ns2-pinmux.txt   | 102 
> +
>  1 file changed, 102 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.txt

Acked-by: Rob Herring 

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

[Rob Herring]

On Wed, Mar 02, 2016 at 10:01:35PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin 
> 
> Si-En Technology was acquired by ISSI in 2011, and it appears that
> the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
> As the IS31FL32XX driver already handles the *3218 devices, there
> is no longer a need for the dedicated SN3218 driver.
> 
> Add the "sn,sn3218" and "sn,sn3216" compatible strings into the
> IS31FL32XX driver and binding documentation, and remove the
> leds-sn3218 driver.
> 
> Datasheets:
> IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
> SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf
> 
> IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
> SN3216; http://www.si-en.com/uploadpdf/SN3216201152410148.pdf
> 
> Signed-off-by: David Rivshin 
> ---
> 
> Note that the leds-sn3218 binding use a 0-based 'reg' property, while
> the leds-is31fl32xx binding uses a 1-based 'reg' property. This seemed
> to be the preferred binding based on [1]. Since leds-sn3216 has not been
> in a released kernel, there is are no backwards-compatibility concerns.

It would probably make more sense to revert the sn3216 driver/binding 
and add the additions to the previous patches. Doesn't matter to me 
though.

Acked-by: Rob Herring 

> 
> Changes from RFC:
>  new
> 
> [1] http://www.spinics.net/lists/linux-leds/msg05589.html
> 
>  .../devicetree/bindings/leds/leds-is31fl32xx.txt   |   9 +-
>  .../devicetree/bindings/leds/leds-sn3218.txt   |  41 ---
>  drivers/leds/Kconfig   |  18 +-
>  drivers/leds/Makefile  |   1 -
>  drivers/leds/leds-is31fl32xx.c |   6 +-
>  drivers/leds/leds-sn3218.c | 306 
> -
>  6 files changed, 14 insertions(+), 367 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/leds/leds-sn3218.txt
>  delete mode 100644 drivers/leds/leds-sn3218.c

Re: [PATCH V3 1/4] net-next: mediatek: document MediaTek SoC ethernet binding

[Rob Herring]

On Thu, Mar 03, 2016 at 09:02:38PM +0100, John Crispin wrote:
> This adds the binding documentation for the MediaTek Ethernet
> controller.
> 
> Signed-off-by: John Crispin 
> Cc: devicet...@vger.kernel.org
> ---
>  .../devicetree/bindings/net/mediatek-net.txt   |   77 
> 
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/mediatek-net.txt

Acked-by: Rob Herring 

Re: [PATCH 1/3] pinctrl: Broadcom Northstar2 pinctrl device tree bindings

[Rob Herring]

On Thu, Mar 03, 2016 at 06:41:41AM -0500, Yendapally Reddy Dhananjaya Reddy 
wrote:
> Device tree binding documentation for Broadcom NS2 IOMUX
> 
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
> 
> ---
>  .../bindings/pinctrl/brcm,ns2-pinmux.txt   | 102 
> +
>  1 file changed, 102 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/brcm,ns2-pinmux.txt

Acked-by: Rob Herring 

Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver

[Rob Herring]

On Wed, Mar 02, 2016 at 10:01:35PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin 
> 
> Si-En Technology was acquired by ISSI in 2011, and it appears that
> the IS31FL3218/IS31FL3216 are just rebranded SN3218/SN3216 devices.
> As the IS31FL32XX driver already handles the *3218 devices, there
> is no longer a need for the dedicated SN3218 driver.
> 
> Add the "sn,sn3218" and "sn,sn3216" compatible strings into the
> IS31FL32XX driver and binding documentation, and remove the
> leds-sn3218 driver.
> 
> Datasheets:
> IS31FL3218: http://www.issi.com/WW/pdf/31FL3218.pdf
> SN3218: http://www.si-en.com/uploadpdf/s2011517171720.pdf
> 
> IS31FL3216: http://www.issi.com/WW/pdf/31FL3216.pdf
> SN3216; http://www.si-en.com/uploadpdf/SN3216201152410148.pdf
> 
> Signed-off-by: David Rivshin 
> ---
> 
> Note that the leds-sn3218 binding use a 0-based 'reg' property, while
> the leds-is31fl32xx binding uses a 1-based 'reg' property. This seemed
> to be the preferred binding based on [1]. Since leds-sn3216 has not been
> in a released kernel, there is are no backwards-compatibility concerns.

It would probably make more sense to revert the sn3216 driver/binding 
and add the additions to the previous patches. Doesn't matter to me 
though.

Acked-by: Rob Herring 

> 
> Changes from RFC:
>  new
> 
> [1] http://www.spinics.net/lists/linux-leds/msg05589.html
> 
>  .../devicetree/bindings/leds/leds-is31fl32xx.txt   |   9 +-
>  .../devicetree/bindings/leds/leds-sn3218.txt   |  41 ---
>  drivers/leds/Kconfig   |  18 +-
>  drivers/leds/Makefile  |   1 -
>  drivers/leds/leds-is31fl32xx.c |   6 +-
>  drivers/leds/leds-sn3218.c | 306 
> -
>  6 files changed, 14 insertions(+), 367 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/leds/leds-sn3218.txt
>  delete mode 100644 drivers/leds/leds-sn3218.c

Re: [PATCH V3 1/4] net-next: mediatek: document MediaTek SoC ethernet binding

[Rob Herring]

On Thu, Mar 03, 2016 at 09:02:38PM +0100, John Crispin wrote:
> This adds the binding documentation for the MediaTek Ethernet
> controller.
> 
> Signed-off-by: John Crispin 
> Cc: devicet...@vger.kernel.org
> ---
>  .../devicetree/bindings/net/mediatek-net.txt   |   77 
> 
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/net/mediatek-net.txt

Acked-by: Rob Herring 

Re: [PATCH 16/17] dt-bindings: Add Western Digital to vendor prefixes

[Rob Herring]

On Thu, Mar 03, 2016 at 12:40:09PM +0100, Neil Armstrong wrote:
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH 2/4 v2] drm: Add DT bindings documentation for ARC PGU display controller

[Rob Herring]

On Thu, Mar 03, 2016 at 05:39:14PM +0300, Alexey Brodkin wrote:
> This add DT bindings documentation for ARC PGU display controller.
> 
> Signed-off-by: Alexey Brodkin 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: devicet...@vger.kernel.org
> Cc: linux-snps-...@lists.infradead.org
> ---
> 
> Changes v1 -> v2:
>  * Clean-up

Not really useful. What we like to see is what changed. Maintainers have 
short memories and don't remember what they said previously (unless 
comments are ignored).

> 
>  .../devicetree/bindings/display/snps,arcpgu.txt| 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/snps,arcpgu.txt
> 
> diff --git a/Documentation/devicetree/bindings/display/snps,arcpgu.txt 
> b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> new file mode 100644
> index 000..57f3bc8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/snps,arcpgu.txt
> @@ -0,0 +1,33 @@
> +ARC PGU
> +
> +This is a display controller found on several development boards produced
> +by Synopsys. The ARC PGU is an RGB streamer that reads the data from a
> +framebuffer and sends it to a single digital encoder (usually HDMI).
> +
> +Required properties:
> +  - compatible: "snps,arcpgu"
> +  - reg: Physical base address and length of the controller's registers.
> +  - clocks: A list of phandle + clock-specifier pairs, one for each
> +entry in 'clock-names'.
> +  - clock-names: A list of clock names. For ARC PGU it should contain:
> +  - "pxlclk" for the clock feeding the output PLL of the controller.
> +
> +Required sub-nodes:
> +  - port: The PGU connection to an encoder chip. The connection is modelled
> +using the OF graph bindings specified in
> +Documentation/devicetree/bindings/graph.txt.
> +
> +Example:
> +
> +/ {
> + ...
> +
> + pgu@ {
> + compatible = "snps,arcpgu";
> + reg = <0x 0x400>;
> + clocks = <_node>;
> + clock-names = "pxlclk";

Where's the port? Didn't you previously say it was optional?

> + };
> +
> + ...
> +};
> -- 
> 2.5.0
> 

Re: [PATCH v2] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Krzysztof Kozlowski]

2016-03-04 20:02 GMT+09:00 Sylwester Nawrocki :
> On 03/04/2016 02:02 AM, Krzysztof Kozlowski wrote:
>> The MFD_SYSCON depends on HAS_IOMEM so when selecting
>> it avoid unmet direct dependencies.
>
>> diff --git a/drivers/media/platform/exynos4-is/Kconfig
>> b/drivers/media/platform/exynos4-is/Kconfig
>> index 57d42c6172c5..c4317b99d257 100644
>> --- a/drivers/media/platform/exynos4-is/Kconfig
>> +++ b/drivers/media/platform/exynos4-is/Kconfig
>> @@ -17,6 +17,7 @@ config VIDEO_S5P_FIMC
>>   tristate "S5P/EXYNOS4 FIMC/CAMIF camera interface driver"
>>   depends on I2C
>>   depends on HAS_DMA
>> + depends on HAS_IOMEM# For MFD_SYSCON
>>   select VIDEOBUF2_DMA_CONTIG
>>   select V4L2_MEM2MEM_DEV
>>   select MFD_SYSCON
>
> While we are already at it, shouldn't "depends on HAS_IOMEM"
> be instead added at the top level entry in this Kconfig file,
> i.e. "config VIDEO_SAMSUNG_EXYNOS4_IS" ? For things like
> devm_ioremap_resource() depending on HAS_IOMEM and used in all
> the sub-drivers, enabled by VIDEO_SAMSUNG_EXYNOS4_IS?

Indeed that would make sense... but now after some more looking at it,
even this patch is not needed. All these drivers are children of
MEDIA_SUPPORT which already depends on HAS_IOMEM.

Best regards,
Krzysztof

Re: [PATCH 01/17] dt-bindings: vendor-prefixes: Add PLX Technology

[Rob Herring]

On Thu, Mar 03, 2016 at 04:02:15PM +0100, Philipp Zabel wrote:
> Am Donnerstag, den 03.03.2016, 12:39 +0100 schrieb Neil Armstrong:
> > Add PLX Technology vendor prefix.
> > 
> > Signed-off-by: Neil Armstrong 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 72e2c5a..03970fb 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -178,6 +178,7 @@ picochipPicochip Ltd
> >  plathome   Plat'Home Co., Ltd.
> >  plda   PLDA
> >  pixcir  PIXCIR MICROELECTRONICS Co., Ltd
> > +plxtechPLX Technology, Inc.
> 
> The PLX Technology NASDAQ symbol used to be PLXT.

And is no longer listed? If not, then plxtech is fine. Otherwise, use 
plxt.

Can you fix the alphabetizing while you are at it.

Rob

Re: [PATCH 1/2] regulator: max8973: add DT binding details for junction warn temp

[Rob Herring]

On Fri, Mar 04, 2016 at 03:57:53PM +0530, Laxman Dewangan wrote:
> The driver MAX8973 supports the driver for Maxim MAX77621.
> MAX77621 supports the junction temp warning at 120 degC and
> 140 degC which is configurable. It generates alert signal when
> junction temperature crosses these threshold.
> 
> Add DT properties and its binding details to make this
> configuration from DT.
> 
> Signed-off-by: Laxman Dewangan 
> ---
>  Documentation/devicetree/bindings/regulator/max8973-regulator.txt | 7 +++
>  1 file changed, 7 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH] ASoC: rockchip: add bindings for spdif controller

[Rob Herring]

On Fri, Mar 04, 2016 at 06:31:54PM +0800, Sugar Zhang wrote:
> this patch add compatible for rk3366/rk3368/rk3399 spdif,
> these three spdifs share the same type.
> 
> Signed-off-by: Sugar Zhang 
> ---
> 
>  Documentation/devicetree/bindings/sound/rockchip-spdif.txt |  8 ++--
>  sound/soc/rockchip/rockchip_spdif.c| 13 ++---
>  2 files changed, 16 insertions(+), 5 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH 01/17] dt-bindings: vendor-prefixes: Add PLX Technology

[Rob Herring]

On Thu, Mar 03, 2016 at 04:02:15PM +0100, Philipp Zabel wrote:
> Am Donnerstag, den 03.03.2016, 12:39 +0100 schrieb Neil Armstrong:
> > Add PLX Technology vendor prefix.
> > 
> > Signed-off-by: Neil Armstrong 
> > ---
> >  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 72e2c5a..03970fb 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -178,6 +178,7 @@ picochipPicochip Ltd
> >  plathome   Plat'Home Co., Ltd.
> >  plda   PLDA
> >  pixcir  PIXCIR MICROELECTRONICS Co., Ltd
> > +plxtechPLX Technology, Inc.
> 
> The PLX Technology NASDAQ symbol used to be PLXT.

And is no longer listed? If not, then plxtech is fine. Otherwise, use 
plxt.

Can you fix the alphabetizing while you are at it.

Rob

Re: [PATCH 1/2] regulator: max8973: add DT binding details for junction warn temp

[Rob Herring]

On Fri, Mar 04, 2016 at 03:57:53PM +0530, Laxman Dewangan wrote:
> The driver MAX8973 supports the driver for Maxim MAX77621.
> MAX77621 supports the junction temp warning at 120 degC and
> 140 degC which is configurable. It generates alert signal when
> junction temperature crosses these threshold.
> 
> Add DT properties and its binding details to make this
> configuration from DT.
> 
> Signed-off-by: Laxman Dewangan 
> ---
>  Documentation/devicetree/bindings/regulator/max8973-regulator.txt | 7 +++
>  1 file changed, 7 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH] ASoC: rockchip: add bindings for spdif controller

[Rob Herring]

On Fri, Mar 04, 2016 at 06:31:54PM +0800, Sugar Zhang wrote:
> this patch add compatible for rk3366/rk3368/rk3399 spdif,
> these three spdifs share the same type.
> 
> Signed-off-by: Sugar Zhang 
> ---
> 
>  Documentation/devicetree/bindings/sound/rockchip-spdif.txt |  8 ++--
>  sound/soc/rockchip/rockchip_spdif.c| 13 ++---
>  2 files changed, 16 insertions(+), 5 deletions(-)

Acked-by: Rob Herring 

Re: [PATCH v2] media: platform: Add missing MFD_SYSCON dependency on HAS_IOMEM

[Krzysztof Kozlowski]

2016-03-04 20:02 GMT+09:00 Sylwester Nawrocki :
> On 03/04/2016 02:02 AM, Krzysztof Kozlowski wrote:
>> The MFD_SYSCON depends on HAS_IOMEM so when selecting
>> it avoid unmet direct dependencies.
>
>> diff --git a/drivers/media/platform/exynos4-is/Kconfig
>> b/drivers/media/platform/exynos4-is/Kconfig
>> index 57d42c6172c5..c4317b99d257 100644
>> --- a/drivers/media/platform/exynos4-is/Kconfig
>> +++ b/drivers/media/platform/exynos4-is/Kconfig
>> @@ -17,6 +17,7 @@ config VIDEO_S5P_FIMC
>>   tristate "S5P/EXYNOS4 FIMC/CAMIF camera interface driver"
>>   depends on I2C
>>   depends on HAS_DMA
>> + depends on HAS_IOMEM# For MFD_SYSCON
>>   select VIDEOBUF2_DMA_CONTIG
>>   select V4L2_MEM2MEM_DEV
>>   select MFD_SYSCON
>
> While we are already at it, shouldn't "depends on HAS_IOMEM"
> be instead added at the top level entry in this Kconfig file,
> i.e. "config VIDEO_SAMSUNG_EXYNOS4_IS" ? For things like
> devm_ioremap_resource() depending on HAS_IOMEM and used in all
> the sub-drivers, enabled by VIDEO_SAMSUNG_EXYNOS4_IS?

Indeed that would make sense... but now after some more looking at it,
even this patch is not needed. All these drivers are children of
MEDIA_SUPPORT which already depends on HAS_IOMEM.

Best regards,
Krzysztof

Re: [PATCH 1/4] DT: Add vendor prefix for Integrated Silicon Solutions Inc.

[Rob Herring]

On Wed, Mar 02, 2016 at 10:01:32PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin 
> 
> ISSI is the stock ticker Integrated Silicon Solutions Inc.
> Company website: http://www.issi.com
> 
> Signed-off-by: David Rivshin 
> ---
> 
> Changes from RFC:
>  none
> 
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH 1/4] DT: Add vendor prefix for Integrated Silicon Solutions Inc.

[Rob Herring]

On Wed, Mar 02, 2016 at 10:01:32PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin 
> 
> ISSI is the stock ticker Integrated Silicon Solutions Inc.
> Company website: http://www.issi.com
> 
> Signed-off-by: David Rivshin 
> ---
> 
> Changes from RFC:
>  none
> 
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

Re: [PATCH v2 2/2] phy: rcar-gen3-usb2: add fallback binding

[Rob Herring]

On Thu, Mar 03, 2016 at 09:38:38AM +0900, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
> 
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
> 
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
> 
> Signed-off-by: Simon Horman 
> ---
> v2
> * Use renesas,rcar-gen3-usb-phy rather than renesas,usb-phy-gen3 as
>   the new compatibility string to fit in with the preferred scheme
>   for new compatibility string names.
> ---
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 --
>  drivers/phy/phy-rcar-gen3-usb2.c |  1 +
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> index eaf7e9b7ce6b..86826ca2fdef 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> @@ -6,6 +6,12 @@ This file provides information on what the device node for 
> the R-Car generation
>  Required properties:
>  - compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an 
> R8A7795
> SoC.
> +   "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible 
> device.
> +
> +   When compatible with the generic version, nodes must list the
> +   SoC-specific version corresponding to the platform first
> +   followed by the generic version.
> +
>  - reg: offset and length of the partial USB 2.0 Host register block.
>  - clocks: clock phandle and specifier pair(s).
>  - #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
> @@ -19,14 +25,14 @@ channel as USB OTG:
>  Example (R-Car H3):
>  
>   usb-phy@ee080200 {
> - compatible = "renesas,usb2-phy-r8a7795";
> + compatible = 
> "renesas,usb2-phy-r8a7795","renesas,rcar-gen3-usb2-phy";

space...

>   reg = <0 0xee080200 0 0x700>;
>   interrupts = ;
>   clocks = <_clks R8A7795_CLK_EHCI0>;
>   };
>  
>   usb-phy@ee0a0200 {
> - compatible = "renesas,usb2-phy-r8a7795";
> + compatible = 
> "renesas,usb2-phy-r8a7795","renesas,rcar-gen3-usb2-phy";

space...

Otherwise,

Acked-by: Rob Herring 

Re: [PATCH 2/4] DT: leds: Add binding for the ISSI IS31FL32xx family of LED controllers

[Rob Herring]

On Wed, Mar 02, 2016 at 10:01:33PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin 
> 
> This adds a binding description for the is31fl3236/35/18/16 I2C LED
> controllers.
> 
> Signed-off-by: David Rivshin 
> ---
> 
> Rob,
>  I went with the 1-based 'reg' property here. I inferred that that
> would be your preference based on the previous thread [1]. Let me
> know if that's not the case.
> 
> Changes from RFC:
>  - Removed max-brightness property.
>  - Added #address-cells and #size-cells properties to the example.
> 
> [1] http://www.spinics.net/lists/linux-leds/msg05589.html
> 
>  .../devicetree/bindings/leds/leds-is31fl32xx.txt   | 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt 
> b/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> new file mode 100644
> index 000..539df2e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> @@ -0,0 +1,49 @@
> +Binding for ISSI IS31FL32xx LED Drivers
> +
> +The IS31FL32xx family of LED drivers are I2C devices with multiple
> +constant-current channels, each with independent 256-level PWM control.
> +Each LED is represented as a sub-node of the device.
> +
> +Required properties:
> +- compatible: one of
> + issi,is31fl3236
> + issi,is31fl3235
> + issi,is31fl3218
> + issi,is31fl3216
> +- reg: I2C slave address
> +- address-cells : must be 1
> +- size-cells : must be 0
> +
> +LED sub-node properties:
> +- reg : LED channel number (1..N)
> +- label :  (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +- linux,default-trigger :  (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +
> +
> +Example:
> +
> +leds: is31fl3236@3c {

Other way around: is31fl3236: leds@3c

Otherwise,

Acked-by: Rob Herring 

Re: [PATCH 1/2] Documentation: synopsys-dw-mshc: add binding for resets

[Rob Herring]

On Thu, Mar 03, 2016 at 09:33:37AM +0800, Guodong Xu wrote:
> Add resets property to synopsys-dw-mshc bindings. It is intended to
> represent the hardware reset signal present internally in some host
> controller IC designs.
> 
> See Documentation/devicetree/bindings/reset/reset.txt for details.
> 
> Signed-off-by: Guodong Xu 
> ---
>  Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
> b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> index 8636f5a..9b4896c 100644
> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> @@ -39,6 +39,10 @@ Required Properties:
>  
>  Optional properties:
>  
> +* resets: phandle + reset specifier pair, intended to represent hardware
> +  reset signal present internally in some host controller IC designs.
> +  See Documentation/devicetree/bindings/reset/reset.txt for details.
> +
>  * clocks: from common clock binding: handle to biu and ciu clocks for the
>bus interface unit clock and the card interface unit clock.
>  
> @@ -48,7 +52,7 @@ Optional properties:
>clock-frequency.  It is an error to omit both the ciu clock and the
>clock-frequency.
>  
> -* clock-frequency: should be the frequency (in Hz) of the ciu clock.  If this
> +* clock-frequency: should be tke frequency (in Hz) of the ciu clock.  If this

You've added a typo here.

Otherwise,

Acked-by: Rob Herring 

Re: [PATCH v2 1/2] phy: rcar-gen2: add fallback binding

[Rob Herring]

On Thu, Mar 03, 2016 at 09:38:37AM +0900, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
> 
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
> 
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
> 
> Signed-off-by: Simon Horman 
> ---
> v2
> * Use renesas,rcar-gen2-usb-phy rather than renesas,usb-phy-gen2 as
>   the new compatibility string to fit in with the preferred scheme
>   for new compatibility string names.
> ---
>  Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 8 +++-
>  drivers/phy/phy-rcar-gen2.c | 1 +
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt 
> b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> index d564ba4f1cf6..feb1c3c102c2 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> @@ -7,6 +7,12 @@ Required properties:
>  - compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 
> SoC.
> "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
> "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC.
> +   "renesas,rcar-gen2-usb-phy" for a generic R-Car Gen2 compatible 
> device.
> +
> +   When compatible with the generic version, nodes must list the
> +   SoC-specific version corresponding to the platform first
> +   followed by the generic version.
> +
>  - reg: offset and length of the register block.
>  - #address-cells: number of address cells for the USB channel subnodes, must
> be <1>.
> @@ -34,7 +40,7 @@ the USB channel; see the selector meanings below:
>  Example (Lager board):
>  
>   usb-phy@e6590100 {
> - compatible = "renesas,usb-phy-r8a7790";
> + compatible = 
> "renesas,usb-phy-r8a7790","renesas,rcar-gen2-usb-phy";
Space here ^

Otherwise,

Acked-by: Rob Herring 

Re: [PATCH v2 2/2] phy: rcar-gen3-usb2: add fallback binding

[Rob Herring]

On Thu, Mar 03, 2016 at 09:38:38AM +0900, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
> 
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
> 
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
> 
> Signed-off-by: Simon Horman 
> ---
> v2
> * Use renesas,rcar-gen3-usb-phy rather than renesas,usb-phy-gen3 as
>   the new compatibility string to fit in with the preferred scheme
>   for new compatibility string names.
> ---
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 --
>  drivers/phy/phy-rcar-gen3-usb2.c |  1 +
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> index eaf7e9b7ce6b..86826ca2fdef 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> @@ -6,6 +6,12 @@ This file provides information on what the device node for 
> the R-Car generation
>  Required properties:
>  - compatible: "renesas,usb2-phy-r8a7795" if the device is a part of an 
> R8A7795
> SoC.
> +   "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 compatible 
> device.
> +
> +   When compatible with the generic version, nodes must list the
> +   SoC-specific version corresponding to the platform first
> +   followed by the generic version.
> +
>  - reg: offset and length of the partial USB 2.0 Host register block.
>  - clocks: clock phandle and specifier pair(s).
>  - #phy-cells: see phy-bindings.txt in the same directory, must be <0>.
> @@ -19,14 +25,14 @@ channel as USB OTG:
>  Example (R-Car H3):
>  
>   usb-phy@ee080200 {
> - compatible = "renesas,usb2-phy-r8a7795";
> + compatible = 
> "renesas,usb2-phy-r8a7795","renesas,rcar-gen3-usb2-phy";

space...

>   reg = <0 0xee080200 0 0x700>;
>   interrupts = ;
>   clocks = <_clks R8A7795_CLK_EHCI0>;
>   };
>  
>   usb-phy@ee0a0200 {
> - compatible = "renesas,usb2-phy-r8a7795";
> + compatible = 
> "renesas,usb2-phy-r8a7795","renesas,rcar-gen3-usb2-phy";

space...

Otherwise,

Acked-by: Rob Herring 

Re: [PATCH 2/4] DT: leds: Add binding for the ISSI IS31FL32xx family of LED controllers

[Rob Herring]

On Wed, Mar 02, 2016 at 10:01:33PM -0500, David Rivshin (Allworx) wrote:
> From: David Rivshin 
> 
> This adds a binding description for the is31fl3236/35/18/16 I2C LED
> controllers.
> 
> Signed-off-by: David Rivshin 
> ---
> 
> Rob,
>  I went with the 1-based 'reg' property here. I inferred that that
> would be your preference based on the previous thread [1]. Let me
> know if that's not the case.
> 
> Changes from RFC:
>  - Removed max-brightness property.
>  - Added #address-cells and #size-cells properties to the example.
> 
> [1] http://www.spinics.net/lists/linux-leds/msg05589.html
> 
>  .../devicetree/bindings/leds/leds-is31fl32xx.txt   | 49 
> ++
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt 
> b/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> new file mode 100644
> index 000..539df2e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-is31fl32xx.txt
> @@ -0,0 +1,49 @@
> +Binding for ISSI IS31FL32xx LED Drivers
> +
> +The IS31FL32xx family of LED drivers are I2C devices with multiple
> +constant-current channels, each with independent 256-level PWM control.
> +Each LED is represented as a sub-node of the device.
> +
> +Required properties:
> +- compatible: one of
> + issi,is31fl3236
> + issi,is31fl3235
> + issi,is31fl3218
> + issi,is31fl3216
> +- reg: I2C slave address
> +- address-cells : must be 1
> +- size-cells : must be 0
> +
> +LED sub-node properties:
> +- reg : LED channel number (1..N)
> +- label :  (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +- linux,default-trigger :  (optional)
> +  see Documentation/devicetree/bindings/leds/common.txt
> +
> +
> +Example:
> +
> +leds: is31fl3236@3c {

Other way around: is31fl3236: leds@3c

Otherwise,

Acked-by: Rob Herring 

Re: [PATCH 1/2] Documentation: synopsys-dw-mshc: add binding for resets

[Rob Herring]

On Thu, Mar 03, 2016 at 09:33:37AM +0800, Guodong Xu wrote:
> Add resets property to synopsys-dw-mshc bindings. It is intended to
> represent the hardware reset signal present internally in some host
> controller IC designs.
> 
> See Documentation/devicetree/bindings/reset/reset.txt for details.
> 
> Signed-off-by: Guodong Xu 
> ---
>  Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt 
> b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> index 8636f5a..9b4896c 100644
> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> @@ -39,6 +39,10 @@ Required Properties:
>  
>  Optional properties:
>  
> +* resets: phandle + reset specifier pair, intended to represent hardware
> +  reset signal present internally in some host controller IC designs.
> +  See Documentation/devicetree/bindings/reset/reset.txt for details.
> +
>  * clocks: from common clock binding: handle to biu and ciu clocks for the
>bus interface unit clock and the card interface unit clock.
>  
> @@ -48,7 +52,7 @@ Optional properties:
>clock-frequency.  It is an error to omit both the ciu clock and the
>clock-frequency.
>  
> -* clock-frequency: should be the frequency (in Hz) of the ciu clock.  If this
> +* clock-frequency: should be tke frequency (in Hz) of the ciu clock.  If this

You've added a typo here.

Otherwise,

Acked-by: Rob Herring 

Re: [PATCH v2 1/2] phy: rcar-gen2: add fallback binding

[Rob Herring]

On Thu, Mar 03, 2016 at 09:38:37AM +0900, Simon Horman wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
> 
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
> 
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
> 
> Signed-off-by: Simon Horman 
> ---
> v2
> * Use renesas,rcar-gen2-usb-phy rather than renesas,usb-phy-gen2 as
>   the new compatibility string to fit in with the preferred scheme
>   for new compatibility string names.
> ---
>  Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 8 +++-
>  drivers/phy/phy-rcar-gen2.c | 1 +
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt 
> b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> index d564ba4f1cf6..feb1c3c102c2 100644
> --- a/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt
> @@ -7,6 +7,12 @@ Required properties:
>  - compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 
> SoC.
> "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
> "renesas,usb-phy-r8a7794" if the device is a part of R8A7794 SoC.
> +   "renesas,rcar-gen2-usb-phy" for a generic R-Car Gen2 compatible 
> device.
> +
> +   When compatible with the generic version, nodes must list the
> +   SoC-specific version corresponding to the platform first
> +   followed by the generic version.
> +
>  - reg: offset and length of the register block.
>  - #address-cells: number of address cells for the USB channel subnodes, must
> be <1>.
> @@ -34,7 +40,7 @@ the USB channel; see the selector meanings below:
>  Example (Lager board):
>  
>   usb-phy@e6590100 {
> - compatible = "renesas,usb-phy-r8a7790";
> + compatible = 
> "renesas,usb-phy-r8a7790","renesas,rcar-gen2-usb-phy";
Space here ^

Otherwise,

Acked-by: Rob Herring 

Re: [PATCH v10] serial: support for 16550A serial ports on LP-8x4x

[Rob Herring]

On Wed, Mar 02, 2016 at 12:25:35AM +0300, Sergei Ianovich wrote:
> The patch adds support for 3 additional LP-8x4x built-in serial
> ports.
> 
> The device can also host up to 8 extension cards with 4 serial ports
> on each card for a total of 35 ports. However, I don't have
> the hardware to test extension cards, so they are not supported, yet.

That's a lot of serial ports...

[...]

> diff --git a/Documentation/devicetree/bindings/serial/icpdas-lp8841-uart.txt 
> b/Documentation/devicetree/bindings/serial/icpdas-lp8841-uart.txt
> new file mode 100644
> index 000..d6acd22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/icpdas-lp8841-uart.txt
> @@ -0,0 +1,41 @@
> +* UART ports on ICP DAS LP-8841
> +
> +LP-8441, LP-8141 and LP-8041 are fully compatible.
> +
> +ICP DAS LP-8841 contains three additional serial ports interfaced via
> +Analog Devices ADM213EA chips in addition to 3 serial ports on PXA CPU.
> +
> +The chips themselves are standard, they would work with 8250_core if

Describe in h/w terms how they are different, not what Linux driver 
won't work.

> +properly connected. However, they are not connected normally. Al least

s/Al/At/

> +some of their config pins are wired to a different address region. So
> +the driver is board-specific.
> +
> +Required properties:
> +- compatible : should be "icpdas,uart-lp8841"
> +
> +- reg : should provide 16 byte man IO memory region and 1 byte region for

What is "man IO"?

> + termios

termios is a Linux term.

> +
> +- interrupts : should provide interrupt

Perhaps you should include other properties standard for 8250 such as 
access size or shift. Possibly if the non-standard bits are already 
configured, the UART could be used for earlycon?

> +
> +Optional property:
> +- interrupt-parent : should provide a link to interrupt controller either
> +  explicitly or implicitly from a parent node
> +
> +Examples (from pxa27x-lp8x4x.dts):
> +
> + serial@9050 {
> + compatible = "icpdas,uart-lp8841";
> + reg = <0x9050 0x10
> +0x9030 0x02>;
> + interrupts = <13>;
> + status = "okay";
> + };
> +
> + serial@9060 {
> + compatible = "icpdas,uart-lp8841";
> + reg = <0x9060 0x10
> +0x9032 0x02>;
> + interrupts = <14>;
> + status = "okay";
> + };

[...]

> diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
> index 3b5cf9c..68640c1 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -394,3 +394,17 @@ config SERIAL_8250_PXA
>   help
> If you have a machine based on an Intel XScale PXA2xx CPU you
> can enable its onboard serial ports by enabling this option.
> +
> +   If you choose M here, the module name will be 8250_pxa.
> +
> +config SERIAL_8250_LP8841
> + tristate "Support 16550A ports on ICP DAS LP-8841"
> + depends on SERIAL_8250 && MACH_PXA27X_DT
> + select LP8841_IRQ

Generally, drivers don't select their interrupt controller.

> + help
> +   In addition to serial ports on PXA270 SoC, LP-8841 has 1 dual
> +   RS232/RS485 port, 1 RS485 port and 1 RS232 port.
> +
> +   Say N here, unless you plan to run this kernel on a LP-8841 system.
> +
> +   If you choose M here, the module name will be 8250_lp8841.

> diff --git a/drivers/tty/serial/8250/Makefile 
> b/drivers/tty/serial/8250/Makefile
> index d1e2f2d..10b4bf0 100644
> --- a/drivers/tty/serial/8250/Makefile
> +++ b/drivers/tty/serial/8250/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_SERIAL_8250_ACCENT)+= 8250_accent.o

>  obj-$(CONFIG_SERIAL_8250_BOCA)   += 8250_boca.o
>  obj-$(CONFIG_SERIAL_8250_EXAR_ST16C554)  += 8250_exar_st16c554.o
>  obj-$(CONFIG_SERIAL_8250_HUB6)   += 8250_hub6.o
> +obj-$(CONFIG_SERIAL_8250_LP8X4X) += 8250_lp8x4x.o

This should be dropped.

>  obj-$(CONFIG_SERIAL_8250_FSL)+= 8250_fsl.o
>  obj-$(CONFIG_SERIAL_8250_DW) += 8250_dw.o
>  obj-$(CONFIG_SERIAL_8250_EM) += 8250_em.o
> @@ -30,5 +31,6 @@ obj-$(CONFIG_SERIAL_8250_INGENIC)   += 8250_ingenic.o
>  obj-$(CONFIG_SERIAL_8250_MID)+= 8250_mid.o
>  obj-$(CONFIG_SERIAL_OF_PLATFORM) += 8250_of.o
>  obj-$(CONFIG_SERIAL_8250_PXA)+= 8250_pxa.o
> +obj-$(CONFIG_SERIAL_8250_LP8841) += 8250_lp8841.o

This should be in alphabetical order. OF_PLATFORM is not for legacy 
reasons I think.

>  
>  CFLAGS_8250_ingenic.o += -I$(srctree)/scripts/dtc/libfdt
> -- 
> 2.7.0
> 

Re: [PATCH v2 5/6] Documentation: devicetree: amlogic: Document Tronsmart Vega S95 boards

[Rob Herring]

On Wed, Mar 02, 2016 at 03:35:00AM +0100, Andreas Färber wrote:
> Use "tronsmart,vega-s95" as well as
> "tronsmart,vega-s95-pro",
> "tronsmart,vega-s95-meta" and
> "tronsmart,vega-s95-telos" compatible strings.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v1 -> v2: unchanged
>  
>  Documentation/devicetree/bindings/arm/amlogic.txt | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v10] serial: support for 16550A serial ports on LP-8x4x

[Rob Herring]

On Wed, Mar 02, 2016 at 12:25:35AM +0300, Sergei Ianovich wrote:
> The patch adds support for 3 additional LP-8x4x built-in serial
> ports.
> 
> The device can also host up to 8 extension cards with 4 serial ports
> on each card for a total of 35 ports. However, I don't have
> the hardware to test extension cards, so they are not supported, yet.

That's a lot of serial ports...

[...]

> diff --git a/Documentation/devicetree/bindings/serial/icpdas-lp8841-uart.txt 
> b/Documentation/devicetree/bindings/serial/icpdas-lp8841-uart.txt
> new file mode 100644
> index 000..d6acd22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/icpdas-lp8841-uart.txt
> @@ -0,0 +1,41 @@
> +* UART ports on ICP DAS LP-8841
> +
> +LP-8441, LP-8141 and LP-8041 are fully compatible.
> +
> +ICP DAS LP-8841 contains three additional serial ports interfaced via
> +Analog Devices ADM213EA chips in addition to 3 serial ports on PXA CPU.
> +
> +The chips themselves are standard, they would work with 8250_core if

Describe in h/w terms how they are different, not what Linux driver 
won't work.

> +properly connected. However, they are not connected normally. Al least

s/Al/At/

> +some of their config pins are wired to a different address region. So
> +the driver is board-specific.
> +
> +Required properties:
> +- compatible : should be "icpdas,uart-lp8841"
> +
> +- reg : should provide 16 byte man IO memory region and 1 byte region for

What is "man IO"?

> + termios

termios is a Linux term.

> +
> +- interrupts : should provide interrupt

Perhaps you should include other properties standard for 8250 such as 
access size or shift. Possibly if the non-standard bits are already 
configured, the UART could be used for earlycon?

> +
> +Optional property:
> +- interrupt-parent : should provide a link to interrupt controller either
> +  explicitly or implicitly from a parent node
> +
> +Examples (from pxa27x-lp8x4x.dts):
> +
> + serial@9050 {
> + compatible = "icpdas,uart-lp8841";
> + reg = <0x9050 0x10
> +0x9030 0x02>;
> + interrupts = <13>;
> + status = "okay";
> + };
> +
> + serial@9060 {
> + compatible = "icpdas,uart-lp8841";
> + reg = <0x9060 0x10
> +0x9032 0x02>;
> + interrupts = <14>;
> + status = "okay";
> + };

[...]

> diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
> index 3b5cf9c..68640c1 100644
> --- a/drivers/tty/serial/8250/Kconfig
> +++ b/drivers/tty/serial/8250/Kconfig
> @@ -394,3 +394,17 @@ config SERIAL_8250_PXA
>   help
> If you have a machine based on an Intel XScale PXA2xx CPU you
> can enable its onboard serial ports by enabling this option.
> +
> +   If you choose M here, the module name will be 8250_pxa.
> +
> +config SERIAL_8250_LP8841
> + tristate "Support 16550A ports on ICP DAS LP-8841"
> + depends on SERIAL_8250 && MACH_PXA27X_DT
> + select LP8841_IRQ

Generally, drivers don't select their interrupt controller.

> + help
> +   In addition to serial ports on PXA270 SoC, LP-8841 has 1 dual
> +   RS232/RS485 port, 1 RS485 port and 1 RS232 port.
> +
> +   Say N here, unless you plan to run this kernel on a LP-8841 system.
> +
> +   If you choose M here, the module name will be 8250_lp8841.

> diff --git a/drivers/tty/serial/8250/Makefile 
> b/drivers/tty/serial/8250/Makefile
> index d1e2f2d..10b4bf0 100644
> --- a/drivers/tty/serial/8250/Makefile
> +++ b/drivers/tty/serial/8250/Makefile
> @@ -18,6 +18,7 @@ obj-$(CONFIG_SERIAL_8250_ACCENT)+= 8250_accent.o

>  obj-$(CONFIG_SERIAL_8250_BOCA)   += 8250_boca.o
>  obj-$(CONFIG_SERIAL_8250_EXAR_ST16C554)  += 8250_exar_st16c554.o
>  obj-$(CONFIG_SERIAL_8250_HUB6)   += 8250_hub6.o
> +obj-$(CONFIG_SERIAL_8250_LP8X4X) += 8250_lp8x4x.o

This should be dropped.

>  obj-$(CONFIG_SERIAL_8250_FSL)+= 8250_fsl.o
>  obj-$(CONFIG_SERIAL_8250_DW) += 8250_dw.o
>  obj-$(CONFIG_SERIAL_8250_EM) += 8250_em.o
> @@ -30,5 +31,6 @@ obj-$(CONFIG_SERIAL_8250_INGENIC)   += 8250_ingenic.o
>  obj-$(CONFIG_SERIAL_8250_MID)+= 8250_mid.o
>  obj-$(CONFIG_SERIAL_OF_PLATFORM) += 8250_of.o
>  obj-$(CONFIG_SERIAL_8250_PXA)+= 8250_pxa.o
> +obj-$(CONFIG_SERIAL_8250_LP8841) += 8250_lp8841.o

This should be in alphabetical order. OF_PLATFORM is not for legacy 
reasons I think.

>  
>  CFLAGS_8250_ingenic.o += -I$(srctree)/scripts/dtc/libfdt
> -- 
> 2.7.0
> 

Re: [PATCH v2 5/6] Documentation: devicetree: amlogic: Document Tronsmart Vega S95 boards

[Rob Herring]

On Wed, Mar 02, 2016 at 03:35:00AM +0100, Andreas Färber wrote:
> Use "tronsmart,vega-s95" as well as
> "tronsmart,vega-s95-pro",
> "tronsmart,vega-s95-meta" and
> "tronsmart,vega-s95-telos" compatible strings.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v1 -> v2: unchanged
>  
>  Documentation/devicetree/bindings/arm/amlogic.txt | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH v2 3/6] Documentation: devicetree: amlogic: Document Meson GXBaby

[Rob Herring]

On Wed, Mar 02, 2016 at 03:34:58AM +0100, Andreas Färber wrote:
> Use "amlogic,meson-gxbb" compatible string.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v1 -> v2: unchanged
>  
>  Documentation/devicetree/bindings/arm/amlogic.txt | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH V2 RESEND 1/4] regulator: DT: Add DT property for active-discharge configuration

[Rob Herring]

On Wed, Mar 02, 2016 at 04:24:45PM +0530, Laxman Dewangan wrote:
> Add common DT property for regulator node to support of
> active discharge enable/disable configuration of regulator.
> 
> Signed-off-by: Laxman Dewangan 
> ---
> Changes from V1:
>  None
> 
>  Documentation/devicetree/bindings/regulator/regulator.txt | 5 +
>  1 file changed, 5 insertions(+)

Looks okay to me, but for a common property I don't understand what 
active discharge means (or why you would want to use it).

Acked-by: Rob Herring 

Re: [PATCH V2 RESEND 1/4] regulator: DT: Add DT property for active-discharge configuration

[Rob Herring]

On Wed, Mar 02, 2016 at 04:24:45PM +0530, Laxman Dewangan wrote:
> Add common DT property for regulator node to support of
> active discharge enable/disable configuration of regulator.
> 
> Signed-off-by: Laxman Dewangan 
> ---
> Changes from V1:
>  None
> 
>  Documentation/devicetree/bindings/regulator/regulator.txt | 5 +
>  1 file changed, 5 insertions(+)

Looks okay to me, but for a common property I don't understand what 
active discharge means (or why you would want to use it).

Acked-by: Rob Herring 

Re: [PATCH v2 3/6] Documentation: devicetree: amlogic: Document Meson GXBaby

[Rob Herring]

On Wed, Mar 02, 2016 at 03:34:58AM +0100, Andreas Färber wrote:
> Use "amlogic,meson-gxbb" compatible string.
> 
> Signed-off-by: Andreas Färber 
> ---
>  v1 -> v2: unchanged
>  
>  Documentation/devicetree/bindings/arm/amlogic.txt | 4 
>  1 file changed, 4 insertions(+)

Acked-by: Rob Herring 

Re: [PATCH 1/3] Documentation: dt: Add Broadcom iproc pwm controller binding

[Rob Herring]

On Tue, Mar 01, 2016 at 12:42:47PM -0500, Yendapally Reddy Dhananjaya Reddy 
wrote:
> Add a binding for Broadcom iproc pwm controller
> 
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 
> 
> ---
>  Documentation/devicetree/bindings/pwm/brcm,kona-pwm.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Rob Herring 

Re: [PATCH v3 4/7] bindings: move cpm_qe binding from powerpc/fsl to soc/fsl

[Rob Herring]

On Tue, Mar 01, 2016 at 03:09:40PM +0800, Zhao Qiang wrote:
> cpm_qe is supported on both powerpc and arm.
> and the QE code has been moved from arch/powerpc into
> drivers/soc/fsl, so move cpm_qe binding from powerpc/fsl
> to soc/fsl
> 
> Signed-off-by: Zhao Qiang 
> ---

I already acked this. In the future, please add acks on subsequent revs.

Acked-by: Rob Herring 

Re: [RFC v2 1/3] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[Rob Herring]

On Tue, Mar 01, 2016 at 09:29:14PM +0800, HS Liao wrote:
> This adds documentation for the MediaTek Global Command Engine (GCE) unit
> found in MT8173 SoCs.
> 
> Signed-off-by: HS Liao 
> ---
>  .../devicetree/bindings/soc/mediatek/gce.txt   |   34 
> 
>  1 file changed, 34 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/soc/mediatek/gce.txt

Acked-by: Rob Herring 

Re: [PATCH 2/5] Documentation: dt: socfpga: Add Altera Arri10 L2 cache binding

[Rob Herring]

On Tue, Mar 01, 2016 at 10:38:18AM -0600, ttha...@opensource.altera.com wrote:
> From: Thor Thayer 
> 
> Add the device tree binding string needed to support the Altera L2
> cache on the Arria10 chip.
> 
> Signed-off-by: Thor Thayer 
> ---
>  .../bindings/arm/altera/socfpga-eccmgr.txt |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Acked-by: Rob Herring