Re: [PATCH 01/10] staging: lustre: LNet drop rule implementation
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
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(&atchan->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",
&lli->saddr, &lli->daddr,
lli->ctrla, lli->ctrlb, &lli->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", &dev->res->start);
+ cal_info(dev, "CAL Registers @ %pa:\n", &dev->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",
&pmem->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", &map->phys_addr);
+ rmcd_debug(MMAP, "%pad", &map->phys_addr);
kref_get(&map->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", &map->phys_addr);
+ rmcd_debug(MMAP, "%pad", &map->phys_addr);
mutex_lock(&map->md->buf_mutex);
kref_put(&map->ref, mport_release_mapping);
mutex_unlock(&map->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, &priv->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, &lstart, 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, &priv->pdev->dev,
- "Translated (RIO_0x%llx -> PCIe_0x%pad), size=0x%x",
+ "Translated (RIO_0x%llx -> PCIe_%pad), size=0x%x",
rstart, &lstart, 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, &priv->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, &loc_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, &priv->pdev->dev,
- "Unmap IBW mapped to PCIe_0x%pad", &lstart);
+
Re: [PATCH 1/2] sigaltstack: implement SS_AUTODISARM flag
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
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
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(&agent->lock);
> agent->state = AGENT_STATE_DEAD;
> spin_unlock_bh(&agent->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
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
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
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
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
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
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(&master->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
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
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
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
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,
+ &max_vfn, &max_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 0x2
Re: [PATCH 4/4] leds: Replace dedicated SN3218 driver with IS31FL32XX driver
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
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 led_classdev.brightne
Re: [9/9] powerpc: optimise csum_partial() call when len is constant
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
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
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
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
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"
> -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
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 = <&rst LWHPS2FPGA_RESET>;
> + reset-names = "lwhps2fpga";
> + clocks = <&l4_main_clk>;
> + bridge-enable = <0>;
> + };
> +
> + hps_fpgabridge1: fpgabridge@ff50 {
> + compatible = "altr,socfpga-hps2fpga-bridge";
> + reg = <0xff50 0x1>;
> + resets = <&rst HPS2FPGA_RESET>;
> + reset-names = "hps2fpga";
> + clocks = <&l4_main_clk>;
> + bridge-enable = <1>;
> + };
> +
> + hps_fpgabridge2: fpgabridge@ff60 {
> + compatible = "altr,socfpga-fpga2hps-bridge";
> + reg = <0xff60 0x10>;
> + resets = <&rst FPGA2HPS_RESET>;
> + reset-names = "fpga2hps";
> + clocks = <&l4_main_clk>;
> + };
> --
> 1.7.9.5
>
Re: [PATCH 0/2] [media] exynos4-is: Trivial fixes for DT port/endpoint parse logic
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 1/9] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
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
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
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
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 = <&rcc 0 25>, <&rcc 0 26>, <&rcc 0 27>;
> + st,syscon = <&syscfg 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
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 1/3] pinctrl: Broadcom Northstar2 pinctrl device tree bindings
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
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
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
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
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 = <&clock_node>;
> + clock-names = "pxlclk";
Where's the port? Didn't you previously say it was optional?
> + };
> +
> + ...
> +};
> --
> 2.5.0
>
Re: [PATCH 01/17] dt-bindings: vendor-prefixes: Add PLX Technology
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
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
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
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.
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
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 = <&mstp7_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
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
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
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
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
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 RESEND 1/4] regulator: DT: Add DT property for active-discharge configuration
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
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
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
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
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
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
Re: [PATCH v3 3/7] QE: Add uqe_serial document to bindings
On Tue, Mar 01, 2016 at 03:09:39PM +0800, Zhao Qiang wrote:
> Add uqe_serial document to
> Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2
> - modify tx/rx-clock-name specification
> Changes for v2
> - NA
>
> .../bindings/powerpc/fsl/cpm_qe/uqe_serial.txt| 19
> +++
> 1 file changed, 19 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
>
> diff --git
> a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> new file mode 100644
> index 000..436c71c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/uqe_serial.txt
> @@ -0,0 +1,19 @@
> +* Serial
> +
> +Currently defined compatibles:
> +- ucc_uart
I guess this is in use already and okay. However, looking at the driver
there really should be SoC specific compatible strings here since the
driver is looking up the SoC compatible string and composing the
firmware filename from that.
> +
> +Properties for ucc_uart:
> +port-number : port number of UCC-UART
> +tx/rx-clock-name : should be "brg1"-"brg16" for internal clock source,
> +should be "clk1"-"clk28" for external clock source.
> +
> +Example:
> +
> + ucc_serial: ucc@2200 {
> + device_type = "serial";
Drop device_type. It should only be used in a few legacy cases.
Looks like the driver is matching on this. Please drop it from the
driver too. I'd leave dts files for now, but they should be updated too
later.
> + compatible = "ucc_uart";
> + port-number = <1>;
> + rx-clock-name = "brg2";
> + tx-clock-name = "brg2";
> + };
> --
> 2.1.0.27.g96db324
>
Re: [PATCH v3 2/7] QE: Add ucc hdlc document to bindings
On Tue, Mar 01, 2016 at 03:09:38PM +0800, Zhao Qiang wrote: > Add ucc hdlc document to > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt > > Signed-off-by: Zhao Qiang > --- > Changes for v2 > - use ucc-hdlc instead of ucc_hdlc > - add more information to properties. > Changes for v3 > - use fsl,tx-timeslot-mask instead of fsl,tx-timeslot > - use fsl,rx-timeslot-mask instead of fsl,rx-timeslot > - add more info > > .../bindings/powerpc/fsl/cpm_qe/network.txt| 81 > ++ > 1 file changed, 81 insertions(+) Acked-by: Rob Herring
Re: [PATCH v3 1/7] QE: Add IC, SI and SIRAM document to device tree bindings.
On Tue, Mar 01, 2016 at 03:09:37PM +0800, Zhao Qiang wrote: > Add IC, SI and SIRAM document of QE to > Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt > > Signed-off-by: Zhao Qiang > --- > Changes for v2 > - Add interrupt-controller in Required properties > - delete address-cells and size-cells for qe-si and qe-siram > Changes for v3 > - Add SoC specific caompatible strings to qe-si and qe-siram > > .../devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt | 50 > ++ > 1 file changed, 50 insertions(+) Acked-by: Rob Herring
Re: [PATCH V5 01/15] ACPI: MCFG: Move mmcfg_list management to drivers/acpi
On Fri, Mar 04, 2016 at 02:05:56PM +0530, Jayachandran Chandrashekaran Nair
wrote:
> On Fri, Mar 4, 2016 at 4:21 AM, Bjorn Helgaas wrote:
> > Hi Tomasz, Jayachandran, et al,
> >
> > On Tue, Feb 16, 2016 at 02:53:31PM +0100, Tomasz Nowicki wrote:
> >> From: Jayachandran C
> >>
> >> Move pci_mmcfg_list handling to a drivers/acpi/pci_mcfg.c. This is
> >> to share the API and code with ARM64 later. The corresponding
> >> declarations are moved from asm/pci_x86.h to linux/pci-acpi.h
> >>
> >> As a part of this we introduce three functions that can be
> >> implemented by the arch code: pci_mmconfig_map_resource() to map a
> >> mcfg entry, pci_mmconfig_unmap_resource to do the corresponding
> >> unmap and pci_mmconfig_enabled to see if the arch setup of
> >> mcfg entries was successful. We also provide weak implementations
> >> of these, which will be used from ARM64. On x86, we retain the
> >> old logic by providing platform specific implementation.
> >>
> >> This patch is purely rearranging code, it should not have any
> >> impact on the logic of MCFG parsing or list handling.
> >
> > I definitely want to figure out how to make this work well on ARM64.
> > I need to ponder this some more, so these are just some initial
> > thoughts.
> >
> > My first impression is that (a) the x86 MCFG code is an unmitigated
> > disaster, and (b) we're trying a little too hard to make that mess
> > generic. I think we might be better served if we came up with some
> > cleaner, more generic code that we can use for ARM64 today, and
> > migrate x86 toward that over time.
> >
> > My concern is that if we elevate the current x86 code to be
> > "arch-independent", we will be perpetuating some interfaces and
> > designs that shouldn't be allowed to escape arch/x86.
>
> I think the major decision is whether to maintain the pci_mmcfg_list
> for all architectures or not. My initial plan was not to do this because
> of the mess (basically the ECAM region info should be attached to
> the pci root and not maintained in a separate list that needs locking),
> The patch I posted initially https://patchwork.ozlabs.org/patch/553464/
> had a much simpler way of handling the MCFG table without using
> the list.
I agree that ECAM info should be attached to the PCI host controller.
That should simplify locking and hot-add and hot-removal of host
controllers.
I think pci_mmcfg_list is an implementation detail that may not need
to be generic. I certainly don't think it needs to be part of the
interface.
> In x86 case it is not feasible to remove using the pci_mmcfg_list.
> The only use of it outside is in xen that can be fixed up.
>
> > Some of the code that moved to drivers/acpi/pci_mcfg.c is not really
> > ACPI-specific, and could potentially be used for non-ACPI bridges that
> > support ECAM. I'd like to see that sort of code moved to a new file
> > like drivers/pci/ecam.c.
> >
> > There's a little bit of overlap here with the ECAM code in
> > pci-host-generic.c. I'm not sure whether or how to include that, but
> > it's a very good example of how simple this *should* be: probe the
> > host bridge, discover the ECAM region, request the region, ioremap it,
> > done.
>
> I had a similar approach in my initial patchset, please see the patch
> above. The resource for ECAM is mapped similar to the the way
> pci-host-generic.c handled it. An additional step I could do was to
> move the common code (ioremap and mapbus) into a common
> file and share the code with pci-host-generic.c
>
> >> diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c
> >> new file mode 100644
> >> index 000..ea84365
> >> --- /dev/null
> >> +++ b/drivers/acpi/pci_mcfg.c
> >> ...
> >> +int __weak pci_mmconfig_map_resource(struct device *dev,
> >> + struct pci_mmcfg_region *mcfg)
> >> +{
> >> + struct resource *tmp;
> >> + void __iomem *vaddr;
> >> +
> >> + tmp = insert_resource_conflict(&iomem_resource, &mcfg->res);
> >> + if (tmp) {
> >> + dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
> >> + &mcfg->res, tmp->name, tmp);
> >> + return -EBUSY;
> >> + }
> >
> > I think this is a mistake in the x86 MCFG support that we should not
> > carry over to a generic implementation. We should not use the MCFG
> > table for resource reservation because MCFG is not defined by the ACPI
> > spec and an OS need not include support for it. The platform must
> > indicate in some other, more generic way, that ECAM space is reserved.
> > This probably means ECAM space should be declared in a PNP0C02 _CRS
> > method (see the PCI Firmware Spec r3.0, sec 4.1.2, note 2).
> >
> > We might need some kind of x86-specific quirk that does this, or a
> > pcibios hook or something here; I just don't think it should be
> > generic.
> >
> >> +int __init pci_mmconfig_parse_table(void)
> >> +{
> >> + return acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
> >> +}
> >
> > I don't like the fact that we parse th
Re: [4/9] powerpc: inline ip_fast_csum()
On Tue, Sep 22, 2015 at 04:34:25PM +0200, Christophe Leroy wrote:
> @@ -137,6 +130,45 @@ static inline __wsum csum_add(__wsum csum, __wsum addend)
> #endif
> }
>
> +/*
> + * This is a version of ip_compute_csum() optimized for IP headers,
> + * which always checksum on 4 octet boundaries. ihl is the number
> + * of 32-bit words and is always >= 5.
> + */
> +static inline __wsum ip_fast_csum_nofold(const void *iph, unsigned int ihl)
> +{
> + u32 *ptr = (u32 *)iph + 1;
const?
> +#ifdef __powerpc64__
> + unsigned int i;
> + u64 s = *(__force u32 *)iph;
const?
Why __force?
> + s += (s >> 32);
> + return (__force __wsum)s;
> +
> +#else
> + __wsum sum, tmp;
> +
> + asm("mtctr %3;"
> + "addc %0,%4,%5;"
> + "1:lwzu %1, 4(%2);"
> + "adde %0,%0,%1;"
> + "bdnz 1b;"
> + "addze %0,%0;"
> + : "=r"(sum), "=r"(tmp), "+b"(ptr)
> + : "r"(ihl - 2), "r"(*(u32 *)iph), "r"(*ptr)
> + : "ctr", "xer", "memory");
Space between " and (
Space after :
const in cast
I've fixed these up while applying.
-Scott
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
Hi Arnd,
[auto build test WARNING on staging/staging-testing]
[also build test WARNING 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/Arnd-Bergmann/isdn-icn-remove-a-warning/20160303-031435
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 warnings (new ones prefixed by >>):
In file included from arch/m68k/include/asm/io_mm.h:26:0,
from arch/m68k/include/asm/io.h:4,
from include/linux/io.h:25,
from drivers/staging/i4l/icn/icn.h:41,
from drivers/staging/i4l/icn/icn.c:12:
drivers/staging/i4l/icn/icn.c: In function 'icn_shiftout':
arch/m68k/include/asm/raw_io.h:43:32: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
#define out_8(addr,b) (void)((*(__force volatile u8 *) (addr)) = (b))
^
arch/m68k/include/asm/io_mm.h:396:72: note: in expansion of macro 'out_8'
#define outb(val, port) ((port) < 1024 ? isa_rom_outb((val), (port)) :
out_8((port), (val)))
^
>> drivers/staging/i4l/icn/icn.h:59:16: note: in expansion of macro 'outb'
#define OUTB_P outb
^
>> drivers/staging/i4l/icn/icn.c:89:3: note: in expansion of macro 'OUTB_P'
OUTB_P((u_char) ((val >> s) & 1) ? 0xff : 0, port);
^
vim +/outb +59 drivers/staging/i4l/icn/icn.h
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 35 #ifdef __KERNEL__
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 36 /* Kernel
includes */
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 37
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 38 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 39 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 40 #include
2584cf83 drivers/isdn/icn/icn.h Dan Williams 2015-08-10 @41 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 42 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 43 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 44 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 45 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 46 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 47 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 48 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 49 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 50 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 51 #include
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 52
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 53 #endif
/* __KERNEL__ */
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 54
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 55 /* some useful
macros for debugging */
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 56 #ifdef
ICN_DEBUG_PORT
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 57 #define
OUTB_P(v, p) {printk(KERN_DEBUG "icn: outb_p(0x%02x,0x%03x)\n", v, p);
outb_p(v, p);}
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 58 #else
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 @59 #define OUTB_P
outb
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 60 #endif
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 61
^1da177e drivers/isdn/icn/icn.h Linus Torvalds 2005-04-16 62 /* Defaults for
Port-Address and shared-memory */
:: The code at line 59 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2
:: TO: Linus Torvalds
:: CC: Linus Torvalds
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v6 0/3] fallocate for block devices to provide zero-out
On Fri, Mar 4, 2016 at 4:55 PM, Darrick J. Wong wrote: > > This is a redesign of the patch series that fixes various interface > problems with the existing "zero out this part of a block device" > code. BLKZEROOUT2 is gone. I replied to two of the patches with small nits, but on the whole I like it. The only nit that I think is serious is that you shouldn't be requiring people to have to use FALLOC_FL_KEEP_SIZE. If anything, you might just change that logic to say: If FALLOC_FL_KEEP_SIZE is set, then we truncate the hole punching/zeroing to the size of the device. So people could do something like fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, 0, ~0); to trim the whole device (and if FALLOC_FL_KEEP_SIZE isn't set, then the above would be an error simply because the requested hole was bigger than the device) Linus
Re: [PATCH 3/3] block: implement (some of) fallocate for block devices
On Fri, Mar 4, 2016 at 4:56 PM, Darrick J. Wong wrote: > + > + /* We can't change the bdev size from here */ > + if (!(mode & FALLOC_FL_KEEP_SIZE)) > + return -EOPNOTSUPP; Oh, and this I think is wrong. The thing is, FALLOC_FL_KEEP_SIZE is only supposed to matter if the region is outside the existing length. So if y ou punch a hole in the middle of a file, you don't need FALLOC_FL_KEEP_SIZE. I would suggest removing this check entirely, since you already check that people don't try to punch holes past the end of the device. So FALLOC_FL_KEEP_SIZE is simply a non-issue, and shouldn't even be checked. Linus
Re: [PATCH] mtd: nand: pxa3xx_nand: fix dmaengine initialization
On Fri, Feb 12, 2016 at 11:29:04PM +0100, Robert Jarzmik wrote:
> When the driver is initialized in a pure device-tree platform, the
> driver's probe fails allocating the dma channel :
> [ 525.624435] pxa3xx-nand 4310.nand: no resource defined for data DMA
> [ 525.632088] pxa3xx-nand 4310.nand: alloc nand resource failed
>
> The reason is that the DMA IO resource is not acquired through platform
> resources but by OF bindings.
>
> Fix this by ensuring that DMA IO resources are only queried in the non
> device-tree case.
>
> Fixes: 8f5ba31aa565 ("mtd: nand: pxa3xx-nand: switch to dmaengine")
> Signed-off-by: Robert Jarzmik
Applied to l2-mtd.git
Re: [PATCH 3/3] block: implement (some of) fallocate for block devices
On Fri, Mar 4, 2016 at 4:56 PM, Darrick J. Wong wrote: > + /* Only punch if the device can do zeroing discard. */ > + if ((mode & FALLOC_FL_PUNCH_HOLE) && > + (!blk_queue_discard(q) || !q->limits.discard_zeroes_data)) > + return -EOPNOTSUPP; I'm ok with this, but suspect that some users would prefer to just turn this into ZERO_RANGE silently. Comments from people who would be expected to use this? Linus
Re: [PATCH 2/3] block: require write_same and discard requests align to logical block size
On Fri, Mar 4, 2016 at 4:56 PM, Darrick J. Wong wrote: > > + bs_mask = (bdev_logical_block_size(bdev) >> 9) - 1; > + if ((sector & bs_mask) || ((sector + nr_sects) & bs_mask)) > + return -EINVAL; This test may _work_, but it's kind of crazily overly complicated. The sane test would be just "are the start and length aligned": if ((sector & bs_mask) || (nr_sects & bs_mask)) return -EINVAL; and the *smart* test is simpler still, and asks "are there invalid bits in either the start or the length": if ((sector | nr_sects) & bs_mask) return -EINVAL: I suspect either of these would be fine, and the compiler may even notice that there's the smart way of doing it. The compiler *might* even notice that the original version can be simplified and generate sane code. But I think that original version is not only overly complicated, it's also actually less obvious than the simpler versions, if only because the whole conditional is so big that you have to actively parse it. That last shortest form is actually so simple that I think it's the easiest to understand too - the conditional is simply so small that it doesn't take a lot of effort to see what it does. Linus
Re: [PATCH 07/10] staging: lustre: add last missing sparse annotation __user
On Mar 4, 2016, at 9:09 PM, James Simmons wrote: > From: Frank Zago > > One of the __user was missed in being applied to upstream > client. This is broken out of patch 11819. It was not, the bug was fixed in another way. > Signed-off-by: Frank Zago > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5396 > Reviewed-on: http://review.whamcloud.com/11819 > Reviewed-by: James Simmons > Reviewed-by: Dmitry Eremin > Reviewed-by: Oleg Drokin > --- > drivers/staging/lustre/lnet/lnet/api-ni.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/staging/lustre/lnet/lnet/api-ni.c > b/drivers/staging/lustre/lnet/lnet/api-ni.c > index a666d49..7395985 100644 > --- a/drivers/staging/lustre/lnet/lnet/api-ni.c > +++ b/drivers/staging/lustre/lnet/lnet/api-ni.c > @@ -2041,7 +2041,7 @@ LNetCtl(unsigned int cmd, void *arg) > id.nid = data->ioc_nid; > id.pid = data->ioc_u32[0]; > rc = lnet_ping(id, data->ioc_u32[1], /* timeout */ > -data->ioc_pbuf1, > +(lnet_process_id_t __user *)data->ioc_pbuf1, We do not need this one anymore, since ioc_pbuf1 is defned as user now: drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h: void __user *ioc_pbuf1; > data->ioc_plen1 / sizeof(lnet_process_id_t)); > if (rc < 0) > return rc; > -- > 1.7.1 >
Re: [PATCH v11 17/24] perf config: Collect configs to handle config variables
On 03/04/2016 10:58 PM, Namhyung Kim wrote: Hi Taeung, On Fri, Mar 04, 2016 at 09:45:44PM +0900, Taeung Song wrote: Hi, Namhyung and all (I'm modifying this patch to be tidy) I have a mere question about name of a variable for current config list that contains section list which has key-value pairs from ~/.perfconfig or $(sysconfdir)/perfconfig config file. (This variable is designed to be used by several functions that handle config information(key-value pairs).) I used 'sections' for this variable (type is 'struct list_head'), but IMHO, I think that renaming it is better e.g. 1) 'cfglist' 2) 'configlist' 3) 'config_list' 4) 'cfgset' 5) 'configset' 6) 'config_set' ... :-\ It is trivial question, but I wanna know a opinion of other people. :-) I'd go with 3 or 6. Or simply 'configs' or 'perf_configs' is fine for me. Thank you for your opinion. :-) Taeung
[RFC PATCH 1/2] percpu_counter: Allow falling back to global counter on large system
Per-cpu counters are used in quite a number of places within
the kernel. On large system with a lot of CPUs, however, doing a
percpu_counter_sum() can be very expensive as nr_cpu cachelines will
need to be read. In __percpu_counter_compare(), the chance of calling
percpu_counter_sum() also increases with increasing number of CPUs
if the global counter value is relatively small.
On large system, using a global counter with lock may actually be
faster than doing a percpu_counter_sum() which can be frequently
called from __percpu_counter_compare().
This patch provides a mechanism to selectively degenerate per-cpu
counters to global counters at per-cpu counter initialization time. The
following new API is added:
percpu_counter_set_limit(struct percpu_counter *fbc,
u32 percpu_limit)
The function should be called after percpu_counter_set(). It will
compare the total limit (nr_cpu * percpu_limit) against the current
counter value. If the limit is not smaller, it will disable per-cpu
counter and use only the global counter instead. At run time, when
the counter value grows past the total limit, per-cpu counter will
be enabled again.
Runtime disabling of per-cpu counters, however, is not currently
supported as it will slow down the per-cpu fast path.
Signed-off-by: Waiman Long
---
include/linux/percpu_counter.h | 10 +
lib/percpu_counter.c | 72 +++-
2 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/include/linux/percpu_counter.h b/include/linux/percpu_counter.h
index 84a1094..04a3783 100644
--- a/include/linux/percpu_counter.h
+++ b/include/linux/percpu_counter.h
@@ -16,8 +16,14 @@
#ifdef CONFIG_SMP
+/*
+ * The per-cpu counter will be degenerated into a global counter when limit
+ * is set at initialization time. It will change back to a real per-cpu
+ * counter once the count exceed the given limit.
+ */
struct percpu_counter {
raw_spinlock_t lock;
+ u32 limit;
s64 count;
#ifdef CONFIG_HOTPLUG_CPU
struct list_head list; /* All percpu_counters are on a list */
@@ -42,6 +48,7 @@ void percpu_counter_set(struct percpu_counter *fbc, s64
amount);
void __percpu_counter_add(struct percpu_counter *fbc, s64 amount, s32 batch);
s64 __percpu_counter_sum(struct percpu_counter *fbc);
int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch);
+void percpu_counter_set_limit(struct percpu_counter *fbc, u32 percpu_limit);
static inline int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs)
{
@@ -170,6 +177,9 @@ static inline int percpu_counter_initialized(struct
percpu_counter *fbc)
return 1;
}
+static inline void percpu_counter_set_limit(struct percpu_counter *fbc,
+ u32 percpu_limit) { }
+
#endif /* CONFIG_SMP */
static inline void percpu_counter_inc(struct percpu_counter *fbc)
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index f051d69..f101c06 100644
--- a/lib/percpu_counter.c
+++ b/lib/percpu_counter.c
@@ -75,11 +75,25 @@ EXPORT_SYMBOL(percpu_counter_set);
void __percpu_counter_add(struct percpu_counter *fbc, s64 amount, s32 batch)
{
s64 count;
+ unsigned long flags;
+
+ if (fbc->limit) {
+ raw_spin_lock_irqsave(&fbc->lock, flags);
+ if (unlikely(!fbc->limit)) {
+ raw_spin_unlock_irqrestore(&fbc->lock, flags);
+ goto percpu_add;
+ }
+ fbc->count += amount;
+ if (abs(fbc->count) > fbc->limit)
+ fbc->limit = 0; /* Revert back to per-cpu counter */
+ raw_spin_unlock_irqrestore(&fbc->lock, flags);
+ return;
+ }
+percpu_add:
preempt_disable();
count = __this_cpu_read(*fbc->counters) + amount;
if (count >= batch || count <= -batch) {
- unsigned long flags;
raw_spin_lock_irqsave(&fbc->lock, flags);
fbc->count += count;
__this_cpu_sub(*fbc->counters, count - amount);
@@ -94,6 +108,8 @@ EXPORT_SYMBOL(__percpu_counter_add);
/*
* Add up all the per-cpu counts, return the result. This is a more accurate
* but much slower version of percpu_counter_read_positive()
+ *
+ * If a limit is set, the count can be returned directly without locking.
*/
s64 __percpu_counter_sum(struct percpu_counter *fbc)
{
@@ -101,6 +117,9 @@ s64 __percpu_counter_sum(struct percpu_counter *fbc)
int cpu;
unsigned long flags;
+ if (READ_ONCE(fbc->limit))
+ return READ_ONCE(fbc->count);
+
raw_spin_lock_irqsave(&fbc->lock, flags);
ret = fbc->count;
for_each_online_cpu(cpu) {
@@ -120,6 +139,7 @@ int __percpu_counter_init(struct percpu_counter *fbc, s64
amount, gfp_t gfp,
raw_spin_lock_init(&fbc->lock);
lockdep_set_class(&fbc->lock, key);
fbc->count = amo
[RFC PATCH 2/2] xfs: Allow degeneration of m_fdblocks/m_ifree to global counters
Small XFS filesystems on systems with large number of CPUs can incur a
significant overhead due to excessive calls to the percpu_counter_sum()
function which needs to walk through a large number of different
cachelines.
This patch uses the newly added percpu_counter_set_limit() API to
potentially switch the m_fdblocks and m_ifree per-cpu counters to
a global counter with locks at filesystem mount time if its size
is small relatively to the number of CPUs available.
A possible use case is the use of the NVDIMM as an application scratch
storage area for log file and other small files. Current battery-backed
NVDIMMs are pretty small in size, e.g. 8G per DIMM. So we cannot create
large filesystem on top of them.
On a 4-socket 80-thread system running 4.5-rc6 kernel, this patch can
improve the throughput of the AIM7 XFS disk workload by 25%. Before
the patch, the perf profile was:
18.68% 0.08% reaim [k] __percpu_counter_compare
18.05% 9.11% reaim [k] __percpu_counter_sum
0.37% 0.36% reaim [k] __percpu_counter_add
After the patch, the perf profile was:
0.73% 0.36% reaim [k] __percpu_counter_add
0.27% 0.27% reaim [k] __percpu_counter_compare
Signed-off-by: Waiman Long
---
fs/xfs/xfs_mount.c |1 -
fs/xfs/xfs_mount.h |5 +
fs/xfs/xfs_super.c |6 ++
3 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index bb753b3..fe74b91 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1163,7 +1163,6 @@ xfs_mod_ifree(
* a large batch count (1024) to minimise global counter updates except when
* we get near to ENOSPC and we have to be very accurate with our updates.
*/
-#define XFS_FDBLOCKS_BATCH 1024
int
xfs_mod_fdblocks(
struct xfs_mount*mp,
diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h
index b570984..d9520f4 100644
--- a/fs/xfs/xfs_mount.h
+++ b/fs/xfs/xfs_mount.h
@@ -206,6 +206,11 @@ typedef struct xfs_mount {
#defineXFS_WSYNC_WRITEIO_LOG 14 /* 16k */
/*
+ * FD blocks batch size for per-cpu compare
+ */
+#define XFS_FDBLOCKS_BATCH 1024
+
+/*
* Allow large block sizes to be reported to userspace programs if the
* "largeio" mount option is used.
*
diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 59c9b7b..c0b4f79 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -1412,6 +1412,12 @@ xfs_reinit_percpu_counters(
percpu_counter_set(&mp->m_icount, mp->m_sb.sb_icount);
percpu_counter_set(&mp->m_ifree, mp->m_sb.sb_ifree);
percpu_counter_set(&mp->m_fdblocks, mp->m_sb.sb_fdblocks);
+
+ /*
+* Use default batch size for m_ifree
+*/
+ percpu_counter_set_limit(&mp->m_ifree, 0);
+ percpu_counter_set_limit(&mp->m_fdblocks, 4 * XFS_FDBLOCKS_BATCH);
}
static void
--
1.7.1
[RFC PATCH 0/2] percpu_counter: Enable switching to global counter
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 fs/xfs/xfs_mount.c |1 - fs/xfs/xfs_mount.h |5 +++ fs/xfs/xfs_super.c |6 +++ include/linux/percpu_counter.h | 10 + lib/percpu_counter.c | 72 +++- 5 files changed, 92 insertions(+), 2 deletions(-)
Re: [PATCH v5 00/26] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
On Mon, Feb 29, 2016 at 06:25:12PM +0200, Roger Quadros wrote: > On 19/02/16 23:15, Roger Quadros wrote: > > Hi, > > > > @Tony > > Patches 15 and 24 are new and will need your review. > > I've modified patch 22 to include the new am335x boards introduced since > > v4.4. > > > > Patches are based on top of omap-for-v4.6/dt so that the DT changes apply > > cleanly. > > > > @Brian > > If you can Ack the MTD related changes we can push the series (excluding DT > > patches) > > to an immutable branch and you can then pull it into l2-mtd.git > > Gentle ping on this. Thanks. I think this series looks a lot better. I don't think I have any fundamental issues with the MTD stuff, aside from the one comment about the 'reg' property. If we get a satisfactory answer for that (and you fix the small stuff), then: Acked-by: Brian Norris (That's also presuming the relevant players are all on board with the DT "ABI" breakage. But I think your old binding really needed a fixup, so the warning might be sufficient.) Brian
[PATCH v6 2/2] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan
This patch adds Generic PHY access for sdhci-of-arasan. Driver
can get PHY handler from dt-binding, and power-on/init the PHY.
Currently, it's just mandatory for arasan,sdhci-5.1.
Signed-off-by: Shawn Lin
Serise-changes: 6
- rebase on Ulf's next
- fix some preexisting problems of err handling suggested
by Adrian
Serise-changes: 5
- remove rpm support from this serise
- fix some err case for handling phy
Serise-changes: 4
- remove suspend/resume_phy
- add err handle label for system PM callback
- fix comments of struct sdhci_arasan_data and system PM
callback suggested by Michal
Serise-changes: 3
- remove phy_init/exit for suspend/resume
- adjust phy_int/power_on seq to make code more reasonable
simplify suspend/resume_phy
Serise-changes: 2
- Keep phy as a mandatory requirement for arasan,sdhci-5.1
---
Changes in v6: None
Changes in v2: None
drivers/mmc/host/sdhci-of-arasan.c | 71 +-
1 file changed, 63 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 1e4b5e0..2e482b1 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include "sdhci-pltfm.h"
#define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
@@ -32,9 +33,11 @@
/**
* struct sdhci_arasan_data
* @clk_ahb: Pointer to the AHB clock
+ * @phy: Pointer to the generic phy
*/
struct sdhci_arasan_data {
struct clk *clk_ahb;
+ struct phy *phy;
};
static unsigned int sdhci_arasan_get_timeout_clock(struct sdhci_host *host)
@@ -88,6 +91,15 @@ static int sdhci_arasan_suspend(struct device *dev)
if (ret)
return ret;
+ if (!IS_ERR(sdhci_arasan->phy)) {
+ ret = phy_power_off(sdhci_arasan->phy);
+ if (ret) {
+ dev_err(dev, "Cannot power off phy.\n");
+ sdhci_resume_host(host);
+ return ret;
+ }
+ }
+
clk_disable(pltfm_host->clk);
clk_disable(sdhci_arasan->clk_ahb);
@@ -118,10 +130,17 @@ static int sdhci_arasan_resume(struct device *dev)
ret = clk_enable(pltfm_host->clk);
if (ret) {
dev_err(dev, "Cannot enable SD clock.\n");
- clk_disable(sdhci_arasan->clk_ahb);
return ret;
}
+ if (!IS_ERR(sdhci_arasan->phy)) {
+ ret = phy_power_on(sdhci_arasan->phy);
+ if (ret) {
+ dev_err(dev, "Cannot power on phy.\n");
+ return ret;
+ }
+ }
+
return sdhci_resume_host(host);
}
#endif /* ! CONFIG_PM_SLEEP */
@@ -148,19 +167,21 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
sdhci_arasan->clk_ahb = devm_clk_get(&pdev->dev, "clk_ahb");
if (IS_ERR(sdhci_arasan->clk_ahb)) {
dev_err(&pdev->dev, "clk_ahb clock not found.\n");
- return PTR_ERR(sdhci_arasan->clk_ahb);
+ ret = PTR_ERR(sdhci_arasan->clk_ahb);
+ goto err_pltfm_free;
}
clk_xin = devm_clk_get(&pdev->dev, "clk_xin");
if (IS_ERR(clk_xin)) {
dev_err(&pdev->dev, "clk_xin clock not found.\n");
- return PTR_ERR(clk_xin);
+ ret = PTR_ERR(clk_xin);
+ goto err_pltfm_free;
}
ret = clk_prepare_enable(sdhci_arasan->clk_ahb);
if (ret) {
dev_err(&pdev->dev, "Unable to enable AHB clock.\n");
- return ret;
+ goto err_pltfm_free;
}
ret = clk_prepare_enable(clk_xin);
@@ -178,19 +199,48 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
goto clk_disable_all;
}
+ sdhci_arasan->phy = ERR_PTR(-ENODEV);
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "arasan,sdhci-5.1")) {
+ sdhci_arasan->phy = devm_phy_get(&pdev->dev,
+"phy_arasan");
+ if (IS_ERR(sdhci_arasan->phy)) {
+ ret = PTR_ERR(sdhci_arasan->phy);
+ dev_err(&pdev->dev, "No phy for arasan,sdhci-5.1.\n");
+ goto clk_disable_all;
+ }
+
+ ret = phy_init(sdhci_arasan->phy);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "phy_init err.\n");
+ goto clk_disable_all;
+ }
+
+ ret = phy_power_on(sdhci_arasan->phy);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "phy_power_on err.\n");
+ goto err_phy_power;
+ }
+ }
+
ret = sdhci_add_host(host);
if (ret)
- goto err_pltfm_free;
+ goto err_add_host;
return 0;
-err_pltfm_fre
[PATCH v6 1/2] Documentation: bindings: add description of phy for sdhci-of-arasan
This patch adds phys and phy-names for sdhci-of-arasan as required
properties for arasan,sdhci-5.1, and details the example as well.
Signed-off-by: Shawn Lin
Acked-by: Rob Herring
---
Changes in v6:
- add Rob's Acked-by tag
Changes in v2:
- Keep phy as a mandatory requirement for arasan,sdhci-5.1
.../devicetree/bindings/mmc/arasan,sdhci.txt | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
index da541c3..31b35c3 100644
--- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -1,11 +1,12 @@
Device Tree Bindings for the Arasan SDHCI Controller
- The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
- deviations are documented here.
+ The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
+ Only deviations are documented here.
[1] Documentation/devicetree/bindings/mmc/mmc.txt
[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
[3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+ [4] Documentation/devicetree/bindings/phy/phy-bindings.txt
Required Properties:
- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
@@ -17,6 +18,10 @@ Required Properties:
- interrupt-parent: Phandle for the interrupt controller that services
interrupts for this device.
+Required Properties for "arasan,sdhci-5.1":
+ - phys: From PHY bindings: Phandle for the Generic PHY for arasan.
+ - phy-names: MUST be "phy_arasan".
+
Example:
sdhci@e010 {
compatible = "arasan,sdhci-8.9a";
@@ -26,3 +31,14 @@ Example:
interrupt-parent = <&gic>;
interrupts = <0 24 4>;
} ;
+
+ sdhci@e280 {
+ compatible = "arasan,sdhci-5.1";
+ reg = <0xe280 0x1000>;
+ clock-names = "clk_xin", "clk_ahb";
+ clocks = <&cru 8>, <&cru 18>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 24 4>;
+ phys = <&emmc_phy>;
+ phy-names = "phy_arasan";
+ } ;
--
2.3.7
[PATCH v6 0/2] Add phy support for arasan,sdhci-5.1
Phy is mandatory requirement for arasan,sdhci-5.1, so we introduce generic phy support for sdhci-of-arasan. This version is rebased on Ulf's next to make it applied cleanly. Also, we fix some preexisting problems of err handling suggested by Adrian. Shawn Lin (2): Documentation: bindings: add description of phy for sdhci-of-arasan mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan .../devicetree/bindings/mmc/arasan,sdhci.txt | 20 +- drivers/mmc/host/sdhci-of-arasan.c | 71 +++--- 2 files changed, 81 insertions(+), 10 deletions(-) -- 2.3.7
Re: [PATCH v5 09/26] mtd: nand: omap: Clean up device tree support
Sorry, another small thing I noticed.
On Fri, Feb 19, 2016 at 11:15:31PM +0200, Roger Quadros wrote:
> Move NAND specific device tree parsing to NAND driver.
>
> The NAND controller node must have a compatible id, register space
> resource and interrupt resource.
>
> Signed-off-by: Roger Quadros
> ---
[...]
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 9e99199..0a637c4 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -177,10 +178,11 @@ struct omap_nand_info {
> struct gpmc_nand_regs reg;
> struct gpmc_nand_ops*ops;
> /* generated at runtime depending on ECC algorithm and layout selected
> */
^^^ I don't think that comment describes the following line. You
probably meant to delete this one?
> + boolflash_bbt;
> + /* generated at runtime depending on ECC algorithm and layout */
> struct nand_ecclayout oobinfo;
> /* fields specific for BCHx_HW ECC scheme */
> struct device *elm_dev;
> - struct device_node *of_node;
> };
>
> static inline struct omap_nand_info *mtd_to_omap(struct mtd_info *mtd)
[...]
Brian
Re: [PATCH v3] net: jme: fix suspend/resume on JMC260
On Fri, Mar 4, 2016 at 1:32 AM, Diego Viola wrote: > On Thu, Mar 3, 2016 at 6:19 PM, Diego Viola wrote: >> On Thu, Mar 3, 2016 at 6:14 PM, Diego Viola wrote: >>> On Thu, Mar 3, 2016 at 2:55 AM, Diego Viola wrote: On Thu, Mar 3, 2016 at 12:19 AM, Diego Viola wrote: > On Wed, Mar 2, 2016 at 2:14 AM, Guo-Fu Tseng > wrote: >> On Wed, 24 Feb 2016 23:58:56 -0500 (EST), David Miller wrote >>> From: Diego Viola >>> Date: Tue, 23 Feb 2016 12:04:04 -0300 >>> >>> > The JMC260 network card fails to suspend/resume because the call to >>> > jme_start_irq() was too early, moving the call to jme_start_irq() >>> > after >>> > the call to jme_reset_link() makes it work. >>> > >>> > Prior this change suspend/resume would fail unless >>> > /sys/power/pm_async=0 >>> > was explicitly specified. >>> > >>> > Relevant bug report: >>> > https://bugzilla.kernel.org/show_bug.cgi?id=112351 >>> > >>> > Signed-off-by: Diego Viola >>> >>> Applied and queued up for -stable, thanks. >> >> Just reviewed it, it should have no side effect. >> >> Thanks David, Diego. >> >> Guo-Fu Tseng >> > > Hi all, > > I'm having another issue with jme and I'm not sure if it's related to > the same issue with suspend/resume, but the problem now is WoL. > > Let me try to describe the problem a bit: > > I put my machine to sleep in S3 and I send WoL packets from a laptop, > and the machine doesn't wake up at all, I tried inspecting packets > with tcpdump and nothing shows up in the tcpdump output. > > When the machine is in working state, and I send WoL packets and I > initiate a S3, it refuses to go in sleep mode. > > I tried the same in Windows (waking up from S3 via WoL) and it works > there. > > Does anyone have any ideas what the problem can be? I talked with Guo > and he suspects the problem is motherboard failure, I also think the > issue can be a BIOS bug since I hear so many horror stories about AMI > BIOS issues with Linux. > > But it's still a mystery to me given all these conditions I mentioned. > > Diego The reason I believe that both problems might be connected (suspend/resume & WoL) is that when I disable WoL with ethtool, e.g. sudo ethtool -s eth0 wol d The resume from suspend hang disappears, and there is no need for the patch that moves the jme_start_irq() function call anymore, this also regardless of pm_async being 1 or 0. Can someone experienced with power management help here please? Diego >>> >>> Actually, I just tried it now and I CAN read see the packets coming in >>> in the tcpdump output. >>> >>> The machine just doesn't wake up from S3 after I send the packets. >>> >>> Any ideas? >>> >>> Diego >> >> I can see the packets in the tcpdump output* > > I just tried again and I can't capture those packets anymore, > strangely ICMP packets with ping arrive fine but when I try to send > WoL packets they don't arrive. > > Diego It looks like the problem is ACPI after all, because I tried enabling resume by keyboard/mouse/lan, etc. and none of these methods work. I'd like to be able to debug the BIOS ACPI thing, but I don't know where to start. I've tried disassembling the DSDT and this is what I get: http://ix.io/oYY Any ideas what to do next? Diego
Re: [PATCH v3 16/52] mtd: nand: use mtd_set_ecclayout() where appropriate
On Fri, Feb 26, 2016 at 01:57:24AM +0100, Boris Brezillon wrote: > Use the mtd_set_ecclayout() helper instead of directly assigning the > mtd->ecclayout field. > > Signed-off-by: Boris Brezillon > --- > drivers/mtd/nand/nand_base.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c > index 17504f2..5093a3c 100644 > --- a/drivers/mtd/nand/nand_base.c > +++ b/drivers/mtd/nand/nand_base.c > @@ -4288,7 +4288,7 @@ int nand_scan_tail(struct mtd_info *mtd) > ecc->write_oob_raw = ecc->write_oob; > > /* propagate ecc info to mtd_info */ > - mtd->ecclayout = ecc->layout; > + mtd_set_ecclayout(mtd, ecc->layout); I'm having trouble applying this one. For the life of me, I can't figure out where you got this context from. This block only appears much later in nand_scan_tail()... Do you think you could post a git tree with your intended changes? I may just try to pull something in like that instead. BTW, I'm not sure the OMAP refactorings are going to come in time, but I was planning to pull those directly from the TI folks (i.e., they won't be rebased on l2-mtd.git), since there's some intermingling of platform changes there. I think I can fix the conflicts fine, but FYI. Brian > mtd->ecc_strength = ecc->strength; > mtd->ecc_step_size = ecc->size; > > -- > 2.1.4 >
Re: [PATCH v2 2/3] libnvdimm, pmem: adjust for section collisions with 'System RAM'
On Fri, Mar 4, 2016 at 6:48 PM, Toshi Kani wrote:
> On Thu, 2016-03-03 at 13:53 -0800, Dan Williams wrote:
>> On a platform where 'Persistent Memory' and 'System RAM' are mixed
>> within a given sparsemem section, trim the namespace and notify about the
>> sub-optimal alignment.
>>
>> Cc: Toshi Kani
>> Cc: Ross Zwisler
>> Signed-off-by: Dan Williams
>> ---
>> drivers/nvdimm/namespace_devs.c |7 ++
>> drivers/nvdimm/pfn.h| 10 ++-
>> drivers/nvdimm/pfn_devs.c |5 ++
>> drivers/nvdimm/pmem.c | 125 -
>> --
>> 4 files changed, 111 insertions(+), 36 deletions(-)
>>
>> diff --git a/drivers/nvdimm/namespace_devs.c
>> b/drivers/nvdimm/namespace_devs.c
>> index 8ebfcaae3f5a..463756ca2d4b 100644
>> --- a/drivers/nvdimm/namespace_devs.c
>> +++ b/drivers/nvdimm/namespace_devs.c
>> @@ -133,6 +133,7 @@ bool nd_is_uuid_unique(struct device *dev, u8 *uuid)
>> bool pmem_should_map_pages(struct device *dev)
>> {
>> struct nd_region *nd_region = to_nd_region(dev->parent);
>> + struct nd_namespace_io *nsio;
>>
>> if (!IS_ENABLED(CONFIG_ZONE_DEVICE))
>> return false;
>> @@ -143,6 +144,12 @@ bool pmem_should_map_pages(struct device *dev)
>> if (is_nd_pfn(dev) || is_nd_btt(dev))
>> return false;
>>
>> + nsio = to_nd_namespace_io(dev);
>> + if (region_intersects(nsio->res.start, resource_size(&nsio-
>> >res),
>> + IORESOURCE_SYSTEM_RAM,
>> + IORES_DESC_NONE) == REGION_MIXED)
>
> Should this be != REGION_DISJOINT for safe?
Acutally, it's ok. It doesn't need to be disjoint. The problem is
mixing an mm-zone within a given section. If the region intersects
system-ram then devm_memremap_pages() is a no-op and we can use the
existing page allocation and linear mapping.
>
>> + return false;
>> +
>
> :
>
>> @@ -304,21 +311,56 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
>> }
>>
>> memset(pfn_sb, 0, sizeof(*pfn_sb));
>> - npfns = (pmem->size - SZ_8K) / SZ_4K;
>> +
>> + /*
>> + * Check if pmem collides with 'System RAM' when section aligned
>> and
>> + * trim it accordingly
>> + */
>> + nsio = to_nd_namespace_io(&ndns->dev);
>> + start = PHYS_SECTION_ALIGN_DOWN(nsio->res.start);
>> + size = resource_size(&nsio->res);
>> + if (region_intersects(start, size, IORESOURCE_SYSTEM_RAM,
>> + IORES_DESC_NONE) == REGION_MIXED) {
>> +
>> + start = nsio->res.start;
>> + start_pad = PHYS_SECTION_ALIGN_UP(start) - start;
>> + }
>> +
>> + start = nsio->res.start;
>> + size = PHYS_SECTION_ALIGN_UP(start + size) - start;
>> + if (region_intersects(start, size, IORESOURCE_SYSTEM_RAM,
>> + IORES_DESC_NONE) == REGION_MIXED) {
>> + size = resource_size(&nsio->res);
>> + end_trunc = start + size - PHYS_SECTION_ALIGN_DOWN(start
>> + size);
>> + }
>
> This check seems to assume that guest's regular memory layout does not
> change. That is, if there is no collision at first, there won't be any
> later. Is this a valid assumption?
If platform firmware changes the physical alignment during the
lifetime of the namespace there's not much we can do. Another problem
not addressed by this patch is firmware choosing to hot plug system
ram into the same section as persistent memory. As far as I can see
all we do is ask firmware implementations to respect Linux section
boundaries and otherwise not change alignments.
Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()
On 3/4/2016 10:23 AM, Douglas Anderson wrote:
> From testing and trying to make sense of the documentation, it appears
> that a 10 ms delay is needed after resetting the core to make sure that
> everything is stable and consistent. Let's add it.
>
> In my testing (on rk3288) this allows us to revert commit
> 192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835"). Though I
> could never reproduce the problems on my board, this might also allow us
> to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
> dr_mode").
>
> Signed-off-by: Douglas Anderson
> ---
> drivers/usb/dwc2/core.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
> index 5e5a0f135b5a..8710b2d3e770 100644
> --- a/drivers/usb/dwc2/core.c
> +++ b/drivers/usb/dwc2/core.c
> @@ -277,6 +277,26 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
> }
> } while (!(greset & GRSTCTL_AHBIDLE));
>
> + /*
> + * Sleep for 10-15 ms after the reset to let it finish.
> + *
> + * It's been confirmed on at least one version of the controller
> + * that this is a requirement that this is a requirement in order for
> + * everything to settle. Specifically if you:
> + * - change GNPTXFSIZ or HPTXFSIZ before the reset
> + * - do the reset
> + * - read GNPTXFSIZ or HPTXFSIZ in a loop
> + * ...you'll find that it takes almost exactly 10 ms for the registers
> + * to return to their reset defaults.
> + *
> + * Note that it's possible that this 10 ms is the time referred to
> + * in "Host Initialization" where it says to "Wait at least 10 ms for
> + * the reset process to complete". In "Device Initialization" there
> + * is also talk of a reset lasting 10 ms. That may be the source of
> + * this delay.
> + */
> + usleep_range(1, 15000);
> +
> return 0;
> }
>
>
Hi Doug,
Thanks for tracking this down.
Caesar,
Could you test these two commits on your rk3066 platform? And also see
if it works after reverting bd84f4ae9986?
Thanks,
John
Re: [PATCH] cxgbit: fix dma_addr_t printk format
On Sat, 2016-03-05 at 01:34 +0100, Arnd Bergmann wrote:
> On Friday 04 March 2016 16:25:07 Joe Perches wrote:
> > > diff --git a/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
> > > b/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
[]
> > > @@ -179,7 +179,7 @@ cxgbit_dump_sgl(const char *cap, struct scatterlist
> > > *sgl, int nents)
> > > for_each_sg(sgl, sg, nents, i)
> > > pr_info("\t%d/%u, 0x%p: len %u, off %u, pg 0x%p, dma
> > > 0x%llx, %u\n",
> > > i, nents, sg, sg->length, sg->offset, sg_page(sg),
> > > - sg_dma_address(sg), sg_dma_len(sg));
> > > + (u64)sg_dma_address(sg), sg_dma_len(sg));
[]
> > You could create a temporary:
for_each_sg(sgl, sg, nents, i) {
dma_addr_t addr = sg_dma_address(sg);
pr_info("\t%d/%u, 0x%p: len %u, off %u, pg 0x%p, dma %pad,
%u\n",
i, nents, sg, sg->length, sg->offset, sg_page(sg),
&addr, sg_dma_len(sg));
}
Sure, but the cast seemed nicer in this case, the result is the same.
Not quite as 0x%llx isn't always the same width and doesn't
have leading 0's like %pad
[PATCH 04/10] staging: lustre: fix 'NULL pointer dereference' errors
From: Sebastien Buisson
Fix 'NULL pointer dereference' defects found by Coverity version
6.5.3:
Dereference after null check (FORWARD_NULL)
For instance, Passing null pointer to a function which dereferences
it.
Dereference before null check (REVERSE_INULL)
Null-checking variable suggests that it may be null, but it has
already been dereferenced on all paths leading to the check.
Dereference null return value (NULL_RETURNS)
The following fixes for the LNet layer are broken out of patch
http://review.whamcloud.com/4720.
Signed-off-by: Sebastien Buisson
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2217
Reviewed-on: http://review.whamcloud.com/4720
Reviewed-by: Dmitry Eremin
Reviewed-by: Oleg Drokin
---
drivers/staging/lustre/lnet/lnet/lib-move.c|2 +
drivers/staging/lustre/lnet/selftest/conctl.c | 49 ++--
.../lustre/lustre/include/lustre/lustre_user.h |3 +
drivers/staging/lustre/lustre/ldlm/ldlm_request.c |7 ++-
drivers/staging/lustre/lustre/lmv/lmv_obd.c|2 +-
drivers/staging/lustre/lustre/lov/lov_request.c|2 +-
drivers/staging/lustre/lustre/mgc/mgc_request.c| 10 -
.../lustre/lustre/obdclass/lprocfs_status.c| 24 +
drivers/staging/lustre/lustre/ptlrpc/layout.c |2 +-
9 files changed, 61 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
b/drivers/staging/lustre/lnet/lnet/lib-move.c
index a5e90e7..f323b8b 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
@@ -162,6 +162,7 @@ lnet_iov_nob(unsigned int niov, struct kvec *iov)
{
unsigned int nob = 0;
+ LASSERT(!niov || iov);
while (niov-- > 0)
nob += (iov++)->iov_len;
@@ -282,6 +283,7 @@ lnet_kiov_nob(unsigned int niov, lnet_kiov_t *kiov)
{
unsigned int nob = 0;
+ LASSERT(!niov || kiov);
while (niov-- > 0)
nob += (kiov++)->kiov_len;
diff --git a/drivers/staging/lustre/lnet/selftest/conctl.c
b/drivers/staging/lustre/lnet/selftest/conctl.c
index 714d14b..62cacb6 100644
--- a/drivers/staging/lustre/lnet/selftest/conctl.c
+++ b/drivers/staging/lustre/lnet/selftest/conctl.c
@@ -670,44 +670,45 @@ static int
lst_stat_query_ioctl(lstio_stat_args_t *args)
{
int rc;
- char *name;
+ char *name = NULL;
/* TODO: not finished */
if (args->lstio_sta_key != console_session.ses_key)
return -EACCES;
- if (!args->lstio_sta_resultp ||
- (!args->lstio_sta_namep && !args->lstio_sta_idsp) ||
- args->lstio_sta_nmlen <= 0 ||
- args->lstio_sta_nmlen > LST_NAME_SIZE)
- return -EINVAL;
-
- if (args->lstio_sta_idsp &&
- args->lstio_sta_count <= 0)
+ if (!args->lstio_sta_resultp)
return -EINVAL;
- LIBCFS_ALLOC(name, args->lstio_sta_nmlen + 1);
- if (!name)
- return -ENOMEM;
-
- if (copy_from_user(name, args->lstio_sta_namep,
- args->lstio_sta_nmlen)) {
- LIBCFS_FREE(name, args->lstio_sta_nmlen + 1);
- return -EFAULT;
- }
+ if (args->lstio_sta_idsp) {
+ if (args->lstio_sta_count <= 0)
+ return -EINVAL;
- if (!args->lstio_sta_idsp) {
- rc = lstcon_group_stat(name, args->lstio_sta_timeout,
- args->lstio_sta_resultp);
- } else {
rc = lstcon_nodes_stat(args->lstio_sta_count,
args->lstio_sta_idsp,
args->lstio_sta_timeout,
args->lstio_sta_resultp);
- }
+ } else if (args->lstio_sta_namep) {
+ if (args->lstio_sta_nmlen <= 0 ||
+ args->lstio_sta_nmlen > LST_NAME_SIZE)
+ return -EINVAL;
- LIBCFS_FREE(name, args->lstio_sta_nmlen + 1);
+ LIBCFS_ALLOC(name, args->lstio_sta_nmlen + 1);
+ if (!name)
+ return -ENOMEM;
+ rc = copy_from_user(name, args->lstio_sta_namep,
+ args->lstio_sta_nmlen);
+ if (!rc)
+ rc = lstcon_group_stat(name, args->lstio_sta_timeout,
+ args->lstio_sta_resultp);
+ else
+ rc = -EFAULT;
+ } else {
+ rc = -EINVAL;
+ }
+
+ if (name)
+ LIBCFS_FREE(name, args->lstio_sta_nmlen + 1);
return rc;
}
diff --git a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
b/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
index 9f026bd..276906e 100644
--- a/drivers/staging/lustre/lustre/include/lustre/lustre_user.h
+++ b/drivers/staging/lustre/lustre/include/lustre/lustre_
[PATCH 05/10] staging: lustre: fix 'data race condition' issue in framework.c
From: Sebastien Buisson Fix 'data race condition' defects found by Coverity version 6.5.0: Data race condition (MISSING_LOCK) Accessing variable without holding lock. Elsewhere, this variable is accessed with lock held. Signed-off-by: Sebastien Buisson Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2744 Reviewed-on: http://review.whamcloud.com/6568 Reviewed-by: Bob Glossman Reviewed-by: Andreas Dilger --- drivers/staging/lustre/lnet/selftest/framework.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/staging/lustre/lnet/selftest/framework.c b/drivers/staging/lustre/lnet/selftest/framework.c index dbd2c61..5c7cafa 100644 --- a/drivers/staging/lustre/lnet/selftest/framework.c +++ b/drivers/staging/lustre/lnet/selftest/framework.c @@ -981,9 +981,8 @@ sfw_run_test(swi_workitem_t *wi) list_add_tail(&rpc->crpc_list, &tsi->tsi_active_rpcs); spin_unlock(&tsi->tsi_lock); - rpc->crpc_timeout = rpc_timeout; - spin_lock(&rpc->crpc_lock); + rpc->crpc_timeout = rpc_timeout; srpc_post_rpc(rpc); spin_unlock(&rpc->crpc_lock); return 0; -- 1.7.1
[PATCH 02/10] staging: lustre: LNet network latency simulation
From: Liang Zhen
Incoming lnet message can be delayed for seconds if it can match
any of LNet Delay Rules.
User can add/remove/list Delay Rule by lctl commands:
- lctl net_delay_add
Add a new Delay Rule to LNet, options
<-s | --source SRC_NID>
<-d | --dest DST_NID>
<<-r | --rate RATE_NUMBER>
<-i | --interlval SECONDS>>
<-l | --latency DELAY_LATENCY>
- lctl net_delay_del
Remove matched Delay Rule from LNet, options:
<[-a | --all] |
<-s | --source SRC_NID>
<-d | --dest DST_NID>>
- lctl net_delay_list
List all Delay Rules in LNet
- lctl net_delay_reset
Reset statistic counters for all Delay Rules
Signed-off-by: Liang Zhen
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5435
Reviewed-on: http://review.whamcloud.com/11409
Reviewed-by: Amir Shehata
Reviewed-by: Bobi Jam
Reviewed-by: Oleg Drokin
---
.../staging/lustre/include/linux/lnet/lib-lnet.h | 17 +
.../staging/lustre/include/linux/lnet/lib-types.h |3 +
.../staging/lustre/include/linux/lnet/lnetctl.h| 21 +-
drivers/staging/lustre/lnet/lnet/api-ni.c |1 +
drivers/staging/lustre/lnet/lnet/lib-move.c| 73 ++-
drivers/staging/lustre/lnet/lnet/lib-msg.c |6 +
drivers/staging/lustre/lnet/lnet/net_fault.c | 601 +++-
7 files changed, 683 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index 7b3f858..dfc0208 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -559,13 +559,22 @@ void lnet_portals_destroy(void);
/* message functions */
int lnet_parse(lnet_ni_t *ni, lnet_hdr_t *hdr,
lnet_nid_t fromnid, void *private, int rdma_req);
+int lnet_parse_local(lnet_ni_t *ni, lnet_msg_t *msg);
+int lnet_parse_forward_locked(lnet_ni_t *ni, lnet_msg_t *msg);
+
void lnet_recv(lnet_ni_t *ni, void *private, lnet_msg_t *msg, int delayed,
unsigned int offset, unsigned int mlen, unsigned int rlen);
+void lnet_ni_recv(lnet_ni_t *ni, void *private, lnet_msg_t *msg,
+ int delayed, unsigned int offset,
+ unsigned int mlen, unsigned int rlen);
+
lnet_msg_t *lnet_create_reply_msg(lnet_ni_t *ni, lnet_msg_t *get_msg);
void lnet_set_reply_msg_len(lnet_ni_t *ni, lnet_msg_t *msg, unsigned int len);
void lnet_finalize(lnet_ni_t *ni, lnet_msg_t *msg, int rc);
+void lnet_drop_message(lnet_ni_t *ni, int cpt, void *private,
+ unsigned int nob);
void lnet_drop_delayed_msg_list(struct list_head *head, char *reason);
void lnet_recv_delayed_msg_list(struct list_head *head);
@@ -586,6 +595,14 @@ void lnet_fault_fini(void);
bool lnet_drop_rule_match(lnet_hdr_t *hdr);
+int lnet_delay_rule_add(struct lnet_fault_attr *attr);
+int lnet_delay_rule_del(lnet_nid_t src, lnet_nid_t dst, bool shutdown);
+int lnet_delay_rule_list(int pos, struct lnet_fault_attr *attr,
+struct lnet_fault_stat *stat);
+void lnet_delay_rule_reset(void);
+void lnet_delay_rule_check(void);
+bool lnet_delay_rule_match_locked(lnet_hdr_t *hdr, struct lnet_msg *msg);
+
/** @} lnet_fault_simulation */
void lnet_counters_get(lnet_counters_t *counters);
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h
b/drivers/staging/lustre/include/linux/lnet/lib-types.h
index cb09a8a..29c72f8 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
@@ -88,6 +88,7 @@ typedef struct lnet_msg {
unsigned intmsg_rtrcredit:1;/* taken a global router credit
*/
unsigned intmsg_peerrtrcredit:1;/* taken a peer router credit */
unsigned intmsg_onactivelist:1; /* on the activelist */
+ unsigned intmsg_rdma_get:1;
struct lnet_peer*msg_txpeer; /* peer I'm sending to */
struct lnet_peer*msg_rxpeer; /* peer I received from */
@@ -574,6 +575,7 @@ typedef struct {
/* failure simulation */
struct list_head ln_test_peers;
struct list_head ln_drop_rules;
+ struct list_head ln_delay_rules;
struct list_head ln_nis; /* LND instances */
/* NIs bond on specific CPT(s) */
@@ -610,6 +612,7 @@ typedef struct {
struct mutex ln_api_mutex;
struct mutex ln_lnd_mutex;
+ struct mutex ln_delay_mutex;
/* Have I called LNetNIInit myself? */
int ln_niinit_self;
/* LNetNIInit/LNetNIFini counter */
diff --git a/drivers/staging/lustre/include/linux/lnet/lnetctl.h
b/drivers/staging/lustre/include/linux/lnet/lnetctl.h
index ec33bf8..3957507 100644
--- a/drivers/staging/lustre/include/linux/lnet/lnetctl.h
+++ b/drivers/staging/lustre/
[PATCH 06/10] staging: lustre: Correct missing newline
From: James Nunez
Several error messages are missing newline characters
at the end of the message. Newlines are added where
necessary and other minor corrections; no punctuation
at the end of an error message, add a return code to
the end of error messages, device name at the beginning,
etc.
There are just a couple of places where newlines are
removed and this is only in LDLM_DEBUG_NOLOCK. The definition
of LDLM_DEBUG_NOLOCK already has a newline in it and
resulted in double newlines printed.
Signed-off-by: James Nunez
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-4871
Reviewed-on: http://review.whamcloud.com/1
Reviewed-by: Andreas Dilger
Reviewed-by: John L. Hammond
Reviewed-by: Cliff White
---
drivers/staging/lustre/lnet/selftest/framework.c |6 +++---
drivers/staging/lustre/lnet/selftest/rpc.c |2 +-
drivers/staging/lustre/lustre/ldlm/ldlm_request.c |2 +-
drivers/staging/lustre/lustre/llite/file.c |8
drivers/staging/lustre/lustre/lmv/lmv_obd.c|2 +-
drivers/staging/lustre/lustre/lov/lov_lock.c |2 +-
drivers/staging/lustre/lustre/lov/lov_obd.c|2 +-
drivers/staging/lustre/lustre/lov/lov_pool.c |4 ++--
drivers/staging/lustre/lustre/mdc/mdc_request.c|3 ++-
drivers/staging/lustre/lustre/mgc/mgc_request.c|3 ++-
drivers/staging/lustre/lustre/obdclass/cl_lock.c |2 +-
.../lustre/lustre/obdclass/lprocfs_status.c|2 +-
drivers/staging/lustre/lustre/obdclass/lu_object.c |2 +-
.../staging/lustre/lustre/obdecho/echo_client.c|8 ++--
drivers/staging/lustre/lustre/osc/osc_cache.c |9 +
drivers/staging/lustre/lustre/osc/osc_lock.c |2 +-
drivers/staging/lustre/lustre/osc/osc_request.c|3 ++-
drivers/staging/lustre/lustre/ptlrpc/client.c |6 +++---
drivers/staging/lustre/lustre/ptlrpc/sec.c |4 ++--
19 files changed, 40 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/lustre/lnet/selftest/framework.c
b/drivers/staging/lustre/lnet/selftest/framework.c
index 5c7cafa..a2f94fa 100644
--- a/drivers/staging/lustre/lnet/selftest/framework.c
+++ b/drivers/staging/lustre/lnet/selftest/framework.c
@@ -453,7 +453,7 @@ sfw_make_session(srpc_mksn_reqst_t *request,
srpc_mksn_reply_t *reply)
/* brand new or create by force */
LIBCFS_ALLOC(sn, sizeof(sfw_session_t));
if (!sn) {
- CERROR("Dropping RPC (mksn) under memory pressure.\n");
+ CERROR("dropping RPC mksn under memory pressure\n");
return -ENOMEM;
}
@@ -1155,7 +1155,7 @@ sfw_add_test(struct srpc_server_rpc *rpc)
bat = sfw_bid2batch(request->tsr_bid);
if (!bat) {
- CERROR("Dropping RPC (%s) from %s under memory pressure.\n",
+ CERROR("dropping RPC %s from %s under memory pressure\n",
rpc->srpc_scd->scd_svc->sv_name,
libcfs_id2str(rpc->srpc_peer));
return -ENOMEM;
@@ -1367,7 +1367,7 @@ sfw_bulk_ready(struct srpc_server_rpc *rpc, int status)
}
if (sfw_del_session_timer()) {
- CERROR("Dropping RPC (%s) from %s: racing with expiry timer",
+ CERROR("dropping RPC %s from %s: racing with expiry timer\n",
sv->sv_name, libcfs_id2str(rpc->srpc_peer));
spin_unlock(&sfw_data.fw_lock);
return -EAGAIN;
diff --git a/drivers/staging/lustre/lnet/selftest/rpc.c
b/drivers/staging/lustre/lnet/selftest/rpc.c
index 129fa02..5eb4232 100644
--- a/drivers/staging/lustre/lnet/selftest/rpc.c
+++ b/drivers/staging/lustre/lnet/selftest/rpc.c
@@ -667,7 +667,7 @@ srpc_finish_service(struct srpc_service *sv)
}
if (scd->scd_buf_nposted > 0) {
- CDEBUG(D_NET, "waiting for %d posted buffers to unlink",
+ CDEBUG(D_NET, "waiting for %d posted buffers to
unlink\n",
scd->scd_buf_nposted);
spin_unlock(&scd->scd_lock);
return 0;
diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_request.c
b/drivers/staging/lustre/lustre/ldlm/ldlm_request.c
index 6f0761c..c7904a9 100644
--- a/drivers/staging/lustre/lustre/ldlm/ldlm_request.c
+++ b/drivers/staging/lustre/lustre/ldlm/ldlm_request.c
@@ -1041,7 +1041,7 @@ int ldlm_cli_cancel(struct lustre_handle *lockh,
/* concurrent cancels on the same handle can happen */
lock = ldlm_handle2lock_long(lockh, LDLM_FL_CANCELING);
if (!lock) {
- LDLM_DEBUG_NOLOCK("lock is already being destroyed\n");
+ LDLM_DEBUG_NOLOCK("lock is already being destroyed");
return 0;
}
diff --git a/drivers/staging/lustre/lustre/llite/file.c
b/drivers/staging/lustre/lustre/llite/file.c
index d3ed905..cf619af 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+
[PATCH 07/10] staging: lustre: add last missing sparse annotation __user
From: Frank Zago One of the __user was missed in being applied to upstream client. This is broken out of patch 11819. Signed-off-by: Frank Zago Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5396 Reviewed-on: http://review.whamcloud.com/11819 Reviewed-by: James Simmons Reviewed-by: Dmitry Eremin Reviewed-by: Oleg Drokin --- drivers/staging/lustre/lnet/lnet/api-ni.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/staging/lustre/lnet/lnet/api-ni.c b/drivers/staging/lustre/lnet/lnet/api-ni.c index a666d49..7395985 100644 --- a/drivers/staging/lustre/lnet/lnet/api-ni.c +++ b/drivers/staging/lustre/lnet/lnet/api-ni.c @@ -2041,7 +2041,7 @@ LNetCtl(unsigned int cmd, void *arg) id.nid = data->ioc_nid; id.pid = data->ioc_u32[0]; rc = lnet_ping(id, data->ioc_u32[1], /* timeout */ - data->ioc_pbuf1, + (lnet_process_id_t __user *)data->ioc_pbuf1, data->ioc_plen1 / sizeof(lnet_process_id_t)); if (rc < 0) return rc; -- 1.7.1
[PATCH 08/10] staging: lustre: change test to asser in LNetGetId
The ln_refcount test was changed into an assert. Signed-off-by: James Simmons --- drivers/staging/lustre/lnet/lnet/api-ni.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/staging/lustre/lnet/lnet/api-ni.c b/drivers/staging/lustre/lnet/lnet/api-ni.c index 7395985..4843980 100644 --- a/drivers/staging/lustre/lnet/lnet/api-ni.c +++ b/drivers/staging/lustre/lnet/lnet/api-ni.c @@ -2090,9 +2090,7 @@ LNetGetId(unsigned int index, lnet_process_id_t *id) int cpt; int rc = -ENOENT; - /* LNetNI initilization failed? */ - if (!the_lnet.ln_refcount) - return rc; + LASSERT(the_lnet.ln_refcount > 0); cpt = lnet_net_lock_current(); -- 1.7.1
[PATCH 03/10] staging: lustre: fix 'data race condition' issue in conrpc.c
From: Sebastien Buisson
Fix 'data race condition' defects found by Coverity version 6.5.0:
Data race condition (MISSING_LOCK)
Accessing variable without holding lock. Elsewhere,
this variable is accessed with lock held.
Signed-off-by: Sebastien Buisson
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-2744
Reviewed-on: http://review.whamcloud.com/6567
Reviewed-by: Liang Zhen
Reviewed-by: Dmitry Eremin
Reviewed-by: Oleg Drokin
---
drivers/staging/lustre/lnet/selftest/conrpc.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.c
b/drivers/staging/lustre/lnet/selftest/conrpc.c
index e6376a0..8a67f89 100644
--- a/drivers/staging/lustre/lnet/selftest/conrpc.c
+++ b/drivers/staging/lustre/lnet/selftest/conrpc.c
@@ -945,8 +945,12 @@ lstcon_sesnew_stat_reply(lstcon_rpc_trans_t *trans,
return status;
if (!trans->tas_feats_updated) {
- trans->tas_feats_updated = 1;
- trans->tas_features = reply->msg_ses_feats;
+ spin_lock(&console_session.ses_rpc_lock);
+ if (!trans->tas_feats_updated) { /* recheck with lock */
+ trans->tas_feats_updated = 1;
+ trans->tas_features = reply->msg_ses_feats;
+ }
+ spin_unlock(&console_session.ses_rpc_lock);
}
if (reply->msg_ses_feats != trans->tas_features) {
--
1.7.1
Re: [PATCH v5 09/26] mtd: nand: omap: Clean up device tree support
A couple of sparse warnings.
On Fri, Feb 19, 2016 at 11:15:31PM +0200, Roger Quadros wrote:
> Move NAND specific device tree parsing to NAND driver.
>
> The NAND controller node must have a compatible id, register space
> resource and interrupt resource.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/gpmc-nand.c | 5 +-
> drivers/memory/omap-gpmc.c | 143
> +++
> drivers/mtd/nand/omap2.c | 133 +
> include/linux/platform_data/mtd-nand-omap2.h | 3 +-
> 4 files changed, 152 insertions(+), 132 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
> index 04e6998..f6ac027 100644
> --- a/arch/arm/mach-omap2/gpmc-nand.c
> +++ b/arch/arm/mach-omap2/gpmc-nand.c
[...]
> @@ -2039,9 +1939,42 @@ static int gpmc_probe_generic_child(struct
> platform_device *pdev,
> goto err;
> }
>
> - ret = of_property_read_u32(child, "bank-width", &gpmc_s.device_width);
> - if (ret < 0)
> - goto err;
> + if (of_node_cmp(child->name, "nand") == 0) {
> + /* NAND specific setup */
> + u32 val;
drivers/memory/omap-gpmc.c:1952:13: originally declared here [sparse]
drivers/memory/omap-gpmc.c:2029:21: warning: symbol 'val' shadows an earlier
one [sparse]
> +
> + /* Warn about older DT blobs with no compatible property */
> + if (!of_property_read_bool(child, "compatible")) {
> + dev_warn(&pdev->dev,
> + "Incompatible NAND node: missing compatible");
> + ret = -EINVAL;
> + goto err;
> + }
> +
[...]
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 9e99199..0a637c4 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
[...]
> +static int omap_get_dt_info(struct device *dev, struct omap_nand_info *info)
> +{
> + struct device_node *child = dev->of_node;
> + int i;
> + const char *s;
> +
> + /* In old bindings, CS num is embedded in reg property */
> + if (of_property_read_u32(child, "reg", &info->gpmc_cs) < 0) {
Sparse doesn't like this one:
drivers/mtd/nand/omap2.c:1660:49: warning: incorrect type in argument 3
(different signedness) [sparse]
drivers/mtd/nand/omap2.c:1660:49:expected unsigned int [usertype]
*out_value [sparse]
drivers/mtd/nand/omap2.c:1660:49:got int * [sparse]
> + dev_err(dev, "reg not found in DT\n");
> + return -EINVAL;
> + }
> +
[...]
Brian
[PATCH 10/10] staging: lustre: make LNet use lprocfs_call_handler
Sometime ago a patch was submitted to duplicate the
proc_call_handler code in the LNet layer. This was
due to the thinking libcfs was not used by the LNet
layer. This was a wrong assumption so lets make LNet
use the lprocfs_call_handler from the libcfs layer.
Signed-off-by: James Simmons
---
.../staging/lustre/include/linux/libcfs/libcfs.h |4 ++
drivers/staging/lustre/lnet/lnet/router_proc.c | 32
drivers/staging/lustre/lustre/libcfs/module.c |9 +++--
3 files changed, 15 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
index 1eab0eb..7d63620 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs.h
@@ -154,5 +154,9 @@ struct lnet_debugfs_symlink_def {
void lustre_insert_debugfs(struct ctl_table *table,
const struct lnet_debugfs_symlink_def *symlinks);
+int lprocfs_call_handler(void *data, int write, loff_t *ppos,
+void __user *buffer, size_t *lenp,
+int (*handler)(void *data, int write,
+loff_t pos, void __user *buffer, int len));
#endif /* _LIBCFS_H */
diff --git a/drivers/staging/lustre/lnet/lnet/router_proc.c
b/drivers/staging/lustre/lnet/lnet/router_proc.c
index ce4331e..65f65a3 100644
--- a/drivers/staging/lustre/lnet/lnet/router_proc.c
+++ b/drivers/staging/lustre/lnet/lnet/router_proc.c
@@ -73,26 +73,6 @@
#define LNET_PROC_VERSION(v) ((unsigned int)((v) & LNET_PROC_VER_MASK))
-static int proc_call_handler(void *data, int write, loff_t *ppos,
-void __user *buffer, size_t *lenp,
-int (*handler)(void *data, int write,
- loff_t pos, void __user *buffer,
- int len))
-{
- int rc = handler(data, write, *ppos, buffer, *lenp);
-
- if (rc < 0)
- return rc;
-
- if (write) {
- *ppos += *lenp;
- } else {
- *lenp = rc;
- *ppos += rc;
- }
- return 0;
-}
-
static int __proc_lnet_stats(void *data, int write,
loff_t pos, void __user *buffer, int nob)
{
@@ -144,8 +124,8 @@ static int __proc_lnet_stats(void *data, int write,
static int proc_lnet_stats(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- return proc_call_handler(table->data, write, ppos, buffer, lenp,
-__proc_lnet_stats);
+ return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
+ __proc_lnet_stats);
}
static int proc_lnet_routes(struct ctl_table *table, int write,
@@ -640,8 +620,8 @@ static int __proc_lnet_buffers(void *data, int write,
static int proc_lnet_buffers(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- return proc_call_handler(table->data, write, ppos, buffer, lenp,
-__proc_lnet_buffers);
+ return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
+ __proc_lnet_buffers);
}
static int proc_lnet_nis(struct ctl_table *table, int write,
@@ -865,8 +845,8 @@ static int proc_lnet_portal_rotor(struct ctl_table *table,
int write,
void __user *buffer, size_t *lenp,
loff_t *ppos)
{
- return proc_call_handler(table->data, write, ppos, buffer, lenp,
-__proc_lnet_portal_rotor);
+ return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
+ __proc_lnet_portal_rotor);
}
static struct ctl_table lnet_table[] = {
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
b/drivers/staging/lustre/lustre/libcfs/module.c
index a7e06ec..cdc640b 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -217,10 +217,10 @@ struct cfs_psdev_ops libcfs_psdev_ops = {
libcfs_ioctl
};
-static int lprocfs_call_handler(void *data, int write, loff_t *ppos,
-void __user *buffer, size_t *lenp,
-int (*handler)(void *data, int write, loff_t pos,
- void __user *buffer, int len))
+int lprocfs_call_handler(void *data, int write, loff_t *ppos,
+void __user *buffer, size_t *lenp,
+int (*handler)(void *data, int write, loff_t pos,
+ void __user *buffer, int len))
{
int rc = handler(data, write, *ppos, buffer, *lenp);
@@ -235,6 +235,7 @@ static int lprocfs_call_handler(v
[PATCH 09/10] staging: lustre: rename proc_call_handler to lprocfs_call_handler
Using proc_call_handler as a function name is way too generic.
Rename to lprocfs_call_handler to avoid possible collisions.
Signed-off-by: James Simmons
---
drivers/staging/lustre/lustre/libcfs/module.c | 18 +-
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/module.c
b/drivers/staging/lustre/lustre/libcfs/module.c
index 2a62331..a7e06ec 100644
--- a/drivers/staging/lustre/lustre/libcfs/module.c
+++ b/drivers/staging/lustre/lustre/libcfs/module.c
@@ -217,7 +217,7 @@ struct cfs_psdev_ops libcfs_psdev_ops = {
libcfs_ioctl
};
-static int proc_call_handler(void *data, int write, loff_t *ppos,
+static int lprocfs_call_handler(void *data, int write, loff_t *ppos,
void __user *buffer, size_t *lenp,
int (*handler)(void *data, int write, loff_t pos,
void __user *buffer, int len))
@@ -280,8 +280,8 @@ static int __proc_dobitmasks(void *data, int write,
static int proc_dobitmasks(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- return proc_call_handler(table->data, write, ppos, buffer, lenp,
-__proc_dobitmasks);
+ return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
+ __proc_dobitmasks);
}
static int __proc_dump_kernel(void *data, int write,
@@ -296,8 +296,8 @@ static int __proc_dump_kernel(void *data, int write,
static int proc_dump_kernel(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- return proc_call_handler(table->data, write, ppos, buffer, lenp,
-__proc_dump_kernel);
+ return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
+ __proc_dump_kernel);
}
static int __proc_daemon_file(void *data, int write,
@@ -319,8 +319,8 @@ static int __proc_daemon_file(void *data, int write,
static int proc_daemon_file(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- return proc_call_handler(table->data, write, ppos, buffer, lenp,
-__proc_daemon_file);
+ return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
+ __proc_daemon_file);
}
static int libcfs_force_lbug(struct ctl_table *table, int write,
@@ -389,8 +389,8 @@ static int __proc_cpt_table(void *data, int write,
static int proc_cpt_table(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
- return proc_call_handler(table->data, write, ppos, buffer, lenp,
-__proc_cpt_table);
+ return lprocfs_call_handler(table->data, write, ppos, buffer, lenp,
+ __proc_cpt_table);
}
static struct ctl_table lnet_table[] = {
--
1.7.1
[PATCH 01/10] staging: lustre: LNet drop rule implementation
From: Liang Zhen
This is implementation of LNet Drop Rule, which can randomly drop
LNet messages at specified rate.
LNet Drop Rule can only be applied to receive side of message. User
can add drop_rule either on end point of cluster (client/server) or
on LNet routers.
Here are lctl command to control LNet Drop Rules:
- net_drop_add -s SRC_NID -d DEST_NID --rate VALUE
drop 1/@VALUE of messages from @SRC_NID to @DEST_NID
- net_drop_del -s SRC_NID -d DEST_NID
remove all drop rules from @SRC_NID to @DEST_NID
- net_drop_list
list all drop rules on current node
Examples:
- lctl net_drop_add -s *@o2ib0 -d 192.168.1.102@tcp 1000
add new drop rule, it will drop 1/1000 messages from network o2ib0
to 192.168.1.102@tcp
- lctl net_drop_add -s 10.8.6.123@o2ib1 -d * 500
add new drop rule, it will drop 1/500 messages from 10.8.6.123@o2ib1
to all nodes
Signed-off-by: Liang Zhen
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-5435
Reviewed-on: http://review.whamcloud.com/11314
Reviewed-by: Bobi Jam
Reviewed-by: Amir Shehata
Reviewed-by: Johann Lombardi
Reviewed-by: Oleg Drokin
---
.../lustre/include/linux/libcfs/libcfs_ioctl.h |1 +
.../staging/lustre/include/linux/lnet/lib-lnet.h | 10 +
.../staging/lustre/include/linux/lnet/lib-types.h |2 +
.../staging/lustre/include/linux/lnet/lnetctl.h| 83
drivers/staging/lustre/lnet/lnet/Makefile |2 +-
drivers/staging/lustre/lnet/lnet/api-ni.c |6 +
drivers/staging/lustre/lnet/lnet/lib-move.c|8 +
drivers/staging/lustre/lnet/lnet/net_fault.c | 436
8 files changed, 547 insertions(+), 1 deletions(-)
create mode 100644 drivers/staging/lustre/lnet/lnet/net_fault.c
diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
index f788631..5ca99bd 100644
--- a/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
+++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_ioctl.h
@@ -121,6 +121,7 @@ struct libcfs_ioctl_handler {
#define IOC_LIBCFS_PING_IOWR('e', 61, long)
/* #define IOC_LIBCFS_DEBUG_PEER _IOWR('e', 62, long) */
#define IOC_LIBCFS_LNETST_IOWR('e', 63, long)
+#defineIOC_LIBCFS_LNET_FAULT _IOWR('e', 64, long)
/* lnd ioctls */
#define IOC_LIBCFS_REGISTER_MYNID_IOWR('e', 70, long)
#define IOC_LIBCFS_CLOSE_CONNECTION_IOWR('e', 71, long)
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index 84642dc..7b3f858 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -578,6 +578,16 @@ char *lnet_msgtyp2str(int type);
void lnet_print_hdr(lnet_hdr_t *hdr);
int lnet_fail_nid(lnet_nid_t nid, unsigned int threshold);
+/** \addtogroup lnet_fault_simulation @{ */
+
+int lnet_fault_ctl(int cmd, struct libcfs_ioctl_data *data);
+int lnet_fault_init(void);
+void lnet_fault_fini(void);
+
+bool lnet_drop_rule_match(lnet_hdr_t *hdr);
+
+/** @} lnet_fault_simulation */
+
void lnet_counters_get(lnet_counters_t *counters);
void lnet_counters_reset(void);
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h
b/drivers/staging/lustre/include/linux/lnet/lib-types.h
index d2513db..cb09a8a 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
@@ -40,6 +40,7 @@
#include
#include "types.h"
+#include "lnetctl.h"
/* Max payload size */
#define LNET_MAX_PAYLOAD CONFIG_LNET_MAX_PAYLOAD
@@ -572,6 +573,7 @@ typedef struct {
struct lnet_peer_table **ln_peer_tables;
/* failure simulation */
struct list_head ln_test_peers;
+ struct list_head ln_drop_rules;
struct list_head ln_nis; /* LND instances */
/* NIs bond on specific CPT(s) */
diff --git a/drivers/staging/lustre/include/linux/lnet/lnetctl.h
b/drivers/staging/lustre/include/linux/lnet/lnetctl.h
index 4b64f62..ec33bf8 100644
--- a/drivers/staging/lustre/include/linux/lnet/lnetctl.h
+++ b/drivers/staging/lustre/include/linux/lnet/lnetctl.h
@@ -17,6 +17,89 @@
#include "types.h"
+/** \addtogroup lnet_fault_simulation
+ * @{
+ */
+
+enum {
+ LNET_CTL_DROP_ADD,
+ LNET_CTL_DROP_DEL,
+ LNET_CTL_DROP_RESET,
+ LNET_CTL_DROP_LIST,
+};
+
+#define LNET_ACK_BIT BIT(0)
+#define LNET_PUT_BIT BIT(1)
+#define LNET_GET_BIT BIT(2)
+#define LNET_REPLY_BIT BIT(3)
+
+/** ioctl parameter for LNet fault simulation */
+struct lnet_fault_attr {
+ /**
+* source NID of drop rule
+* LNET_NID_ANY is wildcard for all sources
+* 255.255.255.255@net is wildcard for all addresses from @net
+*/
+ lnet_nid_t
[PATCH 00/10] Last batch of fixes for LNet
This batch merges the remaining LNet patches from the OpenSFS branch for the upstream client. Once merged the LNet code will be up to date with the latest production code. Only style issues are remaining. Still future patches being developed for LNet will be landed to the upstream client as soon as they are ready after extensive testing. Frank Zago (1): staging: lustre: add last missing sparse annotation __user James Nunez (1): staging: lustre: Correct missing newline James Simmons (3): staging: lustre: change test to asser in LNetGetId staging: lustre: rename proc_call_handler to lprocfs_call_handler staging: lustre: make LNet use lprocfs_call_handler Liang Zhen (2): staging: lustre: LNet drop rule implementation staging: lustre: LNet network latency simulation Sebastien Buisson (3): staging: lustre: fix 'data race condition' issue in conrpc.c staging: lustre: fix 'NULL pointer dereference' errors staging: lustre: fix 'data race condition' issue in framework.c .../staging/lustre/include/linux/libcfs/libcfs.h |4 + .../lustre/include/linux/libcfs/libcfs_ioctl.h |1 + .../staging/lustre/include/linux/lnet/lib-lnet.h | 27 + .../staging/lustre/include/linux/lnet/lib-types.h |5 + .../staging/lustre/include/linux/lnet/lnetctl.h| 100 ++ drivers/staging/lustre/lnet/lnet/Makefile |2 +- drivers/staging/lustre/lnet/lnet/api-ni.c | 13 +- drivers/staging/lustre/lnet/lnet/lib-move.c| 83 +- drivers/staging/lustre/lnet/lnet/lib-msg.c |6 + drivers/staging/lustre/lnet/lnet/net_fault.c | 1025 drivers/staging/lustre/lnet/lnet/router_proc.c | 32 +- drivers/staging/lustre/lnet/selftest/conctl.c | 49 +- drivers/staging/lustre/lnet/selftest/conrpc.c |8 +- drivers/staging/lustre/lnet/selftest/framework.c |9 +- drivers/staging/lustre/lnet/selftest/rpc.c |2 +- .../lustre/lustre/include/lustre/lustre_user.h |3 + drivers/staging/lustre/lustre/ldlm/ldlm_request.c |9 +- .../staging/lustre/lustre/libcfs/libcfs_string.c | 27 +- drivers/staging/lustre/lustre/libcfs/module.c | 25 +- drivers/staging/lustre/lustre/llite/file.c |8 +- drivers/staging/lustre/lustre/lmv/lmv_obd.c|4 +- drivers/staging/lustre/lustre/lov/lov_lock.c |2 +- drivers/staging/lustre/lustre/lov/lov_obd.c|2 +- drivers/staging/lustre/lustre/lov/lov_pool.c |4 +- drivers/staging/lustre/lustre/lov/lov_request.c|2 +- drivers/staging/lustre/lustre/mdc/mdc_request.c|3 +- drivers/staging/lustre/lustre/mgc/mgc_request.c| 11 +- drivers/staging/lustre/lustre/obdclass/cl_lock.c |2 +- .../lustre/lustre/obdclass/lprocfs_status.c| 26 +- drivers/staging/lustre/lustre/obdclass/lu_object.c |2 +- .../staging/lustre/lustre/obdecho/echo_client.c|8 +- drivers/staging/lustre/lustre/osc/osc_cache.c |9 +- drivers/staging/lustre/lustre/osc/osc_lock.c |2 +- drivers/staging/lustre/lustre/osc/osc_request.c|3 +- drivers/staging/lustre/lustre/ptlrpc/client.c |6 +- drivers/staging/lustre/lustre/ptlrpc/layout.c |2 +- drivers/staging/lustre/lustre/ptlrpc/sec.c |4 +- 37 files changed, 1380 insertions(+), 150 deletions(-) create mode 100644 drivers/staging/lustre/lnet/lnet/net_fault.c
Re: [PATCH v5 10/26] mtd: nand: omap: Update DT binding documentation
On Fri, Feb 19, 2016 at 11:15:32PM +0200, Roger Quadros wrote:
> Add compatible id and interrupts. The NAND interrupts are
> provided by the GPMC controller node.
>
> Signed-off-by: Roger Quadros
> ---
> Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 17 +
> 1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index fb733c4..810b87b 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -13,7 +13,11 @@ Documentation/devicetree/bindings/mtd/nand.txt
>
> Required properties:
>
> - - reg: The CS line the peripheral is connected to
> + - compatible: "ti,omap2-nand"
> + - reg: range id (CS number), base offset and length of the
> + NAND I/O space
Is it normal to mix types of addressing in a single 'reg' property? Is
your code working for anything besides CS==0?
Brian
> + - interrupt-parent: must point to gpmc node
> + - interrupts: Two interrupt specifiers, one for fifoevent, one for
> termcount.
>
> Optional properties:
>
> @@ -55,20 +59,25 @@ Example for an AM33xx board:
> gpmc: gpmc@5000 {
> compatible = "ti,am3352-gpmc";
> ti,hwmods = "gpmc";
> - reg = <0x5000 0x100>;
> + reg = <0x5000 0x36c>;
> interrupts = <100>;
> gpmc,num-cs = <8>;
> gpmc,num-waitpins = <2>;
> #address-cells = <2>;
> #size-cells = <1>;
> - ranges = <0 0 0x0800 0x2000>; /* CS0: NAND */
> + ranges = <0 0 0x0800 0x100>;/* CS0 space, 16MB */
> elm_id = <&elm>;
>
> nand@0,0 {
> - reg = <0 0 0>; /* CS0, offset 0 */
> + compatible = "ti,omap2-nand";
> + reg = <0 0 4>; /* CS0, offset 0, NAND I/O
> window 4 */
> + interrupt-parent = <&gpmc>;
> + interrupts = <0 IRQ_TYPE_NONE>, <1 IRQ_TYPE NONE>;
> nand-bus-width = <16>;
> ti,nand-ecc-opt = "bch8";
> ti,nand-xfer-type = "polled";
> + interrupt-parent = <&gpmc>;
> + interrupts = <0>, <1>;
>
> gpmc,sync-clk-ps = <0>;
> gpmc,cs-on-ns = <0>;
> --
> 2.1.4
>
Re: [PATCH v2 2/3] libnvdimm, pmem: adjust for section collisions with 'System RAM'
On Thu, 2016-03-03 at 13:53 -0800, Dan Williams wrote:
> On a platform where 'Persistent Memory' and 'System RAM' are mixed
> within a given sparsemem section, trim the namespace and notify about the
> sub-optimal alignment.
>
> Cc: Toshi Kani
> Cc: Ross Zwisler
> Signed-off-by: Dan Williams
> ---
> drivers/nvdimm/namespace_devs.c |7 ++
> drivers/nvdimm/pfn.h| 10 ++-
> drivers/nvdimm/pfn_devs.c |5 ++
> drivers/nvdimm/pmem.c | 125 -
> --
> 4 files changed, 111 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/nvdimm/namespace_devs.c
> b/drivers/nvdimm/namespace_devs.c
> index 8ebfcaae3f5a..463756ca2d4b 100644
> --- a/drivers/nvdimm/namespace_devs.c
> +++ b/drivers/nvdimm/namespace_devs.c
> @@ -133,6 +133,7 @@ bool nd_is_uuid_unique(struct device *dev, u8 *uuid)
> bool pmem_should_map_pages(struct device *dev)
> {
> struct nd_region *nd_region = to_nd_region(dev->parent);
> + struct nd_namespace_io *nsio;
>
> if (!IS_ENABLED(CONFIG_ZONE_DEVICE))
> return false;
> @@ -143,6 +144,12 @@ bool pmem_should_map_pages(struct device *dev)
> if (is_nd_pfn(dev) || is_nd_btt(dev))
> return false;
>
> + nsio = to_nd_namespace_io(dev);
> + if (region_intersects(nsio->res.start, resource_size(&nsio-
> >res),
> + IORESOURCE_SYSTEM_RAM,
> + IORES_DESC_NONE) == REGION_MIXED)
Should this be != REGION_DISJOINT for safe?
> + return false;
> +
:
> @@ -304,21 +311,56 @@ static int nd_pfn_init(struct nd_pfn *nd_pfn)
> }
>
> memset(pfn_sb, 0, sizeof(*pfn_sb));
> - npfns = (pmem->size - SZ_8K) / SZ_4K;
> +
> + /*
> + * Check if pmem collides with 'System RAM' when section aligned
> and
> + * trim it accordingly
> + */
> + nsio = to_nd_namespace_io(&ndns->dev);
> + start = PHYS_SECTION_ALIGN_DOWN(nsio->res.start);
> + size = resource_size(&nsio->res);
> + if (region_intersects(start, size, IORESOURCE_SYSTEM_RAM,
> + IORES_DESC_NONE) == REGION_MIXED) {
> +
> + start = nsio->res.start;
> + start_pad = PHYS_SECTION_ALIGN_UP(start) - start;
> + }
> +
> + start = nsio->res.start;
> + size = PHYS_SECTION_ALIGN_UP(start + size) - start;
> + if (region_intersects(start, size, IORESOURCE_SYSTEM_RAM,
> + IORES_DESC_NONE) == REGION_MIXED) {
> + size = resource_size(&nsio->res);
> + end_trunc = start + size - PHYS_SECTION_ALIGN_DOWN(start
> + size);
> + }
This check seems to assume that guest's regular memory layout does not
change. That is, if there is no collision at first, there won't be any
later. Is this a valid assumption?
Thanks,
-Toshi
Re: [RESEND PATCH v5 2/2] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan
Hi Adrian,
On 2016/3/4 20:12, Adrian Hunter wrote:
[...]
I don't know that disabling clocks is necessarily the right thing to do if
the resume fails. You might want to consider what happens if the system
tries to use the device when it is in that state. It's been a long time
since I did any ARM work but aren't you risking bus errors. Might just as
well not bother and save a few lines of code.
Firstly, I really just follow the orginal err handle.
It's risking bus errors if disabling ahb clk, but ahb clk is most very
likely to shared by many controllers. So regarding to the clk reference
count, the ahb_clk is not *really* disabled and just decrease the
reference count. How about keep these handles here?
I would remove the error handling on the grounds that it does not do
anything useful.
Take another ronud of thinking it, probably you are right. When failing
to resume from deelp sleep, we return err to dpm. dpm still roll-forward
to wakeup by calling resume callback one-by-one. It means that finally
when system in wakeup state with disabled ahb_clk, but we then going to
access mmc as normal, which is not acceptable. Especially for debuging
the failure, we have to enable ahb_clk manually.
Will remove the error handling.
Thanks.
+return ret;
}
#endif /* ! CONFIG_PM_SLEEP */
@@ -183,6 +207,30 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
goto clk_disable_all;
}
+sdhci_arasan->phy = ERR_PTR(-ENODEV);
+if (of_device_is_compatible(pdev->dev.of_node,
+"arasan,sdhci-5.1")) {
+sdhci_arasan->phy = devm_phy_get(&pdev->dev,
+ "phy_arasan");
+if (IS_ERR(sdhci_arasan->phy)) {
+ret = PTR_ERR(sdhci_arasan->phy);
+dev_err(&pdev->dev, "No phy for arasan,sdhci-5.1.\n");
+goto clk_disable_all;
+}
+
+ret = phy_init(sdhci_arasan->phy);
+if (ret < 0) {
+dev_err(&pdev->dev, "phy_init err.\n");
+goto clk_disable_all;
+}
+
+ret = phy_power_on(sdhci_arasan->phy);
+if (ret < 0) {
+dev_err(&pdev->dev, "phy_power_on err.\n");
+goto err_phy_power;
+}
+}
+
ret = sdhci_add_host(host);
if (ret)
goto err_pltfm_free;
@@ -190,7 +238,12 @@ static int sdhci_arasan_probe(struct platform_device
*pdev)
return 0;
err_pltfm_free:
+if (!IS_ERR(sdhci_arasan->phy))
+phy_power_off(sdhci_arasan->phy);
sdhci_pltfm_free(pdev);
+err_phy_power:
+if (!IS_ERR(sdhci_arasan->phy))
Looks like you are using sdhci_arasan after it has been free'd by
sdhci_pltfm_free().
Also there seem to be cases where sdhci_arasan_probe() can exit after
sdhci_pltfm_init() without calling sdhci_pltfm_free().
Good catch, will fix it.
+phy_exit(sdhci_arasan->phy);
clk_disable_all:
clk_disable_unprepare(clk_xin);
clk_dis_ahb:
@@ -205,6 +258,11 @@ static int sdhci_arasan_remove(struct
platform_device *pdev)
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
+if (!IS_ERR(sdhci_arasan->phy)) {
+phy_power_off(sdhci_arasan->phy);
+phy_exit(sdhci_arasan->phy);
+}
+
When you re-base, take care to keep this chunk above
sdhci_pltfm_unregister().
sure.
Thanks for reviewing it.
clk_disable_unprepare(sdhci_arasan->clk_ahb);
return sdhci_pltfm_unregister(pdev);
--
Best Regards
Shawn Lin
Re: [PATCH] platform/chrome: Add Chrome OS keyboard backlight LEDs support
On Fri, Mar 4, 2016 at 5:23 PM, Dmitry Torokhov
wrote:
> This is a driver for ACPI-based keyboard backlight LEDs found on
> Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports
> backlight as "chromeos::kbd_backlight" LED class device in sysfs.
>
> Signed-off-by: Simon Que
> Signed-off-by: Duncan Laurie
> Signed-off-by: Dmitry Torokhov
> ---
>
> Changes form previous submission:
>
> - moved from drivers/leds to drivers/platform/chrome
> - added method to retrieve brightness from ACPI
> - renamed to cros_kbd_led_backlight
> - config option renamed to CROS_KBD_LED_BACKLIGHT
> - no longer setting initial brightness to max brightness (although on
> Pixel 1 - Link - ACPI initially reports 100 as brightness anyway)
>
> I ran this on Pixel 1; Evan, could you give it a spin on your Pixel 2?
>
> Thanks!
>
> drivers/platform/chrome/Kconfig | 10 ++
> drivers/platform/chrome/Makefile | 15 +--
> drivers/platform/chrome/cros_kbd_led_backlight.c | 123
> +++
> 3 files changed, 141 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
> index d03df4a..76bdae1 100644
> --- a/drivers/platform/chrome/Kconfig
> +++ b/drivers/platform/chrome/Kconfig
> @@ -64,4 +64,14 @@ config CROS_EC_PROTO
> help
>ChromeOS EC communication protocol helpers.
>
> +config CROS_KBD_LED_BACKLIGHT
> + tristate "Backlight LED support for Chrome OS keyboards"
> + depends on LEDS_CLASS && ACPI
> + help
> + This option enables support for the keyboard backlight LEDs on
> + select Chrome OS systems.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called cros_kbd_led_backlight.
> +
> endif # CHROMEOS_PLATFORMS
> diff --git a/drivers/platform/chrome/Makefile
> b/drivers/platform/chrome/Makefile
> index bc498bd..4f34627 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -1,8 +1,9 @@
>
> -obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
> -obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
> -cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o \
> - cros_ec_lightbar.o cros_ec_vbc.o
> -obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
> -obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
> -obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
> +obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
> +obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
> +cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o \
> + cros_ec_lightbar.o cros_ec_vbc.o
> +obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
> +obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
> +obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
> +obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
> diff --git a/drivers/platform/chrome/cros_kbd_led_backlight.c
> b/drivers/platform/chrome/cros_kbd_led_backlight.c
> new file mode 100644
> index 000..55477d7
> --- /dev/null
> +++ b/drivers/platform/chrome/cros_kbd_led_backlight.c
> @@ -0,0 +1,123 @@
> +/*
> + * Keyboard backlight LED driver for Chrome OS.
> + *
> + * Copyright (C) 2012 Google, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* Keyboard LED ACPI Device must be defined in firmware */
> +#define ACPI_KEYBOARD_BACKLIGHT_DEVICE "\\_SB.KBLT"
> +#define ACPI_KEYBOARD_BACKLIGHT_READ ACPI_KEYBOARD_BACKLIGHT_DEVICE ".KBQC"
> +#define ACPI_KEYBOARD_BACKLIGHT_WRITE ACPI_KEYBOARD_BACKLIGHT_DEVICE ".KBCM"
> +
> +#define ACPI_KEYBOARD_BACKLIGHT_MAX100
> +
> +static void keyboard_led_set_brightness(struct led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + union acpi_object param;
> + struct acpi_object_list input;
> + acpi_status status;
> +
> + param.type = ACPI_TYPE_INTEGER;
> + param.integer.value = brightness;
> + input.count = 1;
> + input.pointer = ¶m;
> +
> + status = acpi_evaluate_object(NULL, ACPI_KEYBOARD_BACKLIGHT_WRITE,
> + &input, NULL);
> + if (ACPI_FAILURE(status))
> + dev_err(cdev->dev, "Error setting keybo
Re: [PATCH v5 17/26] mtd: nand: omap2: Implement NAND ready using gpiolib
+ Boris
On Fri, Feb 19, 2016 at 11:15:39PM +0200, Roger Quadros wrote:
> The GPMC WAIT pin status are now available over gpiolib.
> Update the omap_dev_ready() function to use gpio instead of
> directly accessing GPMC register space.
>
> Signed-off-by: Roger Quadros
> ---
> .../devicetree/bindings/mtd/gpmc-nand.txt | 2 ++
> drivers/mtd/nand/omap2.c | 29
> ++
> include/linux/platform_data/mtd-nand-omap2.h | 2 +-
> 3 files changed, 21 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index 810b87b..256bb86 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -48,6 +48,7 @@ Optional properties:
> locating ECC errors for BCHx algorithms. SoC devices which have
> ELM hardware engines should specify this device node in .dtsi
> Using ELM for ECC error correction frees some CPU cycles.
> + - rb-gpios: GPIO specifier for the ready/busy# pin.
^^ Looks better, I think.
Brian
>
> For inline partition table parsing (optional):
>
> @@ -78,6 +79,7 @@ Example for an AM33xx board:
> ti,nand-xfer-type = "polled";
> interrupt-parent = <&gpmc>;
> interrupts = <0>, <1>;
> + rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
>
> gpmc,sync-clk-ps = <0>;
> gpmc,cs-on-ns = <0>;
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 0a637c4..e7939f1 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -183,6 +184,8 @@ struct omap_nand_info {
> struct nand_ecclayout oobinfo;
> /* fields specific for BCHx_HW ECC scheme */
> struct device *elm_dev;
> + /* NAND ready gpio */
> + struct gpio_desc*ready_gpiod;
> };
>
> static inline struct omap_nand_info *mtd_to_omap(struct mtd_info *mtd)
> @@ -1024,21 +1027,16 @@ static int omap_wait(struct mtd_info *mtd, struct
> nand_chip *chip)
> }
>
> /**
> - * omap_dev_ready - calls the platform specific dev_ready function
> + * omap_dev_ready - checks the NAND Ready GPIO line
> * @mtd: MTD device structure
> + *
> + * Returns true if ready and false if busy.
> */
> static int omap_dev_ready(struct mtd_info *mtd)
> {
> - unsigned int val = 0;
> struct omap_nand_info *info = mtd_to_omap(mtd);
>
> - val = readl(info->reg.gpmc_status);
> -
> - if ((val & 0x100) == 0x100) {
> - return 1;
> - } else {
> - return 0;
> - }
> + return gpiod_get_value(info->ready_gpiod);
> }
>
> /**
> @@ -1754,7 +1752,9 @@ static int omap_nand_probe(struct platform_device *pdev)
> info->gpmc_cs = pdata->cs;
> info->reg = pdata->reg;
> info->ecc_opt = pdata->ecc_opt;
> - info->dev_ready = pdata->dev_ready;
> + if (pdata->dev_ready)
> + dev_info(&pdev->dev, "pdata->dev_ready is
> deprecated\n");
> +
> info->xfer_type = pdata->xfer_type;
> info->devsize = pdata->devsize;
> info->elm_of_node = pdata->elm_of_node;
> @@ -1786,6 +1786,13 @@ static int omap_nand_probe(struct platform_device
> *pdev)
> nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
> nand_chip->cmd_ctrl = omap_hwcontrol;
>
> + info->ready_gpiod = devm_gpiod_get_optional(&pdev->dev, "rb",
> + GPIOD_IN);
> + if (IS_ERR(info->ready_gpiod)) {
> + dev_err(dev, "failed to get ready gpio\n");
> + return PTR_ERR(info->ready_gpiod);
> + }
> +
> /*
>* If RDY/BSY line is connected to OMAP then use the omap ready
>* function and the generic nand_wait function which reads the status
> @@ -1793,7 +1800,7 @@ static int omap_nand_probe(struct platform_device *pdev)
>* chip delay which is slightly more than tR (AC Timing) of the NAND
>* device and read status register until you get a failure or success
>*/
> - if (info->dev_ready) {
> + if (info->ready_gpiod) {
> nand_chip->dev_ready = omap_dev_ready;
> nand_chip->chip_delay = 0;
> } else {
> diff --git a/include/linux/platform_data/mtd-nand-omap2.h
> b/include/linux/platform_data/mtd-nand-omap2.h
> index 7f6de53..17d57a1 100644
> --- a/include/linux/platform_data/mtd-nand-omap2.h
> +++ b/include/linux/platform_data/mtd-nand-omap2.h
> @@ -71,7 +71,6 @@ struct omap_nand_platform_data {
> int cs;
> struct mtd_partition*parts;
> int
Re: [PATCH v5 03/26] memory: omap-gpmc: Introduce GPMC to NAND interface
Hi Roger,
On Fri, Feb 19, 2016 at 11:15:25PM +0200, Roger Quadros wrote:
> The OMAP GPMC module has certain registers dedicated for NAND
> access and some NAND bits mixed with other GPMC functionality.
>
> For the NAND dedicated registers we have the struct gpmc_nand_regs.
>
> The NAND driver needs to access NAND specific bits from the
> following non-dedicated registers
> 1) FIFOEVENT and TERMCOUNT from GPMC_IRQENABLE and GPMC_IRQSTATUS
> 2) EMPTYWRITEBUFFERSTATUS from GPMC_STATUS
>
> For accessing these bits we introduce the struct gpmc_nand_ops.
>
> Rename the gpmc_update_nand_reg() API to gpmc_omap_get_nand_ops()
> and make it return the gpmc_nand_ops along with updating the
> gpmc_nand_regs. This API will be called by the OMAP NAND driver
> to access the necessary bits in GPMC register space.
>
> Signed-off-by: Roger Quadros
> ---
> drivers/memory/omap-gpmc.c | 21
> include/linux/omap-gpmc.h | 49
> --
> 2 files changed, 68 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 6515dfc..c2f7320 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -1098,6 +1098,27 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg,
> int cs)
> }
> }
>
> +static struct gpmc_nand_ops nand_ops;
> +
> +/**
> + * gpmc_omap_get_nand_ops - Get the GPMC NAND interface
> + * @regs: the GPMC NAND register map exclusive for NAND use.
> + * @cs: GPMC chip select number on which the NAND sits. The
> + * register map returned will be specific to this chip select.
> + *
> + * Returns NULL on error e.g. invalid cs.
> + */
> +struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *reg, int
> cs)
> +{
> + if (cs >= gpmc_cs_num)
> + return NULL;
> +
> + gpmc_update_nand_reg(reg, cs);
> +
> + return &nand_ops;
> +}
> +EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
> +
> int gpmc_get_client_irq(unsigned irq_config)
> {
> int i;
> diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
> index 2dcef1c..7de9f9b 100644
> --- a/include/linux/omap-gpmc.h
> +++ b/include/linux/omap-gpmc.h
> @@ -14,14 +14,59 @@
> #define GPMC_IRQ_FIFOEVENTENABLE 0x01
> #define GPMC_IRQ_COUNT_EVENT 0x02
>
> +enum gpmc_nand_irq {
> + GPMC_NAND_IRQ_FIFOEVENT = 0,
> + GPMC_NAND_IRQ_TERMCOUNT,
> +};
> +
> +/**
> + * gpmc_nand_ops - Interface between NAND and GPMC
> + * @nand_irq_enable: enable the requested GPMC NAND interrupt event.
> + * @nand_irq_disable: disable the requested GPMC NAND interrupt event.
> + * @nand_irq_clear: clears the GPMC NAND interrupt event status.
> + * @nand_irq_status: get the NAND interrupt event status.
> + * @nand_write_buffer_empty: get the NAND write buffer empty status.
> + */
> +struct gpmc_nand_ops {
> + int (*nand_irq_enable)(enum gpmc_nand_irq irq);
> + int (*nand_irq_disable)(enum gpmc_nand_irq irq);
> + void (*nand_irq_clear)(enum gpmc_nand_irq irq);
> + u32 (*nand_irq_status)(void);
^^ These 4 aren't being used in this revision?
> + bool (*nand_writebuffer_empty)(void);
> +};
> +
> +struct gpmc_nand_regs;
> +
> +#if IS_ENABLED(CONFIG_OMAP_GPMC)
> +struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
> + int cs);
> +#else
> +static inline gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs
> *regs,
> + int cs)
> +{
> + return NULL;
> +}
> +#endif /* CONFIG_OMAP_GPMC */
> +
> +/**/
> +
> +/* deprecated APIs */
> +#if IS_ENABLED(CONFIG_OMAP_GPMC)
> +void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
> +#else
> +static inline void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
> +{
> + reg = NULL;
What are you trying to do here? 'reg' is local, so the assignment is
pointless.
> +}
> +#endif /* CONFIG_OMAP_GPMC */
Brian
[PATCH] platform/chrome: Add Chrome OS keyboard backlight LEDs support
This is a driver for ACPI-based keyboard backlight LEDs found on
Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports
backlight as "chromeos::kbd_backlight" LED class device in sysfs.
Signed-off-by: Simon Que
Signed-off-by: Duncan Laurie
Signed-off-by: Dmitry Torokhov
---
Changes form previous submission:
- moved from drivers/leds to drivers/platform/chrome
- added method to retrieve brightness from ACPI
- renamed to cros_kbd_led_backlight
- config option renamed to CROS_KBD_LED_BACKLIGHT
- no longer setting initial brightness to max brightness (although on
Pixel 1 - Link - ACPI initially reports 100 as brightness anyway)
I ran this on Pixel 1; Evan, could you give it a spin on your Pixel 2?
Thanks!
drivers/platform/chrome/Kconfig | 10 ++
drivers/platform/chrome/Makefile | 15 +--
drivers/platform/chrome/cros_kbd_led_backlight.c | 123 +++
3 files changed, 141 insertions(+), 7 deletions(-)
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index d03df4a..76bdae1 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -64,4 +64,14 @@ config CROS_EC_PROTO
help
ChromeOS EC communication protocol helpers.
+config CROS_KBD_LED_BACKLIGHT
+ tristate "Backlight LED support for Chrome OS keyboards"
+ depends on LEDS_CLASS && ACPI
+ help
+ This option enables support for the keyboard backlight LEDs on
+ select Chrome OS systems.
+
+ To compile this driver as a module, choose M here: the
+ module will be called cros_kbd_led_backlight.
+
endif # CHROMEOS_PLATFORMS
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index bc498bd..4f34627 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -1,8 +1,9 @@
-obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
-obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
-cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o \
- cros_ec_lightbar.o cros_ec_vbc.o
-obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
-obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
-obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
+obj-$(CONFIG_CHROMEOS_LAPTOP) += chromeos_laptop.o
+obj-$(CONFIG_CHROMEOS_PSTORE) += chromeos_pstore.o
+cros_ec_devs-objs := cros_ec_dev.o cros_ec_sysfs.o \
+ cros_ec_lightbar.o cros_ec_vbc.o
+obj-$(CONFIG_CROS_EC_CHARDEV) += cros_ec_devs.o
+obj-$(CONFIG_CROS_EC_LPC) += cros_ec_lpc.o
+obj-$(CONFIG_CROS_EC_PROTO)+= cros_ec_proto.o
+obj-$(CONFIG_CROS_KBD_LED_BACKLIGHT) += cros_kbd_led_backlight.o
diff --git a/drivers/platform/chrome/cros_kbd_led_backlight.c
b/drivers/platform/chrome/cros_kbd_led_backlight.c
new file mode 100644
index 000..55477d7
--- /dev/null
+++ b/drivers/platform/chrome/cros_kbd_led_backlight.c
@@ -0,0 +1,123 @@
+/*
+ * Keyboard backlight LED driver for Chrome OS.
+ *
+ * Copyright (C) 2012 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Keyboard LED ACPI Device must be defined in firmware */
+#define ACPI_KEYBOARD_BACKLIGHT_DEVICE "\\_SB.KBLT"
+#define ACPI_KEYBOARD_BACKLIGHT_READ ACPI_KEYBOARD_BACKLIGHT_DEVICE ".KBQC"
+#define ACPI_KEYBOARD_BACKLIGHT_WRITE ACPI_KEYBOARD_BACKLIGHT_DEVICE ".KBCM"
+
+#define ACPI_KEYBOARD_BACKLIGHT_MAX100
+
+static void keyboard_led_set_brightness(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ union acpi_object param;
+ struct acpi_object_list input;
+ acpi_status status;
+
+ param.type = ACPI_TYPE_INTEGER;
+ param.integer.value = brightness;
+ input.count = 1;
+ input.pointer = ¶m;
+
+ status = acpi_evaluate_object(NULL, ACPI_KEYBOARD_BACKLIGHT_WRITE,
+ &input, NULL);
+ if (ACPI_FAILURE(status))
+ dev_err(cdev->dev, "Error setting keyboard LED value: %d\n",
+ status);
+}
+
+static enum led_brightness
+keyboard_led_get_brightness(struct led_classdev *cdev)
+{
+ unsigned long long brightness;
+ acpi_status status;
+
+ status = acpi_evaluate_integer(NULL, ACPI_KEYBOARD_BACKLIGHT_READ,
+
[PATCH] mtd: nand: check status before reporting timeout
In commit b70af9bef49b ("mtd: nand: increase ready wait timeout and
report timeouts"), we increased the likelihood of scheduling during
nand_wait(). This makes us more likely to hit the time_before(...)
condition, since a lot of time may pass before we get scheduled again.
Now, the loop was already buggy, since we don't check if the NAND is
ready after exiting the loop; we simply print out a timeout warning. Fix
this by doing a final status check before printing a timeout message.
This isn't actually a critical bug, since the only effect is a false
warning print. But too many prints never hurt anyone, did they? :)
Side note: perhaps I'm not smart enough, but I'm not sure what the best
policy is for this kind of loop; do we busy loop (i.e., no
cond_resched()) to keep the lowest I/O latency (it's not great if the
resched is delaying Richard's system ~400ms)? Or do we allow
rescheduling, to play nice with the rest of the system (since some
operations can take quite a while)?
Reported-by: Richard Weinberger
Signed-off-by: Brian Norris
Reviewed-by: Boris Brezillon
Reviewed-by: Richard Weinberger
Reviewed-by: Harvey Hunt
---
drivers/mtd/nand/nand_base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index f2c8ff398d6c..596a9b0503da 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -566,8 +566,8 @@ void nand_wait_ready(struct mtd_info *mtd)
cond_resched();
} while (time_before(jiffies, timeo));
- pr_warn_ratelimited(
- "timeout while waiting for chip to become ready\n");
+ if (!chip->dev_ready(mtd))
+ pr_warn_ratelimited("timeout while waiting for chip to become
ready\n");
out:
led_trigger_event(nand_led_trigger, LED_OFF);
}
--
2.7.0.rc3.207.g0ac5344
Re: [RFT PATCH 1/2] usb: dwc2: Add a 10 ms delay to dwc2_core_reset()
Hi,
On Fri, Mar 4, 2016 at 4:33 PM, Doug Anderson wrote:
> Michael,
>
> On Fri, Mar 4, 2016 at 4:09 PM, Michael Niewoehner
> wrote:
From testing and trying to make sense of the documentation, it appears
that a 10 ms delay is needed after resetting the core to make sure that
everything is stable and consistent. Let's add it.
In my testing (on rk3288) this allows us to revert commit
192cb07f7928 ("usb: dwc2: Fix probe problem on bcm2835"). Though I
could never reproduce the problems on my board, this might also allow us
to revert commit bd84f4ae9986 ("usb: dwc2: Add extra delay when forcing
dr_mode").
Signed-off-by: Douglas Anderson
>>>
>>> Tested-by: Michael Niewoehner
>
> Thanks! That's great news!
>
>
>>> I’m a bit confused since git log says bd84f4ae9986 has been merged in
>>> 62718e304aa6 but looking at drivers/usb/dwc2/core.c it seems the patch has
>>> not been applied anyways ...
>>> However, I tested you your two patches with „magically reverted“
>>> bd84f4ae9986 (msleep 50) on rk3188.
>>> The sdcard keeps being detected and boots just fine.
>> I meant usb stick of course… too much sdcards in my head today \o/.
>
> Odd. It looks to be there for me...
>
> $ git checkout 62718e304aa6
> HEAD is now at 62718e304aa6... Merge tag 'usb-4.5-rc6' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
>
> $ git grep -C3 "NOTE: This is required" -- drivers/usb/dwc2/core.c
> drivers/usb/dwc2/core.c-}
> drivers/usb/dwc2/core.c-
> drivers/usb/dwc2/core.c-/*
> drivers/usb/dwc2/core.c: * NOTE: This is required for some
> rockchip soc based
> drivers/usb/dwc2/core.c- * platforms.
> drivers/usb/dwc2/core.c- */
> drivers/usb/dwc2/core.c-msleep(50);
For anyone playing along at home, please see
.
-Doug
[GIT PULL] libnvdimm, nfit: fix for 4.5-rc7
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
...to receive one straggling fix for NVDIMM support.
The KVM/QEMU enabling for NVDIMMs has recently reached the point where
it is able to accept some ACPI _DSM requests from a guest VM. However
they immediately found that the 4.5-rc kernel is unusable because the
kernel's 'nfit' driver fails to load upon seeing a valid "not
supported" response from the virtual BIOS for an address range scrub
command.
It is not mandatory that a platform implement address range scrubbing,
so this fix from Vishal properly treats the "not supported" response as
"skip scrubbing and continue loading the driver".
The following changes since commit fc77dbd34c5c99bce46d40a2491937c3bcbd10af:
Linux 4.5-rc6 (2016-02-28 08:41:20 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes
for you to fetch changes up to 6e2452dff4441e3dc24d415c8b2cda8a3ba52116:
nfit: Continue init even if ARS commands are unimplemented (2016-03-04
16:46:13 -0800)
Vishal Verma (1):
nfit: Continue init even if ARS commands are unimplemented
drivers/acpi/nfit.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
commit 6e2452dff4441e3dc24d415c8b2cda8a3ba52116
Author: Vishal Verma
Date: Thu Mar 3 15:39:41 2016 -0700
nfit: Continue init even if ARS commands are unimplemented
If firmware doesn't implement any of the ARS commands, take that to
mean that ARS is unsupported, and continue to initialize regions without
bad block lists. We cannot make the assumption that ARS commands will be
unconditionally supported on all NVDIMMs.
Reported-by: Haozhong Zhang
Signed-off-by: Vishal Verma
Acked-by: Xiao Guangrong
Tested-by: Haozhong Zhang
Signed-off-by: Dan Williams
diff --git a/drivers/acpi/nfit.c b/drivers/acpi/nfit.c
index fb53db187854..35947ac87644 100644
--- a/drivers/acpi/nfit.c
+++ b/drivers/acpi/nfit.c
@@ -1590,14 +1590,21 @@ static int acpi_nfit_find_poison(struct acpi_nfit_desc
*acpi_desc,
start = ndr_desc->res->start;
len = ndr_desc->res->end - ndr_desc->res->start + 1;
+ /*
+ * If ARS is unimplemented, unsupported, or if the 'Persistent Memory
+ * Scrub' flag in extended status is not set, skip this but continue
+ * initialization
+ */
rc = ars_get_cap(nd_desc, ars_cap, start, len);
+ if (rc == -ENOTTY) {
+ dev_dbg(acpi_desc->dev,
+ "Address Range Scrub is not implemented, won't create
an error list\n");
+ rc = 0;
+ goto out;
+ }
if (rc)
goto out;
- /*
- * If ARS is unsupported, or if the 'Persistent Memory Scrub' flag in
- * extended status is not set, skip this but continue initialization
- */
if ((ars_cap->status & 0x) ||
!(ars_cap->status >> 16 & ND_ARS_PERSISTENT)) {
dev_warn(acpi_desc->dev,
