Re: [PATCH] net: ethernet: ti: davinci_cpdma: fix fixed prio cpdma ctlr configuration

[ivan.khoronzhuk]

On 10.11.16 18:37, Grygorii Strashko wrote:



On 11/09/2016 05:56 PM, Ivan Khoronzhuk wrote:



On 09.11.16 23:09, Grygorii Strashko wrote:



On 11/08/2016 07:10 AM, Ivan Khoronzhuk wrote:

The dma ctlr is reseted to 0 while cpdma start, thus cpdma ctlr


I assume this is because cpdma_ctlr_start() does soft reset. Is it
correct?

Probably not. I've seen this register doesn't hold any previous settings
(just trash)


What register CPDMA_DMACONTROL or CPSW_DMACTRL?


after cpdma_ctlr_stop(), actually after last channel is stopped (inside
of cpdma_ctlr_stop()).


So, You are stating that Registers context is changed after stop?


Then cpdma_ctlr_start() just reset it to 0.


"just trash" or "0".

Sry, I do not see how cpdma_ctlr_stop() can affect on registers state :(
and I'd very appreciated if can provide more detailed information.


I've checked again, it was my mistake. It simply reset to 0 while soft reset.






cannot be configured after cpdma is stopped. So, restore content
of cpdma ctlr while off/on procedure.

Based on net-next/master


^ remove it

sure





Signed-off-by: Ivan Khoronzhuk 
---
 drivers/net/ethernet/ti/cpsw.c  |   6 +-
 drivers/net/ethernet/ti/davinci_cpdma.c | 103
+---
 drivers/net/ethernet/ti/davinci_cpdma.h |   2 +
 3 files changed, 58 insertions(+), 53 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c
b/drivers/net/ethernet/ti/cpsw.c
index b1ddf89..4d04b8e 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1376,10 +1376,6 @@ static int cpsw_ndo_open(struct net_device *ndev)
   ALE_ALL_PORTS, ALE_ALL_PORTS, 0, 0);

 if (!cpsw_common_res_usage_state(cpsw)) {
-/* setup tx dma to fixed prio and zero offset */
-cpdma_control_set(cpsw->dma, CPDMA_TX_PRIO_FIXED, 1);
-cpdma_control_set(cpsw->dma, CPDMA_RX_BUFFER_OFFSET, 0);
-
 /* disable priority elevation */
 __raw_writel(0, >regs->ptype);

@@ -2710,6 +2706,8 @@ static int cpsw_probe(struct platform_device
*pdev)
 dma_params.desc_align= 16;
 dma_params.has_ext_regs= true;
 dma_params.desc_hw_addr = dma_params.desc_mem_phys;
+dma_params.rxbuf_offset= 0;
+dma_params.fixed_prio= 1;


Do we really need this new parameters? Do you have plans to use other
values?

I'm ok if this is static (equally as a bunch of rest in dma_params), no
see reason to use other values,


That's what i wanted to know :) - go static, pls.


it at least now. But the issue is not only in these two parameters and
not only in cpsw_ndo_open().
It touches cpsw_set_channels() also, where ctlr stop/start is present.
In order to not copy cpdma_control_set(cpsw->dma, CPDMA_TX_PRIO_FIXED,
1)...
in all such kind places in eth drivers, better to allow the cpdma to
control it's parameters...

The cpdma ctlr register holds a little more parameters (but only two of
them are set in cpsw)
Maybe there is reason to save them also. Actually I'd seen this problem
when playing with
on/off channel shapers, unfortunately the cpdma ctlr holds this info
also, and it was lost
while on/off (but I'm going to restore it in chan_start()).



I understand you change, but I'm note sure about real root cause :(

so, are you Ok with current version?

Re: [PATCH] net: ethernet: ti: davinci_cpdma: fix fixed prio cpdma ctlr configuration

[ivan.khoronzhuk]

On 10.11.16 18:37, Grygorii Strashko wrote:



On 11/09/2016 05:56 PM, Ivan Khoronzhuk wrote:



On 09.11.16 23:09, Grygorii Strashko wrote:



On 11/08/2016 07:10 AM, Ivan Khoronzhuk wrote:

The dma ctlr is reseted to 0 while cpdma start, thus cpdma ctlr


I assume this is because cpdma_ctlr_start() does soft reset. Is it
correct?

Probably not. I've seen this register doesn't hold any previous settings
(just trash)


What register CPDMA_DMACONTROL or CPSW_DMACTRL?


after cpdma_ctlr_stop(), actually after last channel is stopped (inside
of cpdma_ctlr_stop()).


So, You are stating that Registers context is changed after stop?


Then cpdma_ctlr_start() just reset it to 0.


"just trash" or "0".

Sry, I do not see how cpdma_ctlr_stop() can affect on registers state :(
and I'd very appreciated if can provide more detailed information.


I've checked again, it was my mistake. It simply reset to 0 while soft reset.






cannot be configured after cpdma is stopped. So, restore content
of cpdma ctlr while off/on procedure.

Based on net-next/master


^ remove it

sure





Signed-off-by: Ivan Khoronzhuk 
---
 drivers/net/ethernet/ti/cpsw.c  |   6 +-
 drivers/net/ethernet/ti/davinci_cpdma.c | 103
+---
 drivers/net/ethernet/ti/davinci_cpdma.h |   2 +
 3 files changed, 58 insertions(+), 53 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c
b/drivers/net/ethernet/ti/cpsw.c
index b1ddf89..4d04b8e 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1376,10 +1376,6 @@ static int cpsw_ndo_open(struct net_device *ndev)
   ALE_ALL_PORTS, ALE_ALL_PORTS, 0, 0);

 if (!cpsw_common_res_usage_state(cpsw)) {
-/* setup tx dma to fixed prio and zero offset */
-cpdma_control_set(cpsw->dma, CPDMA_TX_PRIO_FIXED, 1);
-cpdma_control_set(cpsw->dma, CPDMA_RX_BUFFER_OFFSET, 0);
-
 /* disable priority elevation */
 __raw_writel(0, >regs->ptype);

@@ -2710,6 +2706,8 @@ static int cpsw_probe(struct platform_device
*pdev)
 dma_params.desc_align= 16;
 dma_params.has_ext_regs= true;
 dma_params.desc_hw_addr = dma_params.desc_mem_phys;
+dma_params.rxbuf_offset= 0;
+dma_params.fixed_prio= 1;


Do we really need this new parameters? Do you have plans to use other
values?

I'm ok if this is static (equally as a bunch of rest in dma_params), no
see reason to use other values,


That's what i wanted to know :) - go static, pls.


it at least now. But the issue is not only in these two parameters and
not only in cpsw_ndo_open().
It touches cpsw_set_channels() also, where ctlr stop/start is present.
In order to not copy cpdma_control_set(cpsw->dma, CPDMA_TX_PRIO_FIXED,
1)...
in all such kind places in eth drivers, better to allow the cpdma to
control it's parameters...

The cpdma ctlr register holds a little more parameters (but only two of
them are set in cpsw)
Maybe there is reason to save them also. Actually I'd seen this problem
when playing with
on/off channel shapers, unfortunately the cpdma ctlr holds this info
also, and it was lost
while on/off (but I'm going to restore it in chan_start()).



I understand you change, but I'm note sure about real root cause :(

so, are you Ok with current version?

Re: [PATCH v3 5/5] net: ethernet: ti: cpsw: add ethtool channels support

[ivan.khoronzhuk]

On 17.08.16 09:22, Mugunthan V N wrote:

On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote:

These ops allow to control number of channels driver is allowed to
work with at cpdma level. The maximum number of channels is 8 for
rx and 8 for tx. In dual_emac mode the h/w channels are shared
between two interfaces and changing number on one interface changes
number of channels on another.

How many channels are supported and enabled:
$ ethtool -l ethX

Change number of channels (up to 8)
$ ethtool -L ethX rx 6 tx 6

Per-channel statistic:
$ ethtool -S ethX

Signed-off-by: Ivan Khoronzhuk 
---
 drivers/net/ethernet/ti/cpsw.c | 180 -
 1 file changed, 176 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 6dcbd8a..f02e577 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -735,6 +735,11 @@ static void cpsw_rx_handler(void *token, int len, int 
status)
}

 requeue:
+   if (netif_dormant(ndev)) {
+   dev_kfree_skb_any(new_skb);
+   return;
+   }
+
ch = cpsw->rxch[skb_get_queue_mapping(new_skb)];
ret = cpdma_chan_submit(ch, new_skb, new_skb->data,
skb_tailroom(new_skb), 0);
@@ -1267,9 +1272,8 @@ static void cpsw_init_host_port(struct cpsw_priv *priv)
}
 }

-static int cpsw_fill_rx_channels(struct net_device *ndev)
+static int cpsw_fill_rx_channels(struct cpsw_priv *priv)


This change can be moved to patch 1/5 where the function definition is
added at first.

Yes. Will do it in v4.




 {
-   struct cpsw_priv *priv = netdev_priv(ndev);
struct cpsw_common *cpsw = priv->cpsw;
struct sk_buff *skb;
int ch, i, ret;
@@ -1279,7 +1283,7 @@ static int cpsw_fill_rx_channels(struct net_device *ndev)

ch_buf_num = cpdma_chan_get_rx_buf_num(cpsw->rxch[ch]);
for (i = 0; i < ch_buf_num; i++) {
-   skb = __netdev_alloc_skb_ip_align(ndev,
+   skb = __netdev_alloc_skb_ip_align(priv->ndev,
  cpsw->rx_packet_max,
  GFP_KERNEL);
if (!skb) {
@@ -1397,7 +1401,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
enable_irq(cpsw->irqs_table[0]);
}

-   ret = cpsw_fill_rx_channels(ndev);
+   ret = cpsw_fill_rx_channels(priv);
if (ret < 0)
goto err_cleanup;

@@ -2060,6 +2064,172 @@ static void cpsw_ethtool_op_complete(struct net_device 
*ndev)
cpsw_err(priv, drv, "ethtool complete failed %d\n", ret);
 }

+static void cpsw_get_channels(struct net_device *ndev,
+ struct ethtool_channels *ch)
+{
+   struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
+
+   ch->max_combined = 0;
+   ch->max_rx = CPSW_MAX_QUEUES;
+   ch->max_tx = CPSW_MAX_QUEUES;
+   ch->max_other = 0;
+   ch->other_count = 0;
+   ch->rx_count = cpsw->rx_ch_num;
+   ch->tx_count = cpsw->tx_ch_num;
+   ch->combined_count = 0;
+}
+
+static int cpsw_check_ch_settings(struct cpsw_common *cpsw,
+ struct ethtool_channels *ch)
+{
+   if (ch->combined_count)
+   return -EINVAL;
+
+   /* verify we have at least one channel in each direction */
+   if (!ch->rx_count || !ch->tx_count)
+   return -EINVAL;
+
+   if (ch->rx_count > cpsw->data.channels ||
+   ch->tx_count > cpsw->data.channels)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int cpsw_update_channels_res(struct cpsw_priv *priv, int ch_num, int rx)
+{
+   int (*poll)(struct napi_struct *, int);
+   struct cpsw_common *cpsw = priv->cpsw;
+   void (*handler)(void *, int, int);
+   struct cpdma_chan **chan;
+   int ret, *ch;
+
+   if (rx) {
+   ch = >rx_ch_num;
+   chan = cpsw->rxch;
+   handler = cpsw_rx_handler;
+   poll = cpsw_rx_poll;
+   } else {
+   ch = >tx_ch_num;
+   chan = cpsw->txch;
+   handler = cpsw_tx_handler;
+   poll = cpsw_tx_poll;
+   }
+
+   while (*ch < ch_num) {
+   chan[*ch] = cpdma_chan_create(cpsw->dma, *ch, handler, rx);
+
+   if (IS_ERR(chan[*ch]))
+   return PTR_ERR(chan[*ch]);
+
+   if (!chan[*ch])
+   return -EINVAL;
+
+   cpsw_info(priv, ifup, "created new %d %s channel\n", *ch,
+ (rx ? "rx" : "tx"));
+   (*ch)++;
+   }
+
+   while (*ch > ch_num) {
+   (*ch)--;
+
+   ret = cpdma_chan_destroy(chan[*ch]);
+   if (ret)
+  

Re: [PATCH v3 5/5] net: ethernet: ti: cpsw: add ethtool channels support

[ivan.khoronzhuk]

On 17.08.16 09:22, Mugunthan V N wrote:

On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote:

These ops allow to control number of channels driver is allowed to
work with at cpdma level. The maximum number of channels is 8 for
rx and 8 for tx. In dual_emac mode the h/w channels are shared
between two interfaces and changing number on one interface changes
number of channels on another.

How many channels are supported and enabled:
$ ethtool -l ethX

Change number of channels (up to 8)
$ ethtool -L ethX rx 6 tx 6

Per-channel statistic:
$ ethtool -S ethX

Signed-off-by: Ivan Khoronzhuk 
---
 drivers/net/ethernet/ti/cpsw.c | 180 -
 1 file changed, 176 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 6dcbd8a..f02e577 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -735,6 +735,11 @@ static void cpsw_rx_handler(void *token, int len, int 
status)
}

 requeue:
+   if (netif_dormant(ndev)) {
+   dev_kfree_skb_any(new_skb);
+   return;
+   }
+
ch = cpsw->rxch[skb_get_queue_mapping(new_skb)];
ret = cpdma_chan_submit(ch, new_skb, new_skb->data,
skb_tailroom(new_skb), 0);
@@ -1267,9 +1272,8 @@ static void cpsw_init_host_port(struct cpsw_priv *priv)
}
 }

-static int cpsw_fill_rx_channels(struct net_device *ndev)
+static int cpsw_fill_rx_channels(struct cpsw_priv *priv)


This change can be moved to patch 1/5 where the function definition is
added at first.

Yes. Will do it in v4.




 {
-   struct cpsw_priv *priv = netdev_priv(ndev);
struct cpsw_common *cpsw = priv->cpsw;
struct sk_buff *skb;
int ch, i, ret;
@@ -1279,7 +1283,7 @@ static int cpsw_fill_rx_channels(struct net_device *ndev)

ch_buf_num = cpdma_chan_get_rx_buf_num(cpsw->rxch[ch]);
for (i = 0; i < ch_buf_num; i++) {
-   skb = __netdev_alloc_skb_ip_align(ndev,
+   skb = __netdev_alloc_skb_ip_align(priv->ndev,
  cpsw->rx_packet_max,
  GFP_KERNEL);
if (!skb) {
@@ -1397,7 +1401,7 @@ static int cpsw_ndo_open(struct net_device *ndev)
enable_irq(cpsw->irqs_table[0]);
}

-   ret = cpsw_fill_rx_channels(ndev);
+   ret = cpsw_fill_rx_channels(priv);
if (ret < 0)
goto err_cleanup;

@@ -2060,6 +2064,172 @@ static void cpsw_ethtool_op_complete(struct net_device 
*ndev)
cpsw_err(priv, drv, "ethtool complete failed %d\n", ret);
 }

+static void cpsw_get_channels(struct net_device *ndev,
+ struct ethtool_channels *ch)
+{
+   struct cpsw_common *cpsw = ndev_to_cpsw(ndev);
+
+   ch->max_combined = 0;
+   ch->max_rx = CPSW_MAX_QUEUES;
+   ch->max_tx = CPSW_MAX_QUEUES;
+   ch->max_other = 0;
+   ch->other_count = 0;
+   ch->rx_count = cpsw->rx_ch_num;
+   ch->tx_count = cpsw->tx_ch_num;
+   ch->combined_count = 0;
+}
+
+static int cpsw_check_ch_settings(struct cpsw_common *cpsw,
+ struct ethtool_channels *ch)
+{
+   if (ch->combined_count)
+   return -EINVAL;
+
+   /* verify we have at least one channel in each direction */
+   if (!ch->rx_count || !ch->tx_count)
+   return -EINVAL;
+
+   if (ch->rx_count > cpsw->data.channels ||
+   ch->tx_count > cpsw->data.channels)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int cpsw_update_channels_res(struct cpsw_priv *priv, int ch_num, int rx)
+{
+   int (*poll)(struct napi_struct *, int);
+   struct cpsw_common *cpsw = priv->cpsw;
+   void (*handler)(void *, int, int);
+   struct cpdma_chan **chan;
+   int ret, *ch;
+
+   if (rx) {
+   ch = >rx_ch_num;
+   chan = cpsw->rxch;
+   handler = cpsw_rx_handler;
+   poll = cpsw_rx_poll;
+   } else {
+   ch = >tx_ch_num;
+   chan = cpsw->txch;
+   handler = cpsw_tx_handler;
+   poll = cpsw_tx_poll;
+   }
+
+   while (*ch < ch_num) {
+   chan[*ch] = cpdma_chan_create(cpsw->dma, *ch, handler, rx);
+
+   if (IS_ERR(chan[*ch]))
+   return PTR_ERR(chan[*ch]);
+
+   if (!chan[*ch])
+   return -EINVAL;
+
+   cpsw_info(priv, ifup, "created new %d %s channel\n", *ch,
+ (rx ? "rx" : "tx"));
+   (*ch)++;
+   }
+
+   while (*ch > ch_num) {
+   (*ch)--;
+
+   ret = cpdma_chan_destroy(chan[*ch]);
+   if (ret)
+   return ret;
+
+

Re: [PATCH 1/3] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

[ivan.khoronzhuk]

On 26.07.16 19:02, Grygorii Strashko wrote:

On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote:



On 22.07.16 16:58, Grygorii Strashko wrote:

Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
cpsw module removal:
 cpsw_remove()
 - cpdma_ctlr_destroy()
   - spin_lock_irqsave(>lock, flags)
   - cpdma_ctlr_stop()
 - spin_lock_irqsave(>lock, flags); <- deadlock
   - cpdma_chan_destroy()
 - spin_lock_irqsave(>lock, flags); <- deadlock

The issue has not been observed before because CPDMA channels have
been destroyed manually by CPSW until commit d941ebe88a41 ("net:
ethernet: ti: cpsw: use destroy ctlr to destroy channels") was merged.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/davinci_cpdma.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index a68652a..89242e9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -436,7 +436,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 if (!ctlr)
 return -EINVAL;

-spin_lock_irqsave(>lock, flags);

Should ctlr->state be checked under lock?
Seems like here should be used unlocked static versions of
cpdma_ctlr_stop() and cpdma_chan_destroy() instead.


As per my understanding it's not expected the ctlr->state will be changed at 
this
moment as all net devices has been unregistered already.

Seems yes, the race can be only in case of incorrect usage, stop while destroy,
destroy while start...etc..all they are mostly unreal use-cases, you are right,
but such check w/o lock always under eyes control, that always makes you think
that smth wrong.






 if (ctlr->state != CPDMA_STATE_IDLE)


May be I can move above check in cpdma_ctlr_stop() instead.
What do you think?

Yes, it be more clear.
I was thinking about lock deletion also, as under this destroy function the
ctlr destroys it's resources one by one, ok, the channels are destroyed under 
lock,
but pool (it's good that it's destroyed after channels). I see that it 
should never
happen, but ctrl is external structure, who knows as it can be used while 
destroying.
That was my paranoiac point, so don't pay a lot attention to it. In case of 
normal usage,
as it's currently is and should be, the lock can be removed.




 cpdma_ctlr_stop(ctlr);

@@ -444,7 +443,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 cpdma_chan_destroy(ctlr->channels[i]);

 cpdma_desc_pool_destroy(ctlr->pool);
-spin_unlock_irqrestore(>lock, flags);
 return ret;
 }
 EXPORT_SYMBOL_GPL(cpdma_ctlr_destroy);

Re: [PATCH 1/3] net: ethernet: ti: cpdma: fix lockup in cpdma_ctlr_destroy()

[ivan.khoronzhuk]

On 26.07.16 19:02, Grygorii Strashko wrote:

On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote:



On 22.07.16 16:58, Grygorii Strashko wrote:

Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
cpsw module removal:
 cpsw_remove()
 - cpdma_ctlr_destroy()
   - spin_lock_irqsave(>lock, flags)
   - cpdma_ctlr_stop()
 - spin_lock_irqsave(>lock, flags); <- deadlock
   - cpdma_chan_destroy()
 - spin_lock_irqsave(>lock, flags); <- deadlock

The issue has not been observed before because CPDMA channels have
been destroyed manually by CPSW until commit d941ebe88a41 ("net:
ethernet: ti: cpsw: use destroy ctlr to destroy channels") was merged.

Signed-off-by: Grygorii Strashko 
---
 drivers/net/ethernet/ti/davinci_cpdma.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c
b/drivers/net/ethernet/ti/davinci_cpdma.c
index a68652a..89242e9 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -436,7 +436,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 if (!ctlr)
 return -EINVAL;

-spin_lock_irqsave(>lock, flags);

Should ctlr->state be checked under lock?
Seems like here should be used unlocked static versions of
cpdma_ctlr_stop() and cpdma_chan_destroy() instead.


As per my understanding it's not expected the ctlr->state will be changed at 
this
moment as all net devices has been unregistered already.

Seems yes, the race can be only in case of incorrect usage, stop while destroy,
destroy while start...etc..all they are mostly unreal use-cases, you are right,
but such check w/o lock always under eyes control, that always makes you think
that smth wrong.






 if (ctlr->state != CPDMA_STATE_IDLE)


May be I can move above check in cpdma_ctlr_stop() instead.
What do you think?

Yes, it be more clear.
I was thinking about lock deletion also, as under this destroy function the
ctlr destroys it's resources one by one, ok, the channels are destroyed under 
lock,
but pool (it's good that it's destroyed after channels). I see that it 
should never
happen, but ctrl is external structure, who knows as it can be used while 
destroying.
That was my paranoiac point, so don't pay a lot attention to it. In case of 
normal usage,
as it's currently is and should be, the lock can be removed.




 cpdma_ctlr_stop(ctlr);

@@ -444,7 +443,6 @@ int cpdma_ctlr_destroy(struct cpdma_ctlr *ctlr)
 cpdma_chan_destroy(ctlr->channels[i]);

 cpdma_desc_pool_destroy(ctlr->pool);
-spin_unlock_irqrestore(>lock, flags);
 return ret;
 }
 EXPORT_SYMBOL_GPL(cpdma_ctlr_destroy);

Re: [PATCH] net: ethernet: ti: cpdma: switch to use genalloc

[ivan.khoronzhuk]

On 23.06.16 15:36, Grygorii Strashko wrote:

TI CPDMA currently uses a bitmap for tracking descriptors alloactions
allocations, but The genalloc already handles the same and can be used
as with special memory (SRAM) as with DMA cherent memory chank
(dma_alloc_coherent()). Hence, switch to using genalloc and add
desc_num property for each channel for limitation of max number of
allowed descriptors for each CPDMA channel. This patch do not affect
on net throuput.

Cc: Ivan Khoronzhuk 
Signed-off-by: Grygorii Strashko 


Tested-by: Ivan Khoronzhuk 


---
Testing
TCP window: 256K, bandwidth in Mbits/sec:
  host: iperf -s
  device: iperf -c  172.22.39.17 -t600 -i5 -d -w128K

AM437x-idk, 1Gbps link
  before: : 341.60, after: 232+123=355
am57xx-beagle-x15, 1Gbps link
  before: : 1112.80, after: 814+321=1135
am335x-boneblack, 100Mbps link
  before: : 162.40, after: 72+93=165

  drivers/net/ethernet/ti/davinci_cpdma.c | 136 +++-
  1 file changed, 62 insertions(+), 74 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c 
b/drivers/net/ethernet/ti/davinci_cpdma.c
index 18bf3a8..03b9882 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -21,7 +21,7 @@
  #include 
  #include 
  #include 
-
+#include 
  #include "davinci_cpdma.h"

  /* DMA Registers */
@@ -87,9 +87,8 @@ struct cpdma_desc_pool {
void*cpumap;/* dma_alloc map */
int desc_size, mem_size;
int num_desc, used_desc;
-   unsigned long   *bitmap;
struct device   *dev;
-   spinlock_t  lock;
+   struct gen_pool *gen_pool;
  };

  enum cpdma_state {
@@ -117,6 +116,7 @@ struct cpdma_chan {
int chan_num;
spinlock_t  lock;
int count;
+   u32 desc_num;
u32 mask;
cpdma_handler_fnhandler;
enum dma_data_direction dir;
@@ -145,6 +145,20 @@ struct cpdma_chan {
 (directed << CPDMA_TO_PORT_SHIFT));  \
} while (0)

+static void cpdma_desc_pool_destroy(struct cpdma_desc_pool *pool)
+{
+   if (!pool)
+   return;
+
+   WARN_ON(pool->used_desc);
+   if (pool->cpumap) {
+   dma_free_coherent(pool->dev, pool->mem_size, pool->cpumap,
+ pool->phys);
+   } else {
+   iounmap(pool->iomap);
+   }
+}
+
  /*
   * Utility constructs for a cpdma descriptor pool.  Some devices (e.g. davinci
   * emac) have dedicated on-chip memory for these descriptors.  Some other
@@ -155,24 +169,25 @@ static struct cpdma_desc_pool *
  cpdma_desc_pool_create(struct device *dev, u32 phys, dma_addr_t hw_addr,
int size, int align)
  {
-   int bitmap_size;
struct cpdma_desc_pool *pool;
+   int ret;

pool = devm_kzalloc(dev, sizeof(*pool), GFP_KERNEL);
if (!pool)
-   goto fail;
-
-   spin_lock_init(>lock);
+   goto gen_pool_create_fail;

pool->dev= dev;
pool->mem_size   = size;
pool->desc_size  = ALIGN(sizeof(struct cpdma_desc), align);
pool->num_desc   = size / pool->desc_size;

-   bitmap_size  = (pool->num_desc / BITS_PER_LONG) * sizeof(long);
-   pool->bitmap = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
-   if (!pool->bitmap)
-   goto fail;
+   pool->gen_pool = devm_gen_pool_create(dev, ilog2(pool->desc_size), -1,
+ "cpdma");
+   if (IS_ERR(pool->gen_pool)) {
+   dev_err(dev, "pool create failed %ld\n",
+   PTR_ERR(pool->gen_pool));
+   goto gen_pool_create_fail;
+   }

if (phys) {
pool->phys  = phys;
@@ -185,24 +200,22 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, 
dma_addr_t hw_addr,
pool->phys = pool->hw_addr; /* assumes no IOMMU, don't use this 
value */
}

-   if (pool->iomap)
-   return pool;
-fail:
-   return NULL;
-}
-
-static void cpdma_desc_pool_destroy(struct cpdma_desc_pool *pool)
-{
-   if (!pool)
-   return;
+   if (!pool->iomap)
+   goto gen_pool_create_fail;

-   WARN_ON(pool->used_desc);
-   if (pool->cpumap) {
-   dma_free_coherent(pool->dev, pool->mem_size, pool->cpumap,
- pool->phys);
-   } else {
-   iounmap(pool->iomap);
+   ret = gen_pool_add_virt(pool->gen_pool, (unsigned long)pool->iomap,
+   pool->phys, pool->mem_size, -1);
+   if (ret < 0) {
+   

Re: [PATCH] net: ethernet: ti: cpdma: switch to use genalloc

[ivan.khoronzhuk]

On 23.06.16 15:36, Grygorii Strashko wrote:

TI CPDMA currently uses a bitmap for tracking descriptors alloactions
allocations, but The genalloc already handles the same and can be used
as with special memory (SRAM) as with DMA cherent memory chank
(dma_alloc_coherent()). Hence, switch to using genalloc and add
desc_num property for each channel for limitation of max number of
allowed descriptors for each CPDMA channel. This patch do not affect
on net throuput.

Cc: Ivan Khoronzhuk 
Signed-off-by: Grygorii Strashko 


Tested-by: Ivan Khoronzhuk 


---
Testing
TCP window: 256K, bandwidth in Mbits/sec:
  host: iperf -s
  device: iperf -c  172.22.39.17 -t600 -i5 -d -w128K

AM437x-idk, 1Gbps link
  before: : 341.60, after: 232+123=355
am57xx-beagle-x15, 1Gbps link
  before: : 1112.80, after: 814+321=1135
am335x-boneblack, 100Mbps link
  before: : 162.40, after: 72+93=165

  drivers/net/ethernet/ti/davinci_cpdma.c | 136 +++-
  1 file changed, 62 insertions(+), 74 deletions(-)

diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c 
b/drivers/net/ethernet/ti/davinci_cpdma.c
index 18bf3a8..03b9882 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -21,7 +21,7 @@
  #include 
  #include 
  #include 
-
+#include 
  #include "davinci_cpdma.h"

  /* DMA Registers */
@@ -87,9 +87,8 @@ struct cpdma_desc_pool {
void*cpumap;/* dma_alloc map */
int desc_size, mem_size;
int num_desc, used_desc;
-   unsigned long   *bitmap;
struct device   *dev;
-   spinlock_t  lock;
+   struct gen_pool *gen_pool;
  };

  enum cpdma_state {
@@ -117,6 +116,7 @@ struct cpdma_chan {
int chan_num;
spinlock_t  lock;
int count;
+   u32 desc_num;
u32 mask;
cpdma_handler_fnhandler;
enum dma_data_direction dir;
@@ -145,6 +145,20 @@ struct cpdma_chan {
 (directed << CPDMA_TO_PORT_SHIFT));  \
} while (0)

+static void cpdma_desc_pool_destroy(struct cpdma_desc_pool *pool)
+{
+   if (!pool)
+   return;
+
+   WARN_ON(pool->used_desc);
+   if (pool->cpumap) {
+   dma_free_coherent(pool->dev, pool->mem_size, pool->cpumap,
+ pool->phys);
+   } else {
+   iounmap(pool->iomap);
+   }
+}
+
  /*
   * Utility constructs for a cpdma descriptor pool.  Some devices (e.g. davinci
   * emac) have dedicated on-chip memory for these descriptors.  Some other
@@ -155,24 +169,25 @@ static struct cpdma_desc_pool *
  cpdma_desc_pool_create(struct device *dev, u32 phys, dma_addr_t hw_addr,
int size, int align)
  {
-   int bitmap_size;
struct cpdma_desc_pool *pool;
+   int ret;

pool = devm_kzalloc(dev, sizeof(*pool), GFP_KERNEL);
if (!pool)
-   goto fail;
-
-   spin_lock_init(>lock);
+   goto gen_pool_create_fail;

pool->dev= dev;
pool->mem_size   = size;
pool->desc_size  = ALIGN(sizeof(struct cpdma_desc), align);
pool->num_desc   = size / pool->desc_size;

-   bitmap_size  = (pool->num_desc / BITS_PER_LONG) * sizeof(long);
-   pool->bitmap = devm_kzalloc(dev, bitmap_size, GFP_KERNEL);
-   if (!pool->bitmap)
-   goto fail;
+   pool->gen_pool = devm_gen_pool_create(dev, ilog2(pool->desc_size), -1,
+ "cpdma");
+   if (IS_ERR(pool->gen_pool)) {
+   dev_err(dev, "pool create failed %ld\n",
+   PTR_ERR(pool->gen_pool));
+   goto gen_pool_create_fail;
+   }

if (phys) {
pool->phys  = phys;
@@ -185,24 +200,22 @@ cpdma_desc_pool_create(struct device *dev, u32 phys, 
dma_addr_t hw_addr,
pool->phys = pool->hw_addr; /* assumes no IOMMU, don't use this 
value */
}

-   if (pool->iomap)
-   return pool;
-fail:
-   return NULL;
-}
-
-static void cpdma_desc_pool_destroy(struct cpdma_desc_pool *pool)
-{
-   if (!pool)
-   return;
+   if (!pool->iomap)
+   goto gen_pool_create_fail;

-   WARN_ON(pool->used_desc);
-   if (pool->cpumap) {
-   dma_free_coherent(pool->dev, pool->mem_size, pool->cpumap,
- pool->phys);
-   } else {
-   iounmap(pool->iomap);
+   ret = gen_pool_add_virt(pool->gen_pool, (unsigned long)pool->iomap,
+   pool->phys, pool->mem_size, -1);
+   if (ret < 0) {
+   dev_err(dev, "pool add failed %d\n", ret);
+   goto 

Re: [REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables

[ivan.khoronzhuk]

Hi Paul,

The dmi_remap() is arch dependent function and for mainline used as 
ioremap_cache for x86, arm..
And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking 
about k4.5.
It's rather bug of dmi_remap than the patch which just use it.

The only reason why the bug wasn't found earlier it was unmapped back at init, 
but it
doesn't mean it cannot be used after init, which can lead to strange behavior 
in future.
If it should be ioremap_cache(), it's better to change dmi_remap() for your 
arch.

Oh, yes, k4.2 is using the ioremap instead of ioremap_cache().
But seems it's currently solved with:
commit ce1143aa60273220a9f89012f2aaaed04f97e9a2
"x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()"
So, probably, it should be back ported.

On 28.03.16 11:44, Paul Menzel wrote:

Dear Ivan, dear Jeann,


There is an unwanted regression due to commit d7f96f97 (firmware:
dmi_scan: add SBMIOS entry and DMI tables).

Since Linux kernel 4.2 the utility `cbmem`, used to access information
stored in memory, from the coreboot project [1] does not work anymore
on a lot of systems as reported in coreboot’s issue tracker as ticket
#33 [2].

```
Failed to mmap /dev/mem: Resource temporarily unavailable
```

Aaron Durbin analyzed on the coreboot mailing list [3]:


3) Why is that range set as uncached-minus?  Would write-back work?


Please see this thread:
http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html

The actual issue stems from
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f
which maintains a persistent mapping of smbios tables. It uses
dmi_remap() which is '#define dmi_remap ioremap' which is where the
uncached-minus PAT entry comes from. It should be using the same
mechanism as  the ACPI table mappings which uses ioremap_cache().


It’d be great, if the commit could be reverted, or the code be changed
in a way that `cbmem` still works.

If I should report this issue somewhere else, please tell me too, and
I’ll do my best to follow up there.


Thanks,

Paul


[1] https://www.coreboot.org
[2] https://ticket.coreboot.org/issues/33
[3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html

Re: [REGRESSION] firmware: dmi_scan: add SBMIOS entry and DMI tables

[ivan.khoronzhuk]

Hi Paul,

The dmi_remap() is arch dependent function and for mainline used as 
ioremap_cache for x86, arm..
And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking 
about k4.5.
It's rather bug of dmi_remap than the patch which just use it.

The only reason why the bug wasn't found earlier it was unmapped back at init, 
but it
doesn't mean it cannot be used after init, which can lead to strange behavior 
in future.
If it should be ioremap_cache(), it's better to change dmi_remap() for your 
arch.

Oh, yes, k4.2 is using the ioremap instead of ioremap_cache().
But seems it's currently solved with:
commit ce1143aa60273220a9f89012f2aaaed04f97e9a2
"x86/dmi: Switch dmi_remap() from ioremap() [uncached] to ioremap_cache()"
So, probably, it should be back ported.

On 28.03.16 11:44, Paul Menzel wrote:

Dear Ivan, dear Jeann,


There is an unwanted regression due to commit d7f96f97 (firmware:
dmi_scan: add SBMIOS entry and DMI tables).

Since Linux kernel 4.2 the utility `cbmem`, used to access information
stored in memory, from the coreboot project [1] does not work anymore
on a lot of systems as reported in coreboot’s issue tracker as ticket
#33 [2].

```
Failed to mmap /dev/mem: Resource temporarily unavailable
```

Aaron Durbin analyzed on the coreboot mailing list [3]:


3) Why is that range set as uncached-minus?  Would write-back work?


Please see this thread:
http://www.coreboot.org/pipermail/coreboot/2015-September/080381.html

The actual issue stems from
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/firmware/dmi_scan.c?id=d7f96f97c4031fa4ffdb7801f9aae23e96170a6f
which maintains a persistent mapping of smbios tables. It uses
dmi_remap() which is '#define dmi_remap ioremap' which is where the
uncached-minus PAT entry comes from. It should be using the same
mechanism as  the ACPI table mappings which uses ioremap_cache().


It’d be great, if the commit could be reverted, or the code be changed
in a way that `cbmem` still works.

If I should report this issue somewhere else, please tell me too, and
I’ll do my best to follow up there.


Thanks,

Paul


[1] https://www.coreboot.org
[2] https://ticket.coreboot.org/issues/33
[3] https://www.coreboot.org/pipermail/coreboot/2015-October/080568.html

Re: [PATCH 3.2 068/221] firmware: dmi_scan: Fix dmi_len type

[ivan.khoronzhuk]

Hi Ben,

There is no need in this patch for 3.2, only beginning from 3.19.
SMBIOSv3 is absent in k3.2, and for previous SMBIOS versions 16-bit dmi len
is enough. It should had been mentioned in the commit/code, sorry.

On 05.05.15 04:16, Ben Hutchings wrote:

3.2.69-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ivan Khoronzhuk 

commit 6d9ff473317245e3e5cd9922b4520411c2296388 upstream.

According to SMBIOSv3 specification the length of DMI table can be
up to 32bits wide. So use appropriate type to avoid overflow.

It's obvious that dmi_num theoretically can be more than u16 also,
so it's can be changed to u32 or at least it's better to use int
instead of u16, but on that moment I cannot imagine dmi structure
count more than 65535 and it can require changing type of vars that
work with it. So I didn't correct it.

Acked-by: Ard Biesheuvel 
Signed-off-by: Ivan Khoronzhuk 
Signed-off-by: Matt Fleming 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings 
---
  drivers/firmware/dmi_scan.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -69,7 +69,7 @@ static char * __init dmi_string(const st
   *We have to be cautious here. We have seen BIOSes with DMI pointers
   *pointing to completely the wrong place for example
   */
-static void dmi_table(u8 *buf, int len, int num,
+static void dmi_table(u8 *buf, u32 len, int num,
  void (*decode)(const struct dmi_header *, void *),
  void *private_data)
  {
@@ -99,7 +99,7 @@ static void dmi_table(u8 *buf, int len,
  }
  
  static u32 dmi_base;

-static u16 dmi_len;
+static u32 dmi_len;
  static u16 dmi_num;
  
  static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,


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


--
Regards,
Ivan Khoronzhuk

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

Re: [PATCH 3.2 068/221] firmware: dmi_scan: Fix dmi_len type

[ivan.khoronzhuk]

Hi Ben,

There is no need in this patch for 3.2, only beginning from 3.19.
SMBIOSv3 is absent in k3.2, and for previous SMBIOS versions 16-bit dmi len
is enough. It should had been mentioned in the commit/code, sorry.

On 05.05.15 04:16, Ben Hutchings wrote:

3.2.69-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Ivan Khoronzhuk ivan.khoronz...@linaro.org

commit 6d9ff473317245e3e5cd9922b4520411c2296388 upstream.

According to SMBIOSv3 specification the length of DMI table can be
up to 32bits wide. So use appropriate type to avoid overflow.

It's obvious that dmi_num theoretically can be more than u16 also,
so it's can be changed to u32 or at least it's better to use int
instead of u16, but on that moment I cannot imagine dmi structure
count more than 65535 and it can require changing type of vars that
work with it. So I didn't correct it.

Acked-by: Ard Biesheuvel a...@linaro.org
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@linaro.org
Signed-off-by: Matt Fleming matt.flem...@intel.com
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
  drivers/firmware/dmi_scan.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -69,7 +69,7 @@ static char * __init dmi_string(const st
   *We have to be cautious here. We have seen BIOSes with DMI pointers
   *pointing to completely the wrong place for example
   */
-static void dmi_table(u8 *buf, int len, int num,
+static void dmi_table(u8 *buf, u32 len, int num,
  void (*decode)(const struct dmi_header *, void *),
  void *private_data)
  {
@@ -99,7 +99,7 @@ static void dmi_table(u8 *buf, int len,
  }
  
  static u32 dmi_base;

-static u16 dmi_len;
+static u32 dmi_len;
  static u16 dmi_num;
  
  static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,


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


--
Regards,
Ivan Khoronzhuk

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

Re: [PATCH 1/2] firmware: dmi_scan: Simplified displayed version

[Ivan.khoronzhuk]

Sorry sent it from wrong address, just don't have access to linaro mailbox,
at least for now.

--
Regards,
Ivan Khoronzhuk

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

Re: [PATCH] firmware: dmi_scan: Trim DMI table length before exporting it

[Ivan.khoronzhuk]

Hi, Jean

On 26.04.15 23:47, Jean Delvare wrote:

The SMBIOS v3 entry points specify a maximum length for the DMI table,
not the exact length. Thus there may be garbage after the end-of-table
marker, which we don't want to export to user-space. Adjust dmi_len
when we find the end-of-table marker, so that only the actual table
payload is exported.


According to above it seems that change doesn't affect SMBIOS < 3.



Signed-off-by: Jean Delvare 
Cc: Ivan Khoronzhuk 
---
  drivers/firmware/dmi_scan.c |   15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

--- linux-4.1-rc0.orig/drivers/firmware/dmi_scan.c  2015-04-26 
18:56:15.65785 +0200
+++ linux-4.1-rc0/drivers/firmware/dmi_scan.c   2015-04-26 22:42:59.183547584 
+0200
@@ -108,15 +108,19 @@ static void dmi_decode_table(u8 *buf,
if (data - buf < dmi_len - 1)
decode(dm, private_data);
  
+		data += 2;

+   i++;
+
/*
 * 7.45 End-of-Table (Type 127) [SMBIOS reference spec v3.0.0]
 */
if (dm->type == DMI_ENTRY_END_OF_TABLE)
break;
-
-   data += 2;
-   i++;
}
+
+   /* Trim DMI table length if needed */
+   if (dmi_len > data - buf)
+   dmi_len = data - buf;


Why is it checked here? Wouldn't be better to simply assign: dmi_len = 
data - buf;
I guess it's supposed to not trim table in case of exit by ieven !dmi_num.

But in this case, probably, it be better to do it in the cycle:

if (dmi->type == DMI_ENTRY_END_OF_TABLE) {
dmi_len = data - buf;
break;
}

just to avoid redundant check.

But question is, what if we exit by i
  }
  
  static phys_addr_t dmi_base;

@@ -125,8 +129,9 @@ static int __init dmi_walk_early(void (*
void *))
  {
u8 *buf;
+   u32 orig_dmi_len = dmi_len;
  
-	buf = dmi_early_remap(dmi_base, dmi_len);

+   buf = dmi_early_remap(dmi_base, orig_dmi_len);
if (buf == NULL)
return -1;
  
@@ -134,7 +139,7 @@ static int __init dmi_walk_early(void (*
  
  	add_device_randomness(buf, dmi_len);
  
-	dmi_early_unmap(buf, dmi_len);

+   dmi_early_unmap(buf, orig_dmi_len);
return 0;
  }
  



--
Regards,
Ivan Khoronzhuk

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

Re: [PATCH] firmware: dmi_scan: Trim DMI table length before exporting it

[Ivan.khoronzhuk]

Hi, Jean

On 26.04.15 23:47, Jean Delvare wrote:

The SMBIOS v3 entry points specify a maximum length for the DMI table,
not the exact length. Thus there may be garbage after the end-of-table
marker, which we don't want to export to user-space. Adjust dmi_len
when we find the end-of-table marker, so that only the actual table
payload is exported.


According to above it seems that change doesn't affect SMBIOS  3.



Signed-off-by: Jean Delvare jdelv...@suse.de
Cc: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---
  drivers/firmware/dmi_scan.c |   15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

--- linux-4.1-rc0.orig/drivers/firmware/dmi_scan.c  2015-04-26 
18:56:15.65785 +0200
+++ linux-4.1-rc0/drivers/firmware/dmi_scan.c   2015-04-26 22:42:59.183547584 
+0200
@@ -108,15 +108,19 @@ static void dmi_decode_table(u8 *buf,
if (data - buf  dmi_len - 1)
decode(dm, private_data);
  
+		data += 2;

+   i++;
+
/*
 * 7.45 End-of-Table (Type 127) [SMBIOS reference spec v3.0.0]
 */
if (dm-type == DMI_ENTRY_END_OF_TABLE)
break;
-
-   data += 2;
-   i++;
}
+
+   /* Trim DMI table length if needed */
+   if (dmi_len  data - buf)
+   dmi_len = data - buf;


Why is it checked here? Wouldn't be better to simply assign: dmi_len = 
data - buf;
I guess it's supposed to not trim table in case of exit by idmi_num or 
even !dmi_num.

But in this case, probably, it be better to do it in the cycle:

if (dmi-type == DMI_ENTRY_END_OF_TABLE) {
dmi_len = data - buf;
break;
}

just to avoid redundant check.

But question is, what if we exit by idmi_num?
Wouldn't be better to trim buffer in such case also?


  }
  
  static phys_addr_t dmi_base;

@@ -125,8 +129,9 @@ static int __init dmi_walk_early(void (*
void *))
  {
u8 *buf;
+   u32 orig_dmi_len = dmi_len;
  
-	buf = dmi_early_remap(dmi_base, dmi_len);

+   buf = dmi_early_remap(dmi_base, orig_dmi_len);
if (buf == NULL)
return -1;
  
@@ -134,7 +139,7 @@ static int __init dmi_walk_early(void (*
  
  	add_device_randomness(buf, dmi_len);
  
-	dmi_early_unmap(buf, dmi_len);

+   dmi_early_unmap(buf, orig_dmi_len);
return 0;
  }
  



--
Regards,
Ivan Khoronzhuk

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

Re: [PATCH 1/2] firmware: dmi_scan: Simplified displayed version

[Ivan.khoronzhuk]

Sorry sent it from wrong address, just don't have access to linaro mailbox,
at least for now.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch v2 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

Jean,

On 21.04.15 18:36, Jean Delvare wrote:

Hi again Ivan,

On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:

+   bin_attr_DMI.size = dmi_len;
+   bin_attr_DMI.private = dmi_table;
+   ret = sysfs_create_bin_file(tables_kobj, _attr_DMI);
+   if (!ret)
+   return 0;

I just found that more work is needed here for the SMBIOS v3 entry
point case. These entry points do not specify the exact length of the
table, but only its maximum. The real world sample I have access to
indeed specifies a maximum length of 6419 bytes, but the actual table
only spans over 2373 bytes. It is properly terminated with a type 127
DMI structure, so the kernel table parser ignores the garbage after it.
The garbage is however exported to user-space above.

I taught dmidecode to ignore the garbage, but there are two problem
left here. First problem is a waste of memory. Minor issue I suppose,
who cares about a few kilobytes these days.

Second problem is a security problem. We are leaking the contents of
physical memory to user-space. In my case it's filled with 0xffs so no
big deal. But what if actual data happens to be stored there? It
definitely shouldn't go to user-space.

So dmi_len needs to be trimmed to the actual table size before the
attribute above is created. I have an idea how this could be
implemented easily, let me give it a try.

Maybe we should trim the length for previous implementations, too.
There is no reason to walk past a type 127 structure anyway, ever.



It can happen of-cause, I've also thought about that sometime ago,
but forget...).
I've sent the updated series already.
Let me know when your fix will be ready and I will re-base the
series if it has conflicts.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch v2 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

Hi Jean,

On 21.04.15 17:24, Jean Delvare wrote:

Hi Ivan,

On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi/tables and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.

Signed-off-by: Ivan Khoronzhuk 
---
  .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
  drivers/firmware/dmi-sysfs.c   | 17 +++--
  drivers/firmware/dmi_scan.c| 82 ++
  include/linux/dmi.h|  2 +
  4 files changed, 114 insertions(+), 9 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables
(...)
+static int __init dmi_init(void)
+{
+   int ret;
+   u8 *dmi_table = NULL;
+   struct kobject *tables_kobj = NULL;
+
+   if (!dmi_available) {
+   ret = -ENODATA;
+   goto err;
+   }
+
+   /*
+* Set up dmi directory at /sys/firmware/dmi. This entry should stay
+* even after farther error, as it can be used by other modules like
+* dmi-sysfs.
+*/
+   dmi_kobj = kobject_create_and_add("dmi", firmware_kobj);
+   tables_kobj = kobject_create_and_add("tables", dmi_kobj);

I'm afraid you can't do that. kobject_create_and_add() doesn't check if
the parent is NULL and will happily create "tables" at the root of
sysfs if for any reason the previous call to kobject_create_and_add()
failed and returned NULL. I agree it is unlikely and would be cleaned
up immediately, but still, instantiating an object at the wrong place,
even temporarily, is wrong.


+   if (!(dmi_kobj && tables_kobj)) {
+   ret = -ENOMEM;
+   goto err;
+   }

I'd rather go with:

if (!(dmi_kobj = kobject_create_and_add("dmi", firmware_kobj))
 || !(tables_kobj = kobject_create_and_add("tables", dmi_kobj))) {

I know that checkpatch complains about this construct, but in many
cases it is the right thing to do.

Another possible approach is simply:

dmi_kobj = kobject_create_and_add("dmi", firmware_kobj);
if (dmi_kobj)
tables_kobj = kobject_create_and_add("tables", dmi_kobj);
if (!tables_kobj) {


+
+   bin_attr_smbios_entry_point.size = smbios_entry_point_size;
+   bin_attr_smbios_entry_point.private = smbios_entry_point;
+   ret = sysfs_create_bin_file(tables_kobj, _attr_smbios_entry_point);
+   if (ret)
+   goto err;
+
+   dmi_table = dmi_remap(dmi_base, dmi_len);
+   if (!dmi_table) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   bin_attr_DMI.size = dmi_len;
+   bin_attr_DMI.private = dmi_table;
+   ret = sysfs_create_bin_file(tables_kobj, _attr_DMI);
+   if (!ret)
+   return 0;
+
+err:
+   pr_err("dmi: Firmware registration failed.\n");
+
+   if (tables_kobj) {
+   sysfs_remove_bin_file(tables_kobj,
+ _attr_smbios_entry_point);
+   kobject_del(tables_kobj);
+   kobject_put(tables_kobj);
+   }
+
+   if (dmi_table)
+   dmi_unmap(dmi_table);

I'm not happy with this single error label. This forces you to
initialize all your pointers to NULL and then to check for them to find
out what needs to be done in the error path. With multiple error labels,
you would know exactly what needs to be done, this is more efficient.


+
+   return ret;
+}

Everything else looks good. No need to resend, I'll fix up the above
myself in place or as an incremental patch.

Thanks,


Don't bother, I'll send corrected version.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch v2 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

Hi Jean,

On 21.04.15 17:24, Jean Delvare wrote:

Hi Ivan,

On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi/tables and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---
  .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
  drivers/firmware/dmi-sysfs.c   | 17 +++--
  drivers/firmware/dmi_scan.c| 82 ++
  include/linux/dmi.h|  2 +
  4 files changed, 114 insertions(+), 9 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables
(...)
+static int __init dmi_init(void)
+{
+   int ret;
+   u8 *dmi_table = NULL;
+   struct kobject *tables_kobj = NULL;
+
+   if (!dmi_available) {
+   ret = -ENODATA;
+   goto err;
+   }
+
+   /*
+* Set up dmi directory at /sys/firmware/dmi. This entry should stay
+* even after farther error, as it can be used by other modules like
+* dmi-sysfs.
+*/
+   dmi_kobj = kobject_create_and_add(dmi, firmware_kobj);
+   tables_kobj = kobject_create_and_add(tables, dmi_kobj);

I'm afraid you can't do that. kobject_create_and_add() doesn't check if
the parent is NULL and will happily create tables at the root of
sysfs if for any reason the previous call to kobject_create_and_add()
failed and returned NULL. I agree it is unlikely and would be cleaned
up immediately, but still, instantiating an object at the wrong place,
even temporarily, is wrong.


+   if (!(dmi_kobj  tables_kobj)) {
+   ret = -ENOMEM;
+   goto err;
+   }

I'd rather go with:

if (!(dmi_kobj = kobject_create_and_add(dmi, firmware_kobj))
 || !(tables_kobj = kobject_create_and_add(tables, dmi_kobj))) {

I know that checkpatch complains about this construct, but in many
cases it is the right thing to do.

Another possible approach is simply:

dmi_kobj = kobject_create_and_add(dmi, firmware_kobj);
if (dmi_kobj)
tables_kobj = kobject_create_and_add(tables, dmi_kobj);
if (!tables_kobj) {


+
+   bin_attr_smbios_entry_point.size = smbios_entry_point_size;
+   bin_attr_smbios_entry_point.private = smbios_entry_point;
+   ret = sysfs_create_bin_file(tables_kobj, bin_attr_smbios_entry_point);
+   if (ret)
+   goto err;
+
+   dmi_table = dmi_remap(dmi_base, dmi_len);
+   if (!dmi_table) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   bin_attr_DMI.size = dmi_len;
+   bin_attr_DMI.private = dmi_table;
+   ret = sysfs_create_bin_file(tables_kobj, bin_attr_DMI);
+   if (!ret)
+   return 0;
+
+err:
+   pr_err(dmi: Firmware registration failed.\n);
+
+   if (tables_kobj) {
+   sysfs_remove_bin_file(tables_kobj,
+ bin_attr_smbios_entry_point);
+   kobject_del(tables_kobj);
+   kobject_put(tables_kobj);
+   }
+
+   if (dmi_table)
+   dmi_unmap(dmi_table);

I'm not happy with this single error label. This forces you to
initialize all your pointers to NULL and then to check for them to find
out what needs to be done in the error path. With multiple error labels,
you would know exactly what needs to be done, this is more efficient.


+
+   return ret;
+}

Everything else looks good. No need to resend, I'll fix up the above
myself in place or as an incremental patch.

Thanks,


Don't bother, I'll send corrected version.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch v2 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

Jean,

On 21.04.15 18:36, Jean Delvare wrote:

Hi again Ivan,

On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:

+   bin_attr_DMI.size = dmi_len;
+   bin_attr_DMI.private = dmi_table;
+   ret = sysfs_create_bin_file(tables_kobj, bin_attr_DMI);
+   if (!ret)
+   return 0;

I just found that more work is needed here for the SMBIOS v3 entry
point case. These entry points do not specify the exact length of the
table, but only its maximum. The real world sample I have access to
indeed specifies a maximum length of 6419 bytes, but the actual table
only spans over 2373 bytes. It is properly terminated with a type 127
DMI structure, so the kernel table parser ignores the garbage after it.
The garbage is however exported to user-space above.

I taught dmidecode to ignore the garbage, but there are two problem
left here. First problem is a waste of memory. Minor issue I suppose,
who cares about a few kilobytes these days.

Second problem is a security problem. We are leaking the contents of
physical memory to user-space. In my case it's filled with 0xffs so no
big deal. But what if actual data happens to be stored there? It
definitely shouldn't go to user-space.

So dmi_len needs to be trimmed to the actual table size before the
attribute above is created. I have an idea how this could be
implemented easily, let me give it a try.

Maybe we should trim the length for previous implementations, too.
There is no reason to walk past a type 127 structure anyway, ever.



It can happen of-cause, I've also thought about that sometime ago,
but forget...).
I've sent the updated series already.
Let me know when your fix will be ready and I will re-base the
series if it has conflicts.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode_table

[Ivan.khoronzhuk]

Hi Jean,

On 17.04.15 13:11, Ivan.khoronzhuk wrote:



On 17.04.15 11:54, Jean Delvare wrote:

Hi Ivan,

On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:

On 16.04.15 11:35, Jean Delvare wrote:

On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:

Jean, do you want me to pick this patch up or are you going to?

Good question, we need to agree on a strategy.

There are 3 patch sets to consider here.

1* My patch fixing the UUID ordering bug. It must go in first and
 immediately, as it fixes a regression and will have to be 
backported

 to stable branches.

||
V


2* 2 older patches from Ivan which are currently in your efi-next tree
 if I'm not mistaken. Both were based on an old tree so they do 
not
 apply cleanly on kernel v4.0, I had to fix them up manually. I 
have

They are in master tree already.


 no idea if git would be able to merge them properly, as the fix
 above changed the context even more.

Current efi-next already merged, so you should base your patches on
top of last changes.

Correct. I looked at the result and the merge looks correct. I'll turn
my objections into fixup patches to apply on top, where still worth it.
In particular I'll start with the ".x" revert, as it will make
backporting the bug fix easier.


3* The 3 new patches from Ivan which I am reviewing now, which are not
 applied in any public tree AFAIK.

It shouldn't happen,
I've been verifying just now once again.
They are applied on top of linux_next cleanly.
Equal as on efi/next.

I can't see them at
http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=next

To clarify: I do not claim that they can't be applied, I'm only saying
they're not there yet (which is OK as they were still pending my
review.) They do apply just fine, no problem with this.

I don't really care who picks these patches up and sends them to 
Linus,

but I think they should all follow the same route so that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.

I'm going to base my series
"firmware: dmi_scan: add SBMIOS entry point and DMI tables"
on top of linux next unless you have already your tree to pick up 
changes.

Please let me know, if you have one.

I have no formal tree yet, but my current patch set can be seen at:
http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/

First 2 patches from you are already upstream. You should rebase your
updated patch series on top of upstream + patches 03 and 04, as they
will go in first.

Thanks,


Not sure that's a good idea to base on patches that doesn't path any 
review and
no one cannot apply. At least it be good you send them that I can 
point on them in

commit message.



Don't know why your patches don't apply on top of linux next.
They looks w/o conflicts. I've applied them by hand. To avoid mess, 
could you

please send them in order I can refer on them in my commit message.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode_table

[Ivan.khoronzhuk]

On 17.04.15 11:54, Jean Delvare wrote:

Hi Ivan,

On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:

On 16.04.15 11:35, Jean Delvare wrote:

On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:

Jean, do you want me to pick this patch up or are you going to?

Good question, we need to agree on a strategy.

There are 3 patch sets to consider here.

1* My patch fixing the UUID ordering bug. It must go in first and
 immediately, as it fixes a regression and will have to be backported
 to stable branches.

||
V


2* 2 older patches from Ivan which are currently in your efi-next tree
 if I'm not mistaken. Both were based on an old tree so they do not
 apply cleanly on kernel v4.0, I had to fix them up manually. I have

They are in master tree already.


 no idea if git would be able to merge them properly, as the fix
 above changed the context even more.

Current efi-next already merged, so you should base your patches on
top of last changes.

Correct. I looked at the result and the merge looks correct. I'll turn
my objections into fixup patches to apply on top, where still worth it.
In particular I'll start with the ".x" revert, as it will make
backporting the bug fix easier.


3* The 3 new patches from Ivan which I am reviewing now, which are not
 applied in any public tree AFAIK.

It shouldn't happen,
I've been verifying just now once again.
They are applied on top of linux_next cleanly.
Equal as on efi/next.

I can't see them at
http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=next

To clarify: I do not claim that they can't be applied, I'm only saying
they're not there yet (which is OK as they were still pending my
review.) They do apply just fine, no problem with this.


I don't really care who picks these patches up and sends them to Linus,
but I think they should all follow the same route so that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.

I'm going to base my series
"firmware: dmi_scan: add SBMIOS entry point and DMI tables"
on top of linux next unless you have already your tree to pick up changes.
Please let me know, if you have one.

I have no formal tree yet, but my current patch set can be seen at:
http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/

First 2 patches from you are already upstream. You should rebase your
updated patch series on top of upstream + patches 03 and 04, as they
will go in first.

Thanks,


Not sure that's a good idea to base on patches that doesn't path any 
review and
no one cannot apply. At least it be good you send them that I can point 
on them in

commit message.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode_table

[Ivan.khoronzhuk]

On 17.04.15 11:54, Jean Delvare wrote:

Hi Ivan,

On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:

On 16.04.15 11:35, Jean Delvare wrote:

On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:

Jean, do you want me to pick this patch up or are you going to?

Good question, we need to agree on a strategy.

There are 3 patch sets to consider here.

1* My patch fixing the UUID ordering bug. It must go in first and
 immediately, as it fixes a regression and will have to be backported
 to stable branches.

||
V


2* 2 older patches from Ivan which are currently in your efi-next tree
 if I'm not mistaken. Both were based on an old tree so they do not
 apply cleanly on kernel v4.0, I had to fix them up manually. I have

They are in master tree already.


 no idea if git would be able to merge them properly, as the fix
 above changed the context even more.

Current efi-next already merged, so you should base your patches on
top of last changes.

Correct. I looked at the result and the merge looks correct. I'll turn
my objections into fixup patches to apply on top, where still worth it.
In particular I'll start with the .x revert, as it will make
backporting the bug fix easier.


3* The 3 new patches from Ivan which I am reviewing now, which are not
 applied in any public tree AFAIK.

It shouldn't happen,
I've been verifying just now once again.
They are applied on top of linux_next cleanly.
Equal as on efi/next.

I can't see them at
http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=next

To clarify: I do not claim that they can't be applied, I'm only saying
they're not there yet (which is OK as they were still pending my
review.) They do apply just fine, no problem with this.


I don't really care who picks these patches up and sends them to Linus,
but I think they should all follow the same route so that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.

I'm going to base my series
firmware: dmi_scan: add SBMIOS entry point and DMI tables
on top of linux next unless you have already your tree to pick up changes.
Please let me know, if you have one.

I have no formal tree yet, but my current patch set can be seen at:
http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/

First 2 patches from you are already upstream. You should rebase your
updated patch series on top of upstream + patches 03 and 04, as they
will go in first.

Thanks,


Not sure that's a good idea to base on patches that doesn't path any 
review and
no one cannot apply. At least it be good you send them that I can point 
on them in

commit message.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode_table

[Ivan.khoronzhuk]

Hi Jean,

On 17.04.15 13:11, Ivan.khoronzhuk wrote:



On 17.04.15 11:54, Jean Delvare wrote:

Hi Ivan,

On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:

On 16.04.15 11:35, Jean Delvare wrote:

On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:

Jean, do you want me to pick this patch up or are you going to?

Good question, we need to agree on a strategy.

There are 3 patch sets to consider here.

1* My patch fixing the UUID ordering bug. It must go in first and
 immediately, as it fixes a regression and will have to be 
backported

 to stable branches.

||
V


2* 2 older patches from Ivan which are currently in your efi-next tree
 if I'm not mistaken. Both were based on an old tree so they do 
not
 apply cleanly on kernel v4.0, I had to fix them up manually. I 
have

They are in master tree already.


 no idea if git would be able to merge them properly, as the fix
 above changed the context even more.

Current efi-next already merged, so you should base your patches on
top of last changes.

Correct. I looked at the result and the merge looks correct. I'll turn
my objections into fixup patches to apply on top, where still worth it.
In particular I'll start with the .x revert, as it will make
backporting the bug fix easier.


3* The 3 new patches from Ivan which I am reviewing now, which are not
 applied in any public tree AFAIK.

It shouldn't happen,
I've been verifying just now once again.
They are applied on top of linux_next cleanly.
Equal as on efi/next.

I can't see them at
http://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=next

To clarify: I do not claim that they can't be applied, I'm only saying
they're not there yet (which is OK as they were still pending my
review.) They do apply just fine, no problem with this.

I don't really care who picks these patches up and sends them to 
Linus,

but I think they should all follow the same route so that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.

I'm going to base my series
firmware: dmi_scan: add SBMIOS entry point and DMI tables
on top of linux next unless you have already your tree to pick up 
changes.

Please let me know, if you have one.

I have no formal tree yet, but my current patch set can be seen at:
http://jdelvare.nerim.net/devel/linux-3/jdelvare-dmi/

First 2 patches from you are already upstream. You should rebase your
updated patch series on top of upstream + patches 03 and 04, as they
will go in first.

Thanks,


Not sure that's a good idea to base on patches that doesn't path any 
review and
no one cannot apply. At least it be good you send them that I can 
point on them in

commit message.



Don't know why your patches don't apply on top of linux next.
They looks w/o conflicts. I've applied them by hand. To avoid mess, 
could you

please send them in order I can refer on them in my commit message.

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode_table

[Ivan.khoronzhuk]

Hi Jean,

On 16.04.15 11:35, Jean Delvare wrote:

Hi Matt,

On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:

On Thu, 02 Apr, at 03:57:01PM, Ivan Khoronzhuk wrote:

The "dmi_table" function looks like data instance, but it does DMI
table decode. This patch renames it to "dmi_decode_table" name as
more appropriate. That allows us to use "dmi_table" name for correct
purposes.

Signed-off-by: Ivan Khoronzhuk 
---
  drivers/firmware/dmi_scan.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

Looks good to me.

Jean, do you want me to pick this patch up or are you going to?

Good question, we need to agree on a strategy.

There are 3 patch sets to consider here.

1* My patch fixing the UUID ordering bug. It must go in first and
immediately, as it fixes a regression and will have to be backported
to stable branches.


||
V



2* 2 older patches from Ivan which are currently in your efi-next tree
if I'm not mistaken. Both were based on an old tree so they do not
apply cleanly on kernel v4.0, I had to fix them up manually. I have


They are in master tree already.


no idea if git would be able to merge them properly, as the fix
above changed the context even more.


Current efi-next already merged, so you should base your patches on
top of last changes.



3* The 3 new patches from Ivan which I am reviewing now, which are not
applied in any public tree AFAIK.


It shouldn't happen,
I've been verifying just now once again.
They are applied on top of linux_next cleanly.
Equal as on efi/next.



I don't really care who picks these patches up and sends them to Linus,
but I think they should all follow the same route so that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.

Thanks,


Jean,
I'm going to base my series
"firmware: dmi_scan: add SBMIOS entry point and DMI tables"
on top of linux next unless you have already your tree to pick up changes.
Please let me know, if you have one.


--
Regards,
Ivan Khoronzhuk

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

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

Sorry, sent it from not original mail.

On 16.04.15 20:27, subscivan wrote:

Jean,

On 16.04.15 18:44, Jean Delvare wrote:

Hi Ivan,

Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :

On 16.04.15 12:52, Jean Delvare wrote:

On Thu,  2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:
+static BIN_ATTR(smbios_entry_point, S_IRUSR, raw_table_read, 
NULL, 0);

This one could be world-readable as it contains no sensitive
information.

It contains the address of DMI table containing sensitive information.
Who knows which ways can be used to take it. Anyway, no see reasons 
in this

w/o DMI table. But if you insist I can do it "world-readable".

OK, you convinced me.


+struct bin_attribute bin_attr_dmi_table =
+__BIN_ATTR(DMI, S_IRUSR, raw_table_read, NULL, 0);
I do not understand why you don't use BIN_ATTR here too? I tried 
naming

the attribute bin_attr_DMI and it seems to work just fine, checkpatch
doesn't even complain!

I dislike upper case in names, at least in such simple names.
It makes me using bin_attr_DMI lower in the code. That's why.
But if you like it, I will name it "bin_attr_DMI"

I don't like upper case in names either, but in this specific case, I'd
do it for consistency. As you wish though, I really only wanted to know
the reason.


+
+static int __init dmi_init(void)
+{
+int ret = -ENOMEM;
+struct kobject *tables_kobj = NULL;
+
+if (!dmi_available) {
+ret = -ENOSYS;
+goto err;
+}

This is weird. Can this actually happen?

We currently have two ways to enter this module: dmi_scan_machine(),
which is called by the architecture code, and dmi_init(), which is
called at subsys_initcall time. As far as I can see,
core/arch_initcalls are guaranteed to be always called before
subsys_initcalls. If we can rely on that, the test above is not 
needed.

If for any reason we can't, that means that dmi_init() should not be a
subsys_initcall, but should instead be called explicitly at the end of
dmi_scan_machine().

We cannot be sure that firmware_kobj created at time of dmi_init().
The sources don't oblige you to call it at core level,
for instance like it was done for arm64. For x86, dmi_init() can be 
called

before firmware_kobj is created.

Looking at the code, it seems that firmware_kobj is created very, very
early in the boot process. In do_basic_setup(), you can see that
driver_init() (which in turn calls firmware_init(), creating
firmware_kobj) is called before do_initcalls(). So firmware_kobj must be
defined before dmi_scan_machine() or dmi_init() is called.


No. Not must, rather should. See below.



Oh, and this wasn't even my point ;-) I'm fine with you checking if
firmware_kobj is defined. My question was about the dmi_available check
above. But that question was silly anyway, sorry. I confused
dmi_available with dmi_initialized. Checking for dmi_available is
perfectly reasonable, please scratch my objection.


And if I call it from dmi_init() I suppose
I would face an error. As I can't call it in dmi_init I can't be 
sure that
DMI is available at all. So, no, we have to check dmi_available here 
and

call it at subsys layer, where it's supposed to be.

I can't parse that, I suspect you wrote dmi_init where you actually
meant dmi_scan_machine? Given how early firmware_kobj is created, I
think the code currently in dmi_init could in fact go at the end of
dmi_scan_machine.


Actually, dmi_scan_machine can be called even earlier.
As I've sad, for x86, it's called before firmware_kobj is created.

kernel_start()
setup_arch()
dmi_scan_machine()

And for firmware_init(), as you noticed already:

start_kernel()
rest_init()
kernel_init()
kernel_init_freeable()
do_basic_setup()
driver_init()
firmware_init()

Pay attentions that setup_arch() is called much earlier than rest_init().
So dmi_init couldn't in fact go at the end of dmi_scan_machine.


But it's not important for the time being, this can be
attempted later.


(...)
+kobject_del(dmi_kobj);
+kobject_put(dmi_kobj);
+dmi_kobj = NULL;

I'm wondering, wouldn't it make sense to keep dmi_kobj alive (with an
appropriate comment), so that dmi-sysfs has a chance to load? As it is
now, a bug or some unexpected behavior in this new code could cause a
regression for dmi-sysfs users. Just because I don't like dmi_sysfs
doesn't mean we can break it ;-)

As I remember it was not so critical for you last time.
"I don't care which way you choose". And I've explained my position.
But it's not very hard to me to change it. Anyway patch requires 
re-push.

You're right, I did not remember we had discussed this already,
sorry :-(

Well, I still agree that it doesn't really matter, but of two acceptable
solutions for an event which will most likely never happen, why not go
for the ones with the fewer lines of code? ;-)


Ok.


--
Regards,
Ivan Khoronzhuk

--
To un

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

Hi Jean,

On 16.04.15 12:52, Jean Delvare wrote:

Hi Ivan,

On Thu,  2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi/tables and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.

Signed-off-by: Ivan Khoronzhuk 
---
  .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
  drivers/firmware/dmi-sysfs.c   | 11 ++-
  drivers/firmware/dmi_scan.c| 80 ++
  include/linux/dmi.h|  1 +
  4 files changed, 107 insertions(+), 7 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables

First of all: thanks for doing this, it looks mostly good now, and I've
tested it successfully on my own system.


diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables 
b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
new file mode 100644
index 000..f46158c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
@@ -0,0 +1,22 @@
+What:  /sys/firmware/dmi/tables/
+Date:  April 2015
+Contact:   Ivan Khoronzhuk 
+Description:
+   The firmware provides DMI structures as a packed list of
+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   The format of SMBIOS entry point, equal as DMI structures
+   can be read in SMBIOS specification.

"equal as" sounds strange, I think a simple "and" would be better.


Ok




+
+   The dmi/tables provides raw SMBIOS entry point and DMI tables
+   through sysfs as an alternative to utilities reading them
+   from /dev/mem. The raw SMBIOS entry point and DMI table are
+   presented as raw attributes and are accessible via:

"binary attributes" rather than "raw attributes"? The "raw" nature is
already mentioned earlier in the sentence.


Ok




+
+   /sys/firmware/dmi/tables/smbios_entry_point
+   /sys/firmware/dmi/tables/DMI
+
+   The complete DMI information can be taken using these two

"obtained" or "decoded" would sound better than "taken" IMHO.


Ok




+   tables.
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index e0f1cb3..8e1a411 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
.default_attrs = dmi_sysfs_entry_attrs,
  };
  
-static struct kobject *dmi_kobj;

  static struct kset *dmi_kset;
  
  /* Global count of all instances seen.  Only for setup */

@@ -651,10 +650,11 @@ static int __init dmi_sysfs_init(void)
int error = -ENOMEM;

This initialization can be moved to the single error path left that
needs it. (I can do it myself in a separate patch if you don't want to
do it here.)


Let it be in this patch.


int val;
  
-	/* Set up our directory */

-   dmi_kobj = kobject_create_and_add("dmi", firmware_kobj);
-   if (!dmi_kobj)
+   if (!dmi_kobj) {
+   pr_err("dmi-sysfs: dmi entry is absent.\n");
+   error = -ENOSYS;
goto err;
+   }
  
  	dmi_kset = kset_create_and_add("entries", NULL, dmi_kobj);

if (!dmi_kset)
@@ -675,7 +675,6 @@ static int __init dmi_sysfs_init(void)
  err:
cleanup_entry_list();
kset_unregister(dmi_kset);
-   kobject_put(dmi_kobj);
return error;
  }
  
@@ -685,8 +684,6 @@ static void __exit dmi_sysfs_exit(void)

pr_debug("dmi-sysfs: unloading.\n");
cleanup_entry_list();
kset_unregister(dmi_kset);
-   kobject_del(dmi_kobj);
-   kobject_put(dmi_kobj);
  }
  
  module_init(dmi_sysfs_init);

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d3aae09..bb19f8b 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -10,6 +10,9 @@
  #include 
  #include 
  
+struct kobject *dmi_kobj;

+EXPORT_SYMBOL_GPL(dmi_kobj);
+
  /*
   * DMI stands for "Desktop Management Interface".  It is part
   * of and an antecedent to, SMBIOS, which stands for System
@@ -20,6 +23,9 @@ static const char dmi_empty_string[] = "";
  static u32 dmi_ver __initdata;
  static u32 dmi_len;
  static u16 

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

Hi Jean,

On 16.04.15 12:52, Jean Delvare wrote:

Hi Ivan,

On Thu,  2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi/tables and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---
  .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
  drivers/firmware/dmi-sysfs.c   | 11 ++-
  drivers/firmware/dmi_scan.c| 80 ++
  include/linux/dmi.h|  1 +
  4 files changed, 107 insertions(+), 7 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables

First of all: thanks for doing this, it looks mostly good now, and I've
tested it successfully on my own system.


diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables 
b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
new file mode 100644
index 000..f46158c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
@@ -0,0 +1,22 @@
+What:  /sys/firmware/dmi/tables/
+Date:  April 2015
+Contact:   Ivan Khoronzhuk ivan.khoronz...@globallogic.com
+Description:
+   The firmware provides DMI structures as a packed list of
+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   The format of SMBIOS entry point, equal as DMI structures
+   can be read in SMBIOS specification.

equal as sounds strange, I think a simple and would be better.


Ok




+
+   The dmi/tables provides raw SMBIOS entry point and DMI tables
+   through sysfs as an alternative to utilities reading them
+   from /dev/mem. The raw SMBIOS entry point and DMI table are
+   presented as raw attributes and are accessible via:

binary attributes rather than raw attributes? The raw nature is
already mentioned earlier in the sentence.


Ok




+
+   /sys/firmware/dmi/tables/smbios_entry_point
+   /sys/firmware/dmi/tables/DMI
+
+   The complete DMI information can be taken using these two

obtained or decoded would sound better than taken IMHO.


Ok




+   tables.
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index e0f1cb3..8e1a411 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
.default_attrs = dmi_sysfs_entry_attrs,
  };
  
-static struct kobject *dmi_kobj;

  static struct kset *dmi_kset;
  
  /* Global count of all instances seen.  Only for setup */

@@ -651,10 +650,11 @@ static int __init dmi_sysfs_init(void)
int error = -ENOMEM;

This initialization can be moved to the single error path left that
needs it. (I can do it myself in a separate patch if you don't want to
do it here.)


Let it be in this patch.


int val;
  
-	/* Set up our directory */

-   dmi_kobj = kobject_create_and_add(dmi, firmware_kobj);
-   if (!dmi_kobj)
+   if (!dmi_kobj) {
+   pr_err(dmi-sysfs: dmi entry is absent.\n);
+   error = -ENOSYS;
goto err;
+   }
  
  	dmi_kset = kset_create_and_add(entries, NULL, dmi_kobj);

if (!dmi_kset)
@@ -675,7 +675,6 @@ static int __init dmi_sysfs_init(void)
  err:
cleanup_entry_list();
kset_unregister(dmi_kset);
-   kobject_put(dmi_kobj);
return error;
  }
  
@@ -685,8 +684,6 @@ static void __exit dmi_sysfs_exit(void)

pr_debug(dmi-sysfs: unloading.\n);
cleanup_entry_list();
kset_unregister(dmi_kset);
-   kobject_del(dmi_kobj);
-   kobject_put(dmi_kobj);
  }
  
  module_init(dmi_sysfs_init);

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d3aae09..bb19f8b 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -10,6 +10,9 @@
  #include asm/dmi.h
  #include asm/unaligned.h
  
+struct kobject *dmi_kobj;

+EXPORT_SYMBOL_GPL(dmi_kobj);
+
  /*
   * DMI stands for Desktop Management Interface.  It is part
   * of and an antecedent to, SMBIOS, which stands for System
@@ -20,6 +23,9 @@ static const char dmi_empty_string[] = ;
  static 

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

Sorry, sent it from not original mail.

On 16.04.15 20:27, subscivan wrote:

Jean,

On 16.04.15 18:44, Jean Delvare wrote:

Hi Ivan,

Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :

On 16.04.15 12:52, Jean Delvare wrote:

On Thu,  2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:
+static BIN_ATTR(smbios_entry_point, S_IRUSR, raw_table_read, 
NULL, 0);

This one could be world-readable as it contains no sensitive
information.

It contains the address of DMI table containing sensitive information.
Who knows which ways can be used to take it. Anyway, no see reasons 
in this

w/o DMI table. But if you insist I can do it world-readable.

OK, you convinced me.


+struct bin_attribute bin_attr_dmi_table =
+__BIN_ATTR(DMI, S_IRUSR, raw_table_read, NULL, 0);
I do not understand why you don't use BIN_ATTR here too? I tried 
naming

the attribute bin_attr_DMI and it seems to work just fine, checkpatch
doesn't even complain!

I dislike upper case in names, at least in such simple names.
It makes me using bin_attr_DMI lower in the code. That's why.
But if you like it, I will name it bin_attr_DMI

I don't like upper case in names either, but in this specific case, I'd
do it for consistency. As you wish though, I really only wanted to know
the reason.


+
+static int __init dmi_init(void)
+{
+int ret = -ENOMEM;
+struct kobject *tables_kobj = NULL;
+
+if (!dmi_available) {
+ret = -ENOSYS;
+goto err;
+}

This is weird. Can this actually happen?

We currently have two ways to enter this module: dmi_scan_machine(),
which is called by the architecture code, and dmi_init(), which is
called at subsys_initcall time. As far as I can see,
core/arch_initcalls are guaranteed to be always called before
subsys_initcalls. If we can rely on that, the test above is not 
needed.

If for any reason we can't, that means that dmi_init() should not be a
subsys_initcall, but should instead be called explicitly at the end of
dmi_scan_machine().

We cannot be sure that firmware_kobj created at time of dmi_init().
The sources don't oblige you to call it at core level,
for instance like it was done for arm64. For x86, dmi_init() can be 
called

before firmware_kobj is created.

Looking at the code, it seems that firmware_kobj is created very, very
early in the boot process. In do_basic_setup(), you can see that
driver_init() (which in turn calls firmware_init(), creating
firmware_kobj) is called before do_initcalls(). So firmware_kobj must be
defined before dmi_scan_machine() or dmi_init() is called.


No. Not must, rather should. See below.



Oh, and this wasn't even my point ;-) I'm fine with you checking if
firmware_kobj is defined. My question was about the dmi_available check
above. But that question was silly anyway, sorry. I confused
dmi_available with dmi_initialized. Checking for dmi_available is
perfectly reasonable, please scratch my objection.


And if I call it from dmi_init() I suppose
I would face an error. As I can't call it in dmi_init I can't be 
sure that
DMI is available at all. So, no, we have to check dmi_available here 
and

call it at subsys layer, where it's supposed to be.

I can't parse that, I suspect you wrote dmi_init where you actually
meant dmi_scan_machine? Given how early firmware_kobj is created, I
think the code currently in dmi_init could in fact go at the end of
dmi_scan_machine.


Actually, dmi_scan_machine can be called even earlier.
As I've sad, for x86, it's called before firmware_kobj is created.

kernel_start()
setup_arch()
dmi_scan_machine()

And for firmware_init(), as you noticed already:

start_kernel()
rest_init()
kernel_init()
kernel_init_freeable()
do_basic_setup()
driver_init()
firmware_init()

Pay attentions that setup_arch() is called much earlier than rest_init().
So dmi_init couldn't in fact go at the end of dmi_scan_machine.


But it's not important for the time being, this can be
attempted later.


(...)
+kobject_del(dmi_kobj);
+kobject_put(dmi_kobj);
+dmi_kobj = NULL;

I'm wondering, wouldn't it make sense to keep dmi_kobj alive (with an
appropriate comment), so that dmi-sysfs has a chance to load? As it is
now, a bug or some unexpected behavior in this new code could cause a
regression for dmi-sysfs users. Just because I don't like dmi_sysfs
doesn't mean we can break it ;-)

As I remember it was not so critical for you last time.
I don't care which way you choose. And I've explained my position.
But it's not very hard to me to change it. Anyway patch requires 
re-push.

You're right, I did not remember we had discussed this already,
sorry :-(

Well, I still agree that it doesn't really matter, but of two acceptable
solutions for an event which will most likely never happen, why not go
for the ones with the fewer lines of code? ;-)


Ok.


--
Regards,
Ivan Khoronzhuk

--
To unsubscribe from this list: send the line

Re: [Patch 1/3] firmware: dmi_scan: rename dmi_table to dmi_decode_table

[Ivan.khoronzhuk]

Hi Jean,

On 16.04.15 11:35, Jean Delvare wrote:

Hi Matt,

On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:

On Thu, 02 Apr, at 03:57:01PM, Ivan Khoronzhuk wrote:

The dmi_table function looks like data instance, but it does DMI
table decode. This patch renames it to dmi_decode_table name as
more appropriate. That allows us to use dmi_table name for correct
purposes.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---
  drivers/firmware/dmi_scan.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

Looks good to me.

Jean, do you want me to pick this patch up or are you going to?

Good question, we need to agree on a strategy.

There are 3 patch sets to consider here.

1* My patch fixing the UUID ordering bug. It must go in first and
immediately, as it fixes a regression and will have to be backported
to stable branches.


||
V



2* 2 older patches from Ivan which are currently in your efi-next tree
if I'm not mistaken. Both were based on an old tree so they do not
apply cleanly on kernel v4.0, I had to fix them up manually. I have


They are in master tree already.


no idea if git would be able to merge them properly, as the fix
above changed the context even more.


Current efi-next already merged, so you should base your patches on
top of last changes.



3* The 3 new patches from Ivan which I am reviewing now, which are not
applied in any public tree AFAIK.


It shouldn't happen,
I've been verifying just now once again.
They are applied on top of linux_next cleanly.
Equal as on efi/next.



I don't really care who picks these patches up and sends them to Linus,
but I think they should all follow the same route so that Linus has as
little merge work to do as possible. So either you pick them all, or I
do. If I do, you'll have to drop the 2 patches you have in efi-next.
Again I'm fine either way, so please let me know what makes your life
easier and let's do that.

Thanks,


Jean,
I'm going to base my series
firmware: dmi_scan: add SBMIOS entry point and DMI tables
on top of linux next unless you have already your tree to pick up changes.
Please let me know, if you have one.


--
Regards,
Ivan Khoronzhuk

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

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

On 02.04.15 15:57, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi/tables and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.

Signed-off-by: Ivan Khoronzhuk 
---
  .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
  drivers/firmware/dmi-sysfs.c   | 11 ++-
  drivers/firmware/dmi_scan.c| 80 ++
  include/linux/dmi.h|  1 +
  4 files changed, 107 insertions(+), 7 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables 
b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
new file mode 100644
index 000..f46158c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
@@ -0,0 +1,22 @@
+What:  /sys/firmware/dmi/tables/
+Date:  April 2015
+Contact:   Ivan Khoronzhuk 
+Description:
+   The firmware provides DMI structures as a packed list of
+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   The format of SMBIOS entry point, equal as DMI structures
+   can be read in SMBIOS specification.
+
+   The dmi/tables provides raw SMBIOS entry point and DMI tables
+   through sysfs as an alternative to utilities reading them
+   from /dev/mem. The raw SMBIOS entry point and DMI table are
+   presented as raw attributes and are accessible via:
+
+   /sys/firmware/dmi/tables/smbios_entry_point
+   /sys/firmware/dmi/tables/DMI
+
+   The complete DMI information can be taken using these two
+   tables.
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index e0f1cb3..8e1a411 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
.default_attrs = dmi_sysfs_entry_attrs,
  };
  
-static struct kobject *dmi_kobj;

  static struct kset *dmi_kset;
  
  /* Global count of all instances seen.  Only for setup */

@@ -651,10 +650,11 @@ static int __init dmi_sysfs_init(void)
int error = -ENOMEM;
int val;
  
-	/* Set up our directory */

-   dmi_kobj = kobject_create_and_add("dmi", firmware_kobj);
-   if (!dmi_kobj)
+   if (!dmi_kobj) {
+   pr_err("dmi-sysfs: dmi entry is absent.\n");
+   error = -ENOSYS;
goto err;
+   }
  
  	dmi_kset = kset_create_and_add("entries", NULL, dmi_kobj);

if (!dmi_kset)
@@ -675,7 +675,6 @@ static int __init dmi_sysfs_init(void)
  err:
cleanup_entry_list();
kset_unregister(dmi_kset);
-   kobject_put(dmi_kobj);
return error;
  }
  
@@ -685,8 +684,6 @@ static void __exit dmi_sysfs_exit(void)

pr_debug("dmi-sysfs: unloading.\n");
cleanup_entry_list();
kset_unregister(dmi_kset);
-   kobject_del(dmi_kobj);
-   kobject_put(dmi_kobj);
  }
  
  module_init(dmi_sysfs_init);

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d3aae09..bb19f8b 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -10,6 +10,9 @@
  #include 
  #include 
  
+struct kobject *dmi_kobj;

+EXPORT_SYMBOL_GPL(dmi_kobj);
+
  /*
   * DMI stands for "Desktop Management Interface".  It is part
   * of and an antecedent to, SMBIOS, which stands for System
@@ -20,6 +23,9 @@ static const char dmi_empty_string[] = "";
  static u32 dmi_ver __initdata;
  static u32 dmi_len;
  static u16 dmi_num;
+static u8 smbios_entry_point[32];
+static int smbios_entry_point_size;
+
  /*
   * Catch too early calls to dmi_check_system():
   */
@@ -118,6 +124,7 @@ static void dmi_decode_table(u8 *buf,
  }
  
  static phys_addr_t dmi_base;

+static u8 *dmi_table;
  
  static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,

void *))
@@ -476,6 +483,8 @@ static int __init dmi_present(const u8 *buf)
if (memcmp(buf, "_SM_", 4) == 0 &&
buf[5] < 32 && dmi_checksum(buf, buf[5])) {
smbios_ver = get_unaligned_be16(buf + 6);
+   smbios_entry_point_size = buf[5];
+ 

Re: [Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs

[Ivan.khoronzhuk]

+ Roy

On 02.04.15 18:08, Jean Delvare wrote:

Le Thursday 02 April 2015 à 16:02 +0300, Ivan.khoronzhuk a écrit :

Hi Jean,
Sorry for the late reply.
I've send new series
"[Patch 0/3] firmware: dmi_scan: add SBMIOS entry point and DMI tables"
with all last propositions.

Thanks Ivan, no problem. I'll look at it when I have time.

Two related notes:

* On week from April 13th to 17th, this is Hack Week 12 at SUSE. This
time I decided to work on dmidecode. I plan to add full support for
SMBIOS 3.0.0, including the new entry point format. Then I'll work on
integrating your work (the sysfs interface.) Project page:

https://hackweek.suse.com/12/projects/766

If you or anyone else want to participate, you are very welcome. Ideally
we would release dmidecode 2.13 at the end of that week.

* Do you know of any hardware already implementing SMBIOS 3.0 (either
the new entry point format, or the new enumerated values, or both)?
Having a real-world example would make testing much easier.

Thanks,


--
Regards,
Ivan Khoronzhuk

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

Re: [Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs

[Ivan.khoronzhuk]

+ Roy

On 02.04.15 18:08, Jean Delvare wrote:

Le Thursday 02 April 2015 à 16:02 +0300, Ivan.khoronzhuk a écrit :

Hi Jean,
Sorry for the late reply.
I've send new series
[Patch 0/3] firmware: dmi_scan: add SBMIOS entry point and DMI tables
with all last propositions.

Thanks Ivan, no problem. I'll look at it when I have time.

Two related notes:

* On week from April 13th to 17th, this is Hack Week 12 at SUSE. This
time I decided to work on dmidecode. I plan to add full support for
SMBIOS 3.0.0, including the new entry point format. Then I'll work on
integrating your work (the sysfs interface.) Project page:

https://hackweek.suse.com/12/projects/766

If you or anyone else want to participate, you are very welcome. Ideally
we would release dmidecode 2.13 at the end of that week.

* Do you know of any hardware already implementing SMBIOS 3.0 (either
the new entry point format, or the new enumerated values, or both)?
Having a real-world example would make testing much easier.

Thanks,


--
Regards,
Ivan Khoronzhuk

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

Re: [Patch 2/3] firmware: dmi_scan: add SBMIOS entry and DMI tables

[Ivan.khoronzhuk]

On 02.04.15 15:57, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi/tables and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as
proposed by Jean Delvare.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---
  .../ABI/testing/sysfs-firmware-dmi-tables  | 22 ++
  drivers/firmware/dmi-sysfs.c   | 11 ++-
  drivers/firmware/dmi_scan.c| 80 ++
  include/linux/dmi.h|  1 +
  4 files changed, 107 insertions(+), 7 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-tables

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi-tables 
b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
new file mode 100644
index 000..f46158c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi-tables
@@ -0,0 +1,22 @@
+What:  /sys/firmware/dmi/tables/
+Date:  April 2015
+Contact:   Ivan Khoronzhuk ivan.khoronz...@globallogic.com
+Description:
+   The firmware provides DMI structures as a packed list of
+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   The format of SMBIOS entry point, equal as DMI structures
+   can be read in SMBIOS specification.
+
+   The dmi/tables provides raw SMBIOS entry point and DMI tables
+   through sysfs as an alternative to utilities reading them
+   from /dev/mem. The raw SMBIOS entry point and DMI table are
+   presented as raw attributes and are accessible via:
+
+   /sys/firmware/dmi/tables/smbios_entry_point
+   /sys/firmware/dmi/tables/DMI
+
+   The complete DMI information can be taken using these two
+   tables.
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index e0f1cb3..8e1a411 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -566,7 +566,6 @@ static struct kobj_type dmi_sysfs_entry_ktype = {
.default_attrs = dmi_sysfs_entry_attrs,
  };
  
-static struct kobject *dmi_kobj;

  static struct kset *dmi_kset;
  
  /* Global count of all instances seen.  Only for setup */

@@ -651,10 +650,11 @@ static int __init dmi_sysfs_init(void)
int error = -ENOMEM;
int val;
  
-	/* Set up our directory */

-   dmi_kobj = kobject_create_and_add(dmi, firmware_kobj);
-   if (!dmi_kobj)
+   if (!dmi_kobj) {
+   pr_err(dmi-sysfs: dmi entry is absent.\n);
+   error = -ENOSYS;
goto err;
+   }
  
  	dmi_kset = kset_create_and_add(entries, NULL, dmi_kobj);

if (!dmi_kset)
@@ -675,7 +675,6 @@ static int __init dmi_sysfs_init(void)
  err:
cleanup_entry_list();
kset_unregister(dmi_kset);
-   kobject_put(dmi_kobj);
return error;
  }
  
@@ -685,8 +684,6 @@ static void __exit dmi_sysfs_exit(void)

pr_debug(dmi-sysfs: unloading.\n);
cleanup_entry_list();
kset_unregister(dmi_kset);
-   kobject_del(dmi_kobj);
-   kobject_put(dmi_kobj);
  }
  
  module_init(dmi_sysfs_init);

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d3aae09..bb19f8b 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -10,6 +10,9 @@
  #include asm/dmi.h
  #include asm/unaligned.h
  
+struct kobject *dmi_kobj;

+EXPORT_SYMBOL_GPL(dmi_kobj);
+
  /*
   * DMI stands for Desktop Management Interface.  It is part
   * of and an antecedent to, SMBIOS, which stands for System
@@ -20,6 +23,9 @@ static const char dmi_empty_string[] = ;
  static u32 dmi_ver __initdata;
  static u32 dmi_len;
  static u16 dmi_num;
+static u8 smbios_entry_point[32];
+static int smbios_entry_point_size;
+
  /*
   * Catch too early calls to dmi_check_system():
   */
@@ -118,6 +124,7 @@ static void dmi_decode_table(u8 *buf,
  }
  
  static phys_addr_t dmi_base;

+static u8 *dmi_table;
  
  static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,

void *))
@@ -476,6 +483,8 @@ static int __init dmi_present(const u8 *buf)
if (memcmp(buf, _SM_, 4) == 0 
buf[5]  32  dmi_checksum(buf, buf[5])) {
smbios_ver = 

Re: [Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs

[Ivan.khoronzhuk]

Hi Jean,
Sorry for the late reply.
I've send new series
"[Patch 0/3] firmware: dmi_scan: add SBMIOS entry point and DMI tables"
with all last propositions.

On 20.03.15 10:16, Jean Delvare wrote:

Hi Ivan,

On Thu, 19 Mar 2015 19:35:34 +0200, Ivan.khoronzhuk wrote:

On 19.03.15 17:30, Jean Delvare wrote:

Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi subsystem and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as were
proposed by Jean Delvare.

"as was proposed" or even "as proposed" sounds more correct.

BTW, which tree is your patch based on? I can't get it to apply cleanly
on top of any kernel version I tried. I adjusted the patch to my tree
but it means I'm not reviewing your code exactly. Please send patches
which can be applied on top of some recent vanilla tree (3.19 or 4.0-rc4
would be OK at the moment.)

Oh, sorry I forgot to mention, it's based on efi/next, but with consumption
that Matt will remove old version:
   85c83ea firmware: dmi-sysfs: Add SMBIOS entry point area attribute

As you remember, your propositions were slightly late,
and patch had been applied on efi/next when you commented.

OK, I understand. Now I see the two patches I was missing, I'll pick
them so that I can apply your patch cleanly on top of my tree.

I would have appreciated to be Cc'd on these two patches, so I knew
they existed, and maybe I could even have commented on them.


(...)
@@ -118,6 +124,7 @@ static void dmi_table(u8 *buf,
   }
   
   static phys_addr_t dmi_base;

+static u8 *dmi_tb;

Where "tb" stands for... "table", but you couldn't use that because a
function by that name already exist, right? I can think of two less
cryptic ways to solve this: either you rename function dmi_table to,
say, dmi_decode_table (which would be a better name anyway IMHO), or you
name your variable dmi_table_p or dmi_raw_table. But "tb" is not
immediate enough to understand.

If others are OK, I'll better rename dmi_table function to
dmi_decode_table()
(or maybe dmidecode_table :), joke)
as it's more appropriate to what it's doing.
And accordingly dmi_tb to dmi_table.

Yes, that's fine with me. The function rename should be a separate
patch for clarity.


(...)
   static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,
void *))
@@ -476,6 +483,8 @@ static int __init dmi_present(const u8 *buf)
if (memcmp(buf, "_SM_", 4) == 0 &&
buf[5] < 32 && dmi_checksum(buf, buf[5])) {
smbios_ver = get_unaligned_be16(buf + 6);
+   smbios_entry_point_size = buf[5];
+   memcpy(smbios_entry_point, buf, smbios_entry_point_size);
   
   		/* Some BIOS report weird SMBIOS version, fix that up */

switch (smbios_ver) {
@@ -508,6 +517,8 @@ static int __init dmi_present(const u8 *buf)
dmi_ver >> 8, dmi_ver & 0xFF,
(dmi_ver < 0x0300) ? "" : ".x");
} else {
+   smbios_entry_point_size = 15;
+   memcpy(smbios_entry_point, buf, 15);
dmi_ver = (buf[14] & 0xF0) << 4 |
   (buf[14] & 0x0F);
pr_info("Legacy DMI %d.%d present.\n",
@@ -535,6 +546,8 @@ static int __init dmi_smbios3_present(const u8 *buf)
dmi_ver &= 0xFF;
dmi_len = get_unaligned_le32(buf + 12);
dmi_base = get_unaligned_le64(buf + 16);
+   smbios_entry_point_size = buf[6];
+   memcpy(smbios_entry_point, buf, smbios_entry_point_size);
   
   		/*

 * The 64-bit SMBIOS 3.0 entry point no longer has a field

This is inconsistent. You should either use smbios_entry_point_size as
the last argument to memcpy() in all 3 cases (my preference), or you
should use buf[5], 15 and buf[6] respectively, but not mix.

You probably meant "memcpy(smbios_entry_point, buf, 15)"

Yes.


Just wanted to avoid redundant line break.

Line breaks are just fine, code consistency is more important.


(...)
+   if (!smbios_entry_point_size || !dmi_available) {

I already mentioned in a previous review that I don't think you need to
check for !dmi_available, and you sa

Re: [Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs

[Ivan.khoronzhuk]

Hi Jean,
Sorry for the late reply.
I've send new series
[Patch 0/3] firmware: dmi_scan: add SBMIOS entry point and DMI tables
with all last propositions.

On 20.03.15 10:16, Jean Delvare wrote:

Hi Ivan,

On Thu, 19 Mar 2015 19:35:34 +0200, Ivan.khoronzhuk wrote:

On 19.03.15 17:30, Jean Delvare wrote:

Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi subsystem and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as were
proposed by Jean Delvare.

as was proposed or even as proposed sounds more correct.

BTW, which tree is your patch based on? I can't get it to apply cleanly
on top of any kernel version I tried. I adjusted the patch to my tree
but it means I'm not reviewing your code exactly. Please send patches
which can be applied on top of some recent vanilla tree (3.19 or 4.0-rc4
would be OK at the moment.)

Oh, sorry I forgot to mention, it's based on efi/next, but with consumption
that Matt will remove old version:
   85c83ea firmware: dmi-sysfs: Add SMBIOS entry point area attribute

As you remember, your propositions were slightly late,
and patch had been applied on efi/next when you commented.

OK, I understand. Now I see the two patches I was missing, I'll pick
them so that I can apply your patch cleanly on top of my tree.

I would have appreciated to be Cc'd on these two patches, so I knew
they existed, and maybe I could even have commented on them.


(...)
@@ -118,6 +124,7 @@ static void dmi_table(u8 *buf,
   }
   
   static phys_addr_t dmi_base;

+static u8 *dmi_tb;

Where tb stands for... table, but you couldn't use that because a
function by that name already exist, right? I can think of two less
cryptic ways to solve this: either you rename function dmi_table to,
say, dmi_decode_table (which would be a better name anyway IMHO), or you
name your variable dmi_table_p or dmi_raw_table. But tb is not
immediate enough to understand.

If others are OK, I'll better rename dmi_table function to
dmi_decode_table()
(or maybe dmidecode_table :), joke)
as it's more appropriate to what it's doing.
And accordingly dmi_tb to dmi_table.

Yes, that's fine with me. The function rename should be a separate
patch for clarity.


(...)
   static int __init dmi_walk_early(void (*decode)(const struct dmi_header *,
void *))
@@ -476,6 +483,8 @@ static int __init dmi_present(const u8 *buf)
if (memcmp(buf, _SM_, 4) == 0 
buf[5]  32  dmi_checksum(buf, buf[5])) {
smbios_ver = get_unaligned_be16(buf + 6);
+   smbios_entry_point_size = buf[5];
+   memcpy(smbios_entry_point, buf, smbios_entry_point_size);
   
   		/* Some BIOS report weird SMBIOS version, fix that up */

switch (smbios_ver) {
@@ -508,6 +517,8 @@ static int __init dmi_present(const u8 *buf)
dmi_ver  8, dmi_ver  0xFF,
(dmi_ver  0x0300) ?  : .x);
} else {
+   smbios_entry_point_size = 15;
+   memcpy(smbios_entry_point, buf, 15);
dmi_ver = (buf[14]  0xF0)  4 |
   (buf[14]  0x0F);
pr_info(Legacy DMI %d.%d present.\n,
@@ -535,6 +546,8 @@ static int __init dmi_smbios3_present(const u8 *buf)
dmi_ver = 0xFF;
dmi_len = get_unaligned_le32(buf + 12);
dmi_base = get_unaligned_le64(buf + 16);
+   smbios_entry_point_size = buf[6];
+   memcpy(smbios_entry_point, buf, smbios_entry_point_size);
   
   		/*

 * The 64-bit SMBIOS 3.0 entry point no longer has a field

This is inconsistent. You should either use smbios_entry_point_size as
the last argument to memcpy() in all 3 cases (my preference), or you
should use buf[5], 15 and buf[6] respectively, but not mix.

You probably meant memcpy(smbios_entry_point, buf, 15)

Yes.


Just wanted to avoid redundant line break.

Line breaks are just fine, code consistency is more important.


(...)
+   if (!smbios_entry_point_size || !dmi_available) {

I already mentioned in a previous review that I don't think you need to
check for !dmi_available, and you said you agreed.

No.
Previously only smbios entry point was exported.
Now DMI table was added.
smbios_entry_point_size doesn't mean DMI table is present.

Thanks for the explanation, I understand the reasoning now

Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute

[Ivan.khoronzhuk]

On 26.03.15 15:05, Matt Fleming wrote:

On Mon, 16 Mar, at 11:02:29PM, Ivan.khoronzhuk wrote:

Matt, I've sent new patch that replaces this one.
"[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs"
It can take a while to go via review.

OK, thanks Ivan. I've dropped commit ("firmware: dmi-sysfs: Add SMBIOS
entry point area attribute").

The two remaining DMI commits I have are,

   59d7e3c02860 firmware: dmi_scan: Use direct access to static vars
   d759d96eb5cc firmware: dmi_scan: Use full dmi version for SMBIOS3

Am I still sending those for v4.1?



Yes

--
Regards,
Ivan Khoronzhuk

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

Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute

[Ivan.khoronzhuk]

On 26.03.15 15:05, Matt Fleming wrote:

On Mon, 16 Mar, at 11:02:29PM, Ivan.khoronzhuk wrote:

Matt, I've sent new patch that replaces this one.
[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs
It can take a while to go via review.

OK, thanks Ivan. I've dropped commit (firmware: dmi-sysfs: Add SMBIOS
entry point area attribute).

The two remaining DMI commits I have are,

   59d7e3c02860 firmware: dmi_scan: Use direct access to static vars
   d759d96eb5cc firmware: dmi_scan: Use full dmi version for SMBIOS3

Am I still sending those for v4.1?



Yes

--
Regards,
Ivan Khoronzhuk

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

Re: [Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs

[Ivan.khoronzhuk]

On 19.03.15 17:30, Jean Delvare wrote:

Hi Ivan,

Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi subsystem and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as were
proposed by Jean Delvare.

"as was proposed" or even "as proposed" sounds more correct.

BTW, which tree is your patch based on? I can't get it to apply cleanly
on top of any kernel version I tried. I adjusted the patch to my tree
but it means I'm not reviewing your code exactly. Please send patches
which can be applied on top of some recent vanilla tree (3.19 or 4.0-rc4
would be OK at the moment.)


Oh, sorry I forgot to mention, it's based on efi/next, but with consumption
that Matt will remove old version:
 85c83ea firmware: dmi-sysfs: Add SMBIOS entry point area attribute

As you remember, your propositions were slightly late,
and patch had been applied on efi/next when you commented.

Matt, Could you please remove old version.
I hope it will be replaced by new one.


Signed-off-by: Ivan Khoronzhuk 
---

This patch is logical continuation of
"[dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area 
attribute"
https://lkml.org/lkml/2015/2/4/475

Pay attention that this includes /sys/firmware/dmi for holding tables instead of
/sys/firmware/dmi/table as were proposed.

Why is that? I proposed /sys/firmware/dmi/tables because the acpi
subsystem puts its own tables in /sys/firmware/acpi/tables. It seemed
reasonable to follow that example for consistency. What is your reason
for doing it differently?


I just like it more instead of catalog/catalog/catalog...
But it's only proposition. Let's it be under tables.




  Documentation/ABI/testing/sysfs-firmware-dmi   | 122 +++--
  .../ABI/testing/sysfs-firmware-dmi-entries | 110 +++

This is adding a lot of noise to your patch, making it harder to review
and backport. If you think that the contents of sysfs-firmware-dmi would
rather go in a documentation file named sysfs-firmware-dmi-entries, I
have no objection, but it should be done in a separate patch.


yes.


  drivers/firmware/dmi-sysfs.c   |  12 +-
  drivers/firmware/dmi_scan.c| 115 +--
  include/linux/dmi.h|   2 +
  5 files changed, 238 insertions(+), 123 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-entries

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi 
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..6413128 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -1,110 +1,16 @@
  What: /sys/firmware/dmi/
-Date:  February 2011
-Contact:   Mike Waychison 
+Date:  March 2015
+Contact:   Ivan Khoronzhuk 
  Description:
(...)
+   The firmware provides DMI structures as a packed list of
+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   That's why SMBIOS entry point is represented in dmi sysfs
+   like a raw attribute and is accessible via
+   /sys/firmware/dmi/smbios_entry_point. The format of SMBIOS
+   entry point header can be read in SMBIOS specification.
+   To simplify access and processing delay in user space,

"processing delay" doesn't really describe the problem that was present
with the previous patch set. It was more a problem of processing time,
CPU and memory usage, and code complexity. Anyway I see no reason to
explain that here, given that this proposal was rejected.

You'd rather just explain that the raw data is provided through sysfs as
an alternative to utilities reading them from /dev/mem (as you already
correctly explain in the patch description.) That's what your new patch
is all about.


yes




+   subsystem provides also raw dmi table under

DMI better spelled capitalized. I'd also avoid mentioning "subsystem",
I'm not sure why you're using that word (and also in the subject), sysfs
is a virtual file system, and there is no such thing as a "dmi


dmi -> DMI.
According subsystem, it was erroneously noticed from efi.c.
It seems confusing to me too, let avoid it.

Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute

[Ivan.khoronzhuk]

On 10.03.15 11:13, Jean Delvare wrote:

Hi Ivan,

Sorry for the late reply. I think I addressed some points in other
replies already, but for completeness let me reply to this post too.

Le Wednesday 04 March 2015 à 14:30 +0200, Ivan.khoronzhuk a écrit :

On 02/26/2015 11:36 AM, Jean Delvare wrote:

On Wed,  4 Feb 2015 19:06:03 +0200, Ivan Khoronzhuk wrote:

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi 
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..3a9ffe8 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -12,6 +12,16 @@ Description:
cannot ensure that the data as exported to userland is
without error either.
   
+		The firmware provides DMI structures as a packed list of

+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   That's why SMBIOS entry point is represented in dmi sysfs
+   like a raw attribute and is accessible via
+   /sys/firmware/dmi/smbios_raw_header. The format of SMBIOS

As mentioned before, I don't like the name "smbios_raw_header". I think
it should be "smbios_entry_point" or similar.

If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.

Great, thanks.


@@ -669,6 +699,18 @@ static int __init dmi_sysfs_init(void)
goto err;
}
   
+	smbios_raw_header = dmi_get_smbios_entry_area();

+   if (!smbios_raw_header) {
+   pr_debug("dmi-sysfs: SMBIOS raw data is not available.\n");
+   error = -EINVAL;
+   goto err;
+   }

I don't think this should have been a fatal error. Just because for
some reason dmi_get_smbios_entry_area() returned NULL is no good reason
for nor exposing /sys/firmware/dmi/entries as we used to.

It issues an error only in case of when entry table is not available,
if entry point is absent then dmi table is not available a fortiori.
So there is no reason to continue from that point.

Well it could also fail because of an error in the code ;-) But OK, I
agree with you here.


But anyway this is no longer relevant if the code is moved to dmi_scan
as I suggested.


+
+   /* Create the raw binary file to access the entry area */
+   smbios_raw_area_attr.size = size;
+   if (sysfs_create_bin_file(dmi_kobj, _raw_area_attr))
+   goto err;

I think this should have had a corresponding call to
sysfs_remove_bin_file() in dmi_sysfs_exit(). (Again no longer relevant
if the code is moved.)

The removing is done in kobject_del().
Doesn't it? In another way it should be done for
dmi/entries/*/raw attributes also.

It _is_ done for other attributes already:

kset_unregister(dmi_kset);

Which is exactly why I believe it should be done for
smbios_raw_area_attr too. All other kernel drivers are calling
sysfs_create_bin_file() or equivalent in their cleanup function and I
see no reason why this driver would be an exception.


kset_unregister() uses kobject_del()
no see difference.




There's one thing I do not understand. I seem to understand that the
goal behind this patch is to be able to run dmidecode without /dev/mem.
Dmidecode currently reads 2 areas from /dev/mem: the 0xF-0xF
area in search of the entry point, and the DMI data table itself. With
this patch you make the entry point available through sysfs. But
dmidecode will still need to access /dev/mem to access the DMI data
table. So that does not really solve anything, does it?

It's supposed to read DMI table via entries presented by dmi-sysfs.
It contains raw attributes that can be used for these purposes.
No need to use /dev/mem.

Yes, I understood this meanwhile, sorry.


Another case if you want to add binary of whole dmi table to be able to
read it directly in order to parse in dmidecode w/o any additional headache
with open/close. Well, it partly dupes currently present dmi-sysfs.

In fact dmi-sysfs already duplicates a lot of code which was already
present in dmidecode and libsmbios. And exporting the raw table will
require way less code than the implementation you proposed originally.
So the code duplication argument doesn't hold, sorry.


But it simplifies dmi table parsing for dmidecode, and who wants to use
dmi-sysfs, let them use it, but dmidecode will be reading raw entry.
Well let it be. Why not.

Yes, this is exactly my point.


If others are OK, for dmidecode, and probably others tools also,
kernel can constantly expose two tables under /sys/firmware/dmi/tables/
smbios_entry_point and dmi_table. Independently on dmi-sysfs.

That's what I would like to see implemented, yes, thank you very much.

Re: [Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs

[Ivan.khoronzhuk]

On 19.03.15 17:30, Jean Delvare wrote:

Hi Ivan,

Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry and adds code/delay redundancy when direct
access for table is needed.

So this patch creates dmi subsystem and adds SMBIOS entry point to allow
utils in question to work correctly without /dev/mem. Also patch adds
raw dmi table to simplify dmi table processing in user space, as were
proposed by Jean Delvare.

as was proposed or even as proposed sounds more correct.

BTW, which tree is your patch based on? I can't get it to apply cleanly
on top of any kernel version I tried. I adjusted the patch to my tree
but it means I'm not reviewing your code exactly. Please send patches
which can be applied on top of some recent vanilla tree (3.19 or 4.0-rc4
would be OK at the moment.)


Oh, sorry I forgot to mention, it's based on efi/next, but with consumption
that Matt will remove old version:
 85c83ea firmware: dmi-sysfs: Add SMBIOS entry point area attribute

As you remember, your propositions were slightly late,
and patch had been applied on efi/next when you commented.

Matt, Could you please remove old version.
I hope it will be replaced by new one.


Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@globallogic.com
---

This patch is logical continuation of
[dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area 
attribute
https://lkml.org/lkml/2015/2/4/475

Pay attention that this includes /sys/firmware/dmi for holding tables instead of
/sys/firmware/dmi/table as were proposed.

Why is that? I proposed /sys/firmware/dmi/tables because the acpi
subsystem puts its own tables in /sys/firmware/acpi/tables. It seemed
reasonable to follow that example for consistency. What is your reason
for doing it differently?


I just like it more instead of catalog/catalog/catalog...
But it's only proposition. Let's it be under tables.




  Documentation/ABI/testing/sysfs-firmware-dmi   | 122 +++--
  .../ABI/testing/sysfs-firmware-dmi-entries | 110 +++

This is adding a lot of noise to your patch, making it harder to review
and backport. If you think that the contents of sysfs-firmware-dmi would
rather go in a documentation file named sysfs-firmware-dmi-entries, I
have no objection, but it should be done in a separate patch.


yes.


  drivers/firmware/dmi-sysfs.c   |  12 +-
  drivers/firmware/dmi_scan.c| 115 +--
  include/linux/dmi.h|   2 +
  5 files changed, 238 insertions(+), 123 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-firmware-dmi-entries

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi 
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..6413128 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -1,110 +1,16 @@
  What: /sys/firmware/dmi/
-Date:  February 2011
-Contact:   Mike Waychison mi...@google.com
+Date:  March 2015
+Contact:   Ivan Khoronzhuk ivan.khoronz...@globallogic.com
  Description:
(...)
+   The firmware provides DMI structures as a packed list of
+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   That's why SMBIOS entry point is represented in dmi sysfs
+   like a raw attribute and is accessible via
+   /sys/firmware/dmi/smbios_entry_point. The format of SMBIOS
+   entry point header can be read in SMBIOS specification.
+   To simplify access and processing delay in user space,

processing delay doesn't really describe the problem that was present
with the previous patch set. It was more a problem of processing time,
CPU and memory usage, and code complexity. Anyway I see no reason to
explain that here, given that this proposal was rejected.

You'd rather just explain that the raw data is provided through sysfs as
an alternative to utilities reading them from /dev/mem (as you already
correctly explain in the patch description.) That's what your new patch
is all about.


yes




+   subsystem provides also raw dmi table under

DMI better spelled capitalized. I'd also avoid mentioning subsystem,
I'm not sure why you're using that word (and also in the subject), sysfs
is a virtual file system, and there is no such thing as a dmi


dmi - DMI.
According subsystem, it was erroneously noticed 

Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute

[Ivan.khoronzhuk]

On 10.03.15 11:13, Jean Delvare wrote:

Hi Ivan,

Sorry for the late reply. I think I addressed some points in other
replies already, but for completeness let me reply to this post too.

Le Wednesday 04 March 2015 à 14:30 +0200, Ivan.khoronzhuk a écrit :

On 02/26/2015 11:36 AM, Jean Delvare wrote:

On Wed,  4 Feb 2015 19:06:03 +0200, Ivan Khoronzhuk wrote:

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi 
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..3a9ffe8 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -12,6 +12,16 @@ Description:
cannot ensure that the data as exported to userland is
without error either.
   
+		The firmware provides DMI structures as a packed list of

+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   That's why SMBIOS entry point is represented in dmi sysfs
+   like a raw attribute and is accessible via
+   /sys/firmware/dmi/smbios_raw_header. The format of SMBIOS

As mentioned before, I don't like the name smbios_raw_header. I think
it should be smbios_entry_point or similar.

If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.

Great, thanks.


@@ -669,6 +699,18 @@ static int __init dmi_sysfs_init(void)
goto err;
}
   
+	smbios_raw_header = dmi_get_smbios_entry_area(size);

+   if (!smbios_raw_header) {
+   pr_debug(dmi-sysfs: SMBIOS raw data is not available.\n);
+   error = -EINVAL;
+   goto err;
+   }

I don't think this should have been a fatal error. Just because for
some reason dmi_get_smbios_entry_area() returned NULL is no good reason
for nor exposing /sys/firmware/dmi/entries as we used to.

It issues an error only in case of when entry table is not available,
if entry point is absent then dmi table is not available a fortiori.
So there is no reason to continue from that point.

Well it could also fail because of an error in the code ;-) But OK, I
agree with you here.


But anyway this is no longer relevant if the code is moved to dmi_scan
as I suggested.


+
+   /* Create the raw binary file to access the entry area */
+   smbios_raw_area_attr.size = size;
+   if (sysfs_create_bin_file(dmi_kobj, smbios_raw_area_attr))
+   goto err;

I think this should have had a corresponding call to
sysfs_remove_bin_file() in dmi_sysfs_exit(). (Again no longer relevant
if the code is moved.)

The removing is done in kobject_del().
Doesn't it? In another way it should be done for
dmi/entries/*/raw attributes also.

It _is_ done for other attributes already:

kset_unregister(dmi_kset);

Which is exactly why I believe it should be done for
smbios_raw_area_attr too. All other kernel drivers are calling
sysfs_create_bin_file() or equivalent in their cleanup function and I
see no reason why this driver would be an exception.


kset_unregister() uses kobject_del()
no see difference.




There's one thing I do not understand. I seem to understand that the
goal behind this patch is to be able to run dmidecode without /dev/mem.
Dmidecode currently reads 2 areas from /dev/mem: the 0xF-0xF
area in search of the entry point, and the DMI data table itself. With
this patch you make the entry point available through sysfs. But
dmidecode will still need to access /dev/mem to access the DMI data
table. So that does not really solve anything, does it?

It's supposed to read DMI table via entries presented by dmi-sysfs.
It contains raw attributes that can be used for these purposes.
No need to use /dev/mem.

Yes, I understood this meanwhile, sorry.


Another case if you want to add binary of whole dmi table to be able to
read it directly in order to parse in dmidecode w/o any additional headache
with open/close. Well, it partly dupes currently present dmi-sysfs.

In fact dmi-sysfs already duplicates a lot of code which was already
present in dmidecode and libsmbios. And exporting the raw table will
require way less code than the implementation you proposed originally.
So the code duplication argument doesn't hold, sorry.


But it simplifies dmi table parsing for dmidecode, and who wants to use
dmi-sysfs, let them use it, but dmidecode will be reading raw entry.
Well let it be. Why not.

Yes, this is exactly my point.


If others are OK, for dmidecode, and probably others tools also,
kernel can constantly expose two tables under /sys/firmware/dmi/tables/
smbios_entry_point and dmi_table. Independently on dmi-sysfs.

That's what I would like to see implemented, yes, thank you very much.



--
Regards,
Ivan Khoronzhuk

Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute

[Ivan.khoronzhuk]

On 12.03.15 14:22, Matt Fleming wrote:

On Tue, 2015-03-10 at 10:13 +0100, Jean Delvare wrote:

If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.

Great, thanks.

Ivan, please go ahead and submit a new version, we've got time to get
this right for v4.1.



Matt, I've sent new patch that replaces this one.
"[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs"
It can take a while to go via review.

--
Regards,
Ivan Khoronzhuk

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

Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute

[Ivan.khoronzhuk]

On 12.03.15 14:22, Matt Fleming wrote:

On Tue, 2015-03-10 at 10:13 +0100, Jean Delvare wrote:

If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.

Great, thanks.

Ivan, please go ahead and submit a new version, we've got time to get
this right for v4.1.



Matt, I've sent new patch that replaces this one.
[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs
It can take a while to go via review.

--
Regards,
Ivan Khoronzhuk

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

Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute

[Ivan.khoronzhuk]

Hi Jean,

On 03/05/2015 09:46 AM, Jean Delvare wrote:

Hi Ivan,

On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote:

On 02/26/2015 11:41 AM, Jean Delvare wrote:

On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:

Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to implement both the old and the new format. It may be
desirable to expose both to user-space under different names.

Having read the kernel code meanwhile, I see we will call either
dmi_smbios3_present or dmi_present successfully, not both, so
presenting both entry points to user-space would be non-trivial. So I'm
fine with presenting only one entry point in sysfs for the time being.
We can always revisit later if it turns out that dmidecode really needs
both in some cases.

Why do you need two tables ? If kernel can parse the best one why
it should present the old one? The old is subset of new, so the new must
contain all required information, only format can be slightly different.
If dmidecode has problems in reading new version then dmidecode should
be modified, not kernel.

It's not just two tables (I don't expect a lot of BIOSes to provide two
tables in practice, and they would have essentially the same format
anyway) but more importantly two entry points. The _SM3_ entry point is
brand new and most applications (including dmidecode) don't support it
yet. It doesn't matter if the kernel itself can parse it, as it passes
the raw entry point to applications anyway.

It happens that we are introducing this new sysfs raw interface at the
same time _SM3_ is being introduced, so we do not have to care about
backwards compatibility. Both the kernel and dmidecode will need to be
updated to support the new interface, so we can keep things simple and
let the kernel expose only the best entry point.

If the sysfs raw interface was already present at the time _SM3_
support was being added, then we would have had to present both entry
points for backwards compatibility. And if some _SM4_ entry point is
ever added in the future with a new format, we will have to export it
as a new sysfs attribute so as to not break compatibility.

As a summary, I agree that a single entry point file is OK for now, but
only because we are lucky that the timing is right.



Despite of timing is right.

The specification doesn't oblige firmware to provide two entry points.
An implementation may provide either the 32-bit entry point or the 64-bit
entry point, or both. For compatibility with existing SMBIOS parsers, an
implementation should provide the 32-bit entry point, but it's not required.

Another case if specification requires to provide two entry points. Then 
you can

be sure in backward compatibility. But at least for now you can't.

It's obvious, if kernel found two entry points then it can create two 
sysfs attributes.

But, what kernel should do in case if only one new entry point is present.
Generate entry point of old version..., sorry but it's bad idea. At 
least because
where guarantee that we have enough information for this. Only field we 
can bring

thought entry point versions is magic string _SM*_, and based on it, if util
don't support new version it can warn. It's used for differ versions and
there is nothing we can do more.

--
Regards,
Ivan Khoronzhuk

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

Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute

[Ivan.khoronzhuk]

Hi Jean,

On 03/05/2015 09:46 AM, Jean Delvare wrote:

Hi Ivan,

On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote:

On 02/26/2015 11:41 AM, Jean Delvare wrote:

On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:

Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to implement both the old and the new format. It may be
desirable to expose both to user-space under different names.

Having read the kernel code meanwhile, I see we will call either
dmi_smbios3_present or dmi_present successfully, not both, so
presenting both entry points to user-space would be non-trivial. So I'm
fine with presenting only one entry point in sysfs for the time being.
We can always revisit later if it turns out that dmidecode really needs
both in some cases.

Why do you need two tables ? If kernel can parse the best one why
it should present the old one? The old is subset of new, so the new must
contain all required information, only format can be slightly different.
If dmidecode has problems in reading new version then dmidecode should
be modified, not kernel.

It's not just two tables (I don't expect a lot of BIOSes to provide two
tables in practice, and they would have essentially the same format
anyway) but more importantly two entry points. The _SM3_ entry point is
brand new and most applications (including dmidecode) don't support it
yet. It doesn't matter if the kernel itself can parse it, as it passes
the raw entry point to applications anyway.

It happens that we are introducing this new sysfs raw interface at the
same time _SM3_ is being introduced, so we do not have to care about
backwards compatibility. Both the kernel and dmidecode will need to be
updated to support the new interface, so we can keep things simple and
let the kernel expose only the best entry point.

If the sysfs raw interface was already present at the time _SM3_
support was being added, then we would have had to present both entry
points for backwards compatibility. And if some _SM4_ entry point is
ever added in the future with a new format, we will have to export it
as a new sysfs attribute so as to not break compatibility.

As a summary, I agree that a single entry point file is OK for now, but
only because we are lucky that the timing is right.



Despite of timing is right.

The specification doesn't oblige firmware to provide two entry points.
An implementation may provide either the 32-bit entry point or the 64-bit
entry point, or both. For compatibility with existing SMBIOS parsers, an
implementation should provide the 32-bit entry point, but it's not required.

Another case if specification requires to provide two entry points. Then 
you can

be sure in backward compatibility. But at least for now you can't.

It's obvious, if kernel found two entry points then it can create two 
sysfs attributes.

But, what kernel should do in case if only one new entry point is present.
Generate entry point of old version..., sorry but it's bad idea. At 
least because
where guarantee that we have enough information for this. Only field we 
can bring

thought entry point versions is magic string _SM*_, and based on it, if util
don't support new version it can warn. It's used for differ versions and
there is nothing we can do more.

--
Regards,
Ivan Khoronzhuk

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

Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute

[Ivan.khoronzhuk]

Hi Jean,
See reply at v4.

On 02/26/2015 10:50 AM, Jean Delvare wrote:

Hi Ivan, Mark and all,

Le Tuesday 03 February 2015 à 17:48 +0200, Ivan Khoronzhuk a écrit :

On 02/03/2015 04:58 PM, Mark Salter wrote:

On Wed, 2015-01-28 at 14:39 +0200, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, needs to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry. So this patch adds SMBIOS area to
dmi-sysfs in order to allow utils in question to work correctly with
dmi sysfs interface.

Reviewed-by: Ard Biesheuvel 
Signed-off-by: Ivan Khoronzhuk 

Sorry for coming in late, here. Why expose the raw header
instead of exposing the pieces as individual files like
the kernel does for the other dmi info? That way the kernel
decodes the header and presents it in an easy to read
format for dmidecode or even a shell script.

Sorry for coming in even later.

This is a common misconception that dmidecode would be happier with
pre-processed data. In fact it's exactly the opposite, dmidecode will be
much happier with raw data because it already has all the code to decode
the raw data, and that code will have to stay in place anyway as not all
systems have sysfs with the proper information exposed to avoid reading
the raw data from /dev/mem directly.

In a particular it should be noted that the
current /sys/firmware/dmi/entries interface is completely unsuited for
consumption by dmidecode. It would require a significant amount of extra
code in dmidecode to walk and parse the hundreds of files in this
directory. And there would be additional problems, such as slower
execution (500 file open/close cycles, thank you very much) and entries
not being displayed in the same order as when dmidecode reads the table
directly.

So not only Ivan is right with his idea of exposing the raw DMI/SMBIOS
entry point in sysfs, but I think we need to go even further and also
expose the raw DMI data table itself through sysfs. It should go
under /sys/firmware/dmi/tables/, much like ACPI tables live
under /sys/firmware/acpi/tables/.

I would also suggest that both the raw entry point and the raw table
data should be presented regardless of CONFIG_DMI_SYSFS. The code should
be small enough that it should be OK to include it unconditionally. Most
systems don't need the dmi-sysfs code, the use cases seem rather limited
to me, and on distributions it's generally built as a module and not
loaded by default.


The SMBIOS entry point can contain specific fields depending on it's
version. In the specification I didn't find any rules concerning this.

Only field that probably will be available is version number, but
the version number is not only var that can be required by utils.
For example, dmidecode needs also print some additional info like
phys address where dmitable is placed.

I don't sure how exactly next SMBIOS version will be changed.
It can happen that some new data is available...and some old is removed.
It's better to export it as raw data like it was done for dmi entries
via raw attribute and It's better to pass the whole entry table
instead of each time modify the dmi sysfs interface when new SMBIOS
version is issued.



---

v1: https://lkml.org/lkml/2015/1/23/643
v2: https://lkml.org/lkml/2015/1/26/345

v3..v2:

This notation is confusing, being opposite to the git syntax. Please
just write "Changes since v2".


firmware: dmi_scan: add symbol to get SMBIOS entry area
firmware: dmi-sysfs: add SMBIOS entry point area attribute
combined in one patch
added SMBIOS information to ABI sysfs-dmi documentaton

v2..v1:
firmware: dmi_scan: add symbol to get SMBIOS entry area
- used additional static var to hold SMBIOS raw table size
- changed format of get_smbios_entry_area symbol
  returned pointer on const smbios table

firmware: dmi-sysfs: add SMBIOS entry point area attribute
- adopted to updated get_smbios_entry_area symbol
- removed redundant array to save smbios table


   Documentation/ABI/testing/sysfs-firmware-dmi | 10 +++
   drivers/firmware/dmi-sysfs.c | 42 

   drivers/firmware/dmi_scan.c  | 26 +
   include/linux/dmi.h  |  3 ++
   4 files changed, 81 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi 
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..3a9ffe8 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -12,6 +12,16 @@ Description:
cannot ensure that the data as exported to userland is
without error either.
   
+		The firmware provides DMI structures as a packed list of

+   data referenced by a SMBIOS table entry 

Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute

[Ivan.khoronzhuk]

Hi Jean.

On 02/26/2015 11:41 AM, Jean Delvare wrote:

Replying to myself...

On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:

Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to implement both the old and the new format. It may be
desirable to expose both to user-space under different names.

Having read the kernel code meanwhile, I see we will call either
dmi_smbios3_present or dmi_present successfully, not both, so
presenting both entry points to user-space would be non-trivial. So I'm
fine with presenting only one entry point in sysfs for the time being.
We can always revisit later if it turns out that dmidecode really needs
both in some cases.



Why do you need two tables ? If kernel can parse the best one why
it should present the old one? The old is subset of new, so the new must
contain all required information, only format can be slightly different.
If dmidecode has problems in reading new version then dmidecode should
be modified, not kernel.

--
Regards,
Ivan Khoronzhuk

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

Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute

[Ivan.khoronzhuk]

On 02/26/2015 11:36 AM, Jean Delvare wrote:

Hi Ivan,

Sorry for the late review.

On Wed,  4 Feb 2015 19:06:03 +0200, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry. So this patch adds SMBIOS area to
dmi-sysfs in order to allow utils in question to work correctly with
dmi sysfs interface.

Reviewed-by: Ard Biesheuvel 
Signed-off-by: Ivan Khoronzhuk 
---

v1: https://lkml.org/lkml/2015/1/23/643
v2: https://lkml.org/lkml/2015/1/26/345
v3: https://lkml.org/lkml/2015/1/28/768

v4..v2:

Please always provide a list of changes from the previous version of
the patch, otherwise it's quite confusing.


Typo v4..v2 -> v4..v3




   firmware: dmi_scan: add symbol to get SMBIOS entry area
- used u8 type for smbios_header var
   firmware: dmi-sysfs: add SMBIOS entry point area attribute
- replaced -ENODATA on -EINVAL

v3..v2:
   firmware: dmi_scan: add symbol to get SMBIOS entry area
   firmware: dmi-sysfs: add SMBIOS entry point area attribute
- combined in one patch
- added SMBIOS information to ABI sysfs-dmi documentaton

v2..v1:
   firmware: dmi_scan: add symbol to get SMBIOS entry area
- used additional static var to hold SMBIOS raw table size
- changed format of get_smbios_entry_area symbol
  returned pointer on const smbios table

   firmware: dmi-sysfs: add SMBIOS entry point area attribute
- adopted to updated get_smbios_entry_area symbol
- removed redundant array to save smbios table

  Documentation/ABI/testing/sysfs-firmware-dmi | 10 +++
  drivers/firmware/dmi-sysfs.c | 42 
  drivers/firmware/dmi_scan.c  | 26 +
  include/linux/dmi.h  |  3 ++
  4 files changed, 81 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi 
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..3a9ffe8 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -12,6 +12,16 @@ Description:
cannot ensure that the data as exported to userland is
without error either.
  
+		The firmware provides DMI structures as a packed list of

+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   That's why SMBIOS entry point is represented in dmi sysfs
+   like a raw attribute and is accessible via
+   /sys/firmware/dmi/smbios_raw_header. The format of SMBIOS

As mentioned before, I don't like the name "smbios_raw_header". I think
it should be "smbios_entry_point" or similar.


If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.




+   entry point header can be read in SMBIOS specification.
+
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as a firmware-provided
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index e0f1cb3..9b396d7 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -29,6 +29,8 @@
  #define MAX_ENTRY_TYPE 255 /* Most of these aren't used, but we consider
  the top entry type is only 8 bits */
  
+static const u8 *smbios_raw_header;

+
  struct dmi_sysfs_entry {
struct dmi_header dh;
struct kobject kobj;
@@ -646,9 +648,37 @@ static void cleanup_entry_list(void)
}
  }
  
+static ssize_t smbios_entry_area_raw_read(struct file *filp,

This is confusing again, now it's named "entry_area"? Please be
consistent and use entry_point everywhere.

As mentioned before I believe that this code should live in dmi_scan
and not dmi-sysfs.


+ struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t pos, size_t count)
+{
+   ssize_t size;
+
+   size = bin_attr->size;
+
+   if (size > pos)
+   size -= pos;
+   else
+   return 0;
+
+   if (count < size)
+   size = count;
+
+   memcpy(buf, _raw_header[pos], size);
+
+   return size;
+}
+
+static struct bin_attribute smbios_raw_area_attr = {
+   .read = smbios_entry_area_raw_read,
+   .attr = {.name = "smbios_raw_header", .mode = 

Re: [dmidecode] [Patch v4] firmware: dmi-sysfs: add SMBIOS entry point area attribute

[Ivan.khoronzhuk]

On 02/26/2015 11:36 AM, Jean Delvare wrote:

Hi Ivan,

Sorry for the late review.

On Wed,  4 Feb 2015 19:06:03 +0200, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry. So this patch adds SMBIOS area to
dmi-sysfs in order to allow utils in question to work correctly with
dmi sysfs interface.

Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@linaro.org
---

v1: https://lkml.org/lkml/2015/1/23/643
v2: https://lkml.org/lkml/2015/1/26/345
v3: https://lkml.org/lkml/2015/1/28/768

v4..v2:

Please always provide a list of changes from the previous version of
the patch, otherwise it's quite confusing.


Typo v4..v2 - v4..v3




   firmware: dmi_scan: add symbol to get SMBIOS entry area
- used u8 type for smbios_header var
   firmware: dmi-sysfs: add SMBIOS entry point area attribute
- replaced -ENODATA on -EINVAL

v3..v2:
   firmware: dmi_scan: add symbol to get SMBIOS entry area
   firmware: dmi-sysfs: add SMBIOS entry point area attribute
- combined in one patch
- added SMBIOS information to ABI sysfs-dmi documentaton

v2..v1:
   firmware: dmi_scan: add symbol to get SMBIOS entry area
- used additional static var to hold SMBIOS raw table size
- changed format of get_smbios_entry_area symbol
  returned pointer on const smbios table

   firmware: dmi-sysfs: add SMBIOS entry point area attribute
- adopted to updated get_smbios_entry_area symbol
- removed redundant array to save smbios table

  Documentation/ABI/testing/sysfs-firmware-dmi | 10 +++
  drivers/firmware/dmi-sysfs.c | 42 
  drivers/firmware/dmi_scan.c  | 26 +
  include/linux/dmi.h  |  3 ++
  4 files changed, 81 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi 
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..3a9ffe8 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -12,6 +12,16 @@ Description:
cannot ensure that the data as exported to userland is
without error either.
  
+		The firmware provides DMI structures as a packed list of

+   data referenced by a SMBIOS table entry point. The SMBIOS
+   entry point contains general information, like SMBIOS
+   version, DMI table size, etc. The structure, content and
+   size of SMBIOS entry point is dependent on SMBIOS version.
+   That's why SMBIOS entry point is represented in dmi sysfs
+   like a raw attribute and is accessible via
+   /sys/firmware/dmi/smbios_raw_header. The format of SMBIOS

As mentioned before, I don't like the name smbios_raw_header. I think
it should be smbios_entry_point or similar.


If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.




+   entry point header can be read in SMBIOS specification.
+
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as a firmware-provided
diff --git a/drivers/firmware/dmi-sysfs.c b/drivers/firmware/dmi-sysfs.c
index e0f1cb3..9b396d7 100644
--- a/drivers/firmware/dmi-sysfs.c
+++ b/drivers/firmware/dmi-sysfs.c
@@ -29,6 +29,8 @@
  #define MAX_ENTRY_TYPE 255 /* Most of these aren't used, but we consider
  the top entry type is only 8 bits */
  
+static const u8 *smbios_raw_header;

+
  struct dmi_sysfs_entry {
struct dmi_header dh;
struct kobject kobj;
@@ -646,9 +648,37 @@ static void cleanup_entry_list(void)
}
  }
  
+static ssize_t smbios_entry_area_raw_read(struct file *filp,

This is confusing again, now it's named entry_area? Please be
consistent and use entry_point everywhere.

As mentioned before I believe that this code should live in dmi_scan
and not dmi-sysfs.


+ struct kobject *kobj,
+ struct bin_attribute *bin_attr,
+ char *buf, loff_t pos, size_t count)
+{
+   ssize_t size;
+
+   size = bin_attr-size;
+
+   if (size  pos)
+   size -= pos;
+   else
+   return 0;
+
+   if (count  size)
+   size = count;
+
+   memcpy(buf, smbios_raw_header[pos], size);
+
+   return size;
+}
+
+static struct bin_attribute smbios_raw_area_attr = {
+   .read = smbios_entry_area_raw_read,
+   

Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute

[Ivan.khoronzhuk]

Hi Jean,
See reply at v4.

On 02/26/2015 10:50 AM, Jean Delvare wrote:

Hi Ivan, Mark and all,

Le Tuesday 03 February 2015 à 17:48 +0200, Ivan Khoronzhuk a écrit :

On 02/03/2015 04:58 PM, Mark Salter wrote:

On Wed, 2015-01-28 at 14:39 +0200, Ivan Khoronzhuk wrote:

Some utils, like dmidecode and smbios, needs to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi sysfs instead, which
doesn't represent SMBIOS entry. So this patch adds SMBIOS area to
dmi-sysfs in order to allow utils in question to work correctly with
dmi sysfs interface.

Reviewed-by: Ard Biesheuvel ard.biesheu...@linaro.org
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@linaro.org

Sorry for coming in late, here. Why expose the raw header
instead of exposing the pieces as individual files like
the kernel does for the other dmi info? That way the kernel
decodes the header and presents it in an easy to read
format for dmidecode or even a shell script.

Sorry for coming in even later.

This is a common misconception that dmidecode would be happier with
pre-processed data. In fact it's exactly the opposite, dmidecode will be
much happier with raw data because it already has all the code to decode
the raw data, and that code will have to stay in place anyway as not all
systems have sysfs with the proper information exposed to avoid reading
the raw data from /dev/mem directly.

In a particular it should be noted that the
current /sys/firmware/dmi/entries interface is completely unsuited for
consumption by dmidecode. It would require a significant amount of extra
code in dmidecode to walk and parse the hundreds of files in this
directory. And there would be additional problems, such as slower
execution (500 file open/close cycles, thank you very much) and entries
not being displayed in the same order as when dmidecode reads the table
directly.

So not only Ivan is right with his idea of exposing the raw DMI/SMBIOS
entry point in sysfs, but I think we need to go even further and also
expose the raw DMI data table itself through sysfs. It should go
under /sys/firmware/dmi/tables/, much like ACPI tables live
under /sys/firmware/acpi/tables/.

I would also suggest that both the raw entry point and the raw table
data should be presented regardless of CONFIG_DMI_SYSFS. The code should
be small enough that it should be OK to include it unconditionally. Most
systems don't need the dmi-sysfs code, the use cases seem rather limited
to me, and on distributions it's generally built as a module and not
loaded by default.


The SMBIOS entry point can contain specific fields depending on it's
version. In the specification I didn't find any rules concerning this.

Only field that probably will be available is version number, but
the version number is not only var that can be required by utils.
For example, dmidecode needs also print some additional info like
phys address where dmitable is placed.

I don't sure how exactly next SMBIOS version will be changed.
It can happen that some new data is available...and some old is removed.
It's better to export it as raw data like it was done for dmi entries
via raw attribute and It's better to pass the whole entry table
instead of each time modify the dmi sysfs interface when new SMBIOS
version is issued.



---

v1: https://lkml.org/lkml/2015/1/23/643
v2: https://lkml.org/lkml/2015/1/26/345

v3..v2:

This notation is confusing, being opposite to the git syntax. Please
just write Changes since v2.


firmware: dmi_scan: add symbol to get SMBIOS entry area
firmware: dmi-sysfs: add SMBIOS entry point area attribute
combined in one patch
added SMBIOS information to ABI sysfs-dmi documentaton

v2..v1:
firmware: dmi_scan: add symbol to get SMBIOS entry area
- used additional static var to hold SMBIOS raw table size
- changed format of get_smbios_entry_area symbol
  returned pointer on const smbios table

firmware: dmi-sysfs: add SMBIOS entry point area attribute
- adopted to updated get_smbios_entry_area symbol
- removed redundant array to save smbios table


   Documentation/ABI/testing/sysfs-firmware-dmi | 10 +++
   drivers/firmware/dmi-sysfs.c | 42 

   drivers/firmware/dmi_scan.c  | 26 +
   include/linux/dmi.h  |  3 ++
   4 files changed, 81 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi 
b/Documentation/ABI/testing/sysfs-firmware-dmi
index c78f9ab..3a9ffe8 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -12,6 +12,16 @@ Description:
cannot ensure that the data as exported to userland is
without error either.
   
+		The firmware provides DMI structures as a packed list of

+  

Re: [dmidecode] [Patch v3] firmware: dmi-sysfs: add SMBIOS entry point area raw attribute

[Ivan.khoronzhuk]

Hi Jean.

On 02/26/2015 11:41 AM, Jean Delvare wrote:

Replying to myself...

On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:

Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to implement both the old and the new format. It may be
desirable to expose both to user-space under different names.

Having read the kernel code meanwhile, I see we will call either
dmi_smbios3_present or dmi_present successfully, not both, so
presenting both entry points to user-space would be non-trivial. So I'm
fine with presenting only one entry point in sysfs for the time being.
We can always revisit later if it turns out that dmidecode really needs
both in some cases.



Why do you need two tables ? If kernel can parse the best one why
it should present the old one? The old is subset of new, so the new must
contain all required information, only format can be slightly different.
If dmidecode has problems in reading new version then dmidecode should
be modified, not kernel.

--
Regards,
Ivan Khoronzhuk

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

Re: [PATCH v3] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 12/18/2013 02:13 PM, Sekhar Nori wrote:

On Wednesday 18 December 2013 05:21 PM, ivan.khoronzhuk wrote:

Hi, Sekhar

This patch is based on "Reuse davinci-nand driver for Keystone arch" series.
The series has passed review at https://lkml.org/lkml/2013/12/17/241
and can be found at http://git.infradead.org/l2-mtd.git

This patch can be still applied on top of the series without conflicts.

Can you please pick up the $subject patch if you are OK with it?


I have no problems with the patch and can pick it too, but need ack from
MTD maintainer (David) as it touches drivers/mtd/ too.

David,

If you do not have the patch, we can resend it.

Thanks,
Sekhar



Hi Brian,

Do you agree if this patch will go through Davinci tree?

This is the last one we need to reuse Davinci Nand driver for Keystone.

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

Re: [PATCH v3] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 12/18/2013 02:13 PM, Sekhar Nori wrote:

On Wednesday 18 December 2013 05:21 PM, ivan.khoronzhuk wrote:

Hi, Sekhar

This patch is based on Reuse davinci-nand driver for Keystone arch series.
The series has passed review at https://lkml.org/lkml/2013/12/17/241
and can be found at http://git.infradead.org/l2-mtd.git

This patch can be still applied on top of the series without conflicts.

Can you please pick up the $subject patch if you are OK with it?


I have no problems with the patch and can pick it too, but need ack from
MTD maintainer (David) as it touches drivers/mtd/ too.

David,

If you do not have the patch, we can resend it.

Thanks,
Sekhar



Hi Brian,

Do you agree if this patch will go through Davinci tree?

This is the last one we need to reuse Davinci Nand driver for Keystone.

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

Re: [PATCH v3] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 12/05/2013 08:11 PM, Ivan Khoronzhuk wrote:
> The problem that the set timings code contains the call of Davinci
> platform function davinci_aemif_setup_timing() which is not
> accessible if kernel is built for another platform like Keystone.
> 
> The Keysone platform is going to use TI AEMIF driver.
> If TI AEMIF is used we don't need to set timings and bus width.
> It is done by AEMIF driver.
> 
> To get rid of davinci-nand driver dependency on aemif platform code
> we moved aemif code to davinci platform.
> 
> The platform AEMIF code (aemif.c) has to be removed once Davinci
> will be converted to DT and use ti-aemif.c driver.
> 
> Signed-off-by: Sekhar Nori 
> Signed-off-by: Ivan Khoronzhuk 
> ---
> v3..v2:
> - rebased on following patch series:
>   [PATCH v3 0/9] Reuse davinci-nand driver for Keystone arch
>   http://www.spinics.net/lists/arm-kernel/msg291723.html
> - removed AEMIF setup from next boards:
>arch/arm/mach-davinci/board-dm355-evm.c
>arch/arm/mach-davinci/board-dm355-leopard.c
>arch/arm/mach-davinci/board-dm365-evm.c
>arch/arm/mach-davinci/board-neuros-osd2.c
>arch/arm/mach-davinci/devices-tnetv107x.c
> - removed repeated clk_get() from davinci_aemif_setup_timing()
> 
> v2..v1:
> - enabled AEMIF clock
> - removed EXPORT_SYMBOL(davinci_aemif_setup)
> - renamed ugly name davinci_ntosd2_nandflash_device
> CC:
> Sekhar Nori 
> 
>   arch/arm/mach-davinci/aemif.c   |  106 
> ---
>   arch/arm/mach-davinci/board-da830-evm.c |3 +
>   arch/arm/mach-davinci/board-da850-evm.c |3 +
>   arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
>   arch/arm/mach-davinci/board-dm646x-evm.c|3 +
>   arch/arm/mach-davinci/board-mityomapl138.c  |3 +
>   drivers/mtd/nand/davinci_nand.c |   22 -
>   include/linux/platform_data/mtd-davinci-aemif.h |5 +-
>   8 files changed, 115 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
> index f091a90..7adfb7e 100644
> --- a/arch/arm/mach-davinci/aemif.c
> +++ b/arch/arm/mach-davinci/aemif.c
> @@ -16,6 +16,7 @@
>   #include 
>   
>   #include 
> +#include 
>   
>   /* Timing value configuration */
>   
> @@ -43,6 +44,17 @@
>   WSTROBE(WSTROBE_MAX) | \
>   WSETUP(WSETUP_MAX))
>   
> +static inline unsigned int davinci_aemif_readl(void __iomem *base, int 
> offset)
> +{
> + return readl_relaxed(base + offset);
> +}
> +
> +static inline void davinci_aemif_writel(void __iomem *base,
> + int offset, unsigned long value)
> +{
> + writel_relaxed(value, base + offset);
> +}
> +
>   /*
>* aemif_calc_rate - calculate timing data.
>* @wanted: The cycle time needed in nanoseconds.
> @@ -76,6 +88,7 @@ static int aemif_calc_rate(int wanted, unsigned long clk, 
> int max)
>* @t: timing values to be progammed
>* @base: The virtual base address of the AEMIF interface
>* @cs: chip-select to program the timing values for
> + * @clkrate: the AEMIF clkrate
>*
>* This function programs the given timing values (in real clock) into the
>* AEMIF registers taking the AEMIF clock into account.
> @@ -86,24 +99,17 @@ static int aemif_calc_rate(int wanted, unsigned long clk, 
> int max)
>*
>* Returns 0 on success, else negative errno.
>*/
> -int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
> - void __iomem *base, unsigned cs)
> +static int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
> + void __iomem *base, unsigned cs,
> + unsigned long clkrate)
>   {
>   unsigned set, val;
>   int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup;
>   unsigned offset = A1CR_OFFSET + cs * 4;
> - struct clk *aemif_clk;
> - unsigned long clkrate;
>   
>   if (!t)
>   return 0;   /* Nothing to do */
>   
> - aemif_clk = clk_get(NULL, "aemif");
> - if (IS_ERR(aemif_clk))
> - return PTR_ERR(aemif_clk);
> -
> - clkrate = clk_get_rate(aemif_clk);
> -
>   clkrate /= 1000;/* turn clock into kHz for ease of use */
>   
>   ta  = aemif_calc_rate(t->ta, clkrate, TA_MAX);
> @@ -130,4 +136,82 @@ int davinci_aemif_setup_timing(struct 
> davinci_aemif_timing *t,
>   
>   return 0;
>   }
> -EXPORT_SYMBOL(davinci_aemif_setup_timing);
> +
> +/**
> + * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
> + * @pdev - link to platform device to setup settings for
> + *
> + * This function does not use any locking while programming the AEMIF
> + * because it is expected that there is only one user of a given
> + * chip-select.
> + *
> + * Returns 0 on success, else negative errno.
> + */
> +int davinci_aemif_setup(struct platform_device *pdev)
> +{

Re: [PATCH v4 0/9] Reuse davinci-nand driver for Keystone arch

[ivan.khoronzhuk]

On 12/18/2013 09:14 AM, Brian Norris wrote:

On Tue, Dec 17, 2013 at 02:59:06PM +0200, Ivan Khoronzhuk wrote:

This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.

v3..v4:
- mtd: nand: davinci: fix driver registration
dropped __init/__exit/__exit_p as module_platform_driver() is used
- mtd: nand: davinci: adjust DT properties to MTD generic
used of_get_nand_bus_width() helper
- mtd: nand: davinci: don't request AEMIF address range
added comment at code change


Pushed the series to l2-mtd.git. Thanks!

Brian



Thanks

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

Re: [PATCH v4 0/9] Reuse davinci-nand driver for Keystone arch

[ivan.khoronzhuk]

On 12/18/2013 09:14 AM, Brian Norris wrote:

On Tue, Dec 17, 2013 at 02:59:06PM +0200, Ivan Khoronzhuk wrote:

This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.

v3..v4:
- mtd: nand: davinci: fix driver registration
dropped __init/__exit/__exit_p as module_platform_driver() is used
- mtd: nand: davinci: adjust DT properties to MTD generic
used of_get_nand_bus_width() helper
- mtd: nand: davinci: don't request AEMIF address range
added comment at code change


Pushed the series to l2-mtd.git. Thanks!

Brian



Thanks

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

Re: [PATCH v3] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 12/05/2013 08:11 PM, Ivan Khoronzhuk wrote:
 The problem that the set timings code contains the call of Davinci
 platform function davinci_aemif_setup_timing() which is not
 accessible if kernel is built for another platform like Keystone.
 
 The Keysone platform is going to use TI AEMIF driver.
 If TI AEMIF is used we don't need to set timings and bus width.
 It is done by AEMIF driver.
 
 To get rid of davinci-nand driver dependency on aemif platform code
 we moved aemif code to davinci platform.
 
 The platform AEMIF code (aemif.c) has to be removed once Davinci
 will be converted to DT and use ti-aemif.c driver.
 
 Signed-off-by: Sekhar Nori nsek...@ti.com
 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
 ---
 v3..v2:
 - rebased on following patch series:
   [PATCH v3 0/9] Reuse davinci-nand driver for Keystone arch
   http://www.spinics.net/lists/arm-kernel/msg291723.html
 - removed AEMIF setup from next boards:
arch/arm/mach-davinci/board-dm355-evm.c
arch/arm/mach-davinci/board-dm355-leopard.c
arch/arm/mach-davinci/board-dm365-evm.c
arch/arm/mach-davinci/board-neuros-osd2.c
arch/arm/mach-davinci/devices-tnetv107x.c
 - removed repeated clk_get() from davinci_aemif_setup_timing()
 
 v2..v1:
 - enabled AEMIF clock
 - removed EXPORT_SYMBOL(davinci_aemif_setup)
 - renamed ugly name davinci_ntosd2_nandflash_device
 CC:
 Sekhar Nori nsek...@ti.com
 
   arch/arm/mach-davinci/aemif.c   |  106 
 ---
   arch/arm/mach-davinci/board-da830-evm.c |3 +
   arch/arm/mach-davinci/board-da850-evm.c |3 +
   arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
   arch/arm/mach-davinci/board-dm646x-evm.c|3 +
   arch/arm/mach-davinci/board-mityomapl138.c  |3 +
   drivers/mtd/nand/davinci_nand.c |   22 -
   include/linux/platform_data/mtd-davinci-aemif.h |5 +-
   8 files changed, 115 insertions(+), 35 deletions(-)
 
 diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
 index f091a90..7adfb7e 100644
 --- a/arch/arm/mach-davinci/aemif.c
 +++ b/arch/arm/mach-davinci/aemif.c
 @@ -16,6 +16,7 @@
   #include linux/time.h
   
   #include linux/platform_data/mtd-davinci-aemif.h
 +#include linux/platform_data/mtd-davinci.h
   
   /* Timing value configuration */
   
 @@ -43,6 +44,17 @@
   WSTROBE(WSTROBE_MAX) | \
   WSETUP(WSETUP_MAX))
   
 +static inline unsigned int davinci_aemif_readl(void __iomem *base, int 
 offset)
 +{
 + return readl_relaxed(base + offset);
 +}
 +
 +static inline void davinci_aemif_writel(void __iomem *base,
 + int offset, unsigned long value)
 +{
 + writel_relaxed(value, base + offset);
 +}
 +
   /*
* aemif_calc_rate - calculate timing data.
* @wanted: The cycle time needed in nanoseconds.
 @@ -76,6 +88,7 @@ static int aemif_calc_rate(int wanted, unsigned long clk, 
 int max)
* @t: timing values to be progammed
* @base: The virtual base address of the AEMIF interface
* @cs: chip-select to program the timing values for
 + * @clkrate: the AEMIF clkrate
*
* This function programs the given timing values (in real clock) into the
* AEMIF registers taking the AEMIF clock into account.
 @@ -86,24 +99,17 @@ static int aemif_calc_rate(int wanted, unsigned long clk, 
 int max)
*
* Returns 0 on success, else negative errno.
*/
 -int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
 - void __iomem *base, unsigned cs)
 +static int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
 + void __iomem *base, unsigned cs,
 + unsigned long clkrate)
   {
   unsigned set, val;
   int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup;
   unsigned offset = A1CR_OFFSET + cs * 4;
 - struct clk *aemif_clk;
 - unsigned long clkrate;
   
   if (!t)
   return 0;   /* Nothing to do */
   
 - aemif_clk = clk_get(NULL, aemif);
 - if (IS_ERR(aemif_clk))
 - return PTR_ERR(aemif_clk);
 -
 - clkrate = clk_get_rate(aemif_clk);
 -
   clkrate /= 1000;/* turn clock into kHz for ease of use */
   
   ta  = aemif_calc_rate(t-ta, clkrate, TA_MAX);
 @@ -130,4 +136,82 @@ int davinci_aemif_setup_timing(struct 
 davinci_aemif_timing *t,
   
   return 0;
   }
 -EXPORT_SYMBOL(davinci_aemif_setup_timing);
 +
 +/**
 + * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
 + * @pdev - link to platform device to setup settings for
 + *
 + * This function does not use any locking while programming the AEMIF
 + * because it is expected that there is only one user of a given
 + * chip-select.
 + *
 + * Returns 0 on success, else negative errno.
 + */
 +int davinci_aemif_setup(struct platform_device *pdev)
 +{
 +   

Re: [PATCH v3 7/9] mtd: nand: davinci: adjust DT properties to MTD generic

[ivan.khoronzhuk]

On 12/17/2013 10:50 AM, Brian Norris wrote:
> On Thu, Dec 05, 2013 at 07:25:55PM +0200, Ivan Khoronzhuk wrote:
>> --- a/drivers/mtd/nand/davinci_nand.c
>> +++ b/drivers/mtd/nand/davinci_nand.c
>> @@ -558,6 +557,8 @@ static struct davinci_nand_pdata
>>  "ti,davinci-mask-chipsel", ))
>>  pdata->mask_chipsel = prop;
>>  if (!of_property_read_string(pdev->dev.of_node,
>> +"nand-ecc-mode", ) ||
> 
> Is it possible to use the of_get_nand_ecc_mode() helper? It's
> unfortunate that davinci_nand had to use custom bindings in the first
> place, making this more difficult... So I can take this patch as-is.
> 

Yes, I will do nothing for that

>> +!of_property_read_string(pdev->dev.of_node,
>>  "ti,davinci-ecc-mode", )) {
>>  if (!strncmp("none", mode, 4))
>>  pdata->ecc_mode = NAND_ECC_NONE;
>> @@ -570,11 +571,15 @@ static struct davinci_nand_pdata
>>  "ti,davinci-ecc-bits", ))
>>  pdata->ecc_bits = prop;
>>  if (!of_property_read_u32(pdev->dev.of_node,
>> +"nand-bus-width", ) ||
> 
> Similar story here, with of_get_nand_bus_width().
> 

It seems for bus width I can replace it on:

prop = of_get_nand_bus_width(pdev->dev.of_node);
if ( 0 < prop || !of_property_read_u32(pdev->dev.of_node,
 "ti,davinci-nand-buswidth", ))
 if (prop == 16)
 pdata->options |= NAND_BUSWIDTH_16;


>> +!of_property_read_u32(pdev->dev.of_node,
>>  "ti,davinci-nand-buswidth", ))
>>  if (prop == 16)
>>  pdata->options |= NAND_BUSWIDTH_16;
>> -if (of_find_property(pdev->dev.of_node,
>> -"ti,davinci-nand-use-bbt", ))
>> +if (of_property_read_bool(pdev->dev.of_node,
>> +"nand-on-flash-bbt") ||
>> +of_property_read_bool(pdev->dev.of_node,
>> +"ti,davinci-nand-use-bbt"))
>>  pdata->bbt_options = NAND_BBT_USE_FLASH;
>>  }
>>   
> 
> Brian
> 


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

Re: [PATCH v3 9/9] mtd: nand: davinci: don't request AEMIF address range

[ivan.khoronzhuk]

On 12/17/2013 10:42 AM, Brian Norris wrote:

On Thu, Dec 05, 2013 at 07:25:57PM +0200, Ivan Khoronzhuk wrote:

The TI AEMIF driver registers are used to setup timings for each chip
select. The same registers range is used to setup NAND settings.
The AEMIF and NAND drivers not use the same registers in this range.

In case with TI AEMIF driver, the memory address range is requested
already by AEMIF, so we cannot request it twice, just ioremap.

Acked-by: Santosh Shilimkar 
Reviewed-by: Grygorii Strashko 
Reviewed-by: Taras Kondratiuk 
Signed-off-by: Ivan Khoronzhuk 
---
  drivers/mtd/nand/davinci_nand.c |8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index f7b21b8..0cd4dbc 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -636,9 +636,11 @@ static int __init nand_davinci_probe(struct 
platform_device *pdev)
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);

-   base = devm_ioremap_resource(>dev, res2);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   base = devm_ioremap(>dev, res2->start, resource_size(res2));


Since it's important that we don't re-introduce the "request resource"
boilerplate later, can you add a comment describing the situation?


+   if (!base) {
+   dev_err(>dev, "ioremap failed for resource %pR\n", res2);
+   return -EADDRNOTAVAIL;
+   }

info->dev= >dev;
info->base   = base;


Thanks,
Brian



Yes, I'll add the comment.

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

Re: [PATCH v3 1/9] mtd: nand: davinci: fix driver registration

[ivan.khoronzhuk]

On 12/17/2013 11:24 AM, Brian Norris wrote:
> On Thu, Dec 05, 2013 at 07:25:49PM +0200, Ivan Khoronzhuk wrote:
>> --- a/drivers/mtd/nand/davinci_nand.c
>> +++ b/drivers/mtd/nand/davinci_nand.c
>> @@ -877,6 +877,7 @@ static int __exit nand_davinci_remove(struct 
>> platform_device *pdev)
>>   }
>>   
>>   static struct platform_driver nand_davinci_driver = {
>> +.probe  = nand_davinci_probe,
>>  .remove = __exit_p(nand_davinci_remove),
> 
> I believe you need to drop the __exit_p() here. And now that you're
> using module_platform_driver(), you need to drop the __init and __exit
> from the probe() and remove() routines, to avoid section mismatch
> warnings.
> 
>>  .driver = {
>>  .name   = "davinci_nand",
> 
> So on second thought, please resubmit the series with the requested
> changes.
> 
> Thanks,
> Brian
> 

Thanks, Brian.
Do you want me to drop it in stand alone patch or in this one?

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

Re: [PATCH v3 1/9] mtd: nand: davinci: fix driver registration

[ivan.khoronzhuk]

On 12/17/2013 11:24 AM, Brian Norris wrote:
 On Thu, Dec 05, 2013 at 07:25:49PM +0200, Ivan Khoronzhuk wrote:
 --- a/drivers/mtd/nand/davinci_nand.c
 +++ b/drivers/mtd/nand/davinci_nand.c
 @@ -877,6 +877,7 @@ static int __exit nand_davinci_remove(struct 
 platform_device *pdev)
   }
   
   static struct platform_driver nand_davinci_driver = {
 +.probe  = nand_davinci_probe,
  .remove = __exit_p(nand_davinci_remove),
 
 I believe you need to drop the __exit_p() here. And now that you're
 using module_platform_driver(), you need to drop the __init and __exit
 from the probe() and remove() routines, to avoid section mismatch
 warnings.
 
  .driver = {
  .name   = davinci_nand,
 
 So on second thought, please resubmit the series with the requested
 changes.
 
 Thanks,
 Brian
 

Thanks, Brian.
Do you want me to drop it in stand alone patch or in this one?

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

Re: [PATCH v3 9/9] mtd: nand: davinci: don't request AEMIF address range

[ivan.khoronzhuk]

On 12/17/2013 10:42 AM, Brian Norris wrote:

On Thu, Dec 05, 2013 at 07:25:57PM +0200, Ivan Khoronzhuk wrote:

The TI AEMIF driver registers are used to setup timings for each chip
select. The same registers range is used to setup NAND settings.
The AEMIF and NAND drivers not use the same registers in this range.

In case with TI AEMIF driver, the memory address range is requested
already by AEMIF, so we cannot request it twice, just ioremap.

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Grygorii Strashko grygorii.stras...@ti.com
Reviewed-by: Taras Kondratiuk ta...@ti.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
  drivers/mtd/nand/davinci_nand.c |8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index f7b21b8..0cd4dbc 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -636,9 +636,11 @@ static int __init nand_davinci_probe(struct 
platform_device *pdev)
if (IS_ERR(vaddr))
return PTR_ERR(vaddr);

-   base = devm_ioremap_resource(pdev-dev, res2);
-   if (IS_ERR(base))
-   return PTR_ERR(base);
+   base = devm_ioremap(pdev-dev, res2-start, resource_size(res2));


Since it's important that we don't re-introduce the request resource
boilerplate later, can you add a comment describing the situation?


+   if (!base) {
+   dev_err(pdev-dev, ioremap failed for resource %pR\n, res2);
+   return -EADDRNOTAVAIL;
+   }

info-dev= pdev-dev;
info-base   = base;


Thanks,
Brian



Yes, I'll add the comment.

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

Re: [PATCH v3 7/9] mtd: nand: davinci: adjust DT properties to MTD generic

[ivan.khoronzhuk]

On 12/17/2013 10:50 AM, Brian Norris wrote:
 On Thu, Dec 05, 2013 at 07:25:55PM +0200, Ivan Khoronzhuk wrote:
 --- a/drivers/mtd/nand/davinci_nand.c
 +++ b/drivers/mtd/nand/davinci_nand.c
 @@ -558,6 +557,8 @@ static struct davinci_nand_pdata
  ti,davinci-mask-chipsel, prop))
  pdata-mask_chipsel = prop;
  if (!of_property_read_string(pdev-dev.of_node,
 +nand-ecc-mode, mode) ||
 
 Is it possible to use the of_get_nand_ecc_mode() helper? It's
 unfortunate that davinci_nand had to use custom bindings in the first
 place, making this more difficult... So I can take this patch as-is.
 

Yes, I will do nothing for that

 +!of_property_read_string(pdev-dev.of_node,
  ti,davinci-ecc-mode, mode)) {
  if (!strncmp(none, mode, 4))
  pdata-ecc_mode = NAND_ECC_NONE;
 @@ -570,11 +571,15 @@ static struct davinci_nand_pdata
  ti,davinci-ecc-bits, prop))
  pdata-ecc_bits = prop;
  if (!of_property_read_u32(pdev-dev.of_node,
 +nand-bus-width, prop) ||
 
 Similar story here, with of_get_nand_bus_width().
 

It seems for bus width I can replace it on:

prop = of_get_nand_bus_width(pdev-dev.of_node);
if ( 0  prop || !of_property_read_u32(pdev-dev.of_node,
 ti,davinci-nand-buswidth, prop))
 if (prop == 16)
 pdata-options |= NAND_BUSWIDTH_16;


 +!of_property_read_u32(pdev-dev.of_node,
  ti,davinci-nand-buswidth, prop))
  if (prop == 16)
  pdata-options |= NAND_BUSWIDTH_16;
 -if (of_find_property(pdev-dev.of_node,
 -ti,davinci-nand-use-bbt, len))
 +if (of_property_read_bool(pdev-dev.of_node,
 +nand-on-flash-bbt) ||
 +of_property_read_bool(pdev-dev.of_node,
 +ti,davinci-nand-use-bbt))
  pdata-bbt_options = NAND_BBT_USE_FLASH;
  }
   
 
 Brian
 


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

Re: [PATCH 2/2] arm: keystone: enable watchdog support

[ivan.khoronzhuk]

+ CC
devicet...@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-kernel@vger.kernel.org

On 12/10/2013 04:47 PM, Ivan Khoronzhuk wrote:

After Keystone watchdog driver updates are already merged we can
enable WDT in config.

Signed-off-by: Ivan Khoronzhuk 
---
Based on
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
keystone/master

  arch/arm/configs/keystone_defconfig |2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index 9943e5d..8bd940c 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -129,6 +129,8 @@ CONFIG_SPI_DAVINCI=y
  CONFIG_SPI_SPIDEV=y
  # CONFIG_HWMON is not set
  CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_DAVINCI_WATCHDOG=y
  # CONFIG_USB_SUPPORT is not set
  CONFIG_DMADEVICES=y
  CONFIG_COMMON_CLK_DEBUG=y




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

Re: [PATCH 1/2] arm: dts: keystone: add watchdog entry

[ivan.khoronzhuk]

+ CC
devicet...@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-kernel@vger.kernel.org

On 12/10/2013 04:47 PM, Ivan Khoronzhuk wrote:

Add watchdog entry to keystone device tree.

Acked-by: Guenter Roeck 
Signed-off-by: Ivan Khoronzhuk 
---
Based on
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
keystone/master

  arch/arm/boot/dts/keystone.dtsi |6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index f6d6d9e..54a8ff7 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -181,5 +181,11 @@
interrupts = ;
clocks = <>;
};
+
+   wdt: wdt@022f0080 {
+   compatible = "ti,keystone-wdt","ti,davinci-wdt";
+   reg = <0x022f0080 0x80>;
+   clocks = <>;
+   };
};
  };




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

