[char-misc-next 1/3] mei: bus: remove redundant uuid string in debug messages

[Tomas Winkler]

Remove uuid from the debug messages in bus-fixup.c
as this is already part of the device name.

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/bus-fixup.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 020de5919c21..b2d2a6ea576c 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -48,8 +48,7 @@ static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
  */
 static void number_of_connections(struct mei_cl_device *cldev)
 {
-   dev_dbg(&cldev->dev, "running hook %s on %pUl\n",
-   __func__, mei_me_cl_uuid(cldev->me_cl));
+   dev_dbg(&cldev->dev, "running hook %s\n", __func__);
 
if (cldev->me_cl->props.max_number_of_connections > 1)
cldev->do_match = 0;
@@ -62,8 +61,8 @@ static void number_of_connections(struct mei_cl_device *cldev)
  */
 static void blacklist(struct mei_cl_device *cldev)
 {
-   dev_dbg(&cldev->dev, "running hook %s on %pUl\n",
-   __func__, mei_me_cl_uuid(cldev->me_cl));
+   dev_dbg(&cldev->dev, "running hook %s\n", __func__);
+
cldev->do_match = 0;
 }
 
@@ -208,8 +207,7 @@ static void mei_nfc(struct mei_cl_device *cldev)
 
bus = cldev->bus;
 
-   dev_dbg(bus->dev, "running hook %s: %pUl match=%d\n",
-   __func__, mei_me_cl_uuid(cldev->me_cl), cldev->do_match);
+   dev_dbg(&cldev->dev, "running hook %s\n", __func__);
 
mutex_lock(&bus->device_lock);
/* we need to connect to INFO GUID */
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel

[Peter Ujfalusi]

Hi Laurent,

On 11/09/2015 09:50 PM, Laurent Pinchart wrote:
> Hi Peter,
> 
> Thank you for the patch.
> 
> What happened to this patch series ? It looks like 
> dma_request_slave_channel_compat_reason() isn't in mainline, so I can't apply 
> this patch.
> 
> I'll mark this patch as deferred in patchwork, please resubmit it if you 
> resubmit the series

The original series - containing this patch - generated a bit of discussion
and it seams that I will need to do bigger change in the dmaengine API
compared to this.
I think this patch can be dropped as the dmaengine changes will not go in as
they were.

(and by the look of it the issue you're trying to fix
> still exists, so it would be nice if you could get it eventually fixed).

Yes, the issue still valid for the OMAP/DaVinci driver the series was touching.

I will try to send a new series in the coming weeks.

Thanks,
Péter
> 
> On Tuesday 26 May 2015 16:26:07 Peter Ujfalusi wrote:
>> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
>> channel. Only fall back to pio mode if the error code returned is not
>> -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
>>
>> Signed-off-by: Peter Ujfalusi 
>> CC: Laurent Pinchart 
>> CC: Mauro Carvalho Chehab 
>> ---
>>  drivers/media/platform/omap3isp/isphist.c | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/platform/omap3isp/isphist.c
>> b/drivers/media/platform/omap3isp/isphist.c index
>> 7138b043a4aa..e690ca13af0e 100644
>> --- a/drivers/media/platform/omap3isp/isphist.c
>> +++ b/drivers/media/platform/omap3isp/isphist.c
>> @@ -499,14 +499,20 @@ int omap3isp_hist_init(struct isp_device *isp)
>>  if (res)
>>  sig = res->start;
>>
>> -hist->dma_ch = dma_request_slave_channel_compat(mask,
>> +hist->dma_ch = dma_request_slave_channel_compat_reason(mask,
>>  omap_dma_filter_fn, &sig, isp->dev, "hist");
>> -if (!hist->dma_ch)
>> +if (IS_ERR(hist->dma_ch)) {
>> +ret = PTR_ERR(hist->dma_ch);
>> +if (ret == -EPROBE_DEFER)
>> +return ret;
>> +
>> +hist->dma_ch = NULL;
>>  dev_warn(isp->dev,
>>   "hist: DMA channel request failed, using 
>> PIO\n");
>> -else
>> +} else {
>>  dev_dbg(isp->dev, "hist: using DMA channel %s\n",
>>  dma_chan_name(hist->dma_ch));
>> +}
>>  }
>>
>>  hist->ops = &hist_ops;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[char-misc-next 3/3] mei: prevent queuing new flow control credit.

[Tomas Winkler]

From: Alexander Usyskin 

The MEI  FW can receive only one flow control for read.
Currently the driver only checks if a flow control credit was already
sent and read is pending in the rd_pending queue, but it also has to
check if flow control credit already queued in the write control queue
to prevent sending more than one flow control credits.

Signed-off-by: Alexander Usyskin 
Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/client.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index a6c87c713193..72e32615acd9 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1422,6 +1422,25 @@ out:
 }
 
 /**
+ * mei_cl_is_read_fc_cb - check if read cb is waiting for flow control
+ *for given host client
+ *
+ * @cl: host client
+ *
+ * Return: true, if found at least one cb.
+ */
+static bool mei_cl_is_read_fc_cb(struct mei_cl *cl)
+{
+   struct mei_device *dev = cl->dev;
+   struct mei_cl_cb *cb;
+
+   list_for_each_entry(cb, &dev->ctrl_wr_list.list, list)
+   if (cb->fop_type == MEI_FOP_READ && cb->cl == cl)
+   return true;
+   return false;
+}
+
+/**
  * mei_cl_read_start - the start read client message function.
  *
  * @cl: host client
@@ -1445,7 +1464,7 @@ int mei_cl_read_start(struct mei_cl *cl, size_t length, 
struct file *fp)
return -ENODEV;
 
/* HW currently supports only one pending read */
-   if (!list_empty(&cl->rd_pending))
+   if (!list_empty(&cl->rd_pending) || mei_cl_is_read_fc_cb(cl))
return -EBUSY;
 
if (!mei_me_cl_is_active(cl->me_cl)) {
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[char-misc-next 2/3] mei: trace pci configuration space io

[Tomas Winkler]

Use tracing events also for reading and writing pci configuration space
/tracing/events/mei/mei_pci_reg_{read,write}

Signed-off-by: Tomas Winkler 
---
 drivers/misc/mei/hw-me.c | 10 --
 drivers/misc/mei/hw-txe.c| 10 --
 drivers/misc/mei/mei-trace.c |  2 ++
 drivers/misc/mei/mei-trace.h | 38 ++
 4 files changed, 56 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 25b1997a62cb..e2fb44cc5c37 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -189,8 +189,11 @@ static int mei_me_fw_status(struct mei_device *dev,
 
fw_status->count = fw_src->count;
for (i = 0; i < fw_src->count && i < MEI_FW_STATUS_MAX; i++) {
-   ret = pci_read_config_dword(pdev,
-   fw_src->status[i], &fw_status->status[i]);
+   ret = pci_read_config_dword(pdev, fw_src->status[i],
+   &fw_status->status[i]);
+   trace_mei_pci_cfg_read(dev->dev, "PCI_CFG_HSF_X",
+  fw_src->status[i],
+  fw_status->status[i]);
if (ret)
return ret;
}
@@ -215,6 +218,7 @@ static void mei_me_hw_config(struct mei_device *dev)
 
reg = 0;
pci_read_config_dword(pdev, PCI_CFG_HFS_1, ®);
+   trace_mei_pci_cfg_read(dev->dev, "PCI_CFG_HFS_1", PCI_CFG_HFS_1, reg);
hw->d0i3_supported =
((reg & PCI_CFG_HFS_1_D0I3_MSK) == PCI_CFG_HFS_1_D0I3_MSK);
 
@@ -1248,6 +1252,7 @@ static bool mei_me_fw_type_nm(struct pci_dev *pdev)
u32 reg;
 
pci_read_config_dword(pdev, PCI_CFG_HFS_2, ®);
+   trace_mei_pci_cfg_read(&pdev->dev, "PCI_CFG_HFS_2", PCI_CFG_HFS_2, reg);
/* make sure that bit 9 (NM) is up and bit 10 (DM) is down */
return (reg & 0x600) == 0x200;
 }
@@ -1260,6 +1265,7 @@ static bool mei_me_fw_type_sps(struct pci_dev *pdev)
u32 reg;
/* Read ME FW Status check for SPS Firmware */
pci_read_config_dword(pdev, PCI_CFG_HFS_1, ®);
+   trace_mei_pci_cfg_read(&pdev->dev, "PCI_CFG_HFS_1", PCI_CFG_HFS_1, reg);
/* if bits [19:16] = 15, running SPS Firmware */
return (reg & 0xf) == 0xf;
 }
diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c
index bae680c648ff..4a6c1b85f11e 100644
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -28,6 +28,9 @@
 #include "client.h"
 #include "hbm.h"
 
+#include "mei-trace.h"
+
+
 /**
  * mei_txe_reg_read - Reads 32bit data from the txe device
  *
@@ -640,8 +643,11 @@ static int mei_txe_fw_status(struct mei_device *dev,
 
fw_status->count = fw_src->count;
for (i = 0; i < fw_src->count && i < MEI_FW_STATUS_MAX; i++) {
-   ret = pci_read_config_dword(pdev,
-   fw_src->status[i], &fw_status->status[i]);
+   ret = pci_read_config_dword(pdev, fw_src->status[i],
+   &fw_status->status[i]);
+   trace_mei_pci_cfg_read(dev->dev, "PCI_CFG_HSF_X",
+  fw_src->status[i],
+  fw_status->status[i]);
if (ret)
return ret;
}
diff --git a/drivers/misc/mei/mei-trace.c b/drivers/misc/mei/mei-trace.c
index 388efb519138..e19e6acb191b 100644
--- a/drivers/misc/mei/mei-trace.c
+++ b/drivers/misc/mei/mei-trace.c
@@ -22,4 +22,6 @@
 
 EXPORT_TRACEPOINT_SYMBOL(mei_reg_read);
 EXPORT_TRACEPOINT_SYMBOL(mei_reg_write);
+EXPORT_TRACEPOINT_SYMBOL(mei_pci_cfg_read);
+EXPORT_TRACEPOINT_SYMBOL(mei_pci_cfg_write);
 #endif /* __CHECKER__ */
diff --git a/drivers/misc/mei/mei-trace.h b/drivers/misc/mei/mei-trace.h
index 47e1bc6551d4..86e5068837c1 100644
--- a/drivers/misc/mei/mei-trace.h
+++ b/drivers/misc/mei/mei-trace.h
@@ -64,6 +64,44 @@ TRACE_EVENT(mei_reg_write,
  __get_str(dev), __entry->reg,  __entry->offs, __entry->val)
 );
 
+TRACE_EVENT(mei_pci_cfg_read,
+   TP_PROTO(const struct device *dev, const char *reg, u32 offs, u32 val),
+   TP_ARGS(dev, reg, offs, val),
+   TP_STRUCT__entry(
+   __string(dev, dev_name(dev))
+   __field(const char *, reg)
+   __field(u32, offs)
+   __field(u32, val)
+   ),
+   TP_fast_assign(
+   __assign_str(dev, dev_name(dev))
+   __entry->reg  = reg;
+   __entry->offs = offs;
+   __entry->val = val;
+   ),
+   TP_printk("[%s] pci cfg read %s:[%#x] = %#x",
+ __get_str(dev), __entry->reg, __entry->offs, __entry->val)
+);
+
+TRACE_EVENT(mei_pci_cfg_write,
+   TP_PROTO(const struct device *dev, const char *reg, u32 offs, u32 val),
+   TP_ARGS(dev, reg, offs, val),
+   TP_STRUCT__entry(
+   __string(dev, dev_name(dev))
+   __field(co

Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel

[Laurent Vivier]

Le 10/11/2015 01:29, Michael Ellerman a écrit :
> On Sat, 2015-11-07 at 12:35 +0100, Laurent Vivier wrote:
>> Le 07/11/2015 00:24, Scott Wood a écrit :
>>> On Fri, 2015-11-06 at 23:22 +0100, Laurent Vivier wrote:
 Le 06/11/2015 22:09, Scott Wood a écrit :
> On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
>> When I try to cross compile a ppc64 kernel, it generally
>> fails on the VDSO stage. This is true for powerpc64 cross-
>> compiler, but also when I try to build a ppc64le kernel
>> on a ppc64 host.
>>
>> VDSO64L fails:
>>
>>   VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
>> /usr/bin/powerpc64-linux-gnu-ld: arch/powerpc/kernel/vdso64/sigtramp.o:
>> file class ELFCLASS64 incompatible with ELFCLASS32
>> /usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong format
>>
>> This fails because gcc calls "collect2" with
>> "--oformat elf32-powerpcle" with ppc64 objects, without the
>> "--oformat" ld works well because it use the format of the
>> first object as output format.
>>
>> As this case is correctly managed to build the other kernel
>> objects, this patch replaces $(GCC) by $(LD) to generate the
>> VDSO objects.
>>>
 So at this point, I can:

 1- either fix my compiler,
 2- or fix the vdso64 linker command.
>>>
>> Thank you Scott. With the help of the comment from Segher, I can choose
>> #1 now :)
> 
> What distro/toolchain did you hit this on?

fedora 23.

> I actually wrote this same patch a while back, but from memory it broke in 
> some
> configurations. So I never merged it. I'll see if I can find my notes and work
> out exactly why it didn't work, maybe we should merge it anyway, even though
> the real bug is a toolchain bug.

On fedora, there is also a bug in binutils configuration where ld is not
able to manage ppc64le binaries on ppc64 host, but I've already sent a
fix for that and it is now in rawhide (will be in fedora 24).

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

Laurent
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 16/16] regulator: add LM363X driver

[Kim, Milo]

On 11/4/2015 10:59 PM, Mark Brown wrote:

On Mon, Nov 02, 2015 at 02:24:35PM +0900, Milo Kim wrote:

This looks mostly good, just a few fairly small things:


+lm363x_regulator_of_get_init_data(struct device *dev,
+   struct lm363x_regulator *lm363x_regulator, int id)
+{
+   struct device_node *np = dev->of_node;
+   int count;
+
+   count = of_regulator_match(dev, np, &lm363x_regulator_matches[id], 1);
+   if (count <= 0)
+   return ERR_PTR(-ENODEV);
+
+   return lm363x_regulator_matches[id].init_data;
+}


Don't open code DT matching, use of_match in the regulator_desc and let
the core do it for you.


OK, good.
I've also found wrong pointer reference of regulator_cfg.dev. It should 
be pdev->dev instead of pdev->dev->parent.


-   cfg.dev = dev->parent;
+   cfg.dev = dev;

Old code affects wrong parsing from the DT. So, registered regulator has 
different operation mask. In the end, regulators which has zero use 
count never gonna be disabled in regulator_init_compelete().





+   /*
+* Check LCM_EN1/2_GPIO is configured.
+* Those pins are used for enabling VPOS/VNEG LDOs.
+*/
+   if (id == LM3632_LDO_POS)
+   gpio = of_get_named_gpio(np, "ti,lcm-en1-gpio", 0);
+   else if (id == LM3632_LDO_NEG)
+   gpio = of_get_named_gpio(np, "ti,lcm-en2-gpio", 0);


This looks like it should be a switch statement.


Yep!




+   rdev = regulator_register(&lm363x_regulator_desc[id], &cfg);
+   if (IS_ERR(rdev)) {


Use devm_regulator_register().


OK.




+static const struct of_device_id lm363x_regulator_of_match[] = {
+   { .compatible = "ti,lm363x-regulator" },
+   { }
+};
+MODULE_DEVICE_TABLE(of, lm363x_regulator_of_match);


You shouldn't need a compatible string for a device like this, the MFD
should just register a platform device based on the compatible string
for the MFD.



Thanks for catching this.
Let me apply all your comments in the next patch.

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ASoC: davinci-mcasp: Fix TDM slot rx/tx mask associations

[Peter Ujfalusi]

On 11/09/2015 08:19 PM, Andreas Dannenberg wrote:
> Fixes the associations between the tx_mask and rx_mask and the associated
> playback / capture streams during setting of the TDM slot. With this
> patch in place it is now possible for example to only populate tx_mask
> (leaving rx_mask as 0) for output-only codecs to control the TDM slot(s)
> the McASP serial port uses for transmit. Before that, this scenario
> would incorrectly rely on the rx_mask for this.
> 
> Signed-off-by: Andreas Dannenberg 

Acked-by: Peter Ujfalusi 

> ---
>  sound/soc/davinci/davinci-mcasp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/davinci/davinci-mcasp.c 
> b/sound/soc/davinci/davinci-mcasp.c
> index 4495a40..caa0beb 100644
> --- a/sound/soc/davinci/davinci-mcasp.c
> +++ b/sound/soc/davinci/davinci-mcasp.c
> @@ -681,8 +681,8 @@ static int davinci_mcasp_set_tdm_slot(struct snd_soc_dai 
> *dai,
>   }
>  
>   mcasp->tdm_slots = slots;
> - mcasp->tdm_mask[SNDRV_PCM_STREAM_PLAYBACK] = rx_mask;
> - mcasp->tdm_mask[SNDRV_PCM_STREAM_CAPTURE] = tx_mask;
> + mcasp->tdm_mask[SNDRV_PCM_STREAM_PLAYBACK] = tx_mask;
> + mcasp->tdm_mask[SNDRV_PCM_STREAM_CAPTURE] = rx_mask;
>   mcasp->slot_width = slot_width;
>  
>   return davinci_mcasp_set_ch_constraints(mcasp);
> 


-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] memcg/kmem: switch to white list policy

[Vladimir Davydov]

On Mon, Nov 09, 2015 at 03:30:53PM -0500, Tejun Heo wrote:
...
> Hmm can't we simply merge among !SLAB_ACCOUNT and SLAB_ACCOUNT
> kmem_caches within themselves?  I don't think we'd be losing anything
> by restricting merge at that level.  For anything to be tagged
> SLAB_ACCOUNT, it has to have a potential to grow enormous after all.

OK, I'll prepare v2 which will introduce SLAB_ACCOUNT and add it to
SLAB_MERGE_SAME. Let's see what slab maintainers think of it.

Thanks,
Vladimir
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] arm64: add HAVE_LATENCYTOP_SUPPORT config

[Heiko Carstens]

On Fri, Nov 06, 2015 at 04:21:10PM +, Will Deacon wrote:
> On Sat, Nov 07, 2015 at 12:11:16AM +0800, yalin wang wrote:
> > i just enable it on ARM64,
> > and it can work,
> > i don’t see some special requirement to enable this config .
> 
> Right, so why does HAVE_LATENCYTOP_SUPPORT exist?

If I remember correctly then the only dependency was that an architecture
must have implemented save_stack_trace_tsk().
See git commit a3afe70b83fdbbd4d757d2911900d168bc798a31.

So the name of HAVE_LATENCYTOP_SUPPORT is surely a not well chosen, and I
think I introduced it back then. Oh, well.

And looking through the kernel there is at least avr32 which would break
at build time if the config option would be removed completely.

So.. renaming it to STACKTRACE_TSK_SUPPORT would be a good idea.

Will do when time permits, unless somebody else volunteers.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 15/16] leds: add LM3633 driver

[Kim, Milo]

Hi Jacek,

On 11/4/2015 1:15 AM, Jacek Anaszewski wrote:

Hi Milo,

Thanks for the patch. Please find my comments in the code.


diff --git a/Documentation/ABI/testing/sysfs-class-led-lm3633 
b/Documentation/ABI/testing/sysfs-class-led-lm3633
new file mode 100644
index 000..c1d8759
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-lm3633
@@ -0,0 +1,60 @@
+LM3633 LED driver generates programmable pattern via the sysfs.
+
+LED Pattern Generator Structure
+
+(3)
+  (a) --->  ___
+   /   \
+  (2) / \ (4)
+  (b) > _/   \_  ...
+   (1)   (5)
+
+ |<-   period   -> |
+
+What:  /sys/class/leds//pattern_times


"time" noun is uncountable.


+Date:  Oct 2015
+KernelVersion: 4.3


These properties certainly will not appear in 4.3.


Oops! 4.4 gonna be OK?




+Contact:   Milo Kim 
+Description:   read/write
+Set pattern time dimension. There are five arguments.
+  (1) startup delay
+  (2) rising dimming time
+  (3) how much time stays at high level
+  (4) falling dimming time
+  (5) how much time stays at low level
+Ranges are
+  (1), (3), (5): 0 ~ 1. Unit is millisecond.
+  (2), (4): 0 ~ 16000. Unit is millisecond.
+
+Example:
+No delay, rising 200ms, high 300ms, falling 100ms, low 400ms.
+echo "0 200 300 100 400" > /sys/class/leds//pattern_times
+
+cat /sys/class/leds//pattern_times
+delay: 0, rise: 200, high: 300, fall: 100, low: 400


Generally a sysfs attribute should represent a single value.
There are cases where the attribute comprises a list of space separated
values, but certainly colons and commas adds to much noise, and are
cumbersome to parse. I'd opt for creating a separate sysfs attribute
for each of the above 5 properties.


Got it, thanks!




+What:  /sys/class/leds//pattern_levels
+Date:  Oct 2015
+KernelVersion: 4.3
+Contact:   Milo Kim 
+Description:   read/write
+Set pattern level(brightness). There are two arguments.
+  (a) Low brightness level
+  (b) High brightness level
+Ranges are from 0 to 255.
+
+Example:
+Low level is 0, high level is 255.
+echo "0 255" > /sys/class/leds//pattern_levels


I'd go also for two separate attributes. E.g. pattern_brightness_lo and
pattern_brightness_hi, or maybe you'll have better idea.


OK.




+cat /sys/class/leds//pattern_levels
+low brightness: 0, high brightness: 255
+
+What:  /sys/class/leds//run_pattern
+Date:  Oct 2015
+KernelVersion: 4.3
+Contact:   Milo Kim 
+Description:   write only
+After 'pattern_times' and 'pattern_levels' are updated,
+run the pattern by writing 1 to 'run_pattern'.
+To stop running pattern, writes 0 to 'run_pattern'.


I wonder how registering an in-driver trigger would work. It would
allow for hiding above pattern attributes when the trigger is inactive,
and thus making the sysfs interface more transparent. You could avoid
the need for run_pattern attribute, as setting the trigger would itself
activate the pattern, and setting brightness to 0 would turn it off.


I like this idea, let me try to fix it.


+/**
+ * struct ti_lmu_led
+ *
+ * @chip:  Pointer to parent LED device
+ * @bank_id:   LED bank ID
+ * @cdev:  LED subsystem device structure
+ * @name:  LED channel name
+ * @led_string:LED string configuration.
+ * Bit mask is set on parsing DT.
+ * @imax:  [Optional] Max current index.
+ * It's result of ti_lmu_get_current_code().


Why is this optional?


You're correct, this is not optional. DT property is optional.


+static ssize_t lm3633_led_store_pattern_levels(struct device *dev,
+  struct device_attribute *attr,
+  const char *buf, size_t len)
+{
+   struct ti_lmu_led *lmu_led = to_ti_lmu_led(dev);
+   struct ti_lmu_led_chip *chip = lmu_led->chip;
+   unsigned int low, high;
+   u8 reg, offset, val;
+   int ret;
+
+   /*
+* Sequence
+*
+* 1) Read pattern level data
+* 2) Disable a bank before programming a pattern
+* 3) Update LOW BRIGHTNESS register
+* 4) Update HIGH BRIGHTNESS register
+*
+* Level register addresses have offset number based on the LED bank.
+*/
+
+   ret = sscanf(buf, "%u %u", &low, &high);
+   if (ret != 2)
+

Re: regulator: build warning in regulator_lock_supply()

[Sascha Hauer]

On Mon, Nov 09, 2015 at 07:21:48PM -0800, Frank Rowand wrote:
> In the current Linus tree, new build warning.
> 
> When CONFIG_DEBUG_LOCK_ALLOC is not enabled,
> 
>   drivers/regulator/core.c: In function 'regulator_lock_supply':
>   drivers/regulator/core.c:142:6: warning: unused variable 'i' 
> [-Wunused-variable]
> 
> 
> Introduced by commit
> 
>   9f01cd4a915e1 ("regulator: core: introduce function to lock regulators and 
> its supplies")

We could fix this with the following patch. On the other hand I'd say
that it's not our fault that mutex_lock_nested() doesn't use the
variable, so maybe it should rather be a static inline function instead
of a define?

Sascha

-8<---

>From cacf0a5ae54b5255dfd895d32e74611c6cbeee3f Mon Sep 17 00:00:00 2001
From: Sascha Hauer 
Date: Tue, 10 Nov 2015 08:32:46 +0100
Subject: [PATCH] regulator: core: Fix unused variable warning

When CONFIG_DEBUG_LOCK_ALLOC is not enabled, we get:
  drivers/regulator/core.c: In function 'regulator_lock_supply':
  drivers/regulator/core.c:142:6: warning: unused variable 'i' 
[-Wunused-variable]

Fix this by adding a __maybe_unused annotation.

Signed-off-by: Sascha Hauer 
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 73b7683..2453bce 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -139,7 +139,7 @@ static bool have_full_constraints(void)
 static void regulator_lock_supply(struct regulator_dev *rdev)
 {
struct regulator *supply;
-   int i = 0;
+   int __maybe_unused i = 0;
 
while (1) {
mutex_lock_nested(&rdev->mutex, i++);
-- 
2.6.1


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] ASoC: rockchip: i2s: compatible with different chips

[Sugar Zhang]

there maybe more than one i2s module inside chip, and these i2s modules
have different channels features.

for example: there are 3 i2s in rk3066, one support 8 channels playback
and 2 channels capture, but the others only support 2 channels playback
and 2 channels capture.

in order to compatible with these various chips, we add playback and
capture property to specify these values.

there are default channels configuration in driver: 8 channels playback
and 2 channels capture. if not add property, we use the default values.

Signed-off-by: Sugar Zhang 
---
 sound/soc/rockchip/rockchip_i2s.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/sound/soc/rockchip/rockchip_i2s.c 
b/sound/soc/rockchip/rockchip_i2s.c
index 58ee645..ec88e94 100644
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -451,6 +451,7 @@ static int rockchip_i2s_probe(struct platform_device *pdev)
 {
struct device_node *node = pdev->dev.of_node;
struct rk_i2s_dev *i2s;
+   struct snd_soc_dai_driver *soc_dai;
struct resource *res;
void __iomem *regs;
int ret;
@@ -511,17 +512,26 @@ static int rockchip_i2s_probe(struct platform_device 
*pdev)
goto err_pm_disable;
}
 
-   /* refine capture channels */
+   soc_dai = devm_kzalloc(&pdev->dev,
+  sizeof(*soc_dai), GFP_KERNEL);
+   if (!soc_dai)
+   return -ENOMEM;
+
+   memcpy(soc_dai, &rockchip_i2s_dai, sizeof(*soc_dai));
+   if (!of_property_read_u32(node, "rockchip,playback-channels", &val)) {
+   if (val >= 2 && val <= 8)
+   soc_dai->playback.channels_max = val;
+   }
+
if (!of_property_read_u32(node, "rockchip,capture-channels", &val)) {
if (val >= 2 && val <= 8)
-   rockchip_i2s_dai.capture.channels_max = val;
-   else
-   rockchip_i2s_dai.capture.channels_max = 2;
+   soc_dai->capture.channels_max = val;
}
 
ret = devm_snd_soc_register_component(&pdev->dev,
  &rockchip_i2s_component,
- &rockchip_i2s_dai, 1);
+ soc_dai, 1);
+
if (ret) {
dev_err(&pdev->dev, "Could not register DAI\n");
goto err_suspend;
-- 
2.3.6


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] ARM: dts: rockchip: add channels properties for i2s

[Sugar Zhang]

add playback and capture properties to compatible various chips.

Signed-off-by: Sugar Zhang 
---
 arch/arm/boot/dts/rk3066a.dtsi | 6 ++
 arch/arm/boot/dts/rk3188.dtsi  | 2 ++
 arch/arm/boot/dts/rk3288.dtsi  | 2 ++
 3 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index 946f187..1003f9c 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -103,6 +103,8 @@
dma-names = "tx", "rx";
clock-names = "i2s_hclk", "i2s_clk";
clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>;
+   rockchip,playback-channels = <8>;
+   rockchip,capture-channels = <2>;
status = "disabled";
};
 
