[PATCH v2 3/3] sparc: Implement watchdog_nmi_enable and watchdog_nmi_disable

[Babu Moger]

Implement functions watchdog_nmi_enable and watchdog_nmi_disable
to enable/disable nmi watchdog. Sparc uses arch specific nmi watchdog
handler. Currently, we do not have a way to enable/disable nmi watchdog
dynamically. With these patches we can enable or disable arch
specific nmi watchdogs using proc or sysctl interface.

Example commands.
To enable: echo 1 >  /proc/sys/kernel/nmi_watchdog
To disable: echo 0 >  /proc/sys/kernel/nmi_watchdog

It can also achieved using the sysctl parameter kernel.nmi_watchdog

Signed-off-by: Babu Moger 
---
 arch/sparc/kernel/nmi.c |   44 +++-
 1 files changed, 43 insertions(+), 1 deletions(-)

diff --git a/arch/sparc/kernel/nmi.c b/arch/sparc/kernel/nmi.c
index a9973bb..95e73c6 100644
--- a/arch/sparc/kernel/nmi.c
+++ b/arch/sparc/kernel/nmi.c
@@ -42,7 +42,7 @@
  */
 atomic_t nmi_active = ATOMIC_INIT(0);  /* oprofile uses this */
 EXPORT_SYMBOL(nmi_active);
-
+static int nmi_init_done;
 static unsigned int nmi_hz = HZ;
 static DEFINE_PER_CPU(short, wd_enabled);
 static int endflag __initdata;
@@ -153,6 +153,8 @@ static void report_broken_nmi(int cpu, int *prev_nmi_count)
 
 void stop_nmi_watchdog(void *unused)
 {
+   if (!__this_cpu_read(wd_enabled))
+   return;
pcr_ops->write_pcr(0, pcr_ops->pcr_nmi_disable);
__this_cpu_write(wd_enabled, 0);
atomic_dec(_active);
@@ -207,6 +209,9 @@ static int __init check_nmi_watchdog(void)
 
 void start_nmi_watchdog(void *unused)
 {
+   if (__this_cpu_read(wd_enabled))
+   return;
+
__this_cpu_write(wd_enabled, 1);
atomic_inc(_active);
 
@@ -259,6 +264,8 @@ int __init nmi_init(void)
}
}
 
+   nmi_init_done = 1;
+
return err;
 }
 
@@ -270,3 +277,38 @@ static int __init setup_nmi_watchdog(char *str)
return 0;
 }
 __setup("nmi_watchdog=", setup_nmi_watchdog);
+
+/*
+ * sparc specific NMI watchdog enable function.
+ * Enables watchdog if it is not enabled already.
+ */
+int watchdog_nmi_enable(unsigned int cpu)
+{
+   if (atomic_read(_active) == -1) {
+   pr_warn("NMI watchdog cannot be enabled or disabled\n");
+   return -1;
+   }
+
+   /*
+* watchdog thread could start even before nmi_init is called.
+* Just Return in that case. Let nmi_init finish the init
+* process first.
+*/
+   if (!nmi_init_done)
+   return 0;
+
+   smp_call_function_single(cpu, start_nmi_watchdog, NULL, 1);
+
+   return 0;
+}
+/*
+ * sparc specific NMI watchdog disable function.
+ * Disables watchdog if it is not disabled already.
+ */
+void watchdog_nmi_disable(unsigned int cpu)
+{
+   if (atomic_read(_active) == -1)
+   pr_warn_once("NMI watchdog cannot be enabled or disabled\n");
+   else
+   smp_call_function_single(cpu, stop_nmi_watchdog, NULL, 1);
+}
-- 
1.7.1

Re: [GIT PULL] lkdtm fixes for v4.9-rc4

[Kees Cook]