Re: [PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver

[ivan.khoronzhuk]

On 12/10/2013 01:09 AM, Kumar Gala wrote:
> 
> On Nov 26, 2013, at 10:27 AM, Grygorii Strashko  
> wrote:
> 
>> On 11/22/2013 11:04 PM, Kumar Gala wrote:
>>>
>>> On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk  wrote:
>>>
 Add bindings for AEMIF controller drivers/memory/ti-aemif.c

>>>
>>> Binding shouldn’t normally refer to code.
>>>
>>> Just saying something like:
>>>
>>> Adding binging for TI Async External Memory Interface (AEMIF) controller.
>>>
>>>
 Signed-off-by: Ivan Khoronzhuk 
 ---
 .../bindings/memory-controllers/ti-aemif.txt   |  198 
 
 1 file changed, 198 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt

 diff --git 
 a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt 
 b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
 new file mode 100644
 index 000..be0c0cb
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
 @@ -0,0 +1,198 @@
 +* Device tree bindings for Texas instruments AEMIF controller
 +
 +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended 
 to
>>>
>>> The?
>>>
 +provide a glue-less interface to a variety of asynchronous memory devices 
 like
 +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these 
 memories
 +can be accessed at any given time via four chip selects with 64M byte 
 access
 +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM
 +and Mobile SDR are not supported.
 +
 +Documentation:
 +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
 +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
 +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
 +
 +Required properties:
 +
 +- compatible: "ti,davinci-aemif"
 +  "ti,keystone-aemif"
 +  "ti,omap-L138-aemif"
 +
 +- #address-cells: Must be 2. The first cell is the memory partition
 +  number. The 0 partition is for chip selects. And the
 +  second cell is the offset into the partition, for the 0
 +  partition it corresponds to chip select offset.
 +
>>>
>>> Is the first cell just the chip select number?
>>
>> No. It's rather memory range/partition number. Now there are 2 partitions:
>> - control partition which is common for all CS interfaces
>> - CS-specific partition/range
>> (this one can be splitted according to specific SoC requirement)
>>
>> As per Keystone TCI6638K2K
>> Datasheet http://www.ti.com/lit/ds/sprs836d/sprs836d.pdf:
>>
>> 1) the memory range 0 will be from 0x3000 size 0x1000:
>> 00 3000  - 00 33FF  64M EMIF16 CE0
>> 00 3400  - 00 37FF  64M EMIF16 CE1
>> 00 3800  - 00 3BFF  64M EMIF16 CE2
>> 00 3C00  - 00 3FFF  64M EMIF16 CE3
>>
>> 2) the memory range 1:
>> 00 2100 0A00 - 00 2100 0AFF 256 AEMIF Config
>>
>> And AEMIF node contains definition:
>> ranges = <0 0 0x3000 0x1000
>>1 0 0x21000A00 0x100>;
>>
>>
>> Child node has (nand):
>> reg = <0 0 0x400 (cs0)
>> - or - 0 0x400 0x400 (cs1)
>> - or - 0 0x800 0x400 (cs2)
>>  - or - 0 0xC00 0x400 (cs3)
>>  - and -
>> 1 0 0x100>; (for all cs)
>>
>> For example for cs2 child node the resulting mem range 0 will be calculated 
>> as
>>
>> from: 0x3000 + (0 0x800 - 0 0)
>> size: 0x400
>>
>> We don't encode CS number in reg/ranges, because it will allow simply change
>> AEMIF DT definitions depending on each SoC
>> (AEMIF CS memory range can be continuous as above or not, if not - additional
>> range/partition can be added and child device can select the proper one).
> 
> This is quite confusing.  I think the ranges property needs far more 
> description as part of the top level controller node.  It spec out what the 
> various fields are in the ranges property.
> 

