Re: [PATCH] ARM: dts: qcom: msm8974: Add Sony Xperia Z1 Compact

[Bjorn Andersson]

On Sat 02 Dec 20:09 PST 2017, Attila Sz?ll??si wrote:

> This patch adds a DTS file for Sony Xperia Z1 Compact with support for
> regulators, serial UART, eMMC/SD-card, USB, charger, backlight,
> coincell and buttons.
> 
> Work based on arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts.
> 
> Signed-off-by: Attila Szöll??si 

Acked-by: Bjorn Andersson 

Regards,
Bjorn

[PATCH v2] PCI: dwc: Use {upper,lower}_32_bits() macros for clarity

[Stephen Boyd]

We have macros for getting the upper or lower 32 bits of a
number. Use them here to shave a couple lines off the code
and provide clarity.

Signed-off-by: Stephen Boyd 
---

Changes from v1:
 * Update dw_msi_setup_msg() too
 * Reword commit text slightly

 drivers/pci/dwc/pcie-designware-host.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/pci/dwc/pcie-designware-host.c 
b/drivers/pci/dwc/pcie-designware-host.c
index 81e2157a7cfb..454b8d244071 100644
--- a/drivers/pci/dwc/pcie-designware-host.c
+++ b/drivers/pci/dwc/pcie-designware-host.c
@@ -89,10 +89,8 @@ void dw_pcie_msi_init(struct pcie_port *pp)
msi_target = virt_to_phys((void *)pp->msi_data);
 
/* program the msi_data */
-   dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4,
-   (u32)(msi_target & 0x));
-   dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_HI, 4,
-   (u32)(msi_target >> 32 & 0x));
+   dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_LO, 4, lower_32_bits(msi_target));
+   dw_pcie_wr_own_conf(pp, PCIE_MSI_ADDR_HI, 4, upper_32_bits(msi_target));
 }
 
 static void dw_pcie_msi_clear_irq(struct pcie_port *pp, int irq)
@@ -189,8 +187,8 @@ static void dw_msi_setup_msg(struct pcie_port *pp, unsigned 
int irq, u32 pos)
else
msi_target = virt_to_phys((void *)pp->msi_data);
 
-   msg.address_lo = (u32)(msi_target & 0x);
-   msg.address_hi = (u32)(msi_target >> 32 & 0x);
+   msg.address_lo = lower_32_bits(msi_target);
+   msg.address_hi = upper_32_bits(msi_target);
 
if (pp->ops->get_msi_data)
msg.data = pp->ops->get_msi_data(pp, pos);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Russell King - ARM Linux]

On Wed, Dec 27, 2017 at 11:42:52PM +0100, Antoine Tenart wrote:
> Hi Russell,
> 
> On Wed, Dec 27, 2017 at 10:24:01PM +, Russell King - ARM Linux wrote:
> > On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> > >  
> > > +_eth2 {
> > > + /* CPS Lane 5 */
> > > + status = "okay";
> > > + phy-mode = "2500base-x";
> > > + /* Generic PHY, providing serdes lanes */
> > > + phys = <_comphy5 2>;
> > > +};
> > > +
> > 
> > This is wrong.  This lane is connected to a SFP cage which can support
> > more than just 2500base-X.  Tying it in this way to 2500base-X means
> > that this port does not support conenctions at 1000base-X, despite
> > that's one of the most popular and more standardised speeds.
> 
> What do you suggest to describe this in the dt, to enable a port using
> the current PPv2 driver?

I don't - I'm merely pointing out that you're bodging support for the
SFP cage rather than productively discussing phylink for mvpp2.

As far as I remember, the discussion stalled at this point:

- You think there's modes that mvpp2 supports that are not supportable
  if you use phylink.

- I've described what phylink supports, and I've asked you for details
  about what you can't support.

Unfortunately, no details have been forthcoming, and no further
discussion has occurred - the ball is entirely in your court to
progress this issue since I requested information from you and that
is where things seem to have stalled.

The result is that, with your patch, you're locking the port to 2.5G
speeds, meaning that only 4.3Mbps Fibrechannel SFPs can be used with
the port, and it can only be used with another device that supports
2.5G speeds.  You can't use a copper RJ45 module, and you can't use
a standard 1000base-X module either in this configuration.

What I'm most concerned about, given the bindings for comphy that
have been merged, is that Free Electrons is pushing forward seemingly
with no regard to the requirement that the serdes lanes are dynamically
reconfigurable, and that's a basic requirement for SFP, and for the
88x3310 PHYs on the Macchiatobin platform.

So, my question to you is: what is Free Electrons plans to properly
support the ethernet ports on the Macchiatobin platform?


For those on the Cc list who don't know, phylink is part of full support
for SFP and SFP+ cages, sponsored (in terms of hardware including SFP
modules) by SolidRun on both SolidRun's Clearfog and Macchiatobin
platforms, supporting a wide range of SFP modules including:

- 1G Optical ethernet modules (duplex and bidi modules)
- 10/100/1G RJ45 modules
- 10G SFP+ modules
- 2.5Gbase-X using 4.3Mbps Fibrechannel modules
- Direct attach cables

There is work ongoing between Florian, Andrew and myself to switch DSA
to phylink, and have SFP modules working with both Marvell and Broadcom
DSA switches.

Phylink and SFP was already merged into mainline, and has been usable
(provided that the network driver is converted to phylink rather than
phylib) since 4.14-rc1.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Russell King - ARM Linux]

On Wed, Dec 27, 2017 at 11:42:52PM +0100, Antoine Tenart wrote:
> Hi Russell,
> 
> On Wed, Dec 27, 2017 at 10:24:01PM +, Russell King - ARM Linux wrote:
> > On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> > >  
> > > +_eth2 {
> > > + /* CPS Lane 5 */
> > > + status = "okay";
> > > + phy-mode = "2500base-x";
> > > + /* Generic PHY, providing serdes lanes */
> > > + phys = <_comphy5 2>;
> > > +};
> > > +
> > 
> > This is wrong.  This lane is connected to a SFP cage which can support
> > more than just 2500base-X.  Tying it in this way to 2500base-X means
> > that this port does not support conenctions at 1000base-X, despite
> > that's one of the most popular and more standardised speeds.
> 
> What do you suggest to describe this in the dt, to enable a port using
> the current PPv2 driver?

I don't - I'm merely pointing out that you're bodging support for the
SFP cage rather than productively discussing phylink for mvpp2.

As far as I remember, the discussion stalled at this point:

- You think there's modes that mvpp2 supports that are not supportable
  if you use phylink.

- I've described what phylink supports, and I've asked you for details
  about what you can't support.

Unfortunately, no details have been forthcoming, and no further
discussion has occurred - the ball is entirely in your court to
progress this issue since I requested information from you and that
is where things seem to have stalled.

The result is that, with your patch, you're locking the port to 2.5G
speeds, meaning that only 4.3Mbps Fibrechannel SFPs can be used with
the port, and it can only be used with another device that supports
2.5G speeds.  You can't use a copper RJ45 module, and you can't use
a standard 1000base-X module either in this configuration.

What I'm most concerned about, given the bindings for comphy that
have been merged, is that Free Electrons is pushing forward seemingly
with no regard to the requirement that the serdes lanes are dynamically
reconfigurable, and that's a basic requirement for SFP, and for the
88x3310 PHYs on the Macchiatobin platform.

So, my question to you is: what is Free Electrons plans to properly
support the ethernet ports on the Macchiatobin platform?


For those on the Cc list who don't know, phylink is part of full support
for SFP and SFP+ cages, sponsored (in terms of hardware including SFP
modules) by SolidRun on both SolidRun's Clearfog and Macchiatobin
platforms, supporting a wide range of SFP modules including:

- 1G Optical ethernet modules (duplex and bidi modules)
- 10/100/1G RJ45 modules
- 10G SFP+ modules
- 2.5Gbase-X using 4.3Mbps Fibrechannel modules
- Direct attach cables

There is work ongoing between Florian, Andrew and myself to switch DSA
to phylink, and have SFP modules working with both Marvell and Broadcom
DSA switches.

Phylink and SFP was already merged into mainline, and has been usable
(provided that the network driver is converted to phylink rather than
phylib) since 4.14-rc1.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] pinctrl: msm: Delete an error message for a failed memory allocation in msm_pinctrl_probe()

[Bjorn Andersson]