@@ -118,6 +120,8 @@
dma-names = "tx", "rx";
clock-names = "i2s_hclk", "i2s_clk";
clocks = <&cru HCLK_I2S1>, <&cru SCLK_I2S1>;
+   rockchip,playback-channels = <2>;
+   rockchip,capture-channels = <2>;
status = "disabled";
};
 
@@ -133,6 +137,8 @@
dma-names = "tx", "rx";
clock-names = "i2s_hclk", "i2s_clk";
clocks = <&cru HCLK_I2S2>, <&cru SCLK_I2S2>;
+   rockchip,playback-channels = <2>;
+   rockchip,capture-channels = <2>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/rk3188.dtsi b/arch/arm/boot/dts/rk3188.dtsi
index 3163042..b9b6b3a 100644
--- a/arch/arm/boot/dts/rk3188.dtsi
+++ b/arch/arm/boot/dts/rk3188.dtsi
@@ -118,6 +118,8 @@
dma-names = "tx", "rx";
clock-names = "i2s_hclk", "i2s_clk";
clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>;
+   rockchip,playback-channels = <2>;
+   rockchip,capture-channels = <2>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 4e7c6b7..e7ce9f1 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -669,6 +669,8 @@
clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>;
pinctrl-names = "default";
pinctrl-0 = <&i2s0_bus>;
+   rockchip,playback-channels = <8>;
+   rockchip,capture-channels = <2>;
status = "disabled";
};
 
-- 
2.3.6


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] ASoC: rockchip: i2s: compatible with different chips

[Sugar Zhang]

there maybe more than one i2s module inside chip, and these i2s modules
have different channels features.

for example: there are 3 i2s in rk3066, one support 8 channels playback
and 2 channels capture, but the others only support 2 channels playback
and 2 channels capture.

in order to compatible with these various chips, we add playback and
capture property to specify these values.

there are default channels configuration in driver: 8 channels playback
and 2 channels capture. if not add property, we use the default values.

Sugar Zhang (3):
  ASoC: rockchip: i2s: compatible with different chips
  ASoC: rockchip: add playback property
  ARM: dts: rockchip: add channels properties for i2s

 .../devicetree/bindings/sound/rockchip-i2s.txt   |  2 ++
 arch/arm/boot/dts/rk3066a.dtsi   |  6 ++
 arch/arm/boot/dts/rk3188.dtsi|  2 ++
 arch/arm/boot/dts/rk3288.dtsi|  2 ++
 sound/soc/rockchip/rockchip_i2s.c| 20 +++-
 5 files changed, 27 insertions(+), 5 deletions(-)

-- 
2.3.6


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] ASoC: rockchip: add playback property

[Sugar Zhang]

rockchip,playback-channels: max playback channels, 8 channels default.

Signed-off-by: Sugar Zhang 
---
 Documentation/devicetree/bindings/sound/rockchip-i2s.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt 
b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
index 2267d24..b7f3a93 100644
--- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt
@@ -19,6 +19,7 @@ Required properties:
 - clock-names: should contain followings:
- "i2s_hclk": clock for I2S BUS
- "i2s_clk" : clock for I2S controller
+- rockchip,playback-channels: max playback channels, if not set, 8 channels 
default.
 - rockchip,capture-channels: max capture channels, if not set, 2 channels 
default.
 
 Example for rk3288 I2S controller:
@@ -31,5 +32,6 @@ i2s@ff89 {
dma-names = "tx", "rx";
clock-names = "i2s_hclk", "i2s_clk";
clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>;
+   rockchip,playback-channels = <8>;
rockchip,capture-channels = <2>;
 };
-- 
2.3.6


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ASoC: mediatek: Move 22M/24M clock control into I2S ops

[Koro Chen]

22M/24M clocks are only required for I2S, so move the control to
I2S DAI ops.

Signed-off-by: Koro Chen 
---
 sound/soc/mediatek/mtk-afe-pcm.c |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/sound/soc/mediatek/mtk-afe-pcm.c b/sound/soc/mediatek/mtk-afe-pcm.c
index f5baf3c..7f71343 100644
--- a/sound/soc/mediatek/mtk-afe-pcm.c
+++ b/sound/soc/mediatek/mtk-afe-pcm.c
@@ -299,8 +299,6 @@ static int mtk_afe_dais_enable_clks(struct mtk_afe *afe,
dev_err(afe->dev, "Failed to enable m_ck\n");
return ret;
}
-   regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
-  AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M, 0);
}
 
if (b_ck) {
@@ -340,12 +338,8 @@ static int mtk_afe_dais_set_clks(struct mtk_afe *afe,
 static void mtk_afe_dais_disable_clks(struct mtk_afe *afe,
  struct clk *m_ck, struct clk *b_ck)
 {
-   if (m_ck) {
-   regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
-  AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M,
-  AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M);
+   if (m_ck)
clk_disable_unprepare(m_ck);
-   }
if (b_ck)
clk_disable_unprepare(b_ck);
 }
@@ -360,6 +354,8 @@ static int mtk_afe_i2s_startup(struct snd_pcm_substream 
*substream,
return 0;
 
mtk_afe_dais_enable_clks(afe, afe->clocks[MTK_CLK_I2S1_M], NULL);
+   regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
+  AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M, 0);
return 0;
 }
 
@@ -373,6 +369,9 @@ static void mtk_afe_i2s_shutdown(struct snd_pcm_substream 
*substream,
return;
 
mtk_afe_set_i2s_enable(afe, false);
+   regmap_update_bits(afe->regmap, AUDIO_TOP_CON0,
+  AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M,
+  AUD_TCON0_PDN_22M | AUD_TCON0_PDN_24M);
mtk_afe_dais_disable_clks(afe, afe->clocks[MTK_CLK_I2S1_M], NULL);
 
/* disable AFE */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [RFC PATCH] ARM: add v7 LPAE multi-platform defconfig

[Huan Wang]

Hi, Olof,
 
> On Mon, Nov 9, 2015 at 6:53 PM, Alison Wang  wrote:
> > v7 LPAE multi-platform defconfig is based on v7 multi-platform
> > defconfig and adds LPAE support.
> >
> > The platforms based on Cortex-A7/A12/A15/A17, PJ4B, Krait are also
> > enabled in this defconfig. But Cortex-A5/A8/A9, Scorpion and PJ4 are
> > removed.
> >
> > This defconfig is verified on LS1021A which enables GIANFAR, I2C,
> > WATCHDOG, AUDIO, EDMA and DSPI drivers, etc.
> >
> > The other platforms need to be verified by the platform maintainers
> > too.
> >
> > Signed-off-by: Alison Wang 
> 
> This has been discussed before, and what we have chosen to do is to just
> have a multi_v7_defconfig that all these platforms are enabled on but
> with LPAE off.
> 
> Instead, what we do when building (and on our build/boot builders) is to
> take multi_v7 and provide the snippet that turns on ARM_LPAE at that
> time.
> 
> 
[Alison Wang] Thanks for your reply. I tried to make this 
multi_v7_lpae_defconfig
according to the discussion with Russell King. He suggested to make a 
multi_v7_lpae_defconfig
rather than creating a new load of platform specific defconfigs. Attached is 
his original email.

King, do you have any comment about Olof's reply?


Best Regards,
Alison Wang
--- Begin Message ---
On Thu, Sep 17, 2015 at 05:03:34PM +0800, Alison Wang wrote:
> Add Freescale LS1021A initial defconfig file.
> The LS1021A SoC is a dual-core Cortex-A7 based processor.
> 
> LS1021A has some special configurations against imx_v6_v7_defconfig and
> multi_v7_defconfig, such as CONFIG_ARM_LPAE, CONFIG_ARM_PSCI...
> LPAE needs to be supported to access memory beyond the 4GB limit for
> LS1021A. PSCI needs to be supported for LS1021A too. But CONFIG_ARM_LPAE
> and CONFIG_ARM_PSCI are disabled in imx_v6_v7_defconfig and
> multi_v7_defconfig, so a separate LS1021A defconfig is needed.

Sounds like a need for multi_v7_lpae_defconfig rather than creating
a new load of platform specific defconfigs.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--- End Message ---

During high load wait_event_timeout might return a wrong value

[Kalle Kankare]

Hi,

The problem is that the call to might_sleep might sleep and the return value of 
wait_event_timeout does not account for the time slept in there.

The might_sleep includes a call to __schedule if CONFIG_PREEMPT_VOLUNTARY is 
defined.

A problematic scenario can be like the following:

- A driver calls wait_event_timeout with timeout = 10 jiffies, starts sleeping 
in might_sleep.
- An interrupt handler sets the condition true at 5 jiffies and calls wake_up 
for the waitqueue.
- Due to high load the might_sleep wakes up at 100 jiffies.
- In the next if the __wait_cond_timeout returns 1 without manipulating __ret.
- wait_event_timeout returns 10 where it should have returned 1 to denote that 
a timeout was reached.

Or am I misunderstanding what the return value should be ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 00/32] HiSilicon SAS driver

[Hannes Reinecke]

On 11/09/2015 05:32 PM, John Garry wrote:
> This is the driver patchset for the HiSilicon SAS driver. The driver
> is a platform driver.
> 
> The driver will support multiple revisions of HW. Currently only "v1"
> HW is supported.
> 
> The driver uses libsas framework within the SCSI framework.
> 
> The v1 HW supports SSP and SMP, but not STP/SATA.
> 
> Differences to v2:
> - update device tree bindings
> - remove while loops when evaluating hba struct
> - remove _lo and _hi DMA struct fields
> - revised spinlock usage
> - fix error handling for when CMPLT_HDR_ERR_RCRD_XFRD set
> - general coding style and cosmetic fixes
> 
> Differences to v1:
> - re-arch driver into main module and hw-specific driver module
> - allocate hisi_hba in scsi_host_alloc
> - use of_irq_count get irq count - depends on [1]
> - use syscon to handle ctrl reg access
> - get SAS address from device tree
> - do not set cmd_per_lun to 1
> - remove remove controller id
> - use static wq in phy struct
> - process control phy in caller context
> - fix port->port_attached issue for rmmod
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg452833.html
> 
Nice work.

Reviewed-by: Hannes Reinecke 

Although it should be dead trivial to convert the driver to
use scsi-mq; but that can come in with a later patch.

Cheers,

Hannes
-- 
Dr. Hannes ReineckezSeries & Storage
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] gpio: 74xx: fix a possible NULL dereference

[LABBE Corentin]

On Mon, Nov 09, 2015 at 04:16:16PM +0200, Andy Shevchenko wrote:
> On Mon, Nov 9, 2015 at 2:21 AM, Alexandre Courbot  wrote:
> > On Fri, Nov 6, 2015 at 12:55 AM, LABBE Corentin
> >  wrote:
> >> of_match_device could return NULL, and so cause a NULL pointer
> >> dereference later at line 132:
> >> priv->flags = (uintptr_t) of_id->data;
> >>
> >> Reported-by: coverity (CID 1324141)
> >> Signed-off-by: LABBE Corentin 
> >> ---
> >>  drivers/gpio/gpio-74xx-mmio.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpio/gpio-74xx-mmio.c b/drivers/gpio/gpio-74xx-mmio.c
> >> index 6ed7c0f..4a7be0f 100644
> >> --- a/drivers/gpio/gpio-74xx-mmio.c
> >> +++ b/drivers/gpio/gpio-74xx-mmio.c
> >> @@ -120,6 +120,9 @@ static int mmio_74xx_gpio_probe(struct platform_device 
> >> *pdev)
> >> void __iomem *dat;
> >> int err;
> >>
> >> +   if (!of_id)
> >> +   return -ENODEV;
> >> +
> >
> > Nit: in that case, could you also move the assignment of of_id to its
> > own line right above these added lines? It would keep things in the
> > same place
> 
> I think it's more that just a nit. +1 to move assignment.

Hello

I agree, I will send an updated patch soon.

Regards

LABBE Corentin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] x86/mm changes for v4.4

[Ard Biesheuvel]

On 9 November 2015 at 22:08, Kees Cook  wrote:
> On Sat, Nov 7, 2015 at 11:55 PM, Ard Biesheuvel
>  wrote:
>> On 8 November 2015 at 07:58, Kees Cook  wrote:
>>> On Fri, Nov 6, 2015 at 11:39 PM, Ard Biesheuvel
>>>  wrote:
 On 7 November 2015 at 08:09, Ingo Molnar  wrote:
>
> * Matt Fleming  wrote:
>
>> On Fri, 06 Nov, at 07:55:50AM, Ingo Molnar wrote:
>> >
>> >  3) We should fix the EFI permission problem without relying on the 
>> > firmware: it
>> > appears we could just mark everything R-X optimistically, and if a 
>> > write fault
>> > happens (it's pretty rare in fact, only triggers when we write to 
>> > an EFI
>> > variable and so), we can mark the faulting page RW- on the fly, 
>> > because it
>> > appears that writable EFI sections, while not enumerated very well 
>> > in 'old'
>> > firmware, are still supposed to be page granular. (Even 'new' 
>> > firmware I
>> > wouldn't automatically trust to get the enumeration right...)
>>
>> Sorry, this isn't true. I misled you with one of my earlier posts on
>> this topic. Let me try and clear things up...
>>
>> Writing to EFI regions has to do with every invocation of the EFI
>> runtime services - it's not limited to when you read/write/delete EFI
>> variables. In fact, EFI variables really have nothing to do with this
>> discussion, they're a completely opaque concept to the OS, we have no
>> idea how the firmware implements them. Everything is done via the EFI
>> boot/runtime services.
>>
>> The firmware itself will attempt to write to EFI regions when we
>> invoke the EFI services because that's where the PE/COFF ".data" and
>> ".bss" sections live along with the heap. There's even some relocation
>> fixups that occur as SetVirtualAddressMap() time so it'll write to
>> ".text" too.
>>
>> Now, the above PE/COFF sections are usually (always?) contained within
>> EFI regions of type EfiRuntimeServicesCode. We know this is true
>> because the firmware folks have told us so, and because stopping that
>> is the motivation behind the new EFI_PROPERTIES_TABLE feature in UEFI
>> V2.5.
>>
>> The data sections within the region are also *not* guaranteed to be
>> page granular because work was required in Tianocore for emitting
>> sections with 4k alignment as part of the EFI_PROPERTIES_TABLE
>> support.
>>
>> Ultimately, what this means is that if you were to attempt to
>> dynamically fixup those regions that required write permission, you'd
>> have to modify the mappings for the majority of the EFI regions
>> anyway. And if you're blindly allowing write permission as a fixup,
>> there's not much security to be had.
>
> I think you misunderstood my suggestion: the 'fixup' would be changing it 
> from R-X
> to RW-, i.e. it would add 'write' permission but remove 'execute' 
> permission.
>
> Note that there would be no 'RWX' permission at any given moment - which 
> is the
> dangerous combination.
>

 The problem with that is that /any/ page in the UEFI runtime region
 may intersect with both .text and .data of any of the PE/COFF images
 that make up the runtime firmware (since the PE/COFF sections are not
 necessarily page aligned). Such pages require RWX permissions. The
 UEFI memory map does not provide the information to identify those
 pages a priori (the entire region containing several PE/COFF images
 could be covered by a single entry) so it is hard to guess which pages
 should be allowed these RWX permissions.
>>>
>>> I'm sad that UEFI was designed without even the most basic of memory
>>> protections in mind. UEFI _itself_ should be setting up protective
>>> page mappings. :(
>>>
>>
>> Well, the 4 KB alignment of sections was considered prohibitive at the
>> time from code size pov. But this was a long time ago, obviously.
>
> Heh, yeah, I'd expect max 4K padding to get code/data correctly
> aligned on a 2MB binary to not be an issue. :)
>

This is not about section sizes on ARM. The PE/COFF format does not
use segments, like ELF, so the payload (the sections) needs to be
completely disjoint from the header. This means, when using 4 KB
alignment, that every PE/COFF image wastes ~4 KB in the header and 4
KB on average in the section padding (assuming a .text/.data/.reloc
layout, as is common with PE/COFF)

Considering that a typical UEFI firmware image consists of numerous
(around 50 on average, I think) PE/COFF images, and some of them
execute from NOR flash, the Tianocore tooling (which is the reference
implementation) has always been geared towards keeping the alignment
as small as possible, typically 32 bytes unless data objects need
more. Since the UEFI runtime services are typically implemented by
several of these PE/COFF images, and since the memor

Re: [PATCH RESEND 04/16] Documentation: dt-bindings: leds: add LM3633 LED binding information

[Kim, Milo]

Hi Jacek,

On 11/4/2015 1:15 AM, Jacek Anaszewski wrote:

+  - led-max-microamp: Max current setting. Type is .
>+  Unit is microampere. Range is from 5000 to 3.

Could you specify also a step?



Yep, step is 1000. Thanks for catching this.
I'll update the binding in the next patch.

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Attn:New Design/Acupuncture Massage Pen/Aukewel Co., Ltd

[Woody Wu]

Dear Client,

Have a good day!
Glad to learn you're on the market of Acupuncture Pen products

We are the manufacture at family use electronic health devices since 2000.
Have ISO13485:2003 Medical,FDA approved and Europe CE certification.
We keep good quality and reliable cooperation for global valued customers. 

Main products include Acupuncture pen / Massager pen.

If any product meet your demand, please contact us. 
Any of your question will be replied prompt.


Best regards.

Woody Woo

Re: [PATCH v10 1/5] configfs: Allow dynamic group creation

[Christoph Hellwig]

Andrew,

is this simple addition something you could still send on to Linus
for this merge window?  I would make my life easier to have it in
so I could start using it in patches for various trees in the next
merge window.

Thanks,
Christoph

On Fri, Oct 23, 2015 at 06:33:27PM +0300, Daniel Baluta wrote:
> We don't want to hardcode default groups at subsystem
> creation time. We export:
>   * configfs_register_group
>   * configfs_unregister_group
> to allow drivers to programatically create/destroy groups
> later, after module init time.
> 
> This is needed for IIO configfs support.
> 
> Suggested-by: Lars-Peter Clausen 
> Signed-off-by: Daniel Baluta 
> ---
>  fs/configfs/dir.c| 110 
> +++
>  include/linux/configfs.h |  10 +
>  2 files changed, 120 insertions(+)
> 
> diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
> index c81ce7f..a7a1b21 100644
> --- a/fs/configfs/dir.c
> +++ b/fs/configfs/dir.c
> @@ -1636,6 +1636,116 @@ const struct file_operations configfs_dir_operations 
> = {
>   .iterate= configfs_readdir,
>  };
>  
> +/**
> + * configfs_register_group - creates a parent-child relation between two 
> groups
> + * @parent_group:parent group
> + * @group:   child group
> + *
> + * link groups, creates dentry for the child and attaches it to the
> + * parent dentry.
> + *
> + * Return: 0 on success, negative errno code on error
> + */
> +int configfs_register_group(struct config_group *parent_group,
> + struct config_group *group)
> +{
> + struct configfs_subsystem *subsys = parent_group->cg_subsys;
> + struct dentry *parent;
> + int ret;
> +
> + mutex_lock(&subsys->su_mutex);
> + link_group(parent_group, group);
> + mutex_unlock(&subsys->su_mutex);
> +
> + parent = parent_group->cg_item.ci_dentry;
> +
> + mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
> + ret = create_default_group(parent_group, group);
> + if (!ret) {
> + spin_lock(&configfs_dirent_lock);
> + configfs_dir_set_ready(group->cg_item.ci_dentry->d_fsdata);
> + spin_unlock(&configfs_dirent_lock);
> + }
> + mutex_unlock(&d_inode(parent)->i_mutex);
> + return ret;
> +}
> +EXPORT_SYMBOL(configfs_register_group);
> +
> +/**
> + * configfs_unregister_group() - unregisters a child group from its parent
> + * @group: parent group to be unregistered
> + *
> + * Undoes configfs_register_group()
> + */
> +void configfs_unregister_group(struct config_group *group)
> +{
> + struct configfs_subsystem *subsys = group->cg_subsys;
> + struct dentry *dentry = group->cg_item.ci_dentry;
> + struct dentry *parent = group->cg_item.ci_parent->ci_dentry;
> +
> + mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
> + spin_lock(&configfs_dirent_lock);
> + configfs_detach_prep(dentry, NULL);
> + spin_unlock(&configfs_dirent_lock);
> +
> + configfs_detach_group(&group->cg_item);
> + d_inode(dentry)->i_flags |= S_DEAD;
> + dont_mount(dentry);
> + d_delete(dentry);
> + mutex_unlock(&d_inode(parent)->i_mutex);
> +
> + dput(dentry);
> +
> + mutex_lock(&subsys->su_mutex);
> + unlink_group(group);
> + mutex_unlock(&subsys->su_mutex);
> +}
> +EXPORT_SYMBOL(configfs_unregister_group);
> +
> +/**
> + * configfs_register_default_group() - allocates and registers a child group
> + * @parent_group:parent group
> + * @name:child group name
> + * @item_type:   child item type description
> + *
> + * boilerplate to allocate and register a child group with its parent. We 
> need
> + * kzalloc'ed memory because child's default_group is initially empty.
> + *
> + * Return: allocated config group or ERR_PTR() on error
> + */
> +struct config_group *
> +configfs_register_default_group(struct config_group *parent_group,
> + const char *name,
> + struct config_item_type *item_type)
> +{
> + int ret;
> + struct config_group *group;
> +
> + group = kzalloc(sizeof(*group), GFP_KERNEL);
> + if (!group)
> + return ERR_PTR(-ENOMEM);
> + config_group_init_type_name(group, name, item_type);
> +
> + ret = configfs_register_group(parent_group, group);
> + if (ret) {
> + kfree(group);
> + return ERR_PTR(ret);
> + }
> + return group;
> +}
> +EXPORT_SYMBOL(configfs_register_default_group);
> +
> +/**
> + * configfs_unregister_default_group() - unregisters and frees a child group
> + * @group:   the group to act on
> + */
> +void configfs_unregister_default_group(struct config_group *group)
> +{
> + configfs_unregister_group(group);
> + kfree(group);
> +}
> +EXPORT_SYMBOL(configfs_unregister_default_group);
> +
>  int configfs_register_subsystem(struct configfs_subsystem *subsys)
>  {
>   int err;
> diff --git a/include/linux/configfs.h b/i

Re: [PATCH 04/19] v4l: omap3isp: fix handling platform_get_irq result

[Andrzej Hajda]

On 11/09/2015 09:16 PM, Laurent Pinchart wrote:
> Hi Andrzej,
>
> Thank you for the patch.
>
> On Thursday 24 September 2015 16:00:12 Andrzej Hajda wrote:
>> The function can return negative value.
>>
>> The problem has been detected using proposed semantic patch
>> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> Hi,
>>
>> To avoid problems with too many mail recipients I have sent whole
>> patchset only to LKML. Anyway patches have no dependencies.
>>
>> Regards
>> Andrzej
>> ---
>>  drivers/media/platform/omap3isp/isp.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/omap3isp/isp.c
>> b/drivers/media/platform/omap3isp/isp.c index 56e683b..df9d2c2 100644
>> --- a/drivers/media/platform/omap3isp/isp.c
>> +++ b/drivers/media/platform/omap3isp/isp.c
>> @@ -2442,12 +2442,13 @@ static int isp_probe(struct platform_device *pdev)
>>  }
>>
>>  /* Interrupt */
>> -isp->irq_num = platform_get_irq(pdev, 0);
>> -if (isp->irq_num <= 0) {
>> +ret = platform_get_irq(pdev, 0);
>> +if (ret <= 0) {
> Looking at platform_get_irq() all error values are negative. You could just 
> test for ret < 0 here, and remove the ret = -ENODEV assignment below to keep 
> the error code returned by platform_get_irq().
>
> If you're fine with that modification there's no need to resubmit, just let 
> me 
> know and I'll fix it when applying it to my tree.

I left it as before, as it was not related to the patch. Additionally I have
lurked little bit inside platform_get_irq and it looks little bit scary to me:
platform_get_irq returns value of of_irq_get if ret >= 0,
of_irq_get calls of_irq_parse_one which can return 0,
in such case irq_create_of_mapping value is returned which is unsigned int
and evaluates to 0 in case of failures.
I am not sure if above scenario can ever occur, but the code looks so messy to 
me,
that I gave up :)

Anyway if you are sure about your change I am OK with it also :)

Regards
Andrzej

>
>>  dev_err(isp->dev, "No IRQ resource\n");
>>  ret = -ENODEV;
>>  goto error_iommu;
>>  }
>> +isp->irq_num = ret;
>>
>>  if (devm_request_irq(isp->dev, isp->irq_num, isp_isr, IRQF_SHARED,
>>   "OMAP3 ISP", isp)) {

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] avr32: select ARCH_WANT_FRAME_POINTERS and set DEBUG_KERNEL in defconfigs

[Hans-Christian Noren Egtvedt]