Yes, you are right, description is quite poor. I should describe it more clearly

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

Re: [PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver

[ivan.khoronzhuk]

On 12/10/2013 01:09 AM, Kumar Gala wrote:
 
 On Nov 26, 2013, at 10:27 AM, Grygorii Strashko grygorii.stras...@ti.com 
 wrote:
 
 On 11/22/2013 11:04 PM, Kumar Gala wrote:

 On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk ivan.khoronz...@ti.com wrote:

 Add bindings for AEMIF controller drivers/memory/ti-aemif.c


 Binding shouldn’t normally refer to code.

 Just saying something like:

 Adding binging for TI Async External Memory Interface (AEMIF) controller.


 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
 ---
 .../bindings/memory-controllers/ti-aemif.txt   |  198 
 
 1 file changed, 198 insertions(+)
 create mode 100644 
 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt

 diff --git 
 a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt 
 b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
 new file mode 100644
 index 000..be0c0cb
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
 @@ -0,0 +1,198 @@
 +* Device tree bindings for Texas instruments AEMIF controller
 +
 +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended 
 to

 The?

 +provide a glue-less interface to a variety of asynchronous memory devices 
 like
 +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these 
 memories
 +can be accessed at any given time via four chip selects with 64M byte 
 access
 +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM
 +and Mobile SDR are not supported.
 +
 +Documentation:
 +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
 +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
 +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
 +
 +Required properties:
 +
 +- compatible: ti,davinci-aemif
 +  ti,keystone-aemif
 +  ti,omap-L138-aemif
 +
 +- #address-cells: Must be 2. The first cell is the memory partition
 +  number. The 0 partition is for chip selects. And the
 +  second cell is the offset into the partition, for the 0
 +  partition it corresponds to chip select offset.
 +

 Is the first cell just the chip select number?

 No. It's rather memory range/partition number. Now there are 2 partitions:
 - control partition which is common for all CS interfaces
 - CS-specific partition/range
 (this one can be splitted according to specific SoC requirement)

 As per Keystone TCI6638K2K
 Datasheet http://www.ti.com/lit/ds/sprs836d/sprs836d.pdf:

 1) the memory range 0 will be from 0x3000 size 0x1000:
 00 3000  - 00 33FF  64M EMIF16 CE0
 00 3400  - 00 37FF  64M EMIF16 CE1
 00 3800  - 00 3BFF  64M EMIF16 CE2
 00 3C00  - 00 3FFF  64M EMIF16 CE3

 2) the memory range 1:
 00 2100 0A00 - 00 2100 0AFF 256 AEMIF Config

 And AEMIF node contains definition:
 ranges = 0 0 0x3000 0x1000