On Tue, Nov 1, 2016 at 1:19 PM, Greg KH  wrote:
> On Tue, Nov 01, 2016 at 10:32:03AM -0700, Kees Cook wrote:
>> Hi,
>>
>> Please pull this lkdtm fix for v4.9-rc4.
>>
>> Thanks!
>>
>> -Kees
>>
>> The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:
>>
>>   Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
>> tags/lkdtm-v4.9-rc4
>
> I get the build error:
> ERROR: "access_process_vm" [drivers/misc/lkdtm.ko] undefined!
> when pulling this into my tree (based on 4.9-rc3) :(
>
> And for just a single patch, a patch in email is easy for me to handle,
> as obviously this didn't go through any 0-day build testing...

Oh, hrm. I will investigate.

-Kees

-- 
Kees Cook
Nexus Security

Re: [PATCHv3 3/3] z3fold: add compaction worker

[Dan Streetman]

On Thu, Oct 27, 2016 at 7:13 AM, Vitaly Wool  wrote:
> This patch implements compaction worker thread for z3fold. This
> worker does not free up any pages directly but it allows for a
> denser placement of compressed objects which results in less
> actual pages consumed and higher compression ratio therefore.
>
> This patch has been checked with the latest Linus's tree.
>
> Signed-off-by: Vitaly Wool 
> ---
>  mm/z3fold.c | 166 
> ++--
>  1 file changed, 140 insertions(+), 26 deletions(-)
>
> diff --git a/mm/z3fold.c b/mm/z3fold.c
> index 014d84f..cc26ff5 100644
> --- a/mm/z3fold.c
> +++ b/mm/z3fold.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -59,6 +60,7 @@ struct z3fold_ops {
>
>  /**
>   * struct z3fold_pool - stores metadata for each z3fold pool
> + * @name:  pool name
>   * @lock:  protects all pool fields and first|last_chunk fields of any
>   * z3fold page in the pool
>   * @unbuddied: array of lists tracking z3fold pages that contain 2- buddies;
> @@ -72,11 +74,14 @@ struct z3fold_ops {
>   * @unbuddied_nr:  number of unbuddied z3fold pages in the pool.
>   * @ops:   pointer to a structure of user defined operations specified at
>   * pool creation time.
> + * @compact_wq:workqueue for page layout background optimization
> + * @work:  compaction work item
>   *
>   * This structure is allocated at pool creation time and maintains metadata
>   * pertaining to a particular z3fold pool.
>   */
>  struct z3fold_pool {
> +   const char *name;
> rwlock_t lock;
> struct list_head unbuddied[NCHUNKS];
> struct list_head buddied;
> @@ -86,6 +91,8 @@ struct z3fold_pool {
> const struct z3fold_ops *ops;
> struct zpool *zpool;
> const struct zpool_ops *zpool_ops;
> +   struct workqueue_struct *compact_wq;
> +   struct delayed_work work;
>  };
>
>  enum buddy {
> @@ -121,6 +128,7 @@ enum z3fold_page_flags {
> UNDER_RECLAIM = 0,
> PAGE_HEADLESS,
> MIDDLE_CHUNK_MAPPED,
> +   COMPACTION_DEFERRED,
>  };
>
>  /*
> @@ -136,6 +144,9 @@ static int size_to_chunks(size_t size)
>  #define for_each_unbuddied_list(_iter, _begin) \
> for ((_iter) = (_begin); (_iter) < NCHUNKS; (_iter)++)
>
> +#define for_each_unbuddied_list_reverse(_iter, _end) \
> +   for ((_iter) = (_end); (_iter) > 0; (_iter)--)
> +
>  /* Initializes the z3fold header of a newly allocated z3fold page */
>  static struct z3fold_header *init_z3fold_page(struct page *page)
>  {
> @@ -145,6 +156,7 @@ static struct z3fold_header *init_z3fold_page(struct page 
> *page)
> clear_bit(UNDER_RECLAIM, >private);
> clear_bit(PAGE_HEADLESS, >private);
> clear_bit(MIDDLE_CHUNK_MAPPED, >private);
> +   clear_bit(COMPACTION_DEFERRED, >private);
>
> zhdr->first_chunks = 0;
> zhdr->middle_chunks = 0;
> @@ -211,6 +223,116 @@ static int num_free_chunks(struct z3fold_header *zhdr)
> return nfree;
>  }
>
> +static inline void *mchunk_memmove(struct z3fold_header *zhdr,
> +   unsigned short dst_chunk)
> +{
> +   void *beg = zhdr;
> +   return memmove(beg + (dst_chunk << CHUNK_SHIFT),
> +  beg + (zhdr->start_middle << CHUNK_SHIFT),
> +  zhdr->middle_chunks << CHUNK_SHIFT);
> +}
> +
> +static int z3fold_compact_page(struct z3fold_header *zhdr, bool sync)
> +{
> +   struct page *page = virt_to_page(zhdr);
> +   int ret = 0;
> +
> +   if (test_bit(MIDDLE_CHUNK_MAPPED, >private)) {
> +   set_bit(COMPACTION_DEFERRED, >private);
> +   ret = -1;
> +   goto out;
> +   }
> +
> +   clear_bit(COMPACTION_DEFERRED, >private);
> +   if (zhdr->middle_chunks != 0) {
> +   if (zhdr->first_chunks == 0 && zhdr->last_chunks == 0) {
> +   /*
> +* If we are here, no one can access this page
> +* except for z3fold_map or z3fold_free. Both
> +* will wait for page_lock to become free.
> +*/
> +   mchunk_memmove(zhdr, 1); /* move to the beginning */
> +   zhdr->first_chunks = zhdr->middle_chunks;
> +   zhdr->middle_chunks = 0;
> +   zhdr->start_middle = 0;
> +   zhdr->first_num++;
> +   ret = 1;
> +   goto out;
> +   }
> +   if (sync)
> +   goto out;
> +
> +   /*
> +* These are more complicated cases: first or last object
> +* may be mapped. Luckily we don't touch these anyway.
> +*
> +* NB: moving data is 

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

[Ivaylo Dimitrov]

On  1.11.2016 22:11, Sakari Ailus wrote:

Hi Ivaylo,

On Tue, Nov 01, 2016 at 08:36:57AM +0200, Ivaylo Dimitrov wrote:

Hi,

On  1.11.2016 00:54, Sakari Ailus wrote:

Hi Pavel,

On Sun, Oct 23, 2016 at 10:33:15PM +0200, Pavel Machek wrote:

Hi!


Thanks, this answered half of my questions already. ;-)


:-).

I'll have to go through the patches, et8ek8 driver is probably not
enough to get useful video. platform/video-bus-switch.c is needed for
camera switching, then some omap3isp patches to bind flash and
autofocus into the subdevice.

Then, device tree support on n900 can be added.


I briefly discussed with with Sebastian.

Do you think the elusive support for the secondary camera is worth keeping
out the main camera from the DT in mainline? As long as there's a reasonable
way to get it working, I'd just merge that. If someone ever gets the
secondary camera working properly and nicely with the video bus switch,
that's cool, we'll somehow deal with the problem then. But frankly I don't
think it's very useful even if we get there: the quality is really bad.



Yes, lets merge what we have till now, it will be way easier to improve on
it once it is part of the mainline.

BTW, I have (had) patched VBS working almost without problems, when it comes
to it I'll dig it.


I wonder if I'm the only one who wonders what VBS is here. Don't tell me its
the old MS thing. :-) ;-)



Oh, sorry, I thought that V(ideo) B(us) S(witch) is clear in the context :)

[PATCH 2/4] Staging: vme: Use BIT macro for bit field definitions.

[Anton Leshchenko]

Instead of using shift operation use BIT macro for bit field
definitions.

Signed-off-by: Anton Leshchenko 
---
 drivers/staging/vme/devices/vme_pio2.h | 102 -
 1 file changed, 51 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_pio2.h 
b/drivers/staging/vme/devices/vme_pio2.h
index 0b280ae..9da3813 100644
--- a/drivers/staging/vme/devices/vme_pio2.h
+++ b/drivers/staging/vme/devices/vme_pio2.h
@@ -68,38 +68,38 @@ static const int PIO2_CHANNEL_BANK[32] = { 0, 0, 0, 0, 0, 
0, 0, 0,
2, 2, 2, 2, 2, 2, 2, 2,
3, 3, 3, 3, 3, 3, 3, 3 };
 
-#define PIO2_CHANNEL0_BIT  (1 << 0)
-#define PIO2_CHANNEL1_BIT  (1 << 1)
-#define PIO2_CHANNEL2_BIT  (1 << 2)
-#define PIO2_CHANNEL3_BIT  (1 << 3)
-#define PIO2_CHANNEL4_BIT  (1 << 4)
-#define PIO2_CHANNEL5_BIT  (1 << 5)
-#define PIO2_CHANNEL6_BIT  (1 << 6)
-#define PIO2_CHANNEL7_BIT  (1 << 7)
-#define PIO2_CHANNEL8_BIT  (1 << 0)
-#define PIO2_CHANNEL9_BIT  (1 << 1)
-#define PIO2_CHANNEL10_BIT (1 << 2)
-#define PIO2_CHANNEL11_BIT (1 << 3)
-#define PIO2_CHANNEL12_BIT (1 << 4)
-#define PIO2_CHANNEL13_BIT (1 << 5)
-#define PIO2_CHANNEL14_BIT (1 << 6)
-#define PIO2_CHANNEL15_BIT (1 << 7)
-#define PIO2_CHANNEL16_BIT (1 << 0)
-#define PIO2_CHANNEL17_BIT (1 << 1)
-#define PIO2_CHANNEL18_BIT (1 << 2)
-#define PIO2_CHANNEL19_BIT (1 << 3)
-#define PIO2_CHANNEL20_BIT (1 << 4)
-#define PIO2_CHANNEL21_BIT (1 << 5)
-#define PIO2_CHANNEL22_BIT (1 << 6)
-#define PIO2_CHANNEL23_BIT (1 << 7)
-#define PIO2_CHANNEL24_BIT (1 << 0)
-#define PIO2_CHANNEL25_BIT (1 << 1)
-#define PIO2_CHANNEL26_BIT (1 << 2)
-#define PIO2_CHANNEL27_BIT (1 << 3)
-#define PIO2_CHANNEL28_BIT (1 << 4)
-#define PIO2_CHANNEL29_BIT (1 << 5)
-#define PIO2_CHANNEL30_BIT (1 << 6)
-#define PIO2_CHANNEL31_BIT (1 << 7)
+#define PIO2_CHANNEL0_BIT  BIT(0)
+#define PIO2_CHANNEL1_BIT  BIT(1)
+#define PIO2_CHANNEL2_BIT  BIT(2)
+#define PIO2_CHANNEL3_BIT  BIT(3)
+#define PIO2_CHANNEL4_BIT  BIT(4)
+#define PIO2_CHANNEL5_BIT  BIT(5)
+#define PIO2_CHANNEL6_BIT  BIT(6)
+#define PIO2_CHANNEL7_BIT  BIT(7)
+#define PIO2_CHANNEL8_BIT  BIT(0)
+#define PIO2_CHANNEL9_BIT  BIT(1)
+#define PIO2_CHANNEL10_BIT BIT(2)
+#define PIO2_CHANNEL11_BIT BIT(3)
+#define PIO2_CHANNEL12_BIT BIT(4)
+#define PIO2_CHANNEL13_BIT BIT(5)
+#define PIO2_CHANNEL14_BIT BIT(6)
+#define PIO2_CHANNEL15_BIT BIT(7)
+#define PIO2_CHANNEL16_BIT BIT(0)
+#define PIO2_CHANNEL17_BIT BIT(1)
+#define PIO2_CHANNEL18_BIT BIT(2)
+#define PIO2_CHANNEL19_BIT BIT(3)
+#define PIO2_CHANNEL20_BIT BIT(4)
+#define PIO2_CHANNEL21_BIT BIT(5)
+#define PIO2_CHANNEL22_BIT BIT(6)
+#define PIO2_CHANNEL23_BIT BIT(7)
+#define PIO2_CHANNEL24_BIT BIT(0)
+#define PIO2_CHANNEL25_BIT BIT(1)
+#define PIO2_CHANNEL26_BIT BIT(2)
+#define PIO2_CHANNEL27_BIT BIT(3)
+#define PIO2_CHANNEL28_BIT BIT(4)
+#define PIO2_CHANNEL29_BIT BIT(5)
+#define PIO2_CHANNEL30_BIT BIT(6)
+#define PIO2_CHANNEL31_BIT BIT(7)
 
 static const int PIO2_CHANNEL_BIT[32] = { PIO2_CHANNEL0_BIT, PIO2_CHANNEL1_BIT,
PIO2_CHANNEL2_BIT, PIO2_CHANNEL3_BIT,
@@ -120,12 +120,12 @@ static const int PIO2_CHANNEL_BIT[32] = { 
PIO2_CHANNEL0_BIT, PIO2_CHANNEL1_BIT,
};
 
 /* PIO2_REGS_INT_STAT_CNTR (0xc) */
-#define PIO2_COUNTER0  (1 << 0)
-#define PIO2_COUNTER1  (1 << 1)
-#define PIO2_COUNTER2  (1 << 2)
-#define PIO2_COUNTER3  (1 << 3)
-#define PIO2_COUNTER4  (1 << 4)
-#define PIO2_COUNTER5  (1 << 5)
+#define PIO2_COUNTER0  BIT(0)
+#define PIO2_COUNTER1  BIT(1)
+#define PIO2_COUNTER2  BIT(2)
+#define PIO2_COUNTER3  BIT(3)
+#define PIO2_COUNTER4  BIT(4)
+#define PIO2_COUNTER5  BIT(5)
 
 static const int PIO2_COUNTER[6] = { PIO2_COUNTER0, PIO2_COUNTER1,
PIO2_COUNTER2, PIO2_COUNTER3,
@@ -133,8 +133,8 @@ static const int PIO2_COUNTER[6] = { PIO2_COUNTER0, 
PIO2_COUNTER1,
 
 /* PIO2_REGS_CTRL (0x18) */
 #define PIO2_VME_INT_MASK  0x7

[PATCH 1/4] Staging: vme: Remove excessive blank lines.

[Anton Leshchenko]

To make code more readable, remove excessive blank lines.

Signed-off-by: Anton Leshchenko 
---
 drivers/staging/vme/devices/vme_pio2.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_pio2.h 
b/drivers/staging/vme/devices/vme_pio2.h
index d5d94c4..0b280ae 100644
--- a/drivers/staging/vme/devices/vme_pio2.h
+++ b/drivers/staging/vme/devices/vme_pio2.h
@@ -48,8 +48,6 @@ static const int PIO2_REGS_INT_MASK[8] = { 
PIO2_REGS_INT_MASK0,
PIO2_REGS_INT_MASK6,
PIO2_REGS_INT_MASK7 };
 
-
-
 #define PIO2_REGS_CTRL 0x18
 #define PIO2_REGS_VME_VECTOR   0x19
 #define PIO2_REGS_CNTR00x20
@@ -63,7 +61,6 @@ static const int PIO2_REGS_INT_MASK[8] = { 
PIO2_REGS_INT_MASK0,
 
 #define PIO2_REGS_ID   0x30
 
-
 /* PIO2_REGS_DATAx (0x0 - 0x3) */
 
 static const int PIO2_CHANNEL_BANK[32] = { 0, 0, 0, 0, 0, 0, 0, 0,
@@ -204,8 +201,6 @@ static const int PIO2_CNTR_SC_DEV[6] = { PIO2_CNTR_SC_DEV0, 
PIO2_CNTR_SC_DEV1,
 
 #define PIO2_CNTR_BCD  1
 
-
-
 enum pio2_bank_config { NOFIT, INPUT, OUTPUT, BOTH };
 enum pio2_int_config { NONE = 0, LOW2HIGH = 1, HIGH2LOW = 2, EITHER = 4 };
 
-- 
2.10.2

[PATCH] pci-hyperv: move hypercall buffer from stack to heap

[Long Li]

From: Long Li 

We need to pass a segment from a physically continuous buffer to 
hv_do_hypercall. Buffer allocated on the stack may not work if 
CONFIG_VMAP_STACK=y is set. Moving the params buffer from stack to buffer 
returned by kmalloc.

Signed-off-by: Long Li 
Reported-by: Haiyang Zhang 
---
 drivers/pci/host/pci-hyperv.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 763ff87..97e6daf 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -378,6 +378,7 @@ struct hv_pcibus_device {
struct msi_domain_info msi_info;
struct msi_controller msi_chip;
struct irq_domain *irq_domain;
+   struct retarget_msi_interrupt retarget_msi_interrupt_params;
 };
 
 /*
@@ -774,7 +775,7 @@ void hv_irq_unmask(struct irq_data *data)
 {
struct msi_desc *msi_desc = irq_data_get_msi_desc(data);
struct irq_cfg *cfg = irqd_cfg(data);
-   struct retarget_msi_interrupt params;
+   struct retarget_msi_interrupt *params;
struct hv_pcibus_device *hbus;
struct cpumask *dest;
struct pci_bus *pbus;
@@ -785,23 +786,24 @@ void hv_irq_unmask(struct irq_data *data)
pdev = msi_desc_to_pci_dev(msi_desc);
pbus = pdev->bus;
hbus = container_of(pbus->sysdata, struct hv_pcibus_device, sysdata);
-
-   memset(, 0, sizeof(params));
-   params.partition_id = HV_PARTITION_ID_SELF;
-   params.source = 1; /* MSI(-X) */
-   params.address = msi_desc->msg.address_lo;
-   params.data = msi_desc->msg.data;
-   params.device_id = (hbus->hdev->dev_instance.b[5] << 24) |
+   params = >retarget_msi_interrupt_params;
+
+   memset(params, 0, sizeof(*params));
+   params->partition_id = HV_PARTITION_ID_SELF;
+   params->source = 1; /* MSI(-X) */
+   params->address = msi_desc->msg.address_lo;
+   params->data = msi_desc->msg.data;
+   params->device_id = (hbus->hdev->dev_instance.b[5] << 24) |
   (hbus->hdev->dev_instance.b[4] << 16) |
   (hbus->hdev->dev_instance.b[7] << 8) |
   (hbus->hdev->dev_instance.b[6] & 0xf8) |
   PCI_FUNC(pdev->devfn);
-   params.vector = cfg->vector;
+   params->vector = cfg->vector;
 
for_each_cpu_and(cpu, dest, cpu_online_mask)
-   params.vp_mask |= (1ULL << vmbus_cpu_number_to_vp_number(cpu));
+   params->vp_mask |= (1ULL << vmbus_cpu_number_to_vp_number(cpu));
 
-   hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, , NULL);
+   hv_do_hypercall(HVCALL_RETARGET_INTERRUPT, params, NULL);
 
pci_msi_unmask_irq(data);
 }
-- 
2.7.4

Re: [GIT PULL] seccomp fixes for v4.9-rc4

[James Morris]

On Tue, 1 Nov 2016, Kees Cook wrote:

> Hi,
> 
> Please pull these seccomp fixes for v4.9-rc4.

> 
> - fix function prototype documentation
> - fix samples to include NNP setting
> - fix samples to avoid rule truncation
> - fix samples hostprogs variable in Makefile
> 
> 

These fixes don't seem very critical, and Linus was talking yesterday at 
KS about too much churn in the -rc series with non-critical fixes.

How about we queue this up for 4.10?


-- 
James Morris

Re: [PATCH RFC 0/4] Fix PDF build errors

[Mauro Carvalho Chehab]

Em Tue,  1 Nov 2016 16:44:09 -0600
Mauro Carvalho Chehab  escreveu:

> This series address a series of errors during PDF generation from
> media documentation.
> 
> Please notice that patch 2 carries on a PDF conversion from a PNG
> image, because Sphinx is not smart enough to do the convertion.
> 
> This is a temporary solution (That's why I'm marking this series
> as RFC).
> 
> I'm working on a more permanent access where the image format

In time:
"more permanent solution"

> required by Sphinx for PDF output will be met.
> 
> Mauro Carvalho Chehab (4):
>   docs-rst: fix PDF build errors
>   [media] subdev-formats.rst: we need a pdf picture for bayer
>   [media] subdev-formats.rst: don't use adjustbox on a longtable
>   [media] subdev-formats.rst: add missing columns to tabularcolumns
> 
>  Documentation/conf.py  |   4 
>  Documentation/media/index.rst  |   5 -
>  Documentation/media/uapi/v4l/subdev-formats.rst|  17 
> +++--
>  .../media/uapi/v4l/subdev-formats_files/bayer.pdf  | Bin 0 -> 11131 bytes
>  4 files changed, 15 insertions(+), 11 deletions(-)
>  create mode 100644 
> Documentation/media/uapi/v4l/subdev-formats_files/bayer.pdf
> 




Cheers,
Mauro

Re: [PATCH] x86/copy_user: Remove 64-bit asm _copy_*_user variants

[Linus Torvalds]

On Mon, Oct 31, 2016 at 9:10 AM, Borislav Petkov  wrote:
> From: Borislav Petkov 
>
> We already have the same functionality in usercopy_32.c. Share it with
> 64-bit and get rid of some more asm glue which is not needed anymore.

I see this already made it into -tip, but it looks good to me. I think
Al may have some of this in generic code already in his uaccess
cleanup stuff, but I doubt this makes for any huge merge conflict
issues.

 Linus

Re: [PATCH] EFI loader: remove dead code

[Linn Crosetto]

On Tue, Nov 01, 2016 at 08:38:08PM +0300, Eugene Korenevsky wrote:
> *e820ext is always NULL in 'alloc_e820ext()' (see the code of 'exit_boot()').
> Therefore the 'if' condition is always false and the entire 'if' statement is
> pointless. Remove it.
> 
> ---
>  arch/x86/boot/compressed/eboot.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/eboot.c 
> b/arch/x86/boot/compressed/eboot.c
> index cc69e37..edfd4d6 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -956,12 +956,6 @@ static efi_status_t alloc_e820ext(u32 nr_desc, struct 
> setup_data **e820ext,
>   size = sizeof(struct setup_data) +
>   sizeof(struct e820entry) * nr_desc;
>  
> - if (*e820ext) {
> - efi_call_early(free_pool, *e820ext);
> - *e820ext = NULL;
> - *e820ext_size = 0;
> - }
> -

I agree with your reading of the code. On the other hand, alloc_e820ext()
has no knowledge of the 'first' flag used in exit_boot_func() so the call to
free provides some assurance that memory isn't leaked if the calling code is
changed.

If the caller is responsible for freeing the memory in such a case, then
alloc_e820ext() should at least return an error.

--
Linn

Re: [PATCH 0/4 v2] Audio support for adv7511 hdmi bridge

[John Stultz]

On Tue, Oct 18, 2016 at 5:26 PM, Kuninori Morimoto
 wrote:
>
>> > Here's what I'm using to get it working:
>> > https://git.linaro.org/people/john.stultz/android-dev.git/commitdiff/1024cb4
>> > 85b6f00a7e355ce60425f04a584481148
>>
>> Thank you.
>>
>> We need to standardize DT bindings for HDMI sound output. Morimoto-san, could
>> you have a look at the DT bindings proposal for HDMI sound output with the
>> ADV7511, and comment on whether it matches the approach you've taken for HDMI
>> sound output on R-Car Gen3 ?
>
> Above patch is using normal simple-card style for HDMI sound, but as Laurent
> said we want to use same DT style for HDMI video and sound (= OF graph style).
> Fortunately, I posted patch-set for OF graph support on sound card yesterday.
> Can you check this ?
> http://www.spinics.net/lists/devicetree/msg146131.html
> The points are
>  - sound can use OF graph style DT
>  - sound-card DT is no longer needed
>  - it needs type = "sound" property
>
> patch-set [0/23] is this
> http://www.spinics.net/lists/devicetree/msg146113.html

Thanks for the pointers! If I understand this correctly, the OF graph
simple-card method would replace my current simple-card dts usage for
hikey?   Other then just having another out-of-tree patchset to track,
I don't have any objection to trying to use the OF graph simple-card
method in the hikey dts (though I suspect I'll have to pester you for
help when I give it a shot).

Laurent: So this seems to be mostly just a "which implementation do we
use" question for the hikey dts,  and it seems like the adv7511 audio
driver I'm submitting here has any ties to either the graph or normal
simple card method. Is that correct? Are there any changes to the
adv7511 audio support patch you'd like to see or should I just
resubmit it?

thanks
-john

Re: [PATCH 0/2] mmc: dw_mmc: fix the wrong operation for reset controller

[John Stultz]

On Sun, Oct 30, 2016 at 7:49 PM, Jaehoon Chung  wrote:
> This patch adds the "reset-names" as reset controller for dwmmc controller.
> Linaro guys had reported the issue about booting stuck.
>
> Some SoCs are enabled the CONFIG_RESET_CONTROLLER.
> then dwmmc controller are waiting for getting reset controller.
> But if doesn't define "resets" property in device-tree, it should be stuck.
>
> If use the reset-names as reset controller for dwmmc controller,
> it's more stable than now.
> This commit is related with the below commit.
>
> Fixes: d6786fefe816 ("mmc: dw_mmc: add reset support to dwmmc host 
> controller")

So I wasn't hit by the issue, as I don't tend to boot from SD on my
hikey, but I did run these patches and I'm not seeing any issues with
my Android environment.

So for what its worth:
Acked-by: John Stultz 

thanks
-john

[PATCH 4/4] Staging: vme: Fix parenthesis alignment.

[Anton Leshchenko]

Align broken line for code readability.

Signed-off-by: Anton Leshchenko 
---
 drivers/staging/vme/devices/vme_pio2_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vme/devices/vme_pio2_core.c 
b/drivers/staging/vme/devices/vme_pio2_core.c
index 8e66a52..20a2d83 100644
--- a/drivers/staging/vme/devices/vme_pio2_core.c
+++ b/drivers/staging/vme/devices/vme_pio2_core.c
@@ -365,7 +365,7 @@ static int pio2_probe(struct vme_dev *vdev)
vec = card->irq_vector | PIO2_VECTOR_CNTR[i];
 
retval = vme_irq_request(vdev, card->irq_level, vec,
-   _int, card);
+_int, card);
if (retval < 0) {
dev_err(>vdev->dev,
"Unable to attach VME interrupt vector0x%x, 
level 0x%x\n",
-- 
2.10.2

Re: [PATCH] clk: rockchip: optimize the configuration for 800MHz and 1GHz on RK3399

[Heiko Stuebner]

Am Dienstag, 1. November 2016, 11:22:06 CET schrieb Xing Zheng:
> Usually, the 800MHz and 1GHz are supplied for CPLL and NPLL in the RK3399.
> But dues to the carelessly copying from RK3036 when the RK3399 bringing up,
> the refdiv == 6, it will increase the lock time, and it is not an optimal
> configuration.
> 
> Please let's fix them for the lock time and jitter are lower:
> 800 MHz:
> - FVCO == 2.4 GHz, revdiv == 1.
> 1 GHz:
> - FVCO == 3 GHz, revdiv == 1.
> 
> Signed-off-by: Xing Zheng 

applied to my clk-branch for 4.10


Thanks
Heiko

[[PATCH repost v21] 09/11] ARM: socfpga: fpga bridge driver support

[Alan Tull]

Supports Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Allows enabling/disabling the bridges through the FPGA
Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling
of the ports that been configured early on.  This is due to
a hardware limitation where the read, write, and command
ports on the fpga2sdram bridge can only be reconfigured
while there are no transactions to the sdram, i.e. when
running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to
enable or disable the bridge during probe.  If the property
does not exist, the driver will leave the bridge in its
current state.

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/fpga/Kconfig |   7 ++
 drivers/fpga/Makefile|   1 +
 drivers/fpga/altera-fpga2sdram.c | 180 +++
 drivers/fpga/altera-hps2fpga.c   | 222 +++
 4 files changed, 410 insertions(+)
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index e0e1257..5605ad6 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -40,6 +40,13 @@ config FPGA_BRIDGE
  Say Y here if you want to support bridges connected between host
  processors and FPGAs or between FPGAs.
 
+config SOCFPGA_FPGA_BRIDGE
+   tristate "Altera SoCFPGA FPGA Bridges"
+   depends on ARCH_SOCFPGA && FPGA_BRIDGE
+   help
+ Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
+ devices.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d746c3..e658436 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_REGION)  += fpga-region.o
diff --git a/drivers/fpga/altera-fpga2sdram.c b/drivers/fpga/altera-fpga2sdram.c
new file mode 100644
index 000..7ab358e
--- /dev/null
+++ b/drivers/fpga/altera-fpga2sdram.c
@@ -0,0 +1,180 @@
+/*
+ * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
+ *
+ *  Copyright (C) 2013-2016 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 .
+ */
+
+/*
+ * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
+ * host processor system (HPS).
+ *
+ * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
+ * Reconfiguring these ports requires that no SDRAM transactions occur during
+ * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
+ * nor can the FPGA access the SDRAM during reconfiguration.  This driver does
+ * not support reconfiguring the ports.  The ports are configured by code
+ * running out of on chip ram before Linux is started and the configuration
+ * is passed in a handoff register in the system manager.
+ *
+ * This driver supports enabling and disabling of the configured ports, which
+ * allows for safe reprogramming of the FPGA, assuming that the new FPGA image
+ * uses the same port configuration.  Bridges must be disabled before
+ * reprogramming the FPGA and re-enabled after the FPGA has been programmed.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ALT_SDR_CTL_FPGAPORTRST_OFST   0x80
+#define ALT_SDR_CTL_FPGAPORTRST_PORTRSTN_MSK   0x3fff
+#define ALT_SDR_CTL_FPGAPORTRST_RD_SHIFT   0
+#define ALT_SDR_CTL_FPGAPORTRST_WR_SHIFT   4
+#define ALT_SDR_CTL_FPGAPORTRST_CTRL_SHIFT 8
+
+/*
+ * From the Cyclone V HPS Memory Map document:
+ *   These registers are used to store handoff information between the
+ *   preloader and the OS. These 8 registers can be used to store any
+ *   information. The contents of these registers have no impact on
+ *   the state of the HPS hardware.
+ */
+#define SYSMGR_ISWGRP_HANDOFF3  (0x8C)
+
+#define F2S_BRIDGE_NAME "fpga2sdram"
+
+struct alt_fpga2sdram_data {

[[PATCH repost v21] 11/11] fpga-manager: Add Socfpga Arria10 support

[Alan Tull]

Add low level driver to support reprogramming FPGAs for Altera
SoCFPGA Arria10.

Signed-off-by: Alan Tull 
Reviewed-by: Moritz Fischer 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/fpga/Kconfig   |   6 +
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/socfpga-a10.c | 556 +
 3 files changed, 563 insertions(+)
 create mode 100644 drivers/fpga/socfpga-a10.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 8fe6a84..889e4c3 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -26,6 +26,12 @@ config FPGA_MGR_SOCFPGA
help
  FPGA manager driver support for Altera SOCFPGA.
 
+config FPGA_MGR_SOCFPGA_A10
+   tristate "Altera SoCFPGA Arria10"
+   depends on ARCH_SOCFPGA
+   help
+ FPGA manager driver support for Altera Arria10 SoCFPGA.
+
 config FPGA_MGR_ZYNQ_FPGA
tristate "Xilinx Zynq FPGA"
depends on ARCH_ZYNQ || COMPILE_TEST
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index a6f874d..8df07bc 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 
 # FPGA Manager Drivers
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
+obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
 
 # FPGA Bridge Drivers
diff --git a/drivers/fpga/socfpga-a10.c b/drivers/fpga/socfpga-a10.c
new file mode 100644
index 000..ccd9fb2
--- /dev/null
+++ b/drivers/fpga/socfpga-a10.c
@@ -0,0 +1,556 @@
+/*
+ * FPGA Manager Driver for Altera Arria10 SoCFPGA
+ *
+ * Copyright (C) 2015-2016 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+#include 
+
+#define A10_FPGAMGR_DCLKCNT_OFST   0x08
+#define A10_FPGAMGR_DCLKSTAT_OFST  0x0c
+#define A10_FPGAMGR_IMGCFG_CTL_00_OFST 0x70
+#define A10_FPGAMGR_IMGCFG_CTL_01_OFST 0x74
+#define A10_FPGAMGR_IMGCFG_CTL_02_OFST 0x78
+#define A10_FPGAMGR_IMGCFG_STAT_OFST   0x80
+
+#define A10_FPGAMGR_DCLKSTAT_DCLKDONE  BIT(0)
+
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NENABLE_NCONFIG  BIT(0)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NENABLE_NSTATUS  BIT(1)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NENABLE_CONDONE  BIT(2)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NCONFIG  BIT(8)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NSTATUS_OE   BIT(16)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_CONDONE_OE   BIT(24)
+
+#define A10_FPGAMGR_IMGCFG_CTL_01_S2F_NENABLE_CONFIG   BIT(0)
+#define A10_FPGAMGR_IMGCFG_CTL_01_S2F_PR_REQUEST   BIT(16)
+#define A10_FPGAMGR_IMGCFG_CTL_01_S2F_NCE  BIT(24)
+
+#define A10_FPGAMGR_IMGCFG_CTL_02_EN_CFG_CTRL  BIT(0)
+#define A10_FPGAMGR_IMGCFG_CTL_02_CDRATIO_MASK (BIT(16) | BIT(17))
+#define A10_FPGAMGR_IMGCFG_CTL_02_CDRATIO_SHIFT16
+#define A10_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH BIT(24)
+#define A10_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SHIFT   24
+
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_CRC_ERROR  BIT(0)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_EARLY_USERMODE BIT(1)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_USERMODE   BIT(2)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_NSTATUS_PINBIT(4)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_CONDONE_PINBIT(6)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_PR_READY   BIT(9)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_PR_DONEBIT(10)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_PR_ERROR   BIT(11)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_NCONFIG_PINBIT(12)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_MSEL_MASK  (BIT(16) | BIT(17) | BIT(18))
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_MSEL_SHIFT 16
+
+/* FPGA CD Ratio Value */
+#define CDRATIO_x1 0x0
+#define CDRATIO_x2 0x1
+#define CDRATIO_x4  

Re: [PATCH v12 RESEND 0/4] generic TEE subsystem

[Andrew F. Davis]

On 10/28/2016 01:19 PM, Mark Brown wrote:
> On Fri, Oct 28, 2016 at 10:43:24AM -0500, Andrew F. Davis wrote:
> 
>> Do we see this as a chicken and egg situation, or is there any harm
>> beyond the pains of supporting an out-of-tree driver for a while, to
>> wait until we have at least one other TEE to add to this subsystem
>> before merging?
> 
> We haven't been overburneded with TEE vendors wanting to get their
> driver code into mainline - do we have any reasonable prospect of other
> TEE vendors with an interest in mainline turning up in any kind of
> reasonable timeframe?
> 

Doesn't look like anyone has near-term plans for upstreaming non-OPTEE
TEEs, we don't at least (TI), so I guess I see no reason right now to
delay upstreaming of this TEE's driver on the off-chance it is
incompatible with a TEE that may or may not try to get upstreamed later.
I'll redact my objection for now.

Re: [PATCH] UBIFS: Remove some dead code

[Julia Lawall]

On Tue, 1 Nov 2016, Christophe JAILLET wrote:

> Le 01/11/2016 à 12:42, Richard Weinberger a écrit :
> > On 01.11.2016 07:45, Christophe JAILLET wrote:
> > > 'ubifs_fast_find_freeable()' can not return an error pointer, so this test
> > > can be removed.
> > >
> > > Signed-off-by: Christophe JAILLET 
> > > ---
> > >   fs/ubifs/gc.c | 4 
> > >   1 file changed, 4 deletions(-)
> > >
> > > diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
> > > index e845c64b6ce1..7b35e3d6cde7 100644
> > > --- a/fs/ubifs/gc.c
> > > +++ b/fs/ubifs/gc.c
> > > @@ -846,10 +846,6 @@ int ubifs_gc_start_commit(struct ubifs_info *c)
> > >*/
> > >   while (1) {
> > >   lp = ubifs_fast_find_freeable(c);
> > > - if (IS_ERR(lp)) {
> > > - err = PTR_ERR(lp);
> > > - goto out;
> > > - }
> > Good catch, how did you find this?
> > If you have a tool/script I'd like to use it too.
> >
> > Thanks,
> > //richard
> > --
>
> Hi,
> well, it is a bit tricky.
>
> AFAIK, coccinelle is only able to match things in a given file. Finding issues
> between 2 files can be tricky.
>
> So first, I have built a list a functions which are likely to return NULL,
> either because they explicitly return NULL or if its return value is tested
> against NULL or not. See coccinelle script n°1 below.
> Then I have built a list of functions followed by a test with IS_ERR. See
> coccinelle script n°2 below.
>
> These 2 scripts generate 2 lists of functions.
> If a function is present in the 2 files, it is likely that something is
> spurious.
>
> Either the IS_ERR is not needed (this is the case in the patch above), either
> the return value is incorrectly checked. Could also be that NULL is returned
> but an error pointer would be a better option.
>
>
> I also did more or less the same for functions that return PTR_ERR and
> functions that are not followed by a test with IS_ERR.
> I can post these other scripts if wanted.
>
>
>
> Any ideas to improve or speed-up the coccinelle scripts are welcome.
> Julia ?
>
>
> Best regards,
> CJ
>
>
>
> Coccinelle script n°1:
> =
> @find@
> identifier f;
> @@
>
>f(...)
>{
>   ...
>   return NULL;

Do you want functions that always return NULL or that may return NULL?
Currently you are getting those that always return NULL, except perhaps
under ifs.  But if you want functions that may return NULL, it would be
better to put exists in the rule header after find.  This will also likely
be more efficient.

>}
>
> @script:python@
> f << find.f;
> @@
>
> print "%s" %(f)
>
>
>
> @find2@
> identifier f;
> expression x;
> statement S;
> @@
>
>x = f(...);
> (
>if (x) S
> |
>if (!x) S
> )

You might want to put ... after x = f(...);, or rather  when != x = e
for some expression metavariable e.

>
> @script:python@
> f << find2.f;
> @@
>
> print "%s" %(f)
>
>
>
>
>
> Coccinelle script n°2:
> =
> @find@
> statement S;
> type t;
> t *x;
> identifier f;
> @@
>
> x = f(...);

Same here about the ...

julia

> (
> if (IS_ERR(x)) S
> |
> if (!IS_ERR(x)) S
> )
>
>
>
> @script:python@
> f << find.f;
> @@
>
> print "%s" %(f)
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding

[Andrew Lunn]

> +- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
> +  TX/RX lanes to function properly.

Is 'requires' the right word here? The PHY performs the actual swap of
the Tx/Rx lanes.

Andrew

Re: [PATCH v2 2/3] irqchip: mtk-cirq: Add mediatek mtk-cirq implement

[Marc Zyngier]

On Tue, Nov 01 2016 at 11:52:01 AM, Youlin Pei  wrote:
> In Mediatek SOCs, the CIRQ is a low power interrupt controller
> designed to works outside MCUSYS which comprises with Cortex-Ax
> cores,CCI and GIC.
>
> The CIRQ controller is integrated in between MCUSYS( include
> Cortex-Ax, CCI and GIC ) and interrupt sources as the second
> level interrupt controller. The external interrupts which outside
> MCUSYS will feed through CIRQ then bypass to GIC. CIRQ can monitors
> all edge trigger interupts. When an edge interrupt is triggered,
> CIRQ can record the status and generate a pulse signal to GIC when
> flush command executed.
>
> When system enters sleep mode, MCUSYS will be turned off to improve
> power consumption, also GIC is power down. The edge trigger interrupts
> will be lost in this scenario without CIRQ.
>
> This commit provides the CIRQ irqchip implement.
>
> Signed-off-by: Youlin Pei 
> ---
>  drivers/irqchip/Makefile   |2 +-
>  drivers/irqchip/irq-mtk-cirq.c |  262 
> 
>  2 files changed, 263 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/irqchip/irq-mtk-cirq.c
>
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index e4dbfc8..8f33580 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -60,7 +60,7 @@ obj-$(CONFIG_BCM7120_L2_IRQ)+= 
> irq-bcm7120-l2.o
>  obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
>  obj-$(CONFIG_KEYSTONE_IRQ)   += irq-keystone.o
>  obj-$(CONFIG_MIPS_GIC)   += irq-mips-gic.o
> -obj-$(CONFIG_ARCH_MEDIATEK)  += irq-mtk-sysirq.o
> +obj-$(CONFIG_ARCH_MEDIATEK)  += irq-mtk-sysirq.o irq-mtk-cirq.o
>  obj-$(CONFIG_ARCH_DIGICOLOR) += irq-digicolor.o
>  obj-$(CONFIG_RENESAS_H8300H_INTC)+= irq-renesas-h8300h.o
>  obj-$(CONFIG_RENESAS_H8S_INTC)   += irq-renesas-h8s.o
> diff --git a/drivers/irqchip/irq-mtk-cirq.c b/drivers/irqchip/irq-mtk-cirq.c
> new file mode 100644
> index 000..fc43ef3
> --- /dev/null
> +++ b/drivers/irqchip/irq-mtk-cirq.c
> @@ -0,0 +1,262 @@
> +/*
> + * Copyright (c) 2016 MediaTek Inc.
> + * Author: Youlin.Pei 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CIRQ_ACK 0x40
> +#define CIRQ_MASK_SET0xc0
> +#define CIRQ_MASK_CLR0x100
> +#define CIRQ_SENS_SET0x180
> +#define CIRQ_SENS_CLR0x1c0
> +#define CIRQ_POL_SET 0x240
> +#define CIRQ_POL_CLR 0x280
> +#define CIRQ_CONTROL 0x300
> +
> +#define CIRQ_EN  0x1
> +#define CIRQ_EDGE0x2
> +#define CIRQ_FLUSH   0x4
> +
> +#define CIRQ_IRQ_NUM0x200
> +
> +struct mtk_cirq_chip_data {
> + void __iomem *base;
> + unsigned int ext_irq_start;
> +};
> +
> +static struct mtk_cirq_chip_data *cirq_data;

Are you guaranteed that you'll only ever have a single CIRQ in any
system?

> +
> +static void mtk_cirq_write_mask(struct irq_data *data, unsigned int offset)
> +{
> + struct mtk_cirq_chip_data *chip_data = data->chip_data;
> + unsigned int cirq_num = data->hwirq;
> + u32 mask = 1 << (cirq_num % 32);
> +
> + writel(mask, chip_data->base + offset + (cirq_num / 32) * 4);

Why can't you use the relaxed accessors?

> +}
> +
> +static void mtk_cirq_mask(struct irq_data *data)
> +{
> + mtk_cirq_write_mask(data, CIRQ_MASK_SET);
> + irq_chip_mask_parent(data);
> +}
> +
> +static void mtk_cirq_unmask(struct irq_data *data)
> +{
> + mtk_cirq_write_mask(data, CIRQ_MASK_CLR);
> + irq_chip_unmask_parent(data);
> +}
> +
> +static void mtk_cirq_eoi(struct irq_data *data)
> +{
> + mtk_cirq_write_mask(data, CIRQ_ACK);

EOI and ACK have very different semantics. What is this write actually
doing? Also, you're now doing an additional MMIO write on each interrupt
EOI, doubling its cost. Do you really need to do actually signal the HW
that we've EOIed an interrupt? I would have hoped that you'd be able to
put it in "bypass" mode as long as you're not suspending...

> + irq_chip_eoi_parent(data);
> +}
> +
> +static int mtk_cirq_set_type(struct irq_data *data, unsigned int type)
> +{
> + int ret;
> +
> + switch (type & IRQ_TYPE_SENSE_MASK) {
> + case IRQ_TYPE_EDGE_FALLING:
> + mtk_cirq_write_mask(data, CIRQ_POL_CLR);
> + mtk_cirq_write_mask(data, CIRQ_SENS_CLR);
> + break;
> + case 

[PATCH] drm/exynos: gsc: fix spelling mistakes

[Colin King]

From: Colin Ian King 

Trivial fixes to spelling mistakes "precalser" to "prescaler"
in dev_err messages

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/exynos/exynos_drm_fimc.c | 2 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 147ef0d..9587157 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1433,7 +1433,7 @@ static int fimc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
_pos[EXYNOS_DRM_OPS_SRC],
_pos[EXYNOS_DRM_OPS_DST]);
if (ret) {
-   dev_err(dev, "failed to set precalser.\n");
+   dev_err(dev, "failed to set prescaler.\n");
return ret;
}
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 52a9d26..bef5798 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1610,7 +1610,7 @@ static int gsc_ippdrv_start(struct device *dev, enum 
drm_exynos_ipp_cmd cmd)
_pos[EXYNOS_DRM_OPS_SRC],
_pos[EXYNOS_DRM_OPS_DST]);
if (ret) {
-   dev_err(dev, "failed to set precalser.\n");
+   dev_err(dev, "failed to set prescaler.\n");
return ret;
}
 
-- 
2.9.3

Re: [PATCH] ARM: spear: Fix error handling

[Viresh Kumar]

On Sat, Oct 29, 2016 at 7:28 PM, Christophe JAILLET
 wrote:
> 'clk_get_sys()' returns an error pointer in case of error, not NULL. So
> test it with IS_ERR.
>
> Signed-off-by: Christophe JAILLET 
> ---
>  arch/arm/mach-spear/time.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Viresh Kumar 

[PATCH 1/1] usb: xhci: remove the use of xhci->addr_dev

[Lu Baolu]

xhci->addr_dev is used for the completion of both address device
and enable slot commands. It's shared by enumerations of all USB
devices connected to an xhci host. Hence, it's just a source for
possible races. Since we've introduced command structure and the
command queue to xhci driver.  It is time to get rid of addr_dev
and use the completion in the command structure instead.

Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci-mem.c |  1 -
 drivers/usb/host/xhci.c | 18 ++
 drivers/usb/host/xhci.h |  1 -
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 6afe323..4c27828 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -2536,7 +2536,6 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
 * something other than the default (~1ms minimum between interrupts).
 * See section 5.5.1.2.
 */
-   init_completion(>addr_dev);
for (i = 0; i < MAX_HC_SLOTS; ++i)
xhci->devs[i] = NULL;
for (i = 0; i < USB_MAXCHILDREN; ++i) {
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ad06243..e254af7 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3683,20 +3683,19 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
int ret, slot_id;
struct xhci_command *command;
 
-   command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
+   command = xhci_alloc_command(xhci, false, true, GFP_KERNEL);
if (!command)
return 0;
 
/* xhci->slot_id and xhci->addr_dev are not thread-safe */
mutex_lock(>mutex);
spin_lock_irqsave(>lock, flags);
-   command->completion = >addr_dev;
ret = xhci_queue_slot_control(xhci, command, TRB_ENABLE_SLOT, 0);
if (ret) {
spin_unlock_irqrestore(>lock, flags);
mutex_unlock(>mutex);
xhci_dbg(xhci, "FIXME: allocate a command ring segment\n");
-   kfree(command);
+   xhci_free_command(xhci, command);
return 0;
}
xhci_ring_cmd_db(xhci);
@@ -3711,7 +3710,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
xhci_err(xhci, "Max number of devices this xHCI host supports 
is %u.\n",
HCS_MAX_SLOTS(
readl(>cap_regs->hcs_params1)));
-   kfree(command);
+   xhci_free_command(xhci, command);
return 0;
}
 
@@ -3747,7 +3746,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 #endif
 
 
-   kfree(command);
+   xhci_free_command(xhci, command);
/* Is this a LS or FS device under a HS hub? */
/* Hub or peripherial? */
return 1;
@@ -3755,6 +3754,7 @@ int xhci_alloc_dev(struct usb_hcd *hcd, struct usb_device 
*udev)
 disable_slot:
/* Disable slot, if we can do it without mem alloc */
spin_lock_irqsave(>lock, flags);
+   kfree(command->completion);
command->completion = NULL;
command->status = 0;
if (!xhci_queue_slot_control(xhci, command, TRB_DISABLE_SLOT,
@@ -3818,14 +3818,13 @@ static int xhci_setup_device(struct usb_hcd *hcd, 
struct usb_device *udev,
}
}
 
-   command = xhci_alloc_command(xhci, false, false, GFP_KERNEL);
+   command = xhci_alloc_command(xhci, false, true, GFP_KERNEL);
if (!command) {
ret = -ENOMEM;
goto out;
}
 
command->in_ctx = virt_dev->in_ctx;
-   command->completion = >addr_dev;
 
slot_ctx = xhci_get_slot_ctx(xhci, virt_dev->in_ctx);
ctrl_ctx = xhci_get_input_control_ctx(virt_dev->in_ctx);
@@ -3943,7 +3942,10 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct 
usb_device *udev,
   le32_to_cpu(slot_ctx->dev_state) & DEV_ADDR_MASK);
 out:
mutex_unlock(>mutex);
-   kfree(command);
+   if (command) {
+   kfree(command->completion);
+   kfree(command);
+   }
return ret;
 }
 
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index f945380..60f254a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1583,7 +1583,6 @@ struct xhci_hcd {
/* slot enabling and address device helpers */
/* these are not thread safe so use mutex */
struct mutex mutex;
-   struct completion   addr_dev;
int slot_id;
/* For USB 3.0 LPM enable/disable. */
struct xhci_command *lpm_command;
-- 
2.1.4

[PATCH RFC 2/4] [media] subdev-formats.rst: we need a pdf picture for bayer

[Mauro Carvalho Chehab]

The png picture is not ok on Sphinx 1.4.8.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/uapi/v4l/subdev-formats.rst |   4 +---
 .../media/uapi/v4l/subdev-formats_files/bayer.pdf   | Bin 0 -> 11131 bytes
 2 files changed, 1 insertion(+), 3 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/subdev-formats_files/bayer.pdf

diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst 
b/Documentation/media/uapi/v4l/subdev-formats.rst
index e144370f62a0..489a685945e2 100644
--- a/Documentation/media/uapi/v4l/subdev-formats.rst
+++ b/Documentation/media/uapi/v4l/subdev-formats.rst
@@ -1515,13 +1515,11 @@ be named ``MEDIA_BUS_FMT_SRGGB10_2X8_PADHI_LE``.
 .. _bayer-patterns:
 
 .. figure::  subdev-formats_files/bayer.*
-:alt:bayer.png
+:alt:bayer.pdf / bayer.png
 :align:  center
 
 **Figure 4.8 Bayer Patterns**
 
-
-
 The following table lists existing packed Bayer formats. The data
 organization is given as an example for the first pixel only.
 
diff --git a/Documentation/media/uapi/v4l/subdev-formats_files/bayer.pdf 
b/Documentation/media/uapi/v4l/subdev-formats_files/bayer.pdf
new file mode 100644
index 
..8ccef608cabd2cfdd6cfb3e80a5055d5cb05d814
GIT binary patch
literal 11131
zcmaKScUV(P_ijKC4I)iIdZhQ>dq+W#9*_W1BE2Ml^dbmI?Y{Z
zMvh)CP!N}mwI3AD4HQ&`L#@3W-QCozy>O_SjEIo1gs_mPu!xAbw1^PSK*!zge{Iu)
zyW4r}Mp(gQKmdjE8Gg4{p_1t8ST?kZ7{e;%^gAFWfA;0%1U0
z7y)4kX*WNbG9rg+R8hz(0AaxdZjDIR4AwFSf7ZT!j{u{+s`+?5_}WkRa|M
z0tp(misSwPj>W(Hu15WLN=AQ3|BDx(prN;o*B|7M4^U9o+7
zxJL#TTEhkR(5XRf-R+=PQv-IiyBd@b(cS?!O_I3(s_riCa6=DkTPR5QYAgmo
zK@~?YPdzAH)!o&@-R)|Uq=15dadI{GKeYWdMBnj^T;f2ZuBM&=dG{C<-g
z>fD~KUJl_A^EkrrY3MKU5>ow-byhzUza%zy*gLFer+~?u{B$<6AI!l|zfSB=vkx9t
zL<{l_{{T~#d*f}JUT+AhJHvEPnE7;_A(?Z=Lgpfb8+%+~cTQ4K6%ll~CH(?!?~c#Xg)W
z(

Re: [PATCH] drm/exynos: gsc: fix spelling mistakes

[Javier Martinez Canillas]

Hello Colin,

On 11/01/2016 11:23 PM, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fixes to spelling mistakes "precalser" to "prescaler"
> in dev_err messages
> 
> Signed-off-by: Colin Ian King 
> ---

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 28/60] block: introduce QUEUE_FLAG_SPLIT_MP

[Kent Overstreet]

On Mon, Oct 31, 2016 at 08:39:15AM -0700, Christoph Hellwig wrote:
> On Sat, Oct 29, 2016 at 04:08:27PM +0800, Ming Lei wrote:
> > Some drivers(such as dm) should be capable of dealing with multipage
> > bvec, but the incoming bio may be too big, such as, a new singlepage bvec
> > bio can't be cloned from the bio, or can't be allocated to singlepage
> > bvec with same size.
> > 
> > At least crypt dm, log writes and bcache have this kind of issue.
> 
> We already have the segment_size limitation for request based drivers.
> I'd rather extent it to bio drivers if really needed.
> 
> But then again we should look into not having this limitation.  E.g.
> for bcache I'd be really surprised if it's that limited, given that
> Kent came up with this whole multipage bvec scheme.

AFAIK the only issue is with drivers that may have to bounce bios - pages that
were contiguous in the original bio won't necessarily be contiguous in the
bounced bio, thus bouncing might require more than BIO_MAX_SEGMENTS bvecs.

I don't know what Ming's referring to by "singlepage bvec bios".

Anyways, bouncing comes up in multiple places so we probably need to come up
with a generic solution for that. Other than that, there shouldn't be any issues
or limitations - if you're not bouncing, there's no need to clone the bvecs.

Re: [PATCH 1/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths

[Hillf Danton]

On Wednesday, November 02, 2016 12:37 AM Mike Kravetz wrote:
> On 10/19/2016 08:11 PM, Mike Kravetz wrote:
> > Error paths in hugetlb_cow() and hugetlb_no_page() may free a newly
> > allocated huge page.  If a reservation was associated with the huge
> > page, alloc_huge_page() consumed the reservation while allocating.
> > When the newly allocated page is freed in free_huge_page(), it will
> > increment the global reservation count.  However, the reservation entry
> > in the reserve map will remain.  This is not an issue for shared
> > mappings as the entry in the reserve map indicates a reservation exists.
> > But, an entry in a private mapping reserve map indicates the reservation
> > was consumed and no longer exists.  This results in an inconsistency
> > between the reserve map and the global reservation count.  This 'leaks'
> > a reserved huge page.
> >
> > Create a new routine restore_reserve_on_error() to restore the reserve
> > entry in these specific error paths.  This routine makes use of a new
> > function vma_add_reservation() which will add a reserve entry for a
> > specific address/page.
> >
> > In general, these error paths were rarely (if ever) taken on most
> > architectures.  However, powerpc contained arch specific code that
> > that resulted in an extra fault and execution of these error paths
> > on all private mappings.
> >
> > Fixes: 67961f9db8c4 ("mm/hugetlb: fix huge page reserve accounting for 
> > private mappings)
> >
> 
> Any additional comments on this?
> 
> It does address a regression with private mappings that appears to only be
> visible on powerpc.  Aneesh submitted a patch to workaround the issue on
> powerpc that is in mmotm/linux-next (71271479df7e/955f9aa468e0).  Aneesh's
> patch makes the symptoms go away.  This patch addresses root cause.
> 
Both works are needed, thanks.

Acked-by: Hillf Danton 

Re: [RFC PATCH 0/6] UART slave devices using serio

[Rob Herring]

On Mon, Oct 31, 2016 at 10:40 PM, Rob Herring  wrote:
> On Mon, Oct 31, 2016 at 3:00 PM, Peter Hurley  
> wrote:
>> On Tue, Oct 25, 2016 at 4:02 PM, Rob Herring  wrote:
>>>
>>> > Maybe you can try to find some minutes at the Kernel Summit to talk
>>> > about this?
>>>
>>> Still waiting for my invite...
>>>
>>> But I will be at Plumbers if folks want to discuss this.
>>
>>
>> Hey Rob,
>>
>> I'm here so let's make time to discuss this.
>
> Tomorrow should be good for me after the complex device dependencies 
> discussion.

I have a somewhat working branch using ttyport and serio here[1]. It
works with a BT device to the level the device works with my PC which
is only identifying the BCM device and loading the firmware.

I'm still not sure using serio really buys us much. We probably want
to hide some of the sysfs files when using DT binding. It also
provides a file to reconnect devices. I suppose this is because there
is typically no hotplug detection on PS/2 ports? Serio also provides
its own async binding mechanism. Perhaps this can be updated to use
async probing?

The registration of serio ports is a bit problematic. I had the tty
port registration call into the serio ttyport driver to register, but
this broke serio working as a module. While serial drivers can be
modules, the tty_port code is always built-in. So the serio ttyport
driver will request a callback for all tty ports when the serio driver
is loaded. This means any tty driver hotplugged after serio will not
be registered with serio. The only other solution I see is serio would
have to be built-in.

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git serio-tty-slave

Re: tmpfs returns incorrect data on concurrent pread() and truncate()

[Dave Chinner]

On Tue, Nov 01, 2016 at 06:38:26PM -0700, Hugh Dickins wrote:
> On Wed, 2 Nov 2016, Dave Chinner wrote:
> > On Tue, Nov 01, 2016 at 04:51:30PM -0700, Hugh Dickins wrote:
> > > On Wed, 26 Oct 2016, Jakob Unterwurzacher wrote:
> > > 
> > > > tmpfs seems to be incorrectly returning 0-bytes when reading from
> > > > a file that is concurrently being truncated.
> > > 
> > > That is an interesting observation, and you got me worried;
> > > but in fact, it is not a tmpfs problem: if we call it a
> > > problem at all, it's a VFS problem or a userspace problem.
> > > 
> > > You chose a ratio of 3 preads to 1 ftruncate in your program below:
> > > let's call that the Unterwurzacher Ratio, 3 for tmpfs; YMMV, but for
> > > me 4 worked well to show the same issue on ramfs, and 15 on ext4.
> > > 
> > > The Linux VFS does not serialize reads against writes or truncation
> > > very strictly:
> > 
> > Which is a fine, because...
> > 
> > > it's unusual to need that serialization, and most
> > 
> >  many filesystems need more robust serialisation as hole punching
> > (and other fallocate-based extent manipulations) have much stricter
> > serialisation requirements than truncate and these 
> > 
> > > users prefer maximum speed to the additional locking, or intermediate
> > > buffering, that would be required to avoid the issue you've seen.
> > 
> >  require additional locking to be done at the filesystem level
> > to avoid race conditions.
> > 
> > Throw in the fact that we already have to do this serialisation in
> > the filesystem for direct IO as there are no page locks to serialise
> > direct IO against truncate.  And we need to lock out page faults
> > from refaulting while we are doing things like punching holes (to
> > avoid data coherency and corruption bugs), so we need more
> > filesystem level locks to serialise mmap against fallocate().
> > 
> > And DAX has similar issues - there are no struct pages to serialise
> > read or mmap access against truncate, so again we need filesystem
> > level serialisation for this.
> > 
> > Put simple: page locks are insufficient as a generic mechanism for
> > serialising filesystem operations. The locking required for this is
> > generally deeply filesystem implementation specific, so it's fine
> > that the VFS doesn't attempt to provide anything stricter than it
> > currently does
> 
> I think you are saying that: xfs already provides the extra locking
> that avoids this issue; most other filesystems do not; but more can
> be expected to add that extra locking in the coming months?

Effectively, yes. ext4 already has the extra mmap lock for DAX,
and it's likely to get saner internal IO locking as it is converted
to use iomaps (which is also needed for DAX).

As I've pointed out in a different thread recently, filesystems now
have three IO paths - page cache, direct and DAX - and only the page
cache IO uses struct pages. The other IO paths don't, and they still
have to be serialised against truncate and other operations. IOWs,
if a filesystem wants to support the new incoming storage
technologies, it has to do this IO serialisation internally
regardless of whatever other optimisations and go-fast paths the
page cache has...

Cheers,

Dave.

-- 
Dave Chinner
da...@fromorbit.com

Re: [Qemu-devel] [PATCH v9 04/12] vfio iommu: Add support for mediated devices

[Alexey Kardashevskiy]

On 02/11/16 14:29, Kirti Wankhede wrote:
> 
> 
> On 11/2/2016 6:54 AM, Alexey Kardashevskiy wrote:
>> On 02/11/16 01:01, Kirti Wankhede wrote:
>>>
>>>
>>> On 10/28/2016 7:48 AM, Alexey Kardashevskiy wrote:
 On 27/10/16 23:31, Kirti Wankhede wrote:
>
>
> On 10/27/2016 12:50 PM, Alexey Kardashevskiy wrote:
>> On 18/10/16 08:22, Kirti Wankhede wrote:
>>> VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
>>> Mediated device only uses IOMMU APIs, the underlying hardware can be
>>> managed by an IOMMU domain.
>>>
>>> Aim of this change is:
>>> - To use most of the code of TYPE1 IOMMU driver for mediated devices
>>> - To support direct assigned device and mediated device in single module
>>>
>>> Added two new callback functions to struct vfio_iommu_driver_ops. 
>>> Backend
>>> IOMMU module that supports pining and unpinning pages for mdev devices
>>> should provide these functions.
>>> Added APIs for pining and unpining pages to VFIO module. These calls 
>>> back
>>> into backend iommu module to actually pin and unpin pages.
>>>
>>> This change adds pin and unpin support for mediated device to TYPE1 
>>> IOMMU
>>> backend module. More details:
>>> - When iommu_group of mediated devices is attached, task structure is
>>>   cached which is used later to pin pages and page accounting.
>>
>>
>> For SPAPR TCE IOMMU driver, I ended up caching mm_struct with
>> atomic_inc(>mm->mm_count) (patches are on the way) instead of
>> using @current or task as the process might be gone while VFIO container 
>> is
>> still alive and @mm might be needed to do proper cleanup; this might not 
>> be
>> an issue with this patchset now but still you seem to only use @mm from
>> task_struct.
>>
>
> Consider the example of QEMU process which creates VFIO container, QEMU
> in its teardown path would release the container. How could container be
> alive when process is gone?

 do_exit() in kernel/exit.c calls exit_mm() (which sets NULL to tsk->mm)
 first, and then releases open files by calling  exit_files(). So
 container's release() does not have current->mm.

>>>
>>> Incrementing usage count (get_task_struct()) while saving task structure
>>> and decementing it (put_task_struct()) from release() should  work here.
>>> Updating the patch.
>>
>> I cannot see how the task->usage counter prevents do_exit() from performing
>> the exit, can you?
>>
> 
> It will not prevent exit from do_exit(), but that will make sure that we
> don't have stale pointer of task structure. Then we can check whether
> the task is alive and get mm pointer in teardown path as below:


Or you could just reference and use @mm as KVM and others do. Or there is
anything else you need from @current than just @mm?


> 
> {
> struct task_struct *task = domain->external_addr_space->task;
> struct mm_struct *mm = NULL;
> 
> put_pfn(pfn, prot);
> 
> if (pid_alive(task))
> mm = get_task_mm(task);
> 
> if (mm) {
> if (do_accounting)
> vfio_lock_acct(task, -1);
> 
> mmput(mm);
> }
> }



-- 
Alexey

[PATCH v2] EFI loader: remove redundant code

[Eugene Korenevsky]

*e820ext is always NULL in 'alloc_e820ext()' (see the code of 'exit_boot()').
Without loss of generality we can replace freeing with returning
EFI_INVALID_PARAMETER. So if the caller would ever incorrectly pass non-NULL
*e820ext, he will obtain a returned error code.

---
 arch/x86/boot/compressed/eboot.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/x86/boot/compressed/eboot.c b/arch/x86/boot/compressed/eboot.c
index cc69e37..6cc66c7 100644
--- a/arch/x86/boot/compressed/eboot.c
+++ b/arch/x86/boot/compressed/eboot.c
@@ -956,11 +956,8 @@ static efi_status_t alloc_e820ext(u32 nr_desc, struct 
setup_data **e820ext,
size = sizeof(struct setup_data) +
sizeof(struct e820entry) * nr_desc;
 
-   if (*e820ext) {
-   efi_call_early(free_pool, *e820ext);
-   *e820ext = NULL;
-   *e820ext_size = 0;
-   }
+   if (*e820ext)
+   return EFI_INVALID_PARAMETER;
 
status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
size, (void **)e820ext);
-- 
2.10.2

RE: [PATCH v3 3/3] clocksource: Add clockevent support to NPS400 driver

[Thomas Gleixner]

On Tue, 1 Nov 2016, Noam Camus wrote:
> >> +static int nps_clkevent_set_next_event(unsigned long delta,
> >> + struct clock_event_device *dev) {
> >> +  struct irq_desc *desc = irq_to_desc(nps_timer0_irq);
> >> +  struct irq_chip *chip = irq_data_get_irq_chip(>irq_data);
> >> +
> >> +  nps_clkevent_add_thread(true);
> >> +  chip->irq_unmask(>irq_data);
> 

> > Oh no. You are not supposed to fiddle in the guts of the interrupts
> > from a random driver. Can you please explain what you are trying to do
> > and why the existing interfaces are> > not sufficient?

> This function is assigned and used by several hooks at clock_event_device
> type.  Main purpose is to support oneshot timer mode and in general
> support NOHZ_FULL and finally TASK_ISOLATION.

What has the fact that you fiddle in the irq desc to do with nohz full and
isolation?

> The idea for this is borrowed from arch/tile timer driver that just like
> us aiming to support the TASK_ISOLATION.

Which does not make it any better.

> Will it be better to replace these with
> irq_percpu_enable()/irq_percpu_disable() which seem to achieve quiet the
> same affect?

Correct. Not using existing functions is always a bad idea.

> 
> >> +static int nps_clkevent_set_periodic(struct clock_event_device *dev) 
> >> +{
> >> +  nps_clkevent_add_thread(false);
> >> +  if (read_aux_reg(CTOP_AUX_THREAD_ID) == 0)
> >> +  nps_clkevent_timer_event_setup(nps_timer0_freq / HZ);
> 
> >So how is that enabling interrupts again?

> I guess that in our system we never switch back to periodic.  Time
> infrastructure starts as periodic (I set CLOCK_EVT_FEAT_PERIODIC) and
> when timer is ready state is switched to oneshot mode and never goes back
> to periodic.  I might be missing here, but couldn't find any place where
> CLOCK_EVT_STATE_PERIODIC is set but in tick_setup_periodic().  Should I
> call here to enable interrupts anyway?

Right. We never switch back to periodic when we are in one shot mode. So,
you can spare that call.

> >> +  ret = cpuhp_setup_state(CPUHP_AP_NPS_TIMER_STARTING,
> >> +  "AP_NPS_TIMER_STARTING",
> >
> >Please make this "clockevents/nps:starting"
> Sorry but I can't see any similar thing all around.
> Could you explain why you prefer this format for the string?

Because its way better to read. We messed that up when we started the
conversion and switched over to the more informative strings later. Still
need to fixup the existing state derived strings.

Thanks,

tglx

[[PATCH repost v21] 03/11] doc: fpga-mgr: add fpga image info to api

[Alan Tull]

This patch adds a minor change in the FPGA Manager API
to hold information that is specific to an FPGA image
file.  This change is expected to bring little, if any,
pain.

An FPGA image file will have particulars that affect how the
image is programmed to the FPGA.  One example is that
current 'flags' currently has one bit which shows whether the
FPGA image was built for full reconfiguration or partial
reconfiguration.  Another example is timeout values for
enabling or disabling the bridges in the FPGA.  As the
complexity of the FPGA design increases, the bridges in the
FPGA may take longer times to enable or disable.

This patch documents the change in the FPGA Manager API
functions, replacing the 'u32 flag' parameter with a pointer
to struct fpga_image_info.

Signed-off-by: Alan Tull 
Acked-by: Moritz Fischer 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/fpga/fpga-mgr.txt | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/Documentation/fpga/fpga-mgr.txt b/Documentation/fpga/fpga-mgr.txt
index d056d69..087924f 100644
--- a/Documentation/fpga/fpga-mgr.txt
+++ b/Documentation/fpga/fpga-mgr.txt
@@ -18,21 +18,25 @@ API Functions:
 To program the FPGA from a file or from a buffer:
 -
 
-   int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags,
+   int fpga_mgr_buf_load(struct fpga_manager *mgr,
+ struct fpga_image_info *info,
  const char *buf, size_t count);
 
 Load the FPGA from an image which exists as a buffer in memory.
 
-   int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags,
+   int fpga_mgr_firmware_load(struct fpga_manager *mgr,
+  struct fpga_image_info *info,
   const char *image_name);
 
 Load the FPGA from an image which exists as a file.  The image file must be on
-the firmware search path (see the firmware class documentation).
-
-For both these functions, flags == 0 for normal full reconfiguration or
-FPGA_MGR_PARTIAL_RECONFIG for partial reconfiguration.  If successful, the FPGA
-ends up in operating mode.  Return 0 on success or a negative error code.
+the firmware search path (see the firmware class documentation).  If 
successful,
+the FPGA ends up in operating mode.  Return 0 on success or a negative error
+code.
 
+A FPGA design contained in a FPGA image file will likely have particulars that
+affect how the image is programmed to the FPGA.  These are contained in struct
+fpga_image_info.  Currently the only such particular is a single flag bit
+indicating whether the image is for full or partial reconfiguration.
 
 To get/put a reference to a FPGA manager:
 -
@@ -72,8 +76,11 @@ struct device_node *mgr_node = ...
 char *buf = ...
 int count = ...
 
+/* struct with information about the FPGA image to program. */
+struct fpga_image_info info;
+
 /* flags indicates whether to do full or partial reconfiguration */
-int flags = 0;
+info.flags = 0;
 
 int ret;
 
@@ -81,7 +88,7 @@ int ret;
 struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
 
 /* Load the buffer to the FPGA */
-ret = fpga_mgr_buf_load(mgr, flags, buf, count);
+ret = fpga_mgr_buf_load(mgr, , buf, count);
 
 /* Release the FPGA manager */
 fpga_mgr_put(mgr);
@@ -98,8 +105,11 @@ struct device_node *mgr_node = ...
 /* FPGA image is in this file which is in the firmware search path */
 const char *path = "fpga-image-9.rbf"
 
+/* struct with information about the FPGA image to program. */
+struct fpga_image_info info;
+
 /* flags indicates whether to do full or partial reconfiguration */
-int flags = 0;
+info.flags = 0;
 
 int ret;
 
@@ -107,7 +117,7 @@ int ret;
 struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
 
 /* Get the firmware image (path) and load it to the FPGA */
-ret = fpga_mgr_firmware_load(mgr, flags, path);
+ret = fpga_mgr_firmware_load(mgr, , path);
 
 /* Release the FPGA manager */
 fpga_mgr_put(mgr);
-- 
1.9.1

Re: [PATCH] UBIFS: Remove some dead code

[Christophe JAILLET]

Le 01/11/2016 à 12:42, Richard Weinberger a écrit :

On 01.11.2016 07:45, Christophe JAILLET wrote:

'ubifs_fast_find_freeable()' can not return an error pointer, so this test
can be removed.

Signed-off-by: Christophe JAILLET 
---
  fs/ubifs/gc.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index e845c64b6ce1..7b35e3d6cde7 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -846,10 +846,6 @@ int ubifs_gc_start_commit(struct ubifs_info *c)
 */
while (1) {
lp = ubifs_fast_find_freeable(c);
-   if (IS_ERR(lp)) {
-   err = PTR_ERR(lp);
-   goto out;
-   }

Good catch, how did you find this?
If you have a tool/script I'd like to use it too.

Thanks,
//richard
--


Hi,
well, it is a bit tricky.

AFAIK, coccinelle is only able to match things in a given file. Finding 
issues between 2 files can be tricky.


So first, I have built a list a functions which are likely to return 
NULL, either because they explicitly return NULL or if its return value 
is tested against NULL or not. See coccinelle script n°1 below.
Then I have built a list of functions followed by a test with IS_ERR. 
See coccinelle script n°2 below.


These 2 scripts generate 2 lists of functions.
If a function is present in the 2 files, it is likely that something is 
spurious.


Either the IS_ERR is not needed (this is the case in the patch above), 
either the return value is incorrectly checked. Could also be that NULL 
is returned but an error pointer would be a better option.



I also did more or less the same for functions that return PTR_ERR and 
functions that are not followed by a test with IS_ERR.

I can post these other scripts if wanted.



Any ideas to improve or speed-up the coccinelle scripts are welcome.
Julia ?


Best regards,
CJ



Coccinelle script n°1:
=
@find@
identifier f;
@@

   f(...)
   {
  ...
  return NULL;
   }

@script:python@
f << find.f;
@@

print "%s" %(f)



@find2@
identifier f;
expression x;
statement S;
@@

   x = f(...);
(
   if (x) S
|
   if (!x) S
)

@script:python@
f << find2.f;
@@

print "%s" %(f)





Coccinelle script n°2:
=
@find@
statement S;
type t;
t *x;
identifier f;
@@

x = f(...);
(
if (IS_ERR(x)) S
|
if (!IS_ERR(x)) S
)



@script:python@
f << find.f;
@@

print "%s" %(f)

[[PATCH repost v21] 06/11] add sysfs document for fpga bridge class

[Alan Tull]

Add documentation for new FPGA bridge class's sysfs interface.

Signed-off-by: Alan Tull 
Acked-by: Moritz Fischer 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/ABI/testing/sysfs-class-fpga-bridge | 11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge

diff --git a/Documentation/ABI/testing/sysfs-class-fpga-bridge 
b/Documentation/ABI/testing/sysfs-class-fpga-bridge
new file mode 100644
index 000..312ae2c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge
@@ -0,0 +1,11 @@
+What:  /sys/class/fpga_bridge//name
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Name of low level FPGA bridge driver.
+
+What:  /sys/class/fpga_bridge//state
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Show bridge state as "enabled" or "disabled"
-- 
1.9.1

[[PATCH repost v21] 10/11] fpga: add altera freeze bridge support

[Alan Tull]

Add a low level driver for Altera Freeze Bridges to the FPGA Bridge
framework.  A freeze bridge is a bridge that exists in the FPGA
fabric to isolate one region of the FPGA from the busses while that
one region is being reprogrammed.

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/fpga/Kconfig|   9 ++
 drivers/fpga/Makefile   |   1 +
 drivers/fpga/altera-freeze-bridge.c | 273 
 3 files changed, 283 insertions(+)
 create mode 100644 drivers/fpga/altera-freeze-bridge.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 5605ad6..8fe6a84 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -47,6 +47,15 @@ config SOCFPGA_FPGA_BRIDGE
  Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
  devices.
 
+config ALTERA_FREEZE_BRIDGE
+   tristate "Altera FPGA Freeze Bridge"
+   depends on ARCH_SOCFPGA && FPGA_BRIDGE
+   help
+ Say Y to enable drivers for Altera FPGA Freeze bridges.  A
+ freeze bridge is a bridge that exists in the FPGA fabric to
+ isolate one region of the FPGA from the busses while that
+ region is being reprogrammed.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index e658436..a6f874d 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
 obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
+obj-$(CONFIG_ALTERA_FREEZE_BRIDGE) += altera-freeze-bridge.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_REGION)  += fpga-region.o
diff --git a/drivers/fpga/altera-freeze-bridge.c 
b/drivers/fpga/altera-freeze-bridge.c
new file mode 100644
index 000..8dcd9fb
--- /dev/null
+++ b/drivers/fpga/altera-freeze-bridge.c
@@ -0,0 +1,273 @@
+/*
+ * FPGA Freeze Bridge Controller
+ *
+ *  Copyright (C) 2016 Altera Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+#define FREEZE_CSR_STATUS_OFFSET   0
+#define FREEZE_CSR_CTRL_OFFSET 4
+#define FREEZE_CSR_ILLEGAL_REQ_OFFSET  8
+#define FREEZE_CSR_REG_VERSION 12
+
+#define FREEZE_CSR_SUPPORTED_VERSION   2
+
+#define FREEZE_CSR_STATUS_FREEZE_REQ_DONE  BIT(0)
+#define FREEZE_CSR_STATUS_UNFREEZE_REQ_DONEBIT(1)
+
+#define FREEZE_CSR_CTRL_FREEZE_REQ BIT(0)
+#define FREEZE_CSR_CTRL_RESET_REQ  BIT(1)
+#define FREEZE_CSR_CTRL_UNFREEZE_REQ   BIT(2)
+
+#define FREEZE_BRIDGE_NAME "freeze"
+
+struct altera_freeze_br_data {
+   struct device *dev;
+   void __iomem *base_addr;
+   bool enable;
+};
+
+/*
+ * Poll status until status bit is set or we have a timeout.
+ */
+static int altera_freeze_br_req_ack(struct altera_freeze_br_data *priv,
+   u32 timeout, u32 req_ack)
+{
+   struct device *dev = priv->dev;
+   void __iomem *csr_illegal_req_addr = priv->base_addr +
+FREEZE_CSR_ILLEGAL_REQ_OFFSET;
+   u32 status, illegal, ctrl;
+   int ret = -ETIMEDOUT;
+
+   do {
+   illegal = readl(csr_illegal_req_addr);
+   if (illegal) {
+   dev_err(dev, "illegal request detected 0x%x", illegal);
+
+   writel(1, csr_illegal_req_addr);
+
+   illegal = readl(csr_illegal_req_addr);
+   if (illegal)
+   dev_err(dev, "illegal request not cleared 0x%x",
+   illegal);
+
+   ret = -EINVAL;
+   break;
+   }
+
+   status = readl(priv->base_addr + FREEZE_CSR_STATUS_OFFSET);
+   dev_dbg(dev, "%s %x %x\n", __func__, status, req_ack);
+   status &= req_ack;
+   if (status) {
+   ctrl = readl(priv->base_addr + FREEZE_CSR_CTRL_OFFSET);
+   dev_dbg(dev, "%s request %x acknowledged %x %x\n",
+

Re: [PATCH] UBIFS: Remove some dead code

[Julia Lawall]

On Tue, 1 Nov 2016, Christophe JAILLET wrote:

> Le 01/11/2016 à 12:42, Richard Weinberger a écrit :
> > On 01.11.2016 07:45, Christophe JAILLET wrote:
> > > 'ubifs_fast_find_freeable()' can not return an error pointer, so this test
> > > can be removed.
> > >
> > > Signed-off-by: Christophe JAILLET 
> > > ---
> > >   fs/ubifs/gc.c | 4 
> > >   1 file changed, 4 deletions(-)
> > >
> > > diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
> > > index e845c64b6ce1..7b35e3d6cde7 100644
> > > --- a/fs/ubifs/gc.c
> > > +++ b/fs/ubifs/gc.c
> > > @@ -846,10 +846,6 @@ int ubifs_gc_start_commit(struct ubifs_info *c)
> > >*/
> > >   while (1) {
> > >   lp = ubifs_fast_find_freeable(c);
> > > - if (IS_ERR(lp)) {
> > > - err = PTR_ERR(lp);
> > > - goto out;
> > > - }
> > Good catch, how did you find this?
> > If you have a tool/script I'd like to use it too.
> >
> > Thanks,
> > //richard
> > --
>
> Hi,
> well, it is a bit tricky.
>
> AFAIK, coccinelle is only able to match things in a given file. Finding issues
> between 2 files can be tricky.
>
> So first, I have built a list a functions which are likely to return NULL,
> either because they explicitly return NULL or if its return value is tested
> against NULL or not. See coccinelle script n°1 below.
> Then I have built a list of functions followed by a test with IS_ERR. See
> coccinelle script n°2 below.
>
> These 2 scripts generate 2 lists of functions.
> If a function is present in the 2 files, it is likely that something is
> spurious.
>
> Either the IS_ERR is not needed (this is the case in the patch above), either
> the return value is incorrectly checked. Could also be that NULL is returned
> but an error pointer would be a better option.
>
>
> I also did more or less the same for functions that return PTR_ERR and
> functions that are not followed by a test with IS_ERR.
> I can post these other scripts if wanted.
>
>
>
> Any ideas to improve or speed-up the coccinelle scripts are welcome.
> Julia ?

I made a combination of an OCaml program and a Coccinelle script to
collect the error codes (-ENOMEM, etc) that a function is returning, fully
interprocedurally throughout the kernel.  I think it ran for 17 iterations
until reaching a fixed point.  For the information I collected, it ran in
a few hours on an 8 core machine.  I think it could be repurposed to address
this NULL vs ERR_PTR problem.  I'm rolling through the Dutch countryside at
the moment, but I could take a look tomorrow.  Without going to a full
fixpoint iteration, the above strategy looks reasonable.  It could be
interesting to compare the results.  My fixpoint strategy gives up on
function pointers, so it is not completely accurate either.

julia

Re: [PATCH v4] usb: musb: remove duplicated actions

[Bin Liu]

Hi,

On Wed, Oct 26, 2016 at 09:10:07PM +0300, Kirill Esipov wrote:
> Removing unnecessary duplicated actions that we've got while merging:
> 19915e623458 ("Merge 4.1-rc7 into usb-next")
> 
> Signed-off-by: Kirill Esipov 

Applied. Thanks.

Regards,
-Bin.

> ---
>  drivers/usb/musb/musb_core.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index 27dadc0..e01116e 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -2114,11 +2114,6 @@ musb_init_controller(struct device *dev, int nIrq, 
> void __iomem *ctrl)
>   musb->io.ep_offset = musb_flat_ep_offset;
>   musb->io.ep_select = musb_flat_ep_select;
>   }
> - /* And override them with platform specific ops if specified. */
> - if (musb->ops->ep_offset)
> - musb->io.ep_offset = musb->ops->ep_offset;
> - if (musb->ops->ep_select)
> - musb->io.ep_select = musb->ops->ep_select;
>  
>   /* At least tusb6010 has its own offsets */
>   if (musb->ops->ep_offset)
> -- 
> 2.7.4
> 

[PATCH] drm/via: use get_user_pages_unlocked()

[Lorenzo Stoakes]

Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.

Signed-off-by: Lorenzo Stoakes 
---
 drivers/gpu/drm/via/via_dmablit.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/via/via_dmablit.c 
b/drivers/gpu/drm/via/via_dmablit.c
index 1a3ad76..98aae98 100644
--- a/drivers/gpu/drm/via/via_dmablit.c
+++ b/drivers/gpu/drm/via/via_dmablit.c
@@ -238,13 +238,9 @@ via_lock_all_dma_pages(drm_via_sg_info_t *vsg,  
drm_via_dmablit_t *xfer)
vsg->pages = vzalloc(sizeof(struct page *) * vsg->num_pages);
if (NULL == vsg->pages)
return -ENOMEM;
-   down_read(>mm->mmap_sem);
-   ret = get_user_pages((unsigned long)xfer->mem_addr,
-vsg->num_pages,
-(vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 
0,
-vsg->pages, NULL);
-
-   up_read(>mm->mmap_sem);
+   ret = get_user_pages_unlocked((unsigned long)xfer->mem_addr,
+   vsg->num_pages, vsg->pages,
+   (vsg->direction == DMA_FROM_DEVICE) ? FOLL_WRITE : 0);
if (ret != vsg->num_pages) {
if (ret < 0)
return ret;
-- 
2.10.2

[PATCH] drivers/virt: use get_user_pages_unlocked()

[Lorenzo Stoakes]

Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.

Signed-off-by: Lorenzo Stoakes 
---
 drivers/virt/fsl_hypervisor.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
index 150ce2a..d3eca87 100644
--- a/drivers/virt/fsl_hypervisor.c
+++ b/drivers/virt/fsl_hypervisor.c
@@ -243,11 +243,8 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user 
*p)
sg_list = PTR_ALIGN(sg_list_unaligned, sizeof(struct fh_sg_list));
 
/* Get the physical addresses of the source buffer */
-   down_read(>mm->mmap_sem);
-   num_pinned = get_user_pages(param.local_vaddr - lb_offset,
-   num_pages, (param.source == -1) ? 0 : FOLL_WRITE,
-   pages, NULL);
-   up_read(>mm->mmap_sem);
+   num_pinned = get_user_pages_unlocked(param.local_vaddr - lb_offset,
+   num_pages, pages, (param.source == -1) ? 0 : FOLL_WRITE);
 
if (num_pinned != num_pages) {
/* get_user_pages() failed */
-- 
2.10.2

[PATCH] platform: goldfish: pipe: use get_user_pages_unlocked()

[Lorenzo Stoakes]

Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.

Signed-off-by: Lorenzo Stoakes 
---
 drivers/platform/goldfish/goldfish_pipe.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
b/drivers/platform/goldfish/goldfish_pipe.c
index 1aba2c7..2b21033 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -308,10 +308,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp, 
char __user *buffer,
 * returns a small amount, then there's no need to pin that
 * much memory to the process.
 */
-   down_read(>mm->mmap_sem);
-   ret = get_user_pages(address, 1, is_write ? 0 : FOLL_WRITE,
-   , NULL);
-   up_read(>mm->mmap_sem);
+   ret = get_user_pages_unlocked(address, 1, ,
+   is_write ? 0 : FOLL_WRITE);
if (ret < 0)
break;
 
-- 
2.10.2

[PATCH] rapidio: use get_user_pages_unlocked()

[Lorenzo Stoakes]

Moving from get_user_pages() to get_user_pages_unlocked() simplifies the code
and takes advantage of VM_FAULT_RETRY functionality when faulting in pages.

Signed-off-by: Lorenzo Stoakes 
---
 drivers/rapidio/devices/rio_mport_cdev.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
b/drivers/rapidio/devices/rio_mport_cdev.c
index 9013a58..5fdd081 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -889,13 +889,11 @@ rio_dma_transfer(struct file *filp, u32 transfer_mode,
goto err_req;
}
 
-   down_read(>mm->mmap_sem);
-   pinned = get_user_pages(
+   pinned = get_user_pages_unlocked(
(unsigned long)xfer->loc_addr & PAGE_MASK,
nr_pages,
-   dir == DMA_FROM_DEVICE ? FOLL_WRITE : 0,
-   page_list, NULL);
-   up_read(>mm->mmap_sem);
+   page_list,
+   dir == DMA_FROM_DEVICE ? FOLL_WRITE : 0);
 
if (pinned != nr_pages) {
if (pinned < 0) {
-- 
2.10.2

[PATCH v4 7/7] arm64: dts: NS2: add AMAC ethernet support

[Jon Mason]

Add support for the AMAC ethernet to the Broadcom Northstar2 SoC device
tree

Signed-off-by: Jon Mason 
---
 arch/arm64/boot/dts/broadcom/ns2-svk.dts |  5 +
 arch/arm64/boot/dts/broadcom/ns2.dtsi| 12 
 2 files changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index 2d7872a..2e4d90d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -56,6 +56,10 @@
};
 };
 
+ {
+   status = "ok";
+};
+
 _phy0 {
status = "ok";
 };
@@ -172,6 +176,7 @@
 _mux_iproc {
mdio@10 {
gphy0: eth-phy@10 {
+   enet-phy-lane-swap;
reg = <0x10>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index d95dc40..773ed59 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -191,6 +191,18 @@
 
#include "ns2-clock.dtsi"
 
+   enet: ethernet@6100 {
+   compatible = "brcm,ns2-amac";
+   reg = <0x6100 0x1000>,
+ <0x6109 0x1000>,
+ <0x6103 0x100>;
+   reg-names = "amac_base", "idm_base", "nicpm_base";
+   interrupts = ;
+   phy-handle = <>;
+   phy-mode = "rgmii";
+   status = "disabled";
+   };
+
dma0: dma@6136 {
compatible = "arm,pl330", "arm,primecell";
reg = <0x6136 0x1000>;
-- 
2.7.4

[PATCH v4 6/7] net: ethernet: bgmac: add NS2 support

[Jon Mason]

Add support for the variant of amac hardware present in the Broadcom
Northstar2 based SoCs.  Northstar2 requires an additional register to be
configured with the port speed/duplexity (NICPM).  This can be added to
the link callback to hide it from the instances that do not use this.
Also, clearing of the pending interrupts on init is required due to
observed issues on some platforms.

Signed-off-by: Jon Mason 
---
 drivers/net/ethernet/broadcom/bgmac-platform.c | 56 +-
 drivers/net/ethernet/broadcom/bgmac.c  |  3 ++
 drivers/net/ethernet/broadcom/bgmac.h  |  1 +
 3 files changed, 58 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index aed5dc5..f6d48c7 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -14,12 +14,21 @@
 #define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include "bgmac.h"
 
+#define NICPM_IOMUX_CTRL   0x0008
+
+#define NICPM_IOMUX_CTRL_INIT_VAL  0x3196e000
+#define NICPM_IOMUX_CTRL_SPD_SHIFT 10
+#define NICPM_IOMUX_CTRL_SPD_10M   0
+#define NICPM_IOMUX_CTRL_SPD_100M  1
+#define NICPM_IOMUX_CTRL_SPD_1000M 2
+
 static u32 platform_bgmac_read(struct bgmac *bgmac, u16 offset)
 {
return readl(bgmac->plat.base + offset);
@@ -87,12 +96,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac 
*bgmac, u16 offset,
WARN_ON(1);
 }
 
+static void bgmac_nicpm_speed_set(struct net_device *net_dev)
+{
+   struct bgmac *bgmac = netdev_priv(net_dev);
+   u32 val;
+
+   if (!bgmac->plat.nicpm_base)
+   return;
+
+   val = NICPM_IOMUX_CTRL_INIT_VAL;
+   switch (bgmac->net_dev->phydev->speed) {
+   default:
+   pr_err("Unsupported speed.  Defaulting to 1000Mb\n");
+   case SPEED_1000:
+   val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   case SPEED_100:
+   val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   case SPEED_10:
+   val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
+   break;
+   }
+
+   writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
+
+   bgmac_adjust_link(bgmac->net_dev);
+}
+
 static int platform_phy_connect(struct bgmac *bgmac)
 {
struct phy_device *phy_dev;
 
-   phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
-bgmac_adjust_link);
+   if (bgmac->plat.nicpm_base)
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+bgmac->dev->of_node,
+bgmac_nicpm_speed_set);
+   else
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev,
+bgmac->dev->of_node,
+bgmac_adjust_link);
if (!phy_dev) {
dev_err(bgmac->dev, "Phy connect failed\n");
return -ENODEV;
@@ -182,6 +225,14 @@ static int bgmac_probe(struct platform_device *pdev)
if (IS_ERR(bgmac->plat.idm_base))
return PTR_ERR(bgmac->plat.idm_base);
 
+   regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
+   if (regs) {
+   bgmac->plat.nicpm_base = devm_ioremap_resource(>dev,
+  regs);
+   if (IS_ERR(bgmac->plat.nicpm_base))
+   return PTR_ERR(bgmac->plat.nicpm_base);
+   }
+
bgmac->read = platform_bgmac_read;
bgmac->write = platform_bgmac_write;
bgmac->idm_read = platform_bgmac_idm_read;
@@ -213,6 +264,7 @@ static int bgmac_remove(struct platform_device *pdev)
 static const struct of_device_id bgmac_of_enet_match[] = {
{.compatible = "brcm,amac",},
{.compatible = "brcm,nsp-amac",},
+   {.compatible = "brcm,ns2-amac",},
{},
 };
 
diff --git a/drivers/net/ethernet/broadcom/bgmac.c 
b/drivers/net/ethernet/broadcom/bgmac.c
index 4584958..a805cc8 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
 /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
 static void bgmac_chip_init(struct bgmac *bgmac)
 {
+   /* Clear any erroneously pending interrupts */
+   bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
+
/* 1 interrupt per received frame */
bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
 
diff --git a/drivers/net/ethernet/broadcom/bgmac.h 
b/drivers/net/ethernet/broadcom/bgmac.h
index ea52ac3..b1820ea 

[PATCH] net: ip, diag -- Adjust raw_abort to use unlocked __udp_disconnect

[Cyrill Gorcunov]

While being preparing patches for killing raw sockets via
diag netlink interface I noticed that my runs are stuck:

 | [root@pcs7 ~]# cat /proc/`pidof ss`/stack
 | [] __lock_sock+0x80/0xc4
 | [] lock_sock_nested+0x47/0x95
 | [] udp_disconnect+0x19/0x33
 | [] raw_abort+0x33/0x42
 | [] sock_diag_destroy+0x4d/0x52

which has not been the case before. I narrowed it down to the commit

 | commit 286c72deabaa240b7eebbd99496ed3324d69f3c0
 | Author: Eric Dumazet 
 | Date:   Thu Oct 20 09:39:40 2016 -0700
 | 
 | udp: must lock the socket in udp_disconnect()

where we start locking the socket for different reason.

So the raw_abort escaped the renaming and we have to
fix this typo using __udp_disconnect instead.

CC: David S. Miller 
CC: Eric Dumazet 
CC: David Ahern 
CC: Alexey Kuznetsov 
CC: James Morris 
CC: Hideaki YOSHIFUJI 
CC: Patrick McHardy 
CC: Andrey Vagin 
CC: Stephen Hemminger 
Signed-off-by: Cyrill Gorcunov 
---

On top of net-next tree 22ca904ad70afc831d8503e80be1b6558a978759

 net/ipv4/raw.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-ml.git/net/ipv4/raw.c
===
--- linux-ml.git.orig/net/ipv4/raw.c
+++ linux-ml.git/net/ipv4/raw.c
@@ -920,7 +920,7 @@ int raw_abort(struct sock *sk, int err)
 
sk->sk_err = err;
sk->sk_error_report(sk);
-   udp_disconnect(sk, 0);
+   __udp_disconnect(sk, 0);
 
release_sock(sk);
 

Bus error on shm_open/ftruncate/mmap after changing kernel boot partition

[Thierry Moreau]

Strange bug after changing the boot partition (the previous was on a 
hard disk with a few media errors).


I must apologize that the old partition is re-formatted. (As an excuse 
the other services on this server system work fine with the new partition.)


Anyway, the bogus code sequence is below. Should work fine everywhere, 
modulo write permission on /dev/shm.


Same observation with privileged execution.

uname -a reports:

Linux hostname 4.1.3 #15 SMP Sun Aug 30 03:01:12 UTC 2015 x86_64 
Intel(R) Pentium(R) CPU G3250 @ 3.20GHz GenuineIntel GNU/Linux


Obviously, any help appreciated.

Regards

- Thierry Moreau



/* mmap_test.cpp --
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
  int shm_fd;
  shm_fd=shm_open(/*"/dev/shm/"*/"test",
 O_RDWR | O_CREAT | O_EXCL,
 S_IRUSR|S_IWUSR | S_IRGRP|S_IWGRP);
  if (shm_fd>=0) {
if (ftruncate(shm_fd,0x2)==0) {
  void *region=mmap(0,0x2,
   PROT_READ|PROT_WRITE,MAP_SHARED,
   shm_fd,0);
  if (MAP_FAILED!=region) {
fprintf(stderr,"%d %p\n",__LINE__,region);
fprintf(stderr,"%d %d\n",__LINE__,*((int *)region));
/* = this triggers a bus error on the kernel instance */
  }
  else {
fprintf(stderr,"%d %d %s\n",__LINE__,errno,strerror(errno));
  }
}
else {
  fprintf(stderr,"%d %d %s\n",__LINE__,errno,strerror(errno));
}
  }
  else {
fprintf(stderr,"%d %d %s\n",__LINE__,errno,strerror(errno));
  }
return errno;
}

[PATCH v4 5/7] net: ethernet: bgmac: device tree phy enablement

[Jon Mason]

Change the bgmac driver to allow for phy's defined by the device tree

Signed-off-by: Jon Mason 
---
 drivers/net/ethernet/broadcom/bgmac-bcma.c | 48 
 drivers/net/ethernet/broadcom/bgmac-platform.c | 48 +++-
 drivers/net/ethernet/broadcom/bgmac.c  | 52 ++
 drivers/net/ethernet/broadcom/bgmac.h  |  7 
 4 files changed, 105 insertions(+), 50 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c 
b/drivers/net/ethernet/broadcom/bgmac-bcma.c
index c16ec3a..3e3efde 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -80,6 +80,50 @@ static void bcma_bgmac_cmn_maskset32(struct bgmac *bgmac, 
u16 offset, u32 mask,
bcma_maskset32(bgmac->bcma.cmn, offset, mask, set);
 }
 
+static int bcma_phy_connect(struct bgmac *bgmac)
+{
+   struct phy_device *phy_dev;
+   char bus_id[MII_BUS_ID_SIZE + 3];
+
+   /* Connect to the PHY */
+   snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
+bgmac->phyaddr);
+   phy_dev = phy_connect(bgmac->net_dev, bus_id, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+   if (IS_ERR(phy_dev)) {
+   dev_err(bgmac->dev, "PHY connecton failed\n");
+   return PTR_ERR(phy_dev);
+   }
+
+   return 0;
+}
+
+static int bcma_phy_direct_connect(struct bgmac *bgmac)
+{
+   struct fixed_phy_status fphy_status = {
+   .link = 1,
+   .speed = SPEED_1000,
+   .duplex = DUPLEX_FULL,
+   };
+   struct phy_device *phy_dev;
+   int err;
+
+   phy_dev = fixed_phy_register(PHY_POLL, _status, -1, NULL);
+   if (!phy_dev || IS_ERR(phy_dev)) {
+   dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+   return -ENODEV;
+   }
+
+   err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+PHY_INTERFACE_MODE_MII);
+   if (err) {
+   dev_err(bgmac->dev, "Connecting PHY failed\n");
+   return err;
+   }
+
+   return err;
+}
+
 static const struct bcma_device_id bgmac_bcma_tbl[] = {
BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_4706_MAC_GBIT,
  BCMA_ANY_REV, BCMA_ANY_CLASS),
@@ -275,6 +319,10 @@ static int bgmac_probe(struct bcma_device *core)
bgmac->cco_ctl_maskset = bcma_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = bcma_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = bcma_bgmac_cmn_maskset32;
+   if (bgmac->mii_bus)
+   bgmac->phy_connect = bcma_phy_connect;
+   else
+   bgmac->phy_connect = bcma_phy_direct_connect;
 
err = bgmac_enet_probe(bgmac);
if (err)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c 
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index be52f27..aed5dc5 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "bgmac.h"
 
@@ -86,6 +87,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac 
*bgmac, u16 offset,
WARN_ON(1);
 }
 
+static int platform_phy_connect(struct bgmac *bgmac)
+{
+   struct phy_device *phy_dev;
+
+   phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
+bgmac_adjust_link);
+   if (!phy_dev) {
+   dev_err(bgmac->dev, "Phy connect failed\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static int platform_phy_direct_connect(struct bgmac *bgmac)
+{
+   struct fixed_phy_status fphy_status = {
+   .link = 1,
+   .speed = SPEED_1000,
+   .duplex = DUPLEX_FULL,
+   };
+   struct phy_device *phy_dev;
+   int err;
+
+   phy_dev = fixed_phy_register(PHY_POLL, _status, -1, NULL);
+   if (!phy_dev || IS_ERR(phy_dev)) {
+   dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+   return -ENODEV;
+   }
+
+   err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+PHY_INTERFACE_MODE_MII);
+   if (err) {
+   dev_err(bgmac->dev, "Connecting PHY failed\n");
+   return err;
+   }
+
+   return err;
+}
+
 static int bgmac_probe(struct platform_device *pdev)
 {
struct device_node *np = pdev->dev.of_node;
@@ -102,7 +143,6 @@ static int bgmac_probe(struct platform_device *pdev)
/* Set the features of the 4707 family */
bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
-   bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
bgmac->feature_flags |= BGMAC_FEAT_CMDCFG_SR_REV4;
bgmac->feature_flags |= 

[PATCH v4 2/7] Documentation: devicetree: add PHY lane swap binding

[Jon Mason]

Add the documentation for PHY lane swapping.  This is a boolean entry to
notify the phy device drivers that the TX/RX lanes need to be swapped.

Signed-off-by: Jon Mason 
---
 Documentation/devicetree/bindings/net/phy.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/phy.txt 
b/Documentation/devicetree/bindings/net/phy.txt
index bc1c3c8..3dce607 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -35,6 +35,9 @@ Optional Properties:
 - broken-turn-around: If set, indicates the PHY device does not correctly
   release the turn around line low at the end of a MDIO transaction.
 
+- enet-phy-lane-swap: If set, indicates the PHY device requires swapping the
+  TX/RX lanes to function properly.
+
 Example:
 
 ethernet-phy@0 {
-- 
2.7.4

[PATCH v4 4/7] Documentation: devicetree: net: add NS2 bindings to amac

[Jon Mason]

Clean-up the documentation to the bgmac-amac driver, per suggestion by
Rob Herring, and add details for NS2 support.

Signed-off-by: Jon Mason 
---
 Documentation/devicetree/bindings/net/brcm,amac.txt | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt 
b/Documentation/devicetree/bindings/net/brcm,amac.txt
index ba5ecc1..2fefa1a 100644
--- a/Documentation/devicetree/bindings/net/brcm,amac.txt
+++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
@@ -2,11 +2,17 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
 -
 
 Required properties:
- - compatible: "brcm,amac" or "brcm,nsp-amac"
- - reg:Address and length of the GMAC registers,
-   Address and length of the GMAC IDM registers
- - reg-names:  Names of the registers.  Must have both "amac_base" and
-   "idm_base"
+ - compatible: "brcm,amac"
+   "brcm,nsp-amac"
+   "brcm,ns2-amac"
+ - reg:Address and length of the register set for the device. 
It
+   contains the information of registers in the same order as
+   described by reg-names
+ - reg-names:  Names of the registers.
+   "amac_base":Address and length of the GMAC registers
+   "idm_base": Address and length of the GMAC IDM registers
+   "nicpm_base":   Address and length of the NIC Port Manager
+   registers (required for Northstar2)
  - interrupts: Interrupt number
 
 Optional properties:
-- 
2.7.4

[PATCH v9 05/16] dax: remove the last BUG_ON() from fs/dax.c

[Ross Zwisler]

Don't take down the kernel if we get an invalid 'from' and 'length'
argument pair.  Just warn once and return an error.

Signed-off-by: Ross Zwisler 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
---
 fs/dax.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/dax.c b/fs/dax.c
index e52e754..219fa2b 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1194,7 +1194,8 @@ int dax_zero_page_range(struct inode *inode, loff_t from, 
unsigned length,
/* Block boundary? Nothing to do */
if (!length)
return 0;
-   BUG_ON((offset + length) > PAGE_SIZE);
+   if (WARN_ON_ONCE((offset + length) > PAGE_SIZE))
+   return -EINVAL;
 
memset(, 0, sizeof(bh));
bh.b_bdev = inode->i_sb->s_bdev;
-- 
2.7.4

[PATCH v9 01/16] ext4: tell DAX the size of allocation holes

[Ross Zwisler]

When DAX calls _ext4_get_block() and the file offset points to a hole we
currently don't set bh->b_size.  This is current worked around via
buffer_size_valid() in fs/dax.c.

_ext4_get_block() has the hole size information from ext4_map_blocks(), so
populate bh->b_size so we can remove buffer_size_valid() in a later patch.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
---
 fs/ext4/inode.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 9c06472..3d58b2b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -767,6 +767,9 @@ static int _ext4_get_block(struct inode *inode, sector_t 
iblock,
ext4_update_bh_state(bh, map.m_flags);
bh->b_size = inode->i_sb->s_blocksize * map.m_len;
ret = 0;
+   } else if (ret == 0) {
+   /* hole case, need to fill in bh->b_size */
+   bh->b_size = inode->i_sb->s_blocksize * map.m_len;
}
return ret;
 }
-- 
2.7.4

[PATCH v9 06/16] dax: consistent variable naming for DAX entries

[Ross Zwisler]

No functional change.

Consistently use the variable name 'entry' instead of 'ret' for DAX radix
tree entries.  This was already happening in most of the code, so update
get_unlocked_mapping_entry(), grab_mapping_entry() and
dax_unlock_mapping_entry().

Signed-off-by: Ross Zwisler 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
---
 fs/dax.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 219fa2b..835e7f0 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -357,7 +357,7 @@ static inline void *unlock_slot(struct address_space 
*mapping, void **slot)
 static void *get_unlocked_mapping_entry(struct address_space *mapping,
pgoff_t index, void ***slotp)
 {
-   void *ret, **slot;
+   void *entry, **slot;
struct wait_exceptional_entry_queue ewait;
wait_queue_head_t *wq = dax_entry_waitqueue(mapping, index);
 
@@ -367,13 +367,13 @@ static void *get_unlocked_mapping_entry(struct 
address_space *mapping,
ewait.key.index = index;
 
for (;;) {
-   ret = __radix_tree_lookup(>page_tree, index, NULL,
+   entry = __radix_tree_lookup(>page_tree, index, NULL,
  );
-   if (!ret || !radix_tree_exceptional_entry(ret) ||
+   if (!entry || !radix_tree_exceptional_entry(entry) ||
!slot_locked(mapping, slot)) {
if (slotp)
*slotp = slot;
-   return ret;
+   return entry;
}
prepare_to_wait_exclusive(wq, ,
  TASK_UNINTERRUPTIBLE);
@@ -396,13 +396,13 @@ static void *get_unlocked_mapping_entry(struct 
address_space *mapping,
  */
 static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index)
 {
-   void *ret, **slot;
+   void *entry, **slot;
 
 restart:
spin_lock_irq(>tree_lock);
-   ret = get_unlocked_mapping_entry(mapping, index, );
+   entry = get_unlocked_mapping_entry(mapping, index, );
/* No entry for given index? Make sure radix tree is big enough. */
-   if (!ret) {
+   if (!entry) {
int err;
 
spin_unlock_irq(>tree_lock);
@@ -410,10 +410,10 @@ static void *grab_mapping_entry(struct address_space 
*mapping, pgoff_t index)
mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM);
if (err)
return ERR_PTR(err);
-   ret = (void *)(RADIX_TREE_EXCEPTIONAL_ENTRY |
+   entry = (void *)(RADIX_TREE_EXCEPTIONAL_ENTRY |
   RADIX_DAX_ENTRY_LOCK);
spin_lock_irq(>tree_lock);
-   err = radix_tree_insert(>page_tree, index, ret);
+   err = radix_tree_insert(>page_tree, index, entry);
radix_tree_preload_end();
if (err) {
spin_unlock_irq(>tree_lock);
@@ -425,11 +425,11 @@ static void *grab_mapping_entry(struct address_space 
*mapping, pgoff_t index)
/* Good, we have inserted empty locked entry into the tree. */
mapping->nrexceptional++;
spin_unlock_irq(>tree_lock);
-   return ret;
+   return entry;
}
/* Normal page in radix tree? */
-   if (!radix_tree_exceptional_entry(ret)) {
-   struct page *page = ret;
+   if (!radix_tree_exceptional_entry(entry)) {
+   struct page *page = entry;
 
get_page(page);
spin_unlock_irq(>tree_lock);
@@ -442,9 +442,9 @@ static void *grab_mapping_entry(struct address_space 
*mapping, pgoff_t index)
}
return page;
}
-   ret = lock_slot(mapping, slot);
+   entry = lock_slot(mapping, slot);
spin_unlock_irq(>tree_lock);
-   return ret;
+   return entry;
 }
 
 void dax_wake_mapping_entry_waiter(struct address_space *mapping,
@@ -469,11 +469,11 @@ void dax_wake_mapping_entry_waiter(struct address_space 
*mapping,
 
 void dax_unlock_mapping_entry(struct address_space *mapping, pgoff_t index)
 {
-   void *ret, **slot;
+   void *entry, **slot;
 
spin_lock_irq(>tree_lock);
-   ret = __radix_tree_lookup(>page_tree, index, NULL, );
-   if (WARN_ON_ONCE(!ret || !radix_tree_exceptional_entry(ret) ||
+   entry = __radix_tree_lookup(>page_tree, index, NULL, );
+   if (WARN_ON_ONCE(!entry || !radix_tree_exceptional_entry(entry) ||
 !slot_locked(mapping, slot))) {
spin_unlock_irq(>tree_lock);
return;
-- 
2.7.4

[PATCH v9 02/16] dax: remove buffer_size_valid()

[Ross Zwisler]

Now that ext4 properly sets bh.b_size when we call get_block() for a hole,
rely on that value and remove the buffer_size_valid() sanity check.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
Reviewed-by: Christoph Hellwig 
---
 fs/dax.c | 22 +-
 1 file changed, 1 insertion(+), 21 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 014defd..b09817a 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -123,19 +123,6 @@ static bool buffer_written(struct buffer_head *bh)
return buffer_mapped(bh) && !buffer_unwritten(bh);
 }
 
-/*
- * When ext4 encounters a hole, it returns without modifying the buffer_head
- * which means that we can't trust b_size.  To cope with this, we set b_state
- * to 0 before calling get_block and, if any bit is set, we know we can trust
- * b_size.  Unfortunate, really, since ext4 knows precisely how long a hole is
- * and would save us time calling get_block repeatedly.
- */
-static bool buffer_size_valid(struct buffer_head *bh)
-{
-   return bh->b_state != 0;
-}
-
-
 static sector_t to_sector(const struct buffer_head *bh,
const struct inode *inode)
 {
@@ -177,8 +164,6 @@ static ssize_t dax_io(struct inode *inode, struct iov_iter 
*iter,
rc = get_block(inode, block, bh, rw == WRITE);
if (rc)
break;
-   if (!buffer_size_valid(bh))
-   bh->b_size = 1 << blkbits;
bh_max = pos - first + bh->b_size;
bdev = bh->b_bdev;
/*
@@ -1012,12 +997,7 @@ int dax_pmd_fault(struct vm_area_struct *vma, unsigned 
long address,
 
bdev = bh.b_bdev;
 
-   /*
-* If the filesystem isn't willing to tell us the length of a hole,
-* just fall back to PTEs.  Calling get_block 512 times in a loop
-* would be silly.
-*/
-   if (!buffer_size_valid() || bh.b_size < PMD_SIZE) {
+   if (bh.b_size < PMD_SIZE) {
dax_pmd_dbg(, address, "allocated block too small");
return VM_FAULT_FALLBACK;
}
-- 
2.7.4

[PATCH v4 0/7] add NS2 support to bgmac

[Jon Mason]

Changes in v4:
* Actually send out the lane swap binding doc patch (Per Scott Branden)
* Remove unused #define (Per Andrew Lunn)


Changes in v3:
* Clean-up the bgmac DT binding doc (per Rob Herring)
* Document the lane swap binding and make it generic (Per Andrew Lunn)


Changes in v2:
* Remove the PHY power-on (per Andrew Lunn)
* Misc PHY clean-ups regarding comments and #defines (per Andrew Lunn)
  This results on none of the original PHY code from Vikas being
  present.  So, I'm removing him as an author and giving him
  "Inspired-by" credit.
* Move PHY lane swapping to PHY driver (per Andrew Lunn and Florian
  Fainelli)
* Remove bgmac sleep (per Florian Fainelli)
* Re-add bgmac chip reset (per Florian Fainelli and Ray Jui)
* Rebased on latest net-next
* Added patch for bcm54xx_auxctl_read, which is used in the BCM54810


Add support for the amac found in the Broadcom Northstar2 SoC to the
bgmac driver.  This necessitates adding support to connect to an
externally defined phy (as described in the device tree) in the driver.
These phy changes are in addition to the changes necessary to get NS2
working.


Jon Mason (7):
  net: phy: broadcom: add bcm54xx_auxctl_read
  Documentation: devicetree: add PHY lane swap binding
  net: phy: broadcom: Add BCM54810 PHY entry
  Documentation: devicetree: net: add NS2 bindings to amac
  net: ethernet: bgmac: device tree phy enablement
  net: ethernet: bgmac: add NS2 support
  arm64: dts: NS2: add AMAC ethernet support

 .../devicetree/bindings/net/brcm,amac.txt  |  16 ++--
 Documentation/devicetree/bindings/net/phy.txt  |   3 +
 arch/arm64/boot/dts/broadcom/ns2-svk.dts   |   5 ++
 arch/arm64/boot/dts/broadcom/ns2.dtsi  |  12 +++
 drivers/net/ethernet/broadcom/bgmac-bcma.c |  48 ++
 drivers/net/ethernet/broadcom/bgmac-platform.c | 100 -
 drivers/net/ethernet/broadcom/bgmac.c  |  55 ++--
 drivers/net/ethernet/broadcom/bgmac.h  |   8 ++
 drivers/net/phy/Kconfig|   2 +-
 drivers/net/phy/broadcom.c |  68 +-
 include/linux/brcmphy.h|  10 +++
 11 files changed, 270 insertions(+), 57 deletions(-)

-- 
2.7.4

[PATCH v9 00/16] re-enable DAX PMD support

[Ross Zwisler]

DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking.  This series allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled.

Previously we had talked about this series going through the XFS tree, but
Jan has a patch set that will need to build on this series and it heavily
modifies the MM code.  I think he would prefer that series to go through
Andrew Morton's -MM tree, so it probably makes sense for this series to go
through that same tree.

For reference, here is the series from Jan that I was talking about:
https://marc.info/?l=linux-mm=147499252322902=2

Andrew, can you please pick this up for the v4.10 merge window?
This series is currently based on v4.9-rc3.  I tried to rebase onto a -mm
branch or tag, but couldn't find one that contained the DAX iomap changes
that were merged as part of the v4.9 merge window.  I'm happy to rebase &
test on a v4.9-rc* based -MM branch or tag whenever they are available.

Changes since v8:
- Rebased onto v4.9-rc3.
- Updated the DAX PMD fault path so that on fallback we always check to see
  if we are dealing with a transparent huge page, and if we are we will
  split it.  This was already happening for one of the fallback cases via a
  patch from Toshi, and Jan hit a deadlock in another fallback case where
  the same splitting was needed.  (Jan & Toshi)

This series has passed all my xfstests testing, including the test that was
hitting the deadlock with v8.

Here is a tree containing my changes:
https://git.kernel.org/cgit/linux/kernel/git/zwisler/linux.git/log/?h=dax_pmd_v9

Ross Zwisler (16):
  ext4: tell DAX the size of allocation holes
  dax: remove buffer_size_valid()
  ext2: remove support for DAX PMD faults
  dax: make 'wait_table' global variable static
  dax: remove the last BUG_ON() from fs/dax.c
  dax: consistent variable naming for DAX entries
  dax: coordinate locking for offsets in PMD range
  dax: remove dax_pmd_fault()
  dax: correct dax iomap code namespace
  dax: add dax_iomap_sector() helper function
  dax: dax_iomap_fault() needs to call iomap_end()
  dax: move RADIX_DAX_* defines to dax.h
  dax: move put_(un)locked_mapping_entry() in dax.c
  dax: add struct iomap based DAX PMD support
  xfs: use struct iomap based DAX PMD fault path
  dax: remove "depends on BROKEN" from FS_DAX_PMD

 fs/Kconfig  |   1 -
 fs/dax.c| 826 +---
 fs/ext2/file.c  |  35 +--
 fs/ext4/inode.c |   3 +
 fs/xfs/xfs_aops.c   |  26 +-
 fs/xfs/xfs_aops.h   |   3 -
 fs/xfs/xfs_file.c   |  10 +-
 include/linux/dax.h |  58 +++-
 mm/filemap.c|   5 +-
 9 files changed, 537 insertions(+), 430 deletions(-)

-- 
2.7.4

Re: [PATCHv3 1/3] z3fold: make counters atomic

[Dan Streetman]

On Thu, Oct 27, 2016 at 7:08 AM, Vitaly Wool  wrote:
> This patch converts pages_nr per-pool counter to atomic64_t.
> It also introduces a new counter, unbuddied_nr, which is
> atomic64_t, too, to track the number of unbuddied (compactable)
> z3fold pages.

so, with the use of workqueues, do we still need the unbuddied_nr
counter?  It doesn't seem to be used in later patches?

changing the pages_nr to atomic is a good idea though, so we can
safely read it without needing the pool lock.

>
> Signed-off-by: Vitaly Wool 
> ---
>  mm/z3fold.c | 33 +
>  1 file changed, 25 insertions(+), 8 deletions(-)
>
> diff --git a/mm/z3fold.c b/mm/z3fold.c
> index 8f9e89c..5ac325a 100644
> --- a/mm/z3fold.c
> +++ b/mm/z3fold.c
> @@ -69,6 +69,7 @@ struct z3fold_ops {
>   * @lru:   list tracking the z3fold pages in LRU order by most recently
>   * added buddy.
>   * @pages_nr:  number of z3fold pages in the pool.
> + * @unbuddied_nr:  number of unbuddied z3fold pages in the pool.
>   * @ops:   pointer to a structure of user defined operations specified at
>   * pool creation time.
>   *
> @@ -80,7 +81,8 @@ struct z3fold_pool {
> struct list_head unbuddied[NCHUNKS];
> struct list_head buddied;
> struct list_head lru;
> -   u64 pages_nr;
> +   atomic64_t pages_nr;
> +   atomic64_t unbuddied_nr;
> const struct z3fold_ops *ops;
> struct zpool *zpool;
> const struct zpool_ops *zpool_ops;
> @@ -234,7 +236,8 @@ static struct z3fold_pool *z3fold_create_pool(gfp_t gfp,
> INIT_LIST_HEAD(>unbuddied[i]);
> INIT_LIST_HEAD(>buddied);
> INIT_LIST_HEAD(>lru);
> -   pool->pages_nr = 0;
> +   atomic64_set(>pages_nr, 0);
> +   atomic64_set(>unbuddied_nr, 0);
> pool->ops = ops;
> return pool;
>  }
> @@ -334,6 +337,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
> size, gfp_t gfp,
> continue;
> }
> list_del(>buddy);
> +   atomic64_dec(>unbuddied_nr);
> goto found;
> }
> }
> @@ -346,7 +350,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
> size, gfp_t gfp,
> if (!page)
> return -ENOMEM;
> spin_lock(>lock);
> -   pool->pages_nr++;
> +   atomic64_inc(>pages_nr);
> zhdr = init_z3fold_page(page);
>
> if (bud == HEADLESS) {
> @@ -369,6 +373,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
> size, gfp_t gfp,
> /* Add to unbuddied list */
> freechunks = num_free_chunks(zhdr);
> list_add(>buddy, >unbuddied[freechunks]);
> +   atomic64_inc(>unbuddied_nr);
> } else {
> /* Add to buddied list */
> list_add(>buddy, >buddied);
> @@ -412,6 +417,10 @@ static void z3fold_free(struct z3fold_pool *pool, 
> unsigned long handle)
> /* HEADLESS page stored */
> bud = HEADLESS;
> } else {
> +   bool is_unbuddied = zhdr->first_chunks == 0 ||
> +   zhdr->middle_chunks == 0 ||
> +   zhdr->last_chunks == 0;
> +
> bud = handle_to_buddy(handle);
>
> switch (bud) {
> @@ -431,6 +440,8 @@ static void z3fold_free(struct z3fold_pool *pool, 
> unsigned long handle)
> spin_unlock(>lock);
> return;
> }
> +   if (is_unbuddied)
> +   atomic64_dec(>unbuddied_nr);
> }
>
> if (test_bit(UNDER_RECLAIM, >private)) {
> @@ -451,12 +462,13 @@ static void z3fold_free(struct z3fold_pool *pool, 
> unsigned long handle)
> list_del(>lru);
> clear_bit(PAGE_HEADLESS, >private);
> free_z3fold_page(zhdr);
> -   pool->pages_nr--;
> +   atomic64_dec(>pages_nr);
> } else {
> z3fold_compact_page(zhdr);
> /* Add to the unbuddied list */
> freechunks = num_free_chunks(zhdr);
> list_add(>buddy, >unbuddied[freechunks]);
> +   atomic64_inc(>unbuddied_nr);
> }
>
> spin_unlock(>lock);
> @@ -520,6 +532,11 @@ static int z3fold_reclaim_page(struct z3fold_pool *pool, 
> unsigned int retries)
> zhdr = page_address(page);
> if (!test_bit(PAGE_HEADLESS, >private)) {
> list_del(>buddy);
> +   if (zhdr->first_chunks == 0 ||
> +   zhdr->middle_chunks == 0 ||
> +   zhdr->last_chunks == 0)
> +   atomic64_dec(>unbuddied_nr);
> +
>

Re: [PATCHv3 1/3] z3fold: make counters atomic

[Vitaly Wool]

On Tue, Nov 1, 2016 at 9:03 PM, Dan Streetman  wrote:
> On Thu, Oct 27, 2016 at 7:08 AM, Vitaly Wool  wrote:
>> This patch converts pages_nr per-pool counter to atomic64_t.
>> It also introduces a new counter, unbuddied_nr, which is
>> atomic64_t, too, to track the number of unbuddied (compactable)
>> z3fold pages.
>
> so, with the use of workqueues, do we still need the unbuddied_nr
> counter?  It doesn't seem to be used in later patches?

I'm going to add sysfs/debugfs accounting a bit later so it won't rest unused.

Also, with a per-page lock (if I come up with something reasonable) it could
be still worth going back to shrinker.

> changing the pages_nr to atomic is a good idea though, so we can
> safely read it without needing the pool lock.
>
>>
>> Signed-off-by: Vitaly Wool 
>> ---
>>  mm/z3fold.c | 33 +
>>  1 file changed, 25 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/z3fold.c b/mm/z3fold.c
>> index 8f9e89c..5ac325a 100644
>> --- a/mm/z3fold.c
>> +++ b/mm/z3fold.c
>> @@ -69,6 +69,7 @@ struct z3fold_ops {
>>   * @lru:   list tracking the z3fold pages in LRU order by most recently
>>   * added buddy.
>>   * @pages_nr:  number of z3fold pages in the pool.
>> + * @unbuddied_nr:  number of unbuddied z3fold pages in the pool.
>>   * @ops:   pointer to a structure of user defined operations specified 
>> at
>>   * pool creation time.
>>   *
>> @@ -80,7 +81,8 @@ struct z3fold_pool {
>> struct list_head unbuddied[NCHUNKS];
>> struct list_head buddied;
>> struct list_head lru;
>> -   u64 pages_nr;
>> +   atomic64_t pages_nr;
>> +   atomic64_t unbuddied_nr;
>> const struct z3fold_ops *ops;
>> struct zpool *zpool;
>> const struct zpool_ops *zpool_ops;
>> @@ -234,7 +236,8 @@ static struct z3fold_pool *z3fold_create_pool(gfp_t gfp,
>> INIT_LIST_HEAD(>unbuddied[i]);
>> INIT_LIST_HEAD(>buddied);
>> INIT_LIST_HEAD(>lru);
>> -   pool->pages_nr = 0;
>> +   atomic64_set(>pages_nr, 0);
>> +   atomic64_set(>unbuddied_nr, 0);
>> pool->ops = ops;
>> return pool;
>>  }
>> @@ -334,6 +337,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
>> size, gfp_t gfp,
>> continue;
>> }
>> list_del(>buddy);
>> +   atomic64_dec(>unbuddied_nr);
>> goto found;
>> }
>> }
>> @@ -346,7 +350,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
>> size, gfp_t gfp,
>> if (!page)
>> return -ENOMEM;
>> spin_lock(>lock);
>> -   pool->pages_nr++;
>> +   atomic64_inc(>pages_nr);
>> zhdr = init_z3fold_page(page);
>>
>> if (bud == HEADLESS) {
>> @@ -369,6 +373,7 @@ static int z3fold_alloc(struct z3fold_pool *pool, size_t 
>> size, gfp_t gfp,
>> /* Add to unbuddied list */
>> freechunks = num_free_chunks(zhdr);
>> list_add(>buddy, >unbuddied[freechunks]);
>> +   atomic64_inc(>unbuddied_nr);
>> } else {
>> /* Add to buddied list */
>> list_add(>buddy, >buddied);
>> @@ -412,6 +417,10 @@ static void z3fold_free(struct z3fold_pool *pool, 
>> unsigned long handle)
>> /* HEADLESS page stored */
>> bud = HEADLESS;
>> } else {
>> +   bool is_unbuddied = zhdr->first_chunks == 0 ||
>> +   zhdr->middle_chunks == 0 ||
>> +   zhdr->last_chunks == 0;
>> +
>> bud = handle_to_buddy(handle);
>>
>> switch (bud) {
>> @@ -431,6 +440,8 @@ static void z3fold_free(struct z3fold_pool *pool, 
>> unsigned long handle)
>> spin_unlock(>lock);
>> return;
>> }
>> +   if (is_unbuddied)
>> +   atomic64_dec(>unbuddied_nr);
>> }
>>
>> if (test_bit(UNDER_RECLAIM, >private)) {
>> @@ -451,12 +462,13 @@ static void z3fold_free(struct z3fold_pool *pool, 
>> unsigned long handle)
>> list_del(>lru);
>> clear_bit(PAGE_HEADLESS, >private);
>> free_z3fold_page(zhdr);
>> -   pool->pages_nr--;
>> +   atomic64_dec(>pages_nr);
>> } else {
>> z3fold_compact_page(zhdr);
>> /* Add to the unbuddied list */
>> freechunks = num_free_chunks(zhdr);
>> list_add(>buddy, >unbuddied[freechunks]);
>> +   atomic64_inc(>unbuddied_nr);
>> }
>>
>> spin_unlock(>lock);
>> @@ -520,6 +532,11 @@ static int z3fold_reclaim_page(struct z3fold_pool 
>> *pool, unsigned int 

Re: [PATCH v2 2/3] cpuidle:powernv: Add helper function to populate powernv idle states.

[Paul Mackerras]

On Tue, Nov 01, 2016 at 07:32:58PM +1100, Oliver O'Halloran wrote:
> On Thu, Oct 27, 2016 at 7:35 PM, Gautham R. Shenoy
>  wrote:
> > From: "Gautham R. Shenoy" 
> >
> > In the current code for powernv_add_idle_states, there is a lot of code
> > duplication while initializing an idle state in powernv_states table.
> >
> > Add an inline helper function to populate the powernv_states[] table for
> > a given idle state. Invoke this for populating the "Nap", "Fastsleep"
> > and the stop states in powernv_add_idle_states.
> >
> > Signed-off-by: Gautham R. Shenoy 
> > ---
> >  drivers/cpuidle/cpuidle-powernv.c | 82 
> > +++
> >  include/linux/cpuidle.h   |  1 +
> >  2 files changed, 49 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/cpuidle/cpuidle-powernv.c 
> > b/drivers/cpuidle/cpuidle-powernv.c
> > index 7fe442c..11b22b9 100644
> > --- a/drivers/cpuidle/cpuidle-powernv.c
> > +++ b/drivers/cpuidle/cpuidle-powernv.c
> > @@ -167,6 +167,28 @@ static int powernv_cpuidle_driver_init(void)
> > return 0;
> >  }
> >
> > +static inline void add_powernv_state(int index, const char *name,
> > +unsigned int flags,
> > +int (*idle_fn)(struct cpuidle_device *,
> > +   struct cpuidle_driver *,
> > +   int),
> > +unsigned int target_residency,
> > +unsigned int exit_latency,
> > +u64 psscr_val)
> > +{
> > +   strncpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
> > +   strncpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
> 
> If the supplied name is equal to CPUIDLE_NAME_LEN then strncpy() won't
> terminate the string. The least annoying fix is to memset() the whole
> structure to zero and set n to CPUIDLE_NAME_LEN - 1.

Or he could use strlcpy() instead of strncpy().

Paul.

[PATCH] Use -mcount-record for dynamic ftrace

[Andi Kleen]

From: Andi Kleen 

gcc 5 supports a new -mcount-record option to generate ftrace
tables directly. This avoids the need to run record_mcount
manually.

Use this option when available.

It also has a -mcount-nop option to generate the mcount calls
as nops. So far that is not implemented, but it could be used
to optimize patching at boot up.

Signed-off-by: Andi Kleen 
---
 scripts/Makefile.build | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index de46ab03f063..2d7467076411 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -212,6 +212,11 @@ cmd_modversions =  
\
 endif
 
 ifdef CONFIG_FTRACE_MCOUNT_RECORD
+# gcc 5 supports generating the mcount tables directly
+ifneq ($(call cc-option,-mrecord-mcount,y),y)
+  KBUILD_CFLAGS += -mrecord-mcount
+else
+# else do it all manually
 ifdef BUILD_C_RECORDMCOUNT
 ifeq ("$(origin RECORDMCOUNT_WARN)", "command line")
   RECORDMCOUNT_FLAGS = -w
@@ -241,6 +246,7 @@ cmd_record_mcount = 
\
$(sub_cmd_record_mcount)\
fi;
 endif
+endif
 
 ifdef CONFIG_STACK_VALIDATION
 ifneq ($(SKIP_STACK_VALIDATION),1)
-- 
2.5.5

Re: [RFC v3 2/6] Improve the tracking of active utilisation

[luca abeni]

On Tue, 1 Nov 2016 22:46:33 +0100
luca abeni  wrote:
[...]
> > > @@ -1074,6 +1161,14 @@ select_task_rq_dl(struct task_struct *p, int cpu, 
> > > int sd_flag, int flags)
> > >   }
> > >   rcu_read_unlock();
> > >  
> > > + rq = task_rq(p);
> > > + raw_spin_lock(>lock);
> > > + if (hrtimer_active(>dl.inactive_timer)) {
> > > + sub_running_bw(>dl, >dl);
> > > + hrtimer_try_to_cancel(>dl.inactive_timer);
> > 
> > Can't we subtract twice if it happens that after we grabbed rq_lock the 
> > timer
> > fired, so it's now waiting for that lock and it goes ahead and 
> > sub_running_bw
> > again after we release the lock?  
> Uhm... I somehow convinced myself that this could not happen, but I do not
> remember the details, sorry :(
I think I remember the answer now: pi_lock is acquired before invoking 
select_task_rq
and is released after invoking enqueue_task... So, if there is a pending 
inactive
timer, its handler will be executed after the task is enqueued... It will see 
the task
as RUNNING, and will not decrease the active utilisation.

Does this make sense?



Luca

Re: [PATCH 45/60] block: bio: introduce bio_for_each_segment_all_rd() and its write pair

[Kent Overstreet]

On Mon, Oct 31, 2016 at 08:11:23AM -0700, Christoph Hellwig wrote:
> On Mon, Oct 31, 2016 at 09:59:43AM -0400, Theodore Ts'o wrote:
> > What is _rd and _wt supposed to stand for?
> 
> I think it's read and write, but I think the naming is highly
> unfortunate.  I started dabbling around with the patches a bit,
> and to keep my sanity a started reaming it to _pages and _bvec
> which is the real semantics - the _rd or _pages gives you a synthetic
> bvec for each page, and the other one gives you the full bvec.

My original naming was bio_for_each_segment() and bio_for_each_page().

Re: Kernel regression introduced by "e1000e: Do not write lsc to ics in msi-x mode" and/or "e1000e: Do not read ICR in Other interrupt"

[Benjamin Poirier]

On 2016/11/01 19:56, Jack Suter wrote:
> Hi there,
> 
> I have some servers with an 82574L based NIC and recently upgraded from
> a 4.4 series kernel to 4.7. Upon doing so, servers with this chipset
> have begun frequently reporting "Link is Down" and "Link is Up"
> messages. No other related network errors are reported by the kernel or
> e1000e driver. I saw some reports about using "ethtool -s $iface msglvl
> 6" to reveal more information, but nothing extra was reported.
> 
> Some testing showed that this was introduced between the 4.4 and 4.5
> series. I was able to further narrow it down to two commits that look
> related:
> 
>  e1000e: Do not write lsc to ics in msi-x mode
>  (a61cfe4ffad7864a07e0c74969ca7ceb77ab2f1f)
>  e1000e: Do not read ICR in Other interrupt
>  (16ecba59bc333d6282ee057fb02339f77a880beb)

I'm just about to get on a plane but I'll be able to look at this on
Monday. Two guesses are that:
1) There is something else than LSC that triggers the "other" interrupt.
Even if that is so, it should not cause e1000e_check_for_copper_link to
report link down however.
2) The link down events are real but some lsc interrupts were not
processed properly prior to this patchset, causing the events to be
lost/ignored.

Re: [Qemu-devel] [PATCH v9 04/12] vfio iommu: Add support for mediated devices

[Kirti Wankhede]

On 11/2/2016 6:54 AM, Alexey Kardashevskiy wrote:
> On 02/11/16 01:01, Kirti Wankhede wrote:
>>
>>
>> On 10/28/2016 7:48 AM, Alexey Kardashevskiy wrote:
>>> On 27/10/16 23:31, Kirti Wankhede wrote:


 On 10/27/2016 12:50 PM, Alexey Kardashevskiy wrote:
> On 18/10/16 08:22, Kirti Wankhede wrote:
>> VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
>> Mediated device only uses IOMMU APIs, the underlying hardware can be
>> managed by an IOMMU domain.
>>
>> Aim of this change is:
>> - To use most of the code of TYPE1 IOMMU driver for mediated devices
>> - To support direct assigned device and mediated device in single module
>>
>> Added two new callback functions to struct vfio_iommu_driver_ops. Backend
>> IOMMU module that supports pining and unpinning pages for mdev devices
>> should provide these functions.
>> Added APIs for pining and unpining pages to VFIO module. These calls back
>> into backend iommu module to actually pin and unpin pages.
>>
>> This change adds pin and unpin support for mediated device to TYPE1 IOMMU
>> backend module. More details:
>> - When iommu_group of mediated devices is attached, task structure is
>>   cached which is used later to pin pages and page accounting.
>
>
> For SPAPR TCE IOMMU driver, I ended up caching mm_struct with
> atomic_inc(>mm->mm_count) (patches are on the way) instead of
> using @current or task as the process might be gone while VFIO container 
> is
> still alive and @mm might be needed to do proper cleanup; this might not 
> be
> an issue with this patchset now but still you seem to only use @mm from
> task_struct.
>

 Consider the example of QEMU process which creates VFIO container, QEMU
 in its teardown path would release the container. How could container be
 alive when process is gone?
>>>
>>> do_exit() in kernel/exit.c calls exit_mm() (which sets NULL to tsk->mm)
>>> first, and then releases open files by calling  exit_files(). So
>>> container's release() does not have current->mm.
>>>
>>
>> Incrementing usage count (get_task_struct()) while saving task structure
>> and decementing it (put_task_struct()) from release() should  work here.
>> Updating the patch.
> 
> I cannot see how the task->usage counter prevents do_exit() from performing
> the exit, can you?
> 

It will not prevent exit from do_exit(), but that will make sure that we
don't have stale pointer of task structure. Then we can check whether
the task is alive and get mm pointer in teardown path as below:

{
struct task_struct *task = domain->external_addr_space->task;
struct mm_struct *mm = NULL;

put_pfn(pfn, prot);

if (pid_alive(task))
mm = get_task_mm(task);

if (mm) {
if (do_accounting)
vfio_lock_acct(task, -1);

mmput(mm);
}
}

Thanks,
Kirti

Re: Bus error on shm_open/ftruncate/mmap after changing kernel boot partition: FIXED

[Thierry Moreau]

Fixed (but still puzzled) -- see below.

On 01/11/16 07:57 PM, Thierry Moreau wrote:

Strange bug after changing the boot partition (the previous was on a
hard disk with a few media errors).



Ah!

mounting tmpfs on /dev/shm (manually or through fstab) fixes this.

I am somehow puzzled as I think I observe the test program working 
without this mount on some kernel instances.



I must apologize that the old partition is re-formatted. (As an excuse
the other services on this server system work fine with the new partition.)

Anyway, the bogus code sequence is below. Should work fine everywhere,
modulo write permission on /dev/shm.

Same observation with privileged execution.

uname -a reports:

Linux hostname 4.1.3 #15 SMP Sun Aug 30 03:01:12 UTC 2015 x86_64
Intel(R) Pentium(R) CPU G3250 @ 3.20GHz GenuineIntel GNU/Linux

Obviously, any help appreciated.

Regards

- Thierry Moreau



/* mmap_test.cpp --
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
   int shm_fd;
   shm_fd=shm_open(/*"/dev/shm/"*/"test",
  O_RDWR | O_CREAT | O_EXCL,
  S_IRUSR|S_IWUSR | S_IRGRP|S_IWGRP);
   if (shm_fd>=0) {
 if (ftruncate(shm_fd,0x2)==0) {
   void *region=mmap(0,0x2,
PROT_READ|PROT_WRITE,MAP_SHARED,
shm_fd,0);
   if (MAP_FAILED!=region) {
 fprintf(stderr,"%d %p\n",__LINE__,region);
 fprintf(stderr,"%d %d\n",__LINE__,*((int *)region));
 /* = this triggers a bus error on the kernel instance */
   }
   else {
 fprintf(stderr,"%d %d %s\n",__LINE__,errno,strerror(errno));
   }
 }
 else {
   fprintf(stderr,"%d %d %s\n",__LINE__,errno,strerror(errno));
 }
   }
   else {
 fprintf(stderr,"%d %d %s\n",__LINE__,errno,strerror(errno));
   }
return errno;
}

Re: [4.9-rc3] BUG: unable to handle kernel paging request at ffffc900144dfc60

[Linus Torvalds]

On Tue, Nov 1, 2016 at 8:36 AM, Tetsuo Handa
 wrote:
>
> I got an Oops with khungtaskd. This kernel was built with 
> CONFIG_THREAD_INFO_IN_TASK=y .
> Is this same reason?

CONFIG_THREAD_INFO_IN_TASK is always set on x86, but I assume you also
did VMAP_STACK

And yes, it looks like it's the same "touching another process' stack"
issue, just in sched_show_task() called from check_hung_task(), which
seems to have been due to a watchdog triggering. I'm not sure what the
relationship is with the oom killer happening at the same time, but it
makes the whole thing fairly hard to read.

The cleaned-up oops looks like this:

> [  580.803660] BUG: unable to handle kernel paging request at c900144dfc60
> [  580.807153] IP:  thread_saved_pc+0xb/0x20
> [  580.907040] Call Trace:
> [  580.908547]   sched_show_task+0x50/0x240
> [  580.928793]   watchdog+0x3d0/0x4f0
> [  580.930774]   ? watchdog+0x1fd/0x4f0
> [  580.932785]   ? check_memalloc_stalling_tasks+0x820/0x820
> [  580.935649]   kthread+0xfd/0x120
> [  580.937594]   ? kthread_park+0x60/0x60
> [  580.939693]   ? kthread_park+0x60/0x60
> [  580.941743]   ret_from_fork+0x27/0x40
> [  580.944608] Code: 55 48 8b bf d0 01 00 00 be 00 00 00 02 48 89 e5 e8 6b 58 
> 3f 00 5d c3 66 0f 1f 84 00 00 00 00 00 55 48 8b 87 e0 15 00 00 48 89 e5 <48> 
> 8b 40 30 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
> [  580.952519] RIP  [] thread_saved_pc+0xb/0x20
> [  580.954654]  RSP 
> [  580.956272] CR2: c900144dfc60

So we have

  watchdog -> check_hung_uninterruptible_task -> check_hung_task ->
sched_show_task -> thread_saved_pc(), which oopses.

We just checked that task was TASK_UNINTERRUPTIBLE in that chain, but
clearly it races with it dying (due to oom), and so by the time er get
to thread_saved_pc() it's dead and the stack is gone.

Considering that we just print out  a useless hex number, not even a
symbol, and there's a big question mark whether this even makes sense
anyway, I suspect we should just remove it all.  The real information
would have come later as part of "show_stack()", which seems to be
doing the proper  try_get_task_stack().

So I _think_ the fix is to just remove this. Perhaps something like
the attached? Adding scheduler people since this is in their code..

  Linus
 kernel/sched/core.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 42d4027f9e26..3c3022466331 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5196,17 +5196,8 @@ void sched_show_task(struct task_struct *p)
state = __ffs(state) + 1;
printk(KERN_INFO "%-15.15s %c", p->comm,
state < sizeof(stat_nam) - 1 ? stat_nam[state] : '?');
-#if BITS_PER_LONG == 32
-   if (state == TASK_RUNNING)
-   printk(KERN_CONT " running  ");
-   else
-   printk(KERN_CONT " %08lx ", thread_saved_pc(p));
-#else
if (state == TASK_RUNNING)
printk(KERN_CONT "  running task");
-   else
-   printk(KERN_CONT " %016lx ", thread_saved_pc(p));
-#endif
 #ifdef CONFIG_DEBUG_STACK_USAGE
free = stack_not_used(p);
 #endif

Re: [PATCH] clk: nxp: clk-lpc18xx-ccu: Unmap region obtained by of_iomap

[Stephen Boyd]

On 09/20, Arvind Yadav wrote:
> From: Arvind Yadav 
> 
> Free memory mapping, if lpc18xx_ccu_init is not successful.
> 
> Signed-off-by: Arvind Yadav 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/4] clk: Enable compile testing for s2mps11 and max77686

[Stephen Boyd]

On 10/02, Krzysztof Kozlowski wrote:
> s2mps11 and max77686 clock drivers can be compile tested to increase
> build coverage.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

RE: [PATCH v2] phy: rcar-gen3-usb2: add sysfs for usb role swap

[Yoshihiro Shimoda]

Hi Peter,

> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Tuesday, November 01, 2016 8:38 PM
> 
> On Tue, Nov 01, 2016 at 04:01:58PM +0900, Yoshihiro Shimoda wrote:
> > This patch adds sysfs "otg_inputs" for usb role swap. This parameter
> > is write-only and if you use them as the following, you can swap
> > the usb role.
> >
> > For example:
> >  1) connect a usb cable using 2 salvator-x boards
> >  2) On A-device (as host), you input the following command:
> ># echo a_bus_req/ > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
> >  3) On B-device (as peripheral), you input the following command:
> ># echo b_bus_req > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
> >
> > Then, the A-device acts as a peripheral (A-peripheral) and the B-device
> > acts as a host (B-host).
> > Please note that A-device must input the following command if you
> > want the board to act as a host again. (even if you disconnect the usb
> > cable, since id state may be the same, the condition keeps "A-peripheral".)
> >  # echo a_bus_drop > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
> >
> > Also you can use the following command if you want the B-device board to
> > act as a peripheral again.
> >  # echo b_bus_req/ > /sys/devices/platform/soc/ee080200.usb-phy/otg_inputs
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  This patch is based on the latest linux-phy.git / next branch.
> >  (commit id = 7809cd2ce6abd4f431e4b14e6b1276a7cc842ac4)
> >
> >  Since this patch is related to usb, I added email addresses of Greg, 
> > Felipe,
> >  Peter and USB ML as CC. (This patch doesn't use USB OTG FSM though.)
> >
> >  Changed from v1:
> >   - rebase the latest next branch.
> >
> >  .../ABI/testing/sysfs-platform-phy-rcar-gen3-usb2  |  11 ++
> >  drivers/phy/phy-rcar-gen3-usb2.c   | 124 
> > -
> >  2 files changed, 134 insertions(+), 1 deletion(-)
> >  create mode 100644 
> > Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> >
> > diff --git a/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> > new file mode 100644
> > index 000..c7e715af
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-platform-phy-rcar-gen3-usb2
> > @@ -0,0 +1,11 @@
> > +What:  /sys/devices/platform//otg-inputs
> > +Date:  October 2016
> > +KernelVersion: 4.10
> > +Contact:   Yoshihiro Shimoda 
> > +Description:
> > +   This write-only file changes the phy mode for role swap of usb.
> > +   This file accepts the following strings:
> > +"a_bus_req/" - switching from A-Host to A-Peripheral
> > +"a_bus_drop" - switching from A-Peripheral to A-Host
> > +"b_bus_req"  - switching from B-Peripheral to B-Host
> > +"b_bus_req/" - switching from B-Host to B-Peripheral
> 
> Would you really care OTG FSM state machine? If not, you could just use
> "host" and "peripheral" to stand for current USB role, and implement
> role switch sysfs like: /sys/devices/platform//role.

Thank you for the comment!
Since I would not care OTG FSM state machine for now, I will modify the patch to
use "host" and "peripheral" that you suggested.

Best regards,
Yoshihiro Shimoda

> Peter
> 

Re: [PATCH] clk: qoriq: add ls1046a support

[Stephen Boyd]

On 09/07, shh@gmail.com wrote:
> From: Mingkai Hu 
> 
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Shaohui Xie 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v4] media: Driver for Toshiba et8ek8 5MP sensor

[Laurent Pinchart]

Hello,

On Tuesday 01 Nov 2016 00:58:45 Sakari Ailus wrote:
> On Sun, Oct 23, 2016 at 10:40:01PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > > Thanks, this answered half of my questions already. ;-)
> > > 
> > > Do all the modes work for you currently btw.?
> > 
> > Aha, went through my notes. This is what it does in 5MP mode, even on
> > v4.9:
> > 
> > pavel@n900:/my/fcam-dev$ ./camera.py
> > ['-r']
> > ['-l', '"et8ek8 3-003e":0 -> "video-bus-switch":1 [1]']
> > ['-l', '"video-bus-switch":0 -> "OMAP3 ISP CCP2":0 [1]']
> > ['-l', '"OMAP3 ISP CCP2":1 -> "OMAP3 ISP CCDC":0 [1]']
> > ['-l', '"OMAP3 ISP CCDC":1 -> "OMAP3 ISP CCDC output":0 [1]']
> > ['-V', '"et8ek8 3-003e":0 [SGRBG10 2592x1968]']
> > ['-V', '"OMAP3 ISP CCP2":0 [SGRBG10 2592x1968]']
> > ['-V', '"OMAP3 ISP CCP2":1 [SGRBG10 2592x1968]']
> > ['-V', '"OMAP3 ISP CCDC":1 [SGRBG10 2592x1968]']
> > ['-V', '"OMAP3 ISP CCDC":2 [SGRBG10 2592x1968]']
> > Device /dev/video2 opened.
> > Device `OMAP3 ISP CCDC output' on `media' is a video capture (without
> > mplanes) device.
> > Video format set: SGRBG10 (30314142) 2592x1968 (stride 5184) field
> > none buffer size 10202112
> > Video format: SGRBG10 (30314142) 2592x1968 (stride 5184) field none
> > buffer size 10202112
> > 4 buffers requested.
> > length: 10202112 offset: 0 timestamp type/source: mono/EoF
> > Buffer 0/0 mapped at address 0xb63a.
> > length: 10202112 offset: 10203136 timestamp type/source: mono/EoF
> > Buffer 1/0 mapped at address 0xb59e5000.
> > length: 10202112 offset: 20406272 timestamp type/source: mono/EoF
> > Buffer 2/0 mapped at address 0xb502a000.
> > length: 10202112 offset: 30609408 timestamp type/source: mono/EoF
> > Buffer 3/0 mapped at address 0xb466f000.
> > 0 (0) [E] any 0 10202112 B 0.00 2792.366987 0.001 fps ts mono/EoF
> > Unable to queue buffer: Input/output error (5).
> > Unable to requeue buffer: Input/output error (5).
> > Unable to release buffers: Device or resource busy (16).
> > pavel@n900:/my/fcam-dev$
> > 
> > (gitlab.com fcam-dev branch good)
> > 
> > Kernel will say
> > 
> > [ 2689.598358] stream on success
> > [ 2702.426635] Streamon
> > [ 2702.426727] check_format checking px 808534338 808534338, h 984
> > 984, w 1296 1296, bpline 2592 2592, size 2550528 2550528 field 1 1
> > [ 2702.426818] configuring for 1296(2592)x984
> > [ 2702.434722] stream on success
> > [ 2792.276184] Streamon
> > [ 2792.276306] check_format checking px 808534338 808534338, h 1968
> > 1968, w 2592 2592, bpline 5184 5184, size 10202112 10202112 field 1 1
> > [ 2792.276367] configuring for 2592(5184)x1968
> > [ 2792.284240] stream on success
> > [ 2792.368164] omap3isp 480bc000.isp: CCDC won't become idle!
> 
> This is Bad(tm).
> 
> It means that the driver waited for the CCDC to become idle to reprogram it,
> but it didn't happen. This could be a problem in the number of lines
> configured, or some polarity settings between the CCP2 receiver and the
> CCDC.

Is that polarity even configurable ?

> I suspect the latter, but I could be totally wrong here as well since
> it was more than five years I worked on these things. :-I

The OMAP3 ISP CCDC is very fragile when the input signals don't match exactly 
what it expects. This is partly caused by the driver implementation, I believe 
we could do better, but it's been a long time since I looked at that code.

One possible debugging option is to check how much data the CCDC has written 
to memory (if any). If I remember correctly the SBL_CCDC_WR_* registers can 
help there, the target address they store should be incremented as data is 
written to memory.

> > [ 2793.901550] omap3isp 480bc000.isp: Unable to stop OMAP3 ISP CCDC
> 
> And this is probably directly caused by the same problem. :-(

-- 
Regards,

Laurent Pinchart

Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC

[John Heenan]

Barry Day has submitted real world reports for the 8192eu and 8192cu.
This needs to be acknowledged. I have submitted real world reports for
the 8723bu.

When it comes down to it, it looks like the kernel code changes are
really going to be very trivial to fix this problem and we need to
take the focus off dramatic outbursts over style issues to a strategy
for getting usable results from real world testing.

Addressing style issues in a dramatic manner to me looks like a mean
sport for maintainers who line up to easy target first time
contributors. This mean attitude comes from the top with a well known
comment about "publicly making fun of people". The polite comments
over style from Joe Perches and Rafał Miłecki are welcomed.

An effective strategy would be to insert some printk statements to
trace what init steps vendor derived drivers do each time
wpa_supplicant is called and ask real world testers to report their
results. This is a lot more productive and less error prone than
laboriously pouring over vendor source code. Alternative drivers that
use vendor code from Realtek is enormously complicated and a huge pain
to make sense of.

Joe Sorensen's driver code is far easier to make sense of and it is a
shame Realtek don't come to the party. Joe Sorensens's code take takes
advantage of the excellent work of kernel contributors to the mac80211
driver.

Previous comments I made about enable_rf, rtl8xxxu_start,
rtl8xxxu_init_device etc should be clarified. I will leave it for the
moment as it currently serves no direct useful purpose.


John Heenan

On 1 November 2016 at 17:24, John Heenan  wrote:
> I have a prepared another patch that is not USB VID/PID dependent for
> rtl8723bu devices. It is more elegant. I will send it after this
> email.
>
> If I have more patches is it preferable I just put them on github only
> and notify a link address until there might be some resolution?
>
> What I meant below about not finding a matching function is that I
> cannot find matching actions to take on any function calls in
> rtl8xxxu_stop as for rtl8xxxu_start.
>
> The function that is called later and potentially more than once for
> rtl8723bu devices is rtl8xxxu_init_device. There is no corresponding
> rtl8xxxu_deinit_device function.
>
> enable_rf is called in rtl8xxxu_start, not in the delayed call to
> rtl8xxxu_init_device. The corresponding disable_rf is called in
> rtl8xxxu_stop. So no matching issue here. However please see below for
> another potential issue.
>
> power_on is called in rtl8xxxu_init_device. power_off is called in
> rtl8xxxu_disconnect. Does not appear to be an issue if calling
> power_on has no real effect if already on.
>
> The following should be looked at though. For all devices enable_rf is
> only called once. For the proposed patch the first call to
> rtl8xxxu_init_device is called after the single call to enable_rf for
> rtl8723bu devices. Without the patch enable_rf is called after
> rtl8xxxu_init_device for all devices
>
> Perhaps enable_rf just configures RF modes to start up when RF is
> powered on or if called after power_on then enters requested RF modes.
>
> So I cannot see appropriate additional matching action to take.
>
> Below is some background for anyone interested
>
> rtl8xxxu_start and rtl8xxxu_stop are assigned to rtl8xxxu_ops.
>
> rtl8xxxu_probe assigns rtl8xxxu_ops to its driver layer with
> ieee80211_register_hw.
>
> rtl8xxxu_disconnect unassigns rtl8xxxu_ops from its driver layer with
> ieee80211_unregister_hw.
>
> rtl8xxxu_probe and rtl8xxxu_disconnect are USB driver functions
>
> John Heenan
>
>
> On 1 November 2016 at 08:15, John Heenan  wrote:
>> On 1 November 2016 at 07:25, Jes Sorensen  wrote:
>>> John Heenan  writes:
>>
>>>
 @@ -5776,9 +5781,17 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
   struct rtl8xxxu_tx_urb *tx_urb;
   unsigned long flags;
   int ret, i;
 + struct usb_device_descriptor *udesc = >udev->descriptor;

   ret = 0;

 + if(udesc->idVendor == USB_VENDOR_ID_REALTEK
 + && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU) {
 + ret = rtl8xxxu_init_device(hw);
 + if (ret)
 + goto error_out;
 + }
 +
>>>
>>> As mentioned previously, if this is to be changed here, it has to be
>>> matched in the _stop section too.
>>
>> I looked at this and could not find a matching function. I will have a
>> look again.
>>

Re: [PATCH v3 1/7] clk: qcom: ipq4019: Added the clock nodes and operations for pll

[Stephen Boyd]

On 09/21, Abhishek Sahu wrote:
> The current ipq4019 clock driver registered the PLL clocks and
> dividers as fixed clock. These fixed clock needs to be removed
> from driver probe function and same need to be registered with
> clock framework. These PLL clocks should be programmed only
> once and the same are being programmed already by the boot
> loader so the set rate operation is not required for these
> clocks. Only the rate can be calculated by clock operations
> in clock driver file so this patch adds the same.
> 
> The PLL takes the reference clock from XO and generates the
> intermediate VCO frequency. This VCO frequency will be divided
> down by different PLL internal dividers. Some of the PLL
> internal dividers are fixed while other are programmable.
> 
> This patch does the following changes.

This should never be in the commit text. What a patch does should
be obvious from the patch itself. Why we're doing it is much more
important to express.

> 1. Operation for calculating PLL intermediate VCO frequency by
>reading the reference clock divider and feedback divider from
>register. Since VCO frequency falls outside the limit of
>unsigned long for IPQ4019, so this operation will return the
>VCO frequency in kHz.
> 
> 2. Operation for calculating the internal PLL divider clock
>frequency. Clock Divider node should give either fixed
>divider value or divider table(maps the register divider
>value to actual divider value).
> 
> 3. Adds and registers clock nodes for VCO(APPS DDR PLL and FE
>PLL) and PLL internal dividers(SDCC, FEPLL 500 MHz, FEPLL
>200 MHz, FEPLL 125 MHz, FEPLL 125 MHz with delay,
>programmable WCSS 2G and 5G).
> 
> 4. Changes the regmap limit from 0x2d to 0x2 for
>supporting the PLL registers read.

Yep that's obvious from the patch.

> 
> Signed-off-by: Abhishek Sahu 
> ---
>  drivers/clk/qcom/gcc-ipq4019.c   | 292 
> ++-
>  include/dt-bindings/clock/qcom,gcc-ipq4019.h |   9 +
>  2 files changed, 290 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
> index 3cd1af0..9251457 100644
> --- a/drivers/clk/qcom/gcc-ipq4019.c
> +++ b/drivers/clk/qcom/gcc-ipq4019.c
> @@ -28,6 +28,16 @@
>  #include "clk-rcg.h"
>  #include "clk-branch.h"
>  #include "reset.h"
> +#include "clk-regmap-divider.h"
> +
> +#define to_clk_regmap_div(_hw) container_of(to_clk_regmap(_hw),\
> + struct clk_regmap_div, clkr)
> +
> +#define to_clk_pll_div(_hw) container_of((to_clk_regmap_div(_hw)),\
> + struct clk_pll_div, cdiv)
> +
> +#define to_clk_pll_vco(_hw) container_of((to_clk_regmap_div(_hw)),\
> + struct clk_pll_vco, cdiv)
>  

Please remove double parenthesis around to_clk_regmap_div()
unlesss there's some reason for that?

>  enum {
>   P_XO,
> @@ -40,6 +50,35 @@ enum {
>   P_DDRPLLAPSS,
>  };
>  
> +/*
> + * struct clk_pll_vco - vco feedback divider corresponds to PLL_DIV register
> + * @fdbkdiv_shift: lowest bit for FDBKDIV
> + * @fdbkdiv_width: number of bits in FDBKDIV
> + * @cdiv: divider values for PLL_DIV
> + */
> +struct clk_pll_vco {
> + u32 fdbkdiv_shift;
> + u32 fdbkdiv_width;
> + struct clk_regmap_div cdiv;
> +};
> +
> +/*
> + * struct clk_pll_div - clk divider corresponds to PLL_DIV register
> + * @fixed_div: fixed divider value if divider is fixed
> + * @parent_map: map from software's parent index to hardware's src_sel field
> + * @cdiv: divider values for PLL_DIV
> + * @div_table: mapping for actual divider value to register divider value
> + * in case of non fixed divider
> + * @freq_tbl: frequency table
> + */
> +struct clk_pll_div {

s/clk_pll_div/clk_fepll/?

> + u32 fixed_div;
> + const u8 *parent_map;
> + struct clk_regmap_div cdiv;
> + const struct clk_div_table *div_table;
> + const struct freq_tbl *freq_tbl;
> +};
> +
>  static struct parent_map gcc_xo_200_500_map[] = {
>   { P_XO, 0 },
>   { P_FEPLL200, 1 },
> @@ -1155,6 +1194,238 @@ static struct clk_branch gcc_wcss5g_rtc_clk = {
>   },
>  };
>  
> +/*
> + * Calculates the rate from parent rate and divider and round the rate
> + * in MHz. This function takes the parent rate in kHz and returns the
> + * rate in Hz.
> + */
> +static unsigned long clk_calc_divider_rate(unsigned long parent_rate,

Umm... parent_rate should be in Hz here.

> + unsigned int div)
> +{
> + u32 rate;
> +
> + rate = parent_rate / div;
> +
> + /*
> +  * This rate is in kHz and returned value should be rounded
> +  * in MHz. So divide the value with 1000 and multiply it with
> +  * 1000(rate value was divided with 1000) * 1000(kHz to MHz).
> +  */
> + rate /= 1000;
> + rate *= 100;

Is this some complicated mechanism to round down to the 

Re: [PATCH v3 6/7] clk: qcom: ipq4019: changed the frequency value for ddr pll

[Stephen Boyd]

On 09/21, Abhishek Sahu wrote:
> diff --git a/drivers/clk/qcom/gcc-ipq4019.c b/drivers/clk/qcom/gcc-ipq4019.c
> index b2decd5..a2809db 100644
> --- a/drivers/clk/qcom/gcc-ipq4019.c
> +++ b/drivers/clk/qcom/gcc-ipq4019.c
> @@ -546,7 +546,7 @@ static const struct freq_tbl ftbl_gcc_sdcc1_apps_clk[] = {
>   F(2500,  P_FEPLL500, 1,  1, 20),
>   F(5000,  P_FEPLL500, 1,  1, 10),
>   F(1, P_FEPLL500, 1,  1, 5),
> - F(19000, P_DDRPLL,   1,  0, 0),
> + F(19200, P_DDRPLL,   1,  0, 0),

Change from 193 to 190 to 192 please do it once.

>   { }
>  };
>  
> @@ -567,18 +567,18 @@ static struct clk_rcg2  sdcc1_apps_clk_src = {
>  static const struct freq_tbl ftbl_gcc_apps_clk[] = {
>   F(4800,  P_XO, 1, 0, 0),
>   F(2, P_FEPLL200,   1, 0, 0),
> - F(38000, P_DDRPLLAPSS, 1, 0, 0),
> - F(40900, P_DDRPLLAPSS, 1, 0, 0),
> - F(44400, P_DDRPLLAPSS, 1, 0, 0),
> - F(48400, P_DDRPLLAPSS, 1, 0, 0),
> + F(38400, P_DDRPLLAPSS, 1, 0, 0),
> + F(41300, P_DDRPLLAPSS, 1, 0, 0),
> + F(44800, P_DDRPLLAPSS, 1, 0, 0),
> + F(48800, P_DDRPLLAPSS, 1, 0, 0),
>   F(5, P_FEPLL500,   1, 0, 0),
> - F(50700, P_DDRPLLAPSS, 1, 0, 0),
> - F(53200, P_DDRPLLAPSS, 1, 0, 0),
> - F(56000, P_DDRPLLAPSS, 1, 0, 0),
> - F(59200, P_DDRPLLAPSS, 1, 0, 0),
> - F(62600, P_DDRPLLAPSS, 1, 0, 0),
> - F(66600, P_DDRPLLAPSS, 1, 0, 0),
> - F(71000, P_DDRPLLAPSS, 1, 0, 0),
> + F(51200, P_DDRPLLAPSS, 1, 0, 0),
> + F(53700, P_DDRPLLAPSS, 1, 0, 0),
> + F(56500, P_DDRPLLAPSS, 1, 0, 0),
> + F(59700, P_DDRPLLAPSS, 1, 0, 0),
> + F(63200, P_DDRPLLAPSS, 1, 0, 0),
> + F(67200, P_DDRPLLAPSS, 1, 0, 0),
> + F(71600, P_DDRPLLAPSS, 1, 0, 0),

Didn't this patch series introduce table updates already? Why
can't this patch be squashed with that one?

>   { }

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 7/7] clk: qcom: ipq4019: changed i2c freq table

[Stephen Boyd]

On 09/21, Abhishek Sahu wrote:
> The current I2C freq table uses MND values which is not
> applicable for I2C since its RCG does not have MND
> counter. This patch updates the freq table for 19.05
> MHz clk frequency with FEPLL_200 parent.

That's concerning given that we read the registers, but I guess
it works out?

> 
> Signed-off-by: Abhishek Sahu 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] kobject: set state_initialized to 0 in kobject_cleanup

[Wu, Songjun]

On 11/1/2016 22:56, Greg KH wrote:

On Tue, Nov 01, 2016 at 06:41:44PM +0800, Songjun Wu wrote:

If state_initialized is not set to 0 when a kobject is
released, a device is registered, unregistered, and
registered again, the error below will occur.

kobject (dec04bb0): tried to init an initialized object,
something is seriously wrong.


Yes, your code is wrong, don't try to change the kernel core to work
around it :)

That message is there for a reason, and this patch has been rejected
many times in the past.  kobjects can NOT ever be reused, and should
never be static (but yes, there are lots of in-kernel users with static
kobjects, they just never get reused...)

What code is emitting this message?  I'll be glad to help you fix it up
if you can point me at it.


Thank you very much.
I will not use the static kobjects to fix the error.
:)

thanks,

greg k-h

Re: [PATCH 0/4 v2] Audio support for adv7511 hdmi bridge

[Kuninori Morimoto]

Hi John

> > Above patch is using normal simple-card style for HDMI sound, but as Laurent
> > said we want to use same DT style for HDMI video and sound (= OF graph 
> > style).
> > Fortunately, I posted patch-set for OF graph support on sound card 
> > yesterday.
> > Can you check this ?
> > http://www.spinics.net/lists/devicetree/msg146131.html
> > The points are
> >  - sound can use OF graph style DT
> >  - sound-card DT is no longer needed
> >  - it needs type = "sound" property
> >
> > patch-set [0/23] is this
> > http://www.spinics.net/lists/devicetree/msg146113.html
> 
> Thanks for the pointers! If I understand this correctly, the OF graph
> simple-card method would replace my current simple-card dts usage for
> hikey?   Other then just having another out-of-tree patchset to track,
> I don't have any objection to trying to use the OF graph simple-card
> method in the hikey dts (though I suspect I'll have to pester you for
> help when I give it a shot).

I posted v2 patchset OF graph simple-card which doesn't have "type" property.
Anyway, if you use OF graph simple-card, your "CPU" side driver need to
call asoc_simple_card_try_to_probe_graph_card() to probing it.

And this is not 100% mandatory, but your CPU and/or Codec driver
want to adjust OF graph style for parsing. The position is like this

simple-card :: dai-link <-> OF graph simple-card :: port/endpoint

[PATCH V4] mtd: nand: add Loongson1 NAND driver

[Keguang Zhang]

From: Kelvin Cheung 

This patch adds NAND driver for Loongson1B.

Signed-off-by: Kelvin Cheung 

---
v4:
   Retrieve the controller from nand_hw_control.
v3:
   Replace __raw_readl/__raw_writel with readl/writel.
   Split ls1x_nand into two structures: ls1x_nand_chip and
   ls1x_nand_controller.
V2:
   Modify the dependency in Kconfig due to the changes of DMA
   module.
---
 drivers/mtd/nand/Kconfig  |   8 +
 drivers/mtd/nand/Makefile |   1 +
 drivers/mtd/nand/loongson1_nand.c | 571 ++
 3 files changed, 580 insertions(+)
 create mode 100644 drivers/mtd/nand/loongson1_nand.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 7b7a887..2a815c7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -569,4 +569,12 @@ config MTD_NAND_MTK
  Enables support for NAND controller on MTK SoCs.
  This controller is found on mt27xx, mt81xx, mt65xx SoCs.
 
+config MTD_NAND_LOONGSON1
+   tristate "Support for Loongson1 SoC NAND controller"
+   depends on MACH_LOONGSON32
+   select DMADEVICES
+   select LOONGSON1_DMA
+   help
+   Enables support for NAND Flash on Loongson1 SoC based boards.
+
 endif # MTD_NAND
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index cafde6f..04f65a6 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -58,5 +58,6 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= 
hisi504_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/
 obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o
 obj-$(CONFIG_MTD_NAND_MTK) += mtk_nand.o mtk_ecc.o
+obj-$(CONFIG_MTD_NAND_LOONGSON1)   += loongson1_nand.o
 
 nand-objs := nand_base.o nand_bbt.o nand_timings.o
diff --git a/drivers/mtd/nand/loongson1_nand.c 
b/drivers/mtd/nand/loongson1_nand.c
new file mode 100644
index 000..e3999ea
--- /dev/null
+++ b/drivers/mtd/nand/loongson1_nand.c
@@ -0,0 +1,571 @@
+/*
+ * NAND Flash Driver for Loongson 1 SoC
+ *
+ * Copyright (C) 2015-2016 Zhang, Keguang 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Loongson 1 NAND Register Definitions */
+#define NAND_CMD   0x0
+#define NAND_ADDRL 0x4
+#define NAND_ADDRH 0x8
+#define NAND_TIMING0xc
+#define NAND_IDL   0x10
+#define NAND_IDH   0x14
+#define NAND_STATUS0x14
+#define NAND_PARAM 0x18
+#define NAND_OP_NUM0x1c
+#define NAND_CS_RDY0x20
+
+#define NAND_DMA_ADDR  0x40
+
+/* NAND Command Register Bits */
+#define NAND_RDY   BIT(10)
+#define OP_SPARE   BIT(9)
+#define OP_MAINBIT(8)
+#define CMD_STATUS BIT(7)
+#define CMD_RESET  BIT(6)
+#define CMD_READID BIT(5)
+#define BLOCKS_ERASE   BIT(4)
+#define CMD_ERASE  BIT(3)
+#define CMD_WRITE  BIT(2)
+#define CMD_READ   BIT(1)
+#define CMD_VALID  BIT(0)
+
+#defineLS1X_NAND_TIMEOUT   20
+
+/* macros for registers read/write */
+#define nand_readl(nandc, off) \
+   readl((nandc)->reg_base + (off))
+
+#define nand_writel(nandc, off, val)   \
+   writel((val), (nandc)->reg_base + (off))
+
+#define set_cmd(nandc, ctrl)   \
+   nand_writel(nandc, NAND_CMD, ctrl)
+
+#define start_nand(nandc)  \
+   nand_writel(nandc, NAND_CMD, nand_readl(nandc, NAND_CMD) | CMD_VALID)
+
+struct ls1x_nand_chip {
+   struct nand_chip chip;
+   struct plat_ls1x_nand *pdata;
+};
+
+struct ls1x_nand_controller {
+   struct nand_hw_control controller;
+   struct clk *clk;
+   void __iomem *reg_base;
+
+   int cmd_ctrl;
+   char datareg[8];
+   char *data_ptr;
+
+   /* DMA stuff */
+   unsigned char *dma_buf;
+   unsigned int buf_off;
+   unsigned int buf_len;
+
+   /* DMA Engine stuff */
+   unsigned int dma_chan_id;
+   struct dma_chan *dma_chan;
+   dma_cookie_t dma_cookie;
+   struct completion dma_complete;
+   void __iomem *dma_desc;
+};
+
+static inline struct ls1x_nand_chip *to_ls1x_nand_chip(struct mtd_info *mtd)
+{
+   return container_of(mtd_to_nand(mtd), struct ls1x_nand_chip, chip);
+}
+
+static struct ls1x_nand_controller *
+to_ls1x_nand_controller(struct nand_hw_control *ctrl)
+{
+   return container_of(ctrl, struct ls1x_nand_controller, controller);
+}
+
+static void dma_callback(void *data)
+{
+   struct mtd_info *mtd = (struct mtd_info *)data;
+   struct nand_chip *chip = mtd_to_nand(mtd);
+   

Re: [PATCH 45/60] block: bio: introduce bio_for_each_segment_all_rd() and its write pair

[Ming Lei]

On Tue, Nov 1, 2016 at 10:17 PM, Theodore Ts'o  wrote:
> On Tue, Nov 01, 2016 at 07:51:27AM +0800, Ming Lei wrote:
>> Sorry for forgetting to mention one important point:
>>
>> - after multipage bvec is introduced, the iterated bvec pointer
>> still points to singlge page bvec, which is generated in-flight
>> and is readonly actually. That is the motivation about the introduction
>> of bio_for_each_segment_all_rd().
>>
>> So maybe bio_for_each_page_all_ro() is better?
>>
>> For _wt(), we still can keep it as bio_for_each_segment(), which also
>> reflects that now the iterated bvec points to one whole segment if
>> we name _rd as bio_for_each_page_all_ro().
>
> I'm agnostic as to what the right names are --- my big concern is
> there is an explosion of bio_for_each_page_* functions, and that there

There isn't big users of bio_for_each_segment_all(), see:

[ming@linux-2.6]$git grep -n bio_for_each_segment_all ./fs/ | wc -l
23

I guess there isn't execuses to switch to that after this patchset.

>From view of API, bio_for_each_segment_all() is ugly and
exposes the bvec table to users, and the main reason we keep it
is that it can avoid one bvec copy in one loop. And it can be replaced
easily by bio_for_each_segment().

> isn't good documentation about (a) when to use each of these
> functions, and (b) why.  I was goinig through the patch series, and it
> was hard for me to figure out why, and I was looking through all of
> the patches.  Once all of the patches are merged in, I am concerned
> this is going to be massive trapdoor that will snare a large number of
> unwitting developers.

I understand your concern, and let me explain the whole story a bit:

1) in current linus tree, we have the following two bio iterator helpers,
for which we still don't provide any document:

   bio_for_each_segment(bvl, bio, iter)
   bio_for_each_segment_all(bvl, bio, i)

- the former is used to traverse each 'segment' in the bio range
descibed by the 'iter'(just like [start, size]); the latter is used
to traverse each 'segment' in the whole bio, so there isn't 'iter'
passed in.

- in the former helper, typeof('bvl') is 'struct bvec', and the 'segment'
is copied to 'bvl'; in the latter helper, typeof('bvl') is 'struct bvec *', and
it just points to one bvec directly in the table(bio->bi_io_vec) one by one.

- we can use the former helper to implement the latter easily and provide
a more friendly interface, and the main reason we keep it is that _all can
avoid bvec copy in each loop, so it might be a bit efficient.

- even segment is used in the helper's name, but each 'bvl' in the
helper just describes one single page, so actually they should have been
named as the following:

 bio_for_each_page(bvl, bio, iter)
 bio_for_each_page(bvl, bio, iter)

2) this patchset introduces multipage bvec, which will store one
real segment in each 'bvec' of the table(bio->bi_io_vec), and one
segment may include more than one page

- bio_for_each_segment() is kept as current interface to retrieve
one page in each 'bvl', that is just for making current users happy,
and it will be replaced with bio_for_each_page() finally, which
should be a follow-up work of this patchset

- the story of introduction of bio_for_each_segment_all_rd(bvl, bio, i):
we can't simply make 'bvl' point to each bvec in the table direclty
any more, because now each bvec in the table store one real segment
instead of one page. So in this patchst the _rd() is implemented by
bio_for_each_segment(), and we can't change/write to the bvec in the
table any more using the pointer of 'bvl' via this helper.

>
> As far as my preference, from an abstract perspective, if one version
> (the read-write variant, I presume) is always safe, while one (the
> read-only variant) is faster, if you can work under restricted
> circumstances, naming the safe version so it is the "default", and
> more dangerous one with the name that makes it a bit more obvious what
> you have to do in order to use it safely, and then very clearly
> document both in sources, and in the Documentation directory, what the
> issues are and what you have to do in order to use the faster version.

I will add detailed documents about these helpers in next version:

- bio_for_each_segment()
- bio_for_each_segment_all()
- bio_for_each_page_all_ro()(renamed from bio_for_each_segment_all_rd())

Thanks,
Ming

>
> Cheers,
>
> - Ted
>

Re: [GIT PULL] seccomp fixes for v4.9-rc4

[Kees Cook]

On Tue, Nov 1, 2016 at 4:43 PM, James Morris  wrote:
> On Tue, 1 Nov 2016, Kees Cook wrote:
>
>> Hi,
>>
>> Please pull these seccomp fixes for v4.9-rc4.
>
>> 
>> - fix function prototype documentation
>> - fix samples to include NNP setting
>> - fix samples to avoid rule truncation
>> - fix samples hostprogs variable in Makefile
>>
>> 
>
> These fixes don't seem very critical, and Linus was talking yesterday at
> KS about too much churn in the -rc series with non-critical fixes.
>
> How about we queue this up for 4.10?

Okay, sounds good to me. Thanks!

-Kees

-- 
Kees Cook
Nexus Security

Re: [PATCH] MIPS: VDSO: Always select -msoft-float

[Guenter Roeck]

On Tue, Nov 01, 2016 at 10:40:24PM +, Maciej W. Rozycki wrote:
> On Sun, 30 Oct 2016, Guenter Roeck wrote:
> 
> > Some toolchains fail to build mips images with the following build error.
> > 
> > arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'
> > 
> > This is seen, for example, with the 'mipsel-linux-gnu-gcc (Debian 6.1.1-9)
> > 6.1.1 20160705' toolchain as used by the 0Day build robot when building
> > decstation_defconfig.
> > 
> > Comparison of compile flags suggests that the major difference is a missing
> > '-soft-float', which is otherwise defined unconditionally.
> > 
> > Reported-by: kbuild test robot 
> > Cc: James Hogan 
> > Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
> > Signed-off-by: Guenter Roeck 
> > ---
> 
>  Using `-msoft-float' changes the floating-point ABI with the result being 
> incompatible with the rest of the userland.  I think the dynamic loader 
> may not be currently enforcing ABI compatibility here, but this may change 
> in the future.
> 
>  Using `-mno-float' in place of `-msoft-float' might be a safer option, 
> because even if we start enforcing floating-point ABI checks in dynamic 
> loading, then `-mno-float' DSOs will surely remain compatible with 
> everything else, because they guarantee no floating-point code or data 
> even to be ever produced by the compiler, be it using the software or the 
> hardware ABI.  One problem with that option is however that it is 
> apparently not universally accepted, for reasons unclear to me offhand.
> 
>  That written not so long ago I actually explicitly tried the config file 
> sent by the build bot reporting this issue and I built a kernel thus 
> configured with current upstream top-of-tree toolchain components, which 
> went just fine.  So what I suspect you've observied is just another sign 
> of a bug which has been already fixed, maybe even the very same binutils 
> bug I referred to recently.
> 
>  If you send me the generated assembly, i.e. `gettimeofday.s', that is 
> causing you trouble, then I'll see if I can figure out what is going on 
> here.  We may decide to paper a particularly nasty toolchain bug over from 

The problem is seen in 0Day builds, with the toolchain mentioned above.
I don't see the problem myself; I used to see it but switched toolchains
instead of trying to nail down the problem.

I don't think that generated assembly is going to help, though, since the
compiler fails to compile the code in the first place because, as it says,
it doesn't like '-march=r3000' without '-mfp32'.

Guenter

Re: [RFC v2 1/7] mm: Provide generic VDSO unmap and remap functions

[Christopher Covington]

On November 1, 2016 11:23:54 AM MDT, Dmitry Safonov <0x7f454...@gmail.com> 
wrote:
>Hi Christopher,
>
>  by this moment I got another patch for this. I hope, you don't mind
>if I send it concurrently. I haven't sent it yet as I was testing it in
> qemu.

Please do, that'd be great.

Thanks, 
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Sent from my Snapdragon powered Android device with K-9 Mail. Please excuse my 
brevity.

Re: [PATCH 2/2] clk: qcom: mmcc-8996: Add gpu gdscs

[Stephen Boyd]

On 10/20, Rajendra Nayak wrote:
> Add gpu gdsc data for msm8996
> 
> Signed-off-by: Rajendra Nayak 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] clk: qcom: Handle the clamp_io assert/deassert sequence

[Stephen Boyd]

On 10/20, Rajendra Nayak wrote:
> Add a flag to mark gdscs which need to support the clamp deassert/assert
> before and after the gdsc enable/disable
> 
> Signed-off-by: Rajendra Nayak 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: qoriq: add ls1046a support

[Stephen Boyd]

On 09/07, shh@gmail.com wrote:
> From: Mingkai Hu 
> 
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Shaohui Xie 

Would have been nice to have some blurb here about the chip being
supported, but ok.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH net-next 04/11] net: dsa: mv88e6xxx: add port FID accessors

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

>> --- a/drivers/net/dsa/mv88e6xxx/port.c
>> +++ b/drivers/net/dsa/mv88e6xxx/port.c
>> @@ -61,6 +61,8 @@ int mv88e6xxx_port_set_state(struct mv88e6xxx_chip *chip, 
>> int port, u8 state)
>>  return 0;
>>  }
>>  
>> +/* Offset 0x05: Port Control 1 */
>> +
>>  /* Offset 0x06: Port Based VLAN Map */
>>  
>>  int mv88e6xxx_port_set_vlan_map(struct mv88e6xxx_chip *chip, int port, u16 
>> map)
>
> This comment seems in an odd place.

It isn't. Port's default FID uses register 0x05 and I document them
above the related functions.

Thanks,

Vivien

Re: [Qemu-devel] [PATCH v10 00/19] Add Mediated device support

[Jike Song]

On 11/01/2016 11:24 PM, Gerd Hoffmann wrote:
>> I rebased KVMGT upon v10, with 2 minor changes:
>>
>>  1, get_user_pages_remote has only 7 args
> 
> Appears to be a 4.9 merge window change.  v10 as-is applies and builds
> fine against 4.8, after rebasing to 4.9-rc3 it stops building due to
> this.
> 
> Can you share the patch?
> 
>>  2, vfio iommu notifier calls vendor callback with iova instead of pfn
> 
> And this one too?
> 
> Also:  github seems to have the v9 kvmgt version still.  Can you push
> the update?

Zhenyu will help to push it to 01org/gvt-linux. Those 2 patches added by
me are trivial, I guess Kirti will have her formal fixes in next version.

> The kvmgt branch apparently depends on alot of unmerged stuff, "git
> describe" says 1669 patches on top of 4.8-rc8.
> 
> Can you outline what this is? Mostly drm-next?
> How much of this landed in the 4.9 merge window?

Yes, mostly drm-next, targeting 4.10 merge window. The overwhelming
part is the device-model under drivers/gpu/drm/i915/gvt/.
 

--
Thanks,
Jike

Re: [linux-sunxi] Re: [PATCH v3 1/2] drm/bridge: dumb-vga-dac: Support a VDD regulator supply

[Chen-Yu Tsai]

On Mon, Oct 31, 2016 at 2:28 PM, Rob Herring  wrote:
> On Sat, Oct 29, 2016 at 07:06:10PM +0800, Chen-Yu Tsai wrote:
>> Some dumb VGA DACs are active components which require external power.
>> Add support for specifying a regulator as its power supply.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  .../bindings/display/bridge/dumb-vga-dac.txt   |  2 ++
>
> For the binding,
>
> Acked-by: Rob Herring 
>
> One code comment below...
>
>>  drivers/gpu/drm/bridge/dumb-vga-dac.c  | 35 
>> ++
>>  2 files changed, 37 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt 
>> b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> index 003bc246a270..164cbb15f04c 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
>> @@ -16,6 +16,8 @@ graph bindings specified in 
>> Documentation/devicetree/bindings/graph.txt.
>>  - Video port 0 for RGB input
>>  - Video port 1 for VGA output
>>
>> +Optional properties:
>> +- vdd-supply: Power supply for DAC
>>
>>  Example
>>  ---
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c 
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> index afec232185a7..59781e031220 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -12,6 +12,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -23,6 +24,7 @@ struct dumb_vga {
>>   struct drm_connectorconnector;
>>
>>   struct i2c_adapter  *ddc;
>> + struct regulator*vdd;
>>  };
>>
>>  static inline struct dumb_vga *
>> @@ -124,8 +126,33 @@ static int dumb_vga_attach(struct drm_bridge *bridge)
>>   return 0;
>>  }
>>
>> +static void dumb_vga_enable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> + int ret;
>> +
>> + if (!IS_ERR(vga->vdd)) {
>
> if (IS_ERR())
> return;
>
> ...will save some intentation.

I thought about that, though if someone were to add more stuff to
this, such as an enable GPIO, they might have to rework it. A standalone
block of code would be easier to work with. I'm OK either way though.

ChenYu

>
>> + ret = regulator_enable(vga->vdd);
>> +
>> + if (ret) {
>> + DRM_ERROR("Failed to enable vdd regulator: %d\n", ret);
>> + return;
>> + }
>> + }
>> +}
>> +
>> +static void dumb_vga_disable(struct drm_bridge *bridge)
>> +{
>> + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
>> +
>> + if (!IS_ERR(vga->vdd))
>> + regulator_disable(vga->vdd);
>> +}
>> +
>>  static const struct drm_bridge_funcs dumb_vga_bridge_funcs = {
>>   .attach = dumb_vga_attach,
>> + .enable = dumb_vga_enable,
>> + .disable= dumb_vga_disable,
>>  };
>>
>>  static struct i2c_adapter *dumb_vga_retrieve_ddc(struct device *dev)
>> @@ -169,6 +196,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
>>   return -ENOMEM;
>>   platform_set_drvdata(pdev, vga);
>>
>> + vga->vdd = devm_regulator_get_optional(>dev, "vdd");
>> + if (IS_ERR(vga->vdd)) {
>> + ret = PTR_ERR(vga->vdd);
>> + if (ret == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> + dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
>> + }
>> +
>>   vga->ddc = dumb_vga_retrieve_ddc(>dev);
>>   if (IS_ERR(vga->ddc)) {
>>   if (PTR_ERR(vga->ddc) == -ENODEV) {
>> --
>> 2.9.3
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: tmpfs returns incorrect data on concurrent pread() and truncate()

[Hugh Dickins]

On Wed, 2 Nov 2016, Dave Chinner wrote:
> On Tue, Nov 01, 2016 at 04:51:30PM -0700, Hugh Dickins wrote:
> > On Wed, 26 Oct 2016, Jakob Unterwurzacher wrote:
> > 
> > > tmpfs seems to be incorrectly returning 0-bytes when reading from
> > > a file that is concurrently being truncated.
> > 
> > That is an interesting observation, and you got me worried;
> > but in fact, it is not a tmpfs problem: if we call it a
> > problem at all, it's a VFS problem or a userspace problem.
> > 
> > You chose a ratio of 3 preads to 1 ftruncate in your program below:
> > let's call that the Unterwurzacher Ratio, 3 for tmpfs; YMMV, but for
> > me 4 worked well to show the same issue on ramfs, and 15 on ext4.
> > 
> > The Linux VFS does not serialize reads against writes or truncation
> > very strictly:
> 
> Which is a fine, because...
> 
> > it's unusual to need that serialization, and most
> 
>  many filesystems need more robust serialisation as hole punching
> (and other fallocate-based extent manipulations) have much stricter
> serialisation requirements than truncate and these 
> 
> > users prefer maximum speed to the additional locking, or intermediate
> > buffering, that would be required to avoid the issue you've seen.
> 
>  require additional locking to be done at the filesystem level
> to avoid race conditions.
> 
> Throw in the fact that we already have to do this serialisation in
> the filesystem for direct IO as there are no page locks to serialise
> direct IO against truncate.  And we need to lock out page faults
> from refaulting while we are doing things like punching holes (to
> avoid data coherency and corruption bugs), so we need more
> filesystem level locks to serialise mmap against fallocate().
> 
> And DAX has similar issues - there are no struct pages to serialise
> read or mmap access against truncate, so again we need filesystem
> level serialisation for this.
> 
> Put simple: page locks are insufficient as a generic mechanism for
> serialising filesystem operations. The locking required for this is
> generally deeply filesystem implementation specific, so it's fine
> that the VFS doesn't attempt to provide anything stricter than it
> currently does

I think you are saying that: xfs already provides the extra locking
that avoids this issue; most other filesystems do not; but more can
be expected to add that extra locking in the coming months?

Hugh

[PATCH] ARM: dts: imx6: Add imx-weim parameters to dtsi's

[Joshua Clayton]

imx-weim should always set address-cells to 2,
and size_cells to 1.
On imx6, fsl,weim-cs-gpr will always be 

Set these common parameters in the dtsi file,
rather than in a downstream dts.

Signed-off-by: Joshua Clayton 
---
 arch/arm/boot/dts/imx6q-evi.dts  | 3 ---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 2 --
 arch/arm/boot/dts/imx6qdl.dtsi   | 3 +++
 arch/arm/boot/dts/imx6sl.dtsi| 3 +++
 arch/arm/boot/dts/imx6sx.dtsi| 3 +++
 5 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-evi.dts b/arch/arm/boot/dts/imx6q-evi.dts
index bd0b85c..a88cbd8 100644
--- a/arch/arm/boot/dts/imx6q-evi.dts
+++ b/arch/arm/boot/dts/imx6q-evi.dts
@@ -241,10 +241,7 @@
 };
 
  {
-   #address-cells = <2>;
-   #size-cells = <1>;
ranges = <0 0 0x0800 0x0800>;
-   fsl,weim-cs-gpr = <>;
pinctrl-names = "default";
pinctrl-0 = <_weimfpga _weimcs>;
status = "okay";
diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 8006467..52390ba 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -613,8 +613,6 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_weim_nor _weim_cs0>;
-   #address-cells = <2>;
-   #size-cells = <1>;
ranges = <0 0 0x0800 0x0800>;
status = "disabled"; /* pin conflict with SPI NOR */
 
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 1bbd36f..d7bed1f 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1092,10 +1092,13 @@
};
 
weim: weim@021b8000 {
+   #address-cells = <2>;
+   #size-cells = <1>;
compatible = "fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
clocks = < IMX6QDL_CLK_EIM_SLOW>;
+   fsl,weim-cs-gpr = <>;
};
 
ocotp: ocotp@021bc000 {
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 02378db..c2b28c0 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -893,8 +893,11 @@
};
 
weim: weim@021b8000 {
+   #address-cells = <2>;
+   #size-cells = <1>;
reg = <0x021b8000 0x4000>;
interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
+   fsl,weim-cs-gpr = <>;
};
 
ocotp: ocotp@021bc000 {
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 9526c38..78eb023 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -968,10 +968,13 @@
};
 
weim: weim@021b8000 {
+   #address-cells = <2>;
+   #size-cells = <1>;
compatible = "fsl,imx6sx-weim", 
"fsl,imx6q-weim";
reg = <0x021b8000 0x4000>;
interrupts = ;
clocks = < IMX6SX_CLK_EIM_SLOW>;
+   fsl,weim-cs-gpr = <>;
};
 
ocotp: ocotp@021bc000 {
-- 
2.7.4

Re: tmpfs returns incorrect data on concurrent pread() and truncate()

[Hugh Dickins]

On Wed, 26 Oct 2016, Jakob Unterwurzacher wrote:

> tmpfs seems to be incorrectly returning 0-bytes when reading from
> a file that is concurrently being truncated.

That is an interesting observation, and you got me worried;
but in fact, it is not a tmpfs problem: if we call it a
problem at all, it's a VFS problem or a userspace problem.

You chose a ratio of 3 preads to 1 ftruncate in your program below:
let's call that the Unterwurzacher Ratio, 3 for tmpfs; YMMV, but for
me 4 worked well to show the same issue on ramfs, and 15 on ext4.

The Linux VFS does not serialize reads against writes or truncation
very strictly: it's unusual to need that serialization, and most
users prefer maximum speed to the additional locking, or intermediate
buffering, that would be required to avoid the issue you've seen.

> 
> This is causing crashes in gocryptfs, a cryptographic FUSE overlay,
> when it reads a nonce from disk that should absolutely positively
> never be all-zero.

I don't think that there will be much appetite for changing the
kernel's VFS to prevent that.  I hope that gocryptfs can provide
the serialization that it needs for itself, or otherwise handle
those zeroes without crashing.

(Though if something is free to truncate at an awkward moment,
then I imagine it can also mess things up by writing wrong data.)

> 
> I have written a reproducer in C that triggers this issue on
> both boxes I tested, Linux 4.7.2 and 3.16.7, both amd64.
> 
> It can be downloaded from here:
> 
> https://gist.github.com/rfjakob/d01281c737db38075767f90bf03fc475
> 
> or, alternatively, I have attached it to this email at the bottom.
> 
> The reproducer:
> 1) Creates a 10MB file filled with 'x' at /dev/shm/x
> 2) Spawns a thread that truncates the file 3 bytes at a time
> 3) Spawns another thread that pread()s the file 1 byte at a time
>starting from the top
> 4) Prints "wrong data" whenever the pread() gets something that
>is not 'x' or an empty result.

Nice work, thank you, this helped me a lot.

Hugh

> 
> Example run:
> 
> $ gcc -Wall -lpthread truncate_read.c && ./a.out
> wrong data: 0
> wrong data: 0
> wrong data: 0
> wrong data: 0
> wrong data: 0
> wrong data: 0
> wrong data: 0
> wrong data: 0
> wrong data: 0
> wrong data: 0
> [...]
> 
> 
> Best regards,
> Jakob
> 
> 
> -
> truncate_read.c
> --8<---
> 
> 
> // Compile and run:
> // gcc -Wall -lpthread truncate_read.c && ./a.out
> 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int fd;
> int l = 10*1024*1024;
> pthread_t tid[2];
> 
> void* read_thread(void *arg){
>   int o,n;
>   char b;
>   for(o=l; o>0; o--) {
>   b = 'a';
>   n = pread(fd, , 1, o);
>   if(n==0) {
>   continue;
>   }
>   if(b != 'x') {
>   printf("wrong data: %x\n", b);
>   }
>   }
>   return NULL;
> }
> 
> void* truncate_thread(void *arg){
>   // Parent = Truncater
>   int o,n;
>   // "3" seems to be the sweet spot to trigger the most errors.
>   for(o=l; o>0; o-=3) {
>   n = ftruncate(fd, o);
>   if(n!=0) {
>   perror("ftruncate err");
>   }
>   }
>   return NULL;
> }
> 
> int main(int argc, char *argv[]) {
>   fd = open("/dev/shm/x", O_RDWR | O_TRUNC | O_CREAT, 0666);
>   if(fd < 0) {
>   printf("open failed\n");
>   exit(1);
>   }
>   char* x = malloc(l);
>   memset(x, 'x', l);
>   write(fd, x, l);
> 
>   pthread_create(&(tid[0]), NULL, _thread, NULL);
>   pthread_create(&(tid[1]), NULL, _thread, NULL);
> 
>   void *res;
>   pthread_join(tid[0], );
>   pthread_join(tid[1], );
> 
>   return 0;
> }

Kernel regression introduced by "e1000e: Do not write lsc to ics in msi-x mode" and/or "e1000e: Do not read ICR in Other interrupt"

[Jack Suter]

Hi there,

I have some servers with an 82574L based NIC and recently upgraded from
a 4.4 series kernel to 4.7. Upon doing so, servers with this chipset
have begun frequently reporting "Link is Down" and "Link is Up"
messages. No other related network errors are reported by the kernel or
e1000e driver. I saw some reports about using "ethtool -s $iface msglvl
6" to reveal more information, but nothing extra was reported.

Some testing showed that this was introduced between the 4.4 and 4.5
series. I was able to further narrow it down to two commits that look
related:

 e1000e: Do not write lsc to ics in msi-x mode
 (a61cfe4ffad7864a07e0c74969ca7ceb77ab2f1f)
 e1000e: Do not read ICR in Other interrupt
 (16ecba59bc333d6282ee057fb02339f77a880beb)

Reverting these two commits resolves the Link is Down/Link is Up
messages. This has been tested on about six servers so far and all have
stopped reporting these link flaps.

In total I have about ten servers that are frequently seeing this issue,
and a couple dozen more triggering it sporadically.

This is about the extent of my troubleshooting knowledge so far. I am
happy to test code changes and provide any additional information as
necessary. While I do not understand what specifically causes the link
flaps, they reliably begin occurring on the affected servers within a
couple hours of boot.

A snip of one such instance is below.

Thank you for any assistance troubleshooting this.

Kind regards,

Jack Suter

# ethtool -i enp2s0
driver: e1000e
version: 3.2.6-k
firmware-version: 2.1-2
bus-info: :02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

[ 3532.745587] e1000e: enp2s0 NIC Link is Down
[ 3532.771461] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[15463.117592] e1000e: enp2s0 NIC Link is Down
[15463.119419] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[15469.155922] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[15648.196579] e1000e: enp2s0 NIC Link is Down
[15651.405310] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[15728.959981] e1000e: enp2s0 NIC Link is Down
[15729.000625] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[15835.132034] e1000e: enp2s0 NIC Link is Down
[15835.185222] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[15839.104020] e1000e: enp2s0 NIC Link is Down
[15839.142346] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[15845.142287] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[16401.940127] e1000e: enp2s0 NIC Link is Down
[16401.945106] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[16408.121843] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[17025.823220] e1000e: enp2s0 NIC Link is Down
[17025.825473] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx
[17032.100202] e1000e: enp2s0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx/Tx

Re: [RFC/RFT][PATCH] cpufreq: intel_pstate: Generic governors support

[Srinivas Pandruvada]

On Tue, 2016-11-01 at 14:11 -0700, Doug Smythies wrote:
> On 2016.10.22 17:17 Rafael J. Wysocki wrote:
> 
> > 
> > From: Rafael J. Wysocki 
> > 
> > There may be reasons to use generic cpufreq governors (eg.
> > schedutil)
> > on Intel platforms instead of the intel_pstate driver's internal
> > governor.  However, that currently can only be done by disabling
> > intel_pstate altogether and using the acpi-cpufreq driver instead
> > of it, which is subject to limitations.
> > 
> > First of all, acpi-cpufreq only works on systems where the _PSS
> > object is present in the ACPI tables for all logical CPUs.  Second,
> > on those systems acpi-cpufreq will only use frequencies listed by
> > _PSS which may be suboptimal.  In particular, by convention, the
> > whole turbo range is represented in _PSS as a single P-state and
> > the frequency assigned to it is greater by 1 MHz than the greatest
> > non-turbo frequency listed by _PSS.  That may confuse governors to
> > use turbo frequencies less frequently which may lead to suboptimal
> > performance.
> > 
> > For this reason, make it possible to use the intel_pstate driver
> > with generic cpufreq governors as a "normal" cpufreq driver.  That
> > mode is enforced by adding intel_pstate=passive to the kernel
> > command line and cannot be disabled at run time.  In that mode,
> > intel_pstate provides a cpufreq driver interface including
> > the ->target() and ->fast_switch() callbacks and is listed in
> > scaling_driver as "intel_cpufreq".
> 
> It is not clear to me why users that currently use
> intel_pstate=disable on the kernel command line would benefit from
> this change.
Two reasons I think:
- We have a big turbo zone, where current acpi-cpufreq can't select any
target frequency even if controllable.

- We can still target ACPI-CPPC compatible devices in legacy mode and
later in non-legacy mode.

Thanks,
Srinivas

Re: [PATCH 1/3] clk: qcom: gdsc: Add support for gdscs with HW control

[Stephen Boyd]

On 10/24, Sricharan R wrote:
> @@ -164,6 +171,10 @@ static int gdsc_enable(struct generic_pm_domain *domain)
>*/
>   udelay(1);
>  
> + /* Turn on HW trigger mode if supported */
> + if (sc->flags & HW_CTRL)
> + gdsc_hwctrl(sc, true);
> +

It sounds like this will cause glitches if the hardware isn't
asserting their hw control bit by default? This has me concerned
that we can't just throw the hw control enable part into here,
because that bit doesn't live in the clock controller, instead it
lives in the hw block that is powered by the power domain?

Or does the power on reset value of that hw control signal
asserted? If that's true then we should be ok to force it into hw
control mode by default.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 12/15] clk: tegra: dfll: improve function-level documentation

[Stephen Boyd]

On 10/01, Julia Lawall wrote:
> Adjust variables to correspond to the names used in the parameter list of
> the function.  Move the struct device * variable up to the place where it
> appears in the parameter list.
> 
> Issue detected using Coccinelle (http://coccinelle.lip6.fr/)
> 
> Signed-off-by: Julia Lawall 
> 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 9/9] clocksource: import ARC timer driver

[Vineet Gupta]

On 11/01/2016 05:19 PM, Daniel Lezcano wrote:
>>>
>>> One question:
>>>
>>> Why ARC_TIMER_RTC can't be used in a SMP system ? Doesn't have each core its
>>> own clocksource ? It seems you are assuming a clocksource can be used on SMP
>>> only if the clocksource is unique and shared across the cores.
>>
>> Thats what I thought so far. Thing is, the individual core's counters could 
>> get
>> out of sync, simply because non masters cores were halted to begin with and 
>> came
>> up at different points in real time. so a gtod might return different value
>> depending on what core it landed on. Does clocksource also does ticks 
>> broadcasts
>> and such to keep things in sync ?
> 
> Sounds like it is similar than the TSC. Do you agree to have a try by setting
> the CONFIG_HAVE_UNSTABLE_SCHED_CLOCK option ?

I'm not sure why we would want to enable extra stuff - I see work queues and 
bunch
of per cpu counting / math to adjust for the variance, if this was enabled. 
Anyhow
see more below.

> If you can use those per cpu clocksource, performances on your system may
> improve with the sched_clock().

Couple of things

1. Currently we don't hookup sched clock to any counter at all (on my todo list
for a while). So we only get jiffies64 based value - I know that sucks - causes
scheduling to be not super accurate etc - potentially affects benchmarks etc - 
but
that can be fixed easily / independent of this.

2. Say we did have sched_clock() driven by hardware - in SMP system I would 
still
prefer it to be driven by "common" GFRC and not "per cpu" RTC. The overhead of
HAVE_UNSTABLE_SCHED_CLOCK looks way way more than reading GFRC counter like 
this.

local_irq_save(flags);

__mcip_cmd(CMD_GFRC_READ_LO, 0);
stamp.l = read_aux_reg(ARC_REG_MCIP_READBACK);

__mcip_cmd(CMD_GFRC_READ_HI, 0);
stamp.h = read_aux_reg(ARC_REG_MCIP_READBACK);

local_irq_restore(flags);

GFRC reading by 2 cores concurrently doesn't require any synchronization at all.
The irq disabling around it is to make sure we didn't get a bogus readout lest 
an
interrupt came in between the read of 2 words. But if sched_clock can guarantee
that irqs are disable - I can probably even remove it at least for the purpose 
of
sched clock.

However I think we are digressing here a bit. IMHO, what clock we choose to 
drive
sched should not really be driven by the driver. It must be for the arch to 
decide.

We should first focus on how the clockevent/sources are programmed first and 
then
dive into sched_clock_xx as that doesn't exist at the moment for ARC.

>  
>> Because of the git mv you, diff didn't include bulk of driver code which 
>> would
>> make for bulk of review anyways. So perhaps in v2 I don't do the git mv. OK ?
> 
> That means I will review and comment existing code. It is not a problem for me
> if you agree to do the changes.

Sure, the whole point is to make things better as an outcome of review. I have 
no
issues changing code provided we don't add major performance regressions.

Thx,
-Vineet

Re: tmpfs returns incorrect data on concurrent pread() and truncate()

[Dave Chinner]

On Tue, Nov 01, 2016 at 04:51:30PM -0700, Hugh Dickins wrote:
> On Wed, 26 Oct 2016, Jakob Unterwurzacher wrote:
> 
> > tmpfs seems to be incorrectly returning 0-bytes when reading from
> > a file that is concurrently being truncated.
> 
> That is an interesting observation, and you got me worried;
> but in fact, it is not a tmpfs problem: if we call it a
> problem at all, it's a VFS problem or a userspace problem.
> 
> You chose a ratio of 3 preads to 1 ftruncate in your program below:
> let's call that the Unterwurzacher Ratio, 3 for tmpfs; YMMV, but for
> me 4 worked well to show the same issue on ramfs, and 15 on ext4.
> 
> The Linux VFS does not serialize reads against writes or truncation
> very strictly:

Which is a fine, because...

> it's unusual to need that serialization, and most

 many filesystems need more robust serialisation as hole punching
(and other fallocate-based extent manipulations) have much stricter
serialisation requirements than truncate and these 

> users prefer maximum speed to the additional locking, or intermediate
> buffering, that would be required to avoid the issue you've seen.

 require additional locking to be done at the filesystem level
to avoid race conditions.

Throw in the fact that we already have to do this serialisation in
the filesystem for direct IO as there are no page locks to serialise
direct IO against truncate.  And we need to lock out page faults
from refaulting while we are doing things like punching holes (to
avoid data coherency and corruption bugs), so we need more
filesystem level locks to serialise mmap against fallocate().

And DAX has similar issues - there are no struct pages to serialise
read or mmap access against truncate, so again we need filesystem
level serialisation for this.

Put simple: page locks are insufficient as a generic mechanism for
serialising filesystem operations. The locking required for this is
generally deeply filesystem implementation specific, so it's fine
that the VFS doesn't attempt to provide anything stricter than it
currently does

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

[PATCH 1/1] xen-netfront: cast grant table reference first to type int

[Dongli Zhang]

IS_ERR_VALUE() in commit 87557efc27f6a50140fb20df06a917f368ce3c66
("xen-netfront: do not cast grant table reference to signed short") would
not return true for error code unless we cast ref first to type int.

Signed-off-by: Dongli Zhang 
---
 drivers/net/xen-netfront.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 189a28d..bf2744e 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -304,7 +304,7 @@ static void xennet_alloc_rx_buffers(struct netfront_queue 
*queue)
queue->rx_skbs[id] = skb;
 
ref = gnttab_claim_grant_reference(>gref_rx_head);
-   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
+   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)(int)ref));
queue->grant_rx_ref[id] = ref;
 
page = skb_frag_page(_shinfo(skb)->frags[0]);
@@ -428,7 +428,7 @@ static void xennet_tx_setup_grant(unsigned long gfn, 
unsigned int offset,
id = get_id_from_freelist(>tx_skb_freelist, queue->tx_skbs);
tx = RING_GET_REQUEST(>tx, queue->tx.req_prod_pvt++);
ref = gnttab_claim_grant_reference(>gref_tx_head);
-   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)ref));
+   WARN_ON_ONCE(IS_ERR_VALUE((unsigned long)(int)ref));
 
gnttab_grant_foreign_access_ref(ref, queue->info->xbdev->otherend_id,
gfn, GNTMAP_readonly);
-- 
2.7.4

Re: [PATCH net-next 07/11] net: dsa: mv88e6xxx: add port link setter

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

>> +#define LINK_UNKNOWN-1
>> +
>> +/* Port's MAC link state
>> + * LINK_UNKNOWN for normal link detection, 0 to force link down,
>> + * otherwise force link up.
>> + */
>> +int (*port_set_link)(struct mv88e6xxx_chip *chip, int port, int link);
>
> Maybe LINK_AUTO would be better than UNKNOWN? Or LINK_UNFORCED.

I used LINK_UNKNOWN to be consistent with the supported SPEED_UNKNOWN
and DUPLEX_UNKNOWN values of PHY devices.

Thanks,

Vivien

Re: [Qemu-devel] [PATCH v9 04/12] vfio iommu: Add support for mediated devices

[Alexey Kardashevskiy]

On 02/11/16 01:01, Kirti Wankhede wrote:
> 
> 
> On 10/28/2016 7:48 AM, Alexey Kardashevskiy wrote:
>> On 27/10/16 23:31, Kirti Wankhede wrote:
>>>
>>>
>>> On 10/27/2016 12:50 PM, Alexey Kardashevskiy wrote:
 On 18/10/16 08:22, Kirti Wankhede wrote:
> VFIO IOMMU drivers are designed for the devices which are IOMMU capable.
> Mediated device only uses IOMMU APIs, the underlying hardware can be
> managed by an IOMMU domain.
>
> Aim of this change is:
> - To use most of the code of TYPE1 IOMMU driver for mediated devices
> - To support direct assigned device and mediated device in single module
>
> Added two new callback functions to struct vfio_iommu_driver_ops. Backend
> IOMMU module that supports pining and unpinning pages for mdev devices
> should provide these functions.
> Added APIs for pining and unpining pages to VFIO module. These calls back
> into backend iommu module to actually pin and unpin pages.
>
> This change adds pin and unpin support for mediated device to TYPE1 IOMMU
> backend module. More details:
> - When iommu_group of mediated devices is attached, task structure is
>   cached which is used later to pin pages and page accounting.


 For SPAPR TCE IOMMU driver, I ended up caching mm_struct with
 atomic_inc(>mm->mm_count) (patches are on the way) instead of
 using @current or task as the process might be gone while VFIO container is
 still alive and @mm might be needed to do proper cleanup; this might not be
 an issue with this patchset now but still you seem to only use @mm from
 task_struct.

>>>
>>> Consider the example of QEMU process which creates VFIO container, QEMU
>>> in its teardown path would release the container. How could container be
>>> alive when process is gone?
>>
>> do_exit() in kernel/exit.c calls exit_mm() (which sets NULL to tsk->mm)
>> first, and then releases open files by calling  exit_files(). So
>> container's release() does not have current->mm.
>>
> 
> Incrementing usage count (get_task_struct()) while saving task structure
> and decementing it (put_task_struct()) from release() should  work here.
> Updating the patch.

I cannot see how the task->usage counter prevents do_exit() from performing
the exit, can you?



-- 
Alexey