Around Mon 09 Nov 2015 11:21:17 -0800 or thereabout, Yang Shi wrote:
> FRAME_POINTER is set by default if ARCH_WANT_FRAME_POINTERS and DEBUG_KERNEL
> are  selcted, this is the standard way to include FRAME_POINTER used by all
> of other architectures.
> 
> And, set DEBUG_KERNEL=y in defconfigs otherwise FRAME_POINTER won't be enabled
> at all.
> 
> Signed-off-by: Yang Shi 
> ---
>  arch/avr32/Kconfig  | 1 +
>  arch/avr32/configs/atngw100_defconfig   | 1 +
>  arch/avr32/configs/atngw100_evklcd100_defconfig | 1 +
>  arch/avr32/configs/atngw100_evklcd101_defconfig | 1 +
>  arch/avr32/configs/atngw100_mrmt_defconfig  | 1 +
>  arch/avr32/configs/atngw100mkii_defconfig   | 1 +
>  arch/avr32/configs/atngw100mkii_evklcd100_defconfig | 1 +
>  arch/avr32/configs/atngw100mkii_evklcd101_defconfig | 1 +
>  arch/avr32/configs/atstk1002_defconfig  | 1 +
>  arch/avr32/configs/atstk1003_defconfig  | 1 +
>  arch/avr32/configs/atstk1004_defconfig  | 1 +
>  arch/avr32/configs/atstk1006_defconfig  | 1 +
>  arch/avr32/configs/favr-32_defconfig| 1 +
>  arch/avr32/configs/hammerhead_defconfig | 1 +
>  arch/avr32/configs/mimc200_defconfig| 1 +
>  15 files changed, 15 insertions(+)



Acked-by: Hans-Christian Egtvedt 

-- 
Best regards, Hans-Christian Noren Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/urgent] perf: Fix inherited events vs. tracepoint filters

[tip-bot for Peter Zijlstra]

Commit-ID:  b71b437eedaed985062492565d9d421d975ae845
Gitweb: http://git.kernel.org/tip/b71b437eedaed985062492565d9d421d975ae845
Author: Peter Zijlstra 
AuthorDate: Mon, 2 Nov 2015 10:50:51 +0100
Committer:  Ingo Molnar 
CommitDate: Mon, 9 Nov 2015 16:13:11 +0100

perf: Fix inherited events vs. tracepoint filters

Arnaldo reported that tracepoint filters seem to misbehave (ie. not
apply) on inherited events.

The fix is obvious; filters are only set on the actual (parent)
event, use the normal pattern of using this parent event for filters.
This is safe because each child event has a reference to it.

Reported-by: Arnaldo Carvalho de Melo 
Tested-by: Arnaldo Carvalho de Melo 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Adrian Hunter 
Cc: Arnaldo Carvalho de Melo 
Cc: David Ahern 
Cc: Frédéric Weisbecker 
Cc: Jiri Olsa 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Wang Nan 
Cc: sta...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/20151102095051.gn17...@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
---
 kernel/events/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index f8e5c44..98a4b9d 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6909,6 +6909,10 @@ static int perf_tp_filter_match(struct perf_event *event,
 {
void *record = data->raw->data;
 
+   /* only top level events have filters set */
+   if (event->parent)
+   event = event->parent;
+
if (likely(!event->filter) || filter_match_preds(event->filter, record))
return 1;
return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:perf/urgent] perf: Disable IRQs across RCU RS CS that acquires scheduler lock

[tip-bot for Paul E. McKenney]

Commit-ID:  2fd59077755c44dbbd9b2fa89cf988235a3a6a2b
Gitweb: http://git.kernel.org/tip/2fd59077755c44dbbd9b2fa89cf988235a3a6a2b
Author: Paul E. McKenney 
AuthorDate: Wed, 4 Nov 2015 05:48:38 -0800
Committer:  Ingo Molnar 
CommitDate: Mon, 9 Nov 2015 16:13:11 +0100

perf: Disable IRQs across RCU RS CS that acquires scheduler lock

The perf_lock_task_context() function disables preemption across its
RCU read-side critical section because that critical section acquires
a scheduler lock.  If there was a preemption during that RCU read-side
critical section, the rcu_read_unlock() could attempt to acquire scheduler
locks, resulting in deadlock.

However, recent optimizations to expedited grace periods mean that IPI
handlers that execute during preemptible RCU read-side critical sections
can now cause the subsequent rcu_read_unlock() to acquire scheduler locks.
Disabling preemption does nothiing to prevent these IPI handlers from
executing, so these optimizations introduced a deadlock.  In theory,
this deadlock could be avoided by pulling all wakeups and printk()s out
from rnp->lock critical sections, but in practice this would re-introduce
some RCU CPU stall warning bugs.

Given that acquiring scheduler locks entails disabling interrupts, these
deadlocks can be avoided by disabling interrupts (instead of disabling
preemption) across any RCU read-side critical that acquires scheduler
locks and holds them across the rcu_read_unlock().  This commit therefore
makes this change for perf_lock_task_context().

Reported-by: Dave Jones 
Reported-by: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Arnaldo Carvalho de Melo 
Cc: Jiri Olsa 
Cc: Linus Torvalds 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20151104134838.gr29...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar 
---
 kernel/events/core.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index ea02109..f8e5c44 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1050,13 +1050,13 @@ retry:
/*
 * One of the few rules of preemptible RCU is that one cannot do
 * rcu_read_unlock() while holding a scheduler (or nested) lock when
-* part of the read side critical section was preemptible -- see
+* part of the read side critical section was irqs-enabled -- see
 * rcu_read_unlock_special().
 *
 * Since ctx->lock nests under rq->lock we must ensure the entire read
-* side critical section is non-preemptible.
+* side critical section has interrupts disabled.
 */
-   preempt_disable();
+   local_irq_save(*flags);
rcu_read_lock();
ctx = rcu_dereference(task->perf_event_ctxp[ctxn]);
if (ctx) {
@@ -1070,21 +1070,22 @@ retry:
 * if so.  If we locked the right context, then it
 * can't get swapped on us any more.
 */
-   raw_spin_lock_irqsave(&ctx->lock, *flags);
+   raw_spin_lock(&ctx->lock);
if (ctx != rcu_dereference(task->perf_event_ctxp[ctxn])) {
-   raw_spin_unlock_irqrestore(&ctx->lock, *flags);
+   raw_spin_unlock(&ctx->lock);
rcu_read_unlock();
-   preempt_enable();
+   local_irq_restore(*flags);
goto retry;
}
 
if (!atomic_inc_not_zero(&ctx->refcount)) {
-   raw_spin_unlock_irqrestore(&ctx->lock, *flags);
+   raw_spin_unlock(&ctx->lock);
ctx = NULL;
}
}
rcu_read_unlock();
-   preempt_enable();
+   if (!ctx)
+   local_irq_restore(*flags);
return ctx;
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:sched/urgent] sched/numa: Fix math underflow in task_tick_numa()

[tip-bot for Rik van Riel]

Commit-ID:  25b3e5a3344e1f700c1efec5b6f0199f04707fb1
Gitweb: http://git.kernel.org/tip/25b3e5a3344e1f700c1efec5b6f0199f04707fb1
Author: Rik van Riel 
AuthorDate: Thu, 5 Nov 2015 15:56:22 -0500
Committer:  Ingo Molnar 
CommitDate: Mon, 9 Nov 2015 16:13:27 +0100

sched/numa: Fix math underflow in task_tick_numa()

The NUMA balancing code implements delays in scanning by
advancing curr->node_stamp beyond curr->se.sum_exec_runtime.

With unsigned math, that creates an underflow, which results
in task_numa_work being queued all the time, even when we
don't want to.

Avoiding the math underflow makes it possible to reduce CPU
overhead in the NUMA balancing code.

Reported-and-tested-by: Jan Stancek 
Signed-off-by: Rik van Riel 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: mgor...@suse.de
Link: http://lkml.kernel.org/r/1446756983-28173-2-git-send-email-r...@redhat.com
Signed-off-by: Ingo Molnar 
---
 kernel/sched/fair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 824aa9f..f04fda8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2302,7 +2302,7 @@ void task_tick_numa(struct rq *rq, struct task_struct 
*curr)
now = curr->se.sum_exec_runtime;
period = (u64)curr->numa_scan_period * NSEC_PER_MSEC;
 
-   if (now - curr->node_stamp > period) {
+   if (now > curr->node_stamp + period) {
if (!curr->node_stamp)
curr->numa_scan_period = task_scan_min(curr);
curr->node_stamp += period;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] video: constify geode ops structures

[Christoph Hellwig]

On Mon, Nov 09, 2015 at 01:20:12PM -0800, Kees Cook wrote:
> Just to remind everyone: while we certainly want to clean these up in
> the code where possible, we still want to make the constification
> plugin part of the regular builds. We want to provide a
> secure-by-default build, even when vendors are adding their own
> out-of-tree code when producing Linux-based products. So, we'll always
> want to have the plugin as a back-stop for out-of-tree code, or places
> where const was accidentally missed upstream.

Who is 'we'?  While a plugin like this that warns would be very ueful
I strongly disagree with bloating the kernel tree with any infrastructure
primarily aimed at out of tree code.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

PING: [PATCH] net: smsc911x: Reset PHY during initialization

[Pavel Fedin]

 Hello! So, what should we do with this?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On 
> Behalf Of Pavel
> Fedin
> Sent: Monday, November 02, 2015 10:19 AM
> To: 'David Miller'
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> steve.glendinn...@shawell.net
> Subject: RE: [PATCH] net: smsc911x: Reset PHY during initialization
> 
>  Hello!
> 
> > > On certain hardware after software reboot the chip may get stuck and fail
> > > to reinitialize during reset. This can be fixed by ensuring that PHY is
> > > reset too.
> > >
> > > Old PHY resetting method required operational MDIO interface, therefore
> > > the chip should have been already set up. In order to be able to function
> > > during probe, it is changed to use PMT_CTRL register.
> > >
> > > The problem could be observed on SMDK5410 board.
> > >
> > > Signed-off-by: Pavel Fedin 
> >
> > I'm pretty sure this is going to break the PHY loopback test.
> 
>  It's not (at least in normal situation), because first we do the test, and 
> only then, if it
> fails, we reset the PHY. So, during
> normal operation of the driver, when loopback test succeeds at first attempt, 
> we never attempt
> to reset the PHY. And, by the way, at
> least on my board this PHY reset did nothing useful, because after it 
> loopback test still
> failed, all 100 times.
>  And, we don't use PHY reset anywhere outside of loopback test.
> 
> > This is such a tricky and fragile area to get right, therefore I
> > want you to specifically guard any change in how PHY reset is
> > done with tests against the specific chips that have the problem.
> 
>  Well, i could do one (or some combination) of the following, if you really 
> want to:
>  a) Leave PHY reset inside loopback test as it is, but add a second routine 
> and call it only
> before smsc911x_soft_reset().
>  b) Reset PHY only conditionally, using the following algorithm:
> if smsc911x_soft_reset() {
> /* NIC reset failed, kick the PHY and retry */
> smsc911x_phy_reset()
> if (smsc_911x_soft_reset())
> return -ENODEV;
> }
>  c) Do extra PHY reset only if some hint in device tree is specified (or the 
> machine is known
> to have the problem)
> 
>  But, i dislike approach (a) for code duplication, because datasheet says 
> that both reset
> methods are equivalent; i dislike approach
> (b) for actually being a hack; and i dislike (c) for adding extra stuff which 
> seems to be not
> necessary. After all, what is wrong
> with just extra PHY reset before attempting to program anything? By the way, 
> i test my patch
> with both software reboot and hardware
> reboot, and even powercycle. Everything is quite stable.
>  Well, it's up to you to decide. But i'd like to get the fix upstreamed 
> somehow because from
> time to time we use these boards for
> tests, and it's quite annoiying to be unable to reboot them properly.
> 
> > Furthermore, I want you to test whether this has any negative
> > effects on the PHY loopback test.
> 
>  I did. I never disabled loopback test, so i actually discovered a problem 
> (even two) with it.
> First, the problem was chip reset
> timeout. By increasing it to 300ms this problem seemed to be fixed, but 
> loopback test started
> to fail. This was how i found and
> fixed crash with missing phy_disconnect(). I examined the code and discovered 
> that upon
> loopback test failure we reset the PHY and
> retry. But in my case this PHY reset never did the right thing, and all 
> loopback attempts
> (10x10 IIRC) were failing.
>  Some comments in the code gave me a clue that the main NIC can misbehave on 
> reset if e.g. PHY
> is in powerdown state. I printed
> value of its control register and discovered that it was not the case. But 
> then i discovered
> that we actually never try to reset the
> PHY before doing anything. Also, while studying the datasheed i discovered 
> that there is a
> shorthand for resetting PHY without MDIO
> bus set up, but our driver doesn't use it, preferring MDIO method instead, 
> which already
> requires operational NIC.
>  So, i suggested that PHY is just not being reset when board is rebooted by 
> software. I wrote
> the patch and it worked. I verified it
> by reverting my previous NIC reset timeout increase, and it continued to 
> work. After this
> loopback test on my board passes at first
> attempt.
> 
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo

Re: [PATCH V6 0/6] Fast mmio eventfd fixes

[Jason Wang]

On 11/10/2015 04:19 AM, Michael S. Tsirkin wrote:
> On Mon, Nov 09, 2015 at 12:35:45PM +0800, Jason Wang wrote:
>> > 
>> > 
>> > On 11/09/2015 01:11 AM, Michael S. Tsirkin wrote:
>>> > > On Tue, Sep 15, 2015 at 02:41:53PM +0800, Jason Wang wrote:
 > >> Hi:
 > >>
 > >> This series fixes two issues of fast mmio eventfd:
 > >>
 > >> 1) A single iodev instance were registerd on two buses: KVM_MMIO_BUS
 > >>and KVM_FAST_MMIO_BUS. This will cause double in
 > >>ioeventfd_destructor()
 > >> 2) A zero length iodev on KVM_MMIO_BUS will never be found but
 > >>kvm_io_bus_cmp(). This will lead e.g the eventfd will be trapped by
 > >>qemu instead of host.
 > >>
 > >> 1 is fixed by allocating two instances of iodev and introduce a new
 > >> capability for userspace. 2 is fixed by ignore the actual length if
 > >> the length of iodev is zero in kvm_io_bus_cmp().
 > >>
 > >> Please review.
 > >> Changes from V5:
 > >> - move patch of explicitly checking for KVM_MMIO_BUS to patch 1 and
 > >>   remove the unnecessary checks
 > >> - even more grammar and typo fixes
 > >> - rabase to kvm.git
 > >> - document KVM_CAP_FAST_MMIO
>>> > > What's up with userspace using this capability?
>> > 
>> > It was renamed to KVM_CAP_IOEVENTFD_ANY_LENGTH.
>> > 
>>> > > Did patches ever get posted?
>> > 
>> > See https://lkml.org/lkml/2015/9/28/208
> Talking about userspace here.
> QEMU freeze is approaching, it really should
> use this to avoid regressions.
>

The patches were posted at
http://lists.gnu.org/archive/html/qemu-devel/2015-11/msg01276.html

(you were in cc list)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: Make bulk API support optional supplies

[Bjorn Andersson]

Make it possible to use the bulk API with optional supplies, by allowing
the consumer to marking supplies as optional in the regulator_bulk_data.

Signed-off-by: Bjorn Andersson 
---
 drivers/regulator/core.c   | 6 --
 drivers/regulator/devres.c | 7 +--
 include/linux/regulator/consumer.h | 3 +++
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 73b7683355cd..4cf1390784e5 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3451,8 +3451,10 @@ int regulator_bulk_get(struct device *dev, int 
num_consumers,
consumers[i].consumer = NULL;
 
for (i = 0; i < num_consumers; i++) {
-   consumers[i].consumer = regulator_get(dev,
- consumers[i].supply);
+   consumers[i].consumer = _regulator_get(dev,
+  consumers[i].supply,
+  false,
+  !consumers[i].optional);
if (IS_ERR(consumers[i].consumer)) {
ret = PTR_ERR(consumers[i].consumer);
dev_err(dev, "Failed to get supply '%s': %d\n",
diff --git a/drivers/regulator/devres.c b/drivers/regulator/devres.c
index 6ec1d400adae..6ad8ab4c578d 100644
--- a/drivers/regulator/devres.c
+++ b/drivers/regulator/devres.c
@@ -164,8 +164,11 @@ int devm_regulator_bulk_get(struct device *dev, int 
num_consumers,
consumers[i].consumer = NULL;
 
for (i = 0; i < num_consumers; i++) {
-   consumers[i].consumer = devm_regulator_get(dev,
-  consumers[i].supply);
+   consumers[i].consumer = _devm_regulator_get(dev,
+   consumers[i].supply,
+   
consumers[i].optional ?
+   OPTIONAL_GET :
+   NORMAL_GET);
if (IS_ERR(consumers[i].consumer)) {
ret = PTR_ERR(consumers[i].consumer);
dev_err(dev, "Failed to get supply '%s': %d\n",
diff --git a/include/linux/regulator/consumer.h 
b/include/linux/regulator/consumer.h
index 9e0e76992be0..48603506f8de 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -140,6 +140,8 @@ struct regulator;
  *
  * @supply:   The name of the supply.  Initialised by the user before
  *using the bulk regulator APIs.
+ * @optional: The supply should be considered optional. Initialised by the user
+ *before using the bulk regulator APIs.
  * @consumer: The regulator consumer for the supply.  This will be managed
  *by the bulk API.
  *
@@ -149,6 +151,7 @@ struct regulator;
  */
 struct regulator_bulk_data {
const char *supply;
+   bool optional;
struct regulator *consumer;
 
/* private: Internal use */
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 0/6] virtio core DMA API conversion

[Benjamin Herrenschmidt]

On Mon, 2015-11-09 at 18:18 -0800, Andy Lutomirski wrote:
> 
> Which leaves the special case of Xen, where even preexisting devices
> don't bypass the IOMMU.  Can we keep this specific to powerpc and
> sparc?  On x86, this problem is basically nonexistent, since the IOMMU
> is properly self-describing.
> 
> IOW, I think that on x86 we should assume that all virtio devices
> honor the IOMMU.

You don't like performances ? :-)

Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tpm: fix compat 'ppi' link handling in tpm_chip_register()

[Jarkko Sakkinen]

On Mon, Nov 09, 2015 at 10:11:41PM -0800, Jeremiah Mahler wrote:
> Jarkko,
> 
> On Sun, Nov 08, 2015 at 09:51:07AM +0200, Jarkko Sakkinen wrote:
> > __compat_only_sysfs_link_entry_to_kobj() was unconditionally called for
> > TPM1 chips, which caused crash on Acer C720 laptop where DSM for the
> > ACPI object did not exist.
> > 
> > There are two reasons for unwanted behavior:
> > 
> > * The code did not check whether
> >   __compat_only_sysfs_link_entry_to_kobj() returned -ENOENT. This is
> >   OK. It just meanst that ppi is not available.
> > * The code did not clean up properly. Compat link should added only
> >   after all other init is done.
> > 
> > This patch sorts out these issues.
> > 
> > Fixes: 9b774d5cf2db
> > Reported-by: Jeremiah Mahler 
> > Signed-off-by: Jarkko Sakkinen 
> > Tested-by: Jeremiah Mahler 
> > ---
> >  drivers/char/tpm/tpm-chip.c | 18 ++
> >  1 file changed, 10 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> > index a5cdce7..45cc39a 100644
> > --- a/drivers/char/tpm/tpm-chip.c
> > +++ b/drivers/char/tpm/tpm-chip.c
> > @@ -226,14 +226,6 @@ int tpm_chip_register(struct tpm_chip *chip)
> > if (rc)
> > goto out_err;
> >  
> > -   if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> > -   rc = __compat_only_sysfs_link_entry_to_kobj(&chip->pdev->kobj,
> > -   &chip->dev.kobj,
> > -   "ppi");
> > -   if (rc)
> > -   goto out_err;
> > -   }
> > -
> > /* Make the chip available. */
> > spin_lock(&driver_lock);
> > list_add_tail_rcu(&chip->list, &tpm_chip_list);
> > @@ -241,6 +233,16 @@ int tpm_chip_register(struct tpm_chip *chip)
> >  
> > chip->flags |= TPM_CHIP_FLAG_REGISTERED;
> >  
> > +   if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> > +   rc = __compat_only_sysfs_link_entry_to_kobj(&chip->pdev->kobj,
> > +   &chip->dev.kobj,
> > +   "ppi");
> > +   if (rc && rc != -ENOENT) {
> > +   tpm_chip_unregister(chip);
> > +   return rc;
> > +   }
> > +   }
> > +
> > return 0;
> >  out_err:
> > tpm1_chip_unregister(chip);
> > -- 
> > 2.5.0
> > 
> 
> This patch doesn't apply to the latest linux-next (20151109).  I think I
> may be missing a dependent patch.  Do you know which one?

It is expected as there are 7 other bug fixes that I'm including to the
next pull rquest and this is on top.

> - Jeremiah Mahler

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135

[Eddie Huang]

On Mon, 2015-11-09 at 09:59 -0800, Kevin Hilman wrote:
> On Mon, Oct 26, 2015 at 4:40 AM, Eddie Huang  wrote:
> > Hi Kevin,
> >
> > On Mon, 2015-10-26 at 17:06 +0900, Kevin Hilman wrote:
> >> On Mon, Oct 26, 2015 at 4:15 PM, Yingjoe Chen  
> >> wrote:
> >> > On Mon, 2015-10-26 at 09:56 +0900, Kevin Hilman wrote:
> >> >> Hello,
> >> >>
> >> >> On Sat, Oct 3, 2015 at 12:19 AM, Yingjoe Chen 
> >> >>  wrote:
> >> >> > Add arch timer node to enable arch-timer support. MT8135 firmware
> >> >> > doesn't correctly setup arch-timer frequency and CNTVOFF, add
> >> >> > properties to workaround this.
> >> >> >
> >> >> > This also set cpu enable-method to enable SMP.
> >> >> >
> >> >> > Signed-off-by: Yingjoe Chen 
> >> >>
> >> >> kernelci.org started detecting new boot failures for the mt8135-evb in
> >> >> the arm-soc tree[1], and the boot failures were bisected down to this
> >> >> patch, which landed upstream in the form of commit d186a394bb98 (ARM:
> >> >> dts: mt8135: enable basic SMP bringup for mt8135)
> >> >>
> >> >> Maybe this new SMP support requires updating the firmware on the board
> >> >> as well?  If so, the changelog should've been a bit more explicit
> >> >> about firmware dependencies.
> >> >
> >> > Kevin,
> >> >
> >> > Thanks for testing.
> >> >
> >> > No, it doesn't need new firmware. Will test to see what's going wrong.
> >>
> >> Thanks for following up.  I'll be glad to test any patches if you have
> >> anything you'd like me to test.
> >
> > You need "clockevents/drivers/mtk: Fix spurious interrupt leading to
> > crash" (https://lkml.org/lkml/2015/8/24/803)
> >
> > Daniel Lezcano already applied this patch in his tree for 4.4.
> > (https://git.linaro.org/people/daniel.lezcano/linux.git)
> 
> The mt8135-evp board is still failing to boot in linux-next[1] (and
> has been since next-20151022.)  It appears the dependencies are not
> quite correct in linux-next either.
> 
> Kevin
> 
> [1]
> http://kernelci.org/boot/mt8135-evbp1/job/next/kernel/next-20151109/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=564037fe59b514b2f6091909

Hi Kevin,

I check the log [0], it seems first time mt8135-evbp1 boot to kernel
shell successfully, then boot again. In the second time, mt8135 stay in
fastboot mode, waiting host send boot image, then timeout.

I download zImage and dtb in [1], and kernel run to shell successfully
on my platform.

I don't know whether this issue caused by test environment or not.

[0]
http://storage.kernelci.org/next/next-20151109/arm-multi_v7_defconfig/lab-khilman/boot-mt8135-evbp1.txt
[1]
http://kernelci.org/boot/mt8135-evbp1/job/next/kernel/next-20151109/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=564037fe59b514b2f6091909#bisect-content



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tpm: fix compat 'ppi' link handling in tpm_chip_register()

[Jeremiah Mahler]

Jarkko,

On Sun, Nov 08, 2015 at 09:51:07AM +0200, Jarkko Sakkinen wrote:
> __compat_only_sysfs_link_entry_to_kobj() was unconditionally called for
> TPM1 chips, which caused crash on Acer C720 laptop where DSM for the
> ACPI object did not exist.
> 
> There are two reasons for unwanted behavior:
> 
> * The code did not check whether
>   __compat_only_sysfs_link_entry_to_kobj() returned -ENOENT. This is
>   OK. It just meanst that ppi is not available.
> * The code did not clean up properly. Compat link should added only
>   after all other init is done.
> 
> This patch sorts out these issues.
> 
> Fixes: 9b774d5cf2db
> Reported-by: Jeremiah Mahler 
> Signed-off-by: Jarkko Sakkinen 
> Tested-by: Jeremiah Mahler 
> ---
>  drivers/char/tpm/tpm-chip.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index a5cdce7..45cc39a 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -226,14 +226,6 @@ int tpm_chip_register(struct tpm_chip *chip)
>   if (rc)
>   goto out_err;
>  
> - if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> - rc = __compat_only_sysfs_link_entry_to_kobj(&chip->pdev->kobj,
> - &chip->dev.kobj,
> - "ppi");
> - if (rc)
> - goto out_err;
> - }
> -
>   /* Make the chip available. */
>   spin_lock(&driver_lock);
>   list_add_tail_rcu(&chip->list, &tpm_chip_list);
> @@ -241,6 +233,16 @@ int tpm_chip_register(struct tpm_chip *chip)
>  
>   chip->flags |= TPM_CHIP_FLAG_REGISTERED;
>  
> + if (!(chip->flags & TPM_CHIP_FLAG_TPM2)) {
> + rc = __compat_only_sysfs_link_entry_to_kobj(&chip->pdev->kobj,
> + &chip->dev.kobj,
> + "ppi");
> + if (rc && rc != -ENOENT) {
> +     tpm_chip_unregister(chip);
> + return rc;
> + }
> + }
> +
>   return 0;
>  out_err:
>   tpm1_chip_unregister(chip);
> -- 
> 2.5.0
> 

This patch doesn't apply to the latest linux-next (20151109).  I think I
may be missing a dependent patch.  Do you know which one?

-- 
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 3/3] scsi: mptxsas: offload IRQ execution

[Sinan Kaya]

On 11/9/2015 2:15 AM, Hannes Reinecke wrote:

On 11/09/2015 02:57 AM, Sinan Kaya wrote:

The mpt2sas and mpt3sas drivers are spinning forever in
their IRQ handlers if there are a lot of jobs queued up
by the PCIe card. This handler is causing spikes for
the rest of the system and sluggish behavior.

Marking all MSI interrupts as non-shared and moving the
MSI interrupts to thread context. This relexes the rest
of the system execution.


NACK.

If there is a scalability issue when handling interrupts
it should be fixed in the driver directly.

Looking at the driver is should be possible to implement
a worker thread handling the reply descriptor, and having the
interrupt only to fetch the reply descriptor.



Can you go into the detail about which part of the _base_interrupt 
function needs to be executed in ISR context and which part can be 
queued up to worker thread?


I'm not familiar with the hardware or the code. That's why, I moved the 
entire ISR into the thread context.





Cheers,

Hannes



--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch v7 4/7] PCI/ACPI: Add interface acpi_pci_root_create()

[Jiang Liu]

On 2015/11/10 4:09, Arnd Bergmann wrote:
> On Monday 09 November 2015 17:10:43 Lorenzo Pieralisi wrote:
>> On Mon, Nov 09, 2015 at 03:07:38PM +0100, Tomasz Nowicki wrote:
>>> On 06.11.2015 14:22, Jiang Liu wrote:
 On 2015/11/6 20:40, Tomasz Nowicki wrote:
> On 06.11.2015 12:46, Jiang Liu wrote:
>> On 2015/11/6 18:37, Tomasz Nowicki wrote:
>>> On 06.11.2015 09:52, Jiang Liu wrote:
>>> Sure, ARM64 (0-16M IO space) QEMU example:
>>> DWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
>>>   0x, // Granularity
>>>   0x, // Range Minimum
>>>   0x, // Range Maximum
>>>   0x3EFF, // Translation Offset
>>>   0x0001, // Length
>>>   ,, , TypeStatic)
>> The above DWordIO resource descriptor doesn't confirm to the ACPI spec.
>> According to my understanding, ARM/ARM64 has no concept of IO port
>> address space, so the PCI host bridge will map IO port on PCI side
>> onto MMIO on host side. In other words, PCI host bridge on ARM64
>> implement a IO Port->MMIO translation instead of a IO Port->IO Port
>> translation. If that's true, it should use 'TypeTranslation' instead
>> of 'TypeStatic'. And kernel ACPI resource parsing interface doesn't
>> support 'TypeTranslation' yet, so we need to find a solution for it.
>
> I think you are right, we need TypeTranslation flag for ARM64 DWordIO
> descriptors and an extra kernel patch to support it.
 How about the attached to patch to support TypeTranslation?
 It only passes compilation:)
>>>
>>> Based on the further discussion, your draft patch looks good to me.
>>> Lorenzo, do you agree?
>>
>> No, because I still do not understand the difference between ia64 and
>> arm64 (they both drive IO ports cycles through MMIO so the resource
>> descriptors content must be the same or better they must mean the same
>> thing). On top of that, this is something that was heavily debated for DT:
>>
>> http://www.spinics.net/lists/arm-kernel/msg345633.html
>>
>> and I would like to get Arnd and Bjorn opinion on this because we
>> should not "interpret" ACPI specifications, we should understand
>> what they are supposed to describe and write kernel code accordingly.
>>
>> In particular, I would like to understand, for an eg DWordIO descriptor,
>> what Range Minimum, Range Maximum and Translation Offset represent,
>> they can't mean different things depending on the SW parsing them,
>> this totally defeats the purpose.
> 
> I have no clue about what those mean in ACPI though.
> 
> Generally speaking, each PCI domain is expected to have a (normally 64KB)
> range of CPU addresses that gets translated into PCI I/O space the same
> way that config space and memory space are handled.
> This is true for almost every architecture except for x86, which uses
> different CPU instructions for I/O space compared to the other spaces.
> 
>> By the way, ia64 ioremaps the translation_offset (ie new_space()), so
>> basically that's the CPU physical address at which the PCI host bridge
>> map the IO space transactions), I do not think ia64 is any different from
>> arm64 in this respect, if it is please provide an HW description here from
>> the PCI bus perspective here (also an example of ia64 ACPI PCI host bridge
>> tables would help).
> 
> The main difference between ia64 and a lot of the other architectures (e.g.
> sparc is different again) is that ia64 defines a logical address range
> in terms of having a small number for each I/O space followed by the
> offset within that space as a 'port number' and uses a mapping function
> that is defined as
> 
> static inline void *__ia64_mk_io_addr (unsigned long port)
> {
> struct io_space *space = &io_space[IO_SPACE_NR(port)];
> return (space->mmio_base | IO_SPACE_PORT(port););
> }
> static inline unsigned int inl(unsigned long port)
> {
> return *__ia64_mk_io_addr(port);
> }
> 
> Most architectures allow only one I/O port range and put it at a fixed
> virtual address so that inl() simply becomes 
> 
> static inline u32 inl(unsigned long addr)
> {
> return readl(PCI_IOBASE + addr);
> }
> 
> which noticeably reduces code size.
> 
> On some architectures (powerpc, arm, arm64), we then get the same simplified
> definition with a fixed virtual address, and use pci_ioremap_io() or
> something like that to to map a physical address range into this virtual
> address window at the correct io_offset;
Hi all,
Thanks for explanation, I found a way to make the ACPI resource
parsing interface arch neutral, it should help to address Lorenzo's
concern. Please refer to the attached patch. (It's still RFC, not tested
yet).
Thanks,
Gerry
>From 6521d3c5303b1d9830eecede4c1b778deffe17b0 Mon Sep 17 00:00:00 2001
From: Liu Jiang 
Date: Tue, 10 Nov 2015 10:59:11 +0800
Subject: [PATCH] ACPI, PCI: Refine the way to handl

Re: [PATCH v4 0/6] virtio core DMA API conversion

[Andy Lutomirski]

On Mon, Nov 9, 2015 at 9:28 PM, Benjamin Herrenschmidt
 wrote:
> On Mon, 2015-11-09 at 18:18 -0800, Andy Lutomirski wrote:
>>
>> /* Qumranet donated their vendor ID for devices 0x1000 thru 0x10FF.
>> */
>> static const struct pci_device_id virtio_pci_id_table[] = {
>> { PCI_DEVICE(0x1af4, PCI_ANY_ID) },
>> { 0 }
>> };
>>
>> Can we match on that range?
>
> We can, but the problem remains, how do we differenciate an existing
> device that does bypass vs. a newer one that needs the IOMMU and thus
> doesn't have the new "bypass" property in the device-tree.
>

We could do it the other way around: on powerpc, if a PCI device is in
that range and doesn't have the "bypass" property at all, then it's
assumed to bypass the IOMMU.  This means that everything that
currently works continues working.  If someone builds a physical
virtio device or uses another system in PCIe target mode speaking
virtio, then it won't work until they upgrade their firmware to set
bypass=0.  Meanwhile everyone using hypothetical new QEMU also gets
bypass=0 and no ambiguity.

vfio will presumably notice the bypass and correctly refuse to map any
current virtio devices.

Would that work?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 0/6] virtio core DMA API conversion

