[PATCH] usb: core: sysfs: constify attribute_group

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
   67982848   4965025b2 drivers/usb/core/sysfs.o

File size After adding 'const':
   textdata bss dec hex filename
   72302400   4963425a2 drivers/usb/core/sysfs.o

Signed-off-by: Arvind Yadav 
---
 drivers/usb/core/sysfs.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index dfc68ed..2af3121 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -617,7 +617,7 @@ static ssize_t usb3_hardware_lpm_u2_show(struct device *dev,
_attr_usb2_lpm_besl.attr,
NULL,
 };
-static struct attribute_group usb2_hardware_lpm_attr_group = {
+static const struct attribute_group usb2_hardware_lpm_attr_group = {
.name   = power_group_name,
.attrs  = usb2_hardware_lpm_attr,
 };
@@ -627,7 +627,7 @@ static ssize_t usb3_hardware_lpm_u2_show(struct device *dev,
_attr_usb3_hardware_lpm_u2.attr,
NULL,
 };
-static struct attribute_group usb3_hardware_lpm_attr_group = {
+static const struct attribute_group usb3_hardware_lpm_attr_group = {
.name   = power_group_name,
.attrs  = usb3_hardware_lpm_attr,
 };
@@ -639,7 +639,7 @@ static ssize_t usb3_hardware_lpm_u2_show(struct device *dev,
_attr_active_duration.attr,
NULL,
 };
-static struct attribute_group power_attr_group = {
+static const struct attribute_group power_attr_group = {
.name   = power_group_name,
.attrs  = power_attrs,
 };
@@ -805,7 +805,7 @@ static ssize_t remove_store(struct device *dev, struct 
device_attribute *attr,
 #endif
NULL,
 };
-static struct attribute_group dev_attr_grp = {
+static const struct attribute_group dev_attr_grp = {
.attrs = dev_attrs,
 };
 
@@ -838,7 +838,7 @@ static umode_t dev_string_attrs_are_visible(struct kobject 
*kobj,
return a->mode;
 }
 
-static struct attribute_group dev_string_attr_grp = {
+static const struct attribute_group dev_string_attr_grp = {
.attrs =dev_string_attrs,
.is_visible =   dev_string_attrs_are_visible,
 };
@@ -1070,7 +1070,7 @@ static ssize_t interface_authorized_store(struct device 
*dev,
_attr_interface_authorized.attr,
NULL,
 };
-static struct attribute_group intf_attr_grp = {
+static const struct attribute_group intf_attr_grp = {
.attrs = intf_attrs,
 };
 
@@ -1094,7 +1094,7 @@ static umode_t intf_assoc_attrs_are_visible(struct 
kobject *kobj,
return a->mode;
 }
 
-static struct attribute_group intf_assoc_attr_grp = {
+static const struct attribute_group intf_assoc_attr_grp = {
.attrs =intf_assoc_attrs,
.is_visible =   intf_assoc_attrs_are_visible,
 };
-- 
1.9.1

[PATCH] usb: core: sysfs: constify attribute_group

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
   67982848   4965025b2 drivers/usb/core/sysfs.o

File size After adding 'const':
   textdata bss dec hex filename
   72302400   4963425a2 drivers/usb/core/sysfs.o

Signed-off-by: Arvind Yadav 
---
 drivers/usb/core/sysfs.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/core/sysfs.c b/drivers/usb/core/sysfs.c
index dfc68ed..2af3121 100644
--- a/drivers/usb/core/sysfs.c
+++ b/drivers/usb/core/sysfs.c
@@ -617,7 +617,7 @@ static ssize_t usb3_hardware_lpm_u2_show(struct device *dev,
_attr_usb2_lpm_besl.attr,
NULL,
 };
-static struct attribute_group usb2_hardware_lpm_attr_group = {
+static const struct attribute_group usb2_hardware_lpm_attr_group = {
.name   = power_group_name,
.attrs  = usb2_hardware_lpm_attr,
 };
@@ -627,7 +627,7 @@ static ssize_t usb3_hardware_lpm_u2_show(struct device *dev,
_attr_usb3_hardware_lpm_u2.attr,
NULL,
 };
-static struct attribute_group usb3_hardware_lpm_attr_group = {
+static const struct attribute_group usb3_hardware_lpm_attr_group = {
.name   = power_group_name,
.attrs  = usb3_hardware_lpm_attr,
 };
@@ -639,7 +639,7 @@ static ssize_t usb3_hardware_lpm_u2_show(struct device *dev,
_attr_active_duration.attr,
NULL,
 };
-static struct attribute_group power_attr_group = {
+static const struct attribute_group power_attr_group = {
.name   = power_group_name,
.attrs  = power_attrs,
 };
@@ -805,7 +805,7 @@ static ssize_t remove_store(struct device *dev, struct 
device_attribute *attr,
 #endif
NULL,
 };
-static struct attribute_group dev_attr_grp = {
+static const struct attribute_group dev_attr_grp = {
.attrs = dev_attrs,
 };
 
@@ -838,7 +838,7 @@ static umode_t dev_string_attrs_are_visible(struct kobject 
*kobj,
return a->mode;
 }
 
-static struct attribute_group dev_string_attr_grp = {
+static const struct attribute_group dev_string_attr_grp = {
.attrs =dev_string_attrs,
.is_visible =   dev_string_attrs_are_visible,
 };
@@ -1070,7 +1070,7 @@ static ssize_t interface_authorized_store(struct device 
*dev,
_attr_interface_authorized.attr,
NULL,
 };
-static struct attribute_group intf_attr_grp = {
+static const struct attribute_group intf_attr_grp = {
.attrs = intf_attrs,
 };
 
@@ -1094,7 +1094,7 @@ static umode_t intf_assoc_attrs_are_visible(struct 
kobject *kobj,
return a->mode;
 }
 
-static struct attribute_group intf_assoc_attr_grp = {
+static const struct attribute_group intf_assoc_attr_grp = {
.attrs =intf_assoc_attrs,
.is_visible =   intf_assoc_attrs_are_visible,
 };
-- 
1.9.1

[GIT PULL] sound fixes for 4.12-rc7

[Takashi Iwai]

Linus,

please pull sound fixes for v4.12-rc7 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-4.12-rc7

The topmost commit is c7ecb9068e6772c43941ce609f08bc53f36e1dce



sound fixes for 4.12-rc7

Nothing exciting here, just a few stable fixes:
- Suppress spurious kernel WARNING in PCM core
- Fix potential spin deadlock at error handling in firewire
- HD-audio PCI ID addition / fixup



Megha Dey (1):
  ALSA: hda - Add Coffelake PCI ID

Takashi Iwai (2):
  ALSA: pcm: Don't treat NULL chmap as a fatal error
  ALSA: hda - Apply quirks to Broxton-T, too

Takashi Sakamoto (1):
  ALSA: firewire-lib: Fix stall of process context at packet error

---
 sound/core/pcm_lib.c  |  4 ++--
 sound/firewire/amdtp-stream.c |  8 ++--
 sound/firewire/amdtp-stream.h |  2 +-
 sound/pci/hda/hda_intel.c | 11 ---
 4 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 5088d4b8db22..009e6c98754e 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -2492,7 +2492,7 @@ static int pcm_chmap_ctl_get(struct snd_kcontrol 
*kcontrol,
struct snd_pcm_substream *substream;
const struct snd_pcm_chmap_elem *map;
 
-   if (snd_BUG_ON(!info->chmap))
+   if (!info->chmap)
return -EINVAL;
substream = snd_pcm_chmap_substream(info, idx);
if (!substream)
@@ -2524,7 +2524,7 @@ static int pcm_chmap_ctl_tlv(struct snd_kcontrol 
*kcontrol, int op_flag,
unsigned int __user *dst;
int c, count = 0;
 
-   if (snd_BUG_ON(!info->chmap))
+   if (!info->chmap)
return -EINVAL;
if (size < 8)
return -ENOMEM;
diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c
index 9e6f54f8c45d..1e26854b3425 100644
--- a/sound/firewire/amdtp-stream.c
+++ b/sound/firewire/amdtp-stream.c
@@ -682,7 +682,9 @@ static void out_stream_callback(struct fw_iso_context 
*context, u32 tstamp,
cycle = increment_cycle_count(cycle, 1);
if (s->handle_packet(s, 0, cycle, i) < 0) {
s->packet_index = -1;
-   amdtp_stream_pcm_abort(s);
+   if (in_interrupt())
+   amdtp_stream_pcm_abort(s);
+   WRITE_ONCE(s->pcm_buffer_pointer, SNDRV_PCM_POS_XRUN);
return;
}
}
@@ -734,7 +736,9 @@ static void in_stream_callback(struct fw_iso_context 
*context, u32 tstamp,
/* Queueing error or detecting invalid payload. */
if (i < packets) {
s->packet_index = -1;
-   amdtp_stream_pcm_abort(s);
+   if (in_interrupt())
+   amdtp_stream_pcm_abort(s);
+   WRITE_ONCE(s->pcm_buffer_pointer, SNDRV_PCM_POS_XRUN);
return;
}
 
diff --git a/sound/firewire/amdtp-stream.h b/sound/firewire/amdtp-stream.h
index 7e8831722821..ea1a91e99875 100644
--- a/sound/firewire/amdtp-stream.h
+++ b/sound/firewire/amdtp-stream.h
@@ -135,7 +135,7 @@ struct amdtp_stream {
/* For a PCM substream processing. */
struct snd_pcm_substream *pcm;
struct tasklet_struct period_tasklet;
-   unsigned int pcm_buffer_pointer;
+   snd_pcm_uframes_t pcm_buffer_pointer;
unsigned int pcm_period_pointer;
 
/* To wait for first packet. */
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1770f085c2a6..01eb1dc7b5b3 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -370,10 +370,12 @@ enum {
 #define IS_KBL_LP(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x9d71)
 #define IS_KBL_H(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa2f0)
 #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
+#define IS_BXT_T(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x1a98)
 #define IS_GLK(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x3198)
-#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci)) || \
-   IS_KBL(pci) || IS_KBL_LP(pci) || IS_KBL_H(pci)  || \
-   IS_GLK(pci)
+#define IS_CFL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa348)
+#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci) || \
+ IS_BXT_T(pci) || IS_KBL(pci) || IS_KBL_LP(pci) || \
+ IS_KBL_H(pci) || IS_GLK(pci) || IS_CFL(pci))
 
 static char *driver_short_names[] = {
[AZX_DRIVER_ICH] = "HDA Intel",
@@ -2378,6 +2380,9 @@ static const struct pci_device_id azx_ids[] = {
/* Kabylake-H */
{ PCI_DEVICE(0x8086, 0xa2f0),
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
+   /* Coffelake */
+   { PCI_DEVICE(0x8086, 

[GIT PULL] sound fixes for 4.12-rc7

[Takashi Iwai]

Linus,

please pull sound fixes for v4.12-rc7 from:

  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
tags/sound-4.12-rc7

The topmost commit is c7ecb9068e6772c43941ce609f08bc53f36e1dce



sound fixes for 4.12-rc7

Nothing exciting here, just a few stable fixes:
- Suppress spurious kernel WARNING in PCM core
- Fix potential spin deadlock at error handling in firewire
- HD-audio PCI ID addition / fixup



Megha Dey (1):
  ALSA: hda - Add Coffelake PCI ID

Takashi Iwai (2):
  ALSA: pcm: Don't treat NULL chmap as a fatal error
  ALSA: hda - Apply quirks to Broxton-T, too

Takashi Sakamoto (1):
  ALSA: firewire-lib: Fix stall of process context at packet error

---
 sound/core/pcm_lib.c  |  4 ++--
 sound/firewire/amdtp-stream.c |  8 ++--
 sound/firewire/amdtp-stream.h |  2 +-
 sound/pci/hda/hda_intel.c | 11 ---
 4 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index 5088d4b8db22..009e6c98754e 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -2492,7 +2492,7 @@ static int pcm_chmap_ctl_get(struct snd_kcontrol 
*kcontrol,
struct snd_pcm_substream *substream;
const struct snd_pcm_chmap_elem *map;
 
-   if (snd_BUG_ON(!info->chmap))
+   if (!info->chmap)
return -EINVAL;
substream = snd_pcm_chmap_substream(info, idx);
if (!substream)
@@ -2524,7 +2524,7 @@ static int pcm_chmap_ctl_tlv(struct snd_kcontrol 
*kcontrol, int op_flag,
unsigned int __user *dst;
int c, count = 0;
 
-   if (snd_BUG_ON(!info->chmap))
+   if (!info->chmap)
return -EINVAL;
if (size < 8)
return -ENOMEM;
diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c
index 9e6f54f8c45d..1e26854b3425 100644
--- a/sound/firewire/amdtp-stream.c
+++ b/sound/firewire/amdtp-stream.c
@@ -682,7 +682,9 @@ static void out_stream_callback(struct fw_iso_context 
*context, u32 tstamp,
cycle = increment_cycle_count(cycle, 1);
if (s->handle_packet(s, 0, cycle, i) < 0) {
s->packet_index = -1;
-   amdtp_stream_pcm_abort(s);
+   if (in_interrupt())
+   amdtp_stream_pcm_abort(s);
+   WRITE_ONCE(s->pcm_buffer_pointer, SNDRV_PCM_POS_XRUN);
return;
}
}
@@ -734,7 +736,9 @@ static void in_stream_callback(struct fw_iso_context 
*context, u32 tstamp,
/* Queueing error or detecting invalid payload. */
if (i < packets) {
s->packet_index = -1;
-   amdtp_stream_pcm_abort(s);
+   if (in_interrupt())
+   amdtp_stream_pcm_abort(s);
+   WRITE_ONCE(s->pcm_buffer_pointer, SNDRV_PCM_POS_XRUN);
return;
}
 
diff --git a/sound/firewire/amdtp-stream.h b/sound/firewire/amdtp-stream.h
index 7e8831722821..ea1a91e99875 100644
--- a/sound/firewire/amdtp-stream.h
+++ b/sound/firewire/amdtp-stream.h
@@ -135,7 +135,7 @@ struct amdtp_stream {
/* For a PCM substream processing. */
struct snd_pcm_substream *pcm;
struct tasklet_struct period_tasklet;
-   unsigned int pcm_buffer_pointer;
+   snd_pcm_uframes_t pcm_buffer_pointer;
unsigned int pcm_period_pointer;
 
/* To wait for first packet. */
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1770f085c2a6..01eb1dc7b5b3 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -370,10 +370,12 @@ enum {
 #define IS_KBL_LP(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x9d71)
 #define IS_KBL_H(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa2f0)
 #define IS_BXT(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x5a98)
+#define IS_BXT_T(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x1a98)
 #define IS_GLK(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0x3198)
-#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci)) || \
-   IS_KBL(pci) || IS_KBL_LP(pci) || IS_KBL_H(pci)  || \
-   IS_GLK(pci)
+#define IS_CFL(pci) ((pci)->vendor == 0x8086 && (pci)->device == 0xa348)
+#define IS_SKL_PLUS(pci) (IS_SKL(pci) || IS_SKL_LP(pci) || IS_BXT(pci) || \
+ IS_BXT_T(pci) || IS_KBL(pci) || IS_KBL_LP(pci) || \
+ IS_KBL_H(pci) || IS_GLK(pci) || IS_CFL(pci))
 
 static char *driver_short_names[] = {
[AZX_DRIVER_ICH] = "HDA Intel",
@@ -2378,6 +2380,9 @@ static const struct pci_device_id azx_ids[] = {
/* Kabylake-H */
{ PCI_DEVICE(0x8086, 0xa2f0),
  .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
+   /* Coffelake */
+   { PCI_DEVICE(0x8086, 

[no subject]

[Administrator]

PERHATIAN

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama:
Username:
sandi:
Konfirmasi sandi:
E-mail:
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:0986..web...id..nw..website Admin..id...9876mm.2017
Surat Dukungan Teknis ©2017

terima kasih
Sistem Administrator

[no subject]

[Administrator]

PERHATIAN

Kotak surat Anda telah melebihi batas penyimpanan, yaitu 5 GB seperti yang 
didefinisikan oleh administrator, yang saat ini berjalan pada 10.9GB, Anda 
mungkin tidak dapat mengirim atau menerima surat baru sampai Anda kembali 
memvalidasi email mailbox Anda. Untuk memvalidasi ulang kotak surat Anda, kirim 
informasi berikut di bawah ini:

Nama:
Username:
sandi:
Konfirmasi sandi:
E-mail:
telepon:

Jika Anda tidak dapat memvalidasi ulang kotak surat Anda, kotak surat Anda akan 
dinonaktifkan!

Maaf atas ketidaknyamanan ini.
Kode verifikasi: en:0986..web...id..nw..website Admin..id...9876mm.2017
Surat Dukungan Teknis ©2017

terima kasih
Sistem Administrator

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

[Darren Hart]

On Fri, Jun 23, 2017 at 09:44:58AM +0930, Jonathan Woithe wrote:
> On Thu, Jun 22, 2017 at 04:58:09PM -0700, Darren Hart wrote:
> > On Thu, Jun 22, 2017 at 10:46:19PM +0200, Micha?? K??pie?? wrote:
> > > > The events seen by userspace with the original code would be "A-press",
> > > > "B-press", "A-release", "B-release".  With the revised code the order 
> > > > of the
> > > > release events would be reversed compared to the previous behaviour.  
> > > > That
> > > > is, unless I've misunderstood how sparse_keymap_report_event() works.
> > > 
> > > All you wrote above is correct and this patch does change the order of
> > > release events sent to userspace when multiple hotkeys are pressed
> > > simultaneously.  The question is: is it relevant for any practical
> > > scenario?
> > > 
> > > Anyway, I find this matter to be of secondary importance.  The primary
> > > objective of this patch is to get rid of the kfifo.  If anyone has
> > > strong feelings about the change in event ordering, I will be happy to
> > > revert to FIFO in v2.
> > 
> > This all looks reasonable to me, I don't see anything requiring a respin.
> 
> I agree it is of seconary importance.  To me, using LIFO release order is
> counter-intuitive, but it's the sort of question that if put to 100 people
> you'll get a 50/50 split of opinions.
> 
> Especially since the whole "multiple buttons held at once" scenario is
> rather unusual we can go with switching the order if others don't see a
> problem with the behavioural change.

Yes. If anyone notices the implementation difference, I'll be rather surprised.
If they do, we can convert back to FIFO as you say.
-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes

[Darren Hart]

On Fri, Jun 23, 2017 at 09:44:58AM +0930, Jonathan Woithe wrote:
> On Thu, Jun 22, 2017 at 04:58:09PM -0700, Darren Hart wrote:
> > On Thu, Jun 22, 2017 at 10:46:19PM +0200, Micha?? K??pie?? wrote:
> > > > The events seen by userspace with the original code would be "A-press",
> > > > "B-press", "A-release", "B-release".  With the revised code the order 
> > > > of the
> > > > release events would be reversed compared to the previous behaviour.  
> > > > That
> > > > is, unless I've misunderstood how sparse_keymap_report_event() works.
> > > 
> > > All you wrote above is correct and this patch does change the order of
> > > release events sent to userspace when multiple hotkeys are pressed
> > > simultaneously.  The question is: is it relevant for any practical
> > > scenario?
> > > 
> > > Anyway, I find this matter to be of secondary importance.  The primary
> > > objective of this patch is to get rid of the kfifo.  If anyone has
> > > strong feelings about the change in event ordering, I will be happy to
> > > revert to FIFO in v2.
> > 
> > This all looks reasonable to me, I don't see anything requiring a respin.
> 
> I agree it is of seconary importance.  To me, using LIFO release order is
> counter-intuitive, but it's the sort of question that if put to 100 people
> you'll get a 50/50 split of opinions.
> 
> Especially since the whole "multiple buttons held at once" scenario is
> rather unusual we can go with switching the order if others don't see a
> problem with the behavioural change.

Yes. If anyone notices the implementation difference, I'll be rather surprised.
If they do, we can convert back to FIFO as you say.
-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 5/7] platform/x86: fujitsu-laptop: do not update ACPI device power status

[Darren Hart]

On Fri, Jun 23, 2017 at 09:46:59AM +0930, Jonathan Woithe wrote:
> Thanks.  In case it was missed, I supplied my reviewed-by message and
> sign-off in an earlier post.

Yup, got it - thanks!

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 5/7] platform/x86: fujitsu-laptop: do not update ACPI device power status

[Darren Hart]

On Fri, Jun 23, 2017 at 09:46:59AM +0930, Jonathan Woithe wrote:
> Thanks.  In case it was missed, I supplied my reviewed-by message and
> sign-off in an earlier post.

Yup, got it - thanks!

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH/RFC 9/9] perf record: Add --module-dir option

[Namhyung Kim]

Currently perf only searches module binaries on the canonical
directory (/lib/modules/`uname -r`).  But sometimes user needs to load
local modules.  These cannot be copied to the build-id cache since long
name (i.e. real path) of DSOs was not set.

This patch fixes the problem by adding a new --module-dir option so that
perf can record modules in the directory.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-record.txt |  3 +++
 tools/perf/builtin-record.c  |  2 ++
 tools/perf/util/machine.c| 15 ++-
 tools/perf/util/symbol.h |  3 ++-
 4 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index eb2f5fb90534..9030ace9010f 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -480,6 +480,9 @@ Implies --tail-synthesize.
 --use-kcore::
 Use /proc/kcore for symbols and object code reading
 
+--module-dir=PATH::
+Directory name where extra modules are located.
+
 SEE ALSO
 
 linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index a6a6cb56fdf5..8a67fafc0d5b 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1671,6 +1671,8 @@ static struct option __record_options[] = {
"Parse options then exit"),
OPT_BOOLEAN(0, "use-kcore", _conf.use_kcore,
"Use /proc/kcore for object code"),
+   OPT_STRING(0, "module-dir", _conf.extra_module_path, "path",
+  "directory name where extra modules are located"),
OPT_END()
 };
 
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 799efe920f0c..9a18365c443a 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1108,6 +1108,7 @@ static int machine__set_modules_path(struct machine 
*machine)
 {
char *version;
char modules_path[PATH_MAX];
+   int ret;
 
version = get_kernel_version(machine->root_dir);
if (!version)
@@ -1117,7 +1118,19 @@ static int machine__set_modules_path(struct machine 
*machine)
 machine->root_dir, version);
free(version);
 
-   return map_groups__set_modules_path_dir(>kmaps, modules_path, 
0);
+   ret = map_groups__set_modules_path_dir(>kmaps, modules_path, 
0);
+   if (ret < 0)
+   return ret;
+
+   if (symbol_conf.extra_module_path) {
+   snprintf(modules_path, sizeof(modules_path), "%s/%s",
+machine->root_dir, symbol_conf.extra_module_path);
+
+   ret = map_groups__set_modules_path_dir(>kmaps,
+  modules_path, 0);
+   }
+
+   return ret;
 }
 int __weak arch__fix_module_text_start(u64 *start __maybe_unused,
const char *name __maybe_unused)
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 88361eeae813..59370ceb87c4 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -124,7 +124,8 @@ struct symbol_conf {
const char  *vmlinux_name,
*kallsyms_name,
*source_prefix,
-   *field_sep;
+   *field_sep,
+   *extra_module_path;
const char  *default_guest_vmlinux_name,
*default_guest_kallsyms,
*default_guest_modules;
-- 
2.13.1

[PATCH/RFC 9/9] perf record: Add --module-dir option

[Namhyung Kim]

Currently perf only searches module binaries on the canonical
directory (/lib/modules/`uname -r`).  But sometimes user needs to load
local modules.  These cannot be copied to the build-id cache since long
name (i.e. real path) of DSOs was not set.

This patch fixes the problem by adding a new --module-dir option so that
perf can record modules in the directory.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-record.txt |  3 +++
 tools/perf/builtin-record.c  |  2 ++
 tools/perf/util/machine.c| 15 ++-
 tools/perf/util/symbol.h |  3 ++-
 4 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index eb2f5fb90534..9030ace9010f 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -480,6 +480,9 @@ Implies --tail-synthesize.
 --use-kcore::
 Use /proc/kcore for symbols and object code reading
 
+--module-dir=PATH::
+Directory name where extra modules are located.
+
 SEE ALSO
 
 linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index a6a6cb56fdf5..8a67fafc0d5b 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1671,6 +1671,8 @@ static struct option __record_options[] = {
"Parse options then exit"),
OPT_BOOLEAN(0, "use-kcore", _conf.use_kcore,
"Use /proc/kcore for object code"),
+   OPT_STRING(0, "module-dir", _conf.extra_module_path, "path",
+  "directory name where extra modules are located"),
OPT_END()
 };
 
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index 799efe920f0c..9a18365c443a 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1108,6 +1108,7 @@ static int machine__set_modules_path(struct machine 
*machine)
 {
char *version;
char modules_path[PATH_MAX];
+   int ret;
 
version = get_kernel_version(machine->root_dir);
if (!version)
@@ -1117,7 +1118,19 @@ static int machine__set_modules_path(struct machine 
*machine)
 machine->root_dir, version);
free(version);
 
-   return map_groups__set_modules_path_dir(>kmaps, modules_path, 
0);
+   ret = map_groups__set_modules_path_dir(>kmaps, modules_path, 
0);
+   if (ret < 0)
+   return ret;
+
+   if (symbol_conf.extra_module_path) {
+   snprintf(modules_path, sizeof(modules_path), "%s/%s",
+machine->root_dir, symbol_conf.extra_module_path);
+
+   ret = map_groups__set_modules_path_dir(>kmaps,
+  modules_path, 0);
+   }
+
+   return ret;
 }
 int __weak arch__fix_module_text_start(u64 *start __maybe_unused,
const char *name __maybe_unused)
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 88361eeae813..59370ceb87c4 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -124,7 +124,8 @@ struct symbol_conf {
const char  *vmlinux_name,
*kallsyms_name,
*source_prefix,
-   *field_sep;
+   *field_sep,
+   *extra_module_path;
const char  *default_guest_vmlinux_name,
*default_guest_kallsyms,
*default_guest_modules;
-- 
2.13.1

[PATCH/RFC 4/9] perf symbols: Load kernel module symbols ASAP

[Namhyung Kim]

When loading kernel symbols from /proc/kallsyms, it might have different
addresses for modules.  We should honor the mmap event recorded in a
perf.data so load the module symbols when it sees the event so that it
cannot be overridden by symbols in /proc/kallsyms later.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/machine.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index d838f893e639..799efe920f0c 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -656,6 +656,9 @@ struct map *machine__findnew_module_map(struct machine 
*machine, u64 start,
 
map_groups__insert(>kmaps, map);
 
+   if (dso->has_build_id)
+   map__load(map);
+
/* Put the map here because map_groups__insert alread got it */
map__put(map);
 out:
-- 
2.13.1

[PATCHSET/RFC 0/9] perf tools: Support out-of-tree modules

[Namhyung Kim]

Hello,

Currently perf loads modules only in the canonical directory
(/lib/modules/`uname -r`/).  But in some situation users want to use
local or out-of-tree modules which are not placed in the directory.

One example is developing kernel in a qemu environment.  In this case,
guest doesn't see vmlinux or modules but one can load a module in some
directory which was copied separately.  During the development, the
module can be unloaded, fixed and reloaded more than once.

I notice that perf uses symbols in /proc/kallsyms (and /proc/kcore)
and it sometimes shows different result with a same data file.  This
was due to a same module being loaded at a different address or a
reworked module being loaded at a same address.

I think it needs to use build-id cache if possible.  To do that we
need to add an option to search modules and to save them in the
build-id cache automatically.

The code is available on 'perf/kmod-dir-v1' branch at

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (9):
  perf symbols: Use absolute address to fixup map address
  perf tools: Remove duplicate code
  perf symbols: Discard symbols in kallsyms for loaded modules
  perf symbols: Load kernel module symbols ASAP
  perf symbols: Fixup the end address of kernel map properly
  perf symbols: Use already loaded module dso when loading kcore
  perf tools: Add symbol_conf.use_kcore
  perf record: Not use kcore by default
  perf record: Add --module-dir option

 tools/perf/Documentation/perf-record.txt |  6 
 tools/perf/builtin-record.c  |  7 
 tools/perf/perf-with-kcore.sh|  1 +
 tools/perf/util/machine.c| 33 -
 tools/perf/util/map.c|  4 +--
 tools/perf/util/symbol.c | 61 +---
 tools/perf/util/symbol.h |  6 ++--
 7 files changed, 69 insertions(+), 49 deletions(-)

-- 
2.13.1

[PATCH/RFC 4/9] perf symbols: Load kernel module symbols ASAP

[Namhyung Kim]

When loading kernel symbols from /proc/kallsyms, it might have different
addresses for modules.  We should honor the mmap event recorded in a
perf.data so load the module symbols when it sees the event so that it
cannot be overridden by symbols in /proc/kallsyms later.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/machine.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index d838f893e639..799efe920f0c 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -656,6 +656,9 @@ struct map *machine__findnew_module_map(struct machine 
*machine, u64 start,
 
map_groups__insert(>kmaps, map);
 
+   if (dso->has_build_id)
+   map__load(map);
+
/* Put the map here because map_groups__insert alread got it */
map__put(map);
 out:
-- 
2.13.1

[PATCHSET/RFC 0/9] perf tools: Support out-of-tree modules

[Namhyung Kim]

Hello,

Currently perf loads modules only in the canonical directory
(/lib/modules/`uname -r`/).  But in some situation users want to use
local or out-of-tree modules which are not placed in the directory.

One example is developing kernel in a qemu environment.  In this case,
guest doesn't see vmlinux or modules but one can load a module in some
directory which was copied separately.  During the development, the
module can be unloaded, fixed and reloaded more than once.

I notice that perf uses symbols in /proc/kallsyms (and /proc/kcore)
and it sometimes shows different result with a same data file.  This
was due to a same module being loaded at a different address or a
reworked module being loaded at a same address.

I think it needs to use build-id cache if possible.  To do that we
need to add an option to search modules and to save them in the
build-id cache automatically.

The code is available on 'perf/kmod-dir-v1' branch at

  git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git

Thanks,
Namhyung


Namhyung Kim (9):
  perf symbols: Use absolute address to fixup map address
  perf tools: Remove duplicate code
  perf symbols: Discard symbols in kallsyms for loaded modules
  perf symbols: Load kernel module symbols ASAP
  perf symbols: Fixup the end address of kernel map properly
  perf symbols: Use already loaded module dso when loading kcore
  perf tools: Add symbol_conf.use_kcore
  perf record: Not use kcore by default
  perf record: Add --module-dir option

 tools/perf/Documentation/perf-record.txt |  6 
 tools/perf/builtin-record.c  |  7 
 tools/perf/perf-with-kcore.sh|  1 +
 tools/perf/util/machine.c| 33 -
 tools/perf/util/map.c|  4 +--
 tools/perf/util/symbol.c | 61 +---
 tools/perf/util/symbol.h |  6 ++--
 7 files changed, 69 insertions(+), 49 deletions(-)

-- 
2.13.1

[PATCH/RFC 6/9] perf symbols: Use already loaded module dso when loading kcore

[Namhyung Kim]

Even every module has loaded onto same addresses, some modules can be
changed and reloaded.  In that case it needs to access to the old module
in the build-id cache.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index ce79a51f25bf..fe46eb782297 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1155,6 +1155,7 @@ static int dso__load_kcore(struct dso *dso, struct map 
*map,
int err, fd;
char kcore_filename[PATH_MAX];
struct symbol *sym;
+   struct map_groups old_mg;
 
if (!kmaps)
return -EINVAL;
@@ -1196,15 +1197,8 @@ static int dso__load_kcore(struct dso *dso, struct map 
*map,
goto out_err;
}
 
-   /* Remove old maps */
-   old_map = map_groups__first(kmaps, map->type);
-   while (old_map) {
-   struct map *next = map_groups__next(old_map);
-
-   if (old_map != map)
-   map_groups__remove(kmaps, old_map);
-   old_map = next;
-   }
+   old_mg = *kmaps;
+   kmaps->maps[map->type].entries = RB_ROOT;
 
/* Find the kernel map using the first symbol */
sym = dso__first_symbol(dso, map->type);
@@ -1223,24 +1217,31 @@ static int dso__load_kcore(struct dso *dso, struct map 
*map,
while (!list_empty()) {
new_map = list_entry(md.maps.next, struct map, node);
list_del_init(_map->node);
-   if (new_map == replacement_map) {
-   map->start  = new_map->start;
-   map->end= new_map->end;
-   map->pgoff  = new_map->pgoff;
-   map->map_ip = new_map->map_ip;
-   map->unmap_ip   = new_map->unmap_ip;
-   /* Ensure maps are correctly ordered */
-   map__get(map);
-   map_groups__remove(kmaps, map);
-   map_groups__insert(kmaps, map);
-   map__put(map);
-   } else {
-   map_groups__insert(kmaps, new_map);
+
+   map_groups__insert(kmaps, new_map);
+
+   if (new_map != replacement_map) {
+   old_map = map_groups__find(_mg, new_map->type, 
new_map->start);
+   if (old_map && dso__loaded(old_map->dso, 
old_map->type)) {
+   new_map->pgoff = old_map->pgoff;
+
+   dso__put(new_map->dso);
+   new_map->dso = dso__get(old_map->dso);
+   }
}
 
map__put(new_map);
}
 
+   /* Remove old maps */
+   old_map = map_groups__first(_mg, map->type);
+   while (old_map) {
+   struct map *next = map_groups__next(old_map);
+
+   map_groups__remove(_mg, old_map);
+   old_map = next;
+   }
+
/*
 * Set the data type and long name so that kcore can be read via
 * dso__data_read_addr().
-- 
2.13.1

[PATCH/RFC 7/9] perf tools: Add symbol_conf.use_kcore

[Namhyung Kim]

The use_kcore field is to control usage of /proc/kcore when loading
symbols.  This patch only introduces the new field and don't change any
behavior by itself.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 3 ++-
 tools/perf/util/symbol.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index fe46eb782297..3f789f33c2ef 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -36,6 +36,7 @@ char **vmlinux_path;
 
 struct symbol_conf symbol_conf = {
.use_modules= true,
+   .use_kcore  = true,
.try_vmlinux_path   = true,
.annotate_src   = true,
.demangle   = true,
@@ -1324,7 +1325,7 @@ int __dso__load_kallsyms(struct dso *dso, const char 
*filename,
 int dso__load_kallsyms(struct dso *dso, const char *filename,
   struct map *map)
 {
-   return __dso__load_kallsyms(dso, filename, map, false);
+   return __dso__load_kallsyms(dso, filename, map, !symbol_conf.use_kcore);
 }
 
 static int dso__load_perf_map(struct dso *dso, struct map *map)
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 41ebba9a2eb2..88361eeae813 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -119,7 +119,8 @@ struct symbol_conf {
hide_unresolved,
raw_trace,
report_hierarchy,
-   inline_name;
+   inline_name,
+   use_kcore;
const char  *vmlinux_name,
*kallsyms_name,
*source_prefix,
-- 
2.13.1

[PATCH/RFC 7/9] perf tools: Add symbol_conf.use_kcore

[Namhyung Kim]

The use_kcore field is to control usage of /proc/kcore when loading
symbols.  This patch only introduces the new field and don't change any
behavior by itself.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 3 ++-
 tools/perf/util/symbol.h | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index fe46eb782297..3f789f33c2ef 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -36,6 +36,7 @@ char **vmlinux_path;
 
 struct symbol_conf symbol_conf = {
.use_modules= true,
+   .use_kcore  = true,
.try_vmlinux_path   = true,
.annotate_src   = true,
.demangle   = true,
@@ -1324,7 +1325,7 @@ int __dso__load_kallsyms(struct dso *dso, const char 
*filename,
 int dso__load_kallsyms(struct dso *dso, const char *filename,
   struct map *map)
 {
-   return __dso__load_kallsyms(dso, filename, map, false);
+   return __dso__load_kallsyms(dso, filename, map, !symbol_conf.use_kcore);
 }
 
 static int dso__load_perf_map(struct dso *dso, struct map *map)
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index 41ebba9a2eb2..88361eeae813 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -119,7 +119,8 @@ struct symbol_conf {
hide_unresolved,
raw_trace,
report_hierarchy,
-   inline_name;
+   inline_name,
+   use_kcore;
const char  *vmlinux_name,
*kallsyms_name,
*source_prefix,
-- 
2.13.1

[PATCH/RFC 6/9] perf symbols: Use already loaded module dso when loading kcore

[Namhyung Kim]

Even every module has loaded onto same addresses, some modules can be
changed and reloaded.  In that case it needs to access to the old module
in the build-id cache.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index ce79a51f25bf..fe46eb782297 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1155,6 +1155,7 @@ static int dso__load_kcore(struct dso *dso, struct map 
*map,
int err, fd;
char kcore_filename[PATH_MAX];
struct symbol *sym;
+   struct map_groups old_mg;
 
if (!kmaps)
return -EINVAL;
@@ -1196,15 +1197,8 @@ static int dso__load_kcore(struct dso *dso, struct map 
*map,
goto out_err;
}
 
-   /* Remove old maps */
-   old_map = map_groups__first(kmaps, map->type);
-   while (old_map) {
-   struct map *next = map_groups__next(old_map);
-
-   if (old_map != map)
-   map_groups__remove(kmaps, old_map);
-   old_map = next;
-   }
+   old_mg = *kmaps;
+   kmaps->maps[map->type].entries = RB_ROOT;
 
/* Find the kernel map using the first symbol */
sym = dso__first_symbol(dso, map->type);
@@ -1223,24 +1217,31 @@ static int dso__load_kcore(struct dso *dso, struct map 
*map,
while (!list_empty()) {
new_map = list_entry(md.maps.next, struct map, node);
list_del_init(_map->node);
-   if (new_map == replacement_map) {
-   map->start  = new_map->start;
-   map->end= new_map->end;
-   map->pgoff  = new_map->pgoff;
-   map->map_ip = new_map->map_ip;
-   map->unmap_ip   = new_map->unmap_ip;
-   /* Ensure maps are correctly ordered */
-   map__get(map);
-   map_groups__remove(kmaps, map);
-   map_groups__insert(kmaps, map);
-   map__put(map);
-   } else {
-   map_groups__insert(kmaps, new_map);
+
+   map_groups__insert(kmaps, new_map);
+
+   if (new_map != replacement_map) {
+   old_map = map_groups__find(_mg, new_map->type, 
new_map->start);
+   if (old_map && dso__loaded(old_map->dso, 
old_map->type)) {
+   new_map->pgoff = old_map->pgoff;
+
+   dso__put(new_map->dso);
+   new_map->dso = dso__get(old_map->dso);
+   }
}
 
map__put(new_map);
}
 
+   /* Remove old maps */
+   old_map = map_groups__first(_mg, map->type);
+   while (old_map) {
+   struct map *next = map_groups__next(old_map);
+
+   map_groups__remove(_mg, old_map);
+   old_map = next;
+   }
+
/*
 * Set the data type and long name so that kcore can be read via
 * dso__data_read_addr().
-- 
2.13.1

[GIT PULL] extcon next for v4.13

[Chanwoo Choi]

Dear Greg,

This is extcon-next pull request for v4.13. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:

  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.13

for you to fetch changes up to 1f4be24786b8521945b00e1810576911994ba504:

  extcon: int3496: Switch to devm_acpi_dev_add_driver_gpios() (2017-06-12 
10:00:24 +0900)


Update extcon for 4.13

Detailed description for this pull request:
- Use devm_kcalloc() and fix typo for extcon core/extcon-arizona.c.
- Add dependency ARCH_QCOM for extcon-qcom-spmi-misc.c
- Use resource-managed devm_* function for gpios on extcon-int3496.c


Andy Shevchenko (1):
  extcon: int3496: Switch to devm_acpi_dev_add_driver_gpios()

Markus Elfring (3):
  extcon: Use devm_kcalloc() in extcon_dev_register()
  extcon: Fix a typo in three comment lines
  extcon: arizona: Use devm_kcalloc() in arizona_extcon_get_micd_configs()

Peter Robinson (1):
  extcon: qcom-spmi-misc: add dependency on ARCH_QCOM

 drivers/extcon/Kconfig|  1 +
 drivers/extcon/extcon-arizona.c   |  4 +---
 drivers/extcon/extcon-intel-int3496.c |  5 +
 drivers/extcon/extcon.c   | 11 +--
 4 files changed, 8 insertions(+), 13 deletions(-)

[GIT PULL] extcon next for v4.13

[Chanwoo Choi]

Dear Greg,

This is extcon-next pull request for v4.13. I add detailed description of
this pull request on below. Please pull extcon with following updates.

Best Regards,
Chanwoo Choi

The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:

  Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
tags/extcon-next-for-4.13

for you to fetch changes up to 1f4be24786b8521945b00e1810576911994ba504:

  extcon: int3496: Switch to devm_acpi_dev_add_driver_gpios() (2017-06-12 
10:00:24 +0900)


Update extcon for 4.13

Detailed description for this pull request:
- Use devm_kcalloc() and fix typo for extcon core/extcon-arizona.c.
- Add dependency ARCH_QCOM for extcon-qcom-spmi-misc.c
- Use resource-managed devm_* function for gpios on extcon-int3496.c


Andy Shevchenko (1):
  extcon: int3496: Switch to devm_acpi_dev_add_driver_gpios()

Markus Elfring (3):
  extcon: Use devm_kcalloc() in extcon_dev_register()
  extcon: Fix a typo in three comment lines
  extcon: arizona: Use devm_kcalloc() in arizona_extcon_get_micd_configs()

Peter Robinson (1):
  extcon: qcom-spmi-misc: add dependency on ARCH_QCOM

 drivers/extcon/Kconfig|  1 +
 drivers/extcon/extcon-arizona.c   |  4 +---
 drivers/extcon/extcon-intel-int3496.c |  5 +
 drivers/extcon/extcon.c   | 11 +--
 4 files changed, 8 insertions(+), 13 deletions(-)

[PATCH/RFC 8/9] perf record: Not use kcore by default

[Namhyung Kim]

Change perf record not to use /proc/kcore by default.  This is for
kernel developers who use qemu or kvmtools to test their kernels.  On
those environment, kernel image was loaded directly by qemu and the
vmlinux might not be available on the guest.

At the last stage of perf record, it finds hit DSOs to mark them to
record the build-ids.  During this process, it tries to load kernel maps
and falls back to use kallsyms with kcore.  But dso__load_kcore()
removes old mappings so all module info would disappear.

I'm not sure this is intended but it'd be good if it could keep the info
and use it for build-id cache.  Add --use-kcore option to request it
explicitly (like in perf-with-kcore).

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-record.txt | 3 +++
 tools/perf/builtin-record.c  | 5 +
 tools/perf/perf-with-kcore.sh| 1 +
 3 files changed, 9 insertions(+)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index b0e9e921d534..eb2f5fb90534 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -477,6 +477,9 @@ config terms. For example: 'cycles/overwrite/' and 
'instructions/no-overwrite/'.
 
 Implies --tail-synthesize.
 
+--use-kcore::
+Use /proc/kcore for symbols and object code reading
+
 SEE ALSO
 
 linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index ee7d0a82ccd0..a6a6cb56fdf5 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1669,6 +1669,8 @@ static struct option __record_options[] = {
  "signal"),
OPT_BOOLEAN(0, "dry-run", _run,
"Parse options then exit"),
+   OPT_BOOLEAN(0, "use-kcore", _conf.use_kcore,
+   "Use /proc/kcore for object code"),
OPT_END()
 };
 
@@ -1705,6 +1707,9 @@ int cmd_record(int argc, const char **argv)
if (rec->evlist == NULL)
return -ENOMEM;
 
+   /* default to not use kcore, user can change it by --use-kcore option */
+   symbol_conf.use_kcore = false;
+
err = perf_config(perf_record_config, rec);
if (err)
return err;
diff --git a/tools/perf/perf-with-kcore.sh b/tools/perf/perf-with-kcore.sh
index 7e47a7cbc195..4efde3e577dd 100644
--- a/tools/perf/perf-with-kcore.sh
+++ b/tools/perf/perf-with-kcore.sh
@@ -233,6 +233,7 @@ fi
 
 case "$PERF_SUB_COMMAND" in
 "record")
+   PERF_OPTIONS+=("--use-kcore")
while [ "$1" != "--" ] ; do
PERF_OPTIONS+=("$1")
shift || break
-- 
2.13.1

[PATCH/RFC 8/9] perf record: Not use kcore by default

[Namhyung Kim]

Change perf record not to use /proc/kcore by default.  This is for
kernel developers who use qemu or kvmtools to test their kernels.  On
those environment, kernel image was loaded directly by qemu and the
vmlinux might not be available on the guest.

At the last stage of perf record, it finds hit DSOs to mark them to
record the build-ids.  During this process, it tries to load kernel maps
and falls back to use kallsyms with kcore.  But dso__load_kcore()
removes old mappings so all module info would disappear.

I'm not sure this is intended but it'd be good if it could keep the info
and use it for build-id cache.  Add --use-kcore option to request it
explicitly (like in perf-with-kcore).

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/Documentation/perf-record.txt | 3 +++
 tools/perf/builtin-record.c  | 5 +
 tools/perf/perf-with-kcore.sh| 1 +
 3 files changed, 9 insertions(+)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index b0e9e921d534..eb2f5fb90534 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -477,6 +477,9 @@ config terms. For example: 'cycles/overwrite/' and 
'instructions/no-overwrite/'.
 
 Implies --tail-synthesize.
 
+--use-kcore::
+Use /proc/kcore for symbols and object code reading
+
 SEE ALSO
 
 linkperf:perf-stat[1], linkperf:perf-list[1]
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index ee7d0a82ccd0..a6a6cb56fdf5 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -1669,6 +1669,8 @@ static struct option __record_options[] = {
  "signal"),
OPT_BOOLEAN(0, "dry-run", _run,
"Parse options then exit"),
+   OPT_BOOLEAN(0, "use-kcore", _conf.use_kcore,
+   "Use /proc/kcore for object code"),
OPT_END()
 };
 
@@ -1705,6 +1707,9 @@ int cmd_record(int argc, const char **argv)
if (rec->evlist == NULL)
return -ENOMEM;
 
+   /* default to not use kcore, user can change it by --use-kcore option */
+   symbol_conf.use_kcore = false;
+
err = perf_config(perf_record_config, rec);
if (err)
return err;
diff --git a/tools/perf/perf-with-kcore.sh b/tools/perf/perf-with-kcore.sh
index 7e47a7cbc195..4efde3e577dd 100644
--- a/tools/perf/perf-with-kcore.sh
+++ b/tools/perf/perf-with-kcore.sh
@@ -233,6 +233,7 @@ fi
 
 case "$PERF_SUB_COMMAND" in
 "record")
+   PERF_OPTIONS+=("--use-kcore")
while [ "$1" != "--" ] ; do
PERF_OPTIONS+=("$1")
shift || break
-- 
2.13.1

[PATCH/RFC 2/9] perf tools: Remove duplicate code

[Namhyung Kim]

The map_groups__set_module_path() is called after
machine__create_module() which sets build-id and symtab type already.
Also remove is_kmod_dso() as there's no user anymore.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/machine.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index d7f31cb0a4cb..d838f893e639 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1024,12 +1024,6 @@ static char *get_kernel_version(const char *root_dir)
return strdup(name);
 }
 
-static bool is_kmod_dso(struct dso *dso)
-{
-   return dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE ||
-  dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE;
-}
-
 static int map_groups__set_module_path(struct map_groups *mg, const char *path,
   struct kmod_path *m)
 {
@@ -1045,15 +1039,6 @@ static int map_groups__set_module_path(struct map_groups 
*mg, const char *path,
return -ENOMEM;
 
dso__set_long_name(map->dso, long_name, true);
-   dso__kernel_module_get_build_id(map->dso, "");
-
-   /*
-* Full name could reveal us kmod compression, so
-* we need to update the symtab_type if needed.
-*/
-   if (m->comp && is_kmod_dso(map->dso))
-   map->dso->symtab_type++;
-
return 0;
 }
 
-- 
2.13.1

[PATCH/RFC 3/9] perf symbols: Discard symbols in kallsyms for loaded modules

[Namhyung Kim]

If a module is already loaded, it should have symbols and no need to
load new symbols from kallsyms.  Actually kallsyms can have different
addresses if the module was reloaded.

Current code just discards the first symbols only, but it should do the
same for all symbols in the module.  Note that the kernel doesn't set
the dso->loaded bit so simply checking it would do the job IMHO.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e7a98dbd2aed..74078ba595b3 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -787,11 +787,12 @@ static int dso__split_kallsyms(struct dso *dso, struct 
map *map, u64 delta)
curr_map = map;
goto discard_symbol;
}
-
-   if (curr_map->dso->loaded &&
-   !machine__is_default_guest(machine))
-   goto discard_symbol;
}
+
+   if (curr_map->dso->loaded &&
+   !machine__is_default_guest(machine))
+   goto discard_symbol;
+
/*
 * So that we look just like we get from .ko files,
 * i.e. not prelinked, relative to map->start.
-- 
2.13.1

Re: next-20170620 BUG in do_page_fault / do_huge_pmd_wp_page

[Naresh Kamboju]

Hi Valdis,

On 23 June 2017 at 08:56,  <valdis.kletni...@vt.edu> wrote:
> Saw this at boot of next-20170620.  Not sure how I managed to hit 4 BUG in a 
> row...
>
> Looked in 'git log -- mm/' but not seeing anything blatantly obvious.
>
> This ringing any bells?  I'm not in a position to recreate or bisect this 
> until
> the weekend.
>
> [  315.409076] BUG: Bad rss-counter state mm:8a223deb4640 idx:0 val:-512
> [  315.412889] BUG: Bad rss-counter state mm:8a223deb4640 idx:1 val:512
> [  315.416694] BUG: non-zero nr_ptes on freeing mm: 1
> [  315.436098] BUG: Bad page state in process gdm  pfn:3e8400
> [  315.439802] page:e8af0fa1 count:-1 mapcount:0 mapping:  
> (null) index:0x1
> [  315.443264] flags: 0x4000()
> [  315.446715] raw: 4000  0001 
> 
> [  315.450181] raw: dead0100 dead0200  
> 
> [  315.453628] page dumped because: nonzero _count
> [  315.457023] Modules linked in: ts_bm nf_log_ipv4 xt_string nf_log_ipv6 
> nf_log_common xt_LOG sunrpc vfat fat brcmsmac cordic brcmutil dell
> _wmi x86_pkg_temp_thermal crct10dif_pclmul dell_laptop crc32_pclmul 
> crc32c_intel dell_smbios ghash_clmulni_intel dell_smm_hwmon cryptd bcma
> mei_wdt dell_smo8800 dell_rbtn sch_fq tcp_bbr
> [  315.457116] CPU: 3 PID: 6684 Comm: gdm Not tainted 
> 4.12.0-rc6-next-20170620 #506
> [  315.457119] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A19 
> 01/04/2017
> [  315.457122] Call Trace:
> [  315.457131]  dump_stack+0x83/0xd1
> [  315.457141]  bad_page+0x10c/0x1b0
> [  315.457151]  check_new_page_bad+0x12e/0x180
> [  315.457159]  get_page_from_freelist+0x756/0x1840
> [  315.457170]  ? native_sched_clock+0x80/0xf0
> [  315.457184]  ? find_held_lock+0x38/0x160
> [  315.457194]  __alloc_pages_nodemask+0x145/0x5a0
> [  315.457211]  do_huge_pmd_wp_page+0x58d/0x1380
> [  315.457217]  ? cyc2ns_read_begin+0x82/0xb0
> [  315.457224]  ? cyc2ns_read_end+0x22/0x40
> [  315.457229]  ? native_sched_clock+0x80/0xf0
> [  315.457236]  ? native_sched_clock+0x80/0xf0
> [  315.457247]  __handle_mm_fault+0x831/0x14e0
> [  315.457253]  ? sched_clock_cpu+0x1b/0x1e0
> [  315.457273]  handle_mm_fault+0x23c/0x6f0
> [  315.457283]  __do_page_fault+0x460/0x950
> [  315.457298]  do_page_fault+0xc/0x10
> [  315.457305]  page_fault+0x22/0x30
> [  315.457310] RIP: 0033:0x7fe15390e5c1
> [  315.457314] RSP: 002b:7ffd2acdca30 EFLAGS: 00010202
> [  315.457320] RAX:  RBX: 7ffd2acdca50 RCX: 
> 
> [  315.457324] RDX: 00801000 RSI: 7fe14bfff9c0 RDI: 
> 7fe14b7fec10
> [  315.457328] RBP: 7ffd2acdcac0 R08: 7fe14b7fed10 R09: 
> 7fe153b22030
> [  315.457331] R10: 7fe155346900 R11: 0202 R12: 
> 
> [  315.457335] R13:  R14: 0001 R15: 
> 7fe155413000
> [  315.457354] Disabling lock debugging due to kernel taint
>
>
>


This bug occurred on HiKey (arm64) while booting.
Here is the boot log,

Linux version:
---
Linux version 4.12.0-rc6-next-20170622 (buildslave@x86-64-08) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Thu
Jun 22 15:54:05 UTC 2017

Error log:
-
[8.759348] BUG: Bad page state in process dockerd  pfn:6f800
[8.765806] page:7e0001be count:-1 mapcount:0 mapping:
(null) index:0x1
[8.774115] flags: 0xfffc000()
[8.777970] raw: 0fffc000  0001

[8.785915] raw: dead0100 dead0200 

[8.793857] page dumped because: nonzero _count
[8.798506] Modules linked in: asix usbnet adv7511 dw_drm_dsi
kirin_drm drm_kms_helper drm fuse
[8.812369] CPU: 6 PID: 2419 Comm: dockerd Not tainted
4.12.0-rc6-next-20170622 #1
[8.825053] Hardware name: HiKey Development Board (DT)
[8.835330] Call trace:
[8.842735] [] dump_backtrace+0x0/0x230
[8.853141] [] show_stack+0x14/0x20
[8.863121] [] dump_stack+0xb8/0xf0
[8.873018] [] bad_page+0xe4/0x148
[8.882766] [] check_new_page_bad+0x64/0xa0
[8.893262] [] get_page_from_freelist+0xab4/0xca0
[8.904251] [] __alloc_pages_nodemask+0x10c/0x1328
[8.915273] [] alloc_pages_current+0x80/0xe8
[8.925737] [] __page_cache_alloc+0xf8/0x128
[8.936138] [] __do_page_cache_readahead+0x128/0x340
[8.947212] [] filemap_fault+0x328/0x6c8
[8.957166] [] ext4_filemap_fault+0x30/0x50
[8.967394] [] __do_fault+0x20/0x88
[8.976907] [] __handle_mm_fault+0x97c/0x10d0
[8.987311] [] handle_mm_fault+0x1a8/0x338
[8.997385] [] do_page_fault+0x2c0/0x3d0
[9.007222] [] do_mem_abort+0x40/0x98
[9.016720] Exception stack(0x800073b63e20

Re: [PATCH v2 0/6] mediatek: pwm driver add MT2712/MT7622 support

[John Crispin]

On 23/06/17 07:08, Zhi Mao wrote:

change in v2:
1. add error check for enable colock control flow
2. use "goto err_clk(main/top)" coding style, for preparing clk error case
3. remove comments inline /*===*/
4. move "PWM_CLK_DIV_MAX" modification to its own patch
5. move pwm source clock selection to its own patch


Hi,
thanks for updating the series, i will give it a quick test on MT7623 today
John


Zhi Mao (6):
   pwm: kconfig: modify mediatek information
   pwm: mediatek: fix pwm source clock selection
   pwm: mediatek: fix clock control issue
   pwm: bindings: add MT2712/MT7622 information
   pwm: mediatek: add PWM_CLK_DIV_MAX
   pwm: mediatek: add MT2712/MT7622 support

  .../devicetree/bindings/pwm/pwm-mediatek.txt   |6 +-
  drivers/pwm/Kconfig|2 +-
  drivers/pwm/pwm-mediatek.c |  132 ++--
  3 files changed, 103 insertions(+), 37 deletions(-)


___
Linux-mediatek mailing list
linux-media...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH/RFC 2/9] perf tools: Remove duplicate code

[Namhyung Kim]

The map_groups__set_module_path() is called after
machine__create_module() which sets build-id and symtab type already.
Also remove is_kmod_dso() as there's no user anymore.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/machine.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index d7f31cb0a4cb..d838f893e639 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1024,12 +1024,6 @@ static char *get_kernel_version(const char *root_dir)
return strdup(name);
 }
 
-static bool is_kmod_dso(struct dso *dso)
-{
-   return dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE ||
-  dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE;
-}
-
 static int map_groups__set_module_path(struct map_groups *mg, const char *path,
   struct kmod_path *m)
 {
@@ -1045,15 +1039,6 @@ static int map_groups__set_module_path(struct map_groups 
*mg, const char *path,
return -ENOMEM;
 
dso__set_long_name(map->dso, long_name, true);
-   dso__kernel_module_get_build_id(map->dso, "");
-
-   /*
-* Full name could reveal us kmod compression, so
-* we need to update the symtab_type if needed.
-*/
-   if (m->comp && is_kmod_dso(map->dso))
-   map->dso->symtab_type++;
-
return 0;
 }
 
-- 
2.13.1

[PATCH/RFC 3/9] perf symbols: Discard symbols in kallsyms for loaded modules

[Namhyung Kim]

If a module is already loaded, it should have symbols and no need to
load new symbols from kallsyms.  Actually kallsyms can have different
addresses if the module was reloaded.

Current code just discards the first symbols only, but it should do the
same for all symbols in the module.  Note that the kernel doesn't set
the dso->loaded bit so simply checking it would do the job IMHO.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e7a98dbd2aed..74078ba595b3 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -787,11 +787,12 @@ static int dso__split_kallsyms(struct dso *dso, struct 
map *map, u64 delta)
curr_map = map;
goto discard_symbol;
}
-
-   if (curr_map->dso->loaded &&
-   !machine__is_default_guest(machine))
-   goto discard_symbol;
}
+
+   if (curr_map->dso->loaded &&
+   !machine__is_default_guest(machine))
+   goto discard_symbol;
+
/*
 * So that we look just like we get from .ko files,
 * i.e. not prelinked, relative to map->start.
-- 
2.13.1

Re: next-20170620 BUG in do_page_fault / do_huge_pmd_wp_page

[Naresh Kamboju]

Hi Valdis,

On 23 June 2017 at 08:56,   wrote:
> Saw this at boot of next-20170620.  Not sure how I managed to hit 4 BUG in a 
> row...
>
> Looked in 'git log -- mm/' but not seeing anything blatantly obvious.
>
> This ringing any bells?  I'm not in a position to recreate or bisect this 
> until
> the weekend.
>
> [  315.409076] BUG: Bad rss-counter state mm:8a223deb4640 idx:0 val:-512
> [  315.412889] BUG: Bad rss-counter state mm:8a223deb4640 idx:1 val:512
> [  315.416694] BUG: non-zero nr_ptes on freeing mm: 1
> [  315.436098] BUG: Bad page state in process gdm  pfn:3e8400
> [  315.439802] page:e8af0fa1 count:-1 mapcount:0 mapping:  
> (null) index:0x1
> [  315.443264] flags: 0x4000()
> [  315.446715] raw: 4000  0001 
> 
> [  315.450181] raw: dead0100 dead0200  
> 
> [  315.453628] page dumped because: nonzero _count
> [  315.457023] Modules linked in: ts_bm nf_log_ipv4 xt_string nf_log_ipv6 
> nf_log_common xt_LOG sunrpc vfat fat brcmsmac cordic brcmutil dell
> _wmi x86_pkg_temp_thermal crct10dif_pclmul dell_laptop crc32_pclmul 
> crc32c_intel dell_smbios ghash_clmulni_intel dell_smm_hwmon cryptd bcma
> mei_wdt dell_smo8800 dell_rbtn sch_fq tcp_bbr
> [  315.457116] CPU: 3 PID: 6684 Comm: gdm Not tainted 
> 4.12.0-rc6-next-20170620 #506
> [  315.457119] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A19 
> 01/04/2017
> [  315.457122] Call Trace:
> [  315.457131]  dump_stack+0x83/0xd1
> [  315.457141]  bad_page+0x10c/0x1b0
> [  315.457151]  check_new_page_bad+0x12e/0x180
> [  315.457159]  get_page_from_freelist+0x756/0x1840
> [  315.457170]  ? native_sched_clock+0x80/0xf0
> [  315.457184]  ? find_held_lock+0x38/0x160
> [  315.457194]  __alloc_pages_nodemask+0x145/0x5a0
> [  315.457211]  do_huge_pmd_wp_page+0x58d/0x1380
> [  315.457217]  ? cyc2ns_read_begin+0x82/0xb0
> [  315.457224]  ? cyc2ns_read_end+0x22/0x40
> [  315.457229]  ? native_sched_clock+0x80/0xf0
> [  315.457236]  ? native_sched_clock+0x80/0xf0
> [  315.457247]  __handle_mm_fault+0x831/0x14e0
> [  315.457253]  ? sched_clock_cpu+0x1b/0x1e0
> [  315.457273]  handle_mm_fault+0x23c/0x6f0
> [  315.457283]  __do_page_fault+0x460/0x950
> [  315.457298]  do_page_fault+0xc/0x10
> [  315.457305]  page_fault+0x22/0x30
> [  315.457310] RIP: 0033:0x7fe15390e5c1
> [  315.457314] RSP: 002b:7ffd2acdca30 EFLAGS: 00010202
> [  315.457320] RAX:  RBX: 7ffd2acdca50 RCX: 
> 
> [  315.457324] RDX: 00801000 RSI: 7fe14bfff9c0 RDI: 
> 7fe14b7fec10
> [  315.457328] RBP: 7ffd2acdcac0 R08: 7fe14b7fed10 R09: 
> 7fe153b22030
> [  315.457331] R10: 7fe155346900 R11: 0202 R12: 
> 
> [  315.457335] R13:  R14: 0001 R15: 
> 7fe155413000
> [  315.457354] Disabling lock debugging due to kernel taint
>
>
>


This bug occurred on HiKey (arm64) while booting.
Here is the boot log,

Linux version:
---
Linux version 4.12.0-rc6-next-20170622 (buildslave@x86-64-08) (gcc
version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Thu
Jun 22 15:54:05 UTC 2017

Error log:
-
[8.759348] BUG: Bad page state in process dockerd  pfn:6f800
[8.765806] page:7e0001be count:-1 mapcount:0 mapping:
(null) index:0x1
[8.774115] flags: 0xfffc000()
[8.777970] raw: 0fffc000  0001

[8.785915] raw: dead0100 dead0200 

[8.793857] page dumped because: nonzero _count
[8.798506] Modules linked in: asix usbnet adv7511 dw_drm_dsi
kirin_drm drm_kms_helper drm fuse
[8.812369] CPU: 6 PID: 2419 Comm: dockerd Not tainted
4.12.0-rc6-next-20170622 #1
[8.825053] Hardware name: HiKey Development Board (DT)
[8.835330] Call trace:
[8.842735] [] dump_backtrace+0x0/0x230
[8.853141] [] show_stack+0x14/0x20
[8.863121] [] dump_stack+0xb8/0xf0
[8.873018] [] bad_page+0xe4/0x148
[8.882766] [] check_new_page_bad+0x64/0xa0
[8.893262] [] get_page_from_freelist+0xab4/0xca0
[8.904251] [] __alloc_pages_nodemask+0x10c/0x1328
[8.915273] [] alloc_pages_current+0x80/0xe8
[8.925737] [] __page_cache_alloc+0xf8/0x128
[8.936138] [] __do_page_cache_readahead+0x128/0x340
[8.947212] [] filemap_fault+0x328/0x6c8
[8.957166] [] ext4_filemap_fault+0x30/0x50
[8.967394] [] __do_fault+0x20/0x88
[8.976907] [] __handle_mm_fault+0x97c/0x10d0
[8.987311] [] handle_mm_fault+0x1a8/0x338
[8.997385] [] do_page_fault+0x2c0/0x3d0
[9.007222] [] do_mem_abort+0x40/0x98
[9.016720] Exception stack(0x800073b63e20 to 0x800073b63f50)
[ 

Re: [PATCH v2 0/6] mediatek: pwm driver add MT2712/MT7622 support

[John Crispin]

On 23/06/17 07:08, Zhi Mao wrote:

change in v2:
1. add error check for enable colock control flow
2. use "goto err_clk(main/top)" coding style, for preparing clk error case
3. remove comments inline /*===*/
4. move "PWM_CLK_DIV_MAX" modification to its own patch
5. move pwm source clock selection to its own patch


Hi,
thanks for updating the series, i will give it a quick test on MT7623 today
John


Zhi Mao (6):
   pwm: kconfig: modify mediatek information
   pwm: mediatek: fix pwm source clock selection
   pwm: mediatek: fix clock control issue
   pwm: bindings: add MT2712/MT7622 information
   pwm: mediatek: add PWM_CLK_DIV_MAX
   pwm: mediatek: add MT2712/MT7622 support

  .../devicetree/bindings/pwm/pwm-mediatek.txt   |6 +-
  drivers/pwm/Kconfig|2 +-
  drivers/pwm/pwm-mediatek.c |  132 ++--
  3 files changed, 103 insertions(+), 37 deletions(-)


___
Linux-mediatek mailing list
linux-media...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH/RFC 1/9] perf symbols: Use absolute address to fixup map address

[Namhyung Kim]

A symbol address is relative in a map/dso, to setup modules addresses it
should be converted to absolute address.  Note that it only used for
kernel mappings which uses identity map but theorically it should unmap
the address IMHO.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/map.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 2179b2deb730..4867265b800a 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -265,7 +265,7 @@ void map__fixup_start(struct map *map)
struct rb_node *nd = rb_first(symbols);
if (nd != NULL) {
struct symbol *sym = rb_entry(nd, struct symbol, rb_node);
-   map->start = sym->start;
+   map->start = map->unmap_ip(map, sym->start);
}
 }
 
@@ -275,7 +275,7 @@ void map__fixup_end(struct map *map)
struct rb_node *nd = rb_last(symbols);
if (nd != NULL) {
struct symbol *sym = rb_entry(nd, struct symbol, rb_node);
-   map->end = sym->end;
+   map->end = map->unmap_ip(map, sym->end);
}
 }
 
-- 
2.13.1

[PATCH/RFC 1/9] perf symbols: Use absolute address to fixup map address

[Namhyung Kim]

A symbol address is relative in a map/dso, to setup modules addresses it
should be converted to absolute address.  Note that it only used for
kernel mappings which uses identity map but theorically it should unmap
the address IMHO.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/map.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index 2179b2deb730..4867265b800a 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -265,7 +265,7 @@ void map__fixup_start(struct map *map)
struct rb_node *nd = rb_first(symbols);
if (nd != NULL) {
struct symbol *sym = rb_entry(nd, struct symbol, rb_node);
-   map->start = sym->start;
+   map->start = map->unmap_ip(map, sym->start);
}
 }
 
@@ -275,7 +275,7 @@ void map__fixup_end(struct map *map)
struct rb_node *nd = rb_last(symbols);
if (nd != NULL) {
struct symbol *sym = rb_entry(nd, struct symbol, rb_node);
-   map->end = sym->end;
+   map->end = map->unmap_ip(map, sym->end);
}
 }
 
-- 
2.13.1

[PATCH/RFC 5/9] perf symbols: Fixup the end address of kernel map properly

[Namhyung Kim]

When /proc/kallsyms is used for kernel address, addresses in module can
be changed when the module is reloaded.  So if one did perf record with
some module and then for some reason reload the module.  Then perf
report might see a different address for the module and the output can
show incorrect symbols.

For example, let a module XXX was loaded at 0x8a00, the
/proc/kallsyms might show following:

  ...
  0x81234560 t last_symbol_in_vmlinux
  0x8a00 t first_symbol_in_XXX
  ...

As kallsyms fixs up the symbol and map address by using next address,
the end address of last_symbol and kernel map would be start address of
XXX (0x8a00).  And samples in 0x8a001234 can be
found in a map for XXX module.

But later, XXX was reloaded at 0x8a007000, slightly higher than
before.  Now reading /proc/kallsyms tells that the end address of last
symbol would be 0xfff8a007000 and so kernel map is same.  Now
samples in 0x8a001234 - formerly in the XXX module - would go to
the kernel map and show no symbols.

In this case, perf can know the address of map of XXX from mmap event in
perf.data so it can adjust kernel map address using the address of XXX
map.  To do that, replace map__fixup_end() by __map_groups__fixup_end().
This still have incorrect end address of last symbol in the kernel map
but it's ok since samples in that address wouldn't go to the kernel map
anyway.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 74078ba595b3..ce79a51f25bf 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1832,7 +1832,7 @@ static int dso__load_kernel_sym(struct dso *dso, struct 
map *map)
dso->binary_type = DSO_BINARY_TYPE__KALLSYMS;
dso__set_long_name(dso, DSO__NAME_KALLSYMS, false);
map__fixup_start(map);
-   map__fixup_end(map);
+   __map_groups__fixup_end(map->groups, map->type);
}
 
return err;
@@ -1880,7 +1880,7 @@ static int dso__load_guest_kernel_sym(struct dso *dso, 
struct map *map)
machine__mmap_name(machine, path, sizeof(path));
dso__set_long_name(dso, strdup(path), true);
map__fixup_start(map);
-   map__fixup_end(map);
+   __map_groups__fixup_end(map->groups, map->type);
}
 
return err;
-- 
2.13.1

[PATCH/RFC 5/9] perf symbols: Fixup the end address of kernel map properly

[Namhyung Kim]

When /proc/kallsyms is used for kernel address, addresses in module can
be changed when the module is reloaded.  So if one did perf record with
some module and then for some reason reload the module.  Then perf
report might see a different address for the module and the output can
show incorrect symbols.

For example, let a module XXX was loaded at 0x8a00, the
/proc/kallsyms might show following:

  ...
  0x81234560 t last_symbol_in_vmlinux
  0x8a00 t first_symbol_in_XXX
  ...

As kallsyms fixs up the symbol and map address by using next address,
the end address of last_symbol and kernel map would be start address of
XXX (0x8a00).  And samples in 0x8a001234 can be
found in a map for XXX module.

But later, XXX was reloaded at 0x8a007000, slightly higher than
before.  Now reading /proc/kallsyms tells that the end address of last
symbol would be 0xfff8a007000 and so kernel map is same.  Now
samples in 0x8a001234 - formerly in the XXX module - would go to
the kernel map and show no symbols.

In this case, perf can know the address of map of XXX from mmap event in
perf.data so it can adjust kernel map address using the address of XXX
map.  To do that, replace map__fixup_end() by __map_groups__fixup_end().
This still have incorrect end address of last symbol in the kernel map
but it's ok since samples in that address wouldn't go to the kernel map
anyway.

Cc: Adrian Hunter 
Cc: Wang Nan 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 74078ba595b3..ce79a51f25bf 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1832,7 +1832,7 @@ static int dso__load_kernel_sym(struct dso *dso, struct 
map *map)
dso->binary_type = DSO_BINARY_TYPE__KALLSYMS;
dso__set_long_name(dso, DSO__NAME_KALLSYMS, false);
map__fixup_start(map);
-   map__fixup_end(map);
+   __map_groups__fixup_end(map->groups, map->type);
}
 
return err;
@@ -1880,7 +1880,7 @@ static int dso__load_guest_kernel_sym(struct dso *dso, 
struct map *map)
machine__mmap_name(machine, path, sizeof(path));
dso__set_long_name(dso, strdup(path), true);
map__fixup_start(map);
-   map__fixup_end(map);
+   __map_groups__fixup_end(map->groups, map->type);
}
 
return err;
-- 
2.13.1

Re: enabling COMPILE_TEST support for GCC plugins in v4.11

[Michael Ellerman]

[Old thread just popped up in my inbox]

Kees Cook  writes:
> On Thu, Dec 8, 2016 at 5:52 PM, Paul Gortmaker
>  wrote:
>> On Thu, Dec 8, 2016 at 2:00 PM, Kees Cook  wrote:
>>> Hi,
>>>
>>> I'd like to get the GCC plugins building under
>>> allyesconfig/allmodconfig for -next soon (with the intention of
>>> landing the change in v4.11). Specifically, I intend to revert
>>> a519167e753e ("gcc-plugins: disable under COMPILE_TEST").
>>
>> If I recall correctly, I noted that the plugins broke the kernel.org
>> cross compiler toolchains which led to the above disable.
>
> Do you mean these?
> https://www.kernel.org/pub/tools/crosstool/

I think those are the ones Paul is talking about.

Those were mostly built by Tony, who is know, sadly, an Openstack
developer and for some reason doesn't seem to have time to build
toolchains for kernel hackers :P


As folks may have seen on LWN, there are now pre-built toolchains for
many architectures available from the Free Electrons guys, so that may
help to unblock this situation somewhat:

http://toolchains.free-electrons.com/


cheers

Re: enabling COMPILE_TEST support for GCC plugins in v4.11

[Michael Ellerman]

[Old thread just popped up in my inbox]

Kees Cook  writes:
> On Thu, Dec 8, 2016 at 5:52 PM, Paul Gortmaker
>  wrote:
>> On Thu, Dec 8, 2016 at 2:00 PM, Kees Cook  wrote:
>>> Hi,
>>>
>>> I'd like to get the GCC plugins building under
>>> allyesconfig/allmodconfig for -next soon (with the intention of
>>> landing the change in v4.11). Specifically, I intend to revert
>>> a519167e753e ("gcc-plugins: disable under COMPILE_TEST").
>>
>> If I recall correctly, I noted that the plugins broke the kernel.org
>> cross compiler toolchains which led to the above disable.
>
> Do you mean these?
> https://www.kernel.org/pub/tools/crosstool/

I think those are the ones Paul is talking about.

Those were mostly built by Tony, who is know, sadly, an Openstack
developer and for some reason doesn't seem to have time to build
toolchains for kernel hackers :P


As folks may have seen on LWN, there are now pre-built toolchains for
many architectures available from the Free Electrons guys, so that may
help to unblock this situation somewhat:

http://toolchains.free-electrons.com/


cheers

[PATCH] fbdev: omapfb: constify ctrl_caps, color_caps, panel_attr_grp and ctrl_attr_grp

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
  130071536 156   14699396b drivers/video/fbdev/omap/omapfb_main.o

File size After adding 'const':
   textdata bss dec hex filename
  131351408 156   14699396b drivers/video/fbdev/omap/omapfb_main.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/omap/omapfb_main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index f4cbfb3..3479a47 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -62,7 +62,7 @@ struct caps_table_struct {
const char *name;
 };
 
-static struct caps_table_struct ctrl_caps[] = {
+static const struct caps_table_struct ctrl_caps[] = {
{ OMAPFB_CAPS_MANUAL_UPDATE,  "manual update" },
{ OMAPFB_CAPS_TEARSYNC,   "tearing synchronization" },
{ OMAPFB_CAPS_PLANE_RELOCATE_MEM, "relocate plane memory" },
@@ -74,7 +74,7 @@ struct caps_table_struct {
{ OMAPFB_CAPS_SET_BACKLIGHT,  "backlight setting" },
 };
 
-static struct caps_table_struct color_caps[] = {
+static const struct caps_table_struct color_caps[] = {
{ 1 << OMAPFB_COLOR_RGB565, "RGB565", },
{ 1 << OMAPFB_COLOR_YUV422, "YUV422", },
{ 1 << OMAPFB_COLOR_YUV420, "YUV420", },
@@ -1384,7 +1384,7 @@ static DEVICE_ATTR(backlight_level, 0664,
NULL,
 };
 
-static struct attribute_group panel_attr_grp = {
+static const struct attribute_group panel_attr_grp = {
.name  = "panel",
.attrs = panel_attrs,
 };
@@ -1406,7 +1406,7 @@ static ssize_t omapfb_show_ctrl_name(struct device *dev,
NULL,
 };
 
-static struct attribute_group ctrl_attr_grp = {
+static const struct attribute_group ctrl_attr_grp = {
.name  = "ctrl",
.attrs = ctrl_attrs,
 };
-- 
1.9.1

[PATCH] fbdev: omapfb: constify ctrl_caps, color_caps, panel_attr_grp and ctrl_attr_grp

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
  130071536 156   14699396b drivers/video/fbdev/omap/omapfb_main.o

File size After adding 'const':
   textdata bss dec hex filename
  131351408 156   14699396b drivers/video/fbdev/omap/omapfb_main.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/omap/omapfb_main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index f4cbfb3..3479a47 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -62,7 +62,7 @@ struct caps_table_struct {
const char *name;
 };
 
-static struct caps_table_struct ctrl_caps[] = {
+static const struct caps_table_struct ctrl_caps[] = {
{ OMAPFB_CAPS_MANUAL_UPDATE,  "manual update" },
{ OMAPFB_CAPS_TEARSYNC,   "tearing synchronization" },
{ OMAPFB_CAPS_PLANE_RELOCATE_MEM, "relocate plane memory" },
@@ -74,7 +74,7 @@ struct caps_table_struct {
{ OMAPFB_CAPS_SET_BACKLIGHT,  "backlight setting" },
 };
 
-static struct caps_table_struct color_caps[] = {
+static const struct caps_table_struct color_caps[] = {
{ 1 << OMAPFB_COLOR_RGB565, "RGB565", },
{ 1 << OMAPFB_COLOR_YUV422, "YUV422", },
{ 1 << OMAPFB_COLOR_YUV420, "YUV420", },
@@ -1384,7 +1384,7 @@ static DEVICE_ATTR(backlight_level, 0664,
NULL,
 };
 
-static struct attribute_group panel_attr_grp = {
+static const struct attribute_group panel_attr_grp = {
.name  = "panel",
.attrs = panel_attrs,
 };
@@ -1406,7 +1406,7 @@ static ssize_t omapfb_show_ctrl_name(struct device *dev,
NULL,
 };
 
-static struct attribute_group ctrl_attr_grp = {
+static const struct attribute_group ctrl_attr_grp = {
.name  = "ctrl",
.attrs = ctrl_attrs,
 };
-- 
1.9.1

Re: [PATCH v2 13/14] drm: stm: remove dead code and pointless local lut storage

[Peter Rosin]

On 2017-06-22 13:49, Philippe CORNU wrote:
> On 06/22/2017 08:06 AM, Peter Rosin wrote:
>> The redundant fb helper .load_lut is no longer used, and can not
>> work right without also providing the fb helpers .gamma_set and
>> .gamma_get thus rendering the code in this driver suspect.
>>
> 
> Hi Peter,
> STM32 chipsets supports 8-bit CLUT mode but this driver version does not 
> support it "yet" (final patch has not been upstreamed because it was a 
> too big fbdev patch for simply adding CLUT...).
> 
> Regarding your patch below, if it helps you to ease the drm framework 
> update then I am agree to "acknowledge it" asap, else if you are not in 
> a hurry, I would prefer a better and definitive patch handling 8-bit 
> CLUT properly and I am ok to help or/and to do it : )

Hi!

The thing is, without my series you will have to provide four callbacks.
The crtc .gamma_set and the three redundant fb helpers .gamma_get,
.gamma_set and .load_lut that pretty much does exactly what the crtc
.gamma_set is doing. Well not .gamma_get, but...

With my series, you only have to provide the crtc .gamma_set, which you
have to provide anyway. and ...the core will handle everything that
.gamma_get was used for...

I.e., your work to provide CLUT support should start with drm support,
which means the crtc .gamma_set, and then move on to the fbdev
emulation. And I have just eliminated the second step for you, and
as suger on top, you no longer have to convince the core drm maintainers
that adding a lot of fbdev emulation code is needed.

So, I think you actually want to wait for my series to land before adding
CLUT support.

> Extra questions:
> - any plan to update modetest with the DRM_FORMAT_C8 support + gamma 
> get/set?

I don't know that code base at all, but from the glimpse I got when browsing
it, it seemed like it was pretty hardwired to non-palettized modes. I ended
up having no need for it, see below...

> - do you have a simple way to test clut with fbdev, last year we where 
> using an old version of the SDL but I am still looking for a small piece 
> of code to do it (else I will do it myself but C8 on fbdev is not really 
> a priority ;-)

I'm doing pretty much the same thing, I have an application that requires
an old SDL, and I'm using the programs/demos/demo.c program from the very
old libggi as a second test app. But that's just because libggi is what
I'm most familiar with, and it doesn't try to be "nice" and do things
automatically, instead you have to manually insert helpers providing
e.g. palette emulation if the application assumes a palettized mode and
only truecolor modes are available from the HW. SDL tends to add those
things for you, making it less easy to test thing, but I'm not an
"SDL-guy", so there may very well exist some knobs I don't know about.

Oh, you probably didn't see this:
http://marc.info/?l=linux-kernel=149786920731175=4

It sports modeset-pal.c that sets the C8 mode, and does a 5 second
palette animation, w/o using fbdev. I used it instead of digging
further into modetest.

Cheers,
peda

Re: [PATCH v2 13/14] drm: stm: remove dead code and pointless local lut storage

[Peter Rosin]

On 2017-06-22 13:49, Philippe CORNU wrote:
> On 06/22/2017 08:06 AM, Peter Rosin wrote:
>> The redundant fb helper .load_lut is no longer used, and can not
>> work right without also providing the fb helpers .gamma_set and
>> .gamma_get thus rendering the code in this driver suspect.
>>
> 
> Hi Peter,
> STM32 chipsets supports 8-bit CLUT mode but this driver version does not 
> support it "yet" (final patch has not been upstreamed because it was a 
> too big fbdev patch for simply adding CLUT...).
> 
> Regarding your patch below, if it helps you to ease the drm framework 
> update then I am agree to "acknowledge it" asap, else if you are not in 
> a hurry, I would prefer a better and definitive patch handling 8-bit 
> CLUT properly and I am ok to help or/and to do it : )

Hi!

The thing is, without my series you will have to provide four callbacks.
The crtc .gamma_set and the three redundant fb helpers .gamma_get,
.gamma_set and .load_lut that pretty much does exactly what the crtc
.gamma_set is doing. Well not .gamma_get, but...

With my series, you only have to provide the crtc .gamma_set, which you
have to provide anyway. and ...the core will handle everything that
.gamma_get was used for...

I.e., your work to provide CLUT support should start with drm support,
which means the crtc .gamma_set, and then move on to the fbdev
emulation. And I have just eliminated the second step for you, and
as suger on top, you no longer have to convince the core drm maintainers
that adding a lot of fbdev emulation code is needed.

So, I think you actually want to wait for my series to land before adding
CLUT support.

> Extra questions:
> - any plan to update modetest with the DRM_FORMAT_C8 support + gamma 
> get/set?

I don't know that code base at all, but from the glimpse I got when browsing
it, it seemed like it was pretty hardwired to non-palettized modes. I ended
up having no need for it, see below...

> - do you have a simple way to test clut with fbdev, last year we where 
> using an old version of the SDL but I am still looking for a small piece 
> of code to do it (else I will do it myself but C8 on fbdev is not really 
> a priority ;-)

I'm doing pretty much the same thing, I have an application that requires
an old SDL, and I'm using the programs/demos/demo.c program from the very
old libggi as a second test app. But that's just because libggi is what
I'm most familiar with, and it doesn't try to be "nice" and do things
automatically, instead you have to manually insert helpers providing
e.g. palette emulation if the application assumes a palettized mode and
only truecolor modes are available from the HW. SDL tends to add those
things for you, making it less easy to test thing, but I'm not an
"SDL-guy", so there may very well exist some knobs I don't know about.

Oh, you probably didn't see this:
http://marc.info/?l=linux-kernel=149786920731175=4

It sports modeset-pal.c that sets the C8 mode, and does a 5 second
palette animation, w/o using fbdev. I used it instead of digging
further into modetest.

Cheers,
peda

[PATCH] omapfb: panel-dsi-cm: constify dsicm_attr_group

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
   4657 464   051211401 
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.o

File size After adding 'const':
   textdata bss dec hex filename
   4713 400   0511313f9 
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
index fd2b372d..d7bb3d5 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
@@ -559,7 +559,7 @@ static DEVICE_ATTR(ulps_timeout, S_IRUGO | S_IWUSR,
NULL,
 };
 
-static struct attribute_group dsicm_attr_group = {
+static const struct attribute_group dsicm_attr_group = {
.attrs = dsicm_attrs,
 };
 
-- 
1.9.1

[PATCH] omapfb: panel-dsi-cm: constify dsicm_attr_group

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
   4657 464   051211401 
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.o

File size After adding 'const':
   textdata bss dec hex filename
   4713 400   0511313f9 
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.o

Signed-off-by: Arvind Yadav 
---
 drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
index fd2b372d..d7bb3d5 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
@@ -559,7 +559,7 @@ static DEVICE_ATTR(ulps_timeout, S_IRUGO | S_IWUSR,
NULL,
 };
 
-static struct attribute_group dsicm_attr_group = {
+static const struct attribute_group dsicm_attr_group = {
.attrs = dsicm_attrs,
 };
 
-- 
1.9.1

[git pull] drm fixes for v4.12-rc7

[Dave Airlie]

Hi Linus,

A varied bunch of fixes, one for an API regression with connectors,
otherwise amdgpu and i915 have
a bunch of varied fixes, the shrinker ones being the most important.

Dave.

The following changes since commit 41f1830f5a7af77cf5c86359aba3cbd706687e52:

  Linux 4.12-rc6 (2017-06-19 22:19:37 +0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc7

for you to fetch changes up to 33ce7563a4858430fdf38bb867513d3fbc3dda65:

  Merge tag 'drm-misc-fixes-2017-06-22' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-06-23
11:44:51 +1000)


i915, amdgpu and one core regression fix


Alex Deucher (4):
  drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating
  drm/amdgpu: adjust default display clock
  drm/radeon: add a PX quirk for another K53TK variant
  drm/radeon: add a quirk for Toshiba Satellite L20-183

Chris Wilson (3):
  drm/i915: Differentiate between sw write location into ring and
last hw read
  drm/i915: Encourage our shrinker more when our shmemfs allocations fails
  drm/i915: Remove __GFP_NORETRY from our buffer allocator

Daniel Vetter (1):
  drm: Fix GETCONNECTOR regression

Dave Airlie (3):
  Merge tag 'drm-intel-fixes-2017-06-20' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-06-22' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes

Dhinakaran Pandiyan (1):
  drm/i915: Don't enable backlight at setup time.

Junshan Fang (1):
  drm/amdgpu: add Polaris12 DID

Ville Syrjälä (2):
  drm/i915: Fix deadlock witha the pipe A quirk during resume
  drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic()

 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c  |  4 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/atombios_crtc.c|  4 +-
 drivers/gpu/drm/drm_connector.c   | 38 
 drivers/gpu/drm/i915/i915_gem.c   | 63 ++-
 drivers/gpu/drm/i915/i915_gem_request.c   |  2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c|  4 +-
 drivers/gpu/drm/i915/intel_display.c  | 30 +++--
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c |  2 -
 drivers/gpu/drm/i915/intel_lrc.c  |  6 +--
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 41 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h   | 19 +++-
 drivers/gpu/drm/radeon/radeon_combios.c   |  7 +++
 drivers/gpu/drm/radeon/radeon_device.c|  4 ++
 14 files changed, 145 insertions(+), 80 deletions(-)

[git pull] drm fixes for v4.12-rc7

[Dave Airlie]

Hi Linus,

A varied bunch of fixes, one for an API regression with connectors,
otherwise amdgpu and i915 have
a bunch of varied fixes, the shrinker ones being the most important.

Dave.

The following changes since commit 41f1830f5a7af77cf5c86359aba3cbd706687e52:

  Linux 4.12-rc6 (2017-06-19 22:19:37 +0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.12-rc7

for you to fetch changes up to 33ce7563a4858430fdf38bb867513d3fbc3dda65:

  Merge tag 'drm-misc-fixes-2017-06-22' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-06-23
11:44:51 +1000)


i915, amdgpu and one core regression fix


Alex Deucher (4):
  drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating
  drm/amdgpu: adjust default display clock
  drm/radeon: add a PX quirk for another K53TK variant
  drm/radeon: add a quirk for Toshiba Satellite L20-183

Chris Wilson (3):
  drm/i915: Differentiate between sw write location into ring and
last hw read
  drm/i915: Encourage our shrinker more when our shmemfs allocations fails
  drm/i915: Remove __GFP_NORETRY from our buffer allocator

Daniel Vetter (1):
  drm: Fix GETCONNECTOR regression

Dave Airlie (3):
  Merge tag 'drm-intel-fixes-2017-06-20' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge branch 'drm-fixes-4.12' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-06-22' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes

Dhinakaran Pandiyan (1):
  drm/i915: Don't enable backlight at setup time.

Junshan Fang (1):
  drm/amdgpu: add Polaris12 DID

Ville Syrjälä (2):
  drm/i915: Fix deadlock witha the pipe A quirk during resume
  drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic()

 drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c  |  4 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  1 +
 drivers/gpu/drm/amd/amdgpu/atombios_crtc.c|  4 +-
 drivers/gpu/drm/drm_connector.c   | 38 
 drivers/gpu/drm/i915/i915_gem.c   | 63 ++-
 drivers/gpu/drm/i915/i915_gem_request.c   |  2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c|  4 +-
 drivers/gpu/drm/i915/intel_display.c  | 30 +++--
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c |  2 -
 drivers/gpu/drm/i915/intel_lrc.c  |  6 +--
 drivers/gpu/drm/i915/intel_ringbuffer.c   | 41 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h   | 19 +++-
 drivers/gpu/drm/radeon/radeon_combios.c   |  7 +++
 drivers/gpu/drm/radeon/radeon_device.c|  4 ++
 14 files changed, 145 insertions(+), 80 deletions(-)

[PATCH v2 4/6] pwm: bindings: add MT2712/MT7622 information

[Zhi Mao]

add MT2712/MT7622 pwm information

Signed-off-by: Zhi Mao 
---
 .../devicetree/bindings/pwm/pwm-mediatek.txt   |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt 
b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index 54c59b0..ef8bd3c 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -2,6 +2,8 @@ MediaTek PWM controller
 
 Required properties:
  - compatible: should be "mediatek,-pwm":
+   - "mediatek,mt2712-pwm": found on mt2712 SoC.
+   - "mediatek,mt7622-pwm": found on mt7622 SoC.
- "mediatek,mt7623-pwm": found on mt7623 SoC.
  - reg: physical base address and length of the controller's registers.
  - #pwm-cells: must be 2. See pwm.txt in this directory for a description of
@@ -10,7 +12,9 @@ Required properties:
  - clock-names: must contain the following:
- "top": the top clock generator
- "main": clock used by the PWM core
-   - "pwm1-5": the five per PWM clocks
+   - "pwm1-8": the eight per PWM clocks for mt2712
+   - "pwm1-6": the six per PWM clocks for mt7622
+   - "pwm1-5": the five per PWM clocks for mt7623
  - pinctrl-names: Must contain a "default" entry.
  - pinctrl-0: One property must exist for each entry in pinctrl-names.
See pinctrl/pinctrl-bindings.txt for details of the property values.
-- 
1.7.9.5

[PATCH] char: ipmi: constify bmc_dev_attr_group and bmc_device_type

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
  256781024  92   2679468aa drivers/char/ipmi/ipmi_msghandler.o

File size After adding 'const':
   textdata bss dec hex filename
  25806 896  92   2679468aa drivers/char/ipmi/ipmi_msghandler.o

Signed-off-by: Arvind Yadav 
---
 drivers/char/ipmi/ipmi_msghandler.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 9f69995..d60c05c 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -2397,7 +2397,7 @@ static umode_t bmc_dev_attr_is_visible(struct kobject 
*kobj,
return mode;
 }
 
-static struct attribute_group bmc_dev_attr_group = {
+static const struct attribute_group bmc_dev_attr_group = {
.attrs  = bmc_dev_attrs,
.is_visible = bmc_dev_attr_is_visible,
 };
@@ -2407,7 +2407,7 @@ static umode_t bmc_dev_attr_is_visible(struct kobject 
*kobj,
NULL
 };
 
-static struct device_type bmc_device_type = {
+static const struct device_type bmc_device_type = {
.groups = bmc_dev_attr_groups,
 };
 
-- 
1.9.1

[PATCH v2 4/6] pwm: bindings: add MT2712/MT7622 information

[Zhi Mao]

add MT2712/MT7622 pwm information

Signed-off-by: Zhi Mao 
---
 .../devicetree/bindings/pwm/pwm-mediatek.txt   |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt 
b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
index 54c59b0..ef8bd3c 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-mediatek.txt
@@ -2,6 +2,8 @@ MediaTek PWM controller
 
 Required properties:
  - compatible: should be "mediatek,-pwm":
+   - "mediatek,mt2712-pwm": found on mt2712 SoC.
+   - "mediatek,mt7622-pwm": found on mt7622 SoC.
- "mediatek,mt7623-pwm": found on mt7623 SoC.
  - reg: physical base address and length of the controller's registers.
  - #pwm-cells: must be 2. See pwm.txt in this directory for a description of
@@ -10,7 +12,9 @@ Required properties:
  - clock-names: must contain the following:
- "top": the top clock generator
- "main": clock used by the PWM core
-   - "pwm1-5": the five per PWM clocks
+   - "pwm1-8": the eight per PWM clocks for mt2712
+   - "pwm1-6": the six per PWM clocks for mt7622
+   - "pwm1-5": the five per PWM clocks for mt7623
  - pinctrl-names: Must contain a "default" entry.
  - pinctrl-0: One property must exist for each entry in pinctrl-names.
See pinctrl/pinctrl-bindings.txt for details of the property values.
-- 
1.7.9.5

[PATCH] char: ipmi: constify bmc_dev_attr_group and bmc_device_type

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
  256781024  92   2679468aa drivers/char/ipmi/ipmi_msghandler.o

File size After adding 'const':
   textdata bss dec hex filename
  25806 896  92   2679468aa drivers/char/ipmi/ipmi_msghandler.o

Signed-off-by: Arvind Yadav 
---
 drivers/char/ipmi/ipmi_msghandler.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_msghandler.c 
b/drivers/char/ipmi/ipmi_msghandler.c
index 9f69995..d60c05c 100644
--- a/drivers/char/ipmi/ipmi_msghandler.c
+++ b/drivers/char/ipmi/ipmi_msghandler.c
@@ -2397,7 +2397,7 @@ static umode_t bmc_dev_attr_is_visible(struct kobject 
*kobj,
return mode;
 }
 
-static struct attribute_group bmc_dev_attr_group = {
+static const struct attribute_group bmc_dev_attr_group = {
.attrs  = bmc_dev_attrs,
.is_visible = bmc_dev_attr_is_visible,
 };
@@ -2407,7 +2407,7 @@ static umode_t bmc_dev_attr_is_visible(struct kobject 
*kobj,
NULL
 };
 
-static struct device_type bmc_device_type = {
+static const struct device_type bmc_device_type = {
.groups = bmc_dev_attr_groups,
 };
 
-- 
1.9.1

[PATCH v2 1/6] pwm: kconfig: modify mediatek information

[Zhi Mao]

modify mediatek information

Signed-off-by: Zhi Mao 
---
 drivers/pwm/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 313c107..45cdf2a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -300,7 +300,7 @@ config PWM_MEDIATEK
  Generic PWM framework driver for Mediatek ARM SoC.
 
  To compile this driver as a module, choose M here: the module
- will be called pwm-mxs.
+ will be called pwm-mediatek.
 
 config PWM_MXS
tristate "Freescale MXS PWM support"
-- 
1.7.9.5

[PATCH v2 1/6] pwm: kconfig: modify mediatek information

[Zhi Mao]

modify mediatek information

Signed-off-by: Zhi Mao 
---
 drivers/pwm/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 313c107..45cdf2a 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -300,7 +300,7 @@ config PWM_MEDIATEK
  Generic PWM framework driver for Mediatek ARM SoC.
 
  To compile this driver as a module, choose M here: the module
- will be called pwm-mxs.
+ will be called pwm-mediatek.
 
 config PWM_MXS
tristate "Freescale MXS PWM support"
-- 
1.7.9.5

Re: [PATCH] ext4: check return value of kstrtoull correctly in reserved_clusters_store

[Theodore Ts'o]

On Thu, Jun 15, 2017 at 05:57:30PM +0800, Chao Yu wrote:
> kstrtoull returns 0 on success, however, in reserved_clusters_store we
> will return -EINVAL if kstrtoull returns 0, it makes us fail to update
> reserved_clusters value through sysfs.
> 
> Signed-off-by: Chao Yu 
> Signed-off-by: Miao Xie 

Thanks, applied.

- Ted

Re: [PATCH] ext4: check return value of kstrtoull correctly in reserved_clusters_store

[Theodore Ts'o]

On Thu, Jun 15, 2017 at 05:57:30PM +0800, Chao Yu wrote:
> kstrtoull returns 0 on success, however, in reserved_clusters_store we
> will return -EINVAL if kstrtoull returns 0, it makes us fail to update
> reserved_clusters value through sysfs.
> 
> Signed-off-by: Chao Yu 
> Signed-off-by: Miao Xie 

Thanks, applied.

- Ted

[PATCH V3] acpi: acpica: fix acpi parse and parseext cache leaks

[Seunghun Han]

I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.

I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.

Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added _OSI(Processor Device)
[0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)
[0.353182] ACPI: Added _OSI(Processor Aggregator Device)
[0.356028] ACPI: Unable to start the ACPI Interpreter
[0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
[0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects
[0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
4.12.0-rc4-next-20170608+ #10
[0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[0.361873] Call Trace:
[0.362243]  ? dump_stack+0x5c/0x81
[0.362591]  ? kmem_cache_destroy+0x1aa/0x1c0
[0.362944]  ? acpi_sleep_proc_init+0x27/0x27
[0.363296]  ? acpi_os_delete_cache+0xa/0x10
[0.363646]  ? acpi_ut_delete_caches+0x6d/0x7b
[0.364000]  ? acpi_terminate+0xa/0x14
[0.364000]  ? acpi_init+0x2af/0x34f
[0.364000]  ? __class_create+0x4c/0x80
[0.364000]  ? video_setup+0x7f/0x7f
[0.364000]  ? acpi_sleep_proc_init+0x27/0x27
[0.364000]  ? do_one_initcall+0x4e/0x1a0
[0.364000]  ? kernel_init_freeable+0x189/0x20a
[0.364000]  ? rest_init+0xc0/0xc0
[0.364000]  ? kernel_init+0xa/0x100
[0.364000]  ? ret_from_fork+0x25/0x30

I analyzed this memory leak in detail. I found that “Acpi-State” cache and
“Acpi-Parse” cache were merged because the size of cache objects was same
slab cache size.

I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked
using SLAB_NEVER_MERGE flag in kmem_cache_create() function.

Real ACPI cache leak point is as follows:
[0.360101] ACPI: Added _OSI(Module Device)
[0.360101] ACPI: Added _OSI(Processor Device)
[0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)
[0.361043] ACPI: Added _OSI(Processor Aggregator Device)
[0.364016] ACPI: Unable to start the ACPI Interpreter
[0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
[0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects
[0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW
4.12.0-rc4-next-20170608+ #8
[0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[0.372000] Call Trace:
[0.372000]  ? dump_stack+0x5c/0x81
[0.372000]  ? kmem_cache_destroy+0x1aa/0x1c0
[0.372000]  ? acpi_sleep_proc_init+0x27/0x27
[0.372000]  ? acpi_os_delete_cache+0xa/0x10
[0.372000]  ? acpi_ut_delete_caches+0x56/0x7b
[0.372000]  ? acpi_terminate+0xa/0x14
[0.372000]  ? acpi_init+0x2af/0x34f
[0.372000]  ? __class_create+0x4c/0x80
[0.372000]  ? video_setup+0x7f/0x7f
[0.372000]  ? acpi_sleep_proc_init+0x27/0x27
[0.372000]  ? do_one_initcall+0x4e/0x1a0
[0.372000]  ? kernel_init_freeable+0x189/0x20a
[0.372000]  ? rest_init+0xc0/0xc0
[0.372000]  ? kernel_init+0xa/0x100
[0.372000]  ? ret_from_fork+0x25/0x30
[0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects
[0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW
4.12.0-rc4-next-20170608+ #8
[0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[0.392000] Call Trace:
[0.392000]  ? dump_stack+0x5c/0x81
[0.392000]  ? kmem_cache_destroy+0x1aa/0x1c0
[0.392000]  ? acpi_sleep_proc_init+0x27/0x27
[0.392000]  ? acpi_os_delete_cache+0xa/0x10
[0.392000]  ? acpi_ut_delete_caches+0x6d/0x7b
[0.392000]  ? acpi_terminate+0xa/0x14
[0.392000]  ? acpi_init+0x2af/0x34f
[0.392000]  ? __class_create+0x4c/0x80
[0.392000]  ? video_setup+0x7f/0x7f
[0.392000]  ? acpi_sleep_proc_init+0x27/0x27
[0.392000]  ? do_one_initcall+0x4e/0x1a0
[0.392000]  ? kernel_init_freeable+0x189/0x20a
[0.392000]  ? rest_init+0xc0/0xc0
[0.392000]  ? kernel_init+0xa/0x100
[0.392000]  ? ret_from_fork+0x25/0x30

When early abort is occurred due to invalid ACPI information, Linux kernel
terminates ACPI by calling acpi_terminate() function. The function calls
acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_
cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache).

But the deletion codes in acpi_ut_delete_caches() function only delete
slab caches using kmem_cache_destroy() function, therefore the cache
objects should be flushed before acpi_ut_delete_caches() function.

“Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse
function, acpi_ps_parse_loop(). The function should have flush codes to
handle an error state due to invalid AML codes.

This cache leak has a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this 

[PATCH v2 0/6] mediatek: pwm driver add MT2712/MT7622 support

[Zhi Mao]

change in v2:
1. add error check for enable colock control flow
2. use "goto err_clk(main/top)" coding style, for preparing clk error case
3. remove comments inline /*===*/
4. move "PWM_CLK_DIV_MAX" modification to its own patch
5. move pwm source clock selection to its own patch

Zhi Mao (6):
  pwm: kconfig: modify mediatek information
  pwm: mediatek: fix pwm source clock selection
  pwm: mediatek: fix clock control issue
  pwm: bindings: add MT2712/MT7622 information
  pwm: mediatek: add PWM_CLK_DIV_MAX
  pwm: mediatek: add MT2712/MT7622 support

 .../devicetree/bindings/pwm/pwm-mediatek.txt   |6 +-
 drivers/pwm/Kconfig|2 +-
 drivers/pwm/pwm-mediatek.c |  132 ++--
 3 files changed, 103 insertions(+), 37 deletions(-)

[PATCH v2 3/6] pwm: mediatek: fix clock control issue

[Zhi Mao]

1. prepare top/main clk in mtk_pwm_probe() function,
   it will increase power consumption
   and in original code these clocks is only prepeare but never enabled
2. pwm clock should be enabled before setting pwm registers
   in function: mtk_pwm_config()
3. delete "pwm_disable" in function:mtk_pwm_remove(),
   as framework should disable all the pwms, before remove them.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |   69 ++--
 1 file changed, 47 insertions(+), 22 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index d08b5b3..554a042 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -2,6 +2,7 @@
  * Mediatek Pulse Width Modulator driver
  *
  * Copyright (C) 2015 John Crispin 
+ * Copyright (C) 2017 Zhi Mao 
  *
  * This file is licensed under the terms of the GNU General Public
  * License version 2. This program is licensed "as is" without any
@@ -61,6 +62,42 @@ static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct 
pwm_chip *chip)
return container_of(chip, struct mtk_pwm_chip, chip);
 }
 
+static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+   struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+   int ret = 0;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
+   if (ret < 0)
+   return ret;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_MAIN]);
+   if (ret < 0)
+   goto disable_clk_top;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   if (ret < 0)
+   goto disable_clk_main;
+
+   return 0;
+
+disable_clk_main:
+   clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+disable_clk_top:
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+
+   return ret;
+}
+
+static void mtk_pwm_clk_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+   struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+
+   clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+}
+
 static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
unsigned int offset)
 {
@@ -80,6 +117,11 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
u32 resolution, clkdiv = 0;
+   int ret;
+
+   ret = mtk_pwm_clk_enable(chip, pwm);
+   if (ret < 0)
+   return ret;
 
resolution = NSEC_PER_SEC / clk_get_rate(clk);
 
@@ -95,6 +137,8 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
 
+   mtk_pwm_clk_disable(chip, pwm);
+
return 0;
 }
 
@@ -104,7 +148,7 @@ static int mtk_pwm_enable(struct pwm_chip *chip, struct 
pwm_device *pwm)
u32 value;
int ret;
 
-   ret = clk_prepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   ret = mtk_pwm_clk_enable(chip, pwm);
if (ret < 0)
return ret;
 
@@ -124,7 +168,7 @@ static void mtk_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
value &= ~BIT(pwm->hwpwm);
writel(value, pc->regs);
 
-   clk_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   mtk_pwm_clk_disable(chip, pwm);
 }
 
 static const struct pwm_ops mtk_pwm_ops = {
@@ -156,14 +200,6 @@ static int mtk_pwm_probe(struct platform_device *pdev)
return PTR_ERR(pc->clks[i]);
}
 
-   ret = clk_prepare(pc->clks[MTK_CLK_TOP]);
-   if (ret < 0)
-   return ret;
-
-   ret = clk_prepare(pc->clks[MTK_CLK_MAIN]);
-   if (ret < 0)
-   goto disable_clk_top;
-
platform_set_drvdata(pdev, pc);
 
pc->chip.dev = >dev;
@@ -174,26 +210,15 @@ static int mtk_pwm_probe(struct platform_device *pdev)
ret = pwmchip_add(>chip);
if (ret < 0) {
dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
-   goto disable_clk_main;
+   return ret;
}
 
return 0;
-
-disable_clk_main:
-   clk_unprepare(pc->clks[MTK_CLK_MAIN]);
-disable_clk_top:
-   clk_unprepare(pc->clks[MTK_CLK_TOP]);
-
-   return ret;
 }
 
 static int mtk_pwm_remove(struct platform_device *pdev)
 {
struct mtk_pwm_chip *pc = platform_get_drvdata(pdev);
-   unsigned int i;
-
-   for (i = 0; i < pc->chip.npwm; i++)
-   pwm_disable(>chip.pwms[i]);
 
return pwmchip_remove(>chip);
 }
-- 
1.7.9.5

[PATCH V3] acpi: acpica: fix acpi parse and parseext cache leaks

[Seunghun Han]

I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.

I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.

Boot log of ACPI cache leak is as follows:
[0.352414] ACPI: Added _OSI(Module Device)
[0.353182] ACPI: Added _OSI(Processor Device)
[0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)
[0.353182] ACPI: Added _OSI(Processor Aggregator Device)
[0.356028] ACPI: Unable to start the ACPI Interpreter
[0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
[0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects
[0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
4.12.0-rc4-next-20170608+ #10
[0.361273] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[0.361873] Call Trace:
[0.362243]  ? dump_stack+0x5c/0x81
[0.362591]  ? kmem_cache_destroy+0x1aa/0x1c0
[0.362944]  ? acpi_sleep_proc_init+0x27/0x27
[0.363296]  ? acpi_os_delete_cache+0xa/0x10
[0.363646]  ? acpi_ut_delete_caches+0x6d/0x7b
[0.364000]  ? acpi_terminate+0xa/0x14
[0.364000]  ? acpi_init+0x2af/0x34f
[0.364000]  ? __class_create+0x4c/0x80
[0.364000]  ? video_setup+0x7f/0x7f
[0.364000]  ? acpi_sleep_proc_init+0x27/0x27
[0.364000]  ? do_one_initcall+0x4e/0x1a0
[0.364000]  ? kernel_init_freeable+0x189/0x20a
[0.364000]  ? rest_init+0xc0/0xc0
[0.364000]  ? kernel_init+0xa/0x100
[0.364000]  ? ret_from_fork+0x25/0x30

I analyzed this memory leak in detail. I found that “Acpi-State” cache and
“Acpi-Parse” cache were merged because the size of cache objects was same
slab cache size.

I finally found “Acpi-Parse” cache and “Acpi-ParseExt” cache were leaked
using SLAB_NEVER_MERGE flag in kmem_cache_create() function.

Real ACPI cache leak point is as follows:
[0.360101] ACPI: Added _OSI(Module Device)
[0.360101] ACPI: Added _OSI(Processor Device)
[0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)
[0.361043] ACPI: Added _OSI(Processor Aggregator Device)
[0.364016] ACPI: Unable to start the ACPI Interpreter
[0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
[0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects
[0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW
4.12.0-rc4-next-20170608+ #8
[0.371256] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[0.372000] Call Trace:
[0.372000]  ? dump_stack+0x5c/0x81
[0.372000]  ? kmem_cache_destroy+0x1aa/0x1c0
[0.372000]  ? acpi_sleep_proc_init+0x27/0x27
[0.372000]  ? acpi_os_delete_cache+0xa/0x10
[0.372000]  ? acpi_ut_delete_caches+0x56/0x7b
[0.372000]  ? acpi_terminate+0xa/0x14
[0.372000]  ? acpi_init+0x2af/0x34f
[0.372000]  ? __class_create+0x4c/0x80
[0.372000]  ? video_setup+0x7f/0x7f
[0.372000]  ? acpi_sleep_proc_init+0x27/0x27
[0.372000]  ? do_one_initcall+0x4e/0x1a0
[0.372000]  ? kernel_init_freeable+0x189/0x20a
[0.372000]  ? rest_init+0xc0/0xc0
[0.372000]  ? kernel_init+0xa/0x100
[0.372000]  ? ret_from_fork+0x25/0x30
[0.388039] kmem_cache_destroy Acpi-ParseExt: Slab cache still has objects
[0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: GW
4.12.0-rc4-next-20170608+ #8
[0.390557] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS
VirtualBox 12/01/2006
[0.392000] Call Trace:
[0.392000]  ? dump_stack+0x5c/0x81
[0.392000]  ? kmem_cache_destroy+0x1aa/0x1c0
[0.392000]  ? acpi_sleep_proc_init+0x27/0x27
[0.392000]  ? acpi_os_delete_cache+0xa/0x10
[0.392000]  ? acpi_ut_delete_caches+0x6d/0x7b
[0.392000]  ? acpi_terminate+0xa/0x14
[0.392000]  ? acpi_init+0x2af/0x34f
[0.392000]  ? __class_create+0x4c/0x80
[0.392000]  ? video_setup+0x7f/0x7f
[0.392000]  ? acpi_sleep_proc_init+0x27/0x27
[0.392000]  ? do_one_initcall+0x4e/0x1a0
[0.392000]  ? kernel_init_freeable+0x189/0x20a
[0.392000]  ? rest_init+0xc0/0xc0
[0.392000]  ? kernel_init+0xa/0x100
[0.392000]  ? ret_from_fork+0x25/0x30

When early abort is occurred due to invalid ACPI information, Linux kernel
terminates ACPI by calling acpi_terminate() function. The function calls
acpi_ut_delete_caches() function to delete local caches (acpi_gbl_namespace_
cache, state_cache, operand_cache, ps_node_cache, ps_node_ext_cache).

But the deletion codes in acpi_ut_delete_caches() function only delete
slab caches using kmem_cache_destroy() function, therefore the cache
objects should be flushed before acpi_ut_delete_caches() function.

“Acpi-Parse” cache and “Acpi-ParseExt” cache are used in an AML parse
function, acpi_ps_parse_loop(). The function should have flush codes to
handle an error state due to invalid AML codes.

This cache leak has a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this 

[PATCH v2 0/6] mediatek: pwm driver add MT2712/MT7622 support

[Zhi Mao]

change in v2:
1. add error check for enable colock control flow
2. use "goto err_clk(main/top)" coding style, for preparing clk error case
3. remove comments inline /*===*/
4. move "PWM_CLK_DIV_MAX" modification to its own patch
5. move pwm source clock selection to its own patch

Zhi Mao (6):
  pwm: kconfig: modify mediatek information
  pwm: mediatek: fix pwm source clock selection
  pwm: mediatek: fix clock control issue
  pwm: bindings: add MT2712/MT7622 information
  pwm: mediatek: add PWM_CLK_DIV_MAX
  pwm: mediatek: add MT2712/MT7622 support

 .../devicetree/bindings/pwm/pwm-mediatek.txt   |6 +-
 drivers/pwm/Kconfig|2 +-
 drivers/pwm/pwm-mediatek.c |  132 ++--
 3 files changed, 103 insertions(+), 37 deletions(-)

[PATCH v2 3/6] pwm: mediatek: fix clock control issue

[Zhi Mao]

1. prepare top/main clk in mtk_pwm_probe() function,
   it will increase power consumption
   and in original code these clocks is only prepeare but never enabled
2. pwm clock should be enabled before setting pwm registers
   in function: mtk_pwm_config()
3. delete "pwm_disable" in function:mtk_pwm_remove(),
   as framework should disable all the pwms, before remove them.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |   69 ++--
 1 file changed, 47 insertions(+), 22 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index d08b5b3..554a042 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -2,6 +2,7 @@
  * Mediatek Pulse Width Modulator driver
  *
  * Copyright (C) 2015 John Crispin 
+ * Copyright (C) 2017 Zhi Mao 
  *
  * This file is licensed under the terms of the GNU General Public
  * License version 2. This program is licensed "as is" without any
@@ -61,6 +62,42 @@ static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct 
pwm_chip *chip)
return container_of(chip, struct mtk_pwm_chip, chip);
 }
 
+static int mtk_pwm_clk_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+   struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+   int ret = 0;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_TOP]);
+   if (ret < 0)
+   return ret;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_MAIN]);
+   if (ret < 0)
+   goto disable_clk_top;
+
+   ret = clk_prepare_enable(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   if (ret < 0)
+   goto disable_clk_main;
+
+   return 0;
+
+disable_clk_main:
+   clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+disable_clk_top:
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+
+   return ret;
+}
+
+static void mtk_pwm_clk_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+   struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
+
+   clk_disable_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_MAIN]);
+   clk_disable_unprepare(pc->clks[MTK_CLK_TOP]);
+}
+
 static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
unsigned int offset)
 {
@@ -80,6 +117,11 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
struct mtk_pwm_chip *pc = to_mtk_pwm_chip(chip);
struct clk *clk = pc->clks[MTK_CLK_PWM1 + pwm->hwpwm];
u32 resolution, clkdiv = 0;
+   int ret;
+
+   ret = mtk_pwm_clk_enable(chip, pwm);
+   if (ret < 0)
+   return ret;
 
resolution = NSEC_PER_SEC / clk_get_rate(clk);
 
@@ -95,6 +137,8 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
 
+   mtk_pwm_clk_disable(chip, pwm);
+
return 0;
 }
 
@@ -104,7 +148,7 @@ static int mtk_pwm_enable(struct pwm_chip *chip, struct 
pwm_device *pwm)
u32 value;
int ret;
 
-   ret = clk_prepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   ret = mtk_pwm_clk_enable(chip, pwm);
if (ret < 0)
return ret;
 
@@ -124,7 +168,7 @@ static void mtk_pwm_disable(struct pwm_chip *chip, struct 
pwm_device *pwm)
value &= ~BIT(pwm->hwpwm);
writel(value, pc->regs);
 
-   clk_unprepare(pc->clks[MTK_CLK_PWM1 + pwm->hwpwm]);
+   mtk_pwm_clk_disable(chip, pwm);
 }
 
 static const struct pwm_ops mtk_pwm_ops = {
@@ -156,14 +200,6 @@ static int mtk_pwm_probe(struct platform_device *pdev)
return PTR_ERR(pc->clks[i]);
}
 
-   ret = clk_prepare(pc->clks[MTK_CLK_TOP]);
-   if (ret < 0)
-   return ret;
-
-   ret = clk_prepare(pc->clks[MTK_CLK_MAIN]);
-   if (ret < 0)
-   goto disable_clk_top;
-
platform_set_drvdata(pdev, pc);
 
pc->chip.dev = >dev;
@@ -174,26 +210,15 @@ static int mtk_pwm_probe(struct platform_device *pdev)
ret = pwmchip_add(>chip);
if (ret < 0) {
dev_err(>dev, "pwmchip_add() failed: %d\n", ret);
-   goto disable_clk_main;
+   return ret;
}
 
return 0;
-
-disable_clk_main:
-   clk_unprepare(pc->clks[MTK_CLK_MAIN]);
-disable_clk_top:
-   clk_unprepare(pc->clks[MTK_CLK_TOP]);
-
-   return ret;
 }
 
 static int mtk_pwm_remove(struct platform_device *pdev)
 {
struct mtk_pwm_chip *pc = platform_get_drvdata(pdev);
-   unsigned int i;
-
-   for (i = 0; i < pc->chip.npwm; i++)
-   pwm_disable(>chip.pwms[i]);
 
return pwmchip_remove(>chip);
 }
-- 
1.7.9.5

[PATCH v2 6/6] pwm: mediatek: add MT2712/MT7622 support

[Zhi Mao]

1. support multiple chip(MT2712, MT7622, MT7623)
2. add mtk_pwm_com_reg for match the registers of MT2712 pwm8
the register offset address of pwm8 for MT2712 is not fixed 0x40
and they are not the same as pwm0~6.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |   55 +++-
 1 file changed, 44 insertions(+), 11 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index e5f6425..a07ae19 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,11 +41,19 @@ enum {
MTK_CLK_PWM3,
MTK_CLK_PWM4,
MTK_CLK_PWM5,
+   MTK_CLK_PWM6,
+   MTK_CLK_PWM7,
+   MTK_CLK_PWM8,
MTK_CLK_MAX,
 };
 
-static const char * const mtk_pwm_clk_name[] = {
-   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5"
+static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
+   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4",
+   "pwm5", "pwm6", "pwm7", "pwm8"
+};
+
+struct mtk_com_pwm_data {
+   unsigned int pwm_nums;
 };
 
 /**
@@ -57,6 +66,11 @@ struct mtk_pwm_chip {
struct pwm_chip chip;
void __iomem *regs;
struct clk *clks[MTK_CLK_MAX];
+   const struct mtk_com_pwm_data *data;
+};
+
+static const unsigned long mtk_pwm_com_reg[] = {
+   0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
 };
 
 static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct pwm_chip *chip)
@@ -103,14 +117,14 @@ static void mtk_pwm_clk_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
 static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
unsigned int offset)
 {
-   return readl(chip->regs + 0x10 + (num * 0x40) + offset);
+   return readl(chip->regs + mtk_pwm_com_reg[num] + offset);
 }
 
 static inline void mtk_pwm_writel(struct mtk_pwm_chip *chip,
  unsigned int num, unsigned int offset,
  u32 value)
 {
-   writel(value, chip->regs + 0x10 + (num * 0x40) + offset);
+   writel(value, chip->regs + mtk_pwm_com_reg[num] + offset);
 }
 
 static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -193,23 +207,28 @@ static int mtk_pwm_probe(struct platform_device *pdev)
if (!pc)
return -ENOMEM;
 
+   pc->data = of_device_get_match_data(>dev);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pc->regs = devm_ioremap_resource(>dev, res);
if (IS_ERR(pc->regs))
return PTR_ERR(pc->regs);
 
-   for (i = 0; i < MTK_CLK_MAX; i++) {
+   for (i = 0; i < pc->data->pwm_nums + 2; i++) {
pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
-   if (IS_ERR(pc->clks[i]))
+   if (IS_ERR(pc->clks[i])) {
+   dev_err(>dev, "[PWM] clock: %s fail: %ld\n",
+   mtk_pwm_clk_name[i], PTR_ERR(pc->clks[i]));
return PTR_ERR(pc->clks[i]);
+   }
}
 
-   platform_set_drvdata(pdev, pc);
-
pc->chip.dev = >dev;
pc->chip.ops = _pwm_ops;
pc->chip.base = -1;
-   pc->chip.npwm = 5;
+   pc->chip.npwm = pc->data->pwm_nums;
+
+   platform_set_drvdata(pdev, pc);
 
ret = pwmchip_add(>chip);
if (ret < 0) {
@@ -227,9 +246,23 @@ static int mtk_pwm_remove(struct platform_device *pdev)
return pwmchip_remove(>chip);
 }
 
+static const struct mtk_com_pwm_data mt2712_pwm_data = {
+   .pwm_nums = 8,
+};
+
+static const struct mtk_com_pwm_data mt7622_pwm_data = {
+   .pwm_nums = 6,
+};
+
+static const struct mtk_com_pwm_data mt7623_pwm_data = {
+   .pwm_nums = 5,
+};
+
 static const struct of_device_id mtk_pwm_of_match[] = {
-   { .compatible = "mediatek,mt7623-pwm" },
-   { }
+   {.compatible = "mediatek,mt2712-pwm", .data = _pwm_data},
+   {.compatible = "mediatek,mt7622-pwm", .data = _pwm_data},
+   {.compatible = "mediatek,mt7623-pwm", .data = _pwm_data},
+   {},
 };
 MODULE_DEVICE_TABLE(of, mtk_pwm_of_match);
 
-- 
1.7.9.5

[PATCH v2 2/6] pwm: mediatek: fix pwm source clock selection

[Zhi Mao]

In original code, the pwm output frequency is not correct
when set bit<3>=1 to PWMCON register.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 5c11bc7..d08b5b3 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -91,7 +91,7 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (clkdiv > 7)
return -EINVAL;
 
-   mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | BIT(3) | clkdiv);
+   mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
 
-- 
1.7.9.5

[PATCH v2 6/6] pwm: mediatek: add MT2712/MT7622 support

[Zhi Mao]

1. support multiple chip(MT2712, MT7622, MT7623)
2. add mtk_pwm_com_reg for match the registers of MT2712 pwm8
the register offset address of pwm8 for MT2712 is not fixed 0x40
and they are not the same as pwm0~6.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |   55 +++-
 1 file changed, 44 insertions(+), 11 deletions(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index e5f6425..a07ae19 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -40,11 +41,19 @@ enum {
MTK_CLK_PWM3,
MTK_CLK_PWM4,
MTK_CLK_PWM5,
+   MTK_CLK_PWM6,
+   MTK_CLK_PWM7,
+   MTK_CLK_PWM8,
MTK_CLK_MAX,
 };
 
-static const char * const mtk_pwm_clk_name[] = {
-   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4", "pwm5"
+static const char * const mtk_pwm_clk_name[MTK_CLK_MAX] = {
+   "main", "top", "pwm1", "pwm2", "pwm3", "pwm4",
+   "pwm5", "pwm6", "pwm7", "pwm8"
+};
+
+struct mtk_com_pwm_data {
+   unsigned int pwm_nums;
 };
 
 /**
@@ -57,6 +66,11 @@ struct mtk_pwm_chip {
struct pwm_chip chip;
void __iomem *regs;
struct clk *clks[MTK_CLK_MAX];
+   const struct mtk_com_pwm_data *data;
+};
+
+static const unsigned long mtk_pwm_com_reg[] = {
+   0x0010, 0x0050, 0x0090, 0x00d0, 0x0110, 0x0150, 0x0190, 0x0220
 };
 
 static inline struct mtk_pwm_chip *to_mtk_pwm_chip(struct pwm_chip *chip)
@@ -103,14 +117,14 @@ static void mtk_pwm_clk_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
 static inline u32 mtk_pwm_readl(struct mtk_pwm_chip *chip, unsigned int num,
unsigned int offset)
 {
-   return readl(chip->regs + 0x10 + (num * 0x40) + offset);
+   return readl(chip->regs + mtk_pwm_com_reg[num] + offset);
 }
 
 static inline void mtk_pwm_writel(struct mtk_pwm_chip *chip,
  unsigned int num, unsigned int offset,
  u32 value)
 {
-   writel(value, chip->regs + 0x10 + (num * 0x40) + offset);
+   writel(value, chip->regs + mtk_pwm_com_reg[num] + offset);
 }
 
 static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -193,23 +207,28 @@ static int mtk_pwm_probe(struct platform_device *pdev)
if (!pc)
return -ENOMEM;
 
+   pc->data = of_device_get_match_data(>dev);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pc->regs = devm_ioremap_resource(>dev, res);
if (IS_ERR(pc->regs))
return PTR_ERR(pc->regs);
 
-   for (i = 0; i < MTK_CLK_MAX; i++) {
+   for (i = 0; i < pc->data->pwm_nums + 2; i++) {
pc->clks[i] = devm_clk_get(>dev, mtk_pwm_clk_name[i]);
-   if (IS_ERR(pc->clks[i]))
+   if (IS_ERR(pc->clks[i])) {
+   dev_err(>dev, "[PWM] clock: %s fail: %ld\n",
+   mtk_pwm_clk_name[i], PTR_ERR(pc->clks[i]));
return PTR_ERR(pc->clks[i]);
+   }
}
 
-   platform_set_drvdata(pdev, pc);
-
pc->chip.dev = >dev;
pc->chip.ops = _pwm_ops;
pc->chip.base = -1;
-   pc->chip.npwm = 5;
+   pc->chip.npwm = pc->data->pwm_nums;
+
+   platform_set_drvdata(pdev, pc);
 
ret = pwmchip_add(>chip);
if (ret < 0) {
@@ -227,9 +246,23 @@ static int mtk_pwm_remove(struct platform_device *pdev)
return pwmchip_remove(>chip);
 }
 
+static const struct mtk_com_pwm_data mt2712_pwm_data = {
+   .pwm_nums = 8,
+};
+
+static const struct mtk_com_pwm_data mt7622_pwm_data = {
+   .pwm_nums = 6,
+};
+
+static const struct mtk_com_pwm_data mt7623_pwm_data = {
+   .pwm_nums = 5,
+};
+
 static const struct of_device_id mtk_pwm_of_match[] = {
-   { .compatible = "mediatek,mt7623-pwm" },
-   { }
+   {.compatible = "mediatek,mt2712-pwm", .data = _pwm_data},
+   {.compatible = "mediatek,mt7622-pwm", .data = _pwm_data},
+   {.compatible = "mediatek,mt7623-pwm", .data = _pwm_data},
+   {},
 };
 MODULE_DEVICE_TABLE(of, mtk_pwm_of_match);
 
-- 
1.7.9.5

[PATCH v2 2/6] pwm: mediatek: fix pwm source clock selection

[Zhi Mao]

In original code, the pwm output frequency is not correct
when set bit<3>=1 to PWMCON register.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 5c11bc7..d08b5b3 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -91,7 +91,7 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (clkdiv > 7)
return -EINVAL;
 
-   mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | BIT(3) | clkdiv);
+   mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
mtk_pwm_writel(pc, pwm->hwpwm, PWMTHRES, duty_ns / resolution);
 
-- 
1.7.9.5

[PATCH v2 5/6] pwm: mediatek: add PWM_CLK_DIV_MAX

[Zhi Mao]

Replace "7" with "PWM_CLK_DIV_MAX" in function:mtk_pwm_config()
to improve the code readablity.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 554a042..e5f6425 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -30,6 +30,8 @@
 #define PWMDWIDTH  0x2c
 #define PWMTHRES   0x30
 
+#define PWM_CLK_DIV_MAX7
+
 enum {
MTK_CLK_MAIN = 0,
MTK_CLK_TOP,
@@ -130,8 +132,10 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
clkdiv++;
}
 
-   if (clkdiv > 7)
+   if (clkdiv > PWM_CLK_DIV_MAX) {
+   dev_err(chip->dev, "period %d not supported\n", period_ns);
return -EINVAL;
+   }
 
mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
-- 
1.7.9.5

[PATCH v2 5/6] pwm: mediatek: add PWM_CLK_DIV_MAX

[Zhi Mao]

Replace "7" with "PWM_CLK_DIV_MAX" in function:mtk_pwm_config()
to improve the code readablity.

Signed-off-by: Zhi Mao 
---
 drivers/pwm/pwm-mediatek.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
index 554a042..e5f6425 100644
--- a/drivers/pwm/pwm-mediatek.c
+++ b/drivers/pwm/pwm-mediatek.c
@@ -30,6 +30,8 @@
 #define PWMDWIDTH  0x2c
 #define PWMTHRES   0x30
 
+#define PWM_CLK_DIV_MAX7
+
 enum {
MTK_CLK_MAIN = 0,
MTK_CLK_TOP,
@@ -130,8 +132,10 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
clkdiv++;
}
 
-   if (clkdiv > 7)
+   if (clkdiv > PWM_CLK_DIV_MAX) {
+   dev_err(chip->dev, "period %d not supported\n", period_ns);
return -EINVAL;
+   }
 
mtk_pwm_writel(pc, pwm->hwpwm, PWMCON, BIT(15) | clkdiv);
mtk_pwm_writel(pc, pwm->hwpwm, PWMDWIDTH, period_ns / resolution);
-- 
1.7.9.5

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

[Dan Williams]

On Wed, Jun 21, 2017 at 1:30 PM, Luck, Tony  wrote:
>> Persistent memory does have unpoisoning and would require this inverse
>> operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c
>> nvdimm_clear_poison().
>
> Nice.  Well this code will need to cooperate with that ... in particular if 
> the page
> is in an area that can be unpoisoned ... then we should do that *instead* of 
> marking
> the page not present (which breaks up huge/large pages and so affects 
> performance).
>
> Instead of calling it "arch_unmap_pfn" it could be called something like 
> arch_handle_poison()
> and do something like:
>
> void arch_handle_poison(unsigned long pfn)
> {
> if this is a pmem page && pmem_clear_poison(pfn)
> return
> if this is a nvdimm page && nvdimm_clear_poison(pfn)
> return
> /* can't clear, map out from 1:1 region */
> ... code from my patch ...
> }
>
> I'm just not sure how those first two "if" bits work ... particularly in 
> terms of CONFIG dependencies and system
> capabilities.  Perhaps each of pmem and nvdimm could register their unpoison 
> functions and this code could
> just call each in turn?

We don't unpoison pmem without new data to write in it's place. What
context is arch_handle_poison() called? Ideally we only "clear" poison
when we know we are trying to write zero over the poisoned range.

Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages

[Dan Williams]

On Wed, Jun 21, 2017 at 1:30 PM, Luck, Tony  wrote:
>> Persistent memory does have unpoisoning and would require this inverse
>> operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c
>> nvdimm_clear_poison().
>
> Nice.  Well this code will need to cooperate with that ... in particular if 
> the page
> is in an area that can be unpoisoned ... then we should do that *instead* of 
> marking
> the page not present (which breaks up huge/large pages and so affects 
> performance).
>
> Instead of calling it "arch_unmap_pfn" it could be called something like 
> arch_handle_poison()
> and do something like:
>
> void arch_handle_poison(unsigned long pfn)
> {
> if this is a pmem page && pmem_clear_poison(pfn)
> return
> if this is a nvdimm page && nvdimm_clear_poison(pfn)
> return
> /* can't clear, map out from 1:1 region */
> ... code from my patch ...
> }
>
> I'm just not sure how those first two "if" bits work ... particularly in 
> terms of CONFIG dependencies and system
> capabilities.  Perhaps each of pmem and nvdimm could register their unpoison 
> functions and this code could
> just call each in turn?

We don't unpoison pmem without new data to write in it's place. What
context is arch_handle_poison() called? Ideally we only "clear" poison
when we know we are trying to write zero over the poisoned range.

Re: [PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

On 23/06/17 07:11, Alex Williamson wrote:
> On Thu, 15 Jun 2017 15:48:42 +1000
> Alexey Kardashevskiy  wrote:
> 
>> Here is a patchset which Yongji was working on before
>> leaving IBM LTC. Since we still want to have this functionality
>> in the kernel (DPDK is the first user), here is a rebase
>> on the current upstream.
>>
>>
>> Current vfio-pci implementation disallows to mmap the page
>> containing MSI-X table in case that users can write directly
>> to MSI-X table and generate an incorrect MSIs.
>>
>> However, this will cause some performance issue when there
>> are some critical device registers in the same page as the
>> MSI-X table. We have to handle the mmio access to these
>> registers in QEMU emulation rather than in guest.
>>
>> To solve this issue, this series allows to expose MSI-X table
>> to userspace when hardware enables the capability of interrupt
>> remapping which can ensure that a given PCI device can only
>> shoot the MSIs assigned for it. And we introduce a new bus_flags
>> PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
>> for different archs.
>>
>> The patch 3 are based on the proposed patchset[1].
>>
>> Changelog
>> v3:
>> - rebased on the current upstream
> 
> There's something not forthcoming here, the last version I see from
> Yongji is this one:
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2016-June/017245.html
> 
> Which was a 6-patch series where patches 2-4 tried to apply
> PCI_BUS_FLAGS_MSI_REMAP for cases that supported other platforms.  That
> doesn't exist here, so it's not simply a rebase.  Patch 1/ seems to
> equate this new flag to the IOMMU capability IOMMU_CAP_INTR_REMAP, but
> nothing is done here to match them together.  That patch also mentions
> the work Eric has done for similar features on ARM, but again those
> patches are dropped.  It seems like an incomplete feature now.  Thanks,


Thanks! I suspected this is not the latest but could not find anything
better than we use internally for tests, and I could not reach Yongji for
comments whether this was the latest update.

As I am reading the patches, I notice that the "msi remap" term is used all
over the place. While this remapping capability may be the case for x86/arm
(and therefore the IOMMU_CAP_INTR_REMAP flag makes sense), powernv does not
do remapping but provides hardware isolation. When we are allowing MSIX BAR
mapping to the userspace - the isolation is what we really care about. Will
it make sense to rename PCI_BUS_FLAGS_MSI_REMAP to
PCI_BUS_FLAGS_MSI_ISOLATED ?

Another thing - the patchset enables PCI_BUS_FLAGS_MSI_REMAP when IOMMU
just advertises IOMMU_CAP_INTR_REMAP, not necessarily uses it, should the
patchset actually look at something like irq_remapping_enabled in
drivers/iommu/amd_iommu.c instead?



> 
> Alex
> 
>> v2:
>> - Make the commit log more clear
>> - Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
>>   so that we could clearly know what the function does
>> - Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
>>   of iommu_bus_notifier()
>> - Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
>>   table so that we can know whether we allow to mmap MSI-X table
>>   in QEMU
>>
>> [1] 
>> https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html
>>
>>
>> This is based on sha1
>> 63f700aab4c1 Linus Torvalds "Merge tag 'xtensa-20170612' of 
>> git://github.com/jcmvbkbc/linux-xtensa".
>>
>> Please comment. Thanks.
>>
>>
>>
>> Yongji Xie (3):
>>   PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
>>   pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
>>   vfio-pci: Allow to expose MSI-X table to userspace if interrupt
>> remapping is enabled
>>
>>  include/linux/pci.h   |  1 +
>>  arch/powerpc/platforms/powernv/pci-ioda.c |  8 
>>  drivers/vfio/pci/vfio_pci.c   | 18 +++---
>>  drivers/vfio/pci/vfio_pci_rdwr.c  |  3 ++-
>>  4 files changed, 26 insertions(+), 4 deletions(-)
>>
> 


-- 
Alexey

Re: [PATCH kernel 0/3 REPOST] vfio-pci: Add support for mmapping MSI-X table

[Alexey Kardashevskiy]

On 23/06/17 07:11, Alex Williamson wrote:
> On Thu, 15 Jun 2017 15:48:42 +1000
> Alexey Kardashevskiy  wrote:
> 
>> Here is a patchset which Yongji was working on before
>> leaving IBM LTC. Since we still want to have this functionality
>> in the kernel (DPDK is the first user), here is a rebase
>> on the current upstream.
>>
>>
>> Current vfio-pci implementation disallows to mmap the page
>> containing MSI-X table in case that users can write directly
>> to MSI-X table and generate an incorrect MSIs.
>>
>> However, this will cause some performance issue when there
>> are some critical device registers in the same page as the
>> MSI-X table. We have to handle the mmio access to these
>> registers in QEMU emulation rather than in guest.
>>
>> To solve this issue, this series allows to expose MSI-X table
>> to userspace when hardware enables the capability of interrupt
>> remapping which can ensure that a given PCI device can only
>> shoot the MSIs assigned for it. And we introduce a new bus_flags
>> PCI_BUS_FLAGS_MSI_REMAP to test this capability on PCI side
>> for different archs.
>>
>> The patch 3 are based on the proposed patchset[1].
>>
>> Changelog
>> v3:
>> - rebased on the current upstream
> 
> There's something not forthcoming here, the last version I see from
> Yongji is this one:
> 
> https://lists.linuxfoundation.org/pipermail/iommu/2016-June/017245.html
> 
> Which was a 6-patch series where patches 2-4 tried to apply
> PCI_BUS_FLAGS_MSI_REMAP for cases that supported other platforms.  That
> doesn't exist here, so it's not simply a rebase.  Patch 1/ seems to
> equate this new flag to the IOMMU capability IOMMU_CAP_INTR_REMAP, but
> nothing is done here to match them together.  That patch also mentions
> the work Eric has done for similar features on ARM, but again those
> patches are dropped.  It seems like an incomplete feature now.  Thanks,


Thanks! I suspected this is not the latest but could not find anything
better than we use internally for tests, and I could not reach Yongji for
comments whether this was the latest update.

As I am reading the patches, I notice that the "msi remap" term is used all
over the place. While this remapping capability may be the case for x86/arm
(and therefore the IOMMU_CAP_INTR_REMAP flag makes sense), powernv does not
do remapping but provides hardware isolation. When we are allowing MSIX BAR
mapping to the userspace - the isolation is what we really care about. Will
it make sense to rename PCI_BUS_FLAGS_MSI_REMAP to
PCI_BUS_FLAGS_MSI_ISOLATED ?

Another thing - the patchset enables PCI_BUS_FLAGS_MSI_REMAP when IOMMU
just advertises IOMMU_CAP_INTR_REMAP, not necessarily uses it, should the
patchset actually look at something like irq_remapping_enabled in
drivers/iommu/amd_iommu.c instead?



> 
> Alex
> 
>> v2:
>> - Make the commit log more clear
>> - Replace pci_bus_check_msi_remapping() with pci_bus_msi_isolated()
>>   so that we could clearly know what the function does
>> - Set PCI_BUS_FLAGS_MSI_REMAP in pci_create_root_bus() instead
>>   of iommu_bus_notifier()
>> - Reserve VFIO_REGION_INFO_FLAG_CAPS when we allow to mmap MSI-X
>>   table so that we can know whether we allow to mmap MSI-X table
>>   in QEMU
>>
>> [1] 
>> https://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg1138820.html
>>
>>
>> This is based on sha1
>> 63f700aab4c1 Linus Torvalds "Merge tag 'xtensa-20170612' of 
>> git://github.com/jcmvbkbc/linux-xtensa".
>>
>> Please comment. Thanks.
>>
>>
>>
>> Yongji Xie (3):
>>   PCI: Add a new PCI_BUS_FLAGS_MSI_REMAP flag
>>   pci-ioda: Set PCI_BUS_FLAGS_MSI_REMAP for IODA host bridge
>>   vfio-pci: Allow to expose MSI-X table to userspace if interrupt
>> remapping is enabled
>>
>>  include/linux/pci.h   |  1 +
>>  arch/powerpc/platforms/powernv/pci-ioda.c |  8 
>>  drivers/vfio/pci/vfio_pci.c   | 18 +++---
>>  drivers/vfio/pci/vfio_pci_rdwr.c  |  3 ++-
>>  4 files changed, 26 insertions(+), 4 deletions(-)
>>
> 


-- 
Alexey

[PATCH 11/11] ARM64: dts: rockchip: Enable gmac2phy for rk3328-evb

[David Wu]

Let's enable the gmac2phy, make the gmac2phy work on
the rk3328-evb board.

Signed-off-by: David Wu 
---
 arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index cf27239..b9f36da 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -50,6 +50,23 @@
chosen {
stdout-path = "serial2:150n8";
};
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   phy-supply = <_phy>;
+   clock_in_out = "output";
+   assigned-clocks = < SCLK_MAC2PHY_SRC>;
+   assigned-clock-rate = <5000>;
+   assigned-clocks = < SCLK_MAC2PHY>;
+   assigned-clock-parents = < SCLK_MAC2PHY_SRC>;
+   status = "okay";
 };
 
  {
-- 
1.9.1

[PATCH 11/11] ARM64: dts: rockchip: Enable gmac2phy for rk3328-evb

[David Wu]

Let's enable the gmac2phy, make the gmac2phy work on
the rk3328-evb board.

Signed-off-by: David Wu 
---
 arch/arm64/boot/dts/rockchip/rk3328-evb.dts | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
index cf27239..b9f36da 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
@@ -50,6 +50,23 @@
chosen {
stdout-path = "serial2:150n8";
};
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   phy-supply = <_phy>;
+   clock_in_out = "output";
+   assigned-clocks = < SCLK_MAC2PHY_SRC>;
+   assigned-clock-rate = <5000>;
+   assigned-clocks = < SCLK_MAC2PHY>;
+   assigned-clock-parents = < SCLK_MAC2PHY_SRC>;
+   status = "okay";
 };
 
  {
-- 
1.9.1

[PATCH] iommu/arm-smmu-v3, acpi: Add temporary Cavium SMMU-V3 IORT model number definitions

[Robert Richter]

On 23.06.17 06:55:41, Robert Richter wrote:
> On 22.06.17 22:04:37, Lorenzo Pieralisi wrote:
> > On Thu, Jun 22, 2017 at 09:35:35PM +0200, Robert Richter wrote:
> > > On 22.06.17 19:58:22, Will Deacon wrote:
> > > > On Thu, Jun 22, 2017 at 07:22:57PM +0100, Will Deacon wrote:
> > > > > On Thu, Jun 22, 2017 at 05:35:35PM +0530, Geetha sowjanya wrote:
> > > > > > Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas.
> > > > > > 1. Errata ID #74
> > > > > >SMMU register alias Page 1 is not implemented
> > > > > > 2. Errata ID #126
> > > > > >SMMU doesnt support unique IRQ lines and also MSI for gerror,
> > > > > >eventq and cmdq-sync
> > > > > > 
> > > > > > The following patchset does software workaround for these two 
> > > > > > erratas.
> > > > > 
> > > > > I've picked up the first two patches, and left comments on the final 
> > > > > patch.
> > > > 
> > > > ... except that it doesn't build:
> > > > 
> > > > 
> > > > drivers/acpi/arm64/iort.c: In function ‘arm_smmu_v3_resource_size’:
> > > > drivers/acpi/arm64/iort.c:837:21: error: 
> > > > ‘ACPI_IORT_SMMU_V3_CAVIUM_CN99XX’ undeclared (first use in this 
> > > > function)
> > > >   if (smmu->model == ACPI_IORT_SMMU_V3_CAVIUM_CN99XX)
> > > >  ^
> > > > drivers/acpi/arm64/iort.c:837:21: note: each undeclared identifier is 
> > > > reported only once for each function it appears in
> > > > make[4]: *** [drivers/acpi/arm64/iort.o] Error 1
> > > > 
> > > > 
> > > > I don't see ACPI_IORT_SMMU_V3_CAVIUM_CN99XX defined, even in linux-next.
> > > > 
> > > > What's the plan here?
> > > 
> > > It is defined already in acpica and we actually waiting for the acpi
> > > maintainers to include it:
> > > 
> > >  https://github.com/acpica/acpica/commit/d00a4eb86e64
> > > 
> > > We could add
> > > 
> > > /* Until ACPICA headers cover IORT rev. C */
> > > #ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
> > > #define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX   0x2
> > > #endif
> > > 
> > > to both files:
> > > 
> > >  drivers/acpi/arm64/iort.c
> > >  drivers/iommu/arm-smmu-v3.c
> > > 
> > 
> > I thought it was a solved problem (and that the IORT patch was based
> > on Robin's workaround) but I was clearly wrong and I apologise to
> > Will about this.
> > 
> > FWIW, you could add the define in include/linux/acpi_iort.h and I will
> > remove it whenever ACPICA changes make it into the kernel.
> 
> Adding it there will still let depend us on acpi maintainers, while I
> think the over 2 files might go through arm64 tree smoothly. A change
> in acpi_iort.h also adds the definition to other archs and I don't
> think that adding arch #ifdefs to avoid that are welcome in that
> header file too.
> 
> I am going to resend my patch below with an improved wording.

Here it comes:

>From d210b4c540bc4adcebd51d5a87437d2049649e94 Mon Sep 17 00:00:00 2001
From: Robert Richter 
Date: Thu, 22 Jun 2017 21:20:54 +0200
Subject: [PATCH] iommu/arm-smmu-v3, acpi: Add temporary Cavium SMMU-V3 IORT
 model number definitions

The model number is already defined in acpica and we are actually
waiting for the acpi maintainers to include it:

 https://github.com/acpica/acpica/commit/d00a4eb86e64

Adding those temporary definitions until the change makes it into
include/acpi/actbl2.h. Once that is done this patch can be reverted.

Signed-off-by: Robert Richter 
---
 drivers/acpi/arm64/iort.c   | 5 +
 drivers/iommu/arm-smmu-v3.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 797b28dc7b34..15491237a657 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -31,6 +31,11 @@
 #define IORT_IOMMU_TYPE((1 << ACPI_IORT_NODE_SMMU) |   \
(1 << ACPI_IORT_NODE_SMMU_V3))
 
+/* Until ACPICA headers cover IORT rev. C */
+#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
+#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
+#endif
+
 struct iort_its_msi_chip {
struct list_headlist;
struct fwnode_handle*fw_node;
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 380969aa60d5..c759dfa7442d 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -412,6 +412,11 @@
 #define MSI_IOVA_BASE  0x800
 #define MSI_IOVA_LENGTH0x10
 
+/* Until ACPICA headers cover IORT rev. C */
+#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
+#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
+#endif
+
 static bool disable_bypass;
 module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
 MODULE_PARM_DESC(disable_bypass,
-- 
2.11.0

[PATCH 10/11] ARM64: dts: rockchip: Add gmac2phy node support for rk3328

[David Wu]

The gmac2phy controller of rk3328 is connected to internal phy
directly inside, add the node for the internal phy support.

Signed-off-by: David Wu 
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 7e69f1f..29b3800 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -63,6 +63,8 @@
i2c1 = 
i2c2 = 
i2c3 = 
+   ethernet0 = 
+   ethernet1 = 
};
 
cpus {
@@ -391,6 +393,29 @@
status = "disabled";
};
 
+   gmac2phy: eth@ff55 {
+   compatible = "rockchip,rk3328-gmac";
+   reg = <0x0 0xff55 0x0 0x1>;
+   rockchip,grf = <>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < SCLK_MAC2PHY_SRC>, < SCLK_MAC2PHY_RXTX>,
+< SCLK_MAC2PHY_RXTX>, < SCLK_MAC2PHY_REF>,
+< ACLK_MAC2PHY>, < PCLK_MAC2PHY>,
+< SCLK_MAC2PHY_OUT>;
+   clock-names = "stmmaceth", "mac_clk_rx",
+ "mac_clk_tx", "clk_mac_ref",
+ "aclk_mac", "pclk_mac",
+ "clk_macphy";
+   resets = < SRST_GMAC2PHY_A>, < SRST_MACPHY>;
+   reset-names = "stmmaceth", "mac-phy";
+   phy-mode = "rmii";
+   phy-type = "internal";
+   pinctrl-names = "default";
+   pinctrl-0 = <_rxm1 _linkm1>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@ff811000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
1.9.1

[PATCH] iommu/arm-smmu-v3, acpi: Add temporary Cavium SMMU-V3 IORT model number definitions

[Robert Richter]

On 23.06.17 06:55:41, Robert Richter wrote:
> On 22.06.17 22:04:37, Lorenzo Pieralisi wrote:
> > On Thu, Jun 22, 2017 at 09:35:35PM +0200, Robert Richter wrote:
> > > On 22.06.17 19:58:22, Will Deacon wrote:
> > > > On Thu, Jun 22, 2017 at 07:22:57PM +0100, Will Deacon wrote:
> > > > > On Thu, Jun 22, 2017 at 05:35:35PM +0530, Geetha sowjanya wrote:
> > > > > > Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas.
> > > > > > 1. Errata ID #74
> > > > > >SMMU register alias Page 1 is not implemented
> > > > > > 2. Errata ID #126
> > > > > >SMMU doesnt support unique IRQ lines and also MSI for gerror,
> > > > > >eventq and cmdq-sync
> > > > > > 
> > > > > > The following patchset does software workaround for these two 
> > > > > > erratas.
> > > > > 
> > > > > I've picked up the first two patches, and left comments on the final 
> > > > > patch.
> > > > 
> > > > ... except that it doesn't build:
> > > > 
> > > > 
> > > > drivers/acpi/arm64/iort.c: In function ‘arm_smmu_v3_resource_size’:
> > > > drivers/acpi/arm64/iort.c:837:21: error: 
> > > > ‘ACPI_IORT_SMMU_V3_CAVIUM_CN99XX’ undeclared (first use in this 
> > > > function)
> > > >   if (smmu->model == ACPI_IORT_SMMU_V3_CAVIUM_CN99XX)
> > > >  ^
> > > > drivers/acpi/arm64/iort.c:837:21: note: each undeclared identifier is 
> > > > reported only once for each function it appears in
> > > > make[4]: *** [drivers/acpi/arm64/iort.o] Error 1
> > > > 
> > > > 
> > > > I don't see ACPI_IORT_SMMU_V3_CAVIUM_CN99XX defined, even in linux-next.
> > > > 
> > > > What's the plan here?
> > > 
> > > It is defined already in acpica and we actually waiting for the acpi
> > > maintainers to include it:
> > > 
> > >  https://github.com/acpica/acpica/commit/d00a4eb86e64
> > > 
> > > We could add
> > > 
> > > /* Until ACPICA headers cover IORT rev. C */
> > > #ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
> > > #define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX   0x2
> > > #endif
> > > 
> > > to both files:
> > > 
> > >  drivers/acpi/arm64/iort.c
> > >  drivers/iommu/arm-smmu-v3.c
> > > 
> > 
> > I thought it was a solved problem (and that the IORT patch was based
> > on Robin's workaround) but I was clearly wrong and I apologise to
> > Will about this.
> > 
> > FWIW, you could add the define in include/linux/acpi_iort.h and I will
> > remove it whenever ACPICA changes make it into the kernel.
> 
> Adding it there will still let depend us on acpi maintainers, while I
> think the over 2 files might go through arm64 tree smoothly. A change
> in acpi_iort.h also adds the definition to other archs and I don't
> think that adding arch #ifdefs to avoid that are welcome in that
> header file too.
> 
> I am going to resend my patch below with an improved wording.

Here it comes:

>From d210b4c540bc4adcebd51d5a87437d2049649e94 Mon Sep 17 00:00:00 2001
From: Robert Richter 
Date: Thu, 22 Jun 2017 21:20:54 +0200
Subject: [PATCH] iommu/arm-smmu-v3, acpi: Add temporary Cavium SMMU-V3 IORT
 model number definitions

The model number is already defined in acpica and we are actually
waiting for the acpi maintainers to include it:

 https://github.com/acpica/acpica/commit/d00a4eb86e64

Adding those temporary definitions until the change makes it into
include/acpi/actbl2.h. Once that is done this patch can be reverted.

Signed-off-by: Robert Richter 
---
 drivers/acpi/arm64/iort.c   | 5 +
 drivers/iommu/arm-smmu-v3.c | 5 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 797b28dc7b34..15491237a657 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -31,6 +31,11 @@
 #define IORT_IOMMU_TYPE((1 << ACPI_IORT_NODE_SMMU) |   \
(1 << ACPI_IORT_NODE_SMMU_V3))
 
+/* Until ACPICA headers cover IORT rev. C */
+#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
+#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
+#endif
+
 struct iort_its_msi_chip {
struct list_headlist;
struct fwnode_handle*fw_node;
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 380969aa60d5..c759dfa7442d 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -412,6 +412,11 @@
 #define MSI_IOVA_BASE  0x800
 #define MSI_IOVA_LENGTH0x10
 
+/* Until ACPICA headers cover IORT rev. C */
+#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
+#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
+#endif
+
 static bool disable_bypass;
 module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
 MODULE_PARM_DESC(disable_bypass,
-- 
2.11.0

[PATCH 10/11] ARM64: dts: rockchip: Add gmac2phy node support for rk3328

[David Wu]

The gmac2phy controller of rk3328 is connected to internal phy
directly inside, add the node for the internal phy support.

Signed-off-by: David Wu 
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 7e69f1f..29b3800 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -63,6 +63,8 @@
i2c1 = 
i2c2 = 
i2c3 = 
+   ethernet0 = 
+   ethernet1 = 
};
 
cpus {
@@ -391,6 +393,29 @@
status = "disabled";
};
 
+   gmac2phy: eth@ff55 {
+   compatible = "rockchip,rk3328-gmac";
+   reg = <0x0 0xff55 0x0 0x1>;
+   rockchip,grf = <>;
+   interrupts = ;
+   interrupt-names = "macirq";
+   clocks = < SCLK_MAC2PHY_SRC>, < SCLK_MAC2PHY_RXTX>,
+< SCLK_MAC2PHY_RXTX>, < SCLK_MAC2PHY_REF>,
+< ACLK_MAC2PHY>, < PCLK_MAC2PHY>,
+< SCLK_MAC2PHY_OUT>;
+   clock-names = "stmmaceth", "mac_clk_rx",
+ "mac_clk_tx", "clk_mac_ref",
+ "aclk_mac", "pclk_mac",
+ "clk_macphy";
+   resets = < SRST_GMAC2PHY_A>, < SRST_MACPHY>;
+   reset-names = "stmmaceth", "mac-phy";
+   phy-mode = "rmii";
+   phy-type = "internal";
+   pinctrl-names = "default";
+   pinctrl-0 = <_rxm1 _linkm1>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@ff811000 {
compatible = "arm,gic-400";
#interrupt-cells = <3>;
-- 
1.9.1

[PATCH 09/11] ARM: dts: rk3228-evb: Enable the internal phy for gmac

[David Wu]

This patch enables the internal phy for rk3228 evb board
by default.
To use the external 1000M phy on evb board, need to make
some switch of evb board to be on.

Signed-off-by: David Wu 
---
 arch/arm/boot/dts/rk3228-evb.dts | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index 5883433..c4002da 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -50,6 +50,16 @@
device_type = "memory";
reg = <0x6000 0x4000>;
};
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   regulator-name = "vcc_phy";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
 };
 
  {
@@ -60,6 +70,16 @@
status = "okay";
 };
 
+ {
+   assigned-clocks = < SCLK_MAC_SRC>;
+   assigned-clock-rates = <5000>;
+   clock_in_out = "output";
+   phy-supply = <_phy>;
+   phy-mode = "rmii";
+   phy-type = "internal";
+   status = "okay";
+};
+
  {
status = "okay";
 
-- 
1.9.1

[PATCH 09/11] ARM: dts: rk3228-evb: Enable the internal phy for gmac

[David Wu]

This patch enables the internal phy for rk3228 evb board
by default.
To use the external 1000M phy on evb board, need to make
some switch of evb board to be on.

Signed-off-by: David Wu 
---
 arch/arm/boot/dts/rk3228-evb.dts | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
index 5883433..c4002da 100644
--- a/arch/arm/boot/dts/rk3228-evb.dts
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -50,6 +50,16 @@
device_type = "memory";
reg = <0x6000 0x4000>;
};
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   regulator-name = "vcc_phy";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
 };
 
  {
@@ -60,6 +70,16 @@
status = "okay";
 };
 
+ {
+   assigned-clocks = < SCLK_MAC_SRC>;
+   assigned-clock-rates = <5000>;
+   clock_in_out = "output";
+   phy-supply = <_phy>;
+   phy-mode = "rmii";
+   phy-type = "internal";
+   status = "okay";
+};
+
  {
status = "okay";
 
-- 
1.9.1

[PATCH 08/11] ARM: dts: rk322x: Add support internal phy for gmac

[David Wu]

This patch adds internal mac phy clock and internal mac phy reset
for rk gmac using.

Signed-off-by: David Wu 
---
 arch/arm/boot/dts/rk322x.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 48a0c1c..203a583 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -427,13 +427,13 @@
clocks = < SCLK_MAC>, < SCLK_MAC_RX>,
< SCLK_MAC_TX>, < SCLK_MAC_REF>,
< SCLK_MAC_REFOUT>, < ACLK_GMAC>,
-   < PCLK_GMAC>;
+   < PCLK_GMAC>, < SCLK_MAC_PHY>;
clock-names = "stmmaceth", "mac_clk_rx",
"mac_clk_tx", "clk_mac_ref",
"clk_mac_refout", "aclk_mac",
-   "pclk_mac";
-   resets = < SRST_GMAC>;
-   reset-names = "stmmaceth";
+   "pclk_mac", "clk_macphy";
+   resets = < SRST_GMAC>, < SRST_MACPHY>;
+   reset-names = "stmmaceth", "mac-phy";
rockchip,grf = <>;
status = "disabled";
};
-- 
1.9.1

[PATCH 08/11] ARM: dts: rk322x: Add support internal phy for gmac

[David Wu]

This patch adds internal mac phy clock and internal mac phy reset
for rk gmac using.

Signed-off-by: David Wu 
---
 arch/arm/boot/dts/rk322x.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi
index 48a0c1c..203a583 100644
--- a/arch/arm/boot/dts/rk322x.dtsi
+++ b/arch/arm/boot/dts/rk322x.dtsi
@@ -427,13 +427,13 @@
clocks = < SCLK_MAC>, < SCLK_MAC_RX>,
< SCLK_MAC_TX>, < SCLK_MAC_REF>,
< SCLK_MAC_REFOUT>, < ACLK_GMAC>,
-   < PCLK_GMAC>;
+   < PCLK_GMAC>, < SCLK_MAC_PHY>;
clock-names = "stmmaceth", "mac_clk_rx",
"mac_clk_tx", "clk_mac_ref",
"clk_mac_refout", "aclk_mac",
-   "pclk_mac";
-   resets = < SRST_GMAC>;
-   reset-names = "stmmaceth";
+   "pclk_mac", "clk_macphy";
+   resets = < SRST_GMAC>, < SRST_MACPHY>;
+   reset-names = "stmmaceth", "mac-phy";
rockchip,grf = <>;
status = "disabled";
};
-- 
1.9.1

[PATCH 07/11] net: stmmac: dwmac-rk: Add internal phy supprot for rk3328

[David Wu]

There are two mac controllers in the rk3328, the one connects
to external phy, and the other one connects to internal phy.
Like the mac of external phy, the internal phy's mac also needs to
configure the related mac registers at GRF.

Signed-off-by: David Wu 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 90e1fc8..c4c58a2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -323,6 +323,8 @@ static void rk3288_set_rmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
 
 #define RK3328_GRF_MAC_CON00x0900
 #define RK3328_GRF_MAC_CON10x0904
+#define RK3328_GRF_MAC_CON20x0908
+#define RK3328_GRF_MACPHY_CON1 0xb04
 
 /* RK3328_GRF_MAC_CON0 */
 #define RK3328_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 7)
@@ -349,6 +351,9 @@ static void rk3288_set_rmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
 #define RK3328_GMAC_RXCLK_DLY_ENABLE   GRF_BIT(1)
 #define RK3328_GMAC_RXCLK_DLY_DISABLE  GRF_CLR_BIT(0)
 
+/* RK3328_GRF_MACPHY_CON1 */
+#define RK3328_MACPHY_RMII_MODEGRF_BIT(9)
+
 static void rk3328_set_to_rgmii(struct rk_priv_data *bsp_priv,
int tx_delay, int rx_delay)
 {
@@ -373,13 +378,17 @@ static void rk3328_set_to_rgmii(struct rk_priv_data 
*bsp_priv,
 static void rk3328_set_to_rmii(struct rk_priv_data *bsp_priv)
 {
struct device *dev = _priv->pdev->dev;
+   unsigned int reg;
 
if (IS_ERR(bsp_priv->grf)) {
dev_err(dev, "Missing rockchip,grf property\n");
return;
}
 
-   regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1,
+   reg = bsp_priv->internal_phy ? RK3328_GRF_MAC_CON2 :
+ RK3328_GRF_MAC_CON1;
+
+   regmap_write(bsp_priv->grf, reg,
 RK3328_GMAC_PHY_INTF_SEL_RMII |
 RK3328_GMAC_RMII_MODE);
 }
@@ -409,29 +418,40 @@ static void rk3328_set_rgmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
 static void rk3328_set_rmii_speed(struct rk_priv_data *bsp_priv, int speed)
 {
struct device *dev = _priv->pdev->dev;
+   unsigned int reg;
 
if (IS_ERR(bsp_priv->grf)) {
dev_err(dev, "Missing rockchip,grf property\n");
return;
}
 
+   reg = bsp_priv->internal_phy ? RK3328_GRF_MAC_CON2 :
+ RK3328_GRF_MAC_CON1;
+
if (speed == 10)
-   regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1,
+   regmap_write(bsp_priv->grf, reg,
 RK3328_GMAC_RMII_CLK_2_5M |
 RK3328_GMAC_SPEED_10M);
else if (speed == 100)
-   regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1,
+   regmap_write(bsp_priv->grf, reg,
 RK3328_GMAC_RMII_CLK_25M |
 RK3328_GMAC_SPEED_100M);
else
dev_err(dev, "unknown speed value for RMII! speed=%d", speed);
 }
 
+static void rk3328_internal_phy_powerup(struct rk_priv_data *priv)
+{
+   regmap_write(priv->grf, RK3328_GRF_MACPHY_CON1,
+RK3328_MACPHY_RMII_MODE);
+}
+
 static const struct rk_gmac_ops rk3328_ops = {
.set_to_rgmii = rk3328_set_to_rgmii,
.set_to_rmii = rk3328_set_to_rmii,
.set_rgmii_speed = rk3328_set_rgmii_speed,
.set_rmii_speed = rk3328_set_rmii_speed,
+   .internal_phy_powerup =  rk3328_internal_phy_powerup,
 };
 
 #define RK3366_GRF_SOC_CON60x0418
-- 
1.9.1

[PATCH 07/11] net: stmmac: dwmac-rk: Add internal phy supprot for rk3328

[David Wu]

There are two mac controllers in the rk3328, the one connects
to external phy, and the other one connects to internal phy.
Like the mac of external phy, the internal phy's mac also needs to
configure the related mac registers at GRF.

Signed-off-by: David Wu 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 90e1fc8..c4c58a2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -323,6 +323,8 @@ static void rk3288_set_rmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
 
 #define RK3328_GRF_MAC_CON00x0900
 #define RK3328_GRF_MAC_CON10x0904
+#define RK3328_GRF_MAC_CON20x0908
+#define RK3328_GRF_MACPHY_CON1 0xb04
 
 /* RK3328_GRF_MAC_CON0 */
 #define RK3328_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 7)
@@ -349,6 +351,9 @@ static void rk3288_set_rmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
 #define RK3328_GMAC_RXCLK_DLY_ENABLE   GRF_BIT(1)
 #define RK3328_GMAC_RXCLK_DLY_DISABLE  GRF_CLR_BIT(0)
 
+/* RK3328_GRF_MACPHY_CON1 */
+#define RK3328_MACPHY_RMII_MODEGRF_BIT(9)
+
 static void rk3328_set_to_rgmii(struct rk_priv_data *bsp_priv,
int tx_delay, int rx_delay)
 {
@@ -373,13 +378,17 @@ static void rk3328_set_to_rgmii(struct rk_priv_data 
*bsp_priv,
 static void rk3328_set_to_rmii(struct rk_priv_data *bsp_priv)
 {
struct device *dev = _priv->pdev->dev;
+   unsigned int reg;
 
if (IS_ERR(bsp_priv->grf)) {
dev_err(dev, "Missing rockchip,grf property\n");
return;
}
 
-   regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1,
+   reg = bsp_priv->internal_phy ? RK3328_GRF_MAC_CON2 :
+ RK3328_GRF_MAC_CON1;
+
+   regmap_write(bsp_priv->grf, reg,
 RK3328_GMAC_PHY_INTF_SEL_RMII |
 RK3328_GMAC_RMII_MODE);
 }
@@ -409,29 +418,40 @@ static void rk3328_set_rgmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
 static void rk3328_set_rmii_speed(struct rk_priv_data *bsp_priv, int speed)
 {
struct device *dev = _priv->pdev->dev;
+   unsigned int reg;
 
if (IS_ERR(bsp_priv->grf)) {
dev_err(dev, "Missing rockchip,grf property\n");
return;
}
 
+   reg = bsp_priv->internal_phy ? RK3328_GRF_MAC_CON2 :
+ RK3328_GRF_MAC_CON1;
+
if (speed == 10)
-   regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1,
+   regmap_write(bsp_priv->grf, reg,
 RK3328_GMAC_RMII_CLK_2_5M |
 RK3328_GMAC_SPEED_10M);
else if (speed == 100)
-   regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1,
+   regmap_write(bsp_priv->grf, reg,
 RK3328_GMAC_RMII_CLK_25M |
 RK3328_GMAC_SPEED_100M);
else
dev_err(dev, "unknown speed value for RMII! speed=%d", speed);
 }
 
+static void rk3328_internal_phy_powerup(struct rk_priv_data *priv)
+{
+   regmap_write(priv->grf, RK3328_GRF_MACPHY_CON1,
+RK3328_MACPHY_RMII_MODE);
+}
+
 static const struct rk_gmac_ops rk3328_ops = {
.set_to_rgmii = rk3328_set_to_rgmii,
.set_to_rmii = rk3328_set_to_rmii,
.set_rgmii_speed = rk3328_set_rgmii_speed,
.set_rmii_speed = rk3328_set_rmii_speed,
+   .internal_phy_powerup =  rk3328_internal_phy_powerup,
 };
 
 #define RK3366_GRF_SOC_CON60x0418
-- 
1.9.1

[PATCH] char: virtio_console: constify port_attribute_group

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
  13775 656  88   1451938b7 drivers/char/virtio_console.o

File size After adding 'const':
   textdata bss dec hex filename
  13839 592  88   1451938b7 drivers/char/virtio_console.o

Signed-off-by: Arvind Yadav 
---
 drivers/char/virtio_console.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index ad843eb..06bd635 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1308,7 +1308,7 @@ static ssize_t show_port_name(struct device *dev,
NULL
 };
 
-static struct attribute_group port_attribute_group = {
+static const struct attribute_group port_attribute_group = {
.name = NULL,   /* put in device directory */
.attrs = port_sysfs_entries,
 };
-- 
1.9.1

[PATCH] char: virtio_console: constify port_attribute_group

[Arvind Yadav]

File size before:
   textdata bss dec hex filename
  13775 656  88   1451938b7 drivers/char/virtio_console.o

File size After adding 'const':
   textdata bss dec hex filename
  13839 592  88   1451938b7 drivers/char/virtio_console.o

Signed-off-by: Arvind Yadav 
---
 drivers/char/virtio_console.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index ad843eb..06bd635 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1308,7 +1308,7 @@ static ssize_t show_port_name(struct device *dev,
NULL
 };
 
-static struct attribute_group port_attribute_group = {
+static const struct attribute_group port_attribute_group = {
.name = NULL,   /* put in device directory */
.attrs = port_sysfs_entries,
 };
-- 
1.9.1

[PATCH 06/11] net: stmmac: dwmac-rk: Add internal phy support for rk3228

[David Wu]

There is only one mac controller in rk3228, which could connect to
external phy or internal phy, use the grf_com_mux bit15 to route
external/internal phy.

Change-Id: I3a366677047b8032eb535abb0c3e56fa7722aa2e
Signed-off-by: David Wu 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index c1a1413..90e1fc8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -86,6 +86,8 @@ struct rk_priv_data {
 #define RK3228_GRF_MAC_CON00x0900
 #define RK3228_GRF_MAC_CON10x0904
 
+#define RK3228_GRF_CON_MUX 0x50
+
 /* RK3228_GRF_MAC_CON0 */
 #define RK3228_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 7)
 #define RK3228_GMAC_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 0)
@@ -111,6 +113,9 @@ struct rk_priv_data {
 #define RK3228_GMAC_RXCLK_DLY_ENABLE   GRF_BIT(1)
 #define RK3228_GMAC_RXCLK_DLY_DISABLE  GRF_CLR_BIT(1)
 
+/* RK3228_GRF_COM_MUX */
+#define RK3228_GRF_CON_MUX_GMAC_INTERNAL_PHY   GRF_BIT(15)
+
 static void rk3228_set_to_rgmii(struct rk_priv_data *bsp_priv,
int tx_delay, int rx_delay)
 {
@@ -191,11 +196,18 @@ static void rk3228_set_rmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
dev_err(dev, "unknown speed value for RMII! speed=%d", speed);
 }
 
+static void rk3228_internal_phy_powerup(struct rk_priv_data *priv)
+{
+   regmap_write(priv->grf, RK3228_GRF_CON_MUX,
+RK3228_GRF_CON_MUX_GMAC_INTERNAL_PHY);
+}
+
 static const struct rk_gmac_ops rk3228_ops = {
.set_to_rgmii = rk3228_set_to_rgmii,
.set_to_rmii = rk3228_set_to_rmii,
.set_rgmii_speed = rk3228_set_rgmii_speed,
.set_rmii_speed = rk3228_set_rmii_speed,
+   .internal_phy_powerup =  rk3228_internal_phy_powerup,
 };
 
 #define RK3288_GRF_SOC_CON10x0248
-- 
1.9.1

[PATCH 06/11] net: stmmac: dwmac-rk: Add internal phy support for rk3228

[David Wu]

There is only one mac controller in rk3228, which could connect to
external phy or internal phy, use the grf_com_mux bit15 to route
external/internal phy.

Change-Id: I3a366677047b8032eb535abb0c3e56fa7722aa2e
Signed-off-by: David Wu 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index c1a1413..90e1fc8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -86,6 +86,8 @@ struct rk_priv_data {
 #define RK3228_GRF_MAC_CON00x0900
 #define RK3228_GRF_MAC_CON10x0904
 
+#define RK3228_GRF_CON_MUX 0x50
+
 /* RK3228_GRF_MAC_CON0 */
 #define RK3228_GMAC_CLK_RX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 7)
 #define RK3228_GMAC_CLK_TX_DL_CFG(val) HIWORD_UPDATE(val, 0x7F, 0)
@@ -111,6 +113,9 @@ struct rk_priv_data {
 #define RK3228_GMAC_RXCLK_DLY_ENABLE   GRF_BIT(1)
 #define RK3228_GMAC_RXCLK_DLY_DISABLE  GRF_CLR_BIT(1)
 
+/* RK3228_GRF_COM_MUX */
+#define RK3228_GRF_CON_MUX_GMAC_INTERNAL_PHY   GRF_BIT(15)
+
 static void rk3228_set_to_rgmii(struct rk_priv_data *bsp_priv,
int tx_delay, int rx_delay)
 {
@@ -191,11 +196,18 @@ static void rk3228_set_rmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
dev_err(dev, "unknown speed value for RMII! speed=%d", speed);
 }
 
+static void rk3228_internal_phy_powerup(struct rk_priv_data *priv)
+{
+   regmap_write(priv->grf, RK3228_GRF_CON_MUX,
+RK3228_GRF_CON_MUX_GMAC_INTERNAL_PHY);
+}
+
 static const struct rk_gmac_ops rk3228_ops = {
.set_to_rgmii = rk3228_set_to_rgmii,
.set_to_rmii = rk3228_set_to_rmii,
.set_rgmii_speed = rk3228_set_rgmii_speed,
.set_rmii_speed = rk3228_set_rmii_speed,
+   .internal_phy_powerup =  rk3228_internal_phy_powerup,
 };
 
 #define RK3288_GRF_SOC_CON10x0248
-- 
1.9.1

[PATCH 05/11] net: stmmac: dwmac-rk: Add internal phy support

[David Wu]

To make internal phy worked, need to configure the phy_clock,
phy cru_reset and related registers.

Change-Id: I6971c0a769754b824b1b908b56080cbaf7867d13
Signed-off-by: David Wu 
---
 .../devicetree/bindings/net/rockchip-dwmac.txt |  3 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 82 ++
 2 files changed, 85 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt 
b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
index 8f42755..0514f69 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
@@ -22,6 +22,7 @@ Required properties:
   < SCLK_MACREF_OUT> clock gate for RMII reference clock output
   < ACLK_GMAC>: AXI clock gate for GMAC
   < PCLK_GMAC>: APB clock gate for GMAC
+  < MAC_PHY>: clock for internal macphy
  - clock-names: One name for each entry in the clocks property.
  - phy-mode: See ethernet.txt file in the same directory.
  - pinctrl-names: Names corresponding to the numbered pinctrl states.
@@ -35,6 +36,8 @@ Required properties:
  - assigned-clocks: main clock, should be < SCLK_MAC>;
  - assigned-clock-parents = parent of main clock.
can be <_gmac> or < SCLK_MAC_PLL>.
+ - phy-type: For internal phy, it must be "internal"; For external phy, no need
+   to configure this.
 
 Optional properties:
  - tx_delay: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as 
default.
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index a8e8fd5..c1a1413 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -41,6 +41,7 @@ struct rk_gmac_ops {
void (*set_to_rmii)(struct rk_priv_data *bsp_priv);
void (*set_rgmii_speed)(struct rk_priv_data *bsp_priv, int speed);
void (*set_rmii_speed)(struct rk_priv_data *bsp_priv, int speed);
+   void (*internal_phy_powerup)(struct rk_priv_data *bsp_priv);
 };
 
 struct rk_priv_data {
@@ -52,6 +53,7 @@ struct rk_priv_data {
 
bool clk_enabled;
bool clock_input;
+   bool internal_phy;
 
struct clk *clk_mac;
struct clk *gmac_clkin;
@@ -61,6 +63,9 @@ struct rk_priv_data {
struct clk *clk_mac_refout;
struct clk *aclk_mac;
struct clk *pclk_mac;
+   struct clk *clk_macphy;
+
+   struct reset_control *macphy_reset;
 
int tx_delay;
int rx_delay;
@@ -750,6 +755,48 @@ static void rk3399_set_rmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
.set_rmii_speed = rk3399_set_rmii_speed,
 };
 
+#define RK_GRF_MACPHY_CON0 0xb00
+#define RK_GRF_MACPHY_CON1 0xb04
+#define RK_GRF_MACPHY_CON2 0xb08
+#define RK_GRF_MACPHY_CON3 0xb0c
+
+#define RK_MACPHY_ENABLE   GRF_BIT(0)
+#define RK_MACPHY_DISABLE  GRF_CLR_BIT(0)
+#define RK_MACPHY_CFG_CLK_50M  GRF_BIT(14)
+#define RK_GMAC2PHY_RMII_MODE  (GRF_BIT(6) | GRF_CLR_BIT(7))
+#define RK_GRF_CON2_MACPHY_ID  HIWORD_UPDATE(0x1234, 0x, 0)
+#define RK_GRF_CON3_MACPHY_ID  HIWORD_UPDATE(0x35, 0x3f, 0)
+
+static void rk_gmac_internal_phy_powerup(struct rk_priv_data *priv)
+{
+   if (priv->ops->internal_phy_powerup)
+   priv->ops->internal_phy_powerup(priv);
+
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_CFG_CLK_50M);
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_GMAC2PHY_RMII_MODE);
+
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON2, RK_GRF_CON2_MACPHY_ID);
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON3, RK_GRF_CON3_MACPHY_ID);
+
+   /* disable macphy, the default value is enabled */
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_DISABLE);
+   if (priv->macphy_reset)
+   reset_control_assert(priv->macphy_reset);
+   usleep_range(10, 20);
+   if (priv->macphy_reset)
+   reset_control_deassert(priv->macphy_reset);
+   usleep_range(10, 20);
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_ENABLE);
+   msleep(30);
+}
+
+static void rk_gmac_internal_phy_powerdown(struct rk_priv_data *priv)
+{
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_DISABLE);
+   if (priv->macphy_reset)
+   reset_control_assert(priv->macphy_reset);
+}
+
 static int gmac_clk_init(struct rk_priv_data *bsp_priv)
 {
struct device *dev = _priv->pdev->dev;
@@ -803,6 +850,14 @@ static int gmac_clk_init(struct rk_priv_data *bsp_priv)
clk_set_rate(bsp_priv->clk_mac, 5000);
}
 
+   if (bsp_priv->internal_phy) {
+   bsp_priv->clk_macphy = devm_clk_get(dev, "clk_macphy");
+   if (IS_ERR(bsp_priv->clk_macphy))
+   dev_err(dev, "cannot get %s clock\n", "clk_macphy");
+   else
+

[PATCH 05/11] net: stmmac: dwmac-rk: Add internal phy support

[David Wu]

To make internal phy worked, need to configure the phy_clock,
phy cru_reset and related registers.

Change-Id: I6971c0a769754b824b1b908b56080cbaf7867d13
Signed-off-by: David Wu 
---
 .../devicetree/bindings/net/rockchip-dwmac.txt |  3 +
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 82 ++
 2 files changed, 85 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt 
b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
index 8f42755..0514f69 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
@@ -22,6 +22,7 @@ Required properties:
   < SCLK_MACREF_OUT> clock gate for RMII reference clock output
   < ACLK_GMAC>: AXI clock gate for GMAC
   < PCLK_GMAC>: APB clock gate for GMAC
+  < MAC_PHY>: clock for internal macphy
  - clock-names: One name for each entry in the clocks property.
  - phy-mode: See ethernet.txt file in the same directory.
  - pinctrl-names: Names corresponding to the numbered pinctrl states.
@@ -35,6 +36,8 @@ Required properties:
  - assigned-clocks: main clock, should be < SCLK_MAC>;
  - assigned-clock-parents = parent of main clock.
can be <_gmac> or < SCLK_MAC_PLL>.
+ - phy-type: For internal phy, it must be "internal"; For external phy, no need
+   to configure this.
 
 Optional properties:
  - tx_delay: Delay value for TXD timing. Range value is 0~0x7F, 0x30 as 
default.
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index a8e8fd5..c1a1413 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -41,6 +41,7 @@ struct rk_gmac_ops {
void (*set_to_rmii)(struct rk_priv_data *bsp_priv);
void (*set_rgmii_speed)(struct rk_priv_data *bsp_priv, int speed);
void (*set_rmii_speed)(struct rk_priv_data *bsp_priv, int speed);
+   void (*internal_phy_powerup)(struct rk_priv_data *bsp_priv);
 };
 
 struct rk_priv_data {
@@ -52,6 +53,7 @@ struct rk_priv_data {
 
bool clk_enabled;
bool clock_input;
+   bool internal_phy;
 
struct clk *clk_mac;
struct clk *gmac_clkin;
@@ -61,6 +63,9 @@ struct rk_priv_data {
struct clk *clk_mac_refout;
struct clk *aclk_mac;
struct clk *pclk_mac;
+   struct clk *clk_macphy;
+
+   struct reset_control *macphy_reset;
 
int tx_delay;
int rx_delay;
@@ -750,6 +755,48 @@ static void rk3399_set_rmii_speed(struct rk_priv_data 
*bsp_priv, int speed)
.set_rmii_speed = rk3399_set_rmii_speed,
 };
 
+#define RK_GRF_MACPHY_CON0 0xb00
+#define RK_GRF_MACPHY_CON1 0xb04
+#define RK_GRF_MACPHY_CON2 0xb08
+#define RK_GRF_MACPHY_CON3 0xb0c
+
+#define RK_MACPHY_ENABLE   GRF_BIT(0)
+#define RK_MACPHY_DISABLE  GRF_CLR_BIT(0)
+#define RK_MACPHY_CFG_CLK_50M  GRF_BIT(14)
+#define RK_GMAC2PHY_RMII_MODE  (GRF_BIT(6) | GRF_CLR_BIT(7))
+#define RK_GRF_CON2_MACPHY_ID  HIWORD_UPDATE(0x1234, 0x, 0)
+#define RK_GRF_CON3_MACPHY_ID  HIWORD_UPDATE(0x35, 0x3f, 0)
+
+static void rk_gmac_internal_phy_powerup(struct rk_priv_data *priv)
+{
+   if (priv->ops->internal_phy_powerup)
+   priv->ops->internal_phy_powerup(priv);
+
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_CFG_CLK_50M);
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_GMAC2PHY_RMII_MODE);
+
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON2, RK_GRF_CON2_MACPHY_ID);
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON3, RK_GRF_CON3_MACPHY_ID);
+
+   /* disable macphy, the default value is enabled */
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_DISABLE);
+   if (priv->macphy_reset)
+   reset_control_assert(priv->macphy_reset);
+   usleep_range(10, 20);
+   if (priv->macphy_reset)
+   reset_control_deassert(priv->macphy_reset);
+   usleep_range(10, 20);
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_ENABLE);
+   msleep(30);
+}
+
+static void rk_gmac_internal_phy_powerdown(struct rk_priv_data *priv)
+{
+   regmap_write(priv->grf, RK_GRF_MACPHY_CON0, RK_MACPHY_DISABLE);
+   if (priv->macphy_reset)
+   reset_control_assert(priv->macphy_reset);
+}
+
 static int gmac_clk_init(struct rk_priv_data *bsp_priv)
 {
struct device *dev = _priv->pdev->dev;
@@ -803,6 +850,14 @@ static int gmac_clk_init(struct rk_priv_data *bsp_priv)
clk_set_rate(bsp_priv->clk_mac, 5000);
}
 
+   if (bsp_priv->internal_phy) {
+   bsp_priv->clk_macphy = devm_clk_get(dev, "clk_macphy");
+   if (IS_ERR(bsp_priv->clk_macphy))
+   dev_err(dev, "cannot get %s clock\n", "clk_macphy");
+   else
+   

Re: [Devel] [PATCH v9 0/3] Cavium ThunderX2 SMMUv3 errata workarounds

[Robert Richter]

On 22.06.17 22:04:37, Lorenzo Pieralisi wrote:
> On Thu, Jun 22, 2017 at 09:35:35PM +0200, Robert Richter wrote:
> > On 22.06.17 19:58:22, Will Deacon wrote:
> > > On Thu, Jun 22, 2017 at 07:22:57PM +0100, Will Deacon wrote:
> > > > On Thu, Jun 22, 2017 at 05:35:35PM +0530, Geetha sowjanya wrote:
> > > > > Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas.
> > > > > 1. Errata ID #74
> > > > >SMMU register alias Page 1 is not implemented
> > > > > 2. Errata ID #126
> > > > >SMMU doesnt support unique IRQ lines and also MSI for gerror,
> > > > >eventq and cmdq-sync
> > > > > 
> > > > > The following patchset does software workaround for these two erratas.
> > > > 
> > > > I've picked up the first two patches, and left comments on the final 
> > > > patch.
> > > 
> > > ... except that it doesn't build:
> > > 
> > > 
> > > drivers/acpi/arm64/iort.c: In function ‘arm_smmu_v3_resource_size’:
> > > drivers/acpi/arm64/iort.c:837:21: error: 
> > > ‘ACPI_IORT_SMMU_V3_CAVIUM_CN99XX’ undeclared (first use in this function)
> > >   if (smmu->model == ACPI_IORT_SMMU_V3_CAVIUM_CN99XX)
> > >  ^
> > > drivers/acpi/arm64/iort.c:837:21: note: each undeclared identifier is 
> > > reported only once for each function it appears in
> > > make[4]: *** [drivers/acpi/arm64/iort.o] Error 1
> > > 
> > > 
> > > I don't see ACPI_IORT_SMMU_V3_CAVIUM_CN99XX defined, even in linux-next.
> > > 
> > > What's the plan here?
> > 
> > It is defined already in acpica and we actually waiting for the acpi
> > maintainers to include it:
> > 
> >  https://github.com/acpica/acpica/commit/d00a4eb86e64
> > 
> > We could add
> > 
> > /* Until ACPICA headers cover IORT rev. C */
> > #ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
> > #define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX 0x2
> > #endif
> > 
> > to both files:
> > 
> >  drivers/acpi/arm64/iort.c
> >  drivers/iommu/arm-smmu-v3.c
> > 
> 
> I thought it was a solved problem (and that the IORT patch was based
> on Robin's workaround) but I was clearly wrong and I apologise to
> Will about this.
> 
> FWIW, you could add the define in include/linux/acpi_iort.h and I will
> remove it whenever ACPICA changes make it into the kernel.

Adding it there will still let depend us on acpi maintainers, while I
think the over 2 files might go through arm64 tree smoothly. A change
in acpi_iort.h also adds the definition to other archs and I don't
think that adding arch #ifdefs to avoid that are welcome in that
header file too.

I am going to resend my patch below with an improved wording.

Thanks,

-Robert

> 
> Thanks,
> Lorenzo
> 
> > This is similar to what Robin did.
> > 
> > (I checked arm64 include files and the closest was
> > arch/arm64/include/asm/acpi.h, bug this seems not really suitable to
> > me.)
> > 
> > I have created a separate patch to be applied at first below. We can
> > revert it after acpica was updated.
> > 
> > -Robert
> > 
> > 
> > 
> > 
> > From ad7f0112a2a71059c32bd315835c33cc7bc660b8 Mon Sep 17 00:00:00 2001
> > From: Robert Richter 
> > Date: Thu, 22 Jun 2017 21:20:54 +0200
> > Subject: [PATCH] iommu/arm-smmu-v3: Add temporary Cavium SMMU-V3 model nuber
> >  definitions
> > 
> > The model number is already defined in acpica and we actually waiting
> > for the acpi maintainers to include it:
> > 
> >  https://github.com/acpica/acpica/commit/d00a4eb86e64
> > 
> > Adding those temporary definitions until the change makes it into
> > include/acpi/actbl2.h.
> > 
> > Signed-off-by: Robert Richter 
> > ---
> >  drivers/acpi/arm64/iort.c   | 5 +
> >  drivers/iommu/arm-smmu-v3.c | 5 +
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 797b28dc7b34..15491237a657 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -31,6 +31,11 @@
> >  #define IORT_IOMMU_TYPE((1 << ACPI_IORT_NODE_SMMU) |   \
> > (1 << ACPI_IORT_NODE_SMMU_V3))
> >  
> > +/* Until ACPICA headers cover IORT rev. C */
> > +#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
> > +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
> > +#endif
> > +
> >  struct iort_its_msi_chip {
> > struct list_headlist;
> > struct fwnode_handle*fw_node;
> > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > index 380969aa60d5..c759dfa7442d 100644
> > --- a/drivers/iommu/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm-smmu-v3.c
> > @@ -412,6 +412,11 @@
> >  #define MSI_IOVA_BASE  0x800
> >  #define MSI_IOVA_LENGTH0x10
> >  
> > +/* Until ACPICA headers cover IORT rev. C */
> > +#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
> > +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
> > +#endif
> > +
> >  static bool disable_bypass;
> >  module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
> >  MODULE_PARM_DESC(disable_bypass,
> > 

Re: [Devel] [PATCH v9 0/3] Cavium ThunderX2 SMMUv3 errata workarounds

[Robert Richter]

On 22.06.17 22:04:37, Lorenzo Pieralisi wrote:
> On Thu, Jun 22, 2017 at 09:35:35PM +0200, Robert Richter wrote:
> > On 22.06.17 19:58:22, Will Deacon wrote:
> > > On Thu, Jun 22, 2017 at 07:22:57PM +0100, Will Deacon wrote:
> > > > On Thu, Jun 22, 2017 at 05:35:35PM +0530, Geetha sowjanya wrote:
> > > > > Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas.
> > > > > 1. Errata ID #74
> > > > >SMMU register alias Page 1 is not implemented
> > > > > 2. Errata ID #126
> > > > >SMMU doesnt support unique IRQ lines and also MSI for gerror,
> > > > >eventq and cmdq-sync
> > > > > 
> > > > > The following patchset does software workaround for these two erratas.
> > > > 
> > > > I've picked up the first two patches, and left comments on the final 
> > > > patch.
> > > 
> > > ... except that it doesn't build:
> > > 
> > > 
> > > drivers/acpi/arm64/iort.c: In function ‘arm_smmu_v3_resource_size’:
> > > drivers/acpi/arm64/iort.c:837:21: error: 
> > > ‘ACPI_IORT_SMMU_V3_CAVIUM_CN99XX’ undeclared (first use in this function)
> > >   if (smmu->model == ACPI_IORT_SMMU_V3_CAVIUM_CN99XX)
> > >  ^
> > > drivers/acpi/arm64/iort.c:837:21: note: each undeclared identifier is 
> > > reported only once for each function it appears in
> > > make[4]: *** [drivers/acpi/arm64/iort.o] Error 1
> > > 
> > > 
> > > I don't see ACPI_IORT_SMMU_V3_CAVIUM_CN99XX defined, even in linux-next.
> > > 
> > > What's the plan here?
> > 
> > It is defined already in acpica and we actually waiting for the acpi
> > maintainers to include it:
> > 
> >  https://github.com/acpica/acpica/commit/d00a4eb86e64
> > 
> > We could add
> > 
> > /* Until ACPICA headers cover IORT rev. C */
> > #ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
> > #define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX 0x2
> > #endif
> > 
> > to both files:
> > 
> >  drivers/acpi/arm64/iort.c
> >  drivers/iommu/arm-smmu-v3.c
> > 
> 
> I thought it was a solved problem (and that the IORT patch was based
> on Robin's workaround) but I was clearly wrong and I apologise to
> Will about this.
> 
> FWIW, you could add the define in include/linux/acpi_iort.h and I will
> remove it whenever ACPICA changes make it into the kernel.

Adding it there will still let depend us on acpi maintainers, while I
think the over 2 files might go through arm64 tree smoothly. A change
in acpi_iort.h also adds the definition to other archs and I don't
think that adding arch #ifdefs to avoid that are welcome in that
header file too.

I am going to resend my patch below with an improved wording.

Thanks,

-Robert

> 
> Thanks,
> Lorenzo
> 
> > This is similar to what Robin did.
> > 
> > (I checked arm64 include files and the closest was
> > arch/arm64/include/asm/acpi.h, bug this seems not really suitable to
> > me.)
> > 
> > I have created a separate patch to be applied at first below. We can
> > revert it after acpica was updated.
> > 
> > -Robert
> > 
> > 
> > 
> > 
> > From ad7f0112a2a71059c32bd315835c33cc7bc660b8 Mon Sep 17 00:00:00 2001
> > From: Robert Richter 
> > Date: Thu, 22 Jun 2017 21:20:54 +0200
> > Subject: [PATCH] iommu/arm-smmu-v3: Add temporary Cavium SMMU-V3 model nuber
> >  definitions
> > 
> > The model number is already defined in acpica and we actually waiting
> > for the acpi maintainers to include it:
> > 
> >  https://github.com/acpica/acpica/commit/d00a4eb86e64
> > 
> > Adding those temporary definitions until the change makes it into
> > include/acpi/actbl2.h.
> > 
> > Signed-off-by: Robert Richter 
> > ---
> >  drivers/acpi/arm64/iort.c   | 5 +
> >  drivers/iommu/arm-smmu-v3.c | 5 +
> >  2 files changed, 10 insertions(+)
> > 
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 797b28dc7b34..15491237a657 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -31,6 +31,11 @@
> >  #define IORT_IOMMU_TYPE((1 << ACPI_IORT_NODE_SMMU) |   \
> > (1 << ACPI_IORT_NODE_SMMU_V3))
> >  
> > +/* Until ACPICA headers cover IORT rev. C */
> > +#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
> > +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
> > +#endif
> > +
> >  struct iort_its_msi_chip {
> > struct list_headlist;
> > struct fwnode_handle*fw_node;
> > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > index 380969aa60d5..c759dfa7442d 100644
> > --- a/drivers/iommu/arm-smmu-v3.c
> > +++ b/drivers/iommu/arm-smmu-v3.c
> > @@ -412,6 +412,11 @@
> >  #define MSI_IOVA_BASE  0x800
> >  #define MSI_IOVA_LENGTH0x10
> >  
> > +/* Until ACPICA headers cover IORT rev. C */
> > +#ifndef ACPI_IORT_SMMU_V3_CAVIUM_CN99XX
> > +#define ACPI_IORT_SMMU_V3_CAVIUM_CN99XX0x2
> > +#endif
> > +
> >  static bool disable_bypass;
> >  module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
> >  MODULE_PARM_DESC(disable_bypass,
> > -- 
> > 2.11.0
> > 

Re: [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver

[Guenter Roeck]

On 06/22/2017 03:48 PM, Eddie James wrote:

From: "Edward A. James" 

This series adds a hwmon driver to support the OCC on POWER8 and POWER9
processors. The OCC is an embedded processor that provides realtime power and
thermal monitoring and management.

This driver has two different platform drivers as a "base" for the
hwmon stuff, as the means of communicating with the OCC on P8 and P9 is
completely different. For P8, the driver is an I2C client driver. For P9 the
driver is an FSI-based OCC client driver, and uses the OCC driver in-kernel
API.

There was a previous version of this driver that wasn't written with the
differences in communication methods between the two versions in mind. This
driver has been considerably simplified.



I thought I did see this before.

It is customary to use "v2" in such situations, and add a change log.
You expect me to go into the two versions and compare them to figure
out what changed to evaluate if it makes sense. Do you really believe that
I have enough time to do that, and that I would be willing to spend that
time in the first place ?

Presumably you know what changed. Why not just tell me ?

Guenter


Edward A. James (7):
   drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver
   drivers/hwmon/occ: Add command transport method for P8 and P9
   drivers/hwmon/occ: Parse OCC poll response
   drivers/hwmon/occ: Add sensor types and versions
   drivers/hwmon/occ: Add sensor attributes and register hwmon device
   drivers/hwmon/occ: Add non-hwmon attributes
   drivers/hwmon/occ: Add error handling

  Documentation/ABI/testing/sysfs-driver-occ-hwmon   |   77 ++
  .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt   |   18 +
  .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   |   25 +
  Documentation/hwmon/occ|   84 ++
  drivers/hwmon/Kconfig  |2 +
  drivers/hwmon/Makefile |1 +
  drivers/hwmon/occ/Kconfig  |   28 +
  drivers/hwmon/occ/Makefile |   11 +
  drivers/hwmon/occ/common.c | 1242 
  drivers/hwmon/occ/common.h |  151 +++
  drivers/hwmon/occ/p8_i2c.c |  250 
  drivers/hwmon/occ/p9_sbe.c |  144 +++
  12 files changed, 2033 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon
  create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
  create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
  create mode 100644 Documentation/hwmon/occ
  create mode 100644 drivers/hwmon/occ/Kconfig
  create mode 100644 drivers/hwmon/occ/Makefile
  create mode 100644 drivers/hwmon/occ/common.c
  create mode 100644 drivers/hwmon/occ/common.h
  create mode 100644 drivers/hwmon/occ/p8_i2c.c
  create mode 100644 drivers/hwmon/occ/p9_sbe.c

Re: [PATCH 0/7] drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver

[Guenter Roeck]

On 06/22/2017 03:48 PM, Eddie James wrote:

From: "Edward A. James" 

This series adds a hwmon driver to support the OCC on POWER8 and POWER9
processors. The OCC is an embedded processor that provides realtime power and
thermal monitoring and management.

This driver has two different platform drivers as a "base" for the
hwmon stuff, as the means of communicating with the OCC on P8 and P9 is
completely different. For P8, the driver is an I2C client driver. For P9 the
driver is an FSI-based OCC client driver, and uses the OCC driver in-kernel
API.

There was a previous version of this driver that wasn't written with the
differences in communication methods between the two versions in mind. This
driver has been considerably simplified.



I thought I did see this before.

It is customary to use "v2" in such situations, and add a change log.
You expect me to go into the two versions and compare them to figure
out what changed to evaluate if it makes sense. Do you really believe that
I have enough time to do that, and that I would be willing to spend that
time in the first place ?

Presumably you know what changed. Why not just tell me ?

Guenter


Edward A. James (7):
   drivers/hwmon: Add On-Chip Controller (OCC) hwmon driver
   drivers/hwmon/occ: Add command transport method for P8 and P9
   drivers/hwmon/occ: Parse OCC poll response
   drivers/hwmon/occ: Add sensor types and versions
   drivers/hwmon/occ: Add sensor attributes and register hwmon device
   drivers/hwmon/occ: Add non-hwmon attributes
   drivers/hwmon/occ: Add error handling

  Documentation/ABI/testing/sysfs-driver-occ-hwmon   |   77 ++
  .../devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt   |   18 +
  .../devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt   |   25 +
  Documentation/hwmon/occ|   84 ++
  drivers/hwmon/Kconfig  |2 +
  drivers/hwmon/Makefile |1 +
  drivers/hwmon/occ/Kconfig  |   28 +
  drivers/hwmon/occ/Makefile |   11 +
  drivers/hwmon/occ/common.c | 1242 
  drivers/hwmon/occ/common.h |  151 +++
  drivers/hwmon/occ/p8_i2c.c |  250 
  drivers/hwmon/occ/p9_sbe.c |  144 +++
  12 files changed, 2033 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-driver-occ-hwmon
  create mode 100644 Documentation/devicetree/bindings/fsi/ibm,p9-occ-hwmon.txt
  create mode 100644 Documentation/devicetree/bindings/i2c/ibm,p8-occ-hwmon.txt
  create mode 100644 Documentation/hwmon/occ
  create mode 100644 drivers/hwmon/occ/Kconfig
  create mode 100644 drivers/hwmon/occ/Makefile
  create mode 100644 drivers/hwmon/occ/common.c
  create mode 100644 drivers/hwmon/occ/common.h
  create mode 100644 drivers/hwmon/occ/p8_i2c.c
  create mode 100644 drivers/hwmon/occ/p9_sbe.c

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

[Theodore Ts'o]

On Thu, Jun 22, 2017 at 04:23:07PM -0700, Khazhismel Kumykov wrote:
> Previously, a read error would be ignored and we would eventually return
> NULL from ext4_find_entry, which signals "no such file or directory". We
> should be returning EIO.
> 
> Signed-off-by: Khazhismel Kumykov 

Thanks, applied.

- Ted

Re: [PATCH] ext4: Return EIO on read error in ext4_find_entry

[Theodore Ts'o]

On Thu, Jun 22, 2017 at 04:23:07PM -0700, Khazhismel Kumykov wrote:
> Previously, a read error would be ignored and we would eventually return
> NULL from ext4_find_entry, which signals "no such file or directory". We
> should be returning EIO.
> 
> Signed-off-by: Khazhismel Kumykov 

Thanks, applied.

- Ted

Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas

[Linus Torvalds]

On Thu, Jun 22, 2017 at 8:10 PM, Andy Lutomirski  wrote:
>
> Has anyone checked how grsecurity deals with this?  I think they have
> a large stack guard gap.

Don't bother with grsecurity.

Their approach has always been "we don't care if we break anything,
we'll just claim it's because we're extra secure".

The thing is a joke, and they are clowns. When they started talking
about people taking advantage of them, I stopped trying to be polite
about their bullshit.

Their patches are pure garbage.

  Linus

Re: [vs-plain] Re: [PATCH] mm: larger stack guard gap, between vmas

[Linus Torvalds]

On Thu, Jun 22, 2017 at 8:10 PM, Andy Lutomirski  wrote:
>
> Has anyone checked how grsecurity deals with this?  I think they have
> a large stack guard gap.

Don't bother with grsecurity.

Their approach has always been "we don't care if we break anything,
we'll just claim it's because we're extra secure".

The thing is a joke, and they are clowns. When they started talking
about people taking advantage of them, I stopped trying to be polite
about their bullshit.

Their patches are pure garbage.

  Linus

[PATCH] KVM: x86: remove ignored type attribute

[Nick Desaulniers]

The macro insn_fetch marks the 'type' argument as having a specified
alignment.  Type attributes can only be applied to structs, unions, or
enums, but insn_fetch is only ever invoked with integral types, so Clang
produces 19 -Wignored-attributes warnings for this source file.

Signed-off-by: Nick Desaulniers 
---
 arch/x86/kvm/emulate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 7611c034bf95..409081977e59 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -900,7 +900,7 @@ static __always_inline int do_insn_fetch_bytes(struct 
x86_emulate_ctxt *ctxt,
if (rc != X86EMUL_CONTINUE) \
goto done;  \
ctxt->_eip += sizeof(_type);\
-   _x = *(_type __aligned(1) *) ctxt->fetch.ptr;   \
+   _x = *(_type *) ctxt->fetch.ptr;\
ctxt->fetch.ptr += sizeof(_type);   \
_x; \
 })
-- 
2.11.0

[PATCH] KVM: x86: remove ignored type attribute

[Nick Desaulniers]

The macro insn_fetch marks the 'type' argument as having a specified
alignment.  Type attributes can only be applied to structs, unions, or
enums, but insn_fetch is only ever invoked with integral types, so Clang
produces 19 -Wignored-attributes warnings for this source file.

Signed-off-by: Nick Desaulniers 
---
 arch/x86/kvm/emulate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index 7611c034bf95..409081977e59 100644
--- a/arch/x86/kvm/emulate.c
+++ b/arch/x86/kvm/emulate.c
@@ -900,7 +900,7 @@ static __always_inline int do_insn_fetch_bytes(struct 
x86_emulate_ctxt *ctxt,
if (rc != X86EMUL_CONTINUE) \
goto done;  \
ctxt->_eip += sizeof(_type);\
-   _x = *(_type __aligned(1) *) ctxt->fetch.ptr;   \
+   _x = *(_type *) ctxt->fetch.ptr;\
ctxt->fetch.ptr += sizeof(_type);   \
_x; \
 })
-- 
2.11.0

[PATCH 04/11] net: stmmac: dwmac-rk: Remove unwanted code for rk3328_set_to_rmii()

[David Wu]

This is wrong setting for rk3328_set_to_rmii(), so remove it.

Change-Id: I9953784ea44335d90710e5473960c95b3d68a5fd
Signed-off-by: David Wu 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index f0df519..a8e8fd5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -365,9 +365,6 @@ static void rk3328_set_to_rmii(struct rk_priv_data 
*bsp_priv)
regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1,
 RK3328_GMAC_PHY_INTF_SEL_RMII |
 RK3328_GMAC_RMII_MODE);
-
-   /* set MAC to RMII mode */
-   regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1, GRF_BIT(11));
 }
 
 static void rk3328_set_rgmii_speed(struct rk_priv_data *bsp_priv, int speed)
-- 
1.9.1

[PATCH 04/11] net: stmmac: dwmac-rk: Remove unwanted code for rk3328_set_to_rmii()

[David Wu]

This is wrong setting for rk3328_set_to_rmii(), so remove it.

Change-Id: I9953784ea44335d90710e5473960c95b3d68a5fd
Signed-off-by: David Wu 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index f0df519..a8e8fd5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -365,9 +365,6 @@ static void rk3328_set_to_rmii(struct rk_priv_data 
*bsp_priv)
regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1,
 RK3328_GMAC_PHY_INTF_SEL_RMII |
 RK3328_GMAC_RMII_MODE);
-
-   /* set MAC to RMII mode */
-   regmap_write(bsp_priv->grf, RK3328_GRF_MAC_CON1, GRF_BIT(11));
 }
 
 static void rk3328_set_rgmii_speed(struct rk_priv_data *bsp_priv, int speed)
-- 
1.9.1