1 0 0x21000A00 0x100;


 Child node has (nand):
 reg = 0 0 0x400 (cs0)
 - or - 0 0x400 0x400 (cs1)
 - or - 0 0x800 0x400 (cs2)
  - or - 0 0xC00 0x400 (cs3)
  - and -
 1 0 0x100; (for all cs)

 For example for cs2 child node the resulting mem range 0 will be calculated 
 as

 from: 0x3000 + (0 0x800 - 0 0)
 size: 0x400

 We don't encode CS number in reg/ranges, because it will allow simply change
 AEMIF DT definitions depending on each SoC
 (AEMIF CS memory range can be continuous as above or not, if not - additional
 range/partition can be added and child device can select the proper one).
 
 This is quite confusing.  I think the ranges property needs far more 
 description as part of the top level controller node.  It spec out what the 
 various fields are in the ranges property.
 

Yes, you are right, description is quite poor. I should describe it more clearly

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

Re: [PATCH 1/2] arm: dts: keystone: add watchdog entry

[ivan.khoronzhuk]

+ CC
devicet...@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-kernel@vger.kernel.org

On 12/10/2013 04:47 PM, Ivan Khoronzhuk wrote:

Add watchdog entry to keystone device tree.

Acked-by: Guenter Roeck li...@roeck-us.net
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
Based on
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
keystone/master

  arch/arm/boot/dts/keystone.dtsi |6 ++
  1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index f6d6d9e..54a8ff7 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -181,5 +181,11 @@
interrupts = GIC_SPI 300 IRQ_TYPE_EDGE_RISING;
clocks = clkspi;
};
+
+   wdt: wdt@022f0080 {
+   compatible = ti,keystone-wdt,ti,davinci-wdt;
+   reg = 0x022f0080 0x80;
+   clocks = clkwdtimer0;
+   };
};
  };




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

Re: [PATCH 2/2] arm: keystone: enable watchdog support

[ivan.khoronzhuk]

+ CC
devicet...@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-kernel@vger.kernel.org

On 12/10/2013 04:47 PM, Ivan Khoronzhuk wrote:

After Keystone watchdog driver updates are already merged we can
enable WDT in config.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
Based on
git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
keystone/master

  arch/arm/configs/keystone_defconfig |2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index 9943e5d..8bd940c 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -129,6 +129,8 @@ CONFIG_SPI_DAVINCI=y
  CONFIG_SPI_SPIDEV=y
  # CONFIG_HWMON is not set
  CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_DAVINCI_WATCHDOG=y
  # CONFIG_USB_SUPPORT is not set
  CONFIG_DMADEVICES=y
  CONFIG_COMMON_CLK_DEBUG=y




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

Re: [PATCH v3] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 12/06/2013 11:04 PM, Sekhar Nori wrote:
> On 12/5/2013 11:41 PM, Ivan Khoronzhuk wrote:
> 
>> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c 
>> b/arch/arm/mach-davinci/board-mityomapl138.c
>> index 7aa105b..98a66ff 100644
>> --- a/arch/arm/mach-davinci/board-mityomapl138.c
>> +++ b/arch/arm/mach-davinci/board-mityomapl138.c
>> @@ -432,6 +432,9 @@ static void __init mityomapl138_setup_nand(void)
>>   {
>>  platform_add_devices(mityomapl138_devices,
>>   ARRAY_SIZE(mityomapl138_devices));
>> +
>> +if (davinci_aemif_setup(_nandflash_device))
>> +pr_warn("%s: Cannot configure AEMIF.\n", __func__);
>>   }
> 
> I must be missing something, but exactly why is this required for
> board-mityomapl138.c?
> 
> Thanks,
> Sekhar
> 

board-mityomapl138.c - only one board file with NAND_BUSWIDTH_16 option set in 
pdata.
By default bus width is treated as 8 bit, in another case we have to set it.
Currently bus width setup is done in davinci_aemif_setup(). So, to set bus width
correctly we have to call davinci_aemif_setup() for board in question.

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

Re: [PATCH v3] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 12/06/2013 11:04 PM, Sekhar Nori wrote:
 On 12/5/2013 11:41 PM, Ivan Khoronzhuk wrote:
 
 diff --git a/arch/arm/mach-davinci/board-mityomapl138.c 
 b/arch/arm/mach-davinci/board-mityomapl138.c
 index 7aa105b..98a66ff 100644
 --- a/arch/arm/mach-davinci/board-mityomapl138.c
 +++ b/arch/arm/mach-davinci/board-mityomapl138.c
 @@ -432,6 +432,9 @@ static void __init mityomapl138_setup_nand(void)
   {
  platform_add_devices(mityomapl138_devices,
   ARRAY_SIZE(mityomapl138_devices));
 +
 +if (davinci_aemif_setup(mityomapl138_nandflash_device))
 +pr_warn(%s: Cannot configure AEMIF.\n, __func__);
   }
 
 I must be missing something, but exactly why is this required for
 board-mityomapl138.c?
 
 Thanks,
 Sekhar
 

board-mityomapl138.c - only one board file with NAND_BUSWIDTH_16 option set in 
pdata.
By default bus width is treated as 8 bit, in another case we have to set it.
Currently bus width setup is done in davinci_aemif_setup(). So, to set bus width
correctly we have to call davinci_aemif_setup() for board in question.

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

Re: [PATCH v4 1/5] watchdog: davinci: change driver to use WDT core

[ivan.khoronzhuk]

On 12/04/2013 08:58 PM, Guenter Roeck wrote:

On Wed, Dec 04, 2013 at 08:42:31PM +0200, ivan.khoronzhuk wrote:

On 12/04/2013 08:28 PM, Guenter Roeck wrote:

On Wed, Dec 04, 2013 at 11:34:46PM +0530, Sekhar Nori wrote:

On 11/27/2013 6:18 PM, Ivan Khoronzhuk wrote:

To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.

Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.

The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.

The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.

Acked-by: Santosh Shilimkar 
Reviewed-by: Guenter Roeck 
Signed-off-by: Ivan Khoronzhuk 
---
   drivers/watchdog/Kconfig   |2 +
   drivers/watchdog/davinci_wdt.c |  147 
++--
   2 files changed, 37 insertions(+), 112 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 5be6e91..eb8c89d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -271,6 +271,8 @@ config IOP_WATCHDOG
   config DAVINCI_WATCHDOG
tristate "DaVinci watchdog"
depends on ARCH_DAVINCI
+   select WATCHDOG_CORE
+   select WATCHDOG_NOWAYOUT


Its not clear for change log why NOWAYOUT needs to be forced on all the
time for all users of DaVinci watchdog.


... you are right




Actually, thinking about it, it is not necessary and can be replaced with

watchdog_set_nowayout(wdd, 1);


Good idea, I'll replace watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT) on it.
And delete "select WATCHDOG_NOWAYOUT"



In other words, there is no need to force NOWAYOUT on _other_ watchdogs which
may be present in the system. Still, you are right, it would be nice to explain
in the changelog (or maybe even better as comment in the code) why it is
enforced.

Guenter



Only question, should I repost only this patch or whole series?


Reposting only this patch should be sufficient if the others did not change.

Thanks,
Guenter



Thanks.
It is a pity, but along with this patch I have to change 2 patches,
so I'll send whole series.

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

Re: [PATCH v4 1/5] watchdog: davinci: change driver to use WDT core

[ivan.khoronzhuk]

On 12/04/2013 08:28 PM, Guenter Roeck wrote:
> On Wed, Dec 04, 2013 at 11:34:46PM +0530, Sekhar Nori wrote:
>> On 11/27/2013 6:18 PM, Ivan Khoronzhuk wrote:
>>> To reduce code duplicate and increase code readability use WDT core
>>> code to handle WDT interface.
>>>
>>> Remove io_lock as the WDT core uses mutex to lock each wdt device.
>>> Remove wdt_state as the WDT core tracks state with its own variable.
>>>
>>> The watchdog_init_timeout() can read timeout value from timeout-sec
>>> property if the passed value is out of bounds. The heartbeat is
>>> initialized in next way. If heartbeat is not set thought module
>>> parameter, try to read it's value from WDT node timeout-sec property.
>>> If node has no one, use default value.
>>>
>>> The heartbeat is hold in wdd->timeout by WDT core, so use it in
>>> order to set timeout period.
>>>
>>> Acked-by: Santosh Shilimkar 
>>> Reviewed-by: Guenter Roeck 
>>> Signed-off-by: Ivan Khoronzhuk 
>>> ---
>>>   drivers/watchdog/Kconfig   |2 +
>>>   drivers/watchdog/davinci_wdt.c |  147 
>>> ++--
>>>   2 files changed, 37 insertions(+), 112 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
>>> index 5be6e91..eb8c89d 100644
>>> --- a/drivers/watchdog/Kconfig
>>> +++ b/drivers/watchdog/Kconfig
>>> @@ -271,6 +271,8 @@ config IOP_WATCHDOG
>>>   config DAVINCI_WATCHDOG
>>> tristate "DaVinci watchdog"
>>> depends on ARCH_DAVINCI
>>> +   select WATCHDOG_CORE
>>> +   select WATCHDOG_NOWAYOUT
>>
>> Its not clear for change log why NOWAYOUT needs to be forced on all the
>> time for all users of DaVinci watchdog.

... you are right

>>
> Actually, thinking about it, it is not necessary and can be replaced with
> 
>   watchdog_set_nowayout(wdd, 1);

Good idea, I'll replace watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT) on it.
And delete "select WATCHDOG_NOWAYOUT"

> 
> In other words, there is no need to force NOWAYOUT on _other_ watchdogs which
> may be present in the system. Still, you are right, it would be nice to 
> explain
> in the changelog (or maybe even better as comment in the code) why it is
> enforced.
> 
> Guenter
> 

Only question, should I repost only this patch or whole series?

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

Re: [PATCH v2] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 11/29/2013 06:38 AM, Sekhar Nori wrote:

On Wednesday 27 November 2013 08:01 PM, Ivan Khoronzhuk wrote:

The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.

The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver.

To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.

The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.

The long device name "davinci_ntosd2_nandflash_device" was renamed
to "ntosd2_nandflash" as requested by Sekhar Nori, because after
adding changes the line is so broken that its almost unreadable.

Signed-off-by: Ivan Khoronzhuk 


This patch can be simplified in some places.


---
v2..v1:
- enabled AEMIF clock
- removed EXPORT_SYMBOL(davinci_aemif_setup)
- renamed ugly name davinci_ntosd2_nandflash_device

CC:
Sekhar Nori 

  arch/arm/mach-davinci/aemif.c   |   89 ++-
  arch/arm/mach-davinci/board-da830-evm.c |3 +
  arch/arm/mach-davinci/board-da850-evm.c |3 +
  arch/arm/mach-davinci/board-dm355-evm.c |5 ++
  arch/arm/mach-davinci/board-dm355-leopard.c |5 ++
  arch/arm/mach-davinci/board-dm365-evm.c |4 +
  arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
  arch/arm/mach-davinci/board-dm646x-evm.c|3 +
  arch/arm/mach-davinci/board-mityomapl138.c  |3 +
  arch/arm/mach-davinci/board-neuros-osd2.c   |   13 +++-
  arch/arm/mach-davinci/devices-tnetv107x.c   |3 +
  drivers/mtd/nand/davinci_nand.c |   23 --
  include/linux/platform_data/mtd-davinci-aemif.h |5 +-


Most of these boards dont really have a timing structure defined.
Instead of blindly calling AEMIF setup on all boards, it can be
done only on boards that actually need it.


  /*
   * aemif_calc_rate - calculate timing data.
   * @wanted: The cycle time needed in nanoseconds.
@@ -86,7 +98,7 @@ static int aemif_calc_rate(int wanted, unsigned long clk, int 
max)
   *
   * Returns 0 on success, else negative errno.
   */
-int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
+static int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,


passing the clkrate to this function helps avoid a repeated clk_get().
I made these changes locally and here is the updated patch:

---8<---
 From cdea7d6f753db09447fe2232959864ab999fe565 Mon Sep 17 00:00:00 2001
From: Ivan Khoronzhuk 
Date: Wed, 27 Nov 2013 16:31:34 +0200
Subject: [PATCH 1/1] ARM: davinci: aemif: get rid of davinci-nand driver
  dependency on aemif

The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.

The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver. The TI AEMIF driver cannot
be used on all current DaVinci platforms since it is DT-only.

To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.

The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.

Signed-off-by: Ivan Khoronzhuk 
Signed-off-by: Sekhar Nori 
---
  arch/arm/mach-davinci/aemif.c   |  106 ---
  arch/arm/mach-davinci/board-da830-evm.c |3 +
  arch/arm/mach-davinci/board-da850-evm.c |3 +
  arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
  arch/arm/mach-davinci/board-dm646x-evm.c|3 +
  drivers/mtd/nand/davinci_nand.c |   23 -
  include/linux/platform_data/mtd-davinci-aemif.h |5 +-
  7 files changed, 112 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index f091a90..e6dfc58 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -15,6 +15,7 @@
  #include 
  #include 

+#include 
  #include 

  /* Timing value configuration */
@@ -43,6 +44,17 @@
WSTROBE(WSTROBE_MAX) | \
WSETUP(WSETUP_MAX))

+static inline unsigned int davinci_aemif_readl(void __iomem *base, int offset)
+{
+   return readl_relaxed(base + offset);
+}
+
+static inline void davinci_aemif_writel(void __iomem *base,
+   int offset, unsigned long value)
+{
+   writel_relaxed(value, base + offset);
+}
+
  /*
   * aemif_calc_rate - calculate timing data.
   * @wanted: The cycle time needed in nanoseconds.
@@ -76,6 +88,7 @@ static int aemif_calc_rate(int wanted, unsigned long clk, int 
max)
   * @t: timing values 

Re: [PATCH v2] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 11/29/2013 06:38 AM, Sekhar Nori wrote:

On Wednesday 27 November 2013 08:01 PM, Ivan Khoronzhuk wrote:

The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.

The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver.

To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.

The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.

The long device name davinci_ntosd2_nandflash_device was renamed
to ntosd2_nandflash as requested by Sekhar Nori, because after
adding changes the line is so broken that its almost unreadable.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com


This patch can be simplified in some places.


---
v2..v1:
- enabled AEMIF clock
- removed EXPORT_SYMBOL(davinci_aemif_setup)
- renamed ugly name davinci_ntosd2_nandflash_device

CC:
Sekhar Nori nsek...@ti.com

  arch/arm/mach-davinci/aemif.c   |   89 ++-
  arch/arm/mach-davinci/board-da830-evm.c |3 +
  arch/arm/mach-davinci/board-da850-evm.c |3 +
  arch/arm/mach-davinci/board-dm355-evm.c |5 ++
  arch/arm/mach-davinci/board-dm355-leopard.c |5 ++
  arch/arm/mach-davinci/board-dm365-evm.c |4 +
  arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
  arch/arm/mach-davinci/board-dm646x-evm.c|3 +
  arch/arm/mach-davinci/board-mityomapl138.c  |3 +
  arch/arm/mach-davinci/board-neuros-osd2.c   |   13 +++-
  arch/arm/mach-davinci/devices-tnetv107x.c   |3 +
  drivers/mtd/nand/davinci_nand.c |   23 --
  include/linux/platform_data/mtd-davinci-aemif.h |5 +-


Most of these boards dont really have a timing structure defined.
Instead of blindly calling AEMIF setup on all boards, it can be
done only on boards that actually need it.


  /*
   * aemif_calc_rate - calculate timing data.
   * @wanted: The cycle time needed in nanoseconds.
@@ -86,7 +98,7 @@ static int aemif_calc_rate(int wanted, unsigned long clk, int 
max)
   *
   * Returns 0 on success, else negative errno.
   */
-int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
+static int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,


passing the clkrate to this function helps avoid a repeated clk_get().
I made these changes locally and here is the updated patch:

---8---
 From cdea7d6f753db09447fe2232959864ab999fe565 Mon Sep 17 00:00:00 2001
From: Ivan Khoronzhuk ivan.khoronz...@ti.com
Date: Wed, 27 Nov 2013 16:31:34 +0200
Subject: [PATCH 1/1] ARM: davinci: aemif: get rid of davinci-nand driver
  dependency on aemif

The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.

The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver. The TI AEMIF driver cannot
be used on all current DaVinci platforms since it is DT-only.

To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.

The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
  arch/arm/mach-davinci/aemif.c   |  106 ---
  arch/arm/mach-davinci/board-da830-evm.c |3 +
  arch/arm/mach-davinci/board-da850-evm.c |3 +
  arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
  arch/arm/mach-davinci/board-dm646x-evm.c|3 +
  drivers/mtd/nand/davinci_nand.c |   23 -
  include/linux/platform_data/mtd-davinci-aemif.h |5 +-
  7 files changed, 112 insertions(+), 36 deletions(-)

diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index f091a90..e6dfc58 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -15,6 +15,7 @@
  #include linux/module.h
  #include linux/time.h

+#include linux/platform_data/mtd-davinci.h
  #include linux/platform_data/mtd-davinci-aemif.h

  /* Timing value configuration */
@@ -43,6 +44,17 @@
WSTROBE(WSTROBE_MAX) | \
WSETUP(WSETUP_MAX))

+static inline unsigned int davinci_aemif_readl(void __iomem *base, int offset)
+{
+   return readl_relaxed(base + offset);
+}
+
+static inline void davinci_aemif_writel(void __iomem *base,
+   int offset, unsigned long value)
+{
+   writel_relaxed(value, base + offset);
+}
+
  /*
   * aemif_calc_rate 

Re: [PATCH v4 1/5] watchdog: davinci: change driver to use WDT core

[ivan.khoronzhuk]

On 12/04/2013 08:28 PM, Guenter Roeck wrote:
 On Wed, Dec 04, 2013 at 11:34:46PM +0530, Sekhar Nori wrote:
 On 11/27/2013 6:18 PM, Ivan Khoronzhuk wrote:
 To reduce code duplicate and increase code readability use WDT core
 code to handle WDT interface.

 Remove io_lock as the WDT core uses mutex to lock each wdt device.
 Remove wdt_state as the WDT core tracks state with its own variable.

 The watchdog_init_timeout() can read timeout value from timeout-sec
 property if the passed value is out of bounds. The heartbeat is
 initialized in next way. If heartbeat is not set thought module
 parameter, try to read it's value from WDT node timeout-sec property.
 If node has no one, use default value.

 The heartbeat is hold in wdd-timeout by WDT core, so use it in
 order to set timeout period.

 Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
 Reviewed-by: Guenter Roeck li...@roeck-us.net
 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
 ---
   drivers/watchdog/Kconfig   |2 +
   drivers/watchdog/davinci_wdt.c |  147 
 ++--
   2 files changed, 37 insertions(+), 112 deletions(-)

 diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
 index 5be6e91..eb8c89d 100644
 --- a/drivers/watchdog/Kconfig
 +++ b/drivers/watchdog/Kconfig
 @@ -271,6 +271,8 @@ config IOP_WATCHDOG
   config DAVINCI_WATCHDOG
 tristate DaVinci watchdog
 depends on ARCH_DAVINCI
 +   select WATCHDOG_CORE
 +   select WATCHDOG_NOWAYOUT

 Its not clear for change log why NOWAYOUT needs to be forced on all the
 time for all users of DaVinci watchdog.

... you are right


 Actually, thinking about it, it is not necessary and can be replaced with
 
   watchdog_set_nowayout(wdd, 1);

Good idea, I'll replace watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT) on it.
And delete select WATCHDOG_NOWAYOUT

 
 In other words, there is no need to force NOWAYOUT on _other_ watchdogs which
 may be present in the system. Still, you are right, it would be nice to 
 explain
 in the changelog (or maybe even better as comment in the code) why it is
 enforced.
 
 Guenter
 

Only question, should I repost only this patch or whole series?

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

Re: [PATCH v4 1/5] watchdog: davinci: change driver to use WDT core

[ivan.khoronzhuk]

On 12/04/2013 08:58 PM, Guenter Roeck wrote:

On Wed, Dec 04, 2013 at 08:42:31PM +0200, ivan.khoronzhuk wrote:

On 12/04/2013 08:28 PM, Guenter Roeck wrote:

On Wed, Dec 04, 2013 at 11:34:46PM +0530, Sekhar Nori wrote:

On 11/27/2013 6:18 PM, Ivan Khoronzhuk wrote:

To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.

Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.

The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.

The heartbeat is hold in wdd-timeout by WDT core, so use it in
order to set timeout period.

Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Guenter Roeck li...@roeck-us.net
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
   drivers/watchdog/Kconfig   |2 +
   drivers/watchdog/davinci_wdt.c |  147 
++--
   2 files changed, 37 insertions(+), 112 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 5be6e91..eb8c89d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -271,6 +271,8 @@ config IOP_WATCHDOG
   config DAVINCI_WATCHDOG
tristate DaVinci watchdog
depends on ARCH_DAVINCI
+   select WATCHDOG_CORE
+   select WATCHDOG_NOWAYOUT


Its not clear for change log why NOWAYOUT needs to be forced on all the
time for all users of DaVinci watchdog.


... you are right




Actually, thinking about it, it is not necessary and can be replaced with

watchdog_set_nowayout(wdd, 1);


Good idea, I'll replace watchdog_set_nowayout(wdd, WATCHDOG_NOWAYOUT) on it.
And delete select WATCHDOG_NOWAYOUT



In other words, there is no need to force NOWAYOUT on _other_ watchdogs which
may be present in the system. Still, you are right, it would be nice to explain
in the changelog (or maybe even better as comment in the code) why it is
enforced.

Guenter



Only question, should I repost only this patch or whole series?


Reposting only this patch should be sufficient if the others did not change.

Thanks,
Guenter



Thanks.
It is a pity, but along with this patch I have to change 2 patches,
so I'll send whole series.

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

Re: [PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver

[ivan.khoronzhuk]

On 11/29/2013 05:10 PM, Santosh Shilimkar wrote:

On Friday 29 November 2013 10:00 AM, Grygorii Strashko wrote:

Hi Kumar Gala,

On 11/22/2013 11:06 PM, Kumar Gala wrote:


On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk  wrote:


On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:

+   the chip select signal.
+   Minimum value is 1 (0 treated as 1).
+
+- ti,cs-wsetup:write setup width, ns
+   Time between the beginning of a memory cycle
+   and the activation of write strobe.
+   Minimum value is 1 (0 treated as 1).
+
+- ti,cs-wstrobe:   write strobe width, ns
+   Time between the activation and deactivation of
+   the write strobe.
+   Minimum value is 1 (0 treated as 1).
+
+- ti,cs-whold: write hold width, ns
+   Time between the deactivation of the write
+   strobe and the end of the cycle (which may be
+   either an address change or the deactivation of
+   the chip select signal.
+   Minimum value is 1 (0 treated as 1).
+
+If any of the above parameters are absent, current parameter value will be 
taken
+from the corresponding HW reg.
+
+The name for cs node must be in format csN, where N is the cs number.


this is wired we should use reg instead to represent the cs as done for SPI
or a an other property

Best Regards,
J.



Ok, I will add new property cs-chipselect like following :

ti,cs-chipselect:   number of chipselect. Indicates on the
aemif driver which chipselect is used
for accessing the memory.
For compatibles "ti,davinci-aemif" and
"ti,keystone-aemif" it can be in range [0-3].
For compatible "ti,omap-L138-aemif" range is [2-5].

Is it OK?


Why do you need this? As it was mentioned just use reg:

So you’d have something like:

memory-controller@21000A00 {
…
nand:cs2@2 {
reg = <2 0 0>;
ranges;
...

}:
};


I'd prefer to continue with "ti,cs-chipselect" (this is more human friendly 
definition, as for me),
but if you insist - it can be changed as:
memory-controller@21000A00 {
compatible = "ti,keystone-aemif";
...

cs2 {
compatible = "ti,aemif-cs";
reg = <2>;
...
}

cs0 {
compatible = "ti,aemif-cs";
reg = <0>;
...
}



However, I’m confused by the example in which you have:

+   nand@0,0x800 {
+   compatible = "ti,davinci-nand";
+   reg = <0 0x800 0x400
+  1 0x000 0x100>;
+
+   .. see davinci-nand.txt
+   };

What chipselects is this on 0 & 1?


As I described in https://lkml.org/lkml/2013/11/26/282 we are not encoding CS 
number in reg
  - it's memory partition number.

Also, I'd like to note that we *DO NOT introduce* NAND device bindings here.
The Davinci NAND bindings was introduced and accepted more then one year ago, 
and
we've just updated its a bit (keeping full compatibility) and reused
(see https://lkml.org/lkml/2013/11/21/182).
And the CS number is encoded for Davinci NAND node using standalone property
"ti,davinci-chipselect" and we need to provide (2) two memory ranges to it,
as result we can't encode CS number in "reg" for AEMIF child devices 
(NAND/NOR/etc),
as it will break bindings compatibility.

In this document, NAND node is used just as an example of child node.


The above should have been really captured in the commit log to get a better
picture. No way on earth, a reviewer can figure out whether this is new bindings
or copy of bindings already used.

Regards,
Santosh



Ok, I will add it.

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

Re: [PATCH 1/2] memory: ti-aemif: introduce AEMIF driver

[ivan.khoronzhuk]

On 11/29/2013 05:32 PM, Santosh Shilimkar wrote:
> On Wednesday 20 November 2013 10:46 AM, Ivan Khoronzhuk wrote:
>> Add new AEMIF driver for EMIF16 Texas Instruments controller.
>> The EMIF16 module is intended to provide a glue-less interface to
>> a variety of asynchronous memory devices like ASRA M, NOR and NAND
>> memory. A total of 256M bytes of any of these memories can be
>> accessed at any given time via four chip selects with 64M byte access
>> per chip select.
>>
> Please add the number of CS info here.
> 

Ok

>> Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR
>> are not supported.
>>
>> This controller is used on SoCs like Davinci, Keysone2
>>
> 
>   
>> For more informations see documentation:
>> Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
>> OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
>> Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
>>
> This information probably can go below ---
>

Ok

>> Signed-off-by: Ivan Khoronzhuk 
>> ---
>>   drivers/memory/Kconfig|   11 ++
>>   drivers/memory/Makefile   |1 +
>>   drivers/memory/ti-aemif.c |  415 
>> +
>>   3 files changed, 427 insertions(+)
>>   create mode 100644 drivers/memory/ti-aemif.c
>>
>> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
>> index 29a11db..cc0e3c8 100644
>> --- a/drivers/memory/Kconfig
>> +++ b/drivers/memory/Kconfig
>> @@ -7,6 +7,17 @@ menuconfig MEMORY
>>   
>>   if MEMORY
>>   
>> +config TI_AEMIF
>> +bool "Texas Instruments AEMIF driver"
> Driver can be build as loadable module as well so fix above.
> 

Ok

>> +depends on (ARCH_DAVINCI || ARCH_KEYSTONE) && OF
>> +help
>> +  This driver is for the AEMIF module available in Texas Instruments
>> +  SoCs. AEMIF stands for Asynchronous External Memory Interface and
>> +  is intended to provide a glue-less interface to a variety of
>> +  asynchronuous memory devices like ASRAM, NOR and NAND memory. A total
>> +  of 256M bytes of any of these memories can be accessed at a given
>> +  time via four chip selects with 64M byte access per chip select.
>> +
>>   config TI_EMIF
>>  tristate "Texas Instruments EMIF driver"
>>  depends on ARCH_OMAP2PLUS
>> diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
>> index 969d923..d4e150c 100644
>> --- a/drivers/memory/Makefile
>> +++ b/drivers/memory/Makefile
>> @@ -5,6 +5,7 @@
>>   ifeq ($(CONFIG_DDR),y)
>>   obj-$(CONFIG_OF)   += of_memory.o
>>   endif
>> +obj-$(CONFIG_TI_AEMIF)  += ti-aemif.o
>>   obj-$(CONFIG_TI_EMIF)  += emif.o
>>   obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
>>   obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
>> diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
>> new file mode 100644
>> index 000..a4b479a
>> --- /dev/null
>> +++ b/drivers/memory/ti-aemif.c
>> @@ -0,0 +1,415 @@
>> +/*
>> + * TI AEMIF driver
>> + *
>> + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. 
>> http://www.ti.com/
>> + * Copyright (C) Heiko Schocher 
>> + * Copyright (C) Ivan Khoronzhuk 
>> + *
> You mean author above, right, Please fix that for both emails ids.
> 

Ok

>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define TA_SHIFT2
>> +#define RHOLD_SHIFT 4
>> +#define RSTROBE_SHIFT   7
>> +#define RSETUP_SHIFT13
>> +#define WHOLD_SHIFT 17
>> +#define WSTROBE_SHIFT   20
>> +#define WSETUP_SHIFT26
>> +#define EW_SHIFT30
>> +#define SS_SHIFT31
>> +
>> +#define TA(x)   ((x) << TA_SHIFT)
>> +#define RHOLD(x)((x) << RHOLD_SHIFT)
>> +#define RSTROBE(x)  ((x) << RSTROBE_SHIFT)
>> +#define RSETUP(x)   ((x) << RSETUP_SHIFT)
>> +#define WHOLD(x)((x) << WHOLD_SHIFT)
>> +#define WSTROBE(x)  ((x) << WSTROBE_SHIFT)
>> +#define WSETUP(x)   ((x) << WSETUP_SHIFT)
>> +#define EW(x)   ((x) << EW_SHIFT)
>> +#define SS(x)   ((x) << SS_SHIFT)
>> +
>> +#define ASIZE_MAX   0x1
>> +#define TA_MAX  0x3
>> +#define RHOLD_MAX   0x7
>> +#define RSTROBE_MAX 0x3f
>> +#define RSETUP_MAX  0xf
>> +#define WHOLD_MAX   0x7
>> +#define WSTROBE_MAX 0x3f
>> +#define WSETUP_MAX  0xf
>> +#define EW_MAX  0x1
>> +#define SS_MAX  0x1
>> +#define NUM_CS  4
>> +
>> +#define TA_VAL(x)   (((x) & TA(TA_MAX)) >> TA_SHIFT)
>> +#define RHOLD_VAL(x)(((x) & RHOLD(RHOLD_MAX)) >> RHOLD_SHIFT)
>> +#define RSTROBE_VAL(x)  (((x) & RSTROBE(RSTROBE_MAX)) >> RSTROBE_SHIFT)
>> +#define RSETUP_VAL(x)   (((x) & RSETUP(RSETUP_MAX)) >> RSETUP_SHIFT)
>> +#define WHOLD_VAL(x)(((x) & WHOLD(WHOLD_MAX)) >> WHOLD_SHIFT)
>> +#define 

Re: [PATCH v2 00/10] Reuse davinci-nand driver for Keystone arch

[ivan.khoronzhuk]

On 11/29/2013 06:28 PM, Santosh Shilimkar wrote:
> Ivan,
> On Thursday 21 November 2013 06:28 AM, Ivan Khoronzhuk wrote:
>> This series contains fixes and updates of Davinci nand driver in
>> order to reuse it for Keystone platform.
>>
>> The series is combination of two following series:
>> - Davinci nand driver fixes and updates:
>>https://lkml.org/lkml/2013/11/20/271
>> - Reuse davinci-nand driver for Keystone arch
>>https://lkml.org/lkml/2013/11/20/315
>>
>> Ivan Khoronzhuk (10):
>>mtd: nand: davinci: fix driver registration
>>mtd: nand: davinci: return ENOMEM if memory allocation is failed
>>mtd: nand: davinci: check required ti,davinci-chipselect property
>>mtd: nand: davinci: simplify error handling
>>mtd: nand: davinci: move bindings under mtd
>>mtd: nand: davinci: extend description of bindings
>>mtd: nand: davinci: adjust DT properties to MTD generic
>>mtd: nand: davinci: reuse driver for Keystone arch
>>mtd: nand: davinci: don't set timings if AEMIF is used
>>mtd: nand: davinci: don't request AEMIF address range
>>
>>   .../devicetree/bindings/arm/davinci/nand.txt   |   46 
>>   .../devicetree/bindings/mtd/davinci-nand.txt   |   94 
>>   drivers/mtd/nand/Kconfig   |6 +-
>>   drivers/mtd/nand/davinci_nand.c|  117 
>> +++-
>>   4 files changed, 164 insertions(+), 99 deletions(-)
>>   delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
>>   create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt
>>
> Please drop patch 9 from the series considering we are handling it
> differently and repost the entire series with David in cc. David
> has been lining up the patches.
> 
> Regards,
> Santosh
> 

Ok, I'll drop patch 9.
Only question about patch
ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
(http://www.spinics.net/lists/devicetree/msg13711.html).
How would be better, the series would be based on it or vice-versa?

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

Re: [PATCH v2 00/10] Reuse davinci-nand driver for Keystone arch

[ivan.khoronzhuk]

On 11/29/2013 06:28 PM, Santosh Shilimkar wrote:
 Ivan,
 On Thursday 21 November 2013 06:28 AM, Ivan Khoronzhuk wrote:
 This series contains fixes and updates of Davinci nand driver in
 order to reuse it for Keystone platform.

 The series is combination of two following series:
 - Davinci nand driver fixes and updates:
https://lkml.org/lkml/2013/11/20/271
 - Reuse davinci-nand driver for Keystone arch
https://lkml.org/lkml/2013/11/20/315

 Ivan Khoronzhuk (10):
mtd: nand: davinci: fix driver registration
mtd: nand: davinci: return ENOMEM if memory allocation is failed
mtd: nand: davinci: check required ti,davinci-chipselect property
mtd: nand: davinci: simplify error handling
mtd: nand: davinci: move bindings under mtd
mtd: nand: davinci: extend description of bindings
mtd: nand: davinci: adjust DT properties to MTD generic
mtd: nand: davinci: reuse driver for Keystone arch
mtd: nand: davinci: don't set timings if AEMIF is used
mtd: nand: davinci: don't request AEMIF address range

   .../devicetree/bindings/arm/davinci/nand.txt   |   46 
   .../devicetree/bindings/mtd/davinci-nand.txt   |   94 
   drivers/mtd/nand/Kconfig   |6 +-
   drivers/mtd/nand/davinci_nand.c|  117 
 +++-
   4 files changed, 164 insertions(+), 99 deletions(-)
   delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
   create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt

 Please drop patch 9 from the series considering we are handling it
 differently and repost the entire series with David in cc. David
 has been lining up the patches.
 
 Regards,
 Santosh
 

Ok, I'll drop patch 9.
Only question about patch
ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
(http://www.spinics.net/lists/devicetree/msg13711.html).
How would be better, the series would be based on it or vice-versa?

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

Re: [PATCH 1/2] memory: ti-aemif: introduce AEMIF driver

[ivan.khoronzhuk]

On 11/29/2013 05:32 PM, Santosh Shilimkar wrote:
 On Wednesday 20 November 2013 10:46 AM, Ivan Khoronzhuk wrote:
 Add new AEMIF driver for EMIF16 Texas Instruments controller.
 The EMIF16 module is intended to provide a glue-less interface to
 a variety of asynchronous memory devices like ASRA M, NOR and NAND
 memory. A total of 256M bytes of any of these memories can be
 accessed at any given time via four chip selects with 64M byte access
 per chip select.

 Please add the number of CS info here.
 

Ok

 Synchronous memories such as DDR1 SD RAM, SDR SDRAM and Mobile SDR
 are not supported.

 This controller is used on SoCs like Davinci, Keysone2

 
   
 For more informations see documentation:
 Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
 OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
 Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf

 This information probably can go below ---


Ok

 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
 ---
   drivers/memory/Kconfig|   11 ++
   drivers/memory/Makefile   |1 +
   drivers/memory/ti-aemif.c |  415 
 +
   3 files changed, 427 insertions(+)
   create mode 100644 drivers/memory/ti-aemif.c

 diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
 index 29a11db..cc0e3c8 100644
 --- a/drivers/memory/Kconfig
 +++ b/drivers/memory/Kconfig
 @@ -7,6 +7,17 @@ menuconfig MEMORY
   
   if MEMORY
   
 +config TI_AEMIF
 +bool Texas Instruments AEMIF driver
 Driver can be build as loadable module as well so fix above.
 

Ok

 +depends on (ARCH_DAVINCI || ARCH_KEYSTONE)  OF
 +help
 +  This driver is for the AEMIF module available in Texas Instruments
 +  SoCs. AEMIF stands for Asynchronous External Memory Interface and
 +  is intended to provide a glue-less interface to a variety of
 +  asynchronuous memory devices like ASRAM, NOR and NAND memory. A total
 +  of 256M bytes of any of these memories can be accessed at a given
 +  time via four chip selects with 64M byte access per chip select.
 +
   config TI_EMIF
  tristate Texas Instruments EMIF driver
  depends on ARCH_OMAP2PLUS
 diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
 index 969d923..d4e150c 100644
 --- a/drivers/memory/Makefile
 +++ b/drivers/memory/Makefile
 @@ -5,6 +5,7 @@
   ifeq ($(CONFIG_DDR),y)
   obj-$(CONFIG_OF)   += of_memory.o
   endif
 +obj-$(CONFIG_TI_AEMIF)  += ti-aemif.o
   obj-$(CONFIG_TI_EMIF)  += emif.o
   obj-$(CONFIG_MVEBU_DEVBUS) += mvebu-devbus.o
   obj-$(CONFIG_TEGRA20_MC)   += tegra20-mc.o
 diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
 new file mode 100644
 index 000..a4b479a
 --- /dev/null
 +++ b/drivers/memory/ti-aemif.c
 @@ -0,0 +1,415 @@
 +/*
 + * TI AEMIF driver
 + *
 + * Copyright (C) 2010 - 2013 Texas Instruments Incorporated. 
 http://www.ti.com/
 + * Copyright (C) Heiko Schocher h...@denx.de
 + * Copyright (C) Ivan Khoronzhuk ivan.khoronz...@ti.com
 + *
 You mean author above, right, Please fix that for both emails ids.
 

Ok

 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/clk.h
 +#include linux/err.h
 +#include linux/io.h
 +#include linux/kernel.h
 +#include linux/module.h
 +#include linux/of.h
 +#include linux/of_platform.h
 +#include linux/platform_device.h
 +
 +#define TA_SHIFT2
 +#define RHOLD_SHIFT 4
 +#define RSTROBE_SHIFT   7
 +#define RSETUP_SHIFT13
 +#define WHOLD_SHIFT 17
 +#define WSTROBE_SHIFT   20
 +#define WSETUP_SHIFT26
 +#define EW_SHIFT30
 +#define SS_SHIFT31
 +
 +#define TA(x)   ((x)  TA_SHIFT)
 +#define RHOLD(x)((x)  RHOLD_SHIFT)
 +#define RSTROBE(x)  ((x)  RSTROBE_SHIFT)
 +#define RSETUP(x)   ((x)  RSETUP_SHIFT)
 +#define WHOLD(x)((x)  WHOLD_SHIFT)
 +#define WSTROBE(x)  ((x)  WSTROBE_SHIFT)
 +#define WSETUP(x)   ((x)  WSETUP_SHIFT)
 +#define EW(x)   ((x)  EW_SHIFT)
 +#define SS(x)   ((x)  SS_SHIFT)
 +
 +#define ASIZE_MAX   0x1
 +#define TA_MAX  0x3
 +#define RHOLD_MAX   0x7
 +#define RSTROBE_MAX 0x3f
 +#define RSETUP_MAX  0xf
 +#define WHOLD_MAX   0x7
 +#define WSTROBE_MAX 0x3f
 +#define WSETUP_MAX  0xf
 +#define EW_MAX  0x1
 +#define SS_MAX  0x1
 +#define NUM_CS  4
 +
 +#define TA_VAL(x)   (((x)  TA(TA_MAX))  TA_SHIFT)
 +#define RHOLD_VAL(x)(((x)  RHOLD(RHOLD_MAX))  RHOLD_SHIFT)
 +#define RSTROBE_VAL(x)  (((x)  RSTROBE(RSTROBE_MAX))  RSTROBE_SHIFT)
 +#define RSETUP_VAL(x)   (((x)  RSETUP(RSETUP_MAX))  RSETUP_SHIFT)
 +#define WHOLD_VAL(x)(((x)  WHOLD(WHOLD_MAX))  WHOLD_SHIFT)
 +#define WSTROBE_VAL(x)  (((x)  WSTROBE(WSTROBE_MAX))  WSTROBE_SHIFT)
 +#define WSETUP_VAL(x)   (((x)  WSETUP(WSETUP_MAX))  WSETUP_SHIFT)
 +#define 

Re: [PATCH 2/2] memory: ti-aemif: add bindings for AEMIF driver

[ivan.khoronzhuk]

On 11/29/2013 05:10 PM, Santosh Shilimkar wrote:

On Friday 29 November 2013 10:00 AM, Grygorii Strashko wrote:

Hi Kumar Gala,

On 11/22/2013 11:06 PM, Kumar Gala wrote:


On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk ivan.khoronz...@ti.com wrote:


On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:

+   the chip select signal.
+   Minimum value is 1 (0 treated as 1).
+
+- ti,cs-wsetup:write setup width, ns
+   Time between the beginning of a memory cycle
+   and the activation of write strobe.
+   Minimum value is 1 (0 treated as 1).
+
+- ti,cs-wstrobe:   write strobe width, ns
+   Time between the activation and deactivation of
+   the write strobe.
+   Minimum value is 1 (0 treated as 1).
+
+- ti,cs-whold: write hold width, ns
+   Time between the deactivation of the write
+   strobe and the end of the cycle (which may be
+   either an address change or the deactivation of
+   the chip select signal.
+   Minimum value is 1 (0 treated as 1).
+
+If any of the above parameters are absent, current parameter value will be 
taken
+from the corresponding HW reg.
+
+The name for cs node must be in format csN, where N is the cs number.


this is wired we should use reg instead to represent the cs as done for SPI
or a an other property

Best Regards,
J.



Ok, I will add new property cs-chipselect like following :

ti,cs-chipselect:   number of chipselect. Indicates on the
aemif driver which chipselect is used
for accessing the memory.
For compatibles ti,davinci-aemif and
ti,keystone-aemif it can be in range [0-3].
For compatible ti,omap-L138-aemif range is [2-5].

Is it OK?


Why do you need this? As it was mentioned just use reg:

So you’d have something like:

memory-controller@21000A00 {
…
nand:cs2@2 {
reg = 2 0 0;
ranges;
...

}:
};


I'd prefer to continue with ti,cs-chipselect (this is more human friendly 
definition, as for me),
but if you insist - it can be changed as:
memory-controller@21000A00 {
compatible = ti,keystone-aemif;
...

cs2 {
compatible = ti,aemif-cs;
reg = 2;
...
}

cs0 {
compatible = ti,aemif-cs;
reg = 0;
...
}



However, I’m confused by the example in which you have:

+   nand@0,0x800 {
+   compatible = ti,davinci-nand;
+   reg = 0 0x800 0x400
+  1 0x000 0x100;
+
+   .. see davinci-nand.txt
+   };

What chipselects is this on 0  1?


As I described in https://lkml.org/lkml/2013/11/26/282 we are not encoding CS 
number in reg
  - it's memory partition number.

Also, I'd like to note that we *DO NOT introduce* NAND device bindings here.
The Davinci NAND bindings was introduced and accepted more then one year ago, 
and
we've just updated its a bit (keeping full compatibility) and reused
(see https://lkml.org/lkml/2013/11/21/182).
And the CS number is encoded for Davinci NAND node using standalone property
ti,davinci-chipselect and we need to provide (2) two memory ranges to it,
as result we can't encode CS number in reg for AEMIF child devices 
(NAND/NOR/etc),
as it will break bindings compatibility.

In this document, NAND node is used just as an example of child node.


The above should have been really captured in the commit log to get a better
picture. No way on earth, a reviewer can figure out whether this is new bindings
or copy of bindings already used.

Regards,
Santosh



Ok, I will add it.

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

Re: [PATCH v2] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 11/29/2013 06:38 AM, Sekhar Nori wrote:
> On Wednesday 27 November 2013 08:01 PM, Ivan Khoronzhuk wrote:
>> The problem that the set timings code contains the call of Davinci
>> platform function davinci_aemif_setup_timing() which is not
>> accessible if kernel is built for another platform like Keystone.
>>
>> The Keysone platform is going to use TI AEMIF driver.
>> If TI AEMIF is used we don't need to set timings and bus width.
>> It is done by AEMIF driver.
>>
>> To get rid of davinci-nand driver dependency on aemif platform code
>> we moved aemif code to davinci platform.
>>
>> The platform AEMIF code (aemif.c) has to be removed once Davinci
>> will be converted to DT and use ti-aemif.c driver.
>>
>> The long device name "davinci_ntosd2_nandflash_device" was renamed
>> to "ntosd2_nandflash" as requested by Sekhar Nori, because after
>> adding changes the line is so broken that its almost unreadable.
>>
>> Signed-off-by: Ivan Khoronzhuk 
> 
> This patch can be simplified in some places.
> 
>> ---
>> v2..v1:
>> - enabled AEMIF clock
>> - removed EXPORT_SYMBOL(davinci_aemif_setup)
>> - renamed ugly name davinci_ntosd2_nandflash_device
>>
>> CC:
>> Sekhar Nori 
>>
>>   arch/arm/mach-davinci/aemif.c   |   89 
>> ++-
>>   arch/arm/mach-davinci/board-da830-evm.c |3 +
>>   arch/arm/mach-davinci/board-da850-evm.c |3 +
>>   arch/arm/mach-davinci/board-dm355-evm.c |5 ++
>>   arch/arm/mach-davinci/board-dm355-leopard.c |5 ++
>>   arch/arm/mach-davinci/board-dm365-evm.c |4 +
>>   arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
>>   arch/arm/mach-davinci/board-dm646x-evm.c|3 +
>>   arch/arm/mach-davinci/board-mityomapl138.c  |3 +
>>   arch/arm/mach-davinci/board-neuros-osd2.c   |   13 +++-
>>   arch/arm/mach-davinci/devices-tnetv107x.c   |3 +
>>   drivers/mtd/nand/davinci_nand.c |   23 --
>>   include/linux/platform_data/mtd-davinci-aemif.h |5 +-
> 
> Most of these boards dont really have a timing structure defined.
> Instead of blindly calling AEMIF setup on all boards, it can be
> done only on boards that actually need it.
> 

Yes, but in such case we should add AEMIF setup to
arch/arm/mach-davinci/board-mityomapl138.c also,
because it has: .options = NAND_BUSWIDTH_16

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

Re: [PATCH v2] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 11/29/2013 06:38 AM, Sekhar Nori wrote:
 On Wednesday 27 November 2013 08:01 PM, Ivan Khoronzhuk wrote:
 The problem that the set timings code contains the call of Davinci
 platform function davinci_aemif_setup_timing() which is not
 accessible if kernel is built for another platform like Keystone.

 The Keysone platform is going to use TI AEMIF driver.
 If TI AEMIF is used we don't need to set timings and bus width.
 It is done by AEMIF driver.

 To get rid of davinci-nand driver dependency on aemif platform code
 we moved aemif code to davinci platform.

 The platform AEMIF code (aemif.c) has to be removed once Davinci
 will be converted to DT and use ti-aemif.c driver.

 The long device name davinci_ntosd2_nandflash_device was renamed
 to ntosd2_nandflash as requested by Sekhar Nori, because after
 adding changes the line is so broken that its almost unreadable.

 Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
 
 This patch can be simplified in some places.
 
 ---
 v2..v1:
 - enabled AEMIF clock
 - removed EXPORT_SYMBOL(davinci_aemif_setup)
 - renamed ugly name davinci_ntosd2_nandflash_device

 CC:
 Sekhar Nori nsek...@ti.com

   arch/arm/mach-davinci/aemif.c   |   89 
 ++-
   arch/arm/mach-davinci/board-da830-evm.c |3 +
   arch/arm/mach-davinci/board-da850-evm.c |3 +
   arch/arm/mach-davinci/board-dm355-evm.c |5 ++
   arch/arm/mach-davinci/board-dm355-leopard.c |5 ++
   arch/arm/mach-davinci/board-dm365-evm.c |4 +
   arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
   arch/arm/mach-davinci/board-dm646x-evm.c|3 +
   arch/arm/mach-davinci/board-mityomapl138.c  |3 +
   arch/arm/mach-davinci/board-neuros-osd2.c   |   13 +++-
   arch/arm/mach-davinci/devices-tnetv107x.c   |3 +
   drivers/mtd/nand/davinci_nand.c |   23 --
   include/linux/platform_data/mtd-davinci-aemif.h |5 +-
 
 Most of these boards dont really have a timing structure defined.
 Instead of blindly calling AEMIF setup on all boards, it can be
 done only on boards that actually need it.
 

Yes, but in such case we should add AEMIF setup to
arch/arm/mach-davinci/board-mityomapl138.c also,
because it has: .options = NAND_BUSWIDTH_16

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

Re: [PATCH] watchdog: davinci: rename platform driver to davinci-wdt

[ivan.khoronzhuk]

On 11/28/2013 08:04 AM, Sekhar Nori wrote:

On Wednesday 27 November 2013 09:27 PM, Guenter Roeck wrote:

On 11/27/2013 06:00 AM, Sekhar Nori wrote:

On Wednesday 27 November 2013 07:01 PM, Ivan Khoronzhuk wrote:

As we switch to use the watchdog core which permits more than one
active watchdog in the system, rename platform driver to
"davinci-wdt" to be identifiable.

Signed-off-by: Ivan Khoronzhuk 


Looks good to me. Since bulk of this patch touches mach-davinci, I would
like to take this through my tree to avoid conflicts with other
mach-davinci patches I accept.



Good idea, and makes sense.


Added to v3.14/soc with your Reviewed-by

Thanks,
Sekhar

[1]
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/soc



Thanks, Sekhar.
What about other WDT patches, are you OK with them?
https://lkml.org/lkml/2013/11/27/164

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

Re: [PATCH v2] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

+ CC Santosh Shilimkar

On 11/27/2013 04:31 PM, Ivan Khoronzhuk wrote:

The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.

The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver.

To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.

The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.

The long device name "davinci_ntosd2_nandflash_device" was renamed
to "ntosd2_nandflash" as requested by Sekhar Nori, because after
adding changes the line is so broken that its almost unreadable.

Signed-off-by: Ivan Khoronzhuk 
---
v2..v1:
- enabled AEMIF clock
- removed EXPORT_SYMBOL(davinci_aemif_setup)
- renamed ugly name davinci_ntosd2_nandflash_device

CC:
Sekhar Nori 

  arch/arm/mach-davinci/aemif.c   |   89 ++-
  arch/arm/mach-davinci/board-da830-evm.c |3 +
  arch/arm/mach-davinci/board-da850-evm.c |3 +
  arch/arm/mach-davinci/board-dm355-evm.c |5 ++
  arch/arm/mach-davinci/board-dm355-leopard.c |5 ++
  arch/arm/mach-davinci/board-dm365-evm.c |4 +
  arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
  arch/arm/mach-davinci/board-dm646x-evm.c|3 +
  arch/arm/mach-davinci/board-mityomapl138.c  |3 +
  arch/arm/mach-davinci/board-neuros-osd2.c   |   13 +++-
  arch/arm/mach-davinci/devices-tnetv107x.c   |3 +
  drivers/mtd/nand/davinci_nand.c |   23 --
  include/linux/platform_data/mtd-davinci-aemif.h |5 +-
  13 files changed, 133 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index f091a90..64dccfc 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -16,6 +16,7 @@
  #include 

  #include 
+#include 

  /* Timing value configuration */