On Wed 27 Dec 13:10 PST 2017, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Wed, 27 Dec 2017 22:04:22 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Thank's Markus,

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/pinctrl/qcom/pinctrl-msm.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 7a960590ecaa..495432f3341b 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -898,10 +898,9 @@ int msm_pinctrl_probe(struct platform_device *pdev,
>   int ret;
>  
>   pctrl = devm_kzalloc(>dev, sizeof(*pctrl), GFP_KERNEL);
> - if (!pctrl) {
> - dev_err(>dev, "Can't allocate msm_pinctrl\n");
> + if (!pctrl)
>   return -ENOMEM;
> - }
> +
>   pctrl->dev = >dev;
>   pctrl->soc = soc_data;
>   pctrl->chip = msm_gpio_template;
> -- 
> 2.15.1
> 

Re: [PATCH] pinctrl: msm: Delete an error message for a failed memory allocation in msm_pinctrl_probe()

[Bjorn Andersson]

On Wed 27 Dec 13:10 PST 2017, SF Markus Elfring wrote:

> From: Markus Elfring 
> Date: Wed, 27 Dec 2017 22:04:22 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Thank's Markus,

Acked-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/pinctrl/qcom/pinctrl-msm.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 7a960590ecaa..495432f3341b 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -898,10 +898,9 @@ int msm_pinctrl_probe(struct platform_device *pdev,
>   int ret;
>  
>   pctrl = devm_kzalloc(>dev, sizeof(*pctrl), GFP_KERNEL);
> - if (!pctrl) {
> - dev_err(>dev, "Can't allocate msm_pinctrl\n");
> + if (!pctrl)
>   return -ENOMEM;
> - }
> +
>   pctrl->dev = >dev;
>   pctrl->soc = soc_data;
>   pctrl->chip = msm_gpio_template;
> -- 
> 2.15.1
> 

[tip:x86/urgent] x86-32: Fix kexec with stack canary (CONFIG_CC_STACKPROTECTOR)

[tip-bot for Linus Torvalds]

Commit-ID:  ac461122c88a10b7d775de2f56467f097c9e627a
Gitweb: https://git.kernel.org/tip/ac461122c88a10b7d775de2f56467f097c9e627a
Author: Linus Torvalds 
AuthorDate: Wed, 27 Dec 2017 11:48:50 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 27 Dec 2017 20:59:41 +0100

x86-32: Fix kexec with stack canary (CONFIG_CC_STACKPROTECTOR)

Commit e802a51ede91 ("x86/idt: Consolidate IDT invalidation") cleaned up
and unified the IDT invalidation that existed in a couple of places.  It
changed no actual real code.

Despite not changing any actual real code, it _did_ change code generation:
by implementing the common idt_invalidate() function in
archx86/kernel/idt.c, it made the use of the function in
arch/x86/kernel/machine_kexec_32.c be a real function call rather than an
(accidental) inlining of the function.

That, in turn, exposed two issues:

 - in load_segments(), we had incorrectly reset all the segment
   registers, which then made the stack canary load (which gcc does
   using offset of %gs) cause a trap.  Instead of %gs pointing to the
   stack canary, it will be the normal zero-based kernel segment, and
   the stack canary load will take a page fault at address 0x14.

 - to make this even harder to debug, we had invalidated the GDT just
   before calling idt_invalidate(), which meant that the fault happened
   with an invalid GDT, which in turn causes a triple fault and
   immediate reboot.

Fix this by

 (a) not reloading the special segments in load_segments(). We currently
 don't do any percpu accesses (which would require %fs on x86-32) in
 this area, but there's no reason to think that we might not want to
 do them, and like %gs, it's pointless to break it.

 (b) doing idt_invalidate() before invalidating the GDT, to keep things
 at least _slightly_ more debuggable for a bit longer. Without a
 IDT, traps will not work. Without a GDT, traps also will not work,
 but neither will any segment loads etc. So in a very real sense,
 the GDT is even more core than the IDT.

Fixes: e802a51ede91 ("x86/idt: Consolidate IDT invalidation")
Reported-and-tested-by: Alexandru Chirvasitu 
Signed-off-by: Linus Torvalds 
Signed-off-by: Thomas Gleixner 
Cc: Denys Vlasenko 
Cc: Peter Zijlstra 
Cc: Brian Gerst 
Cc: Steven Rostedt 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Josh Poimboeuf 
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.lfd.2.21.1712271143180.8...@i7.lan

---
 arch/x86/kernel/machine_kexec_32.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/kernel/machine_kexec_32.c 
b/arch/x86/kernel/machine_kexec_32.c
index 00bc751..edfede7 100644
--- a/arch/x86/kernel/machine_kexec_32.c
+++ b/arch/x86/kernel/machine_kexec_32.c
@@ -48,8 +48,6 @@ static void load_segments(void)
"\tmovl $"STR(__KERNEL_DS)",%%eax\n"
"\tmovl %%eax,%%ds\n"
"\tmovl %%eax,%%es\n"
-   "\tmovl %%eax,%%fs\n"
-   "\tmovl %%eax,%%gs\n"
"\tmovl %%eax,%%ss\n"
: : : "eax", "memory");
 #undef STR
@@ -232,8 +230,8 @@ void machine_kexec(struct kimage *image)
 * The gdt & idt are now invalid.
 * If you want to load them you must set up your own idt & gdt.
 */
-   set_gdt(phys_to_virt(0), 0);
idt_invalidate(phys_to_virt(0));
+   set_gdt(phys_to_virt(0), 0);
 
/* now call it */
image->start = relocate_kernel_ptr((unsigned long)image->head,

[tip:x86/urgent] x86-32: Fix kexec with stack canary (CONFIG_CC_STACKPROTECTOR)

[tip-bot for Linus Torvalds]

Commit-ID:  ac461122c88a10b7d775de2f56467f097c9e627a
Gitweb: https://git.kernel.org/tip/ac461122c88a10b7d775de2f56467f097c9e627a
Author: Linus Torvalds 
AuthorDate: Wed, 27 Dec 2017 11:48:50 -0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 27 Dec 2017 20:59:41 +0100

x86-32: Fix kexec with stack canary (CONFIG_CC_STACKPROTECTOR)

Commit e802a51ede91 ("x86/idt: Consolidate IDT invalidation") cleaned up
and unified the IDT invalidation that existed in a couple of places.  It
changed no actual real code.

Despite not changing any actual real code, it _did_ change code generation:
by implementing the common idt_invalidate() function in
archx86/kernel/idt.c, it made the use of the function in
arch/x86/kernel/machine_kexec_32.c be a real function call rather than an
(accidental) inlining of the function.

That, in turn, exposed two issues:

 - in load_segments(), we had incorrectly reset all the segment
   registers, which then made the stack canary load (which gcc does
   using offset of %gs) cause a trap.  Instead of %gs pointing to the
   stack canary, it will be the normal zero-based kernel segment, and
   the stack canary load will take a page fault at address 0x14.

 - to make this even harder to debug, we had invalidated the GDT just
   before calling idt_invalidate(), which meant that the fault happened
   with an invalid GDT, which in turn causes a triple fault and
   immediate reboot.

Fix this by

 (a) not reloading the special segments in load_segments(). We currently
 don't do any percpu accesses (which would require %fs on x86-32) in
 this area, but there's no reason to think that we might not want to
 do them, and like %gs, it's pointless to break it.

 (b) doing idt_invalidate() before invalidating the GDT, to keep things
 at least _slightly_ more debuggable for a bit longer. Without a
 IDT, traps will not work. Without a GDT, traps also will not work,
 but neither will any segment loads etc. So in a very real sense,
 the GDT is even more core than the IDT.

Fixes: e802a51ede91 ("x86/idt: Consolidate IDT invalidation")
Reported-and-tested-by: Alexandru Chirvasitu 
Signed-off-by: Linus Torvalds 
Signed-off-by: Thomas Gleixner 
Cc: Denys Vlasenko 
Cc: Peter Zijlstra 
Cc: Brian Gerst 
Cc: Steven Rostedt 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Josh Poimboeuf 
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.lfd.2.21.1712271143180.8...@i7.lan

---
 arch/x86/kernel/machine_kexec_32.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/kernel/machine_kexec_32.c 
b/arch/x86/kernel/machine_kexec_32.c
index 00bc751..edfede7 100644
--- a/arch/x86/kernel/machine_kexec_32.c
+++ b/arch/x86/kernel/machine_kexec_32.c
@@ -48,8 +48,6 @@ static void load_segments(void)
"\tmovl $"STR(__KERNEL_DS)",%%eax\n"
"\tmovl %%eax,%%ds\n"
"\tmovl %%eax,%%es\n"
-   "\tmovl %%eax,%%fs\n"
-   "\tmovl %%eax,%%gs\n"
"\tmovl %%eax,%%ss\n"
: : : "eax", "memory");
 #undef STR
@@ -232,8 +230,8 @@ void machine_kexec(struct kimage *image)
 * The gdt & idt are now invalid.
 * If you want to load them you must set up your own idt & gdt.
 */
-   set_gdt(phys_to_virt(0), 0);
idt_invalidate(phys_to_virt(0));
+   set_gdt(phys_to_virt(0), 0);
 
/* now call it */
image->start = relocate_kernel_ptr((unsigned long)image->head,

[tip:smp/urgent] cpu/hotplug: Move inline keyword at the beginning of declaration

[tip-bot for Mathieu Malaterre]

Commit-ID:  76dc6c097d581ad8eeedf8e1a000423a3d742445
Gitweb: https://git.kernel.org/tip/76dc6c097d581ad8eeedf8e1a000423a3d742445
Author: Mathieu Malaterre 
AuthorDate: Tue, 26 Dec 2017 15:08:53 +0100
Committer:  Thomas Gleixner 
CommitDate: Wed, 27 Dec 2017 19:41:04 +0100

cpu/hotplug: Move inline keyword at the beginning of declaration

Fix non-fatal warnings such as:

kernel/cpu.c:95:1: warning: ‘inline’ is not at beginning of declaration 
[-Wold-style-declaration]
 static void inline cpuhp_lock_release(bool bringup) { }
 ^~

Signed-off-by: Mathieu Malaterre 
Signed-off-by: Thomas Gleixner 
Cc: Arnd Bergmann 
Cc: Sebastian Andrzej Siewior 
Cc: Peter Zijlstra 
Cc: "Paul E. McKenney" 
Link: https://lkml.kernel.org/r/20171226140855.16583-1-ma...@debian.org

---
 kernel/cpu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 41376c3..3d002a6 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -80,19 +80,19 @@ static struct lockdep_map cpuhp_state_down_map =
STATIC_LOCKDEP_MAP_INIT("cpuhp_state-down", _state_down_map);
 
 
-static void inline cpuhp_lock_acquire(bool bringup)
+static inline void cpuhp_lock_acquire(bool bringup)
 {
lock_map_acquire(bringup ? _state_up_map : _state_down_map);
 }
 
-static void inline cpuhp_lock_release(bool bringup)
+static inline void cpuhp_lock_release(bool bringup)
 {
lock_map_release(bringup ? _state_up_map : _state_down_map);
 }
 #else
 
-static void inline cpuhp_lock_acquire(bool bringup) { }
-static void inline cpuhp_lock_release(bool bringup) { }
+static inline void cpuhp_lock_acquire(bool bringup) { }
+static inline void cpuhp_lock_release(bool bringup) { }
 
 #endif
 

[tip:x86/urgent] x86: Remove unused parameter of prepare_switch_to

[tip-bot for rodrigosiqueira]

Commit-ID:  7ac139eaa6bbdb07c547b6916a808eab3897e0e3
Gitweb: https://git.kernel.org/tip/7ac139eaa6bbdb07c547b6916a808eab3897e0e3
Author: rodrigosiqueira 
AuthorDate: Fri, 15 Dec 2017 11:15:33 -0200
Committer:  Thomas Gleixner 
CommitDate: Wed, 27 Dec 2017 20:37:41 +0100

x86: Remove unused parameter of prepare_switch_to

Commit e37e43a497d5 ("x86/mm/64: Enable vmapped stacks
(CONFIG_HAVE_ARCH_VMAP_STACK=y)") added prepare_switch_to with one extra
parameter which is not used by the function, remove it.

Signed-off-by: Rodrigo Siqueira 
Signed-off-by: Thomas Gleixner 
Cc: kernel-janit...@vger.kernel.org
Link: https://lkml.kernel.org/r/20171215131533.hp6kqebw45o7u...@smtp.gmail.com

---
 arch/x86/include/asm/switch_to.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 8c6bd68..1008d46 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -16,8 +16,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct 
task_struct *next_p,
  struct tss_struct *tss);
 
 /* This runs runs on the previous thread's stack. */
-static inline void prepare_switch_to(struct task_struct *prev,
-struct task_struct *next)
+static inline void prepare_switch_to(struct task_struct *next)
 {
 #ifdef CONFIG_VMAP_STACK
/*
@@ -70,7 +69,7 @@ struct fork_frame {
 
 #define switch_to(prev, next, last)\
 do {   \
-   prepare_switch_to(prev, next);  \
+   prepare_switch_to(next);\
\
((last) = __switch_to_asm((prev), (next))); \
 } while (0)

[tip:smp/urgent] cpu/hotplug: Move inline keyword at the beginning of declaration

[tip-bot for Mathieu Malaterre]

Commit-ID:  76dc6c097d581ad8eeedf8e1a000423a3d742445
Gitweb: https://git.kernel.org/tip/76dc6c097d581ad8eeedf8e1a000423a3d742445
Author: Mathieu Malaterre 
AuthorDate: Tue, 26 Dec 2017 15:08:53 +0100
Committer:  Thomas Gleixner 
CommitDate: Wed, 27 Dec 2017 19:41:04 +0100

cpu/hotplug: Move inline keyword at the beginning of declaration

Fix non-fatal warnings such as:

kernel/cpu.c:95:1: warning: ‘inline’ is not at beginning of declaration 
[-Wold-style-declaration]
 static void inline cpuhp_lock_release(bool bringup) { }
 ^~

Signed-off-by: Mathieu Malaterre 
Signed-off-by: Thomas Gleixner 
Cc: Arnd Bergmann 
Cc: Sebastian Andrzej Siewior 
Cc: Peter Zijlstra 
Cc: "Paul E. McKenney" 
Link: https://lkml.kernel.org/r/20171226140855.16583-1-ma...@debian.org

---
 kernel/cpu.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/cpu.c b/kernel/cpu.c
index 41376c3..3d002a6 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -80,19 +80,19 @@ static struct lockdep_map cpuhp_state_down_map =
STATIC_LOCKDEP_MAP_INIT("cpuhp_state-down", _state_down_map);
 
 
-static void inline cpuhp_lock_acquire(bool bringup)
+static inline void cpuhp_lock_acquire(bool bringup)
 {
lock_map_acquire(bringup ? _state_up_map : _state_down_map);
 }
 
-static void inline cpuhp_lock_release(bool bringup)
+static inline void cpuhp_lock_release(bool bringup)
 {
lock_map_release(bringup ? _state_up_map : _state_down_map);
 }
 #else
 
-static void inline cpuhp_lock_acquire(bool bringup) { }
-static void inline cpuhp_lock_release(bool bringup) { }
+static inline void cpuhp_lock_acquire(bool bringup) { }
+static inline void cpuhp_lock_release(bool bringup) { }
 
 #endif
 

[tip:x86/urgent] x86: Remove unused parameter of prepare_switch_to

[tip-bot for rodrigosiqueira]

Commit-ID:  7ac139eaa6bbdb07c547b6916a808eab3897e0e3
Gitweb: https://git.kernel.org/tip/7ac139eaa6bbdb07c547b6916a808eab3897e0e3
Author: rodrigosiqueira 
AuthorDate: Fri, 15 Dec 2017 11:15:33 -0200
Committer:  Thomas Gleixner 
CommitDate: Wed, 27 Dec 2017 20:37:41 +0100

x86: Remove unused parameter of prepare_switch_to

Commit e37e43a497d5 ("x86/mm/64: Enable vmapped stacks
(CONFIG_HAVE_ARCH_VMAP_STACK=y)") added prepare_switch_to with one extra
parameter which is not used by the function, remove it.

Signed-off-by: Rodrigo Siqueira 
Signed-off-by: Thomas Gleixner 
Cc: kernel-janit...@vger.kernel.org
Link: https://lkml.kernel.org/r/20171215131533.hp6kqebw45o7u...@smtp.gmail.com

---
 arch/x86/include/asm/switch_to.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 8c6bd68..1008d46 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -16,8 +16,7 @@ void __switch_to_xtra(struct task_struct *prev_p, struct 
task_struct *next_p,
  struct tss_struct *tss);
 
 /* This runs runs on the previous thread's stack. */
-static inline void prepare_switch_to(struct task_struct *prev,
-struct task_struct *next)
+static inline void prepare_switch_to(struct task_struct *next)
 {
 #ifdef CONFIG_VMAP_STACK
/*
@@ -70,7 +69,7 @@ struct fork_frame {
 
 #define switch_to(prev, next, last)\
 do {   \
-   prepare_switch_to(prev, next);  \
+   prepare_switch_to(next);\
\
((last) = __switch_to_asm((prev), (next))); \
 } while (0)

Re: [PATCH] bpf: selftest for late caller stack size increase

[Daniel Borkmann]

On 12/22/2017 07:12 PM, Jann Horn wrote:
> This checks that it is not possible to bypass the total stack size check in
> update_stack_depth() by calling a function that uses a large amount of
> stack memory *before* using a large amount of stack memory in the caller.
> 
> Currently, the first added testcase causes a rejection as expected, but
> the second testcase is (AFAICS incorrectly) accepted:
> 
> [...]
> #483/p calls: stack overflow using two frames (post-call access) FAIL
> Unexpected success to load!
> 0: (85) call pc+2
> caller:
>  R10=fp0,call_-1
> callee:
>  frame1: R1=ctx(id=0,off=0,imm=0) R10=fp0,call_0
> 3: (72) *(u8 *)(r10 -300) = 0
> 4: (b7) r0 = 0
> 5: (95) exit
> returning from callee:
>  frame1: R0_w=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0,call_0
> to caller at 1:
>  R0_w=inv0 R10=fp0,call_-1
> 
> from 5 to 1: R0=inv0 R10=fp0,call_-1
> 1: (72) *(u8 *)(r10 -300) = 0
> 2: (95) exit
> processed 6 insns, stack depth 300+300
> [...]
> Summary: 704 PASSED, 1 FAILED
> 
> AFAICS the JIT-generated code for the second testcase shows that this
> really causes the stack pointer to be decremented by 300+300:
> 
> first function:
>   55push rbp
> 0001  4889E5mov rbp,rsp
> 0004  4881EC5801sub rsp,0x158
> 000B  4883ED28  sub rbp,byte +0x28
> [...]
> 0025  E89AB3AFE5call 0xe5afb3c4
> 002A  C685D4FE00mov byte [rbp-0x12c],0x0
> [...]
> 0041  4883C528  add rbp,byte +0x28
> 0045  C9leave
> 0046  C3ret
> 
> second function:
>   55push rbp
> 0001  4889E5mov rbp,rsp
> 0004  4881EC5801sub rsp,0x158
> 000B  4883ED28  sub rbp,byte +0x28
> [...]
> 0025  C685D4FE00mov byte [rbp-0x12c],0x0
> [...]
> 003E  4883C528  add rbp,byte +0x28
> 0042  C9leave
> 0043  C3ret
> 
> Signed-off-by: Jann Horn 

Applied to bpf-next, thanks a lot Jann!

Re: [PATCH] bpf: selftest for late caller stack size increase

[Daniel Borkmann]

On 12/22/2017 07:12 PM, Jann Horn wrote:
> This checks that it is not possible to bypass the total stack size check in
> update_stack_depth() by calling a function that uses a large amount of
> stack memory *before* using a large amount of stack memory in the caller.
> 
> Currently, the first added testcase causes a rejection as expected, but
> the second testcase is (AFAICS incorrectly) accepted:
> 
> [...]
> #483/p calls: stack overflow using two frames (post-call access) FAIL
> Unexpected success to load!
> 0: (85) call pc+2
> caller:
>  R10=fp0,call_-1
> callee:
>  frame1: R1=ctx(id=0,off=0,imm=0) R10=fp0,call_0
> 3: (72) *(u8 *)(r10 -300) = 0
> 4: (b7) r0 = 0
> 5: (95) exit
> returning from callee:
>  frame1: R0_w=inv0 R1=ctx(id=0,off=0,imm=0) R10=fp0,call_0
> to caller at 1:
>  R0_w=inv0 R10=fp0,call_-1
> 
> from 5 to 1: R0=inv0 R10=fp0,call_-1
> 1: (72) *(u8 *)(r10 -300) = 0
> 2: (95) exit
> processed 6 insns, stack depth 300+300
> [...]
> Summary: 704 PASSED, 1 FAILED
> 
> AFAICS the JIT-generated code for the second testcase shows that this
> really causes the stack pointer to be decremented by 300+300:
> 
> first function:
>   55push rbp
> 0001  4889E5mov rbp,rsp
> 0004  4881EC5801sub rsp,0x158
> 000B  4883ED28  sub rbp,byte +0x28
> [...]
> 0025  E89AB3AFE5call 0xe5afb3c4
> 002A  C685D4FE00mov byte [rbp-0x12c],0x0
> [...]
> 0041  4883C528  add rbp,byte +0x28
> 0045  C9leave
> 0046  C3ret
> 
> second function:
>   55push rbp
> 0001  4889E5mov rbp,rsp
> 0004  4881EC5801sub rsp,0x158
> 000B  4883ED28  sub rbp,byte +0x28
> [...]
> 0025  C685D4FE00mov byte [rbp-0x12c],0x0
> [...]
> 003E  4883C528  add rbp,byte +0x28
> 0042  C9leave
> 0043  C3ret
> 
> Signed-off-by: Jann Horn 

Applied to bpf-next, thanks a lot Jann!

Re: [PATCH 3/4] libbpf: break loop earlier

[Daniel Borkmann]

On 12/27/2017 09:30 PM, Eric Leblond wrote:
> On Wed, 2017-12-27 at 11:00 -0800, Alexei Starovoitov wrote:
>> On Wed, Dec 27, 2017 at 07:02:28PM +0100, Eric Leblond wrote:
>>> Get out of the loop when we have a match.
>>>
>>> Signed-off-by: Eric Leblond 
>>> ---
>>>  tools/lib/bpf/libbpf.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>> index 5fe8aaa2123e..d263748aa341 100644
>>> --- a/tools/lib/bpf/libbpf.c
>>> +++ b/tools/lib/bpf/libbpf.c
>>> @@ -412,6 +412,7 @@ bpf_object__init_prog_names(struct bpf_object
>>> *obj)
>>>prog->section_name);
>>> return -LIBBPF_ERRNO__LIBELF;
>>> }
>>> +   break;
>>
>> why this is needed?
> 
> It was just cosmetic, no related bug.
> 
>> The top of the loop is:
>>  for (si = 0; si < symbols->d_size / sizeof(GElf_Sym) && !name;
>>
>> so as soon as name is found the loop will exit.
> 
> OK, I've missed that. Please disregard this patch.

Ok, please respin the series one last time w/o this patch then.

Please also keep the already given ACKs on the other patches.

Thanks, Eric!

Re: [PATCH 3/4] libbpf: break loop earlier

[Daniel Borkmann]

On 12/27/2017 09:30 PM, Eric Leblond wrote:
> On Wed, 2017-12-27 at 11:00 -0800, Alexei Starovoitov wrote:
>> On Wed, Dec 27, 2017 at 07:02:28PM +0100, Eric Leblond wrote:
>>> Get out of the loop when we have a match.
>>>
>>> Signed-off-by: Eric Leblond 
>>> ---
>>>  tools/lib/bpf/libbpf.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>>> index 5fe8aaa2123e..d263748aa341 100644
>>> --- a/tools/lib/bpf/libbpf.c
>>> +++ b/tools/lib/bpf/libbpf.c
>>> @@ -412,6 +412,7 @@ bpf_object__init_prog_names(struct bpf_object
>>> *obj)
>>>prog->section_name);
>>> return -LIBBPF_ERRNO__LIBELF;
>>> }
>>> +   break;
>>
>> why this is needed?
> 
> It was just cosmetic, no related bug.
> 
>> The top of the loop is:
>>  for (si = 0; si < symbols->d_size / sizeof(GElf_Sym) && !name;
>>
>> so as soon as name is found the loop will exit.
> 
> OK, I've missed that. Please disregard this patch.

Ok, please respin the series one last time w/o this patch then.

Please also keep the already given ACKs on the other patches.

Thanks, Eric!

[PATCH 03/20] nvmem: vf610-ocotp: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/vf610-ocotp.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
index 5ae9e002f195..752a0983e7fb 100644
--- a/drivers/nvmem/vf610-ocotp.c
+++ b/drivers/nvmem/vf610-ocotp.c
@@ -217,13 +217,6 @@ static const struct of_device_id ocotp_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, ocotp_of_match);
 
-static int vf610_ocotp_remove(struct platform_device *pdev)
-{
-   struct vf610_ocotp *ocotp_dev = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(ocotp_dev->nvmem);
-}
-
 static int vf610_ocotp_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -251,13 +244,11 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
ocotp_config.priv = ocotp_dev;
ocotp_config.dev = dev;
 
-   ocotp_dev->nvmem = nvmem_register(_config);
+   ocotp_dev->nvmem = devm_nvmem_register(dev, _config);
if (IS_ERR(ocotp_dev->nvmem))
return PTR_ERR(ocotp_dev->nvmem);
 
ocotp_dev->dev = dev;
-   platform_set_drvdata(pdev, ocotp_dev);
-
ocotp_dev->timing = vf610_ocotp_calculate_timing(ocotp_dev);
 
return 0;
@@ -265,7 +256,6 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
 
 static struct platform_driver vf610_ocotp_driver = {
.probe = vf610_ocotp_probe,
-   .remove = vf610_ocotp_remove,
.driver = {
.name = "vf610-ocotp",
.of_match_table = ocotp_of_match,
-- 
2.14.3

[PATCH 02/20] nvmem: Introduce devm_nvmem_(un)register()

[Andrey Smirnov]

Introduce devm_nvmem_register()/devm_nvmem_unregister() to make
.remove() unnecessary in trivial drivers.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/core.c   | 41 +
 include/linux/nvmem-provider.h | 17 +
 2 files changed, 58 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 57cbeacfbeb2..84f07ba1f36d 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -551,6 +551,47 @@ int nvmem_unregister(struct nvmem_device *nvmem)
 }
 EXPORT_SYMBOL_GPL(nvmem_unregister);
 
+static void devm_nvmem_release(struct device *dev, void *res)
+{
+   WARN_ON(nvmem_unregister(*(struct nvmem_device **)res));
+}
+
+struct nvmem_device *devm_nvmem_register(struct device *dev,
+const struct nvmem_config *config)
+{
+   struct nvmem_device **ptr, *nvmem;
+
+   ptr = devres_alloc(devm_nvmem_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return ERR_PTR(-ENOMEM);
+
+   nvmem = nvmem_register(config);
+
+   if (!IS_ERR(nvmem)) {
+   *ptr = nvmem;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return nvmem;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_register);
+
+static int devm_nvmem_match(struct device *dev, void *res, void *data)
+{
+   struct nvmem_device **r = res;
+
+   return *r == data;
+}
+
+int devm_nvmem_unregister(struct device *dev, struct nvmem_device *nvmem)
+{
+   return devres_release(dev, devm_nvmem_release, devm_nvmem_match, nvmem);
+}
+EXPORT_SYMBOL(devm_nvmem_unregister);
+
+
 static struct nvmem_device *__nvmem_device_get(struct device_node *np,
   struct nvmem_cell **cellp,
   const char *cell_id)
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index 497706f5adca..493f2f529f00 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -47,6 +47,11 @@ struct nvmem_config {
 struct nvmem_device *nvmem_register(const struct nvmem_config *cfg);
 int nvmem_unregister(struct nvmem_device *nvmem);
 
+struct nvmem_device *devm_nvmem_register(struct device *dev,
+const struct nvmem_config *cfg);
+
+int devm_nvmem_unregister(struct device *dev, struct nvmem_device *nvmem);
+
 #else
 
 static inline struct nvmem_device *nvmem_register(const struct nvmem_config *c)
@@ -59,5 +64,17 @@ static inline int nvmem_unregister(struct nvmem_device 
*nvmem)
return -ENOSYS;
 }
 
+static inline struct nvmem_device *
+devm_nvmem_register(struct device *dev, const struct nvmem_config *c)
+{
+   return nvmem_register(c);
+}
+
+static inline int
+devm_nvmem_unregister(struct device *dev, struct nvmem_device *nvmem)
+{
+   return nvmem_unregister(nvmem);
+}
+
 #endif /* CONFIG_NVMEM */
 #endif  /* ifndef _LINUX_NVMEM_PROVIDER_H */
-- 
2.14.3

[PATCH 03/20] nvmem: vf610-ocotp: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/vf610-ocotp.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
index 5ae9e002f195..752a0983e7fb 100644
--- a/drivers/nvmem/vf610-ocotp.c
+++ b/drivers/nvmem/vf610-ocotp.c
@@ -217,13 +217,6 @@ static const struct of_device_id ocotp_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, ocotp_of_match);
 
-static int vf610_ocotp_remove(struct platform_device *pdev)
-{
-   struct vf610_ocotp *ocotp_dev = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(ocotp_dev->nvmem);
-}
-
 static int vf610_ocotp_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -251,13 +244,11 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
ocotp_config.priv = ocotp_dev;
ocotp_config.dev = dev;
 
-   ocotp_dev->nvmem = nvmem_register(_config);
+   ocotp_dev->nvmem = devm_nvmem_register(dev, _config);
if (IS_ERR(ocotp_dev->nvmem))
return PTR_ERR(ocotp_dev->nvmem);
 
ocotp_dev->dev = dev;
-   platform_set_drvdata(pdev, ocotp_dev);
-
ocotp_dev->timing = vf610_ocotp_calculate_timing(ocotp_dev);
 
return 0;
@@ -265,7 +256,6 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
 
 static struct platform_driver vf610_ocotp_driver = {
.probe = vf610_ocotp_probe,
-   .remove = vf610_ocotp_remove,
.driver = {
.name = "vf610-ocotp",
.of_match_table = ocotp_of_match,
-- 
2.14.3

[PATCH 02/20] nvmem: Introduce devm_nvmem_(un)register()

[Andrey Smirnov]

Introduce devm_nvmem_register()/devm_nvmem_unregister() to make
.remove() unnecessary in trivial drivers.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/core.c   | 41 +
 include/linux/nvmem-provider.h | 17 +
 2 files changed, 58 insertions(+)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 57cbeacfbeb2..84f07ba1f36d 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -551,6 +551,47 @@ int nvmem_unregister(struct nvmem_device *nvmem)
 }
 EXPORT_SYMBOL_GPL(nvmem_unregister);
 
+static void devm_nvmem_release(struct device *dev, void *res)
+{
+   WARN_ON(nvmem_unregister(*(struct nvmem_device **)res));
+}
+
+struct nvmem_device *devm_nvmem_register(struct device *dev,
+const struct nvmem_config *config)
+{
+   struct nvmem_device **ptr, *nvmem;
+
+   ptr = devres_alloc(devm_nvmem_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return ERR_PTR(-ENOMEM);
+
+   nvmem = nvmem_register(config);
+
+   if (!IS_ERR(nvmem)) {
+   *ptr = nvmem;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return nvmem;
+}
+EXPORT_SYMBOL_GPL(devm_nvmem_register);
+
+static int devm_nvmem_match(struct device *dev, void *res, void *data)
+{
+   struct nvmem_device **r = res;
+
+   return *r == data;
+}
+
+int devm_nvmem_unregister(struct device *dev, struct nvmem_device *nvmem)
+{
+   return devres_release(dev, devm_nvmem_release, devm_nvmem_match, nvmem);
+}
+EXPORT_SYMBOL(devm_nvmem_unregister);
+
+
 static struct nvmem_device *__nvmem_device_get(struct device_node *np,
   struct nvmem_cell **cellp,
   const char *cell_id)
diff --git a/include/linux/nvmem-provider.h b/include/linux/nvmem-provider.h
index 497706f5adca..493f2f529f00 100644
--- a/include/linux/nvmem-provider.h
+++ b/include/linux/nvmem-provider.h
@@ -47,6 +47,11 @@ struct nvmem_config {
 struct nvmem_device *nvmem_register(const struct nvmem_config *cfg);
 int nvmem_unregister(struct nvmem_device *nvmem);
 
+struct nvmem_device *devm_nvmem_register(struct device *dev,
+const struct nvmem_config *cfg);
+
+int devm_nvmem_unregister(struct device *dev, struct nvmem_device *nvmem);
+
 #else
 
 static inline struct nvmem_device *nvmem_register(const struct nvmem_config *c)
@@ -59,5 +64,17 @@ static inline int nvmem_unregister(struct nvmem_device 
*nvmem)
return -ENOSYS;
 }
 
+static inline struct nvmem_device *
+devm_nvmem_register(struct device *dev, const struct nvmem_config *c)
+{
+   return nvmem_register(c);
+}
+
+static inline int
+devm_nvmem_unregister(struct device *dev, struct nvmem_device *nvmem)
+{
+   return nvmem_unregister(nvmem);
+}
+
 #endif /* CONFIG_NVMEM */
 #endif  /* ifndef _LINUX_NVMEM_PROVIDER_H */
-- 
2.14.3

[PATCH 04/20] nvmem: imx-ocotp: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/imx-ocotp.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index d7ba351a70c9..68deffe636f3 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -466,26 +466,16 @@ static int imx_ocotp_probe(struct platform_device *pdev)
imx_ocotp_nvmem_config.dev = dev;
imx_ocotp_nvmem_config.priv = priv;
priv->config = _ocotp_nvmem_config;
-   nvmem = nvmem_register(_ocotp_nvmem_config);
+   nvmem = devm_nvmem_register(dev, _ocotp_nvmem_config);
 
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int imx_ocotp_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver imx_ocotp_driver = {
.probe  = imx_ocotp_probe,
-   .remove = imx_ocotp_remove,
.driver = {
.name   = "imx_ocotp",
.of_match_table = imx_ocotp_dt_ids,
-- 
2.14.3

[PATCH 04/20] nvmem: imx-ocotp: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/imx-ocotp.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/imx-ocotp.c b/drivers/nvmem/imx-ocotp.c
index d7ba351a70c9..68deffe636f3 100644
--- a/drivers/nvmem/imx-ocotp.c
+++ b/drivers/nvmem/imx-ocotp.c
@@ -466,26 +466,16 @@ static int imx_ocotp_probe(struct platform_device *pdev)
imx_ocotp_nvmem_config.dev = dev;
imx_ocotp_nvmem_config.priv = priv;
priv->config = _ocotp_nvmem_config;
-   nvmem = nvmem_register(_ocotp_nvmem_config);
+   nvmem = devm_nvmem_register(dev, _ocotp_nvmem_config);
 
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int imx_ocotp_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver imx_ocotp_driver = {
.probe  = imx_ocotp_probe,
-   .remove = imx_ocotp_remove,
.driver = {
.name   = "imx_ocotp",
.of_match_table = imx_ocotp_dt_ids,
-- 
2.14.3

[PATCH 06/20] nvmem: snvs_lgpr: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/snvs_lpgpr.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/snvs_lpgpr.c b/drivers/nvmem/snvs_lpgpr.c
index e5c2a4a17f03..6a2fdd09e74a 100644
--- a/drivers/nvmem/snvs_lpgpr.c
+++ b/drivers/nvmem/snvs_lpgpr.c
@@ -117,22 +117,13 @@ static int snvs_lpgpr_probe(struct platform_device *pdev)
cfg->reg_read  = snvs_lpgpr_read,
cfg->reg_write = snvs_lpgpr_write,
 
-   nvmem = nvmem_register(cfg);
+   nvmem = devm_nvmem_register(dev, cfg);
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int snvs_lpgpr_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static const struct of_device_id snvs_lpgpr_dt_ids[] = {
{ .compatible = "fsl,imx6q-snvs-lpgpr", .data = _lpgpr_cfg_imx6q },
{ .compatible = "fsl,imx6ul-snvs-lpgpr",
@@ -143,7 +134,6 @@ MODULE_DEVICE_TABLE(of, snvs_lpgpr_dt_ids);
 
 static struct platform_driver snvs_lpgpr_driver = {
.probe  = snvs_lpgpr_probe,
-   .remove = snvs_lpgpr_remove,
.driver = {
.name   = "snvs_lpgpr",
.of_match_table = snvs_lpgpr_dt_ids,
-- 
2.14.3

[PATCH 06/20] nvmem: snvs_lgpr: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/snvs_lpgpr.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/snvs_lpgpr.c b/drivers/nvmem/snvs_lpgpr.c
index e5c2a4a17f03..6a2fdd09e74a 100644
--- a/drivers/nvmem/snvs_lpgpr.c
+++ b/drivers/nvmem/snvs_lpgpr.c
@@ -117,22 +117,13 @@ static int snvs_lpgpr_probe(struct platform_device *pdev)
cfg->reg_read  = snvs_lpgpr_read,
cfg->reg_write = snvs_lpgpr_write,
 
-   nvmem = nvmem_register(cfg);
+   nvmem = devm_nvmem_register(dev, cfg);
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int snvs_lpgpr_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static const struct of_device_id snvs_lpgpr_dt_ids[] = {
{ .compatible = "fsl,imx6q-snvs-lpgpr", .data = _lpgpr_cfg_imx6q },
{ .compatible = "fsl,imx6ul-snvs-lpgpr",
@@ -143,7 +134,6 @@ MODULE_DEVICE_TABLE(of, snvs_lpgpr_dt_ids);
 
 static struct platform_driver snvs_lpgpr_driver = {
.probe  = snvs_lpgpr_probe,
-   .remove = snvs_lpgpr_remove,
.driver = {
.name   = "snvs_lpgpr",
.of_match_table = snvs_lpgpr_dt_ids,
-- 
2.14.3

[PATCH 00/20] Verbatim device names and devm_nvmem_(un)register()

[Andrey Smirnov]

Srinivas, all:

This patchset contains various small changes that I recently made to
NVMEM, more specifically:

 - Patches 1 and 2 are two changes I am hoping are acceptable upstream

 - Patches 3 to 14 are a follow up to patch 2

 - Patches 15 to 20 are just trivial fixups and I am more than happy
   to drop them if they seem to add more pointless churn rather then
   value.

Feedback is appreciated!

Thanks,
Andrey Smirnov

Andrey Smirnov (20):
  nvmem: core: Allow specifying device name verbatim
  nvmem: Introduce devm_nvmem_(un)register()
  nvmem: vf610-ocotp: Convert to use devm_nvmem_register()
  nvmem: imx-ocotp: Convert to use devm_nvmem_register()
  nvmem: uniphier-efuse: Convert to use devm_nvmem_register()
  nvmem: snvs_lgpr: Convert to use devm_nvmem_register()
  nvmem: rockchip-efuse: Convert to use devm_nvmem_register()
  nvmem: qfprom: Convert to use devm_nvmem_register()
  nvmem: mtk-efuse: Convert to use devm_nvmem_register()
  nvmem: meson-mx-efuse: Convert to use devm_nvmem_register()
  nvmem: meson-efuse: Convert to use devm_nvmem_register()
  nvmem: lpc18xx_otp: Convert to use devm_nvmem_register()
  nvmem: imx-iim: Convert to use devm_nvmem_register()
  nvmem: bcm-ocotp: Convert to use devm_nvmem_register()
  nvmem: snvs_lpgpr: Convert commas to semicolons
  nvmem: rockchip-efuse: Make use of of_device_get_match_data()
  nvmem: vf610-ocotp: Do not use ">dev" explicitly
  nvmem: rockchip-efuse: Do not use ">dev" explicitly
  nvmem: imx-iim: Do not use ">dev" explicitly
  nvmem: bcm-ocotp: Do not use ">dev" explicitly

 drivers/nvmem/bcm-ocotp.c  | 15 ++--
 drivers/nvmem/core.c   | 52 +++---
 drivers/nvmem/imx-iim.c| 14 ++--
 drivers/nvmem/imx-ocotp.c  | 12 +-
 drivers/nvmem/lpc18xx_otp.c| 12 +-
 drivers/nvmem/meson-efuse.c| 11 +
 drivers/nvmem/meson-mx-efuse.c | 12 +-
 drivers/nvmem/mtk-efuse.c  | 12 +-
 drivers/nvmem/qfprom.c | 12 +-
 drivers/nvmem/rockchip-efuse.c | 28 ---
 drivers/nvmem/snvs_lpgpr.c | 26 +++--
 drivers/nvmem/uniphier-efuse.c | 12 +-
 drivers/nvmem/vf610-ocotp.c| 15 ++--
 include/linux/nvmem-provider.h | 17 ++
 14 files changed, 96 insertions(+), 154 deletions(-)

-- 
2.14.3

[PATCH 18/20] nvmem: rockchip-efuse: Do not use ">dev" explicitly

[Andrey Smirnov]

There's "dev" variable for this already. Use it.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/rockchip-efuse.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
index 979ba0a376a0..3120329aea94 100644
--- a/drivers/nvmem/rockchip-efuse.c
+++ b/drivers/nvmem/rockchip-efuse.c
@@ -202,21 +202,21 @@ static int rockchip_efuse_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   efuse = devm_kzalloc(>dev, sizeof(struct rockchip_efuse_chip),
+   efuse = devm_kzalloc(dev, sizeof(struct rockchip_efuse_chip),
 GFP_KERNEL);
if (!efuse)
return -ENOMEM;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   efuse->base = devm_ioremap_resource(>dev, res);
+   efuse->base = devm_ioremap_resource(dev, res);
if (IS_ERR(efuse->base))
return PTR_ERR(efuse->base);
 
-   efuse->clk = devm_clk_get(>dev, "pclk_efuse");
+   efuse->clk = devm_clk_get(dev, "pclk_efuse");
if (IS_ERR(efuse->clk))
return PTR_ERR(efuse->clk);
 
-   efuse->dev = >dev;
+   efuse->dev = dev;
econfig.size = resource_size(res);
econfig.reg_read = data;
econfig.priv = efuse;
-- 
2.14.3

[PATCH 10/20] nvmem: meson-mx-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/meson-mx-efuse.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/meson-mx-efuse.c b/drivers/nvmem/meson-mx-efuse.c
index a346b4923550..f8e0b92e40ba 100644
--- a/drivers/nvmem/meson-mx-efuse.c
+++ b/drivers/nvmem/meson-mx-efuse.c
@@ -233,25 +233,15 @@ static int meson_mx_efuse_probe(struct platform_device 
*pdev)
return PTR_ERR(efuse->core_clk);
}
 
-   efuse->nvmem = nvmem_register(>config);
+   efuse->nvmem = devm_nvmem_register(>dev, >config);
if (IS_ERR(efuse->nvmem))
return PTR_ERR(efuse->nvmem);
 
-   platform_set_drvdata(pdev, efuse);
-
return 0;
 }
 
-static int meson_mx_efuse_remove(struct platform_device *pdev)
-{
-   struct meson_mx_efuse *efuse = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(efuse->nvmem);
-}
-
 static struct platform_driver meson_mx_efuse_driver = {
.probe = meson_mx_efuse_probe,
-   .remove = meson_mx_efuse_remove,
.driver = {
.name = "meson-mx-efuse",
.of_match_table = meson_mx_efuse_match,
-- 
2.14.3

[PATCH 12/20] nvmem: lpc18xx_otp: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/lpc18xx_otp.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/lpc18xx_otp.c b/drivers/nvmem/lpc18xx_otp.c
index 95268db155e9..74777bfe2dcd 100644
--- a/drivers/nvmem/lpc18xx_otp.c
+++ b/drivers/nvmem/lpc18xx_otp.c
@@ -86,22 +86,13 @@ static int lpc18xx_otp_probe(struct platform_device *pdev)
lpc18xx_otp_nvmem_config.dev = >dev;
lpc18xx_otp_nvmem_config.priv = otp;
 
-   nvmem = nvmem_register(_otp_nvmem_config);
+   nvmem = devm_nvmem_register(>dev, _otp_nvmem_config);
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int lpc18xx_otp_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static const struct of_device_id lpc18xx_otp_dt_ids[] = {
{ .compatible = "nxp,lpc1850-otp" },
{ },
@@ -110,7 +101,6 @@ MODULE_DEVICE_TABLE(of, lpc18xx_otp_dt_ids);
 
 static struct platform_driver lpc18xx_otp_driver = {
.probe  = lpc18xx_otp_probe,
-   .remove = lpc18xx_otp_remove,
.driver = {
.name   = "lpc18xx_otp",
.of_match_table = lpc18xx_otp_dt_ids,
-- 
2.14.3

[PATCH 00/20] Verbatim device names and devm_nvmem_(un)register()

[Andrey Smirnov]

Srinivas, all:

This patchset contains various small changes that I recently made to
NVMEM, more specifically:

 - Patches 1 and 2 are two changes I am hoping are acceptable upstream

 - Patches 3 to 14 are a follow up to patch 2

 - Patches 15 to 20 are just trivial fixups and I am more than happy
   to drop them if they seem to add more pointless churn rather then
   value.

Feedback is appreciated!

Thanks,
Andrey Smirnov

Andrey Smirnov (20):
  nvmem: core: Allow specifying device name verbatim
  nvmem: Introduce devm_nvmem_(un)register()
  nvmem: vf610-ocotp: Convert to use devm_nvmem_register()
  nvmem: imx-ocotp: Convert to use devm_nvmem_register()
  nvmem: uniphier-efuse: Convert to use devm_nvmem_register()
  nvmem: snvs_lgpr: Convert to use devm_nvmem_register()
  nvmem: rockchip-efuse: Convert to use devm_nvmem_register()
  nvmem: qfprom: Convert to use devm_nvmem_register()
  nvmem: mtk-efuse: Convert to use devm_nvmem_register()
  nvmem: meson-mx-efuse: Convert to use devm_nvmem_register()
  nvmem: meson-efuse: Convert to use devm_nvmem_register()
  nvmem: lpc18xx_otp: Convert to use devm_nvmem_register()
  nvmem: imx-iim: Convert to use devm_nvmem_register()
  nvmem: bcm-ocotp: Convert to use devm_nvmem_register()
  nvmem: snvs_lpgpr: Convert commas to semicolons
  nvmem: rockchip-efuse: Make use of of_device_get_match_data()
  nvmem: vf610-ocotp: Do not use ">dev" explicitly
  nvmem: rockchip-efuse: Do not use ">dev" explicitly
  nvmem: imx-iim: Do not use ">dev" explicitly
  nvmem: bcm-ocotp: Do not use ">dev" explicitly

 drivers/nvmem/bcm-ocotp.c  | 15 ++--
 drivers/nvmem/core.c   | 52 +++---
 drivers/nvmem/imx-iim.c| 14 ++--
 drivers/nvmem/imx-ocotp.c  | 12 +-
 drivers/nvmem/lpc18xx_otp.c| 12 +-
 drivers/nvmem/meson-efuse.c| 11 +
 drivers/nvmem/meson-mx-efuse.c | 12 +-
 drivers/nvmem/mtk-efuse.c  | 12 +-
 drivers/nvmem/qfprom.c | 12 +-
 drivers/nvmem/rockchip-efuse.c | 28 ---
 drivers/nvmem/snvs_lpgpr.c | 26 +++--
 drivers/nvmem/uniphier-efuse.c | 12 +-
 drivers/nvmem/vf610-ocotp.c| 15 ++--
 include/linux/nvmem-provider.h | 17 ++
 14 files changed, 96 insertions(+), 154 deletions(-)

-- 
2.14.3

[PATCH 18/20] nvmem: rockchip-efuse: Do not use ">dev" explicitly

[Andrey Smirnov]

There's "dev" variable for this already. Use it.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/rockchip-efuse.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
index 979ba0a376a0..3120329aea94 100644
--- a/drivers/nvmem/rockchip-efuse.c
+++ b/drivers/nvmem/rockchip-efuse.c
@@ -202,21 +202,21 @@ static int rockchip_efuse_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   efuse = devm_kzalloc(>dev, sizeof(struct rockchip_efuse_chip),
+   efuse = devm_kzalloc(dev, sizeof(struct rockchip_efuse_chip),
 GFP_KERNEL);
if (!efuse)
return -ENOMEM;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   efuse->base = devm_ioremap_resource(>dev, res);
+   efuse->base = devm_ioremap_resource(dev, res);
if (IS_ERR(efuse->base))
return PTR_ERR(efuse->base);
 
-   efuse->clk = devm_clk_get(>dev, "pclk_efuse");
+   efuse->clk = devm_clk_get(dev, "pclk_efuse");
if (IS_ERR(efuse->clk))
return PTR_ERR(efuse->clk);
 
-   efuse->dev = >dev;
+   efuse->dev = dev;
econfig.size = resource_size(res);
econfig.reg_read = data;
econfig.priv = efuse;
-- 
2.14.3

[PATCH 10/20] nvmem: meson-mx-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/meson-mx-efuse.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/meson-mx-efuse.c b/drivers/nvmem/meson-mx-efuse.c
index a346b4923550..f8e0b92e40ba 100644
--- a/drivers/nvmem/meson-mx-efuse.c
+++ b/drivers/nvmem/meson-mx-efuse.c
@@ -233,25 +233,15 @@ static int meson_mx_efuse_probe(struct platform_device 
*pdev)
return PTR_ERR(efuse->core_clk);
}
 
-   efuse->nvmem = nvmem_register(>config);
+   efuse->nvmem = devm_nvmem_register(>dev, >config);
if (IS_ERR(efuse->nvmem))
return PTR_ERR(efuse->nvmem);
 
-   platform_set_drvdata(pdev, efuse);
-
return 0;
 }
 
-static int meson_mx_efuse_remove(struct platform_device *pdev)
-{
-   struct meson_mx_efuse *efuse = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(efuse->nvmem);
-}
-
 static struct platform_driver meson_mx_efuse_driver = {
.probe = meson_mx_efuse_probe,
-   .remove = meson_mx_efuse_remove,
.driver = {
.name = "meson-mx-efuse",
.of_match_table = meson_mx_efuse_match,
-- 
2.14.3

[PATCH 12/20] nvmem: lpc18xx_otp: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/lpc18xx_otp.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/lpc18xx_otp.c b/drivers/nvmem/lpc18xx_otp.c
index 95268db155e9..74777bfe2dcd 100644
--- a/drivers/nvmem/lpc18xx_otp.c
+++ b/drivers/nvmem/lpc18xx_otp.c
@@ -86,22 +86,13 @@ static int lpc18xx_otp_probe(struct platform_device *pdev)
lpc18xx_otp_nvmem_config.dev = >dev;
lpc18xx_otp_nvmem_config.priv = otp;
 
-   nvmem = nvmem_register(_otp_nvmem_config);
+   nvmem = devm_nvmem_register(>dev, _otp_nvmem_config);
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int lpc18xx_otp_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static const struct of_device_id lpc18xx_otp_dt_ids[] = {
{ .compatible = "nxp,lpc1850-otp" },
{ },
@@ -110,7 +101,6 @@ MODULE_DEVICE_TABLE(of, lpc18xx_otp_dt_ids);
 
 static struct platform_driver lpc18xx_otp_driver = {
.probe  = lpc18xx_otp_probe,
-   .remove = lpc18xx_otp_remove,
.driver = {
.name   = "lpc18xx_otp",
.of_match_table = lpc18xx_otp_dt_ids,
-- 
2.14.3

[PATCH 11/20] nvmem: meson-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/meson-efuse.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/nvmem/meson-efuse.c b/drivers/nvmem/meson-efuse.c
index a43c68f90937..02ec2873e583 100644
--- a/drivers/nvmem/meson-efuse.c
+++ b/drivers/nvmem/meson-efuse.c
@@ -60,22 +60,13 @@ static int meson_efuse_probe(struct platform_device *pdev)
econfig.reg_read = meson_efuse_read;
econfig.size = size;
 
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(>dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int meson_efuse_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver meson_efuse_driver = {
.probe = meson_efuse_probe,
.remove = meson_efuse_remove,
-- 
2.14.3

[PATCH 15/20] nvmem: snvs_lpgpr: Convert commas to semicolons

[Andrey Smirnov]

Looks like commas were accidentally used where semicolons were
supposed to be. Fix that.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/snvs_lpgpr.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/nvmem/snvs_lpgpr.c b/drivers/nvmem/snvs_lpgpr.c
index 6a2fdd09e74a..90aaf818563b 100644
--- a/drivers/nvmem/snvs_lpgpr.c
+++ b/drivers/nvmem/snvs_lpgpr.c
@@ -110,12 +110,12 @@ static int snvs_lpgpr_probe(struct platform_device *pdev)
cfg->priv = priv;
cfg->name = dev_name(dev);
cfg->dev = dev;
-   cfg->stride = 4,
-   cfg->word_size = 4,
-   cfg->size = 4,
-   cfg->owner = THIS_MODULE,
-   cfg->reg_read  = snvs_lpgpr_read,
-   cfg->reg_write = snvs_lpgpr_write,
+   cfg->stride = 4;
+   cfg->word_size = 4;
+   cfg->size = 4;
+   cfg->owner = THIS_MODULE;
+   cfg->reg_read  = snvs_lpgpr_read;
+   cfg->reg_write = snvs_lpgpr_write;
 
nvmem = devm_nvmem_register(dev, cfg);
if (IS_ERR(nvmem))
-- 
2.14.3

[PATCH 19/20] nvmem: imx-iim: Do not use ">dev" explicitly

[Andrey Smirnov]

There's already "dev" variable for that. Use it.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/imx-iim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvmem/imx-iim.c b/drivers/nvmem/imx-iim.c
index 635561a441bd..3022bd96bd7e 100644
--- a/drivers/nvmem/imx-iim.c
+++ b/drivers/nvmem/imx-iim.c
@@ -125,7 +125,7 @@ static int imx_iim_probe(struct platform_device *pdev)
 
drvdata = of_id->data;
 
-   iim->clk = devm_clk_get(>dev, NULL);
+   iim->clk = devm_clk_get(dev, NULL);
if (IS_ERR(iim->clk))
return PTR_ERR(iim->clk);
 
-- 
2.14.3

[PATCH 09/20] nvmem: mtk-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/mtk-efuse.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
index 9ee3479cfc7b..97ab7e6a4789 100644
--- a/drivers/nvmem/mtk-efuse.c
+++ b/drivers/nvmem/mtk-efuse.c
@@ -72,22 +72,13 @@ static int mtk_efuse_probe(struct platform_device *pdev)
econfig.size = resource_size(res);
econfig.priv = priv;
econfig.dev = dev;
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int mtk_efuse_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static const struct of_device_id mtk_efuse_of_match[] = {
{ .compatible = "mediatek,mt8173-efuse",},
{ .compatible = "mediatek,efuse",},
@@ -97,7 +88,6 @@ MODULE_DEVICE_TABLE(of, mtk_efuse_of_match);
 
 static struct platform_driver mtk_efuse_driver = {
.probe = mtk_efuse_probe,
-   .remove = mtk_efuse_remove,
.driver = {
.name = "mediatek,efuse",
.of_match_table = mtk_efuse_of_match,
-- 
2.14.3

[PATCH 01/20] nvmem: core: Allow specifying device name verbatim

[Andrey Smirnov]

Add code to allow avoid having nvmem core append a numeric suffix to
the end of the name by passing config->id of -1.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/core.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 5a5cefd12153..57cbeacfbeb2 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -475,9 +475,14 @@ struct nvmem_device *nvmem_register(const struct 
nvmem_config *config)
nvmem->reg_write = config->reg_write;
np = config->dev->of_node;
nvmem->dev.of_node = np;
-   dev_set_name(>dev, "%s%d",
-config->name ? : "nvmem",
-config->name ? config->id : nvmem->id);
+
+   if (config->id == -1 && config->name) {
+   dev_set_name(>dev, "%s", config->name);
+   } else {
+   dev_set_name(>dev, "%s%d",
+config->name ? : "nvmem",
+config->name ? config->id : nvmem->id);
+   }
 
nvmem->read_only = of_property_read_bool(np, "read-only") |
   config->read_only;
-- 
2.14.3

[PATCH 14/20] nvmem: bcm-ocotp: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/bcm-ocotp.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
index 5e9e324427f9..24c30fa475cc 100644
--- a/drivers/nvmem/bcm-ocotp.c
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -302,27 +302,17 @@ static int bcm_otpc_probe(struct platform_device *pdev)
 
priv->config = _otpc_nvmem_config;
 
-   nvmem = nvmem_register(_otpc_nvmem_config);
+   nvmem = devm_nvmem_register(dev, _otpc_nvmem_config);
if (IS_ERR(nvmem)) {
dev_err(dev, "error registering nvmem config\n");
return PTR_ERR(nvmem);
}
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int bcm_otpc_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver bcm_otpc_driver = {
.probe  = bcm_otpc_probe,
-   .remove = bcm_otpc_remove,
.driver = {
.name   = "brcm-otpc",
.of_match_table = bcm_otpc_dt_ids,
-- 
2.14.3

[PATCH 15/20] nvmem: snvs_lpgpr: Convert commas to semicolons

[Andrey Smirnov]

Looks like commas were accidentally used where semicolons were
supposed to be. Fix that.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/snvs_lpgpr.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/nvmem/snvs_lpgpr.c b/drivers/nvmem/snvs_lpgpr.c
index 6a2fdd09e74a..90aaf818563b 100644
--- a/drivers/nvmem/snvs_lpgpr.c
+++ b/drivers/nvmem/snvs_lpgpr.c
@@ -110,12 +110,12 @@ static int snvs_lpgpr_probe(struct platform_device *pdev)
cfg->priv = priv;
cfg->name = dev_name(dev);
cfg->dev = dev;
-   cfg->stride = 4,
-   cfg->word_size = 4,
-   cfg->size = 4,
-   cfg->owner = THIS_MODULE,
-   cfg->reg_read  = snvs_lpgpr_read,
-   cfg->reg_write = snvs_lpgpr_write,
+   cfg->stride = 4;
+   cfg->word_size = 4;
+   cfg->size = 4;
+   cfg->owner = THIS_MODULE;
+   cfg->reg_read  = snvs_lpgpr_read;
+   cfg->reg_write = snvs_lpgpr_write;
 
nvmem = devm_nvmem_register(dev, cfg);
if (IS_ERR(nvmem))
-- 
2.14.3

[PATCH 19/20] nvmem: imx-iim: Do not use ">dev" explicitly

[Andrey Smirnov]

There's already "dev" variable for that. Use it.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/imx-iim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/nvmem/imx-iim.c b/drivers/nvmem/imx-iim.c
index 635561a441bd..3022bd96bd7e 100644
--- a/drivers/nvmem/imx-iim.c
+++ b/drivers/nvmem/imx-iim.c
@@ -125,7 +125,7 @@ static int imx_iim_probe(struct platform_device *pdev)
 
drvdata = of_id->data;
 
-   iim->clk = devm_clk_get(>dev, NULL);
+   iim->clk = devm_clk_get(dev, NULL);
if (IS_ERR(iim->clk))
return PTR_ERR(iim->clk);
 
-- 
2.14.3

[PATCH 09/20] nvmem: mtk-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/mtk-efuse.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
index 9ee3479cfc7b..97ab7e6a4789 100644
--- a/drivers/nvmem/mtk-efuse.c
+++ b/drivers/nvmem/mtk-efuse.c
@@ -72,22 +72,13 @@ static int mtk_efuse_probe(struct platform_device *pdev)
econfig.size = resource_size(res);
econfig.priv = priv;
econfig.dev = dev;
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int mtk_efuse_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static const struct of_device_id mtk_efuse_of_match[] = {
{ .compatible = "mediatek,mt8173-efuse",},
{ .compatible = "mediatek,efuse",},
@@ -97,7 +88,6 @@ MODULE_DEVICE_TABLE(of, mtk_efuse_of_match);
 
 static struct platform_driver mtk_efuse_driver = {
.probe = mtk_efuse_probe,
-   .remove = mtk_efuse_remove,
.driver = {
.name = "mediatek,efuse",
.of_match_table = mtk_efuse_of_match,
-- 
2.14.3

[PATCH 01/20] nvmem: core: Allow specifying device name verbatim

[Andrey Smirnov]

Add code to allow avoid having nvmem core append a numeric suffix to
the end of the name by passing config->id of -1.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/core.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 5a5cefd12153..57cbeacfbeb2 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -475,9 +475,14 @@ struct nvmem_device *nvmem_register(const struct 
nvmem_config *config)
nvmem->reg_write = config->reg_write;
np = config->dev->of_node;
nvmem->dev.of_node = np;
-   dev_set_name(>dev, "%s%d",
-config->name ? : "nvmem",
-config->name ? config->id : nvmem->id);
+
+   if (config->id == -1 && config->name) {
+   dev_set_name(>dev, "%s", config->name);
+   } else {
+   dev_set_name(>dev, "%s%d",
+config->name ? : "nvmem",
+config->name ? config->id : nvmem->id);
+   }
 
nvmem->read_only = of_property_read_bool(np, "read-only") |
   config->read_only;
-- 
2.14.3

[PATCH 14/20] nvmem: bcm-ocotp: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/bcm-ocotp.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
index 5e9e324427f9..24c30fa475cc 100644
--- a/drivers/nvmem/bcm-ocotp.c
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -302,27 +302,17 @@ static int bcm_otpc_probe(struct platform_device *pdev)
 
priv->config = _otpc_nvmem_config;
 
-   nvmem = nvmem_register(_otpc_nvmem_config);
+   nvmem = devm_nvmem_register(dev, _otpc_nvmem_config);
if (IS_ERR(nvmem)) {
dev_err(dev, "error registering nvmem config\n");
return PTR_ERR(nvmem);
}
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int bcm_otpc_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver bcm_otpc_driver = {
.probe  = bcm_otpc_probe,
-   .remove = bcm_otpc_remove,
.driver = {
.name   = "brcm-otpc",
.of_match_table = bcm_otpc_dt_ids,
-- 
2.14.3

[PATCH 11/20] nvmem: meson-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/meson-efuse.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/nvmem/meson-efuse.c b/drivers/nvmem/meson-efuse.c
index a43c68f90937..02ec2873e583 100644
--- a/drivers/nvmem/meson-efuse.c
+++ b/drivers/nvmem/meson-efuse.c
@@ -60,22 +60,13 @@ static int meson_efuse_probe(struct platform_device *pdev)
econfig.reg_read = meson_efuse_read;
econfig.size = size;
 
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(>dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int meson_efuse_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver meson_efuse_driver = {
.probe = meson_efuse_probe,
.remove = meson_efuse_remove,
-- 
2.14.3

[PATCH 17/20] nvmem: vf610-ocotp: Do not use ">dev" explicitly

[Andrey Smirnov]

There already a "dev" variable for that. Use it.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/vf610-ocotp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
index 752a0983e7fb..6e6bf7987d9d 100644
--- a/drivers/nvmem/vf610-ocotp.c
+++ b/drivers/nvmem/vf610-ocotp.c
@@ -223,8 +223,7 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
struct resource *res;
struct vf610_ocotp *ocotp_dev;
 
-   ocotp_dev = devm_kzalloc(>dev,
-   sizeof(struct vf610_ocotp), GFP_KERNEL);
+   ocotp_dev = devm_kzalloc(dev, sizeof(struct vf610_ocotp), GFP_KERNEL);
if (!ocotp_dev)
return -ENOMEM;
 
-- 
2.14.3

[PATCH 20/20] nvmem: bcm-ocotp: Do not use ">dev" explicitly

[Andrey Smirnov]

There's "dev" variable for this already. Use it.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/bcm-ocotp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
index 24c30fa475cc..4159b3f41d79 100644
--- a/drivers/nvmem/bcm-ocotp.c
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -262,8 +262,7 @@ static int bcm_otpc_probe(struct platform_device *pdev)
else if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2"))
priv->map = _map_v2;
else {
-   dev_err(>dev,
-   "%s otpc config map not defined\n", __func__);
+   dev_err(dev, "%s otpc config map not defined\n", __func__);
return -EINVAL;
}
 
-- 
2.14.3

[PATCH 16/20] nvmem: rockchip-efuse: Make use of of_device_get_match_data()

[Andrey Smirnov]

Simplify code a bit by using of_device_get_match_data() instead of
of_match_device().

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/rockchip-efuse.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
index d6dc1330f895..979ba0a376a0 100644
--- a/drivers/nvmem/rockchip-efuse.c
+++ b/drivers/nvmem/rockchip-efuse.c
@@ -193,11 +193,11 @@ static int rockchip_efuse_probe(struct platform_device 
*pdev)
struct resource *res;
struct nvmem_device *nvmem;
struct rockchip_efuse_chip *efuse;
-   const struct of_device_id *match;
+   const void *data;
struct device *dev = >dev;
 
-   match = of_match_device(dev->driver->of_match_table, dev);
-   if (!match || !match->data) {
+   data = of_device_get_match_data(dev);
+   if (!data) {
dev_err(dev, "failed to get match data\n");
return -EINVAL;
}
@@ -218,7 +218,7 @@ static int rockchip_efuse_probe(struct platform_device 
*pdev)
 
efuse->dev = >dev;
econfig.size = resource_size(res);
-   econfig.reg_read = match->data;
+   econfig.reg_read = data;
econfig.priv = efuse;
econfig.dev = efuse->dev;
nvmem = devm_nvmem_register(dev, );
-- 
2.14.3

[PATCH 05/20] nvmem: uniphier-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/uniphier-efuse.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
index 9d278b4e1dc7..7ddc6fc012c9 100644
--- a/drivers/nvmem/uniphier-efuse.c
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -60,22 +60,13 @@ static int uniphier_efuse_probe(struct platform_device 
*pdev)
econfig.size = resource_size(res);
econfig.priv = priv;
econfig.dev = dev;
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int uniphier_efuse_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static const struct of_device_id uniphier_efuse_of_match[] = {
{ .compatible = "socionext,uniphier-efuse",},
{/* sentinel */},
@@ -84,7 +75,6 @@ MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);
 
 static struct platform_driver uniphier_efuse_driver = {
.probe = uniphier_efuse_probe,
-   .remove = uniphier_efuse_remove,
.driver = {
.name = "uniphier-efuse",
.of_match_table = uniphier_efuse_of_match,
-- 
2.14.3

[PATCH 17/20] nvmem: vf610-ocotp: Do not use ">dev" explicitly

[Andrey Smirnov]

There already a "dev" variable for that. Use it.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/vf610-ocotp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
index 752a0983e7fb..6e6bf7987d9d 100644
--- a/drivers/nvmem/vf610-ocotp.c
+++ b/drivers/nvmem/vf610-ocotp.c
@@ -223,8 +223,7 @@ static int vf610_ocotp_probe(struct platform_device *pdev)
struct resource *res;
struct vf610_ocotp *ocotp_dev;
 
-   ocotp_dev = devm_kzalloc(>dev,
-   sizeof(struct vf610_ocotp), GFP_KERNEL);
+   ocotp_dev = devm_kzalloc(dev, sizeof(struct vf610_ocotp), GFP_KERNEL);
if (!ocotp_dev)
return -ENOMEM;
 
-- 
2.14.3

[PATCH 20/20] nvmem: bcm-ocotp: Do not use ">dev" explicitly

[Andrey Smirnov]

There's "dev" variable for this already. Use it.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/bcm-ocotp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
index 24c30fa475cc..4159b3f41d79 100644
--- a/drivers/nvmem/bcm-ocotp.c
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -262,8 +262,7 @@ static int bcm_otpc_probe(struct platform_device *pdev)
else if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2"))
priv->map = _map_v2;
else {
-   dev_err(>dev,
-   "%s otpc config map not defined\n", __func__);
+   dev_err(dev, "%s otpc config map not defined\n", __func__);
return -EINVAL;
}
 
-- 
2.14.3

[PATCH 16/20] nvmem: rockchip-efuse: Make use of of_device_get_match_data()

[Andrey Smirnov]

Simplify code a bit by using of_device_get_match_data() instead of
of_match_device().

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/rockchip-efuse.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
index d6dc1330f895..979ba0a376a0 100644
--- a/drivers/nvmem/rockchip-efuse.c
+++ b/drivers/nvmem/rockchip-efuse.c
@@ -193,11 +193,11 @@ static int rockchip_efuse_probe(struct platform_device 
*pdev)
struct resource *res;
struct nvmem_device *nvmem;
struct rockchip_efuse_chip *efuse;
-   const struct of_device_id *match;
+   const void *data;
struct device *dev = >dev;
 
-   match = of_match_device(dev->driver->of_match_table, dev);
-   if (!match || !match->data) {
+   data = of_device_get_match_data(dev);
+   if (!data) {
dev_err(dev, "failed to get match data\n");
return -EINVAL;
}
@@ -218,7 +218,7 @@ static int rockchip_efuse_probe(struct platform_device 
*pdev)
 
efuse->dev = >dev;
econfig.size = resource_size(res);
-   econfig.reg_read = match->data;
+   econfig.reg_read = data;
econfig.priv = efuse;
econfig.dev = efuse->dev;
nvmem = devm_nvmem_register(dev, );
-- 
2.14.3

[PATCH 05/20] nvmem: uniphier-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/uniphier-efuse.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/uniphier-efuse.c b/drivers/nvmem/uniphier-efuse.c
index 9d278b4e1dc7..7ddc6fc012c9 100644
--- a/drivers/nvmem/uniphier-efuse.c
+++ b/drivers/nvmem/uniphier-efuse.c
@@ -60,22 +60,13 @@ static int uniphier_efuse_probe(struct platform_device 
*pdev)
econfig.size = resource_size(res);
econfig.priv = priv;
econfig.dev = dev;
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int uniphier_efuse_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static const struct of_device_id uniphier_efuse_of_match[] = {
{ .compatible = "socionext,uniphier-efuse",},
{/* sentinel */},
@@ -84,7 +75,6 @@ MODULE_DEVICE_TABLE(of, uniphier_efuse_of_match);
 
 static struct platform_driver uniphier_efuse_driver = {
.probe = uniphier_efuse_probe,
-   .remove = uniphier_efuse_remove,
.driver = {
.name = "uniphier-efuse",
.of_match_table = uniphier_efuse_of_match,
-- 
2.14.3

[PATCH 13/20] nvmem: imx-iim: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/imx-iim.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/imx-iim.c b/drivers/nvmem/imx-iim.c
index 52cfe91d9762..635561a441bd 100644
--- a/drivers/nvmem/imx-iim.c
+++ b/drivers/nvmem/imx-iim.c
@@ -138,25 +138,15 @@ static int imx_iim_probe(struct platform_device *pdev)
cfg.size = drvdata->nregs;
cfg.priv = iim;
 
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int imx_iim_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver imx_iim_driver = {
.probe  = imx_iim_probe,
-   .remove = imx_iim_remove,
.driver = {
.name   = "imx-iim",
.of_match_table = imx_iim_dt_ids,
-- 
2.14.3

[PATCH 07/20] nvmem: rockchip-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/rockchip-efuse.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
index 123de77ca5d6..d6dc1330f895 100644
--- a/drivers/nvmem/rockchip-efuse.c
+++ b/drivers/nvmem/rockchip-efuse.c
@@ -221,25 +221,15 @@ static int rockchip_efuse_probe(struct platform_device 
*pdev)
econfig.reg_read = match->data;
econfig.priv = efuse;
econfig.dev = efuse->dev;
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int rockchip_efuse_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver rockchip_efuse_driver = {
.probe = rockchip_efuse_probe,
-   .remove = rockchip_efuse_remove,
.driver = {
.name = "rockchip-efuse",
.of_match_table = rockchip_efuse_match,
-- 
2.14.3

[PATCH 08/20] nvmem: qfprom: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/qfprom.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
index cb3b48b47d64..13bf43c84bd4 100644
--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -47,13 +47,6 @@ static int qfprom_reg_write(void *context,
return 0;
 }
 
-static int qfprom_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct nvmem_config econfig = {
.name = "qfprom",
.stride = 1,
@@ -82,12 +75,10 @@ static int qfprom_probe(struct platform_device *pdev)
econfig.dev = dev;
econfig.priv = priv;
 
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
@@ -99,7 +90,6 @@ MODULE_DEVICE_TABLE(of, qfprom_of_match);
 
 static struct platform_driver qfprom_driver = {
.probe = qfprom_probe,
-   .remove = qfprom_remove,
.driver = {
.name = "qcom,qfprom",
.of_match_table = qfprom_of_match,
-- 
2.14.3

[PATCH 13/20] nvmem: imx-iim: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/imx-iim.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/imx-iim.c b/drivers/nvmem/imx-iim.c
index 52cfe91d9762..635561a441bd 100644
--- a/drivers/nvmem/imx-iim.c
+++ b/drivers/nvmem/imx-iim.c
@@ -138,25 +138,15 @@ static int imx_iim_probe(struct platform_device *pdev)
cfg.size = drvdata->nregs;
cfg.priv = iim;
 
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int imx_iim_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver imx_iim_driver = {
.probe  = imx_iim_probe,
-   .remove = imx_iim_remove,
.driver = {
.name   = "imx-iim",
.of_match_table = imx_iim_dt_ids,
-- 
2.14.3

[PATCH 07/20] nvmem: rockchip-efuse: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/rockchip-efuse.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/rockchip-efuse.c b/drivers/nvmem/rockchip-efuse.c
index 123de77ca5d6..d6dc1330f895 100644
--- a/drivers/nvmem/rockchip-efuse.c
+++ b/drivers/nvmem/rockchip-efuse.c
@@ -221,25 +221,15 @@ static int rockchip_efuse_probe(struct platform_device 
*pdev)
econfig.reg_read = match->data;
econfig.priv = efuse;
econfig.dev = efuse->dev;
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
-static int rockchip_efuse_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct platform_driver rockchip_efuse_driver = {
.probe = rockchip_efuse_probe,
-   .remove = rockchip_efuse_remove,
.driver = {
.name = "rockchip-efuse",
.of_match_table = rockchip_efuse_match,
-- 
2.14.3

[PATCH 08/20] nvmem: qfprom: Convert to use devm_nvmem_register()

[Andrey Smirnov]

Drop all of the code related to .remove hook and make use of
devm_nvmem_register() instead.

Cc: Srinivas Kandagatla 
Cc: Heiko Stuebner 
Cc: Masahiro Yamada 
Cc: Carlo Caione 
Cc: Kevin Hilman 
Cc: Matthias Brugger 
Cc: Joachim Eastwood 
Cc: cphe...@gmail.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Andrey Smirnov 
---
 drivers/nvmem/qfprom.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
index cb3b48b47d64..13bf43c84bd4 100644
--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -47,13 +47,6 @@ static int qfprom_reg_write(void *context,
return 0;
 }
 
-static int qfprom_remove(struct platform_device *pdev)
-{
-   struct nvmem_device *nvmem = platform_get_drvdata(pdev);
-
-   return nvmem_unregister(nvmem);
-}
-
 static struct nvmem_config econfig = {
.name = "qfprom",
.stride = 1,
@@ -82,12 +75,10 @@ static int qfprom_probe(struct platform_device *pdev)
econfig.dev = dev;
econfig.priv = priv;
 
-   nvmem = nvmem_register();
+   nvmem = devm_nvmem_register(dev, );
if (IS_ERR(nvmem))
return PTR_ERR(nvmem);
 
-   platform_set_drvdata(pdev, nvmem);
-
return 0;
 }
 
@@ -99,7 +90,6 @@ MODULE_DEVICE_TABLE(of, qfprom_of_match);
 
 static struct platform_driver qfprom_driver = {
.probe = qfprom_probe,
-   .remove = qfprom_remove,
.driver = {
.name = "qcom,qfprom",
.of_match_table = qfprom_of_match,
-- 
2.14.3

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

[Alexei Starovoitov]

On 12/27/17 12:09 AM, Masami Hiramatsu wrote:

On Tue, 26 Dec 2017 18:12:56 -0800
Alexei Starovoitov  wrote:


On Tue, Dec 26, 2017 at 04:48:25PM +0900, Masami Hiramatsu wrote:

Support in-kernel fault-injection framework via debugfs.
This allows you to inject a conditional error to specified
function using debugfs interfaces.

Signed-off-by: Masami Hiramatsu 
---
 Documentation/fault-injection/fault-injection.txt |5 +
 kernel/Makefile   |1
 kernel/fail_function.c|  169 +
 lib/Kconfig.debug |   10 +
 4 files changed, 185 insertions(+)
 create mode 100644 kernel/fail_function.c

diff --git a/Documentation/fault-injection/fault-injection.txt 
b/Documentation/fault-injection/fault-injection.txt
index 918972babcd8..6243a588dd71 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -30,6 +30,11 @@ o fail_mmc_request
   injects MMC data errors on devices permitted by setting
   debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request

+o fail_function
+
+  injects error return on specific functions by setting debugfs entries
+  under /sys/kernel/debug/fail_function. No boot option supported.


I like it.
Could you document it a bit better?


Yes, I will do in next series.


In particular retval is configurable, but without an example no one
will be able to figure out how to use it.


Ah, right. BTW, as I pointed in the covermail, should we store the
expected error value range into the injectable list? e.g.

ALLOW_ERROR_INJECTION(open_ctree, -1, -MAX_ERRNO)

And provide APIs to check/get it.


I'm afraid such check would be too costly.
Right now we have only two functions marked but I expect hundreds more
will be added in the near future as soon as developers realize the
potential of such error injection.
All of ALLOW_ERROR_INJECTION marks add 8 byte overhead each to .data.
Multiple by 1k and we have 8k of data spent on marks.
If we add max/min range marks that doubles it for very little use.
I think marking function only is enough.

Re: [RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

[Alexei Starovoitov]

On 12/27/17 12:09 AM, Masami Hiramatsu wrote:

On Tue, 26 Dec 2017 18:12:56 -0800
Alexei Starovoitov  wrote:


On Tue, Dec 26, 2017 at 04:48:25PM +0900, Masami Hiramatsu wrote:

Support in-kernel fault-injection framework via debugfs.
This allows you to inject a conditional error to specified
function using debugfs interfaces.

Signed-off-by: Masami Hiramatsu 
---
 Documentation/fault-injection/fault-injection.txt |5 +
 kernel/Makefile   |1
 kernel/fail_function.c|  169 +
 lib/Kconfig.debug |   10 +
 4 files changed, 185 insertions(+)
 create mode 100644 kernel/fail_function.c

diff --git a/Documentation/fault-injection/fault-injection.txt 
b/Documentation/fault-injection/fault-injection.txt
index 918972babcd8..6243a588dd71 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -30,6 +30,11 @@ o fail_mmc_request
   injects MMC data errors on devices permitted by setting
   debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request

+o fail_function
+
+  injects error return on specific functions by setting debugfs entries
+  under /sys/kernel/debug/fail_function. No boot option supported.


I like it.
Could you document it a bit better?


Yes, I will do in next series.


In particular retval is configurable, but without an example no one
will be able to figure out how to use it.


Ah, right. BTW, as I pointed in the covermail, should we store the
expected error value range into the injectable list? e.g.

ALLOW_ERROR_INJECTION(open_ctree, -1, -MAX_ERRNO)

And provide APIs to check/get it.


I'm afraid such check would be too costly.
Right now we have only two functions marked but I expect hundreds more
will be added in the near future as soon as developers realize the
potential of such error injection.
All of ALLOW_ERROR_INJECTION marks add 8 byte overhead each to .data.
Multiple by 1k and we have 8k of data spent on marks.
If we add max/min range marks that doubles it for very little use.
I think marking function only is enough.

[PATCH] perf/x86/intel: Fix minor memleak on Skylake perf initialization

[Andi Kleen]

From: Andi Kleen 

Tommi reports:

I'm seeing this kmemleak report in v4.15-rc4:

unreferenced object 0x8801f3d5d720 (size 64):
  comm "swapper/0", pid 1, jiffies 4294667312 (age 2687.423s)
  hex dump (first 32 bytes):
60 d1 41 ad ff ff ff ff 20 d1 41 ad ff ff ff ff  `.A. .A.
80 d0 41 ad ff ff ff ff 40 d0 41 ad ff ff ff ff  ..A.@.A.
  backtrace:
[] intel_pmu_init+0x1844/0x1d38
[] init_hw_perf_events+0x8c/0x66f
[] do_one_initcall+0x7b/0x1d0
[<8ee1f02a>] kernel_init_freeable+0x163/0x2f9
[] kernel_init+0xf/0x120
[<38a99264>] ret_from_fork+0x24/0x30
[] 0x

$ ./scripts/faddr2line vmlinux intel_pmu_init+0x1844/0x1d38
intel_pmu_init+0x1844/0x1d38:
intel_pmu_init at arch/x86/events/intel/core.c:4296

Which matches line:
extra_attr = merge_attr(extra_attr, skl_format_attr);

So looks like "extra_attr" is leaked here.

Free the attribute in this case.

Reported-by: Tommi Rantala 
Cc: Tommi Rantala 
Fixes: a5df70c354c26 ( perf/x86: Only show format attributes)
Signed-off-by: Andi Kleen 
---
 arch/x86/events/intel/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 09c26a4f139c..71321f48e1e6 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3855,6 +3855,7 @@ __init int intel_pmu_init(void)
struct extra_reg *er;
int version, i;
struct attribute **extra_attr = NULL;
+   bool extra_attr_allocated = false;
char *name;
 
if (!cpu_has(_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
@@ -4294,6 +4295,7 @@ __init int intel_pmu_init(void)
extra_attr = boot_cpu_has(X86_FEATURE_RTM) ?
hsw_format_attr : nhm_format_attr;
extra_attr = merge_attr(extra_attr, skl_format_attr);
+   extra_attr_allocated = true;
x86_pmu.cpu_events = get_hsw_events_attrs();
intel_pmu_pebs_data_source_skl(
boot_cpu_data.x86_model == INTEL_FAM6_SKYLAKE_X);
@@ -4324,6 +4326,8 @@ __init int intel_pmu_init(void)
if (version >= 2 && extra_attr) {
x86_pmu.format_attrs = merge_attr(intel_arch3_formats_attr,
  extra_attr);
+   if (extra_attr_allocated)
+   kfree(extra_attr);
WARN_ON(!x86_pmu.format_attrs);
}
 
-- 
2.14.3

[PATCH] perf/x86/intel: Fix minor memleak on Skylake perf initialization

[Andi Kleen]

From: Andi Kleen 

Tommi reports:

I'm seeing this kmemleak report in v4.15-rc4:

unreferenced object 0x8801f3d5d720 (size 64):
  comm "swapper/0", pid 1, jiffies 4294667312 (age 2687.423s)
  hex dump (first 32 bytes):
60 d1 41 ad ff ff ff ff 20 d1 41 ad ff ff ff ff  `.A. .A.
80 d0 41 ad ff ff ff ff 40 d0 41 ad ff ff ff ff  ..A.@.A.
  backtrace:
[] intel_pmu_init+0x1844/0x1d38
[] init_hw_perf_events+0x8c/0x66f
[] do_one_initcall+0x7b/0x1d0
[<8ee1f02a>] kernel_init_freeable+0x163/0x2f9
[] kernel_init+0xf/0x120
[<38a99264>] ret_from_fork+0x24/0x30
[] 0x

$ ./scripts/faddr2line vmlinux intel_pmu_init+0x1844/0x1d38
intel_pmu_init+0x1844/0x1d38:
intel_pmu_init at arch/x86/events/intel/core.c:4296

Which matches line:
extra_attr = merge_attr(extra_attr, skl_format_attr);

So looks like "extra_attr" is leaked here.

Free the attribute in this case.

Reported-by: Tommi Rantala 
Cc: Tommi Rantala 
Fixes: a5df70c354c26 ( perf/x86: Only show format attributes)
Signed-off-by: Andi Kleen 
---
 arch/x86/events/intel/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 09c26a4f139c..71321f48e1e6 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3855,6 +3855,7 @@ __init int intel_pmu_init(void)
struct extra_reg *er;
int version, i;
struct attribute **extra_attr = NULL;
+   bool extra_attr_allocated = false;
char *name;
 
if (!cpu_has(_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
@@ -4294,6 +4295,7 @@ __init int intel_pmu_init(void)
extra_attr = boot_cpu_has(X86_FEATURE_RTM) ?
hsw_format_attr : nhm_format_attr;
extra_attr = merge_attr(extra_attr, skl_format_attr);
+   extra_attr_allocated = true;
x86_pmu.cpu_events = get_hsw_events_attrs();
intel_pmu_pebs_data_source_skl(
boot_cpu_data.x86_model == INTEL_FAM6_SKYLAKE_X);
@@ -4324,6 +4326,8 @@ __init int intel_pmu_init(void)
if (version >= 2 && extra_attr) {
x86_pmu.format_attrs = merge_attr(intel_arch3_formats_attr,
  extra_attr);
+   if (extra_attr_allocated)
+   kfree(extra_attr);
WARN_ON(!x86_pmu.format_attrs);
}
 
-- 
2.14.3

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

[Alexei Starovoitov]

On 12/26/17 9:56 PM, Masami Hiramatsu wrote:

On Tue, 26 Dec 2017 17:57:32 -0800
Alexei Starovoitov  wrote:


On Tue, Dec 26, 2017 at 04:46:59PM +0900, Masami Hiramatsu wrote:

Check whether error injectable event is on function entry or not.
Currently it checks the event is ftrace-based kprobes or not,
but that is wrong. It should check if the event is on the entry
of target function. Since error injection will override a function
to just return with modified return value, that operation must
be done before the target function starts making stackframe.

As a side effect, bpf error injection is no need to depend on
function-tracer. It can work with sw-breakpoint based kprobe
events too.

Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/Kconfig|2 --
 kernel/trace/bpf_trace.c|6 +++---
 kernel/trace/trace_kprobe.c |8 +---
 kernel/trace/trace_probe.h  |   12 ++--
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ae3a2d519e50..6400e1bf97c5 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -533,9 +533,7 @@ config FUNCTION_PROFILER
 config BPF_KPROBE_OVERRIDE
bool "Enable BPF programs to override a kprobed function"
depends on BPF_EVENTS
-   depends on KPROBES_ON_FTRACE
depends on HAVE_KPROBE_OVERRIDE
-   depends on DYNAMIC_FTRACE_WITH_REGS
default n
help
 Allows BPF to override the execution of a probed function and
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index f6d2327ecb59..d663660f8392 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -800,11 +800,11 @@ int perf_event_attach_bpf_prog(struct perf_event *event,
int ret = -EEXIST;

/*
-* Kprobe override only works for ftrace based kprobes, and only if they
-* are on the opt-in list.
+* Kprobe override only works if they are on the function entry,
+* and only if they are on the opt-in list.
 */
if (prog->kprobe_override &&
-   (!trace_kprobe_ftrace(event->tp_event) ||
+   (!trace_kprobe_on_func_entry(event->tp_event) ||
 !trace_kprobe_error_injectable(event->tp_event)))
return -EINVAL;

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 91f4b57dab82..265e3e27e8dc 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -88,13 +88,15 @@ static nokprobe_inline unsigned long 
trace_kprobe_nhit(struct trace_kprobe *tk)
return nhit;
 }

-int trace_kprobe_ftrace(struct trace_event_call *call)
+bool trace_kprobe_on_func_entry(struct trace_event_call *call)
 {
struct trace_kprobe *tk = (struct trace_kprobe *)call->data;
-   return kprobe_ftrace(>rp.kp);
+
+   return kprobe_on_func_entry(tk->rp.kp.addr, tk->rp.kp.symbol_name,
+   tk->rp.kp.offset);


That would be nice, but did you test this?


Yes, because the jprobe, which was only official user of modifying execution
path using kprobe, did same way to check. (and kretprobe also does it)


My understanding that kprobe will restore all regs and
here we need to override return ip _and_ value.


yes, no problem. kprobe restore all regs from pt_regs, including regs->ip.


Could you add a patch with the test the way Josef did
or describe the steps to test this new mode?


Would you mean below patch? If so, it should work without any change.

 [PATCH v10 4/5] samples/bpf: add a test for bpf_override_return


yeah. I expect bpf_override_return test to work as-is.
I'm asking for the test for new functionality added by this patch.
In particular kprobe on func entry without ftrace.
How did you test it?
and how I can repeat the test?
I'm still not sure that it works correctly.

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

[Alexei Starovoitov]

On 12/26/17 9:56 PM, Masami Hiramatsu wrote:

On Tue, 26 Dec 2017 17:57:32 -0800
Alexei Starovoitov  wrote:


On Tue, Dec 26, 2017 at 04:46:59PM +0900, Masami Hiramatsu wrote:

Check whether error injectable event is on function entry or not.
Currently it checks the event is ftrace-based kprobes or not,
but that is wrong. It should check if the event is on the entry
of target function. Since error injection will override a function
to just return with modified return value, that operation must
be done before the target function starts making stackframe.

As a side effect, bpf error injection is no need to depend on
function-tracer. It can work with sw-breakpoint based kprobe
events too.

Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/Kconfig|2 --
 kernel/trace/bpf_trace.c|6 +++---
 kernel/trace/trace_kprobe.c |8 +---
 kernel/trace/trace_probe.h  |   12 ++--
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ae3a2d519e50..6400e1bf97c5 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -533,9 +533,7 @@ config FUNCTION_PROFILER
 config BPF_KPROBE_OVERRIDE
bool "Enable BPF programs to override a kprobed function"
depends on BPF_EVENTS
-   depends on KPROBES_ON_FTRACE
depends on HAVE_KPROBE_OVERRIDE
-   depends on DYNAMIC_FTRACE_WITH_REGS
default n
help
 Allows BPF to override the execution of a probed function and
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index f6d2327ecb59..d663660f8392 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -800,11 +800,11 @@ int perf_event_attach_bpf_prog(struct perf_event *event,
int ret = -EEXIST;

/*
-* Kprobe override only works for ftrace based kprobes, and only if they
-* are on the opt-in list.
+* Kprobe override only works if they are on the function entry,
+* and only if they are on the opt-in list.
 */
if (prog->kprobe_override &&
-   (!trace_kprobe_ftrace(event->tp_event) ||
+   (!trace_kprobe_on_func_entry(event->tp_event) ||
 !trace_kprobe_error_injectable(event->tp_event)))
return -EINVAL;

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 91f4b57dab82..265e3e27e8dc 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -88,13 +88,15 @@ static nokprobe_inline unsigned long 
trace_kprobe_nhit(struct trace_kprobe *tk)
return nhit;
 }

-int trace_kprobe_ftrace(struct trace_event_call *call)
+bool trace_kprobe_on_func_entry(struct trace_event_call *call)
 {
struct trace_kprobe *tk = (struct trace_kprobe *)call->data;
-   return kprobe_ftrace(>rp.kp);
+
+   return kprobe_on_func_entry(tk->rp.kp.addr, tk->rp.kp.symbol_name,
+   tk->rp.kp.offset);


That would be nice, but did you test this?


Yes, because the jprobe, which was only official user of modifying execution
path using kprobe, did same way to check. (and kretprobe also does it)


My understanding that kprobe will restore all regs and
here we need to override return ip _and_ value.


yes, no problem. kprobe restore all regs from pt_regs, including regs->ip.


Could you add a patch with the test the way Josef did
or describe the steps to test this new mode?


Would you mean below patch? If so, it should work without any change.

 [PATCH v10 4/5] samples/bpf: add a test for bpf_override_return


yeah. I expect bpf_override_return test to work as-is.
I'm asking for the test for new functionality added by this patch.
In particular kprobe on func entry without ftrace.
How did you test it?
and how I can repeat the test?
I'm still not sure that it works correctly.

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Antoine Tenart]

Hi Russell,

On Wed, Dec 27, 2017 at 10:24:01PM +, Russell King - ARM Linux wrote:
> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> >  
> > +_eth2 {
> > +   /* CPS Lane 5 */
> > +   status = "okay";
> > +   phy-mode = "2500base-x";
> > +   /* Generic PHY, providing serdes lanes */
> > +   phys = <_comphy5 2>;
> > +};
> > +
> 
> This is wrong.  This lane is connected to a SFP cage which can support
> more than just 2500base-X.  Tying it in this way to 2500base-X means
> that this port does not support conenctions at 1000base-X, despite
> that's one of the most popular and more standardised speeds.

What do you suggest to describe this in the dt, to enable a port using
the current PPv2 driver?

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Antoine Tenart]

Hi Russell,

On Wed, Dec 27, 2017 at 10:24:01PM +, Russell King - ARM Linux wrote:
> On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> >  
> > +_eth2 {
> > +   /* CPS Lane 5 */
> > +   status = "okay";
> > +   phy-mode = "2500base-x";
> > +   /* Generic PHY, providing serdes lanes */
> > +   phys = <_comphy5 2>;
> > +};
> > +
> 
> This is wrong.  This lane is connected to a SFP cage which can support
> more than just 2500base-X.  Tying it in this way to 2500base-X means
> that this port does not support conenctions at 1000base-X, despite
> that's one of the most popular and more standardised speeds.

What do you suggest to describe this in the dt, to enable a port using
the current PPv2 driver?

Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v6 06/18] PCI: designware-ep: Add generic function for raising MSI irq

[Niklas Cassel]

On Tue, Dec 26, 2017 at 06:20:54PM +0530, Kishon Vijay Abraham I wrote:
> Hi Niklas,

Hello Kishon

> 
> On Wednesday 20 December 2017 04:59 AM, Niklas Cassel wrote:
> > Add a generic function for raising MSI irqs that can be used by all
> > DWC based controllers.
> > 
> > Note that certain controllers, like DRA7xx, have a special convenience
> > register for raising MSI irqs that doesn't require you to explicitly map
> > the MSI address. Therefore, it is likely that certain drivers will
> > not use this generic function, even if they can.
> > 
> > Signed-off-by: Niklas Cassel 
> > ---
> >  drivers/pci/dwc/pcie-designware-ep.c | 35 
> > +++
> >  drivers/pci/dwc/pcie-designware.h|  9 +
> >  2 files changed, 44 insertions(+)
> > 
> > diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> > b/drivers/pci/dwc/pcie-designware-ep.c
> > index 700ed2f4becf..c5aa1cac5041 100644
> > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > @@ -282,6 +282,41 @@ static const struct pci_epc_ops epc_ops = {
> > .stop   = dw_pcie_ep_stop,
> >  };
> >  
> > +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> > +u8 interrupt_num)
> > +{
> > +   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +   struct pci_epc *epc = ep->epc;
> > +   u16 msg_ctrl, msg_data;
> > +   u32 msg_addr_lower, msg_addr_upper;
> > +   u64 msg_addr;
> > +   bool has_upper;
> > +   int ret;
> > +
> > +   /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> > +   msg_ctrl = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
> > +   has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > +   msg_addr_lower = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_L32);
> > +   if (has_upper) {
> > +   msg_addr_upper = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_U32);
> > +   msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_64);
> > +   } else {
> > +   msg_addr_upper = 0;
> > +   msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_32);
> > +   }
> > +   msg_addr = ((u64) msg_addr_upper) << 32 | msg_addr_lower;
> > +   ret = dw_pcie_ep_map_addr(epc, ep->msi_mem_phys, msg_addr,
> > + epc->mem->page_size);
> > +   if (ret)
> > +   return ret;
> > +
> > +   writel(msg_data | (interrupt_num - 1), ep->msi_mem);
> 
> Shouldn't this be msg_data + (interrupt_num - 1)?

I'm not quite sure about this, but if there is a pending irq,
not yet processed by the RC, the msg_data we read out in this
function should have a bit set, matching the pending irq.

If that irq is the same as the irq we are trying to raise,
doing an addition will produce a bogus vector number,
but a bitwise or should work.

For that reason, I think that doing bitwise or seems safer.
However, other than this case, I don't see why it should
matter if we do an addition or a bitwise or.

Are you having some problem with the code?
It seems to be working fine on ARTPEC-6:

# ./pcitest -m 1
MSI1:   OKAY
# ./pcitest -m 2
MSI2:   OKAY
# ./pcitest -m 3
MSI3:   OKAY
# ./pcitest -m 4
MSI4:   OKAY
# ./pcitest -m 5
MSI5:   OKAY
# ./pcitest -m 6
MSI6:   OKAY
# ./pcitest -m 7
MSI7:   OKAY
# ./pcitest -m 8
MSI8:   OKAY
# ./pcitest -m 9
MSI9:   OKAY
# cat /proc/interrupts | grep -i msi
 82:  9  0 GIC-0 180 Level artpec6-pcie-msi
188:  1  0   PCI-MSI  16 Edge  pci-endpoint-test
189:  1  0   PCI-MSI  17 Edge  pci-endpoint-test
190:  1  0   PCI-MSI  18 Edge  pci-endpoint-test
191:  1  0   PCI-MSI  19 Edge  pci-endpoint-test
192:  1  0   PCI-MSI  20 Edge  pci-endpoint-test
193:  1  0   PCI-MSI  21 Edge  pci-endpoint-test
194:  1  0   PCI-MSI  22 Edge  pci-endpoint-test
195:  1  0   PCI-MSI  23 Edge  pci-endpoint-test
196:  1  0   PCI-MSI  24 Edge  pci-endpoint-test
197:  0  0   PCI-MSI  25 Edge  pci-endpoint-test
198:  0  0   PCI-MSI  26 Edge  pci-endpoint-test
199:  0  0   PCI-MSI  27 Edge  pci-endpoint-test
200:  0  0   PCI-MSI  28 Edge  pci-endpoint-test
201:  0  0   PCI-MSI  29 Edge  pci-endpoint-test
202:  0  0   PCI-MSI  30 Edge  pci-endpoint-test
203:  0  0   PCI-MSI  31 Edge  pci-endpoint-test

>From EP:
irq: 1 read msg_data: 0x10 writing: 0x10
irq: 2 read msg_data: 0x10 writing: 0x11
irq: 3 read msg_data: 0x10 writing: 0x12
irq: 4 read msg_data: 0x10 writing: 0x13
irq: 5 read msg_data: 0x10 writing: 0x14
irq: 6 read msg_data: 0x10 writing: 0x15
irq: 7 read msg_data: 0x10 writing: 0x16
irq: 8 read msg_data: 0x10 writing: 0x17
irq: 9 read msg_data: 0x10 writing: 0x18

This also looks correct, 

Re: [PATCH v6 06/18] PCI: designware-ep: Add generic function for raising MSI irq

[Niklas Cassel]

On Tue, Dec 26, 2017 at 06:20:54PM +0530, Kishon Vijay Abraham I wrote:
> Hi Niklas,

Hello Kishon

> 
> On Wednesday 20 December 2017 04:59 AM, Niklas Cassel wrote:
> > Add a generic function for raising MSI irqs that can be used by all
> > DWC based controllers.
> > 
> > Note that certain controllers, like DRA7xx, have a special convenience
> > register for raising MSI irqs that doesn't require you to explicitly map
> > the MSI address. Therefore, it is likely that certain drivers will
> > not use this generic function, even if they can.
> > 
> > Signed-off-by: Niklas Cassel 
> > ---
> >  drivers/pci/dwc/pcie-designware-ep.c | 35 
> > +++
> >  drivers/pci/dwc/pcie-designware.h|  9 +
> >  2 files changed, 44 insertions(+)
> > 
> > diff --git a/drivers/pci/dwc/pcie-designware-ep.c 
> > b/drivers/pci/dwc/pcie-designware-ep.c
> > index 700ed2f4becf..c5aa1cac5041 100644
> > --- a/drivers/pci/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/dwc/pcie-designware-ep.c
> > @@ -282,6 +282,41 @@ static const struct pci_epc_ops epc_ops = {
> > .stop   = dw_pcie_ep_stop,
> >  };
> >  
> > +int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep,
> > +u8 interrupt_num)
> > +{
> > +   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +   struct pci_epc *epc = ep->epc;
> > +   u16 msg_ctrl, msg_data;
> > +   u32 msg_addr_lower, msg_addr_upper;
> > +   u64 msg_addr;
> > +   bool has_upper;
> > +   int ret;
> > +
> > +   /* Raise MSI per the PCI Local Bus Specification Revision 3.0, 6.8.1. */
> > +   msg_ctrl = dw_pcie_readw_dbi(pci, MSI_MESSAGE_CONTROL);
> > +   has_upper = !!(msg_ctrl & PCI_MSI_FLAGS_64BIT);
> > +   msg_addr_lower = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_L32);
> > +   if (has_upper) {
> > +   msg_addr_upper = dw_pcie_readl_dbi(pci, MSI_MESSAGE_ADDR_U32);
> > +   msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_64);
> > +   } else {
> > +   msg_addr_upper = 0;
> > +   msg_data = dw_pcie_readw_dbi(pci, MSI_MESSAGE_DATA_32);
> > +   }
> > +   msg_addr = ((u64) msg_addr_upper) << 32 | msg_addr_lower;
> > +   ret = dw_pcie_ep_map_addr(epc, ep->msi_mem_phys, msg_addr,
> > + epc->mem->page_size);
> > +   if (ret)
> > +   return ret;
> > +
> > +   writel(msg_data | (interrupt_num - 1), ep->msi_mem);
> 
> Shouldn't this be msg_data + (interrupt_num - 1)?

I'm not quite sure about this, but if there is a pending irq,
not yet processed by the RC, the msg_data we read out in this
function should have a bit set, matching the pending irq.

If that irq is the same as the irq we are trying to raise,
doing an addition will produce a bogus vector number,
but a bitwise or should work.

For that reason, I think that doing bitwise or seems safer.
However, other than this case, I don't see why it should
matter if we do an addition or a bitwise or.

Are you having some problem with the code?
It seems to be working fine on ARTPEC-6:

# ./pcitest -m 1
MSI1:   OKAY
# ./pcitest -m 2
MSI2:   OKAY
# ./pcitest -m 3
MSI3:   OKAY
# ./pcitest -m 4
MSI4:   OKAY
# ./pcitest -m 5
MSI5:   OKAY
# ./pcitest -m 6
MSI6:   OKAY
# ./pcitest -m 7
MSI7:   OKAY
# ./pcitest -m 8
MSI8:   OKAY
# ./pcitest -m 9
MSI9:   OKAY
# cat /proc/interrupts | grep -i msi
 82:  9  0 GIC-0 180 Level artpec6-pcie-msi
188:  1  0   PCI-MSI  16 Edge  pci-endpoint-test
189:  1  0   PCI-MSI  17 Edge  pci-endpoint-test
190:  1  0   PCI-MSI  18 Edge  pci-endpoint-test
191:  1  0   PCI-MSI  19 Edge  pci-endpoint-test
192:  1  0   PCI-MSI  20 Edge  pci-endpoint-test
193:  1  0   PCI-MSI  21 Edge  pci-endpoint-test
194:  1  0   PCI-MSI  22 Edge  pci-endpoint-test
195:  1  0   PCI-MSI  23 Edge  pci-endpoint-test
196:  1  0   PCI-MSI  24 Edge  pci-endpoint-test
197:  0  0   PCI-MSI  25 Edge  pci-endpoint-test
198:  0  0   PCI-MSI  26 Edge  pci-endpoint-test
199:  0  0   PCI-MSI  27 Edge  pci-endpoint-test
200:  0  0   PCI-MSI  28 Edge  pci-endpoint-test
201:  0  0   PCI-MSI  29 Edge  pci-endpoint-test
202:  0  0   PCI-MSI  30 Edge  pci-endpoint-test
203:  0  0   PCI-MSI  31 Edge  pci-endpoint-test

>From EP:
irq: 1 read msg_data: 0x10 writing: 0x10
irq: 2 read msg_data: 0x10 writing: 0x11
irq: 3 read msg_data: 0x10 writing: 0x12
irq: 4 read msg_data: 0x10 writing: 0x13
irq: 5 read msg_data: 0x10 writing: 0x14
irq: 6 read msg_data: 0x10 writing: 0x15
irq: 7 read msg_data: 0x10 writing: 0x16
irq: 8 read msg_data: 0x10 writing: 0x17
irq: 9 read msg_data: 0x10 writing: 0x18

This also looks correct, since I enabled 16 irqs,

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Russell King - ARM Linux]

On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> This patch enables the fourth network interface on the Marvell
> Macchiatobin. It is configured in the 2500Base-X PHY mode.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts 
> b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> index b3350827ee55..c51efd511324 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> @@ -279,6 +279,14 @@
>   phys = <_comphy0 1>;
>  };
>  
> +_eth2 {
> + /* CPS Lane 5 */
> + status = "okay";
> + phy-mode = "2500base-x";
> + /* Generic PHY, providing serdes lanes */
> + phys = <_comphy5 2>;
> +};
> +

This is wrong.  This lane is connected to a SFP cage which can support
more than just 2500base-X.  Tying it in this way to 2500base-X means
that this port does not support conenctions at 1000base-X, despite
that's one of the most popular and more standardised speeds.

So, I feel I have to NAK this patch in its current form.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Russell King - ARM Linux]

On Wed, Dec 27, 2017 at 11:14:45PM +0100, Antoine Tenart wrote:
> This patch enables the fourth network interface on the Marvell
> Macchiatobin. It is configured in the 2500Base-X PHY mode.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts 
> b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> index b3350827ee55..c51efd511324 100644
> --- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
> @@ -279,6 +279,14 @@
>   phys = <_comphy0 1>;
>  };
>  
> +_eth2 {
> + /* CPS Lane 5 */
> + status = "okay";
> + phy-mode = "2500base-x";
> + /* Generic PHY, providing serdes lanes */
> + phys = <_comphy5 2>;
> +};
> +

This is wrong.  This lane is connected to a SFP cage which can support
more than just 2500base-X.  Tying it in this way to 2500base-X means
that this port does not support conenctions at 1000base-X, despite
that's one of the most popular and more standardised speeds.

So, I feel I have to NAK this patch in its current form.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH net-next 2/6] phy: cp110-comphy: 2.5G SGMII mode

[Antoine Tenart]

This patch allow the CP100 comphy to configure some lanes in the
2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
same code path.

Signed-off-by: Antoine Tenart 
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index a0d522154cdf..946a6ed7b66f 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -135,19 +135,25 @@ struct mvebu_comhy_conf {
 static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
/* lane 0 */
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
+   MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII_2_5G, 0x1),
/* lane 1 */
MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
+   MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII_2_5G, 0x1),
/* lane 2 */
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
+   MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII_2_5G, 0x1),
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
/* lane 3 */
MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
+   MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII_2_5G, 0x2),
/* lane 4 */
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
+   MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII_2_5G, 0x2),
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
/* lane 5 */
MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
+   MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII_2_5G, 0x1),
 };
 
 struct mvebu_comphy_priv {
@@ -206,6 +212,10 @@ static void mvebu_comphy_ethernet_init_reset(struct 
mvebu_comphy_lane *lane,
if (mode == PHY_MODE_10GKR)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
   MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
+   else if (mode == PHY_MODE_SGMII_2_5G)
+   val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
+  MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
+  MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
else if (mode == PHY_MODE_SGMII)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
   MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
@@ -296,13 +306,13 @@ static int mvebu_comphy_init_plls(struct 
mvebu_comphy_lane *lane,
return 0;
 }
 
-static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
+static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
 {
struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
struct mvebu_comphy_priv *priv = lane->priv;
u32 val;
 
-   mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_SGMII);
+   mvebu_comphy_ethernet_init_reset(lane, mode);
 
val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
@@ -487,7 +497,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
 
switch (lane->mode) {
case PHY_MODE_SGMII:
-   ret = mvebu_comphy_set_mode_sgmii(phy);
+   case PHY_MODE_SGMII_2_5G:
+   ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
break;
case PHY_MODE_10GKR:
ret = mvebu_comphy_set_mode_10gkr(phy);
-- 
2.14.3

[PATCH net-next 4/6] net: mvpp2: 2500baseX support

[Antoine Tenart]

This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
nearly the same code path.

Signed-off-by: Antoine Tenart 
---
 drivers/net/ethernet/marvell/mvpp2.c | 40 
 1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index 094db9dd633f..5d2a6f5a52b6 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4502,6 +4502,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
break;
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
+   case PHY_INTERFACE_MODE_2500BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4540,7 +4541,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
-   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4571,7 +4573,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
-   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4584,7 +4587,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
-   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4612,6 +4616,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
+   case PHY_INTERFACE_MODE_2500BASEX:
+   mode = PHY_MODE_SGMII_2_5G;
+   break;
case PHY_INTERFACE_MODE_10GKR:
mode = PHY_MODE_10GKR;
break;
@@ -4631,7 +4638,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
u32 val;
 
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
-   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
   MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4647,7 +4655,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
}
 
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
-   if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+   if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PORT_TYPE_MASK;
else
val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
@@ -4660,6 +4669,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
 
+   /* Clear all fields we may want to explicitly set below */
+   val &= ~(MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_CONFIG_GMII_SPEED |
+MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_AN_SPEED_EN |
+MVPP2_GMAC_AN_DUPLEX_EN);
+
if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
/* 1000BaseX port cannot negotiate speed nor can it
 * negotiate duplex: they are always operating with a
@@ -4668,6 +4682,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
 */
val |= 

[PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Antoine Tenart]

This patch enables the fourth network interface on the Marvell
Macchiatobin. It is configured in the 2500Base-X PHY mode.

Signed-off-by: Antoine Tenart 
---
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts 
b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index b3350827ee55..c51efd511324 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -279,6 +279,14 @@
phys = <_comphy0 1>;
 };
 
+_eth2 {
+   /* CPS Lane 5 */
+   status = "okay";
+   phy-mode = "2500base-x";
+   /* Generic PHY, providing serdes lanes */
+   phys = <_comphy5 2>;
+};
+
 _pinctrl {
cps_spi1_pins: spi1-pins {
marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15", "mpp16";
-- 
2.14.3

[PATCH net-next 2/6] phy: cp110-comphy: 2.5G SGMII mode

[Antoine Tenart]

This patch allow the CP100 comphy to configure some lanes in the
2.5G SGMII mode. This mode is quite close to SGMII and uses nearly the
same code path.

Signed-off-by: Antoine Tenart 
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index a0d522154cdf..946a6ed7b66f 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -135,19 +135,25 @@ struct mvebu_comhy_conf {
 static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
/* lane 0 */
MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
+   MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII_2_5G, 0x1),
/* lane 1 */
MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
+   MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII_2_5G, 0x1),
/* lane 2 */
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
+   MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII_2_5G, 0x1),
MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
/* lane 3 */
MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
+   MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII_2_5G, 0x2),
/* lane 4 */
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
+   MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII_2_5G, 0x2),
MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
/* lane 5 */
MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
+   MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII_2_5G, 0x1),
 };
 
 struct mvebu_comphy_priv {
@@ -206,6 +212,10 @@ static void mvebu_comphy_ethernet_init_reset(struct 
mvebu_comphy_lane *lane,
if (mode == PHY_MODE_10GKR)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0xe) |
   MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0xe);
+   else if (mode == PHY_MODE_SGMII_2_5G)
+   val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x8) |
+  MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x8) |
+  MVEBU_COMPHY_SERDES_CFG0_HALF_BUS;
else if (mode == PHY_MODE_SGMII)
val |= MVEBU_COMPHY_SERDES_CFG0_GEN_RX(0x6) |
   MVEBU_COMPHY_SERDES_CFG0_GEN_TX(0x6) |
@@ -296,13 +306,13 @@ static int mvebu_comphy_init_plls(struct 
mvebu_comphy_lane *lane,
return 0;
 }
 
-static int mvebu_comphy_set_mode_sgmii(struct phy *phy)
+static int mvebu_comphy_set_mode_sgmii(struct phy *phy, enum phy_mode mode)
 {
struct mvebu_comphy_lane *lane = phy_get_drvdata(phy);
struct mvebu_comphy_priv *priv = lane->priv;
u32 val;
 
-   mvebu_comphy_ethernet_init_reset(lane, PHY_MODE_SGMII);
+   mvebu_comphy_ethernet_init_reset(lane, mode);
 
val = readl(priv->base + MVEBU_COMPHY_RX_CTRL1(lane->id));
val &= ~MVEBU_COMPHY_RX_CTRL1_CLK8T_EN;
@@ -487,7 +497,8 @@ static int mvebu_comphy_power_on(struct phy *phy)
 
switch (lane->mode) {
case PHY_MODE_SGMII:
-   ret = mvebu_comphy_set_mode_sgmii(phy);
+   case PHY_MODE_SGMII_2_5G:
+   ret = mvebu_comphy_set_mode_sgmii(phy, lane->mode);
break;
case PHY_MODE_10GKR:
ret = mvebu_comphy_set_mode_10gkr(phy);
-- 
2.14.3

[PATCH net-next 4/6] net: mvpp2: 2500baseX support

[Antoine Tenart]

This patch adds the 2500Base-X PHY mode support in the Marvell PPv2
driver. 2500Base-X is quite close to 1000Base-X and SGMII modes and uses
nearly the same code path.

Signed-off-by: Antoine Tenart 
---
 drivers/net/ethernet/marvell/mvpp2.c | 40 
 1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index 094db9dd633f..5d2a6f5a52b6 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4502,6 +4502,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
break;
case PHY_INTERFACE_MODE_SGMII:
case PHY_INTERFACE_MODE_1000BASEX:
+   case PHY_INTERFACE_MODE_2500BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4540,7 +4541,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
-   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4571,7 +4573,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
-   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4584,7 +4587,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
-   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4612,6 +4616,9 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
+   case PHY_INTERFACE_MODE_2500BASEX:
+   mode = PHY_MODE_SGMII_2_5G;
+   break;
case PHY_INTERFACE_MODE_10GKR:
mode = PHY_MODE_10GKR;
break;
@@ -4631,7 +4638,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
u32 val;
 
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
-   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
   MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4647,7 +4655,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
}
 
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
-   if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+   if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX ||
+   port->phy_interface == PHY_INTERFACE_MODE_2500BASEX)
val |= MVPP2_GMAC_PORT_TYPE_MASK;
else
val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
@@ -4660,6 +4669,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
 
+   /* Clear all fields we may want to explicitly set below */
+   val &= ~(MVPP2_GMAC_CONFIG_FULL_DUPLEX | MVPP2_GMAC_CONFIG_GMII_SPEED |
+MVPP2_GMAC_CONFIG_MII_SPEED | MVPP2_GMAC_AN_SPEED_EN |
+MVPP2_GMAC_AN_DUPLEX_EN);
+
if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
/* 1000BaseX port cannot negotiate speed nor can it
 * negotiate duplex: they are always operating with a
@@ -4668,6 +4682,10 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
 */
val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
  

[PATCH net-next 5/6] arm64: dts: marvell: mcbin: enable the fourth network interface

[Antoine Tenart]

This patch enables the fourth network interface on the Marvell
Macchiatobin. It is configured in the 2500Base-X PHY mode.

Signed-off-by: Antoine Tenart 
---
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts 
b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index b3350827ee55..c51efd511324 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -279,6 +279,14 @@
phys = <_comphy0 1>;
 };
 
+_eth2 {
+   /* CPS Lane 5 */
+   status = "okay";
+   phy-mode = "2500base-x";
+   /* Generic PHY, providing serdes lanes */
+   phys = <_comphy5 2>;
+};
+
 _pinctrl {
cps_spi1_pins: spi1-pins {
marvell,pins = "mpp12", "mpp13", "mpp14", "mpp15", "mpp16";
-- 
2.14.3

[PATCH net-next 3/6] net: mvpp2: 1000baseX support

[Antoine Tenart]

This patch adds the 1000Base-X PHY mode support in the Marvell PPv2
driver. 1000Base-X is quite close the SGMII and uses nearly the same
code path.

Signed-off-by: Antoine Tenart 
---
 drivers/net/ethernet/marvell/mvpp2.c | 45 
 1 file changed, 35 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index a19760736b71..094db9dd633f 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4501,6 +4501,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
mvpp22_gop_init_rgmii(port);
break;
case PHY_INTERFACE_MODE_SGMII:
+   case PHY_INTERFACE_MODE_1000BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4538,7 +4539,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
u32 val;
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
-   port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+   port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4568,7 +4570,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
}
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
-   port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+   port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4580,7 +4583,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
u32 val;
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
-   port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+   port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4605,6 +4609,7 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
 
switch (port->phy_interface) {
case PHY_INTERFACE_MODE_SGMII:
+   case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4625,7 +4630,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
 {
u32 val;
 
-   if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+   if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
   MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4640,9 +4646,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
 
-   /* The port is connected to a copper PHY */
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
-   val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
+   if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+   val |= MVPP2_GMAC_PORT_TYPE_MASK;
+   else
+   val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
 
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
@@ -4651,6 +4659,19 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
   MVPP2_GMAC_AN_DUPLEX_EN;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+
+   if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+   /* 1000BaseX port cannot negotiate speed nor can it
+* negotiate duplex: they are always operating with a
+* fixed speed of 1000Mbps in full duplex, so force
+* 1000 speed and full duplex here.
+*/
+   val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+  MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+   else
+   val |= MVPP2_GMAC_AN_SPEED_EN |
+  MVPP2_GMAC_AN_DUPLEX_EN;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
 }
 
@@ -4671,7 +4692,8 @@ static void mvpp2_port_mii_gmac_configure(struct 
mvpp2_port *port)
 
/* Configure the PCS and in-band AN */

[PATCH net-next 3/6] net: mvpp2: 1000baseX support

[Antoine Tenart]

This patch adds the 1000Base-X PHY mode support in the Marvell PPv2
driver. 1000Base-X is quite close the SGMII and uses nearly the same
code path.

Signed-off-by: Antoine Tenart 
---
 drivers/net/ethernet/marvell/mvpp2.c | 45 
 1 file changed, 35 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index a19760736b71..094db9dd633f 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -4501,6 +4501,7 @@ static int mvpp22_gop_init(struct mvpp2_port *port)
mvpp22_gop_init_rgmii(port);
break;
case PHY_INTERFACE_MODE_SGMII:
+   case PHY_INTERFACE_MODE_1000BASEX:
mvpp22_gop_init_sgmii(port);
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4538,7 +4539,8 @@ static void mvpp22_gop_unmask_irq(struct mvpp2_port *port)
u32 val;
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
-   port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+   port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
/* Enable the GMAC link status irq for this port */
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val |= MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
@@ -4568,7 +4570,8 @@ static void mvpp22_gop_mask_irq(struct mvpp2_port *port)
}
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
-   port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+   port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_SUM_MASK);
val &= ~MVPP22_GMAC_INT_SUM_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_SUM_MASK);
@@ -4580,7 +4583,8 @@ static void mvpp22_gop_setup_irq(struct mvpp2_port *port)
u32 val;
 
if (phy_interface_mode_is_rgmii(port->phy_interface) ||
-   port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+   port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_INT_MASK);
val |= MVPP22_GMAC_INT_MASK_LINK_STAT;
writel(val, port->base + MVPP22_GMAC_INT_MASK);
@@ -4605,6 +4609,7 @@ static int mvpp22_comphy_init(struct mvpp2_port *port)
 
switch (port->phy_interface) {
case PHY_INTERFACE_MODE_SGMII:
+   case PHY_INTERFACE_MODE_1000BASEX:
mode = PHY_MODE_SGMII;
break;
case PHY_INTERFACE_MODE_10GKR:
@@ -4625,7 +4630,8 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
 {
u32 val;
 
-   if (port->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+   if (port->phy_interface == PHY_INTERFACE_MODE_SGMII ||
+   port->phy_interface == PHY_INTERFACE_MODE_1000BASEX) {
val = readl(port->base + MVPP22_GMAC_CTRL_4_REG);
val |= MVPP22_CTRL4_SYNC_BYPASS_DIS | MVPP22_CTRL4_DP_CLK_SEL |
   MVPP22_CTRL4_QSGMII_BYPASS_ACTIVE;
@@ -4640,9 +4646,11 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
writel(val, port->base + MVPP22_GMAC_CTRL_4_REG);
}
 
-   /* The port is connected to a copper PHY */
val = readl(port->base + MVPP2_GMAC_CTRL_0_REG);
-   val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
+   if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+   val |= MVPP2_GMAC_PORT_TYPE_MASK;
+   else
+   val &= ~MVPP2_GMAC_PORT_TYPE_MASK;
writel(val, port->base + MVPP2_GMAC_CTRL_0_REG);
 
val = readl(port->base + MVPP2_GMAC_AUTONEG_CONFIG);
@@ -4651,6 +4659,19 @@ static void mvpp2_port_mii_gmac_configure_mode(struct 
mvpp2_port *port)
   MVPP2_GMAC_AN_DUPLEX_EN;
if (port->phy_interface == PHY_INTERFACE_MODE_SGMII)
val |= MVPP2_GMAC_IN_BAND_AUTONEG;
+
+   if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX)
+   /* 1000BaseX port cannot negotiate speed nor can it
+* negotiate duplex: they are always operating with a
+* fixed speed of 1000Mbps in full duplex, so force
+* 1000 speed and full duplex here.
+*/
+   val |= MVPP2_GMAC_CONFIG_GMII_SPEED |
+  MVPP2_GMAC_CONFIG_FULL_DUPLEX;
+   else
+   val |= MVPP2_GMAC_AN_SPEED_EN |
+  MVPP2_GMAC_AN_DUPLEX_EN;
+
writel(val, port->base + MVPP2_GMAC_AUTONEG_CONFIG);
 }
 
@@ -4671,7 +4692,8 @@ static void mvpp2_port_mii_gmac_configure(struct 
mvpp2_port *port)
 
/* Configure the PCS and in-band AN */
val = readl(port->base + 

[PATCH net-next 6/6] arm64: dts: marvell: add Ethernet aliases

[Antoine Tenart]

From: Yan Markman 

This patch adds Ethernet aliases in the Marvell Aramada 7040 DB, 8040 DB
and 8040 mcbin device trees so that the bootloader setup the MAC
addresses correctly.

Signed-off-by: Yan Markman 
[Antoine: commit message, small fixes]
Signed-off-by: Antoine Tenart 
---
 arch/arm64/boot/dts/marvell/armada-7040-db.dts| 6 ++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts| 7 +++
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 7 +++
 3 files changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts 
b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 52b5341cb270..62b83416b30c 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -61,6 +61,12 @@
reg = <0x0 0x0 0x0 0x8000>;
};
 
+   aliases {
+   ethernet0 = _eth0;
+   ethernet1 = _eth1;
+   ethernet2 = _eth2;
+   };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "usb3h0-vbus";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts 
b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index d97b72bed662..d9fffde64c44 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -61,6 +61,13 @@
reg = <0x0 0x0 0x0 0x8000>;
};
 
+   aliases {
+   ethernet0 = _eth0;
+   ethernet1 = _eth2;
+   ethernet2 = _eth0;
+   ethernet3 = _eth1;
+   };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "cpm-usb3h0-vbus";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts 
b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index c51efd511324..7a23bb279e1c 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -62,6 +62,13 @@
reg = <0x0 0x0 0x0 0x8000>;
};
 
+   aliases {
+   ethernet0 = _eth0;
+   ethernet1 = _eth0;
+   ethernet2 = _eth1;
+   ethernet3 = _eth2;
+   };
+
/* Regulator labels correspond with schematics */
v_3_3: regulator-3-3v {
compatible = "regulator-fixed";
-- 
2.14.3

[PATCH net-next 6/6] arm64: dts: marvell: add Ethernet aliases

[Antoine Tenart]

From: Yan Markman 

This patch adds Ethernet aliases in the Marvell Aramada 7040 DB, 8040 DB
and 8040 mcbin device trees so that the bootloader setup the MAC
addresses correctly.

Signed-off-by: Yan Markman 
[Antoine: commit message, small fixes]
Signed-off-by: Antoine Tenart 
---
 arch/arm64/boot/dts/marvell/armada-7040-db.dts| 6 ++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts| 7 +++
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 7 +++
 3 files changed, 20 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts 
b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 52b5341cb270..62b83416b30c 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -61,6 +61,12 @@
reg = <0x0 0x0 0x0 0x8000>;
};
 
+   aliases {
+   ethernet0 = _eth0;
+   ethernet1 = _eth1;
+   ethernet2 = _eth2;
+   };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "usb3h0-vbus";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-db.dts 
b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
index d97b72bed662..d9fffde64c44 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-db.dts
@@ -61,6 +61,13 @@
reg = <0x0 0x0 0x0 0x8000>;
};
 
+   aliases {
+   ethernet0 = _eth0;
+   ethernet1 = _eth2;
+   ethernet2 = _eth0;
+   ethernet3 = _eth1;
+   };
+
cpm_reg_usb3_0_vbus: cpm-usb3-0-vbus {
compatible = "regulator-fixed";
regulator-name = "cpm-usb3h0-vbus";
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts 
b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
index c51efd511324..7a23bb279e1c 100644
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -62,6 +62,13 @@
reg = <0x0 0x0 0x0 0x8000>;
};
 
+   aliases {
+   ethernet0 = _eth0;
+   ethernet1 = _eth0;
+   ethernet2 = _eth1;
+   ethernet3 = _eth2;
+   };
+
/* Regulator labels correspond with schematics */
v_3_3: regulator-3-3v {
compatible = "regulator-fixed";
-- 
2.14.3

[PATCH net-next 0/6] net: mvpp2: 1000BaseX and 2000BaseX support

[Antoine Tenart]

Hi all,

This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
common PHY driver (cp110-comphy).

Thanks to theses patches the fourth network interface can be used on the
mcbin, and two patches are attached: one to describe the interface in
the mcbin device tree, and another one adding Ethernet aliases now that
the four interfaces are described.

This was tested on a mcbin.

Patches 1 and 2 should go through the PHY tree, patches 3 and 4 through
the net-next tree and patches 5 and 6 through the mvebu one.

Please note the two mvpp2 patches do not conflict with the ACPI series
Marcin sent a few days ago, and the two series can be processed in
parallel. (Marcin is aware of me sending this series).

Thanks!
Antoine

Antoine Tenart (5):
  phy: add 2.5G SGMII mode to the phy_mode enum
  phy: cp110-comphy: 2.5G SGMII mode
  net: mvpp2: 1000baseX support
  net: mvpp2: 2500baseX support
  arm64: dts: marvell: mcbin: enable the fourth network interface

Yan Markman (1):
  arm64: dts: marvell: add Ethernet aliases

 arch/arm64/boot/dts/marvell/armada-7040-db.dts|  6 ++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts|  7 +++
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 15 +
 drivers/net/ethernet/marvell/mvpp2.c  | 67 +++
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c  | 17 +-
 include/linux/phy/phy.h   |  1 +
 6 files changed, 100 insertions(+), 13 deletions(-)

-- 
2.14.3

[PATCH net-next 0/6] net: mvpp2: 1000BaseX and 2000BaseX support

[Antoine Tenart]

Hi all,

This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
common PHY driver (cp110-comphy).

Thanks to theses patches the fourth network interface can be used on the
mcbin, and two patches are attached: one to describe the interface in
the mcbin device tree, and another one adding Ethernet aliases now that
the four interfaces are described.

This was tested on a mcbin.

Patches 1 and 2 should go through the PHY tree, patches 3 and 4 through
the net-next tree and patches 5 and 6 through the mvebu one.

Please note the two mvpp2 patches do not conflict with the ACPI series
Marcin sent a few days ago, and the two series can be processed in
parallel. (Marcin is aware of me sending this series).

Thanks!
Antoine

Antoine Tenart (5):
  phy: add 2.5G SGMII mode to the phy_mode enum
  phy: cp110-comphy: 2.5G SGMII mode
  net: mvpp2: 1000baseX support
  net: mvpp2: 2500baseX support
  arm64: dts: marvell: mcbin: enable the fourth network interface

Yan Markman (1):
  arm64: dts: marvell: add Ethernet aliases

 arch/arm64/boot/dts/marvell/armada-7040-db.dts|  6 ++
 arch/arm64/boot/dts/marvell/armada-8040-db.dts|  7 +++
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 15 +
 drivers/net/ethernet/marvell/mvpp2.c  | 67 +++
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c  | 17 +-
 include/linux/phy/phy.h   |  1 +
 6 files changed, 100 insertions(+), 13 deletions(-)

-- 
2.14.3

[PATCH net-next 1/6] phy: add 2.5G SGMII mode to the phy_mode enum

[Antoine Tenart]

This patch adds one more generic PHY mode to the phy_mode enum, to allow
configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
callback.

Signed-off-by: Antoine Tenart 
---
 include/linux/phy/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a948d5..70459a28f3a1 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ enum phy_mode {
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
PHY_MODE_SGMII,
+   PHY_MODE_SGMII_2_5G,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
-- 
2.14.3

[PATCH net-next 1/6] phy: add 2.5G SGMII mode to the phy_mode enum

[Antoine Tenart]

This patch adds one more generic PHY mode to the phy_mode enum, to allow
configuring generic PHYs to the 2.5G SGMII mode by using the set_mode
callback.

Signed-off-by: Antoine Tenart 
---
 include/linux/phy/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 4f8423a948d5..70459a28f3a1 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ enum phy_mode {
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
PHY_MODE_SGMII,
+   PHY_MODE_SGMII_2_5G,
PHY_MODE_10GKR,
PHY_MODE_UFS_HS_A,
PHY_MODE_UFS_HS_B,
-- 
2.14.3

Re: [PATCH v3 1/5] dt-bindings: at24: consistently document the compatible property

[Peter Rosin]

On 2017-12-27 14:50, Bartosz Golaszewski wrote:
> Current description of the compatible property for at24 is quite vague.
> 
> State explicitly that any "," pair is accepted as
> long as one of the listed strings is used as fallback.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  Documentation/devicetree/bindings/eeprom/at24.txt | 37 
> +--
>  1 file changed, 15 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt 
> b/Documentation/devicetree/bindings/eeprom/at24.txt
> index cbc80e194ac6..b5ce5a247554 100644
> --- a/Documentation/devicetree/bindings/eeprom/at24.txt
> +++ b/Documentation/devicetree/bindings/eeprom/at24.txt
> @@ -2,28 +2,21 @@ EEPROMs (I2C)
>  
>  Required properties:
>  
> -  - compatible : should be ",", like these:
> -
> - "atmel,24c00", "atmel,24c01", "atmel,24c02", "atmel,24c04",
> - "atmel,24c08", "atmel,24c16", "atmel,24c32", "atmel,24c64",
> - "atmel,24c128", "atmel,24c256", "atmel,24c512", "atmel,24c1024"
> -
> - "catalyst,24c32"
> -
> - "microchip,24c128"
> -
> - "ramtron,24c64"
> -
> - "renesas,r1ex24002"
> -
> - The following manufacturers values have been deprecated:
> - "at", "at24"
> -
> -  If there is no specific driver for , a generic
> -  device with  and manufacturer "atmel" should be used.
> -  Possible types are:
> -  "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64",
> -  "24c128", "24c256", "24c512", "24c1024", "spd"
> +  - compatible: must be a "," pair with one of the
> +following values as fallback:
> +
> +"atmel,24c00",
> +"atmel,24c01",

I read the above as if it is no longer allowed to have a plain old atmel
chip, since the atmel compatibles are now valid as fallbacks /only/. I don't
think that's what you intended?

Cheers,
Peter

> +"atmel,24c02",
> +"atmel,24c04",
> +"atmel,24c08",
> +"atmel,24c16",
> +"atmel,24c32",
> +"atmel,24c64",
> +"atmel,24c128",
> +"atmel,24c256",
> +"atmel,24c512",
> +"atmel,24c1024"
>  
>- reg : the I2C address of the EEPROM
>  
> 

Re: [PATCH v3 1/5] dt-bindings: at24: consistently document the compatible property

[Peter Rosin]

On 2017-12-27 14:50, Bartosz Golaszewski wrote:
> Current description of the compatible property for at24 is quite vague.
> 
> State explicitly that any "," pair is accepted as
> long as one of the listed strings is used as fallback.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  Documentation/devicetree/bindings/eeprom/at24.txt | 37 
> +--
>  1 file changed, 15 insertions(+), 22 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/eeprom/at24.txt 
> b/Documentation/devicetree/bindings/eeprom/at24.txt
> index cbc80e194ac6..b5ce5a247554 100644
> --- a/Documentation/devicetree/bindings/eeprom/at24.txt
> +++ b/Documentation/devicetree/bindings/eeprom/at24.txt
> @@ -2,28 +2,21 @@ EEPROMs (I2C)
>  
>  Required properties:
>  
> -  - compatible : should be ",", like these:
> -
> - "atmel,24c00", "atmel,24c01", "atmel,24c02", "atmel,24c04",
> - "atmel,24c08", "atmel,24c16", "atmel,24c32", "atmel,24c64",
> - "atmel,24c128", "atmel,24c256", "atmel,24c512", "atmel,24c1024"
> -
> - "catalyst,24c32"
> -
> - "microchip,24c128"
> -
> - "ramtron,24c64"
> -
> - "renesas,r1ex24002"
> -
> - The following manufacturers values have been deprecated:
> - "at", "at24"
> -
> -  If there is no specific driver for , a generic
> -  device with  and manufacturer "atmel" should be used.
> -  Possible types are:
> -  "24c00", "24c01", "24c02", "24c04", "24c08", "24c16", "24c32", "24c64",
> -  "24c128", "24c256", "24c512", "24c1024", "spd"
> +  - compatible: must be a "," pair with one of the
> +following values as fallback:
> +
> +"atmel,24c00",
> +"atmel,24c01",

I read the above as if it is no longer allowed to have a plain old atmel
chip, since the atmel compatibles are now valid as fallbacks /only/. I don't
think that's what you intended?

Cheers,
Peter

> +"atmel,24c02",
> +"atmel,24c04",
> +"atmel,24c08",
> +"atmel,24c16",
> +"atmel,24c32",
> +"atmel,24c64",
> +"atmel,24c128",
> +"atmel,24c256",
> +"atmel,24c512",
> +"atmel,24c1024"
>  
>- reg : the I2C address of the EEPROM
>  
> 

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

[Rob Herring]

On Wed, Dec 27, 2017 at 4:20 AM, Sricharan R  wrote:
> Hi Rob,
>
> On 12/26/2017 11:06 PM, Rob Herring wrote:
>> On Thu, Dec 21, 2017 at 5:53 AM, Sricharan R  
>> wrote:
>>> Hi Rob,
>>>
>>> On 12/21/2017 2:48 AM, Rob Herring wrote:
 On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
> Hi Viresh,
>
> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
>> On 19-12-17, 21:25, Sricharan R wrote:
>>> +  cpu@0 {
>>> +  compatible = "qcom,krait";
>>> +  enable-method = "qcom,kpss-acc-v1";
>>> +  device_type = "cpu";
>>> +  reg = <0>;
>>> +  qcom,acc = <>;
>>> +  qcom,saw = <>;
>>> +  clocks = < 0>;
>>> +  clock-names = "cpu";
>>> +  cpu-supply = <_s2a>;
>>> +  operating-points-v2 = <_opp_table>;
>>> +  };
>>> +
>>> +  qcom,pvs {
>>> +  qcom,pvs-format-a;
>>> +  };
>>
>> Not sure what Rob is going to say on that :)
>>
>
>  Yes. Would be good to know the best way.

 Seems like this should be a property of an efuse node either implied by
 the compatible or a separate property. What determines format A vs. B?

>>>
>>>  Yes, this efuse registers are part of the eeprom (qfprom) tied to the soc.
>>>  So this property (details like bitfields and register offsets that it 
>>> represents)
>>>  can be put soc specific and nvmem apis can be used to read
>>>  the registers. Does something like below look ok ?
>>>
>>>  qcom,pvs {
>>> compatible = "qcom,pvs-ipq8064";
>>> nvmem-cells = <_efuse>;
>>>  }
>>
>> Why do you need this node? It doesn't look like it corresponds to a
>> h/w block. It looks like you are just creating it to instantiate a
>> driver.
>>
>>>  qfprom: qfprom@70 {
>>> compatible  = "qcom,qfprom";
>>
>> Either this or...
>>
>>> reg = <0x0070 0x1000>;
>>> #address-cells  = <1>;
>>> #size-cells = <1>;
>>> ranges;
>>> pvs_efuse: pvs {
>>
>> a compatible here should be specific enough so the OS can know what
>> the bits are.
>
>  Infact the above "qcom,pvs" node is required mainly to act as a consumer
>  for the nvmem data provider ("qcom,qfprom") (using nvmem-cells = 
> <_efuse>)
>  Then "qfprom" can be made to contain a "format_a" or "format_b" specific 
> cell.
>
>  So all that is needed is, nvmem-cells = <_efuse_phandle> needs to be 
> available
>  somewhere. The requirement is similar what is now done by 
> "operating-points-v2-ti-cpu"
>  and the ti-cpufreq.c. There "operating-points-v2-ti-cpu" node, contains the 
> syscon
>  register to read the efuse values. Similarly does defining a new
>  "operating-points-v2-krait-cpu" which would contain the nvmem-cells property 
> look ok ?
>  This would avoid defining a new qcom,pvs node.

Yes, this seems reasonable.

>
> cpu@0 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> reg = <0>;
> qcom,acc = <>;
> qcom,saw = <>;
> clocks = < 0>;
> clock-names = "cpu";
> cpu-supply = <_s2a>;
> operating-points-v2 = <_opp_table>;
> };
>
> cpu_opp_table: opp_table {
> compatible = "operating-points-v2-krait-cpu";
>
> nvmem-cells = <_efuse_format_a>;
> /*
>  * Missing opp-shared property means CPUs switch DVFS states
>  * independently.
>  */
>
> opp-14 {
> opp-hz = /bits/ 64 <14>;
> opp-microvolt-speed0-pvs0-v0 = <125>;
> opp-microvolt-speed0-pvs1-v0 = <1175000>;
> opp-microvolt-speed0-pvs2-v0 = <1125000>;
> opp-microvolt-speed0-pvs3-v0 = <105>;
>
> };
> ...
> }
>
> qfprom: qfprom@70 {
> compatible  = "qcom,qfprom";
> reg = <0x0070 0x1000>;
> #address-cells  = <1>;
> #size-cells = <1>;
> ranges;
> pvs_efuse_format_a: pvs {
> reg = <0xc0 0x8>;
> };
> }
>
> Regards,
>  Sricharan
>
> --
> "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
> Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs

[Rob Herring]

On Wed, Dec 27, 2017 at 4:20 AM, Sricharan R  wrote:
> Hi Rob,
>
> On 12/26/2017 11:06 PM, Rob Herring wrote:
>> On Thu, Dec 21, 2017 at 5:53 AM, Sricharan R  
>> wrote:
>>> Hi Rob,
>>>
>>> On 12/21/2017 2:48 AM, Rob Herring wrote:
 On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote:
> Hi Viresh,
>
> On 12/20/2017 8:56 AM, Viresh Kumar wrote:
>> On 19-12-17, 21:25, Sricharan R wrote:
>>> +  cpu@0 {
>>> +  compatible = "qcom,krait";
>>> +  enable-method = "qcom,kpss-acc-v1";
>>> +  device_type = "cpu";
>>> +  reg = <0>;
>>> +  qcom,acc = <>;
>>> +  qcom,saw = <>;
>>> +  clocks = < 0>;
>>> +  clock-names = "cpu";
>>> +  cpu-supply = <_s2a>;
>>> +  operating-points-v2 = <_opp_table>;
>>> +  };
>>> +
>>> +  qcom,pvs {
>>> +  qcom,pvs-format-a;
>>> +  };
>>
>> Not sure what Rob is going to say on that :)
>>
>
>  Yes. Would be good to know the best way.

 Seems like this should be a property of an efuse node either implied by
 the compatible or a separate property. What determines format A vs. B?

>>>
>>>  Yes, this efuse registers are part of the eeprom (qfprom) tied to the soc.
>>>  So this property (details like bitfields and register offsets that it 
>>> represents)
>>>  can be put soc specific and nvmem apis can be used to read
>>>  the registers. Does something like below look ok ?
>>>
>>>  qcom,pvs {
>>> compatible = "qcom,pvs-ipq8064";
>>> nvmem-cells = <_efuse>;
>>>  }
>>
>> Why do you need this node? It doesn't look like it corresponds to a
>> h/w block. It looks like you are just creating it to instantiate a
>> driver.
>>
>>>  qfprom: qfprom@70 {
>>> compatible  = "qcom,qfprom";
>>
>> Either this or...
>>
>>> reg = <0x0070 0x1000>;
>>> #address-cells  = <1>;
>>> #size-cells = <1>;
>>> ranges;
>>> pvs_efuse: pvs {
>>
>> a compatible here should be specific enough so the OS can know what
>> the bits are.
>
>  Infact the above "qcom,pvs" node is required mainly to act as a consumer
>  for the nvmem data provider ("qcom,qfprom") (using nvmem-cells = 
> <_efuse>)
>  Then "qfprom" can be made to contain a "format_a" or "format_b" specific 
> cell.
>
>  So all that is needed is, nvmem-cells = <_efuse_phandle> needs to be 
> available
>  somewhere. The requirement is similar what is now done by 
> "operating-points-v2-ti-cpu"
>  and the ti-cpufreq.c. There "operating-points-v2-ti-cpu" node, contains the 
> syscon
>  register to read the efuse values. Similarly does defining a new
>  "operating-points-v2-krait-cpu" which would contain the nvmem-cells property 
> look ok ?
>  This would avoid defining a new qcom,pvs node.

Yes, this seems reasonable.

>
> cpu@0 {
> compatible = "qcom,krait";
> enable-method = "qcom,kpss-acc-v1";
> device_type = "cpu";
> reg = <0>;
> qcom,acc = <>;
> qcom,saw = <>;
> clocks = < 0>;
> clock-names = "cpu";
> cpu-supply = <_s2a>;
> operating-points-v2 = <_opp_table>;
> };
>
> cpu_opp_table: opp_table {
> compatible = "operating-points-v2-krait-cpu";
>
> nvmem-cells = <_efuse_format_a>;
> /*
>  * Missing opp-shared property means CPUs switch DVFS states
>  * independently.
>  */
>
> opp-14 {
> opp-hz = /bits/ 64 <14>;
> opp-microvolt-speed0-pvs0-v0 = <125>;
> opp-microvolt-speed0-pvs1-v0 = <1175000>;
> opp-microvolt-speed0-pvs2-v0 = <1125000>;
> opp-microvolt-speed0-pvs3-v0 = <105>;
>
> };
> ...
> }
>
> qfprom: qfprom@70 {
> compatible  = "qcom,qfprom";
> reg = <0x0070 0x1000>;
> #address-cells  = <1>;
> #size-cells = <1>;
> ranges;
> pvs_efuse_format_a: pvs {
> reg = <0xc0 0x8>;
> };
> }
>
> Regards,
>  Sricharan
>
> --
> "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
> Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

[Rob Herring]

On Wed, Dec 27, 2017 at 2:56 AM, Viresh Kumar  wrote:
> On 26-12-17, 14:29, Rob Herring wrote:
>> On Mon, Dec 18, 2017 at 03:51:30PM +0530, Viresh Kumar wrote:
>
>> > +On some platforms the exact frequency or voltage may be hidden from the 
>> > OS by
>> > +the firmware and the "opp-hz" or the "opp-microvolt" properties may 
>> > contain
>> > +magic values that represent the frequency or voltage in a firmware 
>> > dependent
>> > +way, for example an index of an array in the firmware.
>>
>> I'm still not convinced this is a good idea.
>
> You were kind-of a few days back :)
>
> lkml.kernel.org/r/CAL_JsqK-qtAaM_Ou5NtxcWR3F_q=8rmpjum-vqgtkhbtwe5...@mail.gmail.com

Yeah, well that was before Stephen said anything.

> So here is the deal:
>
> - I proposed "domain-performance-state" property for this stuff
>   initially.
> - But Kevin didn't like that and proposed reusing "opp-hz" and
>   "opp-microvolt", which we all agreed to multiple times..
> - And we are back to the same discussion now and its painful and time
>   killing for all of us.

There's bigger issues than where we put magic values as I raised in
the other patch.

> TBH, I don't have too strong preferences about any of the suggestions
> you guys have and I need you guys to tell me what binding changes to
> do here and I will do that.
>
>> If you have firmware
>> partially managing things, then I think we should have platform specific
>> bindings or drivers.
>
> What about the initial idea then, like "performance-state" for the
> power domains ? All platforms will anyway replicate that binding only.

I don't really know. I don't really care either. I'll probably go
along with what everyone agrees to, but the only one I see any
agreement from is Ulf. Also, it is pretty vague as to what platforms
will use this. You claimed you can support QCom scenarios, but there's
really no evidence that that is true. What I don't want to see is this
merged and then we need something more yet again in a few months for
another platform.

Rob

Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

[Rob Herring]

On Wed, Dec 27, 2017 at 2:56 AM, Viresh Kumar  wrote:
> On 26-12-17, 14:29, Rob Herring wrote:
>> On Mon, Dec 18, 2017 at 03:51:30PM +0530, Viresh Kumar wrote:
>
>> > +On some platforms the exact frequency or voltage may be hidden from the 
>> > OS by
>> > +the firmware and the "opp-hz" or the "opp-microvolt" properties may 
>> > contain
>> > +magic values that represent the frequency or voltage in a firmware 
>> > dependent
>> > +way, for example an index of an array in the firmware.
>>
>> I'm still not convinced this is a good idea.
>
> You were kind-of a few days back :)
>
> lkml.kernel.org/r/CAL_JsqK-qtAaM_Ou5NtxcWR3F_q=8rmpjum-vqgtkhbtwe5...@mail.gmail.com

Yeah, well that was before Stephen said anything.

> So here is the deal:
>
> - I proposed "domain-performance-state" property for this stuff
>   initially.
> - But Kevin didn't like that and proposed reusing "opp-hz" and
>   "opp-microvolt", which we all agreed to multiple times..
> - And we are back to the same discussion now and its painful and time
>   killing for all of us.

There's bigger issues than where we put magic values as I raised in
the other patch.

> TBH, I don't have too strong preferences about any of the suggestions
> you guys have and I need you guys to tell me what binding changes to
> do here and I will do that.
>
>> If you have firmware
>> partially managing things, then I think we should have platform specific
>> bindings or drivers.
>
> What about the initial idea then, like "performance-state" for the
> power domains ? All platforms will anyway replicate that binding only.

I don't really know. I don't really care either. I'll probably go
along with what everyone agrees to, but the only one I see any
agreement from is Ulf. Also, it is pretty vague as to what platforms
will use this. You claimed you can support QCom scenarios, but there's
really no evidence that that is true. What I don't want to see is this
merged and then we need something more yet again in a few months for
another platform.

Rob

Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver

[Philippe Ombredanne]

Łukasz,

On Wed, Dec 27, 2017 at 11:12 AM, Łukasz Stelmach
 wrote:
> It was <2017-12-22 pią 19:30>, when Philippe Ombredanne wrote:
>> On Fri, Dec 22, 2017 at 5:38 PM, Łukasz Stelmach  
>> wrote:
>>> It was <2017-12-22 pią 14:34>, when Philippe Ombredanne wrote:
 Łukasz,

 On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach  
 wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach 
> Reviewed-by: Krzysztof Kozlowski 

 

> --- /dev/null
> +++ b/drivers/char/hw_random/exynos-trng.c
> @@ -0,0 +1,245 @@
> +/*
> + * RNG driver for Exynos TRNGs
> + *
> + * Author: Łukasz Stelmach 
> + *
> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
> + *
> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
> + * Krzysztof Kozłowski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation;
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */


 Would you mind using the new SPDX tags documented in Thomas patch set
 [1] rather than this fine but longer legalese?

 And if you could spread the word to others in your team this would be very 
 nice.
 See also this fine article posted by Mauro on the Samsung Open Source
 Group Blog [2]
 Thank you!
>>>
>>> Cool! We've been using SPDX to tag RPM packages in Tizen for three years or
>>> more. ;-)
>>
>> Very nice! any pubic pointers?
>  ^
>
> I assume you request an URL of a publicly available web-page ;-)
>
> https://wiki.tizen.org/Packaging/Guidelines#License_Tag

Thank you!
I reckon it took me a minute to figure why you were making a somewhat
cryptic URL related comment.
Then I realized that I had made a rather unfortunate typo, or may be
it was a freudian slip of sorts :D

-- 
Cordially
Philippe Ombredanne

Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver

[Philippe Ombredanne]

Łukasz,

On Wed, Dec 27, 2017 at 11:12 AM, Łukasz Stelmach
 wrote:
> It was <2017-12-22 pią 19:30>, when Philippe Ombredanne wrote:
>> On Fri, Dec 22, 2017 at 5:38 PM, Łukasz Stelmach  
>> wrote:
>>> It was <2017-12-22 pią 14:34>, when Philippe Ombredanne wrote:
 Łukasz,

 On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach  
 wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach 
> Reviewed-by: Krzysztof Kozlowski 

 

> --- /dev/null
> +++ b/drivers/char/hw_random/exynos-trng.c
> @@ -0,0 +1,245 @@
> +/*
> + * RNG driver for Exynos TRNGs
> + *
> + * Author: Łukasz Stelmach 
> + *
> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
> + *
> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
> + * Krzysztof Kozłowski 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation;
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */


 Would you mind using the new SPDX tags documented in Thomas patch set
 [1] rather than this fine but longer legalese?

 And if you could spread the word to others in your team this would be very 
 nice.
 See also this fine article posted by Mauro on the Samsung Open Source
 Group Blog [2]
 Thank you!
>>>
>>> Cool! We've been using SPDX to tag RPM packages in Tizen for three years or
>>> more. ;-)
>>
>> Very nice! any pubic pointers?
>  ^
>
> I assume you request an URL of a publicly available web-page ;-)
>
> https://wiki.tizen.org/Packaging/Guidelines#License_Tag

Thank you!
I reckon it took me a minute to figure why you were making a somewhat
cryptic URL related comment.
Then I realized that I had made a rather unfortunate typo, or may be
it was a freudian slip of sorts :D

-- 
Cordially
Philippe Ombredanne

[PATCH] pinctrl: spear: Delete an error message for a failed memory allocation in spear_pinctrl_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 27 Dec 2017 22:44:04 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/pinctrl/spear/pinctrl-spear.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pinctrl/spear/pinctrl-spear.c 
b/drivers/pinctrl/spear/pinctrl-spear.c
index 4db52ba38d8d..efe79d3f7659 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -361,10 +361,8 @@ int spear_pinctrl_probe(struct platform_device *pdev,
return -ENODEV;
 
pmx = devm_kzalloc(>dev, sizeof(*pmx), GFP_KERNEL);
-   if (!pmx) {
-   dev_err(>dev, "Can't alloc spear_pmx\n");
+   if (!pmx)
return -ENOMEM;
-   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pmx->vbase = devm_ioremap_resource(>dev, res);
-- 
2.15.1

[PATCH] pinctrl: spear: Delete an error message for a failed memory allocation in spear_pinctrl_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Wed, 27 Dec 2017 22:44:04 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/pinctrl/spear/pinctrl-spear.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pinctrl/spear/pinctrl-spear.c 
b/drivers/pinctrl/spear/pinctrl-spear.c
index 4db52ba38d8d..efe79d3f7659 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -361,10 +361,8 @@ int spear_pinctrl_probe(struct platform_device *pdev,
return -ENODEV;
 
pmx = devm_kzalloc(>dev, sizeof(*pmx), GFP_KERNEL);
-   if (!pmx) {
-   dev_err(>dev, "Can't alloc spear_pmx\n");
+   if (!pmx)
return -ENOMEM;
-   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pmx->vbase = devm_ioremap_resource(>dev, res);
-- 
2.15.1

Re: [PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Sakari Ailus]

Hi Yong,

On Thu, Dec 21, 2017 at 10:49:35AM +0800, Yong wrote:
> Hi,
> 
> On Tue, 19 Dec 2017 13:53:28 +0200
> Sakari Ailus  wrote:
> 
> > Hi Yong,
> > 
> > On Thu, Jul 27, 2017 at 01:01:36PM +0800, Yong Deng wrote:
> > > Add binding documentation for Allwinner V3s CSI.
> > > 
> > > Signed-off-by: Yong Deng 
> > 
> > DT bindings should precede the driver.
> 
> OK.
> 
> > 
> > > ---
> > >  .../devicetree/bindings/media/sun6i-csi.txt| 49 
> > > ++
> > >  1 file changed, 49 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
> > > b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > new file mode 100644
> > > index 000..f8d83f6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > @@ -0,0 +1,49 @@
> > > +Allwinner V3s Camera Sensor Interface
> > > +--
> > > +
> > > +Required properties:
> > > +  - compatible: value must be "allwinner,sun8i-v3s-csi"
> > 
> > What are sun6i and sun8i? Is this device first present in sun6i SoCs,
> > whereas you have only defined bindings for sun8i?
> 
> Yes, some sun6i SoCs has the almost same CSI module.
> There is only V3s on my hand. So, I only tested it on V3s. But
> some people work on the others.

Ack.

> 
> > 
> > > +  - reg: base address and size of the memory-mapped region.
> > > +  - interrupts: interrupt associated to this IP
> > > +  - clocks: phandles to the clocks feeding the CSI
> > > +* ahb: the CSI interface clock
> > > +* mod: the CSI module clock
> > > +* ram: the CSI DRAM clock
> > > +  - clock-names: the clock names mentioned above
> > > +  - resets: phandles to the reset line driving the CSI
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> > 
> > Please document mandatory and optional endpoint properties relevant for the
> > hardware.
> 
> I have added below commit in my v3:
> Currently, the driver only support the parallel interface. So, a single port
> node with one endpoint and parallel bus is supported.

Please specify the exact properties that are relevant for the hardware. No
references should be made to the driver, the bindings are entirely
separate.

Are the non-parallel (CSI-2?) and parallel bus on the same interface? If
yes, they should probably use different endpoints, if not, then different
ports.

You could document the other bus or omit it now altogether, in which case
you'd only detail the parallel bus properties here.

> 
> > 
> > > +
> > > +Example:
> > > +
> > > + csi1: csi@01cb4000 {
> > > + compatible = "allwinner,sun8i-v3s-csi";
> > > + reg = <0x01cb4000 0x1000>;
> > > + interrupts = ;
> > > + clocks = < CLK_BUS_CSI>,
> > > +  < CLK_CSI1_SCLK>,
> > > +  < CLK_DRAM_CSI>;
> > > + clock-names = "ahb", "mod", "ram";
> > > + resets = < RST_BUS_CSI>;
> > > +
> > > + port {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + /* Parallel bus endpoint */
> > > + csi1_ep: endpoint {
> > > + remote-endpoint = <_ep>;
> > > + bus-width = <16>;
> > > + data-shift = <0>;
> > > +
> > > + /* If hsync-active/vsync-active are missing,
> > > +embedded BT.656 sync is used */
> > > + hsync-active = <0>; /* Active low */
> > > + vsync-active = <0>; /* Active low */
> > > + data-active = <1>;  /* Active high */
> > > + pclk-sample = <1>;  /* Rising */
> > > + };
> > > + };
> > > + };
> > > +
> > 
> > -- 
> > Kind regards,
> > 
> > Sakari Ailus
> > e-mail: sakari.ai...@iki.fi
> 
> 
> Thanks,
> Yong

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: [PATCH v2 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)

[Sakari Ailus]

Hi Yong,

On Thu, Dec 21, 2017 at 10:49:35AM +0800, Yong wrote:
> Hi,
> 
> On Tue, 19 Dec 2017 13:53:28 +0200
> Sakari Ailus  wrote:
> 
> > Hi Yong,
> > 
> > On Thu, Jul 27, 2017 at 01:01:36PM +0800, Yong Deng wrote:
> > > Add binding documentation for Allwinner V3s CSI.
> > > 
> > > Signed-off-by: Yong Deng 
> > 
> > DT bindings should precede the driver.
> 
> OK.
> 
> > 
> > > ---
> > >  .../devicetree/bindings/media/sun6i-csi.txt| 49 
> > > ++
> > >  1 file changed, 49 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt 
> > > b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > new file mode 100644
> > > index 000..f8d83f6
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > > @@ -0,0 +1,49 @@
> > > +Allwinner V3s Camera Sensor Interface
> > > +--
> > > +
> > > +Required properties:
> > > +  - compatible: value must be "allwinner,sun8i-v3s-csi"
> > 
> > What are sun6i and sun8i? Is this device first present in sun6i SoCs,
> > whereas you have only defined bindings for sun8i?
> 
> Yes, some sun6i SoCs has the almost same CSI module.
> There is only V3s on my hand. So, I only tested it on V3s. But
> some people work on the others.

Ack.

> 
> > 
> > > +  - reg: base address and size of the memory-mapped region.
> > > +  - interrupts: interrupt associated to this IP
> > > +  - clocks: phandles to the clocks feeding the CSI
> > > +* ahb: the CSI interface clock
> > > +* mod: the CSI module clock
> > > +* ram: the CSI DRAM clock
> > > +  - clock-names: the clock names mentioned above
> > > +  - resets: phandles to the reset line driving the CSI
> > > +
> > > +- ports: A ports node with endpoint definitions as defined in
> > > +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> > 
> > Please document mandatory and optional endpoint properties relevant for the
> > hardware.
> 
> I have added below commit in my v3:
> Currently, the driver only support the parallel interface. So, a single port
> node with one endpoint and parallel bus is supported.

Please specify the exact properties that are relevant for the hardware. No
references should be made to the driver, the bindings are entirely
separate.

Are the non-parallel (CSI-2?) and parallel bus on the same interface? If
yes, they should probably use different endpoints, if not, then different
ports.

You could document the other bus or omit it now altogether, in which case
you'd only detail the parallel bus properties here.

> 
> > 
> > > +
> > > +Example:
> > > +
> > > + csi1: csi@01cb4000 {
> > > + compatible = "allwinner,sun8i-v3s-csi";
> > > + reg = <0x01cb4000 0x1000>;
> > > + interrupts = ;
> > > + clocks = < CLK_BUS_CSI>,
> > > +  < CLK_CSI1_SCLK>,
> > > +  < CLK_DRAM_CSI>;
> > > + clock-names = "ahb", "mod", "ram";
> > > + resets = < RST_BUS_CSI>;
> > > +
> > > + port {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + /* Parallel bus endpoint */
> > > + csi1_ep: endpoint {
> > > + remote-endpoint = <_ep>;
> > > + bus-width = <16>;
> > > + data-shift = <0>;
> > > +
> > > + /* If hsync-active/vsync-active are missing,
> > > +embedded BT.656 sync is used */
> > > + hsync-active = <0>; /* Active low */
> > > + vsync-active = <0>; /* Active low */
> > > + data-active = <1>;  /* Active high */
> > > + pclk-sample = <1>;  /* Rising */
> > > + };
> > > + };
> > > + };
> > > +
> > 
> > -- 
> > Kind regards,
> > 
> > Sakari Ailus
> > e-mail: sakari.ai...@iki.fi
> 
> 
> Thanks,
> Yong

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi

Re: v4.15: camera problems on n900

[Pavel Machek]

1;2802;0cOn Wed 2017-12-27 23:17:19, Sakari Ailus wrote:
> On Wed, Dec 27, 2017 at 10:05:43PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
> > seconds, but then I get repeated oopses.
> > 
> > On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
> > camera does not start.
> > 
> > Any ideas what might be wrong there?
> 
> What kind of oopses do you get?

They seemed to be in unrelated processes -> not useful for
debugging. I tried again, but this time it hangs, similar way to
-rc0.5. (That might be good news).

Does it work for you on N9?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 2/3] dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap,memcpy'

[Cyrille Pitchen]

Hi Rob,

+ Ludovic Desroches, maintainer of the DMA controller drivers for AT91 SoCs.

Le 27/12/2017 à 00:23, Rob Herring a écrit :
> On Sun, Dec 24, 2017 at 05:36:05AM +0100, Cyrille Pitchen wrote:
>> The optional 'dmacap,memcpy' DT property tells the Atmel QSPI controller
>> driver to reserve some DMA channel then to use it to perform DMA
>> memcpy() during data transfers. This feature relies on the generic
>> bounce buffer helper from spi-nor.c.
>>
>> Signed-off-by: Cyrille Pitchen 
>> ---
>>  Documentation/devicetree/bindings/mtd/atmel-quadspi.txt | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt 
>> b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
>> index b93c1e2f25dd..002d3f0a445b 100644
>> --- a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
>> +++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
>> @@ -12,6 +12,10 @@ Required properties:
>>  - #address-cells: Should be <1>.
>>  - #size-cells:Should be <0>.
>>  
>> +Optional properties:
>> +- dmacap,memcpy:  Reserve a DMA channel to perform DMA memcpy() between the
>> +  system memory and the QSPI mapped memory.
> 
> How is this a h/w property? Why would I not want to always enable DMA if 
> possible?

The number of DMA channels is limited for a given SoC. This number may be
lower than the number of enabled controllers (spi, i2c, qspi, aes, sha,
des, sdmmc, usart, ...).

So we use a DT property to explicitly tell the matching drivers to request
and reserved the DMA channels they need. This policy is not driver or even
SoC specific but board specific. It's very common to reserved DMA channels
for the most used or most performance dependent controllers, setting the
relevant properties in the device-tree then restricting remaining
controllers to their PIO mode.

> 
> Furthermore, you are reusing a property, but giving it a different 
> meaning. The current definition is an indication whether a DMA 
> controller supports memcpy operations or not. It is not a flag for 
> clients to use memcpy channels.
>

I don't mind changing the name. I thought it would be better to use some
existing one than creating another. However I was not confident on whether
"dmacap,memcpy" was actually a good candidate for what I do in the DMA
patch for the atmel-quadspi.c driver.

Actually, I was relying on your feedbacks :)

> Why don't you use "dmas" property to point to the DMA controller.

I didn't use the "dmas" property because I thought it would not have been
consistent with how this property is used in all other nodes of the sama5*
device-trees. The flags provided in the dma-cells are designed for "memory
to peripheral" or "peripheral to memory" DMA transfers only.

However, here I need to perform some "memory to memory" transfer: the SPI
NOR flash memory is mapped into the AHB bus of SAMA5D2 SoCs. Besides,
once in Serial Memory Mode, data can no longer be transfered through the
TDR or RDR registers of the QSPI controller, only through its AHB mapped
memory window.

So I cannot configured the DMA channel for "peripheral to memory" or
"memory to peripheral" like for other controllers embedded in the SoC but
only for "memory to memory".

Maybe we could extend the flags supported by the "dmas" property but I
guess it may require some little rework in the at_xdmac_xlate() function
of the at_xdmac.c driver.

Or maybe no change at all is required at the at_xdmac.c driver side: we
just don't care about the provided flags in the "dmas" property, especially
the "peripheral id". They would be ignored anyway when the atmel-quadspi.c
driver later calls dmaengine_prep_dma_memcpy(). So I could simply set the
dma cells to 0 in the device-tree?

Ludovic, what do you think about that ?


Best regards,

Cyrille

> 
>> +
>>  Example:
>>  
>>  spi@f002 {
>> @@ -24,6 +28,7 @@ spi@f002 {
>>  #size-cells = <0>;
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_spi0_default>;
>> +dmacap,memcpy;
>>  
>>  m25p80@0 {
>>  ...
>> -- 
>> 2.11.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: v4.15: camera problems on n900

[Pavel Machek]

1;2802;0cOn Wed 2017-12-27 23:17:19, Sakari Ailus wrote:
> On Wed, Dec 27, 2017 at 10:05:43PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > In v4.14, back camera on N900 works. On v4.15-rc1.. it works for few
> > seconds, but then I get repeated oopses.
> > 
> > On v4.15-rc0.5 (commit ed30b147e1f6e396e70a52dbb6c7d66befedd786),
> > camera does not start.
> > 
> > Any ideas what might be wrong there?
> 
> What kind of oopses do you get?

They seemed to be in unrelated processes -> not useful for
debugging. I tried again, but this time it hangs, similar way to
-rc0.5. (That might be good news).

Does it work for you on N9?

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 2/3] dt-bindings: mtd: atmel-quadspi: add an optional property 'dmacap,memcpy'

[Cyrille Pitchen]

Hi Rob,

+ Ludovic Desroches, maintainer of the DMA controller drivers for AT91 SoCs.

Le 27/12/2017 à 00:23, Rob Herring a écrit :
> On Sun, Dec 24, 2017 at 05:36:05AM +0100, Cyrille Pitchen wrote:
>> The optional 'dmacap,memcpy' DT property tells the Atmel QSPI controller
>> driver to reserve some DMA channel then to use it to perform DMA
>> memcpy() during data transfers. This feature relies on the generic
>> bounce buffer helper from spi-nor.c.
>>
>> Signed-off-by: Cyrille Pitchen 
>> ---
>>  Documentation/devicetree/bindings/mtd/atmel-quadspi.txt | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt 
>> b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
>> index b93c1e2f25dd..002d3f0a445b 100644
>> --- a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
>> +++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
>> @@ -12,6 +12,10 @@ Required properties:
>>  - #address-cells: Should be <1>.
>>  - #size-cells:Should be <0>.
>>  
>> +Optional properties:
>> +- dmacap,memcpy:  Reserve a DMA channel to perform DMA memcpy() between the
>> +  system memory and the QSPI mapped memory.
> 
> How is this a h/w property? Why would I not want to always enable DMA if 
> possible?

The number of DMA channels is limited for a given SoC. This number may be
lower than the number of enabled controllers (spi, i2c, qspi, aes, sha,
des, sdmmc, usart, ...).

So we use a DT property to explicitly tell the matching drivers to request
and reserved the DMA channels they need. This policy is not driver or even
SoC specific but board specific. It's very common to reserved DMA channels
for the most used or most performance dependent controllers, setting the
relevant properties in the device-tree then restricting remaining
controllers to their PIO mode.

> 
> Furthermore, you are reusing a property, but giving it a different 
> meaning. The current definition is an indication whether a DMA 
> controller supports memcpy operations or not. It is not a flag for 
> clients to use memcpy channels.
>

I don't mind changing the name. I thought it would be better to use some
existing one than creating another. However I was not confident on whether
"dmacap,memcpy" was actually a good candidate for what I do in the DMA
patch for the atmel-quadspi.c driver.

Actually, I was relying on your feedbacks :)

> Why don't you use "dmas" property to point to the DMA controller.

I didn't use the "dmas" property because I thought it would not have been
consistent with how this property is used in all other nodes of the sama5*
device-trees. The flags provided in the dma-cells are designed for "memory
to peripheral" or "peripheral to memory" DMA transfers only.

However, here I need to perform some "memory to memory" transfer: the SPI
NOR flash memory is mapped into the AHB bus of SAMA5D2 SoCs. Besides,
once in Serial Memory Mode, data can no longer be transfered through the
TDR or RDR registers of the QSPI controller, only through its AHB mapped
memory window.

So I cannot configured the DMA channel for "peripheral to memory" or
"memory to peripheral" like for other controllers embedded in the SoC but
only for "memory to memory".

Maybe we could extend the flags supported by the "dmas" property but I
guess it may require some little rework in the at_xdmac_xlate() function
of the at_xdmac.c driver.

Or maybe no change at all is required at the at_xdmac.c driver side: we
just don't care about the provided flags in the "dmas" property, especially
the "peripheral id". They would be ignored anyway when the atmel-quadspi.c
driver later calls dmaengine_prep_dma_memcpy(). So I could simply set the
dma cells to 0 in the device-tree?

Ludovic, what do you think about that ?


Best regards,

Cyrille

> 
>> +
>>  Example:
>>  
>>  spi@f002 {
>> @@ -24,6 +28,7 @@ spi@f002 {
>>  #size-cells = <0>;
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_spi0_default>;
>> +dmacap,memcpy;
>>  
>>  m25p80@0 {
>>  ...
>> -- 
>> 2.11.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>