[Andy Lutomirski]

On Mon, Nov 9, 2015 at 9:26 PM, Benjamin Herrenschmidt
 wrote:
> On Mon, 2015-11-09 at 18:18 -0800, Andy Lutomirski wrote:
>>
>> Which leaves the special case of Xen, where even preexisting devices
>> don't bypass the IOMMU.  Can we keep this specific to powerpc and
>> sparc?  On x86, this problem is basically nonexistent, since the IOMMU
>> is properly self-describing.
>>
>> IOW, I think that on x86 we should assume that all virtio devices
>> honor the IOMMU.
>
> You don't like performances ? :-)

This should have basically no effect.  Every non-experimental x86
virtio setup in existence either doesn't work at all (Xen) or has DMA
ops that are no-ops.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/5] spi: spi-ti-qspi: add mmap mode read support

[Vignesh R]

ti-qspi controller provides mmap port to read data from SPI flashes.
mmap port is enabled in QSPI_SPI_SWITCH_REG. ctrl module register may
also need to be accessed for some SoCs. The QSPI_SPI_SETUP_REGx needs to
be populated with flash specific information like read opcode, read
mode(quad, dual, normal), address width and dummy bytes. Once,
controller is in mmap mode, the whole flash memory is available as a
memory region at SoC specific address. This region can be accessed using
normal memcpy() (or mem-to-mem dma copy). The ti-qspi controller hardware
will internally communicate with SPI flash over SPI bus and get the
requested data.

Implement spi_mtd_mmap_read() callback to support mmap read over SPI
flash devices. With this, the read throughput increases from ~100kB/s to
~2.5 MB/s.

Signed-off-by: Vignesh R 
---

v3:
 * optimize enable/disable of mmap mode

 drivers/spi/spi-ti-qspi.c | 99 +--
 1 file changed, 95 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 64318fcfacf2..295c11f48440 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -56,6 +56,7 @@ struct ti_qspi {
u32 dc;
 
bool ctrl_mod;
+   bool mmap_enabled;
 };
 
 #define QSPI_PID   (0x0)
@@ -65,11 +66,8 @@ struct ti_qspi {
 #define QSPI_SPI_CMD_REG   (0x48)
 #define QSPI_SPI_STATUS_REG(0x4c)
 #define QSPI_SPI_DATA_REG  (0x50)
-#define QSPI_SPI_SETUP0_REG(0x54)
+#define QSPI_SPI_SETUP_REG(n)  ((0x54 + 4 * n))
 #define QSPI_SPI_SWITCH_REG(0x64)
-#define QSPI_SPI_SETUP1_REG(0x58)
-#define QSPI_SPI_SETUP2_REG(0x5c)
-#define QSPI_SPI_SETUP3_REG(0x60)
 #define QSPI_SPI_DATA_REG_1(0x68)
 #define QSPI_SPI_DATA_REG_2(0x6c)
 #define QSPI_SPI_DATA_REG_3(0x70)
@@ -109,6 +107,16 @@ struct ti_qspi {
 
 #define QSPI_AUTOSUSPEND_TIMEOUT 2000
 
+#define MEM_CS_EN(n)   ((n + 1) << 8)
+
+#define MM_SWITCH  0x1
+
+#define QSPI_SETUP_RD_NORMAL   (0x0 << 12)
+#define QSPI_SETUP_RD_DUAL (0x1 << 12)
+#define QSPI_SETUP_RD_QUAD (0x3 << 12)
+#define QSPI_SETUP_ADDR_SHIFT  8
+#define QSPI_SETUP_DUMMY_SHIFT 10
+
 static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
unsigned long reg)
 {
@@ -366,6 +374,84 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, struct 
spi_transfer *t)
return 0;
 }
 
+static void ti_qspi_enable_memory_map(struct spi_device *spi)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 val;
+
+   ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+   if (qspi->ctrl_mod) {
+   val = readl(qspi->ctrl_base);
+   val |= MEM_CS_EN(spi->chip_select);
+   writel(val, qspi->ctrl_base);
+   /* dummy readl to ensure bus sync */
+   readl(qspi->ctrl_base);
+   }
+   qspi->mmap_enabled = true;
+}
+
+static void ti_qspi_disable_memory_map(struct spi_device *spi)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 val;
+
+   ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
+   if (qspi->ctrl_mod) {
+   val = readl(qspi->ctrl_base);
+   val &= ~MEM_CS_EN(spi->chip_select);
+   writel(val, qspi->ctrl_base);
+   }
+   qspi->mmap_enabled = false;
+}
+
+static void ti_qspi_setup_mmap_read(struct spi_device *spi,
+   u8 read_opcode, u8 addr_width,
+   u8 dummy_bytes)
+{
+   struct ti_qspi  *qspi = spi_master_get_devdata(spi->master);
+   u32 mode = spi->mode & (SPI_RX_DUAL | SPI_RX_QUAD);
+   u32 memval = read_opcode;
+
+   switch (mode) {
+   case SPI_RX_QUAD:
+   memval |= QSPI_SETUP_RD_QUAD;
+   break;
+   case SPI_RX_DUAL:
+   memval |= QSPI_SETUP_RD_DUAL;
+   break;
+   default:
+   memval |= QSPI_SETUP_RD_NORMAL;
+   break;
+   }
+   memval |= ((addr_width - 1) << QSPI_SETUP_ADDR_SHIFT |
+  dummy_bytes << QSPI_SETUP_DUMMY_SHIFT);
+   ti_qspi_write(qspi, memval,
+ QSPI_SPI_SETUP_REG(spi->chip_select));
+}
+
+static int ti_qspi_spi_mtd_mmap_read(struct  spi_device *spi,
+loff_t from, size_t len,
+size_t *retlen, u_char *buf,
+u8 read_opcode, u8 addr_width,
+u8 dummy_bytes)
+{
+   struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
+   int ret = 0;
+
+   mutex_lock(&qspi->list_lock);
+
+   if (!qspi->mmap_enabled)
+   ti_qspi_enable_memory_map(spi);
+   ti_qspi_setup_mm

[PATCH v3 5/5] ARM: dts: AM4372: add entry for qspi mmap region

[Vignesh R]

Add qspi memory mapped region entries for AM43xx based SoCs. Also,
update the binding documents for the controller to document this change.

Signed-off-by: Vignesh R 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
 arch/arm/boot/dts/am4372.dtsi | 4 +++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 334aa3f32cbc..5a1542eda387 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -17,9 +17,10 @@ Recommended properties:
 
 Example:
 
+For am4372:
 qspi: qspi@4b30 {
-   compatible = "ti,dra7xxx-qspi";
-   reg = <0x4790 0x100>, <0x3000 0x3ff>;
+   compatible = "ti,am4372-qspi";
+   reg = <0x4790 0x100>, <0x3000 0x400>;
reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c9701e..e32d164102d1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -963,7 +963,9 @@
 
qspi: qspi@4790 {
compatible = "ti,am4372-qspi";
-   reg = <0x4790 0x100>;
+   reg = <0x4790 0x100>,
+ <0x3000 0x400>;
+   reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Vignesh R]

Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
update the binding documents for the controller to document this change.

Signed-off-by: Vignesh R 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/spi/ti_qspi.txt | 14 ++
 arch/arm/boot/dts/dra7.dtsi   |  7 +--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 601a360531a5..334aa3f32cbc 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -26,3 +26,17 @@ qspi: qspi@4b30 {
spi-max-frequency = <2500>;
ti,hwmods = "qspi";
 };
+
+For dra7xx:
+qspi: qspi@4b30 {
+   compatible = "ti,dra7xxx-qspi";
+   reg = <0x4b30 0x100>,
+ <0x5c00 0x400>,
+ <0x4a002558 0x4>;
+   reg-names = "qspi_base", "qspi_mmap",
+   "qspi_ctrlmod";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   spi-max-frequency = <4800>;
+   ti,hwmods = "qspi";
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8fedddc35999..ad93fe2ccab8 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1108,8 +1108,11 @@
 
qspi: qspi@4b30 {
compatible = "ti,dra7xxx-qspi";
-   reg = <0x4b30 0x100>;
-   reg-names = "qspi_base";
+   reg = <0x4b30 0x100>,
+ <0x5c00 0x400>,
+ <0x4a002558 0x4>;
+   reg-names = "qspi_base", "qspi_mmap",
+   "qspi_ctrlmod";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/5] spi: introduce mmap read support for spi flash devices

[Vignesh R]

In addition to providing direct access to SPI bus, some spi controller
hardwares (like ti-qspi) provide special memory mapped port
to accesses SPI flash devices in order to increase read performance.
This means the controller can automatically send the SPI signals
required to read data from the SPI flash device.
For this, spi controller needs to know flash specific information like
read command to use, dummy bytes and address width. Once these settings
are populated in hardware registers, any read accesses to flash's memory
map region(SoC specific) through memcpy (or mem-to mem DMA copy) will be
handled by controller hardware. The hardware will automatically generate
SPI signals required to read data from flash and present it to CPU/DMA.

Introduce spi_mtd_mmap_read() interface to support memory mapped read
over SPI flash devices. SPI master drivers can implement this callback to
support memory mapped read interfaces. m25p80 flash driver and other
flash drivers can call this to request memory mapped read. The interface
should only be used MTD flashes and cannot be used with other SPI devices.

Signed-off-by: Vignesh R 
---
v3:
 * Remove use of mmap_lock_mutex, use bus_lock_mutex instead.

 drivers/spi/spi.c   | 34 ++
 include/linux/spi/spi.h | 20 
 2 files changed, 54 insertions(+)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index e2415be209d5..0448d29fefc8 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1134,6 +1134,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
}
}
 
+   mutex_lock(&master->bus_lock_mutex);
trace_spi_message_start(master->cur_msg);
 
if (master->prepare_message) {
@@ -1143,6 +1144,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
"failed to prepare message: %d\n", ret);
master->cur_msg->status = ret;
spi_finalize_current_message(master);
+   mutex_unlock(&master->bus_lock_mutex);
return;
}
master->cur_msg_prepared = true;
@@ -1152,6 +1154,7 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
if (ret) {
master->cur_msg->status = ret;
spi_finalize_current_message(master);
+   mutex_unlock(&master->bus_lock_mutex);
return;
}
 
@@ -1159,8 +1162,10 @@ static void __spi_pump_messages(struct spi_master 
*master, bool in_kthread)
if (ret) {
dev_err(&master->dev,
"failed to transfer one message from queue\n");
+   mutex_unlock(&master->bus_lock_mutex);
return;
}
+   mutex_unlock(&master->bus_lock_mutex);
 }
 
 /**
@@ -2327,6 +2332,35 @@ int spi_async_locked(struct spi_device *spi, struct 
spi_message *message)
 EXPORT_SYMBOL_GPL(spi_async_locked);
 
 
+int spi_mtd_mmap_read(struct spi_device *spi, loff_t from, size_t len,
+ size_t *retlen, u_char *buf, u8 read_opcode,
+ u8 addr_width, u8 dummy_bytes)
+
+{
+   struct spi_master *master = spi->master;
+   int ret;
+
+   if (master->auto_runtime_pm) {
+   ret = pm_runtime_get_sync(master->dev.parent);
+   if (ret < 0) {
+   dev_err(&master->dev, "Failed to power device: %d\n",
+   ret);
+   goto err;
+   }
+   }
+   mutex_lock(&master->bus_lock_mutex);
+   ret = master->spi_mtd_mmap_read(spi, from, len, retlen, buf,
+   read_opcode, addr_width,
+   dummy_bytes);
+   mutex_unlock(&master->bus_lock_mutex);
+   if (master->auto_runtime_pm)
+   pm_runtime_put(master->dev.parent);
+
+err:
+   return ret;
+}
+EXPORT_SYMBOL_GPL(spi_mtd_mmap_read);
+
 /*-*/
 
 /* Utility methods for SPI master protocol drivers, layered on
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index cce80e6dc7d1..2f2c431b8917 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -361,6 +361,11 @@ static inline void spi_unregister_driver(struct spi_driver 
*sdrv)
  * @handle_err: the subsystem calls the driver to handle an error that occurs
  * in the generic implementation of transfer_one_message().
  * @unprepare_message: undo any work done by prepare_message().
+ * @spi_mtd_mmap_read: some spi-controller hardwares provide memory.
+ * Flash drivers (like m25p80) can request memory
+ * mapped read via this method. This interface
+ * should only be used by mtd flashes and cannot be
+ * used by other spi devic

[PATCH v3 0/5] Add memory mapped read support for ti-qspi

[Vignesh R]

Changes since v2:
Remove mmap_lock_mutex.
Optimize enable/disable of mmap mode.

Changes since v1:
Introduce API in SPI core that MTD flash driver can call for mmap read
instead of directly calling spi-master driver callback. This API makes
sure that SPI core msg queue is locked during mmap transfers.
v1: https://lkml.org/lkml/2015/9/4/103


Cover letter:

This patch series adds support for memory mapped read port of ti-qspi.
ti-qspi has a special memory mapped port through which SPI flash
memories can be accessed directly via SoC specific memory region.

First patch adds a method to pass flash specific information like read
opcode, dummy bytes etc and to request mmap read. Second patch
implements mmap read method in ti-qspi driver. Patch 3 adapts m25p80 to
use mmap read method before trying normal SPI transfer. Patch 4 and 5
add memory map region DT entries for DRA7xx and AM43xx SoCs.

This patch series is based on the discussions here:
http://www.spinics.net/lists/linux-spi/msg04796.html

Tested on DRA74 EVM and AM437x-SK.
Read performance increases from ~100kB/s to ~2.5MB/s.

Vignesh R (5):
  spi: introduce mmap read support for spi flash devices
  spi: spi-ti-qspi: add mmap mode read support
  mtd: devices: m25p80: add support for mmap read request
  ARM: dts: DRA7: add entry for qspi mmap region
  ARM: dts: AM4372: add entry for qspi mmap region

 Documentation/devicetree/bindings/spi/ti_qspi.txt | 19 -
 arch/arm/boot/dts/am4372.dtsi |  4 +-
 arch/arm/boot/dts/dra7.dtsi   |  7 +-
 drivers/mtd/devices/m25p80.c  |  5 ++
 drivers/spi/spi-ti-qspi.c | 99 ++-
 drivers/spi/spi.c | 34 
 include/linux/spi/spi.h   | 20 +
 7 files changed, 179 insertions(+), 9 deletions(-)

-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 3/5] mtd: devices: m25p80: add support for mmap read request

[Vignesh R]

Certain spi controllers may support memory mapped interface to read from
m25p80 type flash devices. This interface provides better read
performance than regular SPI interface.
Call spi_mtd_mmap_read() interface, if supported, to make use of
memory-mapped interface.

Signed-off-by: Vignesh R 
---
 drivers/mtd/devices/m25p80.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index fe9ceb7b5405..7ef0c5009ead 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -131,6 +131,11 @@ static int m25p80_read(struct spi_nor *nor, loff_t from, 
size_t len,
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
 
+   if (spi_mmap_read_supported(spi))
+   return spi_mtd_mmap_read(spi, from, len, retlen, buf,
+nor->read_opcode,
+nor->addr_width, dummy);
+
spi_message_init(&m);
memset(t, 0, (sizeof t));
 
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 0/6] virtio core DMA API conversion

[Benjamin Herrenschmidt]

On Mon, 2015-11-09 at 18:18 -0800, Andy Lutomirski wrote:
> 
> /* Qumranet donated their vendor ID for devices 0x1000 thru 0x10FF.
> */
> static const struct pci_device_id virtio_pci_id_table[] = {
>     { PCI_DEVICE(0x1af4, PCI_ANY_ID) },
>     { 0 }
> };
> 
> Can we match on that range?

We can, but the problem remains, how do we differenciate an existing
device that does bypass vs. a newer one that needs the IOMMU and thus
doesn't have the new "bypass" property in the device-tree.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [LKP] [lkp] [KVM] 0c32e5dd82: stderr: KVM: entry failed, hardware error 0x80000021

[Huang, Ying]

Wanpeng Li  writes:

> On 11/10/15 9:47 AM, kernel test robot wrote:
>> FYI, we noticed the below changes on
>>
>> https://github.com/0day-ci/linux 
>> Wanpeng-Li/KVM-x86-Reset-RFLAGS-state-following-processor-init-reset/20151103-194355
>> commit 0c32e5dd82fd0e63fd9e6aecf5a4bffbdf2ab207 ("KVM: x86: Reset RFLAGS 
>> state following processor init/reset")
>>
>> The stderr of kvm-unit-tests is as follow for your commit.
>
> Thanks for the report, however, I don't think maintainer pick this
> patch in any tree currently, which tree you are testing against?

We test patches from LKML directly now :)

Best Regards,
Huang, Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [ext4] dfbd72d0d6: -100.0% xfstests.ext4.001.seconds

[kernel test robot]

FYI, we noticed the below changes on

