[PATCH] ARM: i.MX25: fixup broken DryIce GPR

2016-02-03 Thread Steffen Trumtrar 
Fixup the DryIce Non-Non-Volatile-Memory GPR register.

Signed-off-by: Steffen Trumtrar 
---
 arch/arm/mach-imx/imx25.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/mach-imx/imx25.c b/arch/arm/mach-imx/imx25.c
index 8761d636820f..3cfeebbe9348 100644
--- a/arch/arm/mach-imx/imx25.c
+++ b/arch/arm/mach-imx/imx25.c
@@ -20,6 +20,9 @@
 #include 
 #include 
 
+#define MX25_BOOTROM_HAB_MAGIC 0x3c95cac6
+#define MX25_DRYICE_GPR0x3c
+
 void imx25_setup_weimcs(size_t cs, unsigned upper, unsigned lower,
unsigned additional)
 {
@@ -55,9 +58,32 @@ u64 imx_uid(void)
 
 int imx25_init(void)
 {
+   int val;
+
imx25_boot_save_loc((void *)MX25_CCM_BASE_ADDR);
add_generic_device("imx25-esdctl", 0, NULL, MX25_ESDCTL_BASE_ADDR, 
0x1000, IORESOURCE_MEM, NULL);
 
+   /*
+* When the i.MX25 is used with internal boot, the boot ROM always
+* performs some HAB actions. These will copy the value from DryIce
+* GPR (0x53ffc03c) to a location in SRAM (0x78001734) and then 
overwrites
+* the GPR with 0x3c95cac6.
+* After the HAB routine is done, the boot ROM should copy the 
previously
+* saved value from SRAM back to the GPR. The last step is not done.
+* The boot ROM is officially broken in this regard.
+* This renders the Non-volatile memory to a Non-Non-volatile memory.
+* To still be able to use the GPR for its intended purpose, copy the
+* saved SRAM value back manually.
+*/
+   val = readl(MX25_IRAM_BASE_ADDR + 0x1734);
+
+   /*
+* When there is a different value in SRAM than the magic value
+* it must be a value saved to the GPR.
+*/
+   if (val != MX25_BOOTROM_HAB_MAGIC)
+   writel(val, MX25_DRYICE_BASE_ADDR + MX25_DRYICE_GPR);
+
return 0;
 }
 
-- 
2.7.0.rc3


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: scripts/remote: make clean leftovers

2016-02-03 Thread Jan Lübbe 
On Mi, 2016-02-03 at 08:55 +0100, Sascha Hauer wrote:
> On Tue, Jan 26, 2016 at 11:49:09AM +0100, Jan Lübbe wrote:
> > On Di, 2016-01-26 at 11:04 +0100, Yegor Yefremov wrote:
> > > After performing make distclean I've discovered following files being 
> > > removed:
> > > 
> > > Changes not staged for commit:
> > >   (use "git add/rm ..." to update what will be committed)
> > >   (use "git checkout -- ..." to discard changes in working 
> > > directory)
> > > 
> > > deleted:scripts/remote/__init__.py
> > > deleted:scripts/serial/tools/__init__.py
> > > deleted:scripts/serial/urlhandler/__init__.py
> > > 
> > > What should actually happen to these files?
> > 
> > Python uses these files to recognize the directory as containing a
> > module, so we need to keep them.
> 
> They get removed by make distclean, supposedly because they are empty.
> What should they contain? Is it ok to put a comment in them to make them
> non-empty?

Yes, just add a short comment documenting that they need to exist.


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC 1/2] misc: Add MAC address mapper "driver"

2016-02-03 Thread Andrey Smirnov 
On Wed, Feb 3, 2016 at 10:40 AM, Trent Piepho  wrote:
> On Tue, 2016-02-02 at 17:14 -0800, Andrey Smirnov wrote:
>> On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho  wrote:
>> > The way imx28 works in the kernel is to just store the extension in the
>> > OCOTP.  The OUI is determined from the board's compatible property and a
>> > hard coded table in the kernel.  See arch/arm/mach-mxs/mach-mxs.c
>> >
>> > While, IMHO, the hard coded table is ugly, and should have died long
>> > ago, there are board that don't have the entire mac burned into OCOTP.
>> > It seems like neither of these bindings could support a board like this.
>> >
>>
>> What if you created a 'nvmem' provider whose only job is to take a
>> blob from DT, a phandle to another 'nvmem' provider and to return the
>> combined data from both sources. Wouldn't it work for the use-case you
>> are describing?
>
> Not sure what it would look like, example?

I am thinking of something similar to what you describe in "nvmem"
thread. You'd have a software scatter-gather "engine" that would just
take a description of multiple small chunks of memory and represent it
as a continuous property accessible via "nvmem" API. Something like:

mac-address-node {
   compatible = "nvmem-sg"

   composite_mac: mac@0 {
 reg = <_cell 0x0 0x4
 _cell 0x0 0x2
   >;
   };
 };

So you'd get a 'composite_mac' nvmem-cell that in term is comprised of
4 bytes @ offset 0x0 of "nvmem1_cell" and 2 bytes @ offset 0x0 of
"nvmem2_cell".


>
> One thing about the imx28 OCOTP is that the entire MAC isn't in the
> OCOTP.  The OUI part comes from "elsewhere".
>
> In the current kernel, that elsewhere is a hardcoded /board/compatible
> to OUI mapping.  What I did was use the mac-address property to store
> the OUI.  I think that makes a lot more sense.  Actually, storing the
> whole MAC in the ocotp would have made a lot more sense!  But it's one
> time programmable and that's the way all the boards were made.
>

>From looking at the mach-mxs.c and assuming I didn't miss any
important details (which is a big if), it seems to me that it would
still be possible to cover this use-case by introducing(or extending
'nvmem' driver) an additional "nvmem" compatible entity whose only job
would be is to present data hard coded in its corresponding DT-node
via "nvmem" API.

So, say for example for apf28(OUI_ARMADEUS) you'd have something like:

board-oui-node {
  board_oui_cell: oui_cell@0 {
 immediate-data = [0x00  0x1e 0xac];
  };
};

and then you should be able to use <_oui_cell> in the
scatter-gatherer node from above.

Andrey

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH] Add regmap support

2016-02-03 Thread Sascha Hauer 
This series adds simple regmap support. It's overdue to have regmap
support in barebox since regmap can make register accesses far more
generic and convenient. More and more kernel code depends on it, so
here it is for barebox. Two drivers are switched over to regmap to
provide some users.


Sascha Hauer (3):
  Add initial regmap support
  mfd: mc13xxx: Switch to regmap support
  ARM: i.MX ocotp: Switch to regmap support

Steffen Trumtrar (1):
  bitops: Fix shift overflow in GENMASK macros

 arch/arm/mach-imx/ocotp.c  | 146 ++-
 drivers/base/Makefile  |   1 +
 drivers/base/regmap/Makefile   |   1 +
 drivers/base/regmap/internal.h |  18 ++
 drivers/base/regmap/regmap.c   | 398 +
 drivers/mfd/mc13xxx.c  | 123 ++---
 include/linux/bitops.h |   7 +-
 include/regmap.h   |  62 +++
 8 files changed, 594 insertions(+), 162 deletions(-)
 create mode 100644 drivers/base/regmap/Makefile
 create mode 100644 drivers/base/regmap/internal.h
 create mode 100644 drivers/base/regmap/regmap.c
 create mode 100644 include/regmap.h

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 4/4] ARM: i.MX ocotp: Switch to regmap support

2016-02-03 Thread Sascha Hauer 
Signed-off-by: Sascha Hauer 
---
 arch/arm/mach-imx/ocotp.c | 146 ++
 1 file changed, 57 insertions(+), 89 deletions(-)