@@ -43,6 +44,17 @@
WSTROBE(WSTROBE_MAX) | \
WSETUP(WSETUP_MAX))

+static inline unsigned int davinci_aemif_readl(void __iomem *base, int offset)
+{
+   return readl_relaxed(base + offset);
+}
+
+static inline void davinci_aemif_writel(void __iomem *base,
+   int offset, unsigned long value)
+{
+   writel_relaxed(value, base + offset);
+}
+
  /*
   * aemif_calc_rate - calculate timing data.
   * @wanted: The cycle time needed in nanoseconds.
@@ -86,7 +98,7 @@ static int aemif_calc_rate(int wanted, unsigned long clk, int 
max)
   *
   * Returns 0 on success, else negative errno.
   */
-int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
+static int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
void __iomem *base, unsigned cs)
  {
unsigned set, val;
@@ -130,4 +142,77 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing 
*t,

return 0;
  }
-EXPORT_SYMBOL(davinci_aemif_setup_timing);
+
+/**
+ * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
+ * @pdev - link to platform device to setup settings for
+ *
+ * This function does not use any locking while programming the AEMIF
+ * because it is expected that there is only one user of a given
+ * chip-select.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int davinci_aemif_setup(struct platform_device *pdev)
+{
+   struct davinci_nand_pdata *pdata = dev_get_platdata(>dev);
+   uint32_t val;
+   struct resource *res;
+   void __iomem *base;
+   struct clk* clk;
+   int ret = 0;
+
+   clk = clk_get(>dev, "aemif");
+   if (IS_ERR(clk)) {
+   ret = PTR_ERR(clk);
+   dev_dbg(>dev, "unable to get AEMIF clock, err %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(clk);
+   if (ret < 0) {
+   dev_dbg(>dev, "unable to enable AEMIF clock, err %d\n",
+   ret);
+   return ret;
+   }
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res) {
+   dev_err(>dev, "cannot get IORESOURCE_MEM\n");
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   base = ioremap(res->start, resource_size(res));
+   if (!base) {
+   dev_err(>dev, "ioremap failed for resource %pR\n", res);
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   /*
+* Setup Async configuration register in case we did not boot
+* from NAND and so bootloader did not bother to set it up.
+*/
+   val = davinci_aemif_readl(base, A1CR_OFFSET + pdev->id * 4);
+   /*
+* Extended Wait is not valid and Select Strobe mode is not

Re: [PATCH v2] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

+ CC Santosh Shilimkar

On 11/27/2013 04:31 PM, Ivan Khoronzhuk wrote:

The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.

The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver.

To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.

The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.

The long device name davinci_ntosd2_nandflash_device was renamed
to ntosd2_nandflash as requested by Sekhar Nori, because after
adding changes the line is so broken that its almost unreadable.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
v2..v1:
- enabled AEMIF clock
- removed EXPORT_SYMBOL(davinci_aemif_setup)
- renamed ugly name davinci_ntosd2_nandflash_device

CC:
Sekhar Nori nsek...@ti.com

  arch/arm/mach-davinci/aemif.c   |   89 ++-
  arch/arm/mach-davinci/board-da830-evm.c |3 +
  arch/arm/mach-davinci/board-da850-evm.c |3 +
  arch/arm/mach-davinci/board-dm355-evm.c |5 ++
  arch/arm/mach-davinci/board-dm355-leopard.c |5 ++
  arch/arm/mach-davinci/board-dm365-evm.c |4 +
  arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
  arch/arm/mach-davinci/board-dm646x-evm.c|3 +
  arch/arm/mach-davinci/board-mityomapl138.c  |3 +
  arch/arm/mach-davinci/board-neuros-osd2.c   |   13 +++-
  arch/arm/mach-davinci/devices-tnetv107x.c   |3 +
  drivers/mtd/nand/davinci_nand.c |   23 --
  include/linux/platform_data/mtd-davinci-aemif.h |5 +-
  13 files changed, 133 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index f091a90..64dccfc 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -16,6 +16,7 @@
  #include linux/time.h

  #include linux/platform_data/mtd-davinci-aemif.h
+#include linux/platform_data/mtd-davinci.h

  /* Timing value configuration */

@@ -43,6 +44,17 @@
WSTROBE(WSTROBE_MAX) | \
WSETUP(WSETUP_MAX))

+static inline unsigned int davinci_aemif_readl(void __iomem *base, int offset)
+{
+   return readl_relaxed(base + offset);
+}
+
+static inline void davinci_aemif_writel(void __iomem *base,
+   int offset, unsigned long value)
+{
+   writel_relaxed(value, base + offset);
+}
+
  /*
   * aemif_calc_rate - calculate timing data.
   * @wanted: The cycle time needed in nanoseconds.
@@ -86,7 +98,7 @@ static int aemif_calc_rate(int wanted, unsigned long clk, int 
max)
   *
   * Returns 0 on success, else negative errno.
   */
-int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
+static int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
void __iomem *base, unsigned cs)
  {
unsigned set, val;
@@ -130,4 +142,77 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing 
*t,

return 0;
  }
-EXPORT_SYMBOL(davinci_aemif_setup_timing);
+
+/**
+ * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
+ * @pdev - link to platform device to setup settings for
+ *
+ * This function does not use any locking while programming the AEMIF
+ * because it is expected that there is only one user of a given
+ * chip-select.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int davinci_aemif_setup(struct platform_device *pdev)
+{
+   struct davinci_nand_pdata *pdata = dev_get_platdata(pdev-dev);
+   uint32_t val;
+   struct resource *res;
+   void __iomem *base;
+   struct clk* clk;
+   int ret = 0;
+
+   clk = clk_get(pdev-dev, aemif);
+   if (IS_ERR(clk)) {
+   ret = PTR_ERR(clk);
+   dev_dbg(pdev-dev, unable to get AEMIF clock, err %d\n, ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(clk);
+   if (ret  0) {
+   dev_dbg(pdev-dev, unable to enable AEMIF clock, err %d\n,
+   ret);
+   return ret;
+   }
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res) {
+   dev_err(pdev-dev, cannot get IORESOURCE_MEM\n);
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   base = ioremap(res-start, resource_size(res));
+   if (!base) {
+   dev_err(pdev-dev, ioremap failed for resource %pR\n, res);
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   /*
+* Setup Async configuration register in case we did not boot
+* from NAND and so bootloader did not bother to set it up.
+*/
+   val = 

Re: [PATCH] watchdog: davinci: rename platform driver to davinci-wdt

[ivan.khoronzhuk]

On 11/28/2013 08:04 AM, Sekhar Nori wrote:

On Wednesday 27 November 2013 09:27 PM, Guenter Roeck wrote:

On 11/27/2013 06:00 AM, Sekhar Nori wrote:

On Wednesday 27 November 2013 07:01 PM, Ivan Khoronzhuk wrote:

As we switch to use the watchdog core which permits more than one
active watchdog in the system, rename platform driver to
davinci-wdt to be identifiable.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com


Looks good to me. Since bulk of this patch touches mach-davinci, I would
like to take this through my tree to avoid conflicts with other
mach-davinci patches I accept.



Good idea, and makes sense.


Added to v3.14/soc with your Reviewed-by

Thanks,
Sekhar

[1]
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/soc



Thanks, Sekhar.
What about other WDT patches, are you OK with them?
https://lkml.org/lkml/2013/11/27/164

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

Re: [PATCH] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 11/27/2013 03:07 PM, Sekhar Nori wrote:

On Wednesday 27 November 2013 04:31 PM, ivan.khoronzhuk wrote:

@@ -192,9 +193,15 @@ static __init void davinci_ntosd2_init(void)
   davinci_cfg_reg(DM644X_ATAEN_DISABLE);

   /* only one device will be jumpered and detected */
-if (HAS_NAND)
+if (HAS_NAND) {
   platform_device_register(
   _ntosd2_nandflash_device);
+
+if (davinci_aemif_setup(
+_ntosd2_nandflash_device))
+pr_warn("%s: Cannot configure AEMIF.\n",
+__func__);


This is looking really ugly. Can you shorten
davinci_ntosd2_nandflash_device to just "ntosd2_nandflash" or similar?


The rename is not related to the patch, so I won't do this.


The reason I asked you to rename is not because I want to push some
random clean-up into this patch. You had to introduce a line so broken
that its almost unreadable. I offered the suggestion as a way to improve
the readability of the code you are introducing in *this* patch.

Thanks,
Sekhar



Ok, I will rename

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

Re: [PATCH v2 00/10] Reuse davinci-nand driver for Keystone arch

[ivan.khoronzhuk]

On 11/27/2013 03:33 AM, Brian Norris wrote:

Hi Ivan,

On Thu, Nov 21, 2013 at 01:28:15PM +0200, Ivan Khoronzhuk wrote:

This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.

The series is combination of two following series:
- Davinci nand driver fixes and updates:
   https://lkml.org/lkml/2013/11/20/271
- Reuse davinci-nand driver for Keystone arch
   https://lkml.org/lkml/2013/11/20/315


Can you make sure to consistently change the email $subject for your
patch series? For each of the above, it looks like they are actually
version 2, yet they still just say "[PATCH X/Y]" (not "[PATCH v2 X/Y]").
This makes it harder to parse the history of each series. (And the
combining of two un-versioned patch series adds to the confusion.)

Now, this combined series has a good v2 marking (although at this point,
is it really v3? ...whatever, it doesn't matter). Please continue to
write appropriate $subjects for this and future patch series.

Thanks,
Brian



Sorry for the mess, I will

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

Re: [PATCH] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 11/27/2013 10:35 AM, Sekhar Nori wrote:

+ MTD maintainers

On Tuesday 26 November 2013 01:30 AM, Ivan Khoronzhuk wrote:

The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.

The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver.

To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.

The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.

Signed-off-by: Ivan Khoronzhuk 
---
  arch/arm/mach-davinci/aemif.c   |   73 ++-
  arch/arm/mach-davinci/board-da830-evm.c |3 +
  arch/arm/mach-davinci/board-da850-evm.c |3 +
  arch/arm/mach-davinci/board-dm355-evm.c |5 ++
  arch/arm/mach-davinci/board-dm355-leopard.c |5 ++
  arch/arm/mach-davinci/board-dm365-evm.c |4 ++
  arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
  arch/arm/mach-davinci/board-dm646x-evm.c|3 +
  arch/arm/mach-davinci/board-mityomapl138.c  |3 +
  arch/arm/mach-davinci/board-neuros-osd2.c   |9 ++-
  arch/arm/mach-davinci/devices-tnetv107x.c   |3 +
  drivers/mtd/nand/davinci_nand.c |   23 ---
  include/linux/platform_data/mtd-davinci-aemif.h |5 +-
  13 files changed, 116 insertions(+), 28 deletions(-)


[...]


+
+/**
+ * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
+ * @pdev - link to platform device to setup settings for
+ *
+ * This function does not use any locking while programming the AEMIF
+ * because it is expected that there is only one user of a given
+ * chip-select.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int davinci_aemif_setup(struct platform_device *pdev)
+{
+   struct davinci_nand_pdata *pdata = dev_get_platdata(>dev);
+   uint32_t val;
+   struct resource *res;
+   void __iomem *base;
+   int ret = 0;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res) {
+   dev_err(>dev, "cannot get IORESOURCE_MEM\n");
+   return -ENOMEM;
+   }
+
+   base = ioremap(res->start, resource_size(res));
+   if (!base) {
+   dev_err(>dev, "ioremap failed for resource %pR\n", res);
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   /*
+* Setup Async configuration register in case we did not boot
+* from NAND and so bootloader did not bother to set it up.
+*/
+   val = davinci_aemif_readl(base, A1CR_OFFSET + pdev->id * 4);


The AEMIF clock has to be enabled before this. The NAND driver might
load much later.



Ok


+   /*
+* Extended Wait is not valid and Select Strobe mode is not
+* used
+*/
+   val &= ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
+   if (pdata->options & NAND_BUSWIDTH_16)
+   val |= 0x1;
+
+   davinci_aemif_writel(base, A1CR_OFFSET + pdev->id * 4, val);
+
+   if (pdata->timing)
+   ret = davinci_aemif_setup_timing(pdata->timing, base, pdev->id);
+
+   if (ret < 0)
+   dev_dbg(>dev, "NAND timing values setup fail\n");
+
+err:
+   iounmap(base);
+   return ret;
+}
+EXPORT_SYMBOL(davinci_aemif_setup);


No need to export this symbol as nothing apart from platform code uses it.



Ok


  static const short mityomap_mii_pins[] = {
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c 
b/arch/arm/mach-davinci/board-neuros-osd2.c
index bb680af..a7d6668 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -31,6 +31,7 @@
  #include 
  #include 
  #include 
+#include 

  #include 
  #include 
@@ -192,9 +193,15 @@ static __init void davinci_ntosd2_init(void)
davinci_cfg_reg(DM644X_ATAEN_DISABLE);

/* only one device will be jumpered and detected */
-   if (HAS_NAND)
+   if (HAS_NAND) {
platform_device_register(
_ntosd2_nandflash_device);
+
+   if (davinci_aemif_setup(
+   _ntosd2_nandflash_device))
+   pr_warn("%s: Cannot configure AEMIF.\n",
+   __func__);


This is looking really ugly. Can you shorten
davinci_ntosd2_nandflash_device to just "ntosd2_nandflash" or similar?


The rename is not related to the patch, so I won't do this.



I am yet to test this. Will test once the next version is posted.

Overall, I cannot say I am fan of this approach (mostly because we are
ending up having two drivers for the same hardware in kernel). But given
that the other option of adding platform 

Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver

[ivan.khoronzhuk]

On 11/27/2013 02:37 AM, Brian Norris wrote:

On Tue, Nov 26, 2013 at 01:26:44PM -0500, Santosh Shilimkar wrote:

On Tuesday 26 November 2013 12:21 PM, Sekhar Nori wrote:

On 11/26/2013 8:35 PM, Santosh Shilimkar wrote:

On Tuesday 26 November 2013 02:20 AM, Sekhar Nori wrote:

On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote:

+static int davinci_aemif_probe(struct platform_device *pdev)
+{
+   int ret  = -ENODEV, i;
+   struct resource *res;
+   struct device *dev = >dev;
+   struct device_node *np = dev->of_node;
+
+   if (np == NULL)
+   return 0;
+
+   if (aemif) {
+   dev_err(dev, "davinci_aemif driver is in use currently\n");
+   return -EBUSY;
+   }


Why expressly prevent multiple AEMIF devices? Its entirely conceivable
to have two memories like NAND and NOR flash connect to two different
AEMIF interfaces.


Ivan wanted me to clarify the Keystone hardware which supports
1 instance of controller with 4 CS. That allows already four
devices to be connected. Currently NAND and NOR are connected on it
and two more slots are free.

Since driver support what hardware is, lets not build a driver for
hardware which don't exist. And if at all such a support would be
needed in future, we can always add it.


I understand the lack of hardware part, but its common to write the
driver such that it can handle multiple instances. Is there any gain on
current hardware because of this check? From what I am hearing, the code
in question wont be exercised at all. So why go all the way and add it
in first place?


Fair enough. The check can be dropped.


Hmm, while the sentiment expressed by Sekhar is noble (to avoid
unnecessarily constraining the driver), removing the check is not
enough. You're still using a global static variable 'aemif', and it is
important not to accidentally re-use this struct if a second device ever
becomes available. So for the current implementation, the check is
necessary IMO. If instead, you were to make 'aemif' a per-device struct
(like with platform_set_drvdata()), then you would not have this issue.

Brian



Yes, that is the plan to make it a per-device.

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

Re: [PATCH v3 1/6] watchdog: davinci: change driver to use WDT core

[ivan.khoronzhuk]

On 11/27/2013 09:04 AM, Guenter Roeck wrote:

On 11/26/2013 08:31 PM, Sekhar Nori wrote:

On Monday 25 November 2013 07:34 PM, Ivan Khoronzhuk wrote:

To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.

Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.

The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.

The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.

Signed-off-by: Ivan Khoronzhuk 
Acked-by: Santosh Shilimkar 
Reviewed-by: Guenter Roeck 


So this still causes a regression because the clk_get()
fails due to the changed device name. Please fold this
patch in (tested on DM365, compiled on rest).

Also, the change in device name (while needed) does not seem
to be related to usage of wdt core. Can you may be split
that change into a separate patch?



Given all the trouble with it, I think that would be a good idea.

Guenter



Ok, I'll split it for convenience.

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

Re: [PATCH v3 1/6] watchdog: davinci: change driver to use WDT core

[ivan.khoronzhuk]

On 11/27/2013 09:04 AM, Guenter Roeck wrote:

On 11/26/2013 08:31 PM, Sekhar Nori wrote:

On Monday 25 November 2013 07:34 PM, Ivan Khoronzhuk wrote:

To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.

Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.

The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.

The heartbeat is hold in wdd-timeout by WDT core, so use it in
order to set timeout period.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Reviewed-by: Guenter Roeck li...@roeck-us.net


So this still causes a regression because the clk_get()
fails due to the changed device name. Please fold this
patch in (tested on DM365, compiled on rest).

Also, the change in device name (while needed) does not seem
to be related to usage of wdt core. Can you may be split
that change into a separate patch?



Given all the trouble with it, I think that would be a good idea.

Guenter



Ok, I'll split it for convenience.

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

Re: [PATCH 07/12] memory: davinci-aemif: introduce AEMIF driver

[ivan.khoronzhuk]

On 11/27/2013 02:37 AM, Brian Norris wrote:

On Tue, Nov 26, 2013 at 01:26:44PM -0500, Santosh Shilimkar wrote:

On Tuesday 26 November 2013 12:21 PM, Sekhar Nori wrote:

On 11/26/2013 8:35 PM, Santosh Shilimkar wrote:

On Tuesday 26 November 2013 02:20 AM, Sekhar Nori wrote:

On Monday 11 November 2013 10:36 PM, Khoronzhuk, Ivan wrote:

+static int davinci_aemif_probe(struct platform_device *pdev)
+{
+   int ret  = -ENODEV, i;
+   struct resource *res;
+   struct device *dev = pdev-dev;
+   struct device_node *np = dev-of_node;
+
+   if (np == NULL)
+   return 0;
+
+   if (aemif) {
+   dev_err(dev, davinci_aemif driver is in use currently\n);
+   return -EBUSY;
+   }


Why expressly prevent multiple AEMIF devices? Its entirely conceivable
to have two memories like NAND and NOR flash connect to two different
AEMIF interfaces.


Ivan wanted me to clarify the Keystone hardware which supports
1 instance of controller with 4 CS. That allows already four
devices to be connected. Currently NAND and NOR are connected on it
and two more slots are free.

Since driver support what hardware is, lets not build a driver for
hardware which don't exist. And if at all such a support would be
needed in future, we can always add it.


I understand the lack of hardware part, but its common to write the
driver such that it can handle multiple instances. Is there any gain on
current hardware because of this check? From what I am hearing, the code
in question wont be exercised at all. So why go all the way and add it
in first place?


Fair enough. The check can be dropped.


Hmm, while the sentiment expressed by Sekhar is noble (to avoid
unnecessarily constraining the driver), removing the check is not
enough. You're still using a global static variable 'aemif', and it is
important not to accidentally re-use this struct if a second device ever
becomes available. So for the current implementation, the check is
necessary IMO. If instead, you were to make 'aemif' a per-device struct
(like with platform_set_drvdata()), then you would not have this issue.

Brian



Yes, that is the plan to make it a per-device.

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

Re: [PATCH] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 11/27/2013 10:35 AM, Sekhar Nori wrote:

+ MTD maintainers

On Tuesday 26 November 2013 01:30 AM, Ivan Khoronzhuk wrote:

The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.

The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver.

To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.

The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.

Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
  arch/arm/mach-davinci/aemif.c   |   73 ++-
  arch/arm/mach-davinci/board-da830-evm.c |3 +
  arch/arm/mach-davinci/board-da850-evm.c |3 +
  arch/arm/mach-davinci/board-dm355-evm.c |5 ++
  arch/arm/mach-davinci/board-dm355-leopard.c |5 ++
  arch/arm/mach-davinci/board-dm365-evm.c |4 ++
  arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
  arch/arm/mach-davinci/board-dm646x-evm.c|3 +
  arch/arm/mach-davinci/board-mityomapl138.c  |3 +
  arch/arm/mach-davinci/board-neuros-osd2.c   |9 ++-
  arch/arm/mach-davinci/devices-tnetv107x.c   |3 +
  drivers/mtd/nand/davinci_nand.c |   23 ---
  include/linux/platform_data/mtd-davinci-aemif.h |5 +-
  13 files changed, 116 insertions(+), 28 deletions(-)


[...]


+
+/**
+ * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
+ * @pdev - link to platform device to setup settings for
+ *
+ * This function does not use any locking while programming the AEMIF
+ * because it is expected that there is only one user of a given
+ * chip-select.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int davinci_aemif_setup(struct platform_device *pdev)
+{
+   struct davinci_nand_pdata *pdata = dev_get_platdata(pdev-dev);
+   uint32_t val;
+   struct resource *res;
+   void __iomem *base;
+   int ret = 0;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   if (!res) {
+   dev_err(pdev-dev, cannot get IORESOURCE_MEM\n);
+   return -ENOMEM;
+   }
+
+   base = ioremap(res-start, resource_size(res));
+   if (!base) {
+   dev_err(pdev-dev, ioremap failed for resource %pR\n, res);
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   /*
+* Setup Async configuration register in case we did not boot
+* from NAND and so bootloader did not bother to set it up.
+*/
+   val = davinci_aemif_readl(base, A1CR_OFFSET + pdev-id * 4);


The AEMIF clock has to be enabled before this. The NAND driver might
load much later.



Ok


+   /*
+* Extended Wait is not valid and Select Strobe mode is not
+* used
+*/
+   val = ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
+   if (pdata-options  NAND_BUSWIDTH_16)
+   val |= 0x1;
+
+   davinci_aemif_writel(base, A1CR_OFFSET + pdev-id * 4, val);
+
+   if (pdata-timing)
+   ret = davinci_aemif_setup_timing(pdata-timing, base, pdev-id);
+
+   if (ret  0)
+   dev_dbg(pdev-dev, NAND timing values setup fail\n);
+
+err:
+   iounmap(base);
+   return ret;
+}
+EXPORT_SYMBOL(davinci_aemif_setup);


No need to export this symbol as nothing apart from platform code uses it.



Ok


  static const short mityomap_mii_pins[] = {
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c 
b/arch/arm/mach-davinci/board-neuros-osd2.c
index bb680af..a7d6668 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -31,6 +31,7 @@
  #include linux/platform_data/mmc-davinci.h
  #include linux/platform_data/mtd-davinci.h
  #include linux/platform_data/usb-davinci.h
+#include linux/platform_data/mtd-davinci-aemif.h

  #include asm/mach-types.h
  #include asm/mach/arch.h
@@ -192,9 +193,15 @@ static __init void davinci_ntosd2_init(void)
davinci_cfg_reg(DM644X_ATAEN_DISABLE);

/* only one device will be jumpered and detected */
-   if (HAS_NAND)
+   if (HAS_NAND) {
platform_device_register(
davinci_ntosd2_nandflash_device);
+
+   if (davinci_aemif_setup(
+   davinci_ntosd2_nandflash_device))
+   pr_warn(%s: Cannot configure AEMIF.\n,
+   __func__);


This is looking really ugly. Can you shorten
davinci_ntosd2_nandflash_device to just ntosd2_nandflash or similar?


The rename is not related to the patch, so I won't do this.



I am yet to test this. Will test once the next 

Re: [PATCH v2 00/10] Reuse davinci-nand driver for Keystone arch

[ivan.khoronzhuk]

On 11/27/2013 03:33 AM, Brian Norris wrote:

Hi Ivan,

On Thu, Nov 21, 2013 at 01:28:15PM +0200, Ivan Khoronzhuk wrote:

This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.

The series is combination of two following series:
- Davinci nand driver fixes and updates:
   https://lkml.org/lkml/2013/11/20/271
- Reuse davinci-nand driver for Keystone arch
   https://lkml.org/lkml/2013/11/20/315


Can you make sure to consistently change the email $subject for your
patch series? For each of the above, it looks like they are actually
version 2, yet they still just say [PATCH X/Y] (not [PATCH v2 X/Y]).
This makes it harder to parse the history of each series. (And the
combining of two un-versioned patch series adds to the confusion.)

Now, this combined series has a good v2 marking (although at this point,
is it really v3? ...whatever, it doesn't matter). Please continue to
write appropriate $subjects for this and future patch series.

Thanks,
Brian



Sorry for the mess, I will

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

Re: [PATCH] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif

[ivan.khoronzhuk]

On 11/27/2013 03:07 PM, Sekhar Nori wrote:

On Wednesday 27 November 2013 04:31 PM, ivan.khoronzhuk wrote:

@@ -192,9 +193,15 @@ static __init void davinci_ntosd2_init(void)
   davinci_cfg_reg(DM644X_ATAEN_DISABLE);

   /* only one device will be jumpered and detected */
-if (HAS_NAND)
+if (HAS_NAND) {
   platform_device_register(
   davinci_ntosd2_nandflash_device);
+
+if (davinci_aemif_setup(
+davinci_ntosd2_nandflash_device))
+pr_warn(%s: Cannot configure AEMIF.\n,
+__func__);


This is looking really ugly. Can you shorten
davinci_ntosd2_nandflash_device to just ntosd2_nandflash or similar?


The rename is not related to the patch, so I won't do this.


The reason I asked you to rename is not because I want to push some
random clean-up into this patch. You had to introduce a line so broken
that its almost unreadable. I offered the suggestion as a way to improve
the readability of the code you are introducing in *this* patch.

Thanks,
Sekhar



Ok, I will rename

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