https://github.com/0day-ci/linux 
Jan-Kara/ext4-Fix-races-between-page-faults-and-hole-punching/20151105-002716
commit dfbd72d0d6f10086064b918419fb2094ff9fbdb6 ("ext4: Fix races between page 
faults and hole punching")


=
tbox_group/testcase/rootfs/kconfig/compiler/disk/fs/test:
  
vm-kbuild-2G/xfstests/debian-x86_64-2015-02-07.cgz/x86_64-rhel/gcc-4.9/4HDD/ext4/ext4

commit: 
  32b88194f71d6ae7768a29f87fbba454728273ee
  dfbd72d0d6f10086064b918419fb2094ff9fbdb6

32b88194f71d6ae7 dfbd72d0d6f10086064b918419 
 -- 
   fail:runs  %reproductionfail:runs
   | | |
   :4  100%   4:4 last_state.xfstests.exit_code.1
   :4  100%   4:4 xfstests.ext4.001.fail
   :4  100%   4:4 xfstests.nr_fail

vm-kbuild-2G: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
Memory: 2G

The output of xfstests is as follow:

2015-11-09 01:42:14 export TEST_DIR=/fs/vda
2015-11-09 01:42:14 export TEST_DEV=/dev/vda
2015-11-09 01:42:14 export FSTYP=ext4
2015-11-09 01:42:14 export SCRATCH_MNT=/fs/scratch
2015-11-09 01:42:14 mkdir /fs/scratch -p
2015-11-09 01:42:14 export SCRATCH_DEV=/dev/vdd
2015-11-09 01:42:14 ./check ext4/001 ext4/002 ext4/003 ext4/004 ext4/005 
ext4/006 ext4/007 ext4/008 ext4/009 ext4/010 ext4/011 ext4/012 ext4/013 
ext4/014 ext4/015 ext4/016 ext4/017 ext4/018 ext4/019 ext4/271 ext4/301 
ext4/305 ext4/306 ext4/307 ext4/308
FSTYP -- ext4
PLATFORM  -- Linux/x86_64 vm-kbuild-2G-3 4.3.0-rc7-1-gdfbd72d
MKFS_OPTIONS  -- /dev/vdd
MOUNT_OPTIONS -- -o acl,user_xattr /dev/vdd /fs/scratch

ext4/001 - output mismatch (see 
/lkp/benchmarks/xfstests/results//ext4/001.out.bad)
--- tests/ext4/001.out  2015-11-04 17:39:25.0 +0800
+++ /lkp/benchmarks/xfstests/results//ext4/001.out.bad  2015-11-09 
01:42:55.408281000 +0800
@@ -131,14 +131,10 @@
 2: [32..39]: hole
 daa100df6e6711906b61c9ab5aa16032
11. data -> hole -> data
-0: [0..7]: data
-1: [8..31]: unwritten
-2: [32..39]: data
+0: [0..39]: data
...
(Run 'diff -u tests/ext4/001.out 
/lkp/benchmarks/xfstests/results//ext4/001.out.bad'  to see the entire diff)
ext4/002 16s
ext4/003 17s
ext4/004 13s
ext4/005 7s
ext4/006 [not run] Couldn't find e2fuzz
ext4/007 [not run] metadata_csum not supported by this filesystem
ext4/008 [not run] metadata_csum not supported by this filesystem
ext4/009 [not run] metadata_csum not supported by this filesystem
ext4/010 [not run] metadata_csum not supported by this filesystem
ext4/011 [not run] metadata_csum not supported by this filesystem
ext4/012 [not run] metadata_csum not supported by this filesystem
ext4/013 [not run] metadata_csum not supported by this filesystem
ext4/014 [not run] metadata_csum not supported by this filesystem
ext4/015 [not run] metadata_csum not supported by this filesystem
ext4/016 [not run] metadata_csum not supported by this filesystem
ext4/017 [not run] metadata_csum not supported by this filesystem
ext4/018 [not run] metadata_csum not supported by this filesystem
ext4/019 [not run] metadata_csum not supported by this filesystem
ext4/271 17s
ext4/301 114s
ext4/305 40s
ext4/306 18s
ext4/307 50s
ext4/308 22s
Ran: ext4/001 ext4/002 ext4/003 ext4/004 ext4/005 ext4/271 ext4/301 ext4/305 
ext4/306 ext4/307 ext4/308
Not run: ext4/006 ext4/007 ext4/008 ext4/009 ext4/010 ext4/011 ext4/012 
ext4/013 ext4/014 ext4/015 ext4/016 ext4/017 ext4/018 ext4/019
Failures: ext4/001
Failed 1 of 11 tests

To reproduce:

git clone 
git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
cd lkp-tests
bin/lkp install job.yaml  # job file is attached in this email
bin/lkp run job.yaml


Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.


Thanks,
Ying Huang
---
LKP_SERVER: inn
LKP_CGI_PORT: 80
LKP_CIFS_PORT: 139
testcase: xfstests
default-monitors:
  wait: activate-monitor
  kmsg: 
  vmstat:
interval: 10
default-watchdogs:
  oom-killer: 
  watchdog: 
cpufreq_governor: 
model: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap
nr_vm: 16
nr_cpu: 2
memory: 2G
rootfs: debian-x86_64-2015-02-07.cgz
hdd_partitions: "/dev/vda /dev/vdb /dev/vdc /dev/vdd /dev/vde /dev/vdf"
swap_partitions: "/dev/vdg"
ssh_base_port: 23016
category: functional
disk: 4HDD
fs: ext4
xfstests:
  test: ext4
enqueue_time: 2015-11-08 02:34:21.338609409 +08:00
branch: linux-devel/devel-hourly-2015110

spolupráce

[mssg1]

odpovezte mi na nize uvedenou e-mailovou adresu pro vysvetlení výroku.

E-mail: chn.j...@gmail.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] block: create ioctl to discard-or-zeroout a range of blocks

[Darrick J. Wong]

Create a new ioctl to expose the block layer's newfound ability to
issue either a zeroing discard, a WRITE SAME with a zero page, or a
regular write with the zero page.  This BLKZEROOUT2 ioctl takes
{start, length, flags} as parameters.  So far, the only flag available
is to enable the zeroing discard part -- without it, the call invokes
the old BLKZEROOUT behavior.  start and length have the same meaning
as in BLKZEROOUT.

Furthermore, because BLKZEROOUT2 issues commands directly to the
storage device, we must invalidate the page cache (as a regular
O_DIRECT write would do) to avoid returning stale cache contents at a
later time.  BLKZEROOUT never did this, which lead to coherency
problems when e2fsprogs tried to use it.

v2: Padded the structure with extra space for future fun, since the
maintainer never responded...

Signed-off-by: Darrick J. Wong 
---
 block/ioctl.c   |   45 ++---
 include/uapi/linux/fs.h |9 +
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/block/ioctl.c b/block/ioctl.c
index 8061eba..79a2e1c 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -213,19 +213,39 @@ static int blk_ioctl_discard(struct block_device *bdev, 
uint64_t start,
 }
 
 static int blk_ioctl_zeroout(struct block_device *bdev, uint64_t start,
-uint64_t len)
+uint64_t len, uint32_t flags)
 {
+   int ret;
+   struct address_space *mapping;
+   uint64_t end = start + len - 1;
+
+   if (flags & ~BLKZEROOUT2_DISCARD_OK)
+   return -EINVAL;
if (start & 511)
return -EINVAL;
if (len & 511)
return -EINVAL;
-   start >>= 9;
-   len >>= 9;
-
-   if (start + len > (i_size_read(bdev->bd_inode) >> 9))
+   if (end >= i_size_read(bdev->bd_inode))
return -EINVAL;
 
-   return blkdev_issue_zeroout(bdev, start, len, GFP_KERNEL, false);
+   /* Invalidate the page cache, including dirty pages */
+   mapping = bdev->bd_inode->i_mapping;
+   truncate_inode_pages_range(mapping, start, end);
+
+   ret = blkdev_issue_zeroout(bdev, start >> 9, len >> 9, GFP_KERNEL,
+  flags & BLKZEROOUT2_DISCARD_OK);
+   if (ret)
+   goto out;
+
+   /*
+* Invalidate again; if someone wandered in and dirtied a page,
+* the caller will be given -EBUSY.
+*/
+   ret = invalidate_inode_pages2_range(mapping,
+   start >> PAGE_CACHE_SHIFT,
+   end >> PAGE_CACHE_SHIFT);
+out:
+   return ret;
 }
 
 static int put_ushort(unsigned long arg, unsigned short val)
@@ -353,7 +373,18 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode, 
unsigned cmd,
if (copy_from_user(range, (void __user *)arg, sizeof(range)))
return -EFAULT;
 
-   return blk_ioctl_zeroout(bdev, range[0], range[1]);
+   return blk_ioctl_zeroout(bdev, range[0], range[1], 0);
+   }
+   case BLKZEROOUT2: {
+   struct blkzeroout2 p;
+
+   if (!(mode & FMODE_WRITE))
+   return -EBADF;
+
+   if (copy_from_user(&p, (void __user *)arg, sizeof(p)))
+   return -EFAULT;
+
+   return blk_ioctl_zeroout(bdev, p.start, p.length, p.flags);
}
 
case HDIO_GETGEO: {
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 9b964a5..b811fa4 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -152,6 +152,15 @@ struct inodes_stat_t {
 #define BLKSECDISCARD _IO(0x12,125)
 #define BLKROTATIONAL _IO(0x12,126)
 #define BLKZEROOUT _IO(0x12,127)
+struct blkzeroout2 {
+   __u64 start;
+   __u64 length;
+   __u32 flags;
+   __u32 padding;
+   __u64 padding2;
+};
+#define BLKZEROOUT2_DISCARD_OK 1
+#define BLKZEROOUT2 _IOR(0x12, 127, struct blkzeroout2)
 
 #define BMAP_IOCTL 1   /* obsolete - kept for compatibility */
 #define FIBMAP_IO(0x00,1)  /* bmap access */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] thermal: rcar_thermal: tidyup rebind issue

[Nguyen Viet Dung]

Hi,

I have tested rcar_thermal funstion on stable linux v4.3.
It is good with this patchs.

Tested-by: Nguyen Viet Dung 

Best regards
Nguyen Viet Dung

On 2015年11月10日 11:11, Kuninori Morimoto wrote:

Hi Zhang, Eduardo
Cc: Dung, Hiep

rcar_thermal doesn't work after unbind/re-bind today.
These patches are cosmetic, and tidyup it

Kuninori Morimoto (2):
   thermal: rcar_thermal: remove redundant operation
   thermal: rcar_thermal: use pm_runtime_put_sync()

  drivers/thermal/rcar_thermal.c | 49 
+
  1 file changed, 21 insertions(+), 28 deletions(-)


Best regards
---
Kuninori Morimoto



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/5] mtd: nand: Create a BBT flag to access bad block markers in raw mode

[Archit Taneja]

Hi,

On 10/12/2015 01:33 AM, Brian Norris wrote:

Hi Boris,

On Fri, Oct 02, 2015 at 08:27:38AM +0200, Boris Brezillon wrote:

Brian, Archit,

On Thu, 1 Oct 2015 19:44:34 -0700
Brian Norris  wrote:


On Wed, Aug 19, 2015 at 10:19:02AM +0530, Archit Taneja wrote:

Some controllers can access the factory bad block marker from OOB only
when they read it in raw mode. When ECC is enabled, these controllers
discard reading/writing bad block markers, preventing access to them
altogether.

The bbt driver assumes MTD_OPS_PLACE_OOB when scanning for bad blocks.
This results in the nand driver's ecc->read_oob() op to be called, which
works with ECC enabled.

Create a new BBT option flag that tells nand_bbt to force the mode to
MTD_OPS_RAW. This would result in the correct op being called for the
underlying nand controller driver.


Actually I have the same kind of patch in my local tree (for a
different reason though: the HW randomizer can mess up with the BBM
byte if it's not disabled, and the only way to disable it in my current
implementation is to switch to raw mode).



MTD_OPS_RAW is probably the best way to do this, and we should switch
back to it for all users (rather than a new flag).


I'm fine with this solution, but will that be acceptable for everybody?
I mean, some NAND controllers are able to protect some OOB bytes, and
the BBM might fall in those OOB bytes. In this case, shouldn't we rely
on the ECC protection instead of reading the OOB in raw mode?


I think ECC is kind of misused a bit here. It's not really meant for
protecting BBMs, and it's also really not sufficient, esp. given
bitflips in erased areas.


But to do this, we
need to fix up some things. Particularly, we need to extend
'badblockbits' support so that it is applied consistently in all places
(I recall there is one code path in which bad block scanning does take
this into account, and one that doesn't.)


Yes, IIRC Andrea has posted a patch addressing that problem [1].
Another problem I see is that badblockbits is currently assigned a
fixed value by the NAND controller driver (or a default value of 8).
There's no specific logic to correlate it to the required ECC strength.
IMO, we should not let each NAND controller driver decide what is the
appropriate value for each chip but rather implement the logic in
nand_base.c based on ecc->strength and ecc->size, and IIRC this was
the question Andrea asked when he posted his proposal.



About badblockbits: it allows us to do a relaxed heuristic on matching
bad block markers, where we say the BBM is "bad" if more than fewer than
N bits are '1'. Right now, we just say that if there are any 0 bits in
the Bad Block Marker (BBM) region, then the block is bad. But this is
problematic for pages that have been worn down and might have bitflips.
So right now, part of a (bad) solution is to read with ECC, so worn
blocks that have data won't be later interpreted as bad blocks if we
rescan the BBMs (ECC will correct the bitflips, if the OOB is
protected).

But that solution is not really good, since ECC is not really a panacea
for misinterpreted BBMs. And HW like yours apparently won't work like
this.


Okay, I see you gave pretty much the same explanation, which makes mine
useless :-).



So in summary: if we can consistently make BBM checks look for 6 or 7
"one" bits (rather than a full 8 bits, i.e. BBM == 0xff), then we can
just unconditionally switch to RAW rather than PLACE_OOB. And we don't
need a flag like this pach introduces.


I guess it all depends whether we want to let NAND controllers that can
protect their BBM keep doing it (which IMO is not such a bad idea).


I think I was the only one consciously trying to do this. (Though I
guess it's possible some people discreetly hacked it in by not
supporting raw mode properly.) And for my cases, I'm pretty sure a
properly-improved raw mode BBM scan would be just as good, or actually
better. So I'm not sure anyone would really notice if we switched back
and properly accounted for flips.


Was there any progress on the badblockbits work? I'd seen a thread on
linux-mtd but that had sort of died too.

Brian,

Could we get this driver merged for now without BBT support? In my next
revision, I could populate chip->block_bad and chip->block_markbad
and add NAND_SKIP_BBTSCAN to chip->options. I can remove this once
we have badblockbits support.

Thanks,
Archit



Brian

__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/



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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[lkp] [x86/numachip] db1003a719: BUG: kernel early-boot hang

[kernel test robot]

FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit db1003a719d75cebe5843a7906c02c29bec9922c ("x86/numachip: Cleanup 
Numachip support")


Elapsed time: 210
BUG: kernel early-boot hang
Linux version 4.3.0-rc2-1-gdb1003a #1
Command line: root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-intel12-yocto-x86_64-14/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-allyesdebian-db1003a719d75cebe5843a7906c02c29bec9922c-20151107-100037-1jb4qfh-1.yaml
 ARCH=x86_64 kconfig=x86_64-allyesdebian 
branch=sergeh-security/2015-11-05/cgroupns 
commit=db1003a719d75cebe5843a7906c02c29bec9922c 
BOOT_IMAGE=/pkg/linux/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/vmlinuz-4.3.0-rc2-1-gdb1003a
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-intel12-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-intel12-yocto-x86_64-14::dhcp drbd.minor_count=8
qemu-system-x86_64 -enable-kvm -cpu Nehalem -kernel 
/pkg/linux/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/vmlinuz-4.3.0-rc2-1-gdb1003a
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-intel12-yocto-x86_64-14/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-allyesdebian-db1003a719d75cebe5843a7906c02c29bec9922c-20151107-100037-1jb4qfh-1.yaml
 ARCH=x86_64 kconfig=x86_64-allyesdebian 
branch=sergeh-security/2015-11-05/cgroupns 
commit=db1003a719d75cebe5843a7906c02c29bec9922c 
BOOT_IMAGE=/pkg/linux/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/vmlinuz-4.3.0-rc2-1-gdb1003a
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-intel12-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-intel12-yocto-x86_64-14::dhcp drbd.minor_count=8'  -initrd 
/fs/KVM/initrd-vm-intel12-yocto-x86_64-14 -m 832 -smp 2 -device 
e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot -watchdog 
i6300esb -rtc base=localtime -drive 
file=/fs/KVM/disk0-vm-intel12-yocto-x86_64-14,media=disk,if=virtio -drive 
file=/fs/KVM/disk1-vm-intel12-yocto-x86_64-14,media=disk,if=virtio -pidfile 
/dev/shm/kboot/pid-vm-intel12-yocto-x86_64-14 -serial 
file:/dev/shm/kboot/serial-vm-intel12-yocto-x86_64-14 -daemonize -display none 
-monitor null 


Thanks,
Ying Huang
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.3.0-rc2 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
nCONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CON

[PATCH] instmem/gk20a: do not use non-portable dma_to_phys()

[Alexandre Courbot]

dma_to_phys() is not guaranteed to be available on all platforms and
should not be used outside of arch/. Replace it with what it is expected
to do in our case: simply cast the DMA handle to a physical address.

Reported-by: Stephen Rothwell 
Signed-off-by: Alexandre Courbot 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
index fc419bb8eab7..49451645a049 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c
@@ -134,13 +134,17 @@ static void __iomem *
 gk20a_instobj_cpu_map_dma(struct nvkm_memory *memory)
 {
struct gk20a_instobj_dma *node = gk20a_instobj_dma(memory);
-   struct device *dev = node->base.imem->base.subdev.device->dev;
int npages = nvkm_memory_size(memory) >> 12;
struct page *pages[npages];
int i;
 
-   /* phys_to_page does not exist on all platforms... */
-   pages[0] = pfn_to_page(dma_to_phys(dev, node->handle) >> PAGE_SHIFT);
+   /*
+* Ideally we would have a function to translate a handle to a physical
+* address, but there is no portable way of doing this. However since we
+* always use the DMA API without an IOMMU, we can assume that handles
+* are actual physical addresses.
+*/
+   pages[0] = pfn_to_page(((phys_addr_t)node->handle) >> PAGE_SHIFT);
for (i = 1; i < npages; i++)
pages[i] = pages[0] + i;
 
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] of: Print rather than WARN'ing when overlap check fails

[Michael Ellerman]

__rmem_check_for_overlap() is called very early in boot, and on some
powerpc systems it's not safe to call WARN that early in boot.

If the overlap check fails the system will oops instead of printing a
warning. Furthermore because it's so early in boot the console is not up
and the user doesn't see the oops, they just get a dead system.

Fix it by printing an error instead of calling WARN.

Fixes: ae1add247bf8 ("of: Check for overlap in reserved memory regions")
Signed-off-by: Michael Ellerman 
---
 drivers/of/of_reserved_mem.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 62f467b8ccae..49703916a30e 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -226,10 +226,9 @@ static void __init __rmem_check_for_overlap(void)
 
this_end = this->base + this->size;
next_end = next->base + next->size;
-   WARN(1,
-"Reserved memory: OVERLAP DETECTED!\n%s (%pa--%pa) 
overlaps with %s (%pa--%pa)\n",
-this->name, &this->base, &this_end,
-next->name, &next->base, &next_end);
+   pr_err("Reserved memory: OVERLAP DETECTED!\n%s 
(%pa--%pa) overlaps with %s (%pa--%pa)\n",
+  this->name, &this->base, &this_end,
+  next->name, &next->base, &next_end);
}
}
 }
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 8/8] Staging: lustre: llite: Remove ll_finish_md_op_data wrapper

[Shivani Bhardwaj]

Remove the wrapper function ll_finish_md_op_data() and replace all
its calls with the standard function kfree() that it wraps. Also,
prototype of the function is removed as it is no longer of any use.

Signed-off-by: Shivani Bhardwaj 
---
Changes in v2:
Fix commit message and merge a patch

 drivers/staging/lustre/lustre/llite/llite_internal.h |  1 -
 drivers/staging/lustre/lustre/llite/llite_lib.c  | 13 -
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_internal.h 
b/drivers/staging/lustre/lustre/llite/llite_internal.h
index 157c3284..d12d483 100644
--- a/drivers/staging/lustre/lustre/llite/llite_internal.h
+++ b/drivers/staging/lustre/lustre/llite/llite_internal.h
@@ -792,7 +792,6 @@ struct md_op_data *ll_prep_md_op_data(struct md_op_data 
*op_data,
  struct inode *i1, struct inode *i2,
  const char *name, int namelen,
  int mode, __u32 opc, void *data);
-void ll_finish_md_op_data(struct md_op_data *op_data);
 int ll_get_obd_name(struct inode *inode, unsigned int cmd, unsigned long arg);
 char *ll_get_fsname(struct super_block *sb, char *buf, int buflen);
 void ll_open_cleanup(struct super_block *sb, struct ptlrpc_request *open_req);
diff --git a/drivers/staging/lustre/lustre/llite/llite_lib.c 
b/drivers/staging/lustre/lustre/llite/llite_lib.c
index 4a8c759..143be87 100644
--- a/drivers/staging/lustre/lustre/llite/llite_lib.c
+++ b/drivers/staging/lustre/lustre/llite/llite_lib.c
@@ -1355,7 +1355,7 @@ out:
if (!rc)
rc = rc1;
}
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
if (!S_ISDIR(inode->i_mode)) {
mutex_lock(&inode->i_mutex);
@@ -1732,7 +1732,7 @@ int ll_iocontrol(struct inode *inode, struct file *file,
 
op_data->op_valid = OBD_MD_FLFLAGS;
rc = md_getattr(sbi->ll_md_exp, op_data, &req);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc) {
CERROR("failure %d inode %lu\n", rc, inode->i_ino);
return -abs(rc);
@@ -1763,7 +1763,7 @@ int ll_iocontrol(struct inode *inode, struct file *file,
op_data->op_attr.ia_valid |= ATTR_ATTR_FLAG;
rc = md_setattr(sbi->ll_md_exp, op_data,
NULL, 0, NULL, 0, &req, NULL);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
ptlrpc_req_finished(req);
if (rc)
return rc;
@@ -1934,7 +1934,7 @@ void ll_open_cleanup(struct super_block *sb, struct 
ptlrpc_request *open_req)
op_data->op_mod_time = get_seconds();
md_close(exp, op_data, NULL, &close_req);
ptlrpc_req_finished(close_req);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 }
 
 int ll_prep_inode(struct inode **inode, struct ptlrpc_request *req,
@@ -2170,11 +2170,6 @@ struct md_op_data *ll_prep_md_op_data(struct md_op_data 
*op_data,
return op_data;
 }
 
-void ll_finish_md_op_data(struct md_op_data *op_data)
-{
-   kfree(op_data);
-}
-
 int ll_show_options(struct seq_file *seq, struct dentry *dentry)
 {
struct ll_sb_info *sbi;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 7/8] Staging: lustre: llite_close: Substitute function calls

[Shivani Bhardwaj]

Substitute standard function kfree() in place of the function
ll_finish_md_op_data().

Signed-off-by: Shivani Bhardwaj 
---
Changes in v2:
Fix commit message and merge a patch

 drivers/staging/lustre/lustre/llite/llite_close.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_close.c 
b/drivers/staging/lustre/lustre/llite/llite_close.c
index 3f348a3..c4f22ec 100644
--- a/drivers/staging/lustre/lustre/llite/llite_close.c
+++ b/drivers/staging/lustre/lustre/llite/llite_close.c
@@ -301,7 +301,7 @@ static void ll_done_writing(struct inode *inode)
CERROR("inode %lu mdc done_writing failed: rc = %d\n",
   inode->i_ino, rc);
 out:
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (och) {
md_clear_open_replay_data(ll_i2sbi(inode)->ll_md_exp, och);
kfree(och);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 3/4] dmaselftest: add memcpy selftest support functions

[Timur Tabi]

Sinan Kaya wrote:


OK. I did an internal code review before posting the patch. Nobody
complained about iterator types. I am trying to find what goes as a good
practice vs. what is personal style.


I normally check for inappropriate usage of sized integers in my 
reviews, but I admit I'm inconsistent about that sort of thing for 
internal reviews.


--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 6/8] Staging: lustre: llite_nfs: Replace function calls with kfree

[Shivani Bhardwaj]

Replace the calls of the function ll_finish_md_op_data() with the
standard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
Changes in v2:
Fix commit message and merge a patch

 drivers/staging/lustre/lustre/llite/llite_nfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/llite_nfs.c 
b/drivers/staging/lustre/lustre/llite/llite_nfs.c
index e578a11..a3a89a7 100644
--- a/drivers/staging/lustre/lustre/llite/llite_nfs.c
+++ b/drivers/staging/lustre/lustre/llite/llite_nfs.c
@@ -306,7 +306,7 @@ static struct dentry *ll_get_parent(struct dentry *dchild)
return (void *)op_data;
 
rc = md_getattr_name(sbi->ll_md_exp, op_data, &req);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc) {
CERROR("failure %d inode %lu get parent\n", rc, dir->i_ino);
return ERR_PTR(rc);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 5/8] Staging: lustre: symlink: Substitute standard function

[Shivani Bhardwaj]

Substitute the standard function kfree() for the function
ll_finish_md_op_data().

Signed-off-by: Shivani Bhardwaj 
---
Changes in v2:
Fix commit message and merge a patch

 drivers/staging/lustre/lustre/llite/symlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/symlink.c 
b/drivers/staging/lustre/lustre/llite/symlink.c
index 69b2036..6b0d1cc 100644
--- a/drivers/staging/lustre/lustre/llite/symlink.c
+++ b/drivers/staging/lustre/lustre/llite/symlink.c
@@ -73,7 +73,7 @@ static int ll_readlink_internal(struct inode *inode,
 
op_data->op_valid = OBD_MD_LINKNAME;
rc = md_getattr(sbi->ll_md_exp, op_data, request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc) {
if (rc != -ENOENT)
CERROR("inode %lu: rc = %d\n", inode->i_ino, rc);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 2/4] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

On 11/9/2015 1:25 PM, Rob Herring wrote:

On Sun, Nov 08, 2015 at 09:17:20PM -0500, Sinan Kaya wrote:

On 11/8/2015 12:08 AM, Timur Tabi wrote:

On 11/8/2015 12:08 AM, Timur Tabi wrote:

Sinan Kaya wrote:

+val = val & ~(MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS);
+val = val | (mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS);
+val = val & ~(MAX_BUS_REQ_LEN_MASK);
+val = val | (mgmtdev->max_read_request);


val &= ~MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS;
val |= mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS;
val &= ~MAX_BUS_REQ_LEN_MASK;
val |= mgmtdev->max_read_request;


+static const struct of_device_id hidma_mgmt_match[] = {
+{ .compatible = "qcom,hidma-mgmt", },
+{ .compatible = "qcom,hidma-mgmt-1.0", },
+{ .compatible = "qcom,hidma-mgmt-1.1", },
+{},
+};


I thought Rob said that he did NOT want to use version numbers in
compatible strings.  And what's the difference between these three
versions anyway?



This was already discussed here.

https://lkml.org/lkml/2015/11/2/689

The agreement was to use


The suggestion...


compatible = "qcom,hidma-mgmt-1.1", "qcom,hidma-mgmt-1.0",
"qcom,hidma-mgmt";


I don't really want to see 3 generic-ish strings.


I'll be adding code for v1.1 specifically in the future.


Please drop "qcom,hidma-mgmt" altogether. It is already meaningless.
Then add the 1.1 compatible when you add the code for it. Hopefully you
all can decide on part number(s) by then.

Rob



OK. I'll only have "qcom,hidma-mgmt-1.0" for now.


--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] of: Check for overlap in reserved memory regions

[Michael Ellerman]

On Mon, 2015-11-09 at 22:41 -0600, Rob Herring wrote:
> On Mon, Nov 9, 2015 at 10:29 PM, Michael Ellerman  wrote:
> > On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:
> > > Any overlap in the reserved memory regions (those specified in the
> > > reserved-memory DT node) is a bug.  These bugs might go undetected as
> > > long as the contested region isn't used simultaneously by multiple
> > > software agents, which makes such bugs hard to debug.  Fix this by
> > > printing a scary warning during boot if overlap is detected.
> > > 
> > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> > > index 726ebe792813..62f467b8ccae 100644
> > > --- a/drivers/of/of_reserved_mem.c
> > > +++ b/drivers/of/of_reserved_mem.c
> > > @@ -197,12 +198,52 @@ static int __init __reserved_mem_init_node(struct 
> > > reserved_mem *rmem)
> > >   return -ENOENT;
> > >  }
> > > 
> > > +static int __init __rmem_cmp(const void *a, const void *b)
> > > +{
> > > + const struct reserved_mem *ra = a, *rb = b;
> > > +
> > > + return ra->base - rb->base;
> > > +}
> > > +
> > > +static void __init __rmem_check_for_overlap(void)
> > > +{
> > > + int i;
> > > +
> > > + if (reserved_mem_count < 2)
> > > + return;
> > > +
> > > + sort(reserved_mem, reserved_mem_count, sizeof(reserved_mem[0]),
> > > +  __rmem_cmp, NULL);
> > > + for (i = 0; i < reserved_mem_count - 1; i++) {
> > > + struct reserved_mem *this, *next;
> > > +
> > > + this = &reserved_mem[i];
> > > + next = &reserved_mem[i + 1];
> > > + if (!(this->base && next->base))
> > > + continue;
> > > + if (this->base + this->size > next->base) {
> > > + phys_addr_t this_end, next_end;
> > > +
> > > + this_end = this->base + this->size;
> > > + next_end = next->base + next->size;
> > > + WARN(1,
> > > +  "Reserved memory: OVERLAP DETECTED!\n%s 
> > > (%pa--%pa) overlaps with %s (%pa--%pa)\n",
> > > +  this->name, &this->base, &this_end,
> > > +  next->name, &next->base, &next_end);
> > 
> > This is blowing up on some powerpc machines.
> > 
> > It's too early in boot to call WARN() on these systems.
> 
> I didn't realize WARN could not be used early. Good to know.

Yeah, it's a bit horrible.

It used to be even worse, we'd take a recursive trap and you'd get nothing
useful at all. Ben fixed that, which makes BUG work but not WARN, because WARN
requires you to take the trap _and return_. We should be able to fix it in the
medium term, but not immediately.

> > Can we turn it into a pr_err() for now?
> 
> Sounds fine.

> > I'll send a patch?
> 
> Great.

Thanks. I'll just test the final version and then send.

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 4/8] Staging: lustre: xattr_cache: Change function calls to kfree

[Shivani Bhardwaj]

Change the calls of the function ll_finish_md_op_data() to the
standard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
Changes in v2:
Fix commit message and merge a patch

 drivers/staging/lustre/lustre/llite/xattr_cache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lustre/llite/xattr_cache.c 
b/drivers/staging/lustre/lustre/llite/xattr_cache.c
index e1e599c..b7f3efc 100644
--- a/drivers/staging/lustre/lustre/llite/xattr_cache.c
+++ b/drivers/staging/lustre/lustre/llite/xattr_cache.c
@@ -306,7 +306,7 @@ static int ll_xattr_find_get_lock(struct inode *inode,
op_data->op_valid = OBD_MD_FLXATTR | OBD_MD_FLXATTRLS;
 
rc = md_enqueue(exp, &einfo, oit, op_data, &lockh, NULL, 0, NULL, 0);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
if (rc < 0) {
CDEBUG(D_CACHE,
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm tree

[Alexandre Courbot]

On Tue, Nov 10, 2015 at 1:45 AM, Guenter Roeck  wrote:
> On Wed, Nov 04, 2015 at 08:22:26PM +1100, Stephen Rothwell wrote:
>> Hi Dave,
>>
>> After merging the drm tree, today's linux-next build (s390 allmodconfig)
>> failed like this:
>>
>> drivers/gpu/drm/nouveau/nvkm/subdev/instmem/gk20a.c:143:2: error: implicit 
>> declaration of function 'dma_to_phys' [-Werror=implicit-function-declaration]
>>
>> Caused by commit
>>
>>   69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access")
>>
>> Discovered after the release.
>>
> Still seen in next-20151109, affecting at least alpha, i386, parisc, s390,
> and xtensa, but probably other architectures as well.
>
> dma_to_phys() was until now not used from driver code, and is only declared
> for an architecture if it is used/needed there.

Mmm there doesn't seem to be a portable way of getting a physical
address from a DMA handle, which is what we are trying to do in this
code.

In that particular case a cast is enough though, so we should probably
just do that. I will send a patch for Ben/David to include in order to
fix this issue at least.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/8] Staging: lustre: namei: Replace calls with kfree

[Shivani Bhardwaj]

Replace the calls of the function ll_finish_md_op_data() with the
standard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
Changes in v2:
Fix commit message and merge a patch

 drivers/staging/lustre/lustre/llite/namei.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/namei.c 
b/drivers/staging/lustre/lustre/llite/namei.c
index 2ca2200..f058ebe2 100644
--- a/drivers/staging/lustre/lustre/llite/namei.c
+++ b/drivers/staging/lustre/lustre/llite/namei.c
@@ -531,7 +531,7 @@ static struct dentry *ll_lookup_it(struct inode *parent, 
struct dentry *dentry,
 
rc = md_intent_lock(ll_i2mdexp(parent), op_data, NULL, 0, it,
lookup_flags, &req, ll_md_blocking_ast, 0);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
retval = ERR_PTR(rc);
goto out;
@@ -786,7 +786,7 @@ static int ll_new_node(struct inode *dir, struct dentry 
*dentry,
from_kuid(&init_user_ns, current_fsuid()),
from_kgid(&init_user_ns, current_fsgid()),
cfs_curproc_cap_pack(), rdev, &request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (err)
goto err_exit;
 
@@ -961,7 +961,7 @@ static int ll_unlink(struct inode *dir, struct dentry 
*dentry)
ll_get_child_fid(dentry, &op_data->op_fid3);
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc)
goto out;
 
@@ -1011,7 +1011,7 @@ static int ll_rmdir(struct inode *dir, struct dentry 
*dentry)
ll_get_child_fid(dentry, &op_data->op_fid3);
op_data->op_fid2 = op_data->op_fid3;
rc = md_unlink(ll_i2sbi(dir)->ll_md_exp, op_data, &request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc == 0) {
ll_update_times(request, dir);
ll_stats_ops_tally(ll_i2sbi(dir), LPROC_LL_RMDIR, 1);
@@ -1060,7 +1060,7 @@ static int ll_link(struct dentry *old_dentry, struct 
inode *dir,
return PTR_ERR(op_data);
 
err = md_link(sbi->ll_md_exp, op_data, &request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (err)
goto out;
 
@@ -1096,7 +1096,7 @@ static int ll_rename(struct inode *old_dir, struct dentry 
*old_dentry,
old_dentry->d_name.len,
new_dentry->d_name.name,
new_dentry->d_name.len, &request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (!err) {
ll_update_times(request, old_dir);
ll_update_times(request, new_dir);
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 3/4] dmaselftest: add memcpy selftest support functions

[Sinan Kaya]

On 11/9/2015 4:26 AM, Andy Shevchenko wrote:

On Mon, Nov 9, 2015 at 5:07 AM, Sinan Kaya  wrote:



On 11/8/2015 3:09 PM, Andy Shevchenko wrote:


On Sun, Nov 8, 2015 at 6:52 AM, Sinan Kaya  wrote:


This patch adds supporting utility functions
for selftest. The intention is to share the self
test code between different drivers.

Supported test cases include:
1. dma_map_single
2. streaming DMA
3. coherent DMA
4. scatter-gather DMA






+   u32 i, j = 0;


unsigned int


why?


Is i or j is going to be used for HW communication? No? What about
assignment to a values of type u32? No? Plain counters? Use plain
types.


OK. I did an internal code review before posting the patch. Nobody 
complained about iterator types. I am trying to find what goes as a good 
practice vs. what is personal style.




It's actually comment about your all patches I saw last week.


+   int err = 0;
+   int ret;



Any reason to have two instead of one of similar meaning?



removed ret


Don't forget to check if it's redundant assignment (check in all your
patches as well).



I'll look.

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] livepatch: old_name,number scheme in livepatch sysfs directory

[Josh Poimboeuf]

On Mon, Nov 09, 2015 at 05:01:18PM -0600, Chris J Arges wrote:
> On 11/09/2015 02:56 PM, Josh Poimboeuf wrote:
> > I'd recommend splitting this up into two separate patches:
> > 
> > 1. introduce old_sympos
> > 2. change the sysfs interface
> > 
> > On Mon, Nov 09, 2015 at 10:16:05AM -0600, Chris J Arges wrote:
> >> In cases of duplicate symbols in vmlinux, old_sympos will be used to
> >> disambiguate instead of old_addr. Normally old_sympos will be 0, and
> >> default to only returning the first found instance of that symbol. If an
> >> incorrect symbol position is specified then livepatching will fail.
> > 
> > In the case of old_sympos == 0, instead of just returning the first
> > symbol it finds, I think it should ensure that the symbol is unique.  As
> > Miroslav suggested:
> > 
> >   0 - default, preserve more or less current behaviour. If the symbol is 
> >   unique there is no problem. If it is not the patching would fail.
> >   1, 2, ... - occurrence of the symbol in kallsyms.
> >   
> >   The advantage is that if the user does not care and is certain that the 
> >   symbol is unique he doesn't have to do anything. If the symbol is not 
> >   unique he still has means how to solve it.
> > 
> 
> So one part that will be confusing here is as follows.
> 
> If '0' is specified for old_sympos, should the symbol be 'func_name,0'
> or 'func_name,1' provided we have a unique symbol? We could also default
> to 'what the user provides', but this seems odd.

I don't feel strongly either way, but I think using the same number the
user provides is fine, since it makes the sysfs interface consistent
with the old_sympos usage.

> Another option would be to use no postfix when 0 is given, and only
> introduce the ',n' postfix if old_sympos is > 0.

IMO always having a suffix is good, as it makes parsing less surprising
and less error-prone.

> >>  static int klp_write_object_relocations(struct module *pmod,
> >> @@ -307,7 +318,7 @@ static int klp_write_object_relocations(struct module 
> >> *pmod,
> >>else
> >>ret = klp_find_object_symbol(obj->mod->name,
> >> reloc->name,
> >> -   &reloc->val);
> >> +   &reloc->val, 0);
> > 
> > I think it would be a good idea to also add old_sympos to klp_reloc so
> > the relocation code is consistent with the klp_func symbol addressing.
> >
> 
> So you are thinking as an optional external field as well? I'll have to
> look at this a bit more but makes sense to me.

Yeah, the semantics would be the same as klp_func.old_sympos.  We could
add a new klp_reloc.sympos and make klp_reloc.val a private field.

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/8] Staging: lustre: file: Replace function calls with standard function

[Shivani Bhardwaj]

Replace the calls of the function ll_finish_md_op_data() with the
standard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
Changes in v2:
Fix commit message and merge a patch

 drivers/staging/lustre/lustre/llite/file.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/file.c 
b/drivers/staging/lustre/lustre/llite/file.c
index 02f2759..186b5af 100644
--- a/drivers/staging/lustre/lustre/llite/file.c
+++ b/drivers/staging/lustre/lustre/llite/file.c
@@ -202,7 +202,7 @@ static int ll_close_inode_openhandle(struct obd_export 
*md_exp,
rc = -EBUSY;
}
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
 out:
if (exp_connect_som(exp) && !epoch_close &&
@@ -420,7 +420,7 @@ static int ll_intent_file_open(struct dentry *dentry, void 
*lmm,
itp->it_flags |= MDS_OPEN_BY_FID;
rc = md_intent_lock(sbi->ll_md_exp, op_data, lmm, lmmsize, itp,
0 /*unused */, &req, ll_md_blocking_ast, 0);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc == -ESTALE) {
/* reason for keep own exit path - don`t flood log
* with messages with -ESTALE errors.
@@ -819,7 +819,7 @@ ll_lease_open(struct inode *inode, struct file *file, 
fmode_t fmode,
 * open in ll_md_blocking_ast(). Otherwise as ll_md_blocking_lease_ast
 * doesn't deal with openhandle, so normal openhandle will be leaked. */
LDLM_FL_NO_LRU | LDLM_FL_EXCL);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
ptlrpc_req_finished(req);
if (rc < 0)
goto out_release_it;
@@ -1393,7 +1393,7 @@ int ll_lov_getstripe_ea_info(struct inode *inode, const 
char *filename,
 
op_data->op_valid = OBD_MD_FLEASIZE | OBD_MD_FLDIREA;
rc = md_getattr_name(sbi->ll_md_exp, op_data, &req);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
CDEBUG(D_INFO, "md_getattr_name failed on %s: rc %d\n",
   filename, rc);
@@ -2056,7 +2056,7 @@ static int ll_swap_layouts(struct file *file1, struct 
file *file2,
 
rc = obd_iocontrol(LL_IOC_LOV_SWAP_LAYOUTS, ll_i2mdexp(llss->inode1),
   sizeof(*op_data), op_data, NULL);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
 putgl:
if (gid != 0) {
@@ -2131,7 +2131,7 @@ static int ll_hsm_state_set(struct inode *inode, struct 
hsm_state_set *hss)
rc = obd_iocontrol(LL_IOC_HSM_STATE_SET, ll_i2mdexp(inode),
   sizeof(*op_data), op_data, NULL);
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
return rc;
 }
@@ -2350,7 +2350,7 @@ ll_file_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
if (copy_to_user((void *)arg, hus, sizeof(*hus)))
rc = -EFAULT;
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
kfree(hus);
return rc;
}
@@ -2389,7 +2389,7 @@ ll_file_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
if (copy_to_user((char *)arg, hca, sizeof(*hca)))
rc = -EFAULT;
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
kfree(hca);
return rc;
}
@@ -2761,7 +2761,7 @@ ll_file_flock(struct file *file, int cmd, struct 
file_lock *file_lock)
rc = rc2;
}
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
return rc;
 }
@@ -2896,7 +2896,7 @@ static int __ll_inode_revalidate(struct dentry *dentry, 
__u64 ibits)
   based lookup */
&oit, 0, &req,
ll_md_blocking_ast, 0);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
oit.it_create_mode &= ~M_CHECK_STALE;
if (rc < 0) {
rc = ll_inode_revalidate_fini(inode, rc);
@@ -2938,7 +2938,7 @@ static int __ll_inode_revalidate(struct dentry *dentry, 
__u64 ibits)
 
op_data->op_valid = valid;
rc = md_getattr(sbi->ll_md_exp, op_data, &req);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc) {
rc = ll_inode_revalidate_fini(inode, rc);
return rc;
@@ -3533,7 +3533,7 @@ again:
ptlrpc_req_finished(it.d.lustre.it_data);
it.d.lustre.it_data = NULL;
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
mode = it.d.lustre.it_lock_mode;
it.d.lustre.it_lock_mode = 0;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

Re: [PATCH V2 2/3] scsi: fix compiler warning for sg

[Timur Tabi]

Sinan Kaya wrote:


The code says it is using these macros for small integers only which
can't overflow. I was trying to get rid of compiler warning and it seems
to have disappeared.


I would double-check the assembly code, if I were you.  I don't like it 
when warnings just go away like that.


Besides, we *should* be using do_div() for 64-bit division.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 1/8] Staging: lustre: dir: Replace function calls

[Shivani Bhardwaj]

Replace the calls of the function ll_finish_md_op_data() with the
standard function kfree().

Signed-off-by: Shivani Bhardwaj 
---
Changes in v2:
Fix commit message and merge a patch

 drivers/staging/lustre/lustre/llite/dir.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/lustre/lustre/llite/dir.c 
b/drivers/staging/lustre/lustre/llite/dir.c
index 5c2ef92..ba3f469 100644
--- a/drivers/staging/lustre/lustre/llite/dir.c
+++ b/drivers/staging/lustre/lustre/llite/dir.c
@@ -182,7 +182,7 @@ static int ll_dir_filler(void *_hash, struct page *page0)
op_data->op_npages = npages;
op_data->op_offset = hash;
rc = md_readpage(exp, op_data, page_pool, &request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
/* page0 is special, which was added into page cache early */
delete_from_page_cache(page0);
@@ -363,7 +363,7 @@ struct page *ll_get_dir_page(struct inode *dir, __u64 hash,
rc = md_enqueue(ll_i2sbi(dir)->ll_md_exp, &einfo, &it,
op_data, &lockh, NULL, 0, NULL, 0);
 
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
 
request = (struct ptlrpc_request *)it.d.lustre.it_data;
if (request)
@@ -669,7 +669,7 @@ static int ll_dir_setdirstripe(struct inode *dir, struct 
lmv_user_md *lump,
from_kuid(&init_user_ns, current_fsuid()),
from_kgid(&init_user_ns, current_fsgid()),
cfs_curproc_cap_pack(), 0, &request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (err)
goto err_exit;
 err_exit:
@@ -730,7 +730,7 @@ int ll_dir_setstripe(struct inode *inode, struct 
lov_user_md *lump,
/* swabbing is done in lov_setstripe() on server side */
rc = md_setattr(sbi->ll_md_exp, op_data, lump, lum_size,
NULL, 0, &req, NULL);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
ptlrpc_req_finished(req);
if (rc) {
if (rc != -EPERM && rc != -EACCES)
@@ -802,7 +802,7 @@ int ll_dir_getstripe(struct inode *inode, struct lov_mds_md 
**lmmp,
 
op_data->op_valid = OBD_MD_FLEASIZE | OBD_MD_FLDIREA;
rc = md_getattr(sbi->ll_md_exp, op_data, &req);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
CDEBUG(D_INFO, "md_getattr failed on inode %lu/%u: rc %d\n",
   inode->i_ino,
@@ -868,7 +868,7 @@ int ll_get_mdt_idx(struct inode *inode)
op_data->op_flags |= MF_GET_MDT_IDX;
rc = md_getattr(sbi->ll_md_exp, op_data, NULL);
mdtidx = op_data->op_mds;
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
CDEBUG(D_INFO, "md_getattr_name: %d\n", rc);
return rc;
@@ -1301,7 +1301,7 @@ static long ll_dir_ioctl(struct file *file, unsigned int 
cmd, unsigned long arg)
 
op_data->op_valid = OBD_MD_FLID;
rc = md_getattr_name(sbi->ll_md_exp, op_data, &request);
-   ll_finish_md_op_data(op_data);
+   kfree(op_data);
if (rc < 0) {
CDEBUG(D_INFO, "md_getattr_name: %d\n", rc);
goto out_free;
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/3] scsi: fix compiler warning for sg

[Sinan Kaya]

On 11/9/2015 10:26 PM, Timur Tabi wrote:

Sinan Kaya wrote:


I created this patch back in March with an older version of the compiler
and older kernel (3.19). I'm no longer able to reproduce this with this
compiler and linux-next.

Thread model: posix
gcc version 4.8.3 20140401 (prerelease) (crosstool-NG
linaro-1.13.1-4.8-2014.04 - Linaro GCC 4.8-2014.04)

I'll drop this patch.


Are you sure the compiler handles the old macro correctly?  Maybe it's
just quiescing the error message, but it's still broken?



The code says it is using these macros for small integers only which 
can't overflow. I was trying to get rid of compiler warning and it seems 
to have disappeared.


--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/8] Remove wrapper function and clean up the code

[Shivani Bhardwaj]

This patchset removes an unnecessary wrapper function, its prototype and
replaces all its calls in different files with the standard function
that it wraps.
After applying this patch, code becomes cleaner.

Changes in v2:
Fix commit message and merge a patch

Shivani Bhardwaj (8):
  Staging: lustre: dir: Replace function calls
  Staging: lustre: file: Replace function calls with standard function
  Staging: lustre: namei: Replace calls with kfree
  Staging: lustre: xattr_cache: Change function calls to kfree
  Staging: lustre: symlink: Substitute standard function
  Staging: lustre: llite_nfs: Replace function calls with kfree
  Staging: lustre: llite_close: Substitute function calls
  Staging: lustre: llite: Remove ll_finish_md_op_data wrapper

 drivers/staging/lustre/lustre/llite/dir.c  | 14 ++---
 drivers/staging/lustre/lustre/llite/file.c | 24 +++---
 drivers/staging/lustre/lustre/llite/llite_close.c  |  2 +-
 .../staging/lustre/lustre/llite/llite_internal.h   |  1 -
 drivers/staging/lustre/lustre/llite/llite_lib.c| 13 
 drivers/staging/lustre/lustre/llite/llite_nfs.c|  2 +-
 drivers/staging/lustre/lustre/llite/namei.c| 12 +--
 drivers/staging/lustre/lustre/llite/symlink.c  |  2 +-
 drivers/staging/lustre/lustre/llite/xattr_cache.c  |  2 +-
 9 files changed, 33 insertions(+), 39 deletions(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Dan,

On Mon, 9 Nov 2015 18:42:31 -0800 Dan Williams  wrote:
>
> On Mon, Nov 9, 2015 at 5:24 PM, Stephen Rothwell  
> wrote:
> >
> > Is that new stuff in the nvdimm tree really meant for v4.4?  If not,
> > please remove it until -rc1 has been released.  
> 
> Done.  I was indeed squeezing things into this window that I
> shouldn't.  I have postponed these conflicting patches to post 4.4.

Thanks for that.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V3 3/4] dmaselftest: add memcpy selftest support functions

[Sinan Kaya]

On 11/9/2015 8:48 AM, Timur Tabi wrote:

Sinan Kaya wrote:


And why kmalloc anyway?  Why not leave it on the stack?

 char src[] = "hello world";

?


I need to call dma_map_single on this address to convert it to a DMA
address. That's why.


And you can't do that with an object that's on the stack?



no, pasting from here.

https://www.kernel.org/doc/Documentation/DMA-API-HOWTO.txt

under 'What memory is DMA'able?'

This rule also means that you may use neither kernel image addresses
(items in data/text/bss segments), nor module image addresses, nor
stack addresses for DMA.

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 0/5] Arch-independent livepatch

[Jessica Yu]

This patchset removes livepatch's need for architecture-specific relocation
code by leveraging existing code in the module loader to perform
arch-dependent work. Specifically, instead of duplicating code and
re-implementing what the apply_relocate_add() function in the module loader
already does in livepatch's klp_write_module_reloc(), we reuse
apply_relocate_add() to write relocations. The hope is that this will make
livepatch more easily portable to other architectures and greatly reduce
the amount of arch-specific code required to port livepatch to a particular
architecture.

Background: Why does livepatch need to write its own relocations?
==
A typical livepatch module contains patched versions of functions that can
reference non-exported global symbols and non-included local symbols.
Relocations referencing these types of symbols cannot be left in as-is
since the kernel module loader cannot resolve them and will therefore
reject the livepatch module. Furthermore, we cannot apply relocations that
affect modules not loaded yet at run time (e.g. a patch to a driver). The
current kpatch build system therefore solves this problem by embedding
special "dynrela" (dynamic reloc) sections in the resulting patch module
elf output. Using these dynrela sections, livepatch can correctly resolve
symbols while taking into account its scope and what module the symbol
belongs to, and then manually apply the dynamic relocations.

Motivation: Why is having arch-dependent relocation code a problem?
==
The original motivation for this patchset stems from the increasing
roadblocks encountered while attempting to port livepatch to s390.
Specifically, there were problems dealing with s390 PLT and GOT relocation
types (R_390_{PLT,GOT}), which are handled differently from x86's
relocation types (which are much simpler to deal with, and a single
livepatch function (klp_write_module_reloc()) has been sufficient enough).
These s390 reloc types cannot be handled by simply performing a calculation
(as in the x86 case). For s390 modules with PLT/GOT relocations, the kernel
module loader allocates and fills in PLT+GOT table entries for every symbol
referenced by a PLT/GOT reloc in module core memory. So the problem of
porting livepatch to s390 became much more complicated than simply writing
an s390-specific klp_write_module_reloc() function. How can livepatch
handle these relocation types if the s390 module loader needs to allocate
and fill PLT/GOT entries ahead of time? The potential solutions were: 1)
have livepatch possibly allocate and maintain its own PLT/GOT tables for
every patch module (requiring even more arch-specific code), 2) modify the
s390 module loader heavily to accommodate livepatch modules (i.e. allocate
all the needed PLT/GOT entries for livepatch in advance but refrain from
applying relocations for to-be-patched modules), or 3) eliminate this
potential mess by leveraging module loader code to do all the relocation
work, letting livepatch off the hook completely. Solution #3 is what this
patchset implements.

How does this patchset remedy these problems?
==
Reusing the module loader code to perform livepatch relocations means that
livepatch no longer needs arch-specific reloc code and the aforementioned
problems with s390 PLT/GOT reloc types disappear (because we let the module
loader do all the relocation work for us). It will enable livepatch to be
more easily ported to other architectures.

Summary of proposed changes
==
This patch series enables livepatch to use the module loader's
apply_relocate_add() function to resolve livepatch relocations (i.e. what
used to be dynrelas). apply_relocate_add() requires access to a patch
module's section headers, symbol table, reloc section indices, etc., and all
of these are accessible through the load_info struct used in the module
loader. Therefore we persist this struct for livepatch modules and it is
made available through module->info.

The ELF-related changes enable livepatch to patch modules that are not
loaded yet. In order to use apply_relocate_add(), we need real SHT_RELA
sections to pass in. A complication here is that relocations for
not-yet-loaded modules should not be applied when the patch module loads;
they should only be applied once the target module is loaded. Thus kpatch
build scripts were modified to output a livepatch module that contains
special __klp_rela sections that correspond to the modules being patched.
They are marked with a special SHF_RELA_LIVEPATCH section flag to indicate
to the module loader that it should ignore that reloc section and that
livepatch will handle them. The SHN_LIVEPATCH shndx marks symbols that will
have to be resolved once their respective target module loads. So, the
module loader ignores these symbols (and does not attempt to resolve them).
Finally, the STB_LIVEPATCH_EXT symbol bind marks the scope of certain
livepatch symbols, so that livepatch can find the symbol in the right
place. These ELF constants were selected f

[RFC PATCH 4/5] samples: livepatch: init reloc list and mark as klp module

[Jessica Yu]

Intialize the list of relocation sections in the sample
klp_object (even if the list will be empty in this case).
Also mark module as a livepatch module so that the module
loader can appropriately initialize it.

Signed-off-by: Jessica Yu 
---
 samples/livepatch/livepatch-sample.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/samples/livepatch/livepatch-sample.c 
b/samples/livepatch/livepatch-sample.c
index fb8c861..2ef9345 100644
--- a/samples/livepatch/livepatch-sample.c
+++ b/samples/livepatch/livepatch-sample.c
@@ -57,6 +57,7 @@ static struct klp_object objs[] = {
{
/* name being NULL means vmlinux */
.funcs = funcs,
+   .reloc_secs = LIST_HEAD_INIT(objs[0].reloc_secs)
}, { }
 };
 
@@ -89,3 +90,4 @@ static void livepatch_exit(void)
 module_init(livepatch_init);
 module_exit(livepatch_exit);
 MODULE_LICENSE("GPL");
+MODULE_INFO(livepatch, "Y");
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 5/5] livepatch: x86: remove unused relocation code

[Jessica Yu]

Architecture-specific relocation code no longer needed, since symbol
resolution and relocation work will be offloaded to module loader.

Signed-off-by: Jessica Yu 
---
 arch/x86/kernel/Makefile|  1 -
 arch/x86/kernel/livepatch.c | 91 -
 2 files changed, 92 deletions(-)
 delete mode 100644 arch/x86/kernel/livepatch.c

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index b1b78ff..c5e9a5c 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -67,7 +67,6 @@ obj-$(CONFIG_X86_MPPARSE) += mpparse.o
 obj-y  += apic/
 obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
 obj-$(CONFIG_DYNAMIC_FTRACE)   += ftrace.o
-obj-$(CONFIG_LIVEPATCH)+= livepatch.o
 obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
 obj-$(CONFIG_FTRACE_SYSCALLS)  += ftrace.o
 obj-$(CONFIG_X86_TSC)  += trace_clock.o
diff --git a/arch/x86/kernel/livepatch.c b/arch/x86/kernel/livepatch.c
deleted file mode 100644
index d1d35cc..000
--- a/arch/x86/kernel/livepatch.c
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * livepatch.c - x86-specific Kernel Live Patching Core
- *
- * Copyright (C) 2014 Seth Jennings 
- * Copyright (C) 2014 SUSE
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-/**
- * klp_write_module_reloc() - write a relocation in a module
- * @mod:   module in which the section to be modified is found
- * @type:  ELF relocation type (see asm/elf.h)
- * @loc:   address that the relocation should be written to
- * @value: relocation value (sym address + addend)
- *
- * This function writes a relocation to the specified location for
- * a particular module.
- */
-int klp_write_module_reloc(struct module *mod, unsigned long type,
-  unsigned long loc, unsigned long value)
-{
-   int ret, numpages, size = 4;
-   bool readonly;
-   unsigned long val;
-   unsigned long core = (unsigned long)mod->module_core;
-   unsigned long core_size = mod->core_size;
-
-   switch (type) {
-   case R_X86_64_NONE:
-   return 0;
-   case R_X86_64_64:
-   val = value;
-   size = 8;
-   break;
-   case R_X86_64_32:
-   val = (u32)value;
-   break;
-   case R_X86_64_32S:
-   val = (s32)value;
-   break;
-   case R_X86_64_PC32:
-   val = (u32)(value - loc);
-   break;
-   default:
-   /* unsupported relocation type */
-   return -EINVAL;
-   }
-
-   if (loc < core || loc >= core + core_size)
-   /* loc does not point to any symbol inside the module */
-   return -EINVAL;
-
-   readonly = false;
-
-#ifdef CONFIG_DEBUG_SET_MODULE_RONX
-   if (loc < core + mod->core_ro_size)
-   readonly = true;
-#endif
-
-   /* determine if the relocation spans a page boundary */
-   numpages = ((loc & PAGE_MASK) == ((loc + size) & PAGE_MASK)) ? 1 : 2;
-
-   if (readonly)
-   set_memory_rw(loc & PAGE_MASK, numpages);
-
-   ret = probe_kernel_write((void *)loc, &val, size);
-
-   if (readonly)
-   set_memory_ro(loc & PAGE_MASK, numpages);
-
-   return ret;
-}
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 2/5] module: save load_info for livepatch modules

[Jessica Yu]

In livepatch modules, preserve section, symbol, string information from
the load_info struct in the module loader. This information is used to
patch modules that are not loaded in memory yet; specifically it is used
to resolve remaining symbols and write relocations when the target
module loads.

Signed-off-by: Jessica Yu 
---
 include/linux/module.h  | 25 +
 kernel/livepatch/core.c | 17 +
 kernel/module.c | 36 ++--
 3 files changed, 64 insertions(+), 14 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 3a19c79..c8680b1 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -36,6 +36,20 @@ struct modversion_info {
char name[MODULE_NAME_LEN];
 };
 
+struct load_info {
+   Elf_Ehdr *hdr;
+   unsigned long len;
+   Elf_Shdr *sechdrs;
+   char *secstrings, *strtab;
+   unsigned long symoffs, stroffs;
+   struct _ddebug *debug;
+   unsigned int num_debug;
+   bool sig_ok;
+   struct {
+   unsigned int sym, str, mod, vers, info, pcpu;
+   } index;
+};
+
 struct module;
 
 struct module_kobject {
@@ -462,6 +476,8 @@ struct module {
 
 #ifdef CONFIG_LIVEPATCH
bool klp_alive;
+   /* save info to patch to-be-loaded modules */
+   struct load_info *info;
 #endif
 
 #ifdef CONFIG_MODULE_UNLOAD
@@ -635,6 +651,15 @@ static inline bool module_requested_async_probing(struct 
module *module)
return module && module->async_probe_requested;
 }
 
+#ifdef CONFIG_LIVEPATCH
+extern void klp_prepare_patch_module(struct module *mod,
+struct load_info *info);
+extern int
+apply_relocate_add(Elf64_Shdr *sechdrs, const char *strtab,
+  unsigned int symindex, unsigned int relsec,
+  struct module *me);
+#endif
+
 #else /* !CONFIG_MODULES... */
 
 /* Given an address, look for it in the exception tables. */
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 6e53441..087a8c7 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -1001,6 +1001,23 @@ static struct notifier_block klp_module_nb = {
.priority = INT_MIN+1, /* called late but before ftrace notifier */
 };
 
+/*
+ * Save necessary information from info in order to be able to
+ * patch modules that might be loaded later
+ */
+void klp_prepare_patch_module(struct module *mod, struct load_info *info)
+{
+   Elf_Shdr *symsect;
+
+   symsect = info->sechdrs + info->index.sym;
+   /* update sh_addr to point to symtab */
+   symsect->sh_addr = (unsigned long)info->hdr + symsect->sh_offset;
+
+   mod->info = kzalloc(sizeof(*info), GFP_KERNEL);
+   memcpy(mod->info, info, sizeof(*info));
+
+}
+
 static int __init klp_init(void)
 {
int ret;
diff --git a/kernel/module.c b/kernel/module.c
index 8f051a1..8ae3ca5 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -318,20 +318,6 @@ int unregister_module_notifier(struct notifier_block *nb)
 }
 EXPORT_SYMBOL(unregister_module_notifier);
 
-struct load_info {
-   Elf_Ehdr *hdr;
-   unsigned long len;
-   Elf_Shdr *sechdrs;
-   char *secstrings, *strtab;
-   unsigned long symoffs, stroffs;
-   struct _ddebug *debug;
-   unsigned int num_debug;
-   bool sig_ok;
-   struct {
-   unsigned int sym, str, mod, vers, info, pcpu;
-   } index;
-};
-
 /* We require a truly strong try_module_get(): 0 means failure due to
ongoing or failed initialization etc. */
 static inline int strong_try_module_get(struct module *mod)
@@ -2137,6 +2123,11 @@ static int simplify_symbols(struct module *mod, const 
struct load_info *info)
   (long)sym[i].st_value);
break;
 
+#ifdef CONFIG_LIVEPATCH
+   case SHN_LIVEPATCH:
+   break;
+#endif
+
case SHN_UNDEF:
ksym = resolve_symbol_wait(mod, info, name);
/* Ok if resolved.  */
@@ -2185,6 +2176,11 @@ static int apply_relocations(struct module *mod, const 
struct load_info *info)
if (!(info->sechdrs[infosec].sh_flags & SHF_ALLOC))
continue;
 
+#ifdef CONFIG_LIVEPATCH
+   if (info->sechdrs[i].sh_flags & SHF_RELA_LIVEPATCH)
+   continue;
+#endif
+
if (info->sechdrs[i].sh_type == SHT_REL)
err = apply_relocate(info->sechdrs, info->strtab,
 info->index.sym, i, mod);
@@ -3530,8 +3526,20 @@ static int load_module(struct load_info *info, const 
char __user *uargs,
if (err < 0)
goto bug_cleanup;
 
+#ifdef CONFIG_LIVEPATCH
+   /*
+* Save sechdrs, indices, and other data from info
+* in order to patch to-be-loaded modules.
+* Do not call free_copy() for livepatch modules.
+*/
+ 

[RFC PATCH 1/5] elf: add livepatch-specific elf constants

[Jessica Yu]

Add livepatch elf reloc section flag, livepatch symbol bind
and section index

Signed-off-by: Jessica Yu 
---
 include/uapi/linux/elf.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index 71e1d0e..967ce1b 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -118,6 +118,7 @@ typedef __s64   Elf64_Sxword;
 #define STB_LOCAL  0
 #define STB_GLOBAL 1
 #define STB_WEAK   2
+#define STB_LIVEPATCH_EXT 11
 
 #define STT_NOTYPE  0
 #define STT_OBJECT  1
@@ -286,6 +287,7 @@ typedef struct elf64_phdr {
 #define SHF_ALLOC  0x2
 #define SHF_EXECINSTR  0x4
 #define SHF_MASKPROC   0xf000
+#define SHF_RELA_LIVEPATCH  0x400
 
 /* special section indexes */
 #define SHN_UNDEF  0
@@ -295,6 +297,7 @@ typedef struct elf64_phdr {
 #define SHN_ABS0xfff1
 #define SHN_COMMON 0xfff2
 #define SHN_HIRESERVE  0x
+#define SHN_LIVEPATCH 0xff21
  
 typedef struct elf32_shdr {
   Elf32_Word   sh_name;
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] nbd: Remove signal usage

[Al Viro]

On Thu, Oct 29, 2015 at 04:42:37PM +0100, Markus Pargmann wrote:
>   del_timer_sync(&nbd->timeout_timer);
> +
> +out:
> + spin_unlock_irq(&nbd->sock_lock);

... and in its callback we have this:

> @@ -148,17 +155,15 @@ static void nbd_xmit_timeout(unsigned long arg)
>  
>   nbd->disconnect = true;
>  
> - spin_lock_irqsave(&nbd->tasks_lock, flags);
> + spin_lock_irqsave(&nbd->sock_lock, flags);

* CPU 1 enters sock_shutdown() and grabs ->sock_lock.
* on CPU2 the timer hits and we enter the callback, where we spin on that
spinlock.
* in the meanwhile, CPU1 calls del_timer_sync()

Deadlock...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC PATCH 3/5] livepatch: reuse module loader code to write relocations

[Jessica Yu]

Reuse module loader code to write relocations, thereby eliminating the
need for architecture specific code in livepatch. Namely, we reuse
apply_relocate_add() in the module loader to write relocs instead of
duplicating functionality in livepatch's klp_write_module_reloc(). To
apply relocation sections, remaining SHN_LIVEPATCH symbols referenced by
relocs are resolved and then apply_relocate_add() is called to apply
those relocations.

Signed-off-by: Jessica Yu 
---
 include/linux/livepatch.h | 11 --
 include/linux/module.h|  6 
 kernel/livepatch/core.c   | 89 +--
 3 files changed, 70 insertions(+), 36 deletions(-)

diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 31db7a0..601e892 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -85,7 +85,7 @@ struct klp_reloc {
 /**
  * struct klp_object - kernel object structure for live patching
  * @name:  module name (or NULL for vmlinux)
- * @relocs:relocation entries to be applied at load time
+ * @reloc_secs:relocation sections to be applied at load time
  * @funcs: function entries for functions to be patched in the object
  * @kobj:  kobject for sysfs resources
  * @mod:   kernel module associated with the patched object
@@ -95,7 +95,7 @@ struct klp_reloc {
 struct klp_object {
/* external */
const char *name;
-   struct klp_reloc *relocs;
+   struct list_head reloc_secs;
struct klp_func *funcs;
 
/* internal */
@@ -129,6 +129,13 @@ struct klp_patch {
 #define klp_for_each_func(obj, func) \
for (func = obj->funcs; func->old_name; func++)
 
+struct klp_reloc_sec {
+   unsigned int index;
+   char *name;
+   char *objname;
+   struct list_head list;
+};
+
 int klp_register_patch(struct klp_patch *);
 int klp_unregister_patch(struct klp_patch *);
 int klp_enable_patch(struct klp_patch *);
diff --git a/include/linux/module.h b/include/linux/module.h
index c8680b1..3c34eb8 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -793,9 +793,15 @@ extern int module_sysfs_initialized;
 #ifdef CONFIG_DEBUG_SET_MODULE_RONX
 extern void set_all_modules_text_rw(void);
 extern void set_all_modules_text_ro(void);
+extern void
+set_page_attributes(void *start, void *end,
+   int (*set)(unsigned long start, int num_pages));
 #else
 static inline void set_all_modules_text_rw(void) { }
 static inline void set_all_modules_text_ro(void) { }
+static inline void
+set_page_attributes(void *start, void *end,
+   int (*set)(unsigned long start, int num_pages)) { }
 #endif
 
 #ifdef CONFIG_GENERIC_BUG
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 087a8c7..26c419f 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /**
  * struct klp_ops - structure for tracking registered ftrace ops structs
@@ -281,46 +283,54 @@ static int klp_find_external_symbol(struct module *pmod, 
const char *name,
 }
 
 static int klp_write_object_relocations(struct module *pmod,
-   struct klp_object *obj)
+   struct klp_object *obj,
+   struct klp_patch *patch)
 {
-   int ret;
-   struct klp_reloc *reloc;
+   int relindex, num_relas;
+   int i, ret = 0;
+   unsigned long addr;
+   unsigned int bind;
+   char *symname;
+   struct klp_reloc_sec *reloc_sec;
+   struct load_info *info;
+   Elf_Rela *rela;
+   Elf_Sym *sym, *symtab;
+   Elf_Shdr *symsect;
 
if (WARN_ON(!klp_is_object_loaded(obj)))
return -EINVAL;
 
-   if (WARN_ON(!obj->relocs))
-   return -EINVAL;
-
-   for (reloc = obj->relocs; reloc->name; reloc++) {
-   if (!klp_is_module(obj)) {
-   ret = klp_verify_vmlinux_symbol(reloc->name,
-   reloc->val);
-   if (ret)
-   return ret;
-   } else {
-   /* module, reloc->val needs to be discovered */
-   if (reloc->external)
-   ret = klp_find_external_symbol(pmod,
-  reloc->name,
-  &reloc->val);
-   else
-   ret = klp_find_object_symbol(obj->mod->name,
-reloc->name,
-&reloc->val);
-   if (ret)
-   return ret;
-   }
-   ret = klp_write_module_reloc(pmod, reloc->type, reloc->loc,
-   

Re: [PATCH V3 4/4] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

On 11/9/2015 1:19 PM, Rob Herring wrote:

On Sat, Nov 07, 2015 at 11:53:00PM -0500, Sinan Kaya wrote:

This patch adds support for hidma engine. The driver
consists of two logical blocks. The DMA engine interface
and the low-level interface. The hardware only supports
memcpy/memset and this driver only support memcpy
interface. HW and driver doesn't support slave interface.

Signed-off-by: Sinan Kaya 
---
  .../devicetree/bindings/dma/qcom_hidma.txt |  18 +
  drivers/dma/qcom/Kconfig   |   9 +
  drivers/dma/qcom/Makefile  |   2 +
  drivers/dma/qcom/hidma.c   | 743 
  drivers/dma/qcom/hidma.h   | 157 
  drivers/dma/qcom/hidma_dbg.c   | 225 +
  drivers/dma/qcom/hidma_ll.c| 944 +
  7 files changed, 2098 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
  create mode 100644 drivers/dma/qcom/hidma.c
  create mode 100644 drivers/dma/qcom/hidma.h
  create mode 100644 drivers/dma/qcom/hidma_dbg.c
  create mode 100644 drivers/dma/qcom/hidma_ll.c

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt 
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..c9fb2d44
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma"


This should be "qcom,hidma-1.0" to match the example and driver. I
would drop "qcom,hidma" altogether.


I matched it.



Rob



--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] of: Check for overlap in reserved memory regions

[Rob Herring]

On Mon, Nov 9, 2015 at 10:29 PM, Michael Ellerman  wrote:
> On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:
>
>> Any overlap in the reserved memory regions (those specified in the
>> reserved-memory DT node) is a bug.  These bugs might go undetected as
>> long as the contested region isn't used simultaneously by multiple
>> software agents, which makes such bugs hard to debug.  Fix this by
>> printing a scary warning during boot if overlap is detected.
>>
>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>> index 726ebe792813..62f467b8ccae 100644
>> --- a/drivers/of/of_reserved_mem.c
>> +++ b/drivers/of/of_reserved_mem.c
>> @@ -197,12 +198,52 @@ static int __init __reserved_mem_init_node(struct 
>> reserved_mem *rmem)
>>   return -ENOENT;
>>  }
>>
>> +static int __init __rmem_cmp(const void *a, const void *b)
>> +{
>> + const struct reserved_mem *ra = a, *rb = b;
>> +
>> + return ra->base - rb->base;
>> +}
>> +
>> +static void __init __rmem_check_for_overlap(void)
>> +{
>> + int i;
>> +
>> + if (reserved_mem_count < 2)
>> + return;
>> +
>> + sort(reserved_mem, reserved_mem_count, sizeof(reserved_mem[0]),
>> +  __rmem_cmp, NULL);
>> + for (i = 0; i < reserved_mem_count - 1; i++) {
>> + struct reserved_mem *this, *next;
>> +
>> + this = &reserved_mem[i];
>> + next = &reserved_mem[i + 1];
>> + if (!(this->base && next->base))
>> + continue;
>> + if (this->base + this->size > next->base) {
>> + phys_addr_t this_end, next_end;
>> +
>> + this_end = this->base + this->size;
>> + next_end = next->base + next->size;
>> + WARN(1,
>> +  "Reserved memory: OVERLAP DETECTED!\n%s 
>> (%pa--%pa) overlaps with %s (%pa--%pa)\n",
>> +  this->name, &this->base, &this_end,
>> +  next->name, &next->base, &next_end);
>
> This is blowing up on some powerpc machines.
>
> It's too early in boot to call WARN() on these systems.

I didn't realize WARN could not be used early. Good to know.

> Can we turn it into a pr_err() for now?

Sounds fine.

> I'll send a patch?

Great.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] of: Check for overlap in reserved memory regions

[Michael Ellerman]

On Tue, 2015-09-15 at 18:30 -0700, Mitchel Humpherys wrote:

> Any overlap in the reserved memory regions (those specified in the
> reserved-memory DT node) is a bug.  These bugs might go undetected as
> long as the contested region isn't used simultaneously by multiple
> software agents, which makes such bugs hard to debug.  Fix this by
> printing a scary warning during boot if overlap is detected.
> 
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> index 726ebe792813..62f467b8ccae 100644
> --- a/drivers/of/of_reserved_mem.c
> +++ b/drivers/of/of_reserved_mem.c
> @@ -197,12 +198,52 @@ static int __init __reserved_mem_init_node(struct 
> reserved_mem *rmem)
>   return -ENOENT;
>  }
>  
> +static int __init __rmem_cmp(const void *a, const void *b)
> +{
> + const struct reserved_mem *ra = a, *rb = b;
> +
> + return ra->base - rb->base;
> +}
> +
> +static void __init __rmem_check_for_overlap(void)
> +{
> + int i;
> +
> + if (reserved_mem_count < 2)
> + return;
> +
> + sort(reserved_mem, reserved_mem_count, sizeof(reserved_mem[0]),
> +  __rmem_cmp, NULL);
> + for (i = 0; i < reserved_mem_count - 1; i++) {
> + struct reserved_mem *this, *next;
> +
> + this = &reserved_mem[i];
> + next = &reserved_mem[i + 1];
> + if (!(this->base && next->base))
> + continue;
> + if (this->base + this->size > next->base) {
> + phys_addr_t this_end, next_end;
> +
> + this_end = this->base + this->size;
> + next_end = next->base + next->size;
> + WARN(1,
> +  "Reserved memory: OVERLAP DETECTED!\n%s (%pa--%pa) 
> overlaps with %s (%pa--%pa)\n",
> +  this->name, &this->base, &this_end,
> +  next->name, &next->base, &next_end);

This is blowing up on some powerpc machines.

It's too early in boot to call WARN() on these systems.

Can we turn it into a pr_err() for now?

I'll send a patch?

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] module: clean up RO/NX handling.

[Josh Poimboeuf]

On Tue, Nov 10, 2015 at 12:27:34PM +1030, Rusty Russell wrote:
> Josh Poimboeuf  writes:
> > On Mon, Nov 09, 2015 at 02:53:57PM +1030, Rusty Russell wrote:
> >
> >> @@ -1858,74 +1849,75 @@ static void mod_sysfs_teardown(struct module *mod)
> >>  /*
> >>   * LKM RO/NX protection: protect module's text/ro-data
> >>   * from modification and any data from execution.
> >> + *
> >> + * General layout of module is:
> >> + *  [text] [read-only-data] [writable data]
> >> + * text_size -^^   ^
> >> + * ro_size |   |
> >> + * size ---|
> >> + *
> >> + * These values are always page-aligned (as is base)
> >>   */
> >> -void set_page_attributes(void *start, void *end, int (*set)(unsigned long 
> >> start, int num_pages))
> >> +static void frob_text(const struct module_layout *layout,
> >> +int (*set_memory)(unsigned long start, int num_pages))
> >>  {
> >> -  unsigned long begin_pfn = PFN_DOWN((unsigned long)start);
> >> -  unsigned long end_pfn = PFN_DOWN((unsigned long)end);
> >> -
> >> -  if (end_pfn > begin_pfn)
> >> -  set(begin_pfn << PAGE_SHIFT, end_pfn - begin_pfn);
> >> +  BUG_ON((unsigned long)layout->base & (PAGE_SIZE-1));
> >> +  BUG_ON((unsigned long)layout->text_size & (PAGE_SIZE-1));
> >> +  set_memory((unsigned long)layout->base,
> >> + layout->text_size >> PAGE_SHIFT);
> >
> > Should the set_memory() call be skipped if text_size is 0?
> 
> Not AFAICT.  And in practice:
> 1) Every module on my system has a .text section.
> 2) Every module has a rodata section (.modinfo)
> 3) Every module on my system has a .data section.
> 
> So I think it would be a premature optimization.

However, the frob functions are also used for init sections.

A search on my Fedora system's modules for .init.* sections shows that
most modules don't have .init.rodata and .init.data, and some modules
don't even have .init.text.

-- 
Josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 03/11] lsm: add file opener's cred to a setprocattr arguments

[Al Viro]

On Wed, Oct 14, 2015 at 02:41:57PM +0200, Lukasz Pawelczyk wrote:
>   int (*getprocattr)(struct task_struct *p, char *name, char **value);
> - int (*setprocattr)(struct task_struct *p, char *name, void *value,
> - size_t size);
> + int (*setprocattr)(struct task_struct *p, const struct cred *f_cred,
> +char *name, void *value, size_t size);

*grumble*

Why the hell is that thing taking char *name - not even const char *?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: unisys: visorbus: visorbus_main.c: made checkpatch warning-free

[Gavin O'Leary]

Made visorbus_main.c checkpatch warning-free by fixing the comment style
issues.

Signed-off-by: Gavin O'Leary 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index a272b48..eac97d2 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1078,7 +1078,8 @@ away:
 }
 
 /* Write the contents of  to the struct
- * spar_vbus_channel_protocol.chp_info. */
+ * spar_vbus_channel_protocol.chp_info.
+ */
 
 static int
 write_vbus_chp_info(struct visorchannel *chan,
@@ -1096,7 +1097,8 @@ write_vbus_chp_info(struct visorchannel *chan,
 }
 
 /* Write the contents of  to the struct
- * spar_vbus_channel_protocol.bus_info. */
+ * spar_vbus_channel_protocol.bus_info.
+ */
 
 static int
 write_vbus_bus_info(struct visorchannel *chan,
@@ -1370,7 +1372,8 @@ pause_state_change_complete(struct visor_device *dev, int 
status)
 
/* Notify the chipset driver that the pause is complete, which
* will presumably want to send some sort of response to the
-   * initiator. */
+   * initiator.
+   */
(*chipset_responders.device_pause) (dev, status);
 }
 
@@ -1390,7 +1393,8 @@ resume_state_change_complete(struct visor_device *dev, 
int status)
 
/* Notify the chipset driver that the resume is complete,
 * which will presumably want to send some sort of response to
-* the initiator. */
+* the initiator.
+*/
(*chipset_responders.device_resume) (dev, status);
 }
 
@@ -1437,7 +1441,8 @@ initiate_chipset_device_pause_resume(struct visor_device 
*dev, bool is_pause)
 * existing problem prevents us from ever getting a bus
 * resume...  This hack would fail to work should we
 * ever have a bus that contains NO devices, since we
-* would never even get here in that case. */
+* would never even get here in that case.
+*/
fix_vbus_dev_info(dev);
if (!drv->resume)
goto away;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tpm: fix compat 'ppi' link handling in tpm_chip_register()

[Jarkko Sakkinen]

On Mon, Nov 09, 2015 at 03:47:20PM -0700, Jason Gunthorpe wrote:
> On Sun, Nov 08, 2015 at 09:51:07AM +0200, Jarkko Sakkinen wrote:
> > +   if (rc && rc != -ENOENT) {
> > +   tpm_chip_unregister(chip);
> > +   return rc;
> > +   }
> > +   }
> 
> This is still goofy looking, the list_add_tail_rcu should be the last
> thing done and cannot fail. Just code this with the usual goto based
> unwind and goto to do tpm_dev_del_device for the above failure.

Agreed that this would be cleaner.

> > +
> > return 0;
> >  out_err:
> > tpm1_chip_unregister(chip);
> 
> Which avoids calling tpm1_chip_unregister and tpm_chip_unregister in
> the same function, which looks so wrong to a casual read..

I'm not going to change the current patch at this point of release
cycle but this clean up definitely makes sense later on.

> Jason

/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 2/3] pinctrl: e3xx: Adding support for NI Ettus Research USRP E3xx pinconf

[Moritz Fischer]

Linus,

Thanks for your review!

On Mon, Nov 9, 2015 at 2:21 AM, Linus Walleij  wrote:
> On Fri, Nov 6, 2015 at 12:41 AM, Moritz Fischer
>  wrote:
>
>> The USRP E3XX series requires pinctrl to configure the idle state
>> FPGA image for minimizing power consumption.
>> This is required since different daughtercards have different uses
>> for pins on a common connector.
>>
>> Signed-off-by: Moritz Fischer 
> (...)
>
>> +static const struct pinctrl_pin_desc e3xx_pins[] = {
>> +   /* pin0 doesn't exist */
>> +   PINCTRL_PIN(1, "DB_1"),
>> +   PINCTRL_PIN(2, "DB_2"),
> (...)
>> +   PINCTRL_PIN(119, "DB_119"),
>> +   PINCTRL_PIN(120, "DB_120"),
>> +};
>
> These should be the names on the data sheet for the balls/pins on the ASIC.
> Is this the case? I saw some discussion with Arnd that indicated it was
> rather rail names for a certain board and that is not OK.

Well so the chip is an FPGA, so in theory you can connect any logic
inside to (almost)
any ball on the outside (at design time). In our case we have a
daughter-board slot that gives
different meanings to what I call DB_1-DB_120. The pinctrl chip is a
soft-core in that FPGA.
Are you suggesting to use the balls of the FPGA as pin names instead?

>> +static int e3xx_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
>> +{
>> +   return 0;
>> +}
>> +
>> +static const char *e3xx_pinctrl_get_group_name(struct pinctrl_dev *pctldev,
>> +  unsigned selector)
>> +{
>> +   return NULL;
>> +}
>> +
>> +static int e3xx_pinctrl_get_group_pins(struct pinctrl_dev *pctldev,
>> +  unsigned selector,
>> +  const unsigned **pins,
>> +  unsigned *num_pins)
>> +{
>> +   return -ENOTSUPP;
>> +}
>
> Hm maybe we should make these group callbacks optional
> in the pinctrl core?

I'll submit a patchset separately, seems like a good idea.
>
>> +static int e3xx_pinconf_cfg_set(struct pinctrl_dev *pctldev,
>> +   unsigned pin,daughterboard
>> +   unsigned long *configs,
>> +   unsigned num_configs)
>> +{
>> +   u32 reg, mask;
>> +   int i;
>> +   struct e3xx_pinctrl *pctrl;
>> +   unsigned int param, arg;
>> +
>> +   if (pin >= E3XX_NUM_DB_PINS)
>> +   return -ENOTSUPP;
>> +   mask = BIT(pin % E3XX_PINS_PER_REG);
>> +
>> +   pctrl = pinctrl_dev_get_drvdata(pctldev);
>> +
>> +   clk_enable(pctrl->clk);
>
> Have you considered using pm_runtime_get_sync() etc with
> callbacks instead of hammering clk_enable/disable all the
> time? See
> drivers/hwtracing/coresight/coresight-replicator.c
> for an example of how to do it in the runtime PM ops
> callbacks. It requires some tweaks (look closely at all setup
> there) but it pays off.

Thanks for the pointer, I'll take a look.

>> +static int e3xx_pinconf_group_set(struct pinctrl_dev *pctldev,
>> + unsigned selector,
>> + unsigned long *configs,
>> + unsigned num_configs)
>> +{
>> +   return -EAGAIN;
>> +}
>
> Maybe you should group this with the other group callbacks.

Will do.
>
> Apart from these remarks it looks pretty nice.

While testing I found some more (minor) issues, that I'll need to iron out
before I submit a real patch. In my cover letter I had a question about
how to deal with a situation where I'm exclusively either input or output,
Any suggestions on the correct semantics for expressing that?
The documentation seems to indicate that 'input-enable' *must not* influence
the output of a pin. How do I reconfigure a output to no longer be an output?

Cheers,

Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] power: bq27xxx_battery: Add I2C module check dependency in Kconfig

[Sebastian Reichel]

Hi,

On Mon, Nov 09, 2015 at 03:23:03PM -0600, Andrew F. Davis wrote:
> Check if I2C core has been built as a module when BATTERY_BQ27XXX
> is built-in. If so disable I2C functionality.
> 
> Fixes: 6bd03ce3c12a ("power: bq27xxx_battery: Remove unneeded dependency in 
> Kconfig")
> Reported-by: Arnd Bergmann 
> Signed-off-by: Andrew F. Davis 

Thanks, queued.

-- Sebastian


signature.asc
Description: PGP signature

Re: [PATCH v3 08/32] scsi: hisi_sas: add hisi_sas_remove

[Wei Fang]

Hi John,

On 2015/11/10 0:32, John Garry wrote:
> This patch also includes relevant memory/pool
> free'ing and sas/scsi host removal
> 
> Signed-off-by: John Garry 
> ---
>  drivers/scsi/hisi_sas/hisi_sas_main.c | 71 
> ++-
>  1 file changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c 
> b/drivers/scsi/hisi_sas/hisi_sas_main.c
> index 97f5368..7f81000 100644
> --- a/drivers/scsi/hisi_sas/hisi_sas_main.c
> +++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
> @@ -126,6 +126,59 @@ err_out:
>   return -ENOMEM;
>  }
>  
> +static void hisi_sas_free(struct hisi_hba *hisi_hba)
> +{
> + struct device *dev = &hisi_hba->pdev->dev;
> + int i, s;
> +
> + for (i = 0; i < hisi_hba->queue_count; i++) {
> + s = sizeof(struct hisi_sas_cmd_hdr) * HISI_SAS_QUEUE_SLOTS;
> + if (hisi_hba->cmd_hdr[i])
> + dma_free_coherent(dev, s,
> +   hisi_hba->cmd_hdr[i],
> +   hisi_hba->cmd_hdr_dma[i]);
> +
> + s = hisi_hba->hw->complete_hdr_size * HISI_SAS_QUEUE_SLOTS;
> + if (hisi_hba->complete_hdr[i])
> + dma_free_coherent(dev, s,
> +   hisi_hba->complete_hdr[i],
> +   hisi_hba->complete_hdr_dma[i]);
> + }
> +
> + dma_pool_destroy(hisi_hba->status_buffer_pool);
> + dma_pool_destroy(hisi_hba->command_table_pool);
> + dma_pool_destroy(hisi_hba->sge_page_pool);
> +
> + s = HISI_SAS_MAX_ITCT_ENTRIES * sizeof(struct hisi_sas_itct);
> + if (hisi_hba->itct)
> + dma_free_coherent(dev, s,
> +   hisi_hba->itct, hisi_hba->itct_dma);
> +
> + s = HISI_SAS_COMMAND_ENTRIES * sizeof(struct hisi_sas_iost);
> + if (hisi_hba->iost)
> + dma_free_coherent(dev, s,
> +   hisi_hba->iost, hisi_hba->iost_dma);
> +
> + s = HISI_SAS_COMMAND_ENTRIES * sizeof(struct hisi_sas_breakpoint);
> + if (hisi_hba->breakpoint)
> + dma_free_coherent(dev, s,
> +   hisi_hba->breakpoint,
> +   hisi_hba->breakpoint_dma);
> +
> +
> + s = sizeof(struct hisi_sas_initial_fis) * HISI_SAS_MAX_PHYS;
> + if (hisi_hba->initial_fis)
> + dma_free_coherent(dev, s,
> +   hisi_hba->initial_fis,
> +   hisi_hba->initial_fis_dma);
> +
> + s = HISI_SAS_COMMAND_ENTRIES * sizeof(struct hisi_sas_breakpoint) * 2;
> + if (hisi_hba->sata_breakpoint)
> + dma_free_coherent(dev, s,
> +   hisi_hba->sata_breakpoint,
> +   hisi_hba->sata_breakpoint_dma);
> +
> +}
>  
>  static struct Scsi_Host *hisi_sas_shost_alloc(struct platform_device *pdev,
> const struct hisi_sas_hw *hw)
> @@ -188,8 +241,10 @@ static struct Scsi_Host *hisi_sas_shost_alloc(struct 
> platform_device *pdev,
>   if (IS_ERR(hisi_hba->ctrl))
>   goto err_out;
>  
> - if (hisi_sas_alloc(hisi_hba, shost))
> + if (hisi_sas_alloc(hisi_hba, shost)) {
> + hisi_sas_free(hisi_hba);
>   goto err_out;
> + }
>  
>   return shost;
>  err_out:
> @@ -270,6 +325,20 @@ err_out_ha:
>  }
>  EXPORT_SYMBOL_GPL(hisi_sas_probe);
>  
> +int hisi_sas_remove(struct platform_device *pdev)
> +{
> + struct sas_ha_struct *sha = platform_get_drvdata(pdev);
> + struct hisi_hba *hisi_hba = sha->lldd_ha;
> +
> + sas_unregister_ha(sha);
> + sas_remove_host(sha->core.shost);
> + scsi_remove_host(sha->core.shost);

scsi host should be removed before detaching SAS transport.

See more information:
http://www.spinics.net/lists/linux-scsi/msg90088.html

Thanks,
Wei

> + hisi_sas_free(hisi_hba);
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(hisi_sas_remove);
> +
>  static __init int hisi_sas_init(void)
>  {
>   pr_info("hisi_sas: driver version %s\n", DRV_VERSION);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/8] block/genhd.c: Add error handling

[Jens Axboe]

On 11/09/2015 08:33 PM, Al Viro wrote:

On Fri, Nov 06, 2015 at 05:52:08PM +0530, Vishnu Pratap Singh wrote:

Have you even tried to trigger the failure exits you've added?  The
more you've successfully set up, the _less_ your cleanup code ends
up undoing; that simply can't be right.

That aside, as soon as we'd done register_disk(), the damn thing is
available for open(), so bailing out is _really_ not something for
faint-hearted - it's essentially equivalent to removal of device under
somebody who'd opened it and might've started IO, etc.  Going there
simply because some sysfs shite didn't get created doesn't look sane
as far as I'm concerned...

Especially since these failure exits are not going to be tested on
a regular basis, so the amount of bitrot will be pretty high ;-/


I'd greatly prefer it we just leave it alone. Much better to have a disk 
that does actually work and with some sysfs spew in the logs, than bail 
out for fairly vague reasons.


The road to hell is paved with good intentions. It's a noble thought to 
want to clean this up, but I think it does more harm than good.


--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] ARM: add v7 LPAE multi-platform defconfig

[Olof Johansson]

Hi Alison,

On Mon, Nov 9, 2015 at 6:53 PM, Alison Wang  wrote:
> v7 LPAE multi-platform defconfig is based on v7 multi-platform
> defconfig and adds LPAE support.
>
> The platforms based on Cortex-A7/A12/A15/A17, PJ4B, Krait are
> also enabled in this defconfig. But Cortex-A5/A8/A9, Scorpion
> and PJ4 are removed.
>
> This defconfig is verified on LS1021A which enables GIANFAR,
> I2C, WATCHDOG, AUDIO, EDMA and DSPI drivers, etc.
>
> The other platforms need to be verified by the platform
> maintainers too.
>
> Signed-off-by: Alison Wang 

This has been discussed before, and what we have chosen to do is to
just have a multi_v7_defconfig that all these platforms are enabled on
but with LPAE off.

Instead, what we do when building (and on our build/boot builders) is
to take multi_v7 and provide the snippet that turns on ARM_LPAE at
that time.


Regards,

-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL 0/6] ARM: SoC branches for v4.4

[Olof Johansson]

Hi Linus,

Here are our branches from arm-soc for v4.4.

Nothing too crazy this time around, we've documented each branch as usual.

Yet again the DT branch is by far the biggest, and it's not a trend we mind
to continue. This is the first time we're mixing arm64/arm contents in that
branch as well, a likely mode we'll continue going forward.

Also, see the reminder in the soc branch (3/6) about touching up one of
the clocksource init calls from the newly added mediatek code.


Please merge!

Thanks,

-Olof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL 1/6] ARM: SoC non-urgent fixes for v4.4

[Olof Johansson]

A handful of fixes that came in and didn't seem warranted to go in through
the 4.3-rc cycle.

- MAINTAINERS updates for one of the Broadcom platforms and lpc18xx
- A couple of non-critical Davinci bugfixes
- A fix to reset irq affinity for TI platforms (silences a warning at reboot)



Conflicts:

None



The following changes since commit ce5c2d2c256a4c8b523036537cd6be2d6af8f69d:

  arm64: fixup for mm renames

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-fixes-nc

for you to fetch changes up to 19c1c32c66514fabeffa029507cdd808b3ee854c:

  MAINTAINERS: update lpc18xx entry with more drivers



Andy Shevchenko (1):
  ARM: davinci: re-use %*ph specifier

Arnd Bergmann (3):
  ARM: cns3xxx: pci: avoid potential stack overflow
  Merge tag 'davinci-for-v4.4/fixes' of 
git://git.kernel.org/.../nsekhar/linux-davinci into next/fixes-non-critical
  Merge tag 'arm-soc/for-4.4/maintainers' of 
http://github.com/Broadcom/stblinux into next/fixes-non-critical

Joachim Eastwood (1):
  MAINTAINERS: update lpc18xx entry with more drivers

Jon Mason (1):
  MAINTAINERS: add entry for the Broadcom Northstar Plus SoCs

Murali Karicheri (1):
  soc: ti: reset irq affinity before freeing irq

Peter Ujfalusi (1):
  ARM: davinci: clock: Correct return values for API functions


 MAINTAINERS  | 19 ++-
 arch/arm/mach-cns3xxx/pcie.c | 71 +++
 arch/arm/mach-davinci/board-dm644x-evm.c |  4 +-
 arch/arm/mach-davinci/clock.c| 16 --
 drivers/soc/ti/knav_qmss_acc.c   |  4 ++
 5 files changed, 63 insertions(+), 51 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL 6/6] ARM: SoC defconfig updates for v4.4

[Olof Johansson]

Defconfig updates are kept separate from other branches mostly to avoid
conflicts between the different categories (driver branch enabling something
that has context conflict with SoC options, etc).

A lot of this again is scattered across the various hardware platforms.
multi_v7_defconfig, our "generic" config for most 32-bit platforms has
been gone through by Marvell Berlin maintainers and added most options
they need to run on their hardware. Broadcom NSP is also added there,
and the new Atmel SAMA5D2 (added last release). Rockchip also has display
and other devices supported in that config.

In addition to that, the usual small churn of new options being added
here and there.



Conflicts:

None



The following changes since commit 44f3e3191cc45643e19a3ac86eb6b4420bd48f33:

  Merge tag 'armsoc-dt' into HEAD

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-defconfig

for you to fetch changes up to 7c9730c5684d8ffd69ee0b9e1739484cc6a35b23:

  ARM: multi_v7_defconfig: enable UniPhier I2C drivers



Alan Tull (1):
  ARM: socfpga_defconfig: enable fpga manager

Anand Moon (3):
  ARM: exynos_defconfig: Enable LEDS for Odroid-XU3/XU4
  ARM: exynos_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4
  ARM: multi_v7_defconfig: Enable rtl8152 ethernet driver for Odroid-XU4

Andy Gross (3):
  ARM: qcom_defconfig: Enable SMD-RPM regulators
  ARM: multi_v7_defconfig: Enable QCOM SMD/RPM
  arm64: defconfig: Enable devices for MSM8916

Antoine Tenart (1):
  ARM: multi_v7_defconfig: improve multi_v7_defconfig support for Berlin

Arnd Bergmann (3):
  Merge tag 'renesas-defconfig-for-v4.4' of 
git://git.kernel.org/.../horms/renesas into next/defconfig
  Merge tag 'arm-soc/for-4.4/defconfig' of 
http://github.com/Broadcom/stblinux into next/defconfig
  Merge tag 'keystone-config' of 
git://git.kernel.org/.../ssantosh/linux-keystone into next/defconfig

Fabio Estevam (1):
  ARM: imx_v6_v7_defconfig: Remove CONFIG_VMSPLIT_2G

Gerhard Bertelsmann (2):
  can: Allwinner A10/A20 CAN Controller support - Defconfig
  can: Allwinner A10/A20 CAN Controller support - Defconfig

Haibo Chen (1):
  ARM: imx_v6_v7_defconfig: enable imx6ul_tsc

Javier Martinez Canillas (3):
  ARM: exynos_defconfig: Enable USB Video Class support
  ARM: exynos_defconfig: Disable simplefb support
  ARM: exynos_defconfig: Enable WiFi-Ex as a module instead built-in

Joachim Eastwood (1):
  ARM: configs: update lpc18xx defconfig

Jon Mason (1):
  ARM: multi_v7_defconfig: Add NSP to defconfig

Jonathan Liu (1):
  ARM: sunxi_defconfig: enable MODULE_UNLOAD

Ludovic Desroches (6):
  ARM: at91/defconfig: update sama5 defconfig
  ARM: at91/defconfig: update at91_dt defconfig
  ARM: at91/defconfig: add sama5d2 and its new devices to sama5 defconfig
  ARM: multi_v7_defconfig: Add Atmel SAMA5D2 SoC
  ARM: multi_v7_defconfig: Add Atmel Flexcom device
  ARM: multi_v7_defconfig: Add Atmel SDHCI device

Magnus Damm (1):
  ARM: shmobile: Remove Marzen from shmobile_defconfig

Marcel Ziswiler (1):
  ARM: tegra: Update default configuration

Marek Szyprowski (2):
  ARM: exynos_defconfig: Enable DWC2 USB driver and USB ethernet gadget
  ARM: multi_v7_defconfig: Enable DWC2 USB driver and USB ethernet gadget

Masahiro Yamada (1):
  ARM: multi_v7_defconfig: enable UniPhier I2C drivers

Maxime Coquelin (1):
  ARM: configs: Enable FIXED_PHY in multi_v7 defconfig

Nishanth Menon (2):
  ARM: configs: keystone: sync to savedefconfig
  ARM: configs: keystone: Add basic systemd related options

Olof Johansson (9):
  Merge tag 'qcom-defconfig-for-4.4' of 
git://codeaurora.org/quic/kernel/agross-msm into next/defconfig
  Merge tag 'renesas-defconfig2-for-v4.4' of 
git://git.kernel.org/.../horms/renesas into next/defconfig
  Merge tag 'socfpga_defconfig_for_v4.4' of 
git://git.kernel.org/.../dinguyen/linux into next/defconfig
  Merge tag 'mvebu-config-4.4-1' of git://git.infradead.org/linux-mvebu 
into next/defconfig
  Merge tag 'sunxi-defconfig-for-4.4' of 
https://git.kernel.org/.../mripard/linux into next/defconfig
  Merge tag 'imx-defconfig-4.4' of git://git.kernel.org/.../shawnguo/linux 
into next/defconfig
  Merge tag 'at91-ab-defconfig' of git://git.kernel.org/.../abelloni/linux 
into next/defconfig
  Merge tag 'tegra-for-4.4-defconfig' of 
git://git.kernel.org/.../tegra/linux into next/defconfig
  Merge tag 'samsung-defconfig' of 
git://git.kernel.org/.../kgene/linux-samsung into next/defconfig

Priit Laes (1):
  ARM: sunxi_defconfig: Enable LRADC keys (KEYBOARD_SUN4I_LRADC)

Simon Guinot (1):
  ARM: mvebu: enable options for Seagate NAS in mvebu_v7_defconfig

Simon Horman (1):
  ARM: multi_v

[GIT PULL 2/6] ARM: SoC cleanups for v4.4

[Olof Johansson]

Again we have a sizable (but not huge) cleanup branch with a net delta of about
-3k lines.

Main contents here is:

- A bunch of development/cleanup of a few PXA boards
- Removal of bockw platforms on shmobile, since the platform has now gone
  completely multiplatform. Whee!
- move of the 32kHz timer on OMAP to a proper timesource
- Misc cleanup of older OMAP material (incl removal of one board file)
- Switch over to new common PWM lookup support for several platforms

There's also a handful of other cleanups across the tree, but the above are
the major pieces.



Conflicts:

OMAP timer code has a treewide fix vs code deletion conflict. Delete
the code in HEAD, go with contents from branch.



The following changes since commit 97f0fe6cec0cac661e1fc89ed2071fc5ab646c76:

  Merge tag 'armsoc-fixes-nc' into HEAD

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-cleanup

for you to fetch changes up to d3dc3df6330e4b4d799bef4aac6f934b5e726b1c:

  Merge tag 'omap-for-v4.4/soc-clean-up' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into 
next/cleanup



Andrzej Hajda (1):
  ARM: shmobile: apmu: correct type of CPU id

Arnd Bergmann (5):
  Merge tag 'renesas-cleanup-for-v4.4' of 
git://git.kernel.org/.../horms/renesas into next/cleanup
  Merge tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux 
into next/cleanup
  Merge tag 'mvebu-cleanup-4.4-1' of git://git.infradead.org/linux-mvebu 
into next/cleanup
  Merge tag 'omap-for-v4.4/cleanup-pt1' of 
git://git.kernel.org/.../tmlind/linux-omap into next/cleanup
  ARM: pxa: remove incorrect __init annotation on pxa27x_set_pwrmode

Felipe Balbi (13):
  arm: omap2: timer: always define omap4_local_timer_init
  arm: omap2: timer: get rid of obfuscating macros
  arm: omap2: timer: add a gptimer argument to sync32k_timer_init()
  arm: omap2: timer: remove __omap_gptimer_init()
  arm: omap2: timer: provide generic sync32k_timer_init function
  arm: omap2: timer: move realtime_counter_init() around
  arm: omap2: timer: always call clocksource_of_init() when DT
  arm: omap2: timer: rename omap_sync32k_timer_init()
  clocksource: add TI 32.768 Hz counter driver
  arm: omap2+: select 32k clocksource driver
  arm: omap2: timer: limit hwmod usage to non-DT boots
  clocksource: ti-32k: make it depend on GENERIC_CLOCKSOURCE
  arm: omap2: board-generic: use omap4_local_timer_init for AM437x

Franklin S Cooper Jr (2):
  ARM: DRA7/AM335x/AM437x: hwmod: Remove elm address space from hwmod data
  ARM: DRA7/AM335x/AM437x: hwmod: Remove gpmc address space from hwmod data

Geert Uytterhoeven (10):
  ARM: shmobile: Remove unused declaration of 
r8a7778_add_standard_devices_dt()
  ARM: shmobile: Remove obsolete sh-gpio.h
  ARM: shmobile: Remove obsolete custom earlyprintk code
  ARM: shmobile: Remove obsolete intc.h
  ARM: shmobile: Remove obsolete legacy PM Domain leftovers
  ARM: shmobile: Remove obsolete earlytimer registration
  ARM: shmobile: Remove obsolete twd_local_timer declaration
  ARM: shmobile: smp: Make shmobile_smp_apmu_cpu_shutdown() static
  ARM: shmobile: r8a7778: Make r8a7778_init_irq_dt() static
  ARM: shmobile: r8a7779: Remove legacy PM Domain remainings

Gregory CLEMENT (1):
  ARM: mvebu: Use a CR_C constant instead of a hard-coded one

Jarkko Nikula (1):
  ARM: pxa: Remove unused clock_enable field from struct pxa2xx_spi_master

Javier Martinez Canillas (3):
  ARM: OMAP3: vc: Remove unused macros
  ARM: OMAP2+: Remove unneeded semicolons
  ARM: OMAP: Remove duplicated operand in OR operation

Julia Lawall (1):
  ARM: shmobile: R-Mobile: add missing of_node_put

Keerthy (1):
  ARM: OMAP: Change all cpu_is_* occurences to soc_is_* for id.c

Ladislav Michl (1):
  ARM: OMAP1: Remove board support for VoiceBlue board

Laurent Pinchart (2):
  ARM: shmobile: Remove legacy clock support leftovers
  ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

Lee Jones (1):
  ARM: shmobile: dt: Rename incorrect interrupt related binding

Lucas Stach (1):
  ARM: mvebu: remove the workaround imprecise abort fault handler

Marc Zyngier (1):
  ARM: Remove open-coded version of IRQCHIP_DECLARE

Olof Johansson (4):
  Merge tag 'renesas-cleanup2-for-v4.4' of 
git://git.kernel.org/.../horms/renesas into next/cleanup
  Merge tag 'mvebu-cleanup-4.4-2' of git://git.infradead.org/linux-mvebu 
into next/cleanup
  Merge tag 'pxa-for-4.4' of https://github.com/rjarzmik/linux into 
next/cleanup
  Merge tag 'omap-for-v4.4/soc-clean-up' of 
git://git.kernel.org/.../tmlind/linux-omap into next/cleanup

Petr Cvek (22):
  ARM: pxa: magician: Fix indentation in machine files
  ARM: px

[GIT PULL 4/6] ARM: SoC driver updates for v4.4

[Olof Johansson]

As we've enabled multiplatform kernels on ARM, and greatly done away with
the contents under arch/arm/mach-*, there's still need for SoC-related
drivers to go somewhere.

Many of them go in through other driver trees, but we still have
drivers/soc to hold some of the "doesn't fit anywhere" lowlevel code
that might be shared between ARM and ARM64 (or just in general makes
sense to not have under the architecture directory).

This branch contains mostly such code:

- Drivers for qualcomm SoCs for SMEM, SMD and SMD-RPM, used to communicate
with power management blocks on these SoCs for use by clock, regulator and
bus frequency drivers.
- Allwinner Reduced Serial Bus driver, again used to communicate with PMICs.
- Drivers for ARM's SCPI (System Control Processor). Not to be confused with
PSCI (Power State Coordination Interface). SCPI is used to communicate with
the assistant embedded cores doing power management, and we have yet to see
how many of them will implement this for their hardware vs abstracting in
other ways (or not at all like in the past).
- To make confusion between SCPI and PSCI more likely, this release also
includes an update of PSCI to interface version 1.0.
- Rockchip support for power domains.
- A driver to talk to the firmware on Raspberry Pi.



Conflicts:

None



The following changes since commit 13102660efc5d7b4bf0ef6915e43d8c6b5084b68:

  Merge tag 'armsoc-soc' into HEAD

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/armsoc-drivers

for you to fetch changes up to d13a5c8c4c3dbe299659bcff805f79a2c83e2bbc:

  soc: qcom: smd-rpm: Correct size of outgoing message



Alexander Aring (1):
  ARM: bcm2835: add mutual inclusion protection

Alexandre Belloni (1):
  clocksource: atmel-st: get and use slow clock

Andy Gross (1):
  Merge tag 'qcom-fixes-for-4.3-rc1' into base-for-4.4

Antoine Tenart (1):
  clk: berlin: add cpuclk

Arnd Bergmann (9):
  Merge tag 'renesas-clk-for-v4.4' of 
git://git.kernel.org/.../horms/renesas into next/drivers
  Merge tag 'at91-cleanup-4.4' of git://git.kernel.org/.../abelloni/linux 
into next/drivers
  Merge tag 'v4.4-rockchip-drivers1' of 
git://git.kernel.org/.../mmind/linux-rockchip into next/drivers
  Merge tag 'arm-scpi-for-v4.4' of 
git://git.kernel.org/.../sudeep.holla/linux into next/drivers
  firmware: qcom-scm: build for correct architecture level
  Merge tag 'drivers_pl172_for_4.4' of 
https://github.com/manabian/linux-lpc into next/drivers
  Merge tag 'berlin-new-cpuclk-for-4.4-1' of 
git://git.infradead.org/users/hesselba/linux-berlin into next/drivers
  Merge tag 'qcom-soc-for-4.4' of 
git://codeaurora.org/quic/kernel/agross-msm into next/drivers
  soc: qcom/smem: add HWSPINLOCK dependency

Bjorn Andersson (5):
  soc: qcom: smd: Implement id_table driver matching
  soc: qcom: smd: Reject send of too big packets
  soc: qcom: smd: Correct SMEM items for upper channels
  soc: qcom: smd-rpm: Correct the active vs sleep state flagging
  soc: qcom: smd-rpm: Correct size of outgoing message

Boris Brezillon (2):
  clocksource: tcb_clksrc: fix setup_clkevents error path
  misc: atmel_tclib: get and use slow clock

Caesar Wang (3):
  dt-bindings: add power-domain header for RK3288 SoCs
  dt-bindings: add document of Rockchip power domains
  soc: rockchip: power-domain: Add power domain driver

Chen-Yu Tsai (2):
  bus: sunxi-rsb: Add Allwinner Reduced Serial Bus (RSB) controller bindings
  bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus

Eric Anholt (1):
  ARM: bcm2835: Add the Raspberry Pi firmware driver

Geert Uytterhoeven (1):
  dt-bindings: Correct paths in Rockchip power domains binding document

Heiko Stuebner (2):
  Merge branch 'v4.4-armsoc/pd-headers' into v4.4-armsoc/drivers
  soc: rockchip: power-domain: don't try to print the clock name in error 
case

Julia Lawall (1):
  soc: qcom: smd: delete unneeded of_node_put

Lorenzo Pieralisi (6):
  drivers: firmware: psci: add INVALID_ADDRESS return value
  drivers: firmware: psci: move power_state handling to generic code
  drivers: firmware: psci: add PSCI_FEATURES call
  drivers: firmware: psci: add extended stateid power_state support
  drivers: firmware: psci: add PSCI v1.0 DT bindings
  drivers: psci: make PSCI 1.0 functions initialization version dependent

Olof Johansson (4):
  Merge tag 'firmware/psci-1.0' of 
git://git.kernel.org/.../lpieralisi/linux into next/drivers
  Merge branch 'drivers/psci2' into next/drivers
  Merge tag 'v4.4-rockchip-drivers2' of 
git://git.kernel.org/.../mmind/linux-rockchip into next/drivers
  Merge tag 'arm/soc/for-4.4/rpi-drivers' of 
https://github.com/Broadcom/stblinux into next/drivers

Punit Agrawal (