diff --git a/arch/arm/mach-imx/ocotp.c b/arch/arm/mach-imx/ocotp.c
index c99a003..c6c341d 100644
--- a/arch/arm/mach-imx/ocotp.c
+++ b/arch/arm/mach-imx/ocotp.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /*
@@ -71,7 +72,7 @@
 #define MAC_BYTES  8
 
 struct ocotp_priv {
-   struct cdev cdev;
+   struct regmap *map;
void __iomem *base;
struct clk *clk;
struct device_d dev;
@@ -159,53 +160,42 @@ int imx6_ocotp_read_one_u32(u32 index, u32 *pdata, struct 
ocotp_priv *priv)
 
ret = imx6_ocotp_prepare(priv);
if (ret) {
-   dev_err(priv->cdev.dev, "failed to prepare read fuse 0x%08x\n",
+   dev_err(>dev, "failed to prepare read fuse 0x%08x\n",
index);
return ret;
}
 
ret = fuse_read_addr(index, pdata, priv);
if (ret) {
-   dev_err(priv->cdev.dev, "failed to read fuse 0x%08x\n", index);
+   dev_err(>dev, "failed to read fuse 0x%08x\n", index);
return ret;
}
 
if (readl(priv->base) & OCOTP_CTRL_ERROR) {
-   dev_err(priv->cdev.dev, "bad read status at fuse 0x%08x\n", 
index);
+   dev_err(>dev, "bad read status at fuse 0x%08x\n", index);
return -EFAULT;
}
 
return 0;
 }
 
-static ssize_t imx6_ocotp_cdev_read(struct cdev *cdev, void *buf,
-   size_t count, loff_t offset, unsigned long flags)
+static int imx_ocotp_reg_read(void *ctx, unsigned int reg, unsigned int *val)
 {
+   struct ocotp_priv *priv = ctx;
u32 index;
-   ssize_t read_count = 0;
-   int ret, i;
-   struct ocotp_priv *priv = container_of(cdev, struct ocotp_priv, cdev);
-
-   index = offset >> 2;
-   count >>= 2;
-
-   if (count > (FUSE_REGS_COUNT - index))
-   count = FUSE_REGS_COUNT - index - 1;
-
-   for (i = index; i < (index + count); i++) {
-   if (priv->sense_enable) {
-   ret = imx6_ocotp_read_one_u32(i, buf, priv);
-   if (ret)
-   return ret;
-   } else {
-   *(u32 *)buf = readl(priv->base + 0x400 + i * 0x10);
-   }
+   int ret;
 
-   buf += 4;
-   read_count++;
+   index = reg >> 2;
+
+   if (priv->sense_enable) {
+   ret = imx6_ocotp_read_one_u32(index, val, priv);
+   if (ret)
+   return ret;
+   } else {
+   *(u32 *)val = readl(priv->base + 0x400 + index * 0x10);
}
 
-   return read_count << 2;
+   return 0;
 }
 
 static int fuse_blow_addr(u32 addr, u32 value, struct ocotp_priv *priv)
@@ -232,7 +222,7 @@ static int fuse_blow_addr(u32 addr, u32 value, struct 
ocotp_priv *priv)
 
 static int imx6_ocotp_reload_shadow(struct ocotp_priv *priv)
 {
-   dev_info(priv->cdev.dev, "reloading shadow registers...\n");
+   dev_info(>dev, "reloading shadow registers...\n");
writel(OCOTP_CTRL_RELOAD_SHADOWS, priv->base + OCOTP_CTRL_SET);
udelay(1);
 
@@ -246,18 +236,18 @@ int imx6_ocotp_blow_one_u32(u32 index, u32 data, u32 
*pfused_value,
 
ret = imx6_ocotp_prepare(priv);
if (ret) {
-   dev_err(priv->cdev.dev, "prepare to write failed\n");
+   dev_err(>dev, "prepare to write failed\n");
return ret;
}
 
ret = fuse_blow_addr(index, data, priv);
if (ret) {
-   dev_err(priv->cdev.dev, "fuse blow failed\n");
+   dev_err(>dev, "fuse blow failed\n");
return ret;
}
 
if (readl(priv->base) & OCOTP_CTRL_ERROR) {
-   dev_err(priv->cdev.dev, "bad write status\n");
+   dev_err(>dev, "bad write status\n");
return -EFAULT;
}
 
@@ -266,60 +256,29 @@ int imx6_ocotp_blow_one_u32(u32 index, u32 data, u32 
*pfused_value,
return ret;
 }
 
-static ssize_t imx6_ocotp_cdev_write(struct cdev *cdev, const void *buf,
-   size_t count, loff_t offset, unsigned long flags)
+static int imx_ocotp_reg_write(void *ctx, unsigned int reg, unsigned int val)
 {
-   struct ocotp_priv *priv = cdev->priv;
-   int index, i;
-   ssize_t write_count = 0;
-   const u32 *data;
+   struct ocotp_priv *priv = ctx;
+   int index;
u32 pfuse;
int ret;
 
-   /* We could do better, but currently this is what's implemented */
-   if (offset & 0x3 || count & 0x3) {
-   dev_err(cdev->dev, "only u32 aligned writes allowed\n");
-   return -EINVAL;
-   }
-
-   index = offset >> 2;
-   count >>= 2;
-
-   if (count >

[PATCH 1/4] bitops: Fix shift overflow in GENMASK macros

2016-02-03 Thread Sascha Hauer 
From: Steffen Trumtrar 

Based on the original patch for linux:

commit 00b4d9a14125f1e51874def2b9de6092e007412d
Author: Maxime COQUELIN 
Date:   Thu Nov 6 10:54:19 2014

On some 32 bits architectures, including x86, GENMASK(31, 0) returns 0
instead of the expected ~0UL.

This is the same on some 64 bits architectures with GENMASK_ULL(63, 0).

This is due to an overflow in the shift operand, 1 << 32 for GENMASK,
1 << 64 for GENMASK_ULL.

Signed-off-by: Steffen Trumtrar 
---
 include/linux/bitops.h | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index f3a740c..31345c2 100644
--- a/include/linux/bitops.h
+++ b/include/linux/bitops.h
@@ -18,8 +18,11 @@
  * position @h. For example
  * GENMASK_ULL(39, 21) gives us the 64bit vector 0x00e0.
  */
-#define GENMASK(h, l)  (((U32_C(1) << ((h) - (l) + 1)) - 1) << (l))
-#define GENMASK_ULL(h, l)  (((U64_C(1) << ((h) - (l) + 1)) - 1) << (l))
+#define GENMASK(h, l) \
+   (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
+
+#define GENMASK_ULL(h, l) \
+   (((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h
 
 extern unsigned int __sw_hweight8(unsigned int w);
 extern unsigned int __sw_hweight16(unsigned int w);
-- 
2.7.0.rc3


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 2/2] nvmem: Test it with fec/ocotp

2016-02-03 Thread Sascha Hauer 
This adds a test for the nvmem framework. The ocotp is registered as a
nvmem device which shall provide the MAC address for the i.MX FEC
driver.

While this generally works it reveals a shortcoming of the nvmem
framework: There's no way to specify the layout of the cell. For example
the MAC address stored in the OCOTP has another byte order than
the one stored in the IIM module on older i.MX SoCs. The FEC driver
shouldn't know about these differences, so it shouldn't be implemented
there. The OCOTP and IIM drivers are generic drivers used on different
SoCs aswell, so the differences shouldn't be encoded there either.
This leaves the device tree to put the differences in, but this simple
example already shows how complex such a binding probably becomes when
all kinds of different possibilities of byte orders shall be encoded.
What's missing is some kind of mapping driver that could be plugged
between a nvmem provider and its consumer where all these differences
can be handled.

Signed-off-by: Sascha Hauer 
---
 arch/arm/dts/imx6qdl-phytec-pfla02.dtsi |  9 +
 arch/arm/mach-imx/ocotp.c   |  8 
 drivers/net/fec_imx.c   | 30 ++
 3 files changed, 47 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi 
b/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
index b79ce2c..c5f25f9 100644
--- a/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/dts/imx6qdl-phytec-pfla02.dtsi
@@ -85,6 +85,8 @@
 
  {
phy-handle = <>;
+   nvmem-cells = <_mac_address>;
+   nvmem-cell-names = "mac-address";
 
mdio {
#address-cells = <1>;
@@ -171,7 +173,14 @@
 };
 
  {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
barebox,provide-mac-address = < 0x620>;
+
+   fec_mac_address: mac_address@88 {
+   reg = <0x88 0x8>;
+   };
 };
 
  {
diff --git a/arch/arm/mach-imx/ocotp.c b/arch/arm/mach-imx/ocotp.c
index c6c341d..c8ba932 100644
--- a/arch/arm/mach-imx/ocotp.c
+++ b/arch/arm/mach-imx/ocotp.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * a single MAC address reference has the form
@@ -79,6 +80,7 @@ struct ocotp_priv {
int permanent_write_enable;
int sense_enable;
char ethaddr[6];
+   struct nvmem_config nvmem_config;
 };
 
 static int imx6_ocotp_set_timing(struct ocotp_priv *priv)
@@ -404,6 +406,12 @@ static int imx_ocotp_probe(struct device_d *dev)
 if (ret)
 return ret;
 
+   priv->nvmem_config.name = "imx-ocotp",
+   priv->nvmem_config.read_only = true,
+   priv->nvmem_config.dev = dev;
+
+   nvmem_register(>nvmem_config, priv->map);
+
if (IS_ENABLED(CONFIG_IMX_OCOTP_WRITE)) {
dev_add_param_bool(&(priv->dev), "permanent_write_enable",
NULL, NULL, >permanent_write_enable, 
NULL);
diff --git a/drivers/net/fec_imx.c b/drivers/net/fec_imx.c
index 5418034..0448b51 100644
--- a/drivers/net/fec_imx.c
+++ b/drivers/net/fec_imx.c
@@ -621,6 +621,34 @@ static int fec_alloc_receive_packets(struct fec_priv *fec, 
int count, int size)
return 0;
 }
 
+#include 
+
+static void nvmem_test(struct device_d *dev)
+{
+   struct nvmem_cell *cell;
+   uint8_t *buf;
+   int len, i;
+
+   cell = nvmem_cell_get(dev, "mac-address");
+   if (IS_ERR(cell)) {
+   dev_err(dev, "Failed to get cell: %s\n", strerrorp(cell));
+   }
+
+   buf = nvmem_cell_read(cell, );
+   if (IS_ERR(buf)) {
+   dev_err(dev, "Failed to read cell: %s\n", strerrorp(buf));
+   }
+
+   printf("buf: 0x%p len %d\n", buf, len);
+
+   for (i = 0; i < len; i++)
+   printf("%02x ", buf[i]);
+
+   printf("\n");
+
+   free(buf);
+}
+
 #ifdef CONFIG_OFDEVICE
 static int fec_probe_dt(struct device_d *dev, struct fec_priv *fec)
 {
@@ -637,6 +665,8 @@ static int fec_probe_dt(struct device_d *dev, struct 
fec_priv *fec)
if (mdiobus)
fec->miibus.dev.device_node = mdiobus;
 
+   nvmem_test(dev);
+
return 0;
 }
 #else
-- 
2.7.0.rc3


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH] Add nvmem support

2016-02-03 Thread Sascha Hauer 
This ports over the nvmem framework from the kernel. I probably won't
apply it as is since it doesn't make me very happy. While it generally
works the very first test already reveals that it can't properly handle
the different layouts of nvmem cells. The MAC addresses for the i.MX
FEC are stored in different byte orders in the IIM/OCOTP units. There's
simply no proper place to encode these different byte orders, see patch
[2/2].

Sascha


Sascha Hauer (1):
  nvmem: Test it with fec/ocotp

Steffen Trumtrar (1):
  drivers: add nvmem framework from kernel

 arch/arm/dts/imx6qdl-phytec-pfla02.dtsi |   9 +
 arch/arm/mach-imx/ocotp.c   |   8 +
 drivers/Kconfig |   1 +
 drivers/Makefile|   1 +
 drivers/net/fec_imx.c   |  30 ++
 drivers/nvmem/Kconfig   |   8 +
 drivers/nvmem/Makefile  |   6 +
 drivers/nvmem/core.c| 749 
 include/linux/nvmem-consumer.h  | 157 +++
 include/linux/nvmem-provider.h  |  49 +++
 10 files changed, 1018 insertions(+)
 create mode 100644 drivers/nvmem/Kconfig
 create mode 100644 drivers/nvmem/Makefile
 create mode 100644 drivers/nvmem/core.c
 create mode 100644 include/linux/nvmem-consumer.h
 create mode 100644 include/linux/nvmem-provider.h

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 2/2] nvmem: Test it with fec/ocotp

2016-02-03 Thread Sascha Hauer 
On Wed, Feb 03, 2016 at 07:01:03PM +, Trent Piepho wrote:
> On Wed, 2016-02-03 at 17:27 +0100, Sascha Hauer wrote:
> > While this generally works it reveals a shortcoming of the nvmem
> > framework: There's no way to specify the layout of the cell. For example
> > the MAC address stored in the OCOTP has another byte order than
> > the one stored in the IIM module on older i.MX SoCs. The FEC driver
> > shouldn't know about these differences, so it shouldn't be implemented
> > there. The OCOTP and IIM drivers are generic drivers used on different
> > SoCs aswell, so the differences shouldn't be encoded there either.
> > This leaves the device tree to put the differences in, but this simple
> > example already shows how complex such a binding probably becomes when
> > all kinds of different possibilities of byte orders shall be encoded.
> > What's missing is some kind of mapping driver that could be plugged
> > between a nvmem provider and its consumer where all these differences
> > can be handled.
> 
> >  
> >   {
> > phy-handle = <>;
> > +   nvmem-cells = <_mac_address>;
> > +   nvmem-cell-names = "mac-address";
> >  
> > mdio {
> > #address-cells = <1>;
> > @@ -171,7 +173,14 @@
> >  };
> >  
> >   {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > barebox,provide-mac-address = < 0x620>;
> > +
> > +   fec_mac_address: mac_address@88 {
> > +   reg = <0x88 0x8>;
> > +   };
> >  };
> 
> Why is there both a nvmem-cells = <_mac_address> property in the fec
> and also a barebox,provide-mac-address = < 0x620> property in the
> ocotp?  It seems like only one should need to point to the other.

Yes, finally only one is needed. The patch is for testing purposes only
at the moment.

> 
> 
> Here's an idea for an nvmem property for coping byteorder, etc.
> 
> 
> fec_mac_address: mac_address@88 {
> reg = <0x88 0x8>;
> map = [1 2 3 4 5 6 0 0];  // Leftmost octet first order
> map = [6 5 4 3 2 1 0 0];  // Rightmost octet first order
> 
> // Leftmost first, but with opposite byte order within each word
> map = [4 3 2 1 0 0 6 5];
> 
> // Only extension is stored
> reg = <0x88 4>; // Just four bytes are used
> map = [4 5 6 0];
> };
> 
> The idea is the map property lists the destination location of each byte
> in the reg range.  The first item in map is the location of the first
> byte in the range, a value of one (not zero) indicates it should be the
> first byte in the output, 2 the second byte, and so on.  0 means the
> byte isn't used.  It's pretty common to use use six bytes inside a 8
> byte field for a mac.

I guess that would work for this case. The binding as it is documented
currently allows a 'bits' property:

bits:   Is pair of bit location and number of bits, which specifies offset
in bit and number of bits within the address range specified by
reg property. Offset takes values from 0-7.

Both 'map' and 'bits' combined already make a quite confusing binding.

Still it's easy to think of situations where this is still not enough.
Think of checksums or things like "The MAC is valid when this bit is
set" or the case you mention above when only the lower bytes of the MAC
address are stored in the nvmem. I think in all these situations a
purely descriptive binding is not enough.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH] docs: fix typos

2016-02-03 Thread Ulrich Ölmann 
Signed-off-by: Ulrich Ölmann 
---
 Documentation/devicetree/bindings/barebox/barebox,state.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/barebox/barebox,state.rst 
b/Documentation/devicetree/bindings/barebox/barebox,state.rst
index d1b0627..5643edc 100644
--- a/Documentation/devicetree/bindings/barebox/barebox,state.rst
+++ b/Documentation/devicetree/bindings/barebox/barebox,state.rst
@@ -43,7 +43,7 @@ Variable nodes
 
 These are subnodes of a state node each describing a single
 variable. The node name may end with ``@``, but the suffix is
-sripped from the variable name.
+ripped from the variable name.
 
 State variables have a type. Currenty supported types are: ``uint8``,
 ``uint32``, ``enum32``, ``mac`` address or ``string``. Variable length
-- 
2.7.0.rc3


___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH 4/4] ARM: i.MX ocotp: Switch to regmap support

2016-02-03 Thread Sascha Hauer 
Hi Stefan,

On Thu, Feb 04, 2016 at 08:38:30AM +0100, Stefan Christ wrote:
> Hi Sascha,
> 
> > +   priv->map = regmap_init(dev, _ocotp_regmap_bus, priv, 
> > _ocotp_regmap_config);
> > +   if (IS_ERR(priv->map))
> > +   return PTR_ERR(priv->map);
> > +
> > +   ret = regmap_register_cdev(priv->map, "imx-ocotp");
> > +if (ret)
> > +return ret;
> > +
> 
> Here are whitespaces instead of tabs.

Fixed, thanks for noting

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v2 7/8] mdio_bus: Change PHY's naming scheme

2016-02-03 Thread Sascha Hauer 
Hi Andrey,

On Wed, Feb 03, 2016 at 11:23:38AM -0800, Andrey Smirnov wrote:
> On Tue, Feb 2, 2016 at 11:36 PM, Sascha Hauer  wrote:
> > On Sun, Jan 31, 2016 at 07:10:12PM -0800, Andrey Smirnov wrote:
> >> Change the way PHY devices are named upon creation. This commit replaces
> >> sequentialy numbered "/dev/phy%d" with "/dev/mdio%d-phy%02x". This way
> >> it is significanlty easier to identify which PHY in real-life (e.g. on a
> >> schematic) corresponds to which device in /dev.
> >>
> >> Also, replace asprintf with xasprintf to provide some form of memory
> >> allocation failure checking.
> >>
> >> Signed-off-by: Andrey Smirnov 
> >> ---
> >>  drivers/net/phy/mdio_bus.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> >> index b74b27e..41bf018 100644
> >> --- a/drivers/net/phy/mdio_bus.c
> >> +++ b/drivers/net/phy/mdio_bus.c
> >> @@ -333,7 +333,9 @@ static int mdio_bus_probe(struct device_d *_dev)
> >>   dev_add_param_int_ro(>dev, "phy_addr", dev->addr, "%d");
> >>   dev_add_param_int_ro(>dev, "phy_id", dev->phy_id, "0x%08x");
> >>
> >> - dev->cdev.name = asprintf("phy%d", _dev->id);
> >> + dev->cdev.name = xasprintf("mdio%d-phy%02x",
> >> +dev->bus->dev.id,
> >> +dev->addr);
> >
> > While at it we can change the phy device name in the same way to be
> > consistent:
> 
> Yeah, I agree, let's do this. Let me know if I should do v3 patch set.

I'll squash that here as necessary.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] docs: fix typos

2016-02-03 Thread Sascha Hauer 
On Thu, Feb 04, 2016 at 08:25:24AM +0100, Ulrich Ölmann wrote:
> Signed-off-by: Ulrich Ölmann 
> ---
>  Documentation/devicetree/bindings/barebox/barebox,state.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/barebox/barebox,state.rst 
> b/Documentation/devicetree/bindings/barebox/barebox,state.rst
> index d1b0627..5643edc 100644
> --- a/Documentation/devicetree/bindings/barebox/barebox,state.rst
> +++ b/Documentation/devicetree/bindings/barebox/barebox,state.rst

Applied, thanks

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ARM: i.MX25: fixup broken DryIce GPR

2016-02-03 Thread Sascha Hauer 
On Wed, Feb 03, 2016 at 11:49:03AM +0100, Steffen Trumtrar wrote:
> Fixup the DryIce Non-Non-Volatile-Memory GPR register.
> 
> Signed-off-by: Steffen Trumtrar 
> ---
>  arch/arm/mach-imx/imx25.c | 26 ++
>  1 file changed, 26 insertions(+)

Applied, thanks

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH 3/4] mfd: mc13xxx: Switch to regmap support

2016-02-03 Thread Sascha Hauer 
This moves the mc13xxx driver over to regmap.

Signed-off-by: Sascha Hauer 
---
 drivers/mfd/mc13xxx.c | 123 +-
 1 file changed, 52 insertions(+), 71 deletions(-)

diff --git a/drivers/mfd/mc13xxx.c b/drivers/mfd/mc13xxx.c
index 0ebfc9e..496fcbb 100644
--- a/drivers/mfd/mc13xxx.c
+++ b/drivers/mfd/mc13xxx.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -29,15 +30,16 @@
 
 #define DRIVERNAME "mc13xxx"
 
+#define MC13XXX_NUMREGS0x3f
+
 struct mc13xxx {
-   struct cdev cdev;
+   struct device_d *dev;
+   struct regmap   *map;
union {
struct i2c_client   *client;
struct spi_device   *spi;
};
int revision;
-   int (*reg_read)(struct mc13xxx*, u8, u32*);
-   int (*reg_write)(struct mc13xxx*, u8, u32);
 };
 
 struct mc13xxx_devtype {
@@ -100,8 +102,9 @@ static int spi_rw(struct spi_device *spi, void * buf, 
size_t len)
 #define MXC_PMIC_REG_NUM(reg)  (((reg) & 0x3f) << 25)
 #define MXC_PMIC_WRITE (1 << 31)
 
-static int mc13xxx_spi_reg_read(struct mc13xxx *mc13xxx, u8 reg, u32 *val)
+static int mc13xxx_spi_reg_read(void *ctx, unsigned int reg, unsigned int *val)
 {
+   struct mc13xxx *mc13xxx = ctx;
uint32_t buf;
 
buf = MXC_PMIC_REG_NUM(reg);
@@ -113,8 +116,9 @@ static int mc13xxx_spi_reg_read(struct mc13xxx *mc13xxx, u8 
reg, u32 *val)
return 0;
 }
 
-static int mc13xxx_spi_reg_write(struct mc13xxx *mc13xxx, u8 reg, u32 val)
+static int mc13xxx_spi_reg_write(void *ctx, unsigned int reg, unsigned int val)
 {
+   struct mc13xxx *mc13xxx = ctx;
uint32_t buf = MXC_PMIC_REG_NUM(reg) | MXC_PMIC_WRITE | (val & 
0xff);
 
spi_rw(mc13xxx->spi, , 4);
@@ -124,8 +128,9 @@ static int mc13xxx_spi_reg_write(struct mc13xxx *mc13xxx, 
u8 reg, u32 val)
 #endif
 
 #ifdef CONFIG_I2C
-static int mc13xxx_i2c_reg_read(struct mc13xxx *mc13xxx, u8 reg, u32 *val)
+static int mc13xxx_i2c_reg_read(void *ctx, unsigned int reg, unsigned int *val)
 {
+   struct mc13xxx *mc13xxx = ctx;
u8 buf[3];
int ret;
 
@@ -135,8 +140,9 @@ static int mc13xxx_i2c_reg_read(struct mc13xxx *mc13xxx, u8 
reg, u32 *val)
return ret == 3 ? 0 : ret;
 }
 
-static int mc13xxx_i2c_reg_write(struct mc13xxx *mc13xxx, u8 reg, u32 val)
+static int mc13xxx_i2c_reg_write(void *ctx, unsigned int reg, unsigned int val)
 {
+   struct mc13xxx *mc13xxx = ctx;
u8 buf[] = {
val >> 16,
val >>  8,
@@ -152,13 +158,13 @@ static int mc13xxx_i2c_reg_write(struct mc13xxx *mc13xxx, 
u8 reg, u32 val)
 
 int mc13xxx_reg_write(struct mc13xxx *mc13xxx, u8 reg, u32 val)
 {
-   return mc13xxx->reg_write(mc13xxx, reg, val);
+   return regmap_write(mc13xxx->map, reg, val);
 }
 EXPORT_SYMBOL(mc13xxx_reg_write);
 
 int mc13xxx_reg_read(struct mc13xxx *mc13xxx, u8 reg, u32 *val)
 {
-   return mc13xxx->reg_read(mc13xxx, reg, val);
+   return regmap_read(mc13xxx->map, reg, val);
 }
 EXPORT_SYMBOL(mc13xxx_reg_read);
 
@@ -177,54 +183,6 @@ int mc13xxx_set_bits(struct mc13xxx *mc13xxx, u8 reg, u32 
mask, u32 val)
 }
 EXPORT_SYMBOL(mc13xxx_set_bits);
 
-static ssize_t mc_read(struct cdev *cdev, void *_buf, size_t count, loff_t 
offset, ulong flags)
-{
-   struct mc13xxx *mc13xxx = to_mc13xxx(cdev);
-   u32 *buf = _buf;
-   size_t i = count >> 2;
-   int err;
-
-   offset >>= 2;
-
-   while (i) {
-   err = mc13xxx_reg_read(mc13xxx, offset, buf);
-   if (err)
-   return (ssize_t)err;
-   buf++;
-   i--;
-   offset++;
-   }
-
-   return count;
-}
-
-static ssize_t mc_write(struct cdev *cdev, const void *_buf, size_t count, 
loff_t offset, ulong flags)
-{
-   struct mc13xxx *mc13xxx = to_mc13xxx(cdev);
-   const u32 *buf = _buf;
-   size_t i = count >> 2;
-   int err;
-
-   offset >>= 2;
-
-   while (i) {
-   err = mc13xxx_reg_write(mc13xxx, offset, *buf);
-   if (err)
-   return (ssize_t)err;
-   buf++;
-   i--;
-   offset++;
-   }
-
-   return count;
-}
-
-static struct file_operations mc_fops = {
-   .lseek  = dev_lseek_default,
-   .read   = mc_read,
-   .write  = mc_write,
-};
-
 static int __init mc13783_revision(struct mc13xxx *mc13xxx)
 {
unsigned int rev_id;
@@ -245,7 +203,7 @@ static int __init mc13783_revision(struct mc13xxx *mc13xxx)
} else
sprintf(revstr, "%d.%d", rev / 0x10, rev % 10);
 
-   dev_info(mc_dev->cdev.dev, "Found MC13783 ID: 0x%06x [Rev: %s]\n",
+   dev_info(mc_dev->dev, "Found MC13783 ID: 0x%06x [Rev: %s]\n",

[PATCH 2/4] Add initial regmap support

2016-02-03 Thread Sascha Hauer 
This adds initial regmap support. Function prototypes are from
the Kernel, the implemention is mostly rewritten. Currently the
regmap support is limited to the bare minimum to get started.

Signed-off-by: Sascha Hauer 
---
 drivers/base/Makefile  |   1 +
 drivers/base/regmap/Makefile   |   1 +
 drivers/base/regmap/internal.h |  18 ++
 drivers/base/regmap/regmap.c   | 398 +
 include/regmap.h   |  62 +++
 5 files changed, 480 insertions(+)
 create mode 100644 drivers/base/regmap/Makefile
 create mode 100644 drivers/base/regmap/internal.h
 create mode 100644 drivers/base/regmap/regmap.c
 create mode 100644 include/regmap.h

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index e1f1c7a..4bd4217 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -2,3 +2,4 @@ obj-y   += bus.o
 obj-y  += driver.o
 obj-y  += platform.o
 obj-y  += resource.o
+obj-y  += regmap/
\ No newline at end of file
diff --git a/drivers/base/regmap/Makefile b/drivers/base/regmap/Makefile
new file mode 100644
index 000..4dc3d8c
--- /dev/null
+++ b/drivers/base/regmap/Makefile
@@ -0,0 +1 @@
+obj-y  += regmap.o
\ No newline at end of file
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
new file mode 100644
index 000..52df529
--- /dev/null
+++ b/drivers/base/regmap/internal.h
@@ -0,0 +1,18 @@
+
+#include 
+
+struct regmap {
+   struct device_d *dev;
+   const struct regmap_bus *bus;
+   const char *name;
+   void *bus_context;
+   struct list_head list;
+   int reg_bits;
+   int reg_stride;
+   int pad_bits;
+   int val_bits;
+   int val_bytes;
+   unsigned int max_register;
+
+   struct cdev cdev;
+};
\ No newline at end of file
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
new file mode 100644
index 000..b626f9a
--- /dev/null
+++ b/drivers/base/regmap/regmap.c
@@ -0,0 +1,398 @@
+/*
+ * Register map access API
+ *
+ * Copyright 2016 Sascha Hauer 
+ *
+ * based on Kernel code:
+ *
+ * Copyright 2011 Wolfson Microelectronics plc
+ *
+ * Author: Mark Brown 
+ *
+ * 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; version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "internal.h"
+
+static LIST_HEAD(regmaps);
+
+/*
+ * regmap_init - initialize and register a regmap
+ *
+ * @dev: The device the new regmap belongs to
+ * @bus: The regmap_bus providing read/write access to the map
+ * @bus_context: Context pointer for the bus ops
+ * @config:  Configuration options for this map
+ *
+ * Returns a pointer to the new map or a ERR_PTR value on failure
+ */
+struct regmap *regmap_init(struct device_d *dev,
+const struct regmap_bus *bus,
+void *bus_context,
+const struct regmap_config *config)
+{
+   struct regmap *map;
+
+   map = xzalloc(sizeof(*map));
+   map->dev = dev;
+   map->bus = bus;
+   map->name = config->name;
+   map->bus_context = bus_context;
+   map->reg_bits = config->reg_bits;
+   map->reg_stride = config->reg_stride;
+   if (!map->reg_stride)
+   map->reg_stride = 1;
+   map->pad_bits = config->pad_bits;
+   map->val_bits = config->val_bits;
+   map->val_bytes = DIV_ROUND_UP(config->val_bits, 8);
+   map->max_register = config->max_register;
+
+   list_add_tail(>list, );
+
+   return map;
+}
+
+/*
+ * regmap_init - initialize and register a regmap
+ *
+ * @dev: The device the maps is attached to
+ * @name:Optional name for the map. If given it must match.
+ *
+ * Returns a pointer to the regmap or a ERR_PTR value on failure
+ */
+struct regmap *dev_get_regmap(struct device_d *dev, const char *name)
+{
+   struct regmap *map;
+
+   list_for_each_entry(map, , list) {
+   if (map->dev != dev)
+   continue;
+   if (!name)
+   return map;
+   if (!strcmp(map->name, name))
+   return map;
+   }
+
+   return ERR_PTR(-ENOENT);
+}
+
+/*
+ * of_node_to_regmap - get a regmap from a device node
+ *
+ * node: The device node
+ *
+ * Returns a pointer to the regmap or a ERR_PTR if the node has no
+ * regmap attached.
+ */
+struct regmap *of_node_to_regmap(struct device_node *node)
+{
+   struct regmap *map;
+
+   list_for_each_entry(map, , list) {
+

[PATCH 1/2] drivers: add nvmem framework from kernel

2016-02-03 Thread Sascha Hauer 
From: Steffen Trumtrar 

Add the nvmem framework from Linux.

Based on the v4.4-rc3 version.

Signed-off-by: Steffen Trumtrar 
---
 drivers/Kconfig|   1 +
 drivers/Makefile   |   1 +
 drivers/nvmem/Kconfig  |   8 +
 drivers/nvmem/Makefile |   6 +
 drivers/nvmem/core.c   | 749 +
 include/linux/nvmem-consumer.h | 157 +
 include/linux/nvmem-provider.h |  49 +++
 7 files changed, 971 insertions(+)
 create mode 100644 drivers/nvmem/Kconfig
 create mode 100644 drivers/nvmem/Makefile
 create mode 100644 drivers/nvmem/core.c
 create mode 100644 include/linux/nvmem-consumer.h
 create mode 100644 include/linux/nvmem-provider.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 5984ccc..3b2ea4d 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -31,5 +31,6 @@ source "drivers/pci/Kconfig"
 source "drivers/rtc/Kconfig"
 source "drivers/firmware/Kconfig"
 source "drivers/phy/Kconfig"
+source "drivers/nvmem/Kconfig"
 
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 3afbb61..3d7f328 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -31,3 +31,4 @@ obj-y += rtc/
 obj-$(CONFIG_FIRMWARE) += firmware/
 obj-$(CONFIG_GENERIC_PHY) += phy/
 obj-$(CONFIG_HABV4) += habv4/
+obj-$(CONFIG_NVMEM) += nvmem/
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
new file mode 100644
index 000..218be05
--- /dev/null
+++ b/drivers/nvmem/Kconfig
@@ -0,0 +1,8 @@
+menuconfig NVMEM
+   bool "NVMEM Support"
+   help
+ Support for NVMEM(Non Volatile Memory) devices like EEPROM, EFUSES...
+
+ This framework is designed to provide a generic interface to NVMEM
+
+ If unsure, say no.
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
new file mode 100644
index 000..6df2c69
--- /dev/null
+++ b/drivers/nvmem/Makefile
@@ -0,0 +1,6 @@
+#
+# Makefile for nvmem drivers.
+#
+
+obj-$(CONFIG_NVMEM)+= nvmem_core.o
+nvmem_core-y   := core.o
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
new file mode 100644
index 000..0214253
--- /dev/null
+++ b/drivers/nvmem/core.c
@@ -0,0 +1,749 @@
+/*
+ * nvmem framework core.
+ *
+ * Copyright (C) 2015 Srinivas Kandagatla 
+ * Copyright (C) 2013 Maxime Ripard 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#define DEBUG
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct nvmem_device {
+   const char  *name;
+   struct device_d dev;
+   struct nvmem_bus*bus;
+   struct list_headnode;
+   int stride;
+   int word_size;
+   int ncells;
+   int users;
+   size_t  size;
+   boolread_only;
+   struct regmap   *regmap;
+};
+
+struct nvmem_cell {
+   const char  *name;
+   int offset;
+   int bytes;
+   int bit_offset;
+   int nbits;
+   struct nvmem_device *nvmem;
+   struct list_headnode;
+};
+
+static LIST_HEAD(nvmem_cells);
+static LIST_HEAD(nvmem_devs);
+
+static struct nvmem_device *of_nvmem_find(struct device_node *nvmem_np)
+{
+   struct nvmem_device *dev;
+
+   if (!nvmem_np)
+   return NULL;
+
+   list_for_each_entry(dev, _devs, node)
+   if (dev->dev.device_node->name && 
!strcmp(dev->dev.device_node->name, nvmem_np->name))
+   return dev;
+
+   return NULL;
+}
+
+static struct nvmem_cell *nvmem_find_cell(const char *cell_id)
+{
+   struct nvmem_cell *p;
+
+   list_for_each_entry(p, _cells, node)
+   if (p && !strcmp(p->name, cell_id))
+   return p;
+
+   return NULL;
+}
+
+static void nvmem_cell_drop(struct nvmem_cell *cell)
+{
+   list_del(>node);
+   kfree(cell);
+}
+
+static void nvmem_device_remove_all_cells(const struct nvmem_device *nvmem)
+{
+   struct nvmem_cell *cell;
+   struct list_head *p, *n;
+
+   list_for_each_safe(p, n, _cells) {
+   cell = list_entry(p, struct nvmem_cell, node);
+   if (cell->nvmem == nvmem)
+   nvmem_cell_drop(cell);
+   }
+}
+
+static void nvmem_cell_add(struct nvmem_cell *cell)
+{
+

Re: [PATCH v2 7/8] mdio_bus: Change PHY's naming scheme

2016-02-03 Thread Andrey Smirnov 
On Tue, Feb 2, 2016 at 11:36 PM, Sascha Hauer  wrote:
> On Sun, Jan 31, 2016 at 07:10:12PM -0800, Andrey Smirnov wrote:
>> Change the way PHY devices are named upon creation. This commit replaces
>> sequentialy numbered "/dev/phy%d" with "/dev/mdio%d-phy%02x". This way
>> it is significanlty easier to identify which PHY in real-life (e.g. on a
>> schematic) corresponds to which device in /dev.
>>
>> Also, replace asprintf with xasprintf to provide some form of memory
>> allocation failure checking.
>>
>> Signed-off-by: Andrey Smirnov 
>> ---
>>  drivers/net/phy/mdio_bus.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
>> index b74b27e..41bf018 100644
>> --- a/drivers/net/phy/mdio_bus.c
>> +++ b/drivers/net/phy/mdio_bus.c
>> @@ -333,7 +333,9 @@ static int mdio_bus_probe(struct device_d *_dev)
>>   dev_add_param_int_ro(>dev, "phy_addr", dev->addr, "%d");
>>   dev_add_param_int_ro(>dev, "phy_id", dev->phy_id, "0x%08x");
>>
>> - dev->cdev.name = asprintf("phy%d", _dev->id);
>> + dev->cdev.name = xasprintf("mdio%d-phy%02x",
>> +dev->bus->dev.id,
>> +dev->addr);
>
> While at it we can change the phy device name in the same way to be
> consistent:

Yeah, I agree, let's do this. Let me know if I should do v3 patch set.

Thanks,
Andrey

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [RFC 1/2] misc: Add MAC address mapper "driver"

2016-02-03 Thread Trent Piepho 
On Tue, 2016-02-02 at 17:14 -0800, Andrey Smirnov wrote:
> On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho  wrote:
> > The way imx28 works in the kernel is to just store the extension in the
> > OCOTP.  The OUI is determined from the board's compatible property and a
> > hard coded table in the kernel.  See arch/arm/mach-mxs/mach-mxs.c
> >
> > While, IMHO, the hard coded table is ugly, and should have died long
> > ago, there are board that don't have the entire mac burned into OCOTP.
> > It seems like neither of these bindings could support a board like this.
> >
> 
> What if you created a 'nvmem' provider whose only job is to take a
> blob from DT, a phandle to another 'nvmem' provider and to return the
> combined data from both sources. Wouldn't it work for the use-case you
> are describing?

Not sure what it would look like, example?

One thing about the imx28 OCOTP is that the entire MAC isn't in the
OCOTP.  The OUI part comes from "elsewhere".

In the current kernel, that elsewhere is a hardcoded /board/compatible
to OUI mapping.  What I did was use the mac-address property to store
the OUI.  I think that makes a lot more sense.  Actually, storing the
whole MAC in the ocotp would have made a lot more sense!  But it's one
time programmable and that's the way all the boards were made.

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v2 8/8] miitool: Add code to register a PHY

2016-02-03 Thread Andrey Smirnov 
> What I'd like to do though is the following change. It changes the way
> how the mdio bus / phy address is specified. With separate options for
> specifying the mdio bus and address it's not clear that the -a, -b and
> -r options only make sense when given together, whereas the -a and -b
> options are ignored when information is printed.
> While at it I added a check for the maximum phy address and added a
>  to BAREBOX_CMD_HELP_OPT when an option requires an argument.
>

Yeah, I agree, single "-r" option instead of what I originally had
makes much cleaner UI. Feel free to squash the fixup into my patch or
if it's easier I can make v3 of the patch set.

Thanks,
Andrey

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox