date:20140307

On Fri, Mar 07, 2014 at 03:01:34PM -0500, Wang, Xiaoming wrote:
 pcmd-parmbuf-pbuf has been allocated if command is 
 GEN_CMD_CODE(_Set_Drv_Extra),
 and it enqueued by rtw_enqueue_cmd. rtw_cmd_thread dequeue pcmd by 
 rtw_dequeue_cmd.
 The memory leak happened on this branch if( _FAIL == 
 rtw_cmd_filter(pcmdpriv, pcmd) )
 which goto post_process directly against freeing pcmd-parmbuf-pbuf in
 rtw_drvextra_cmd_hdl which is the cmd_hdl if command is (_Set_Drv_Extra).
 This patch free pcmd-parmbuf-pbuf on forgotten branch to avoid memory leak.
 
 Signed-off-by: Zhang Dongxing dongxing.zh...@intel.com
 Signed-off-by: xiaoming wang xiaoming.w...@intel.com

This code looks completely different in linux-next.  Please redo on top
of linux-next if it's still needed.

regards,
dan carpenter

--
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] [RFC] Taint the kernel for unsafe module options

2014-03-07 Thread Daniel Vetter

On Fri, Mar 7, 2014 at 4:28 AM, Rusty Russell ru...@rustcorp.com.au wrote:
 If this is a good idea, you can write a macro module_param_unsafe_named
 which is a general wrapper.

 For this to work I need to somehow store the safe default value somewhere.
 since with bools or strings there really isn't such a thing, even less
 than with integers where my fairly abitrary -1 choice is already
 restricting. But I don't have a good idea how to do that, since creating a
 local static struct in the macro to store the default + the pointer to the
 storage location feels a bit ugly.

 I was thinking that if use the parameter, they get marked unsafe.  If
 they use it to set it to the default, Don't Do That.

Makes sense. I'll try to come up with something more polished which
addresses your's and Andrew's comments somewhen next week. Presuming
the (here one week later than everywhere else) carnival doesn't
interfere too badly ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/

FlexCAN on i.MX28 interrupt flooding retrying send

2014-03-07 Thread Stanislav Meduna

Hi,

I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
If a packet is being sent when the bus is disconnected, I am getting
an interrupt flooed that basically kills the machine.

This is _not_ the same problem as [2] - my kernel already has
the fix.

The first interrupt comes with ESR 0x00028652, i.e.

TXWRN_INT
BIT1_ERR
STF_ERR
TX_WRN
TXRX
FLT_CONF error passive
ERR_INT

The next ones come the same without the acked TXWRN_INT.
Reading the ESR again immediately after acking gives
0x0250, i.e.

TX_WRN
TXRX
FLT_CONF error passive

so everything ackable has actually been acked.

I think that the problem is that the FlexCAN tries to retransmit
the frame indefinitely. Each retry senses the bus in the invalid
state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
this I aborted the transmitted frame in the error state in the
interrupt handler

#define FLEXCAN_ESR_ERR_TRANSMIT \
(FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)

if (reg_esr  FLEXCAN_ESR_ERR_TRANSMIT) {

/* In case of a transmission error the packet is retried and
 * if the error persists, we will get another interrupt right
 * away. Abort the transmission - a lost packet is better than
 * an irq storm.
 */
if(printk_ratelimit())
netdev_err(dev, Aborted transmission, ESR %08x\n, reg_esr);

can_get_echo_skb(dev, 0);
flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
regs-cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
netif_wake_queue(dev);
}

and the problem disappeared as expected. However, the correct
way is probably to retry during some reasonable (configurable?)
time interval.

What puzzles me is that I did not found any other instance
of this problem in the relevant mailing lists, only the original [2].

I am using the 3.4.77 kernel with the realtime patches, but the
code in the latest mainline looks the same in this respect.
Maybe the realtime patches change some bevaviour, but I don't
think they affect the core problem. I am not really an expert
in the network devices, NAPI etc - maybe in that case the error
interrupt should be disabled and re-enabled only if the
error condition goes away? - I don't know...

Please Cc: me when answering to the list.

[1] 
http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
[2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa

Thanks
-- 
   Stano
--
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/

[PATCH] x86, calgary: use 8M TCE table size by default

2014-03-07 Thread WANG Chao

kexec-tools wants to pass kdump kernel needed memmap via E820 directly,
instead of memmap=exactmap. That'll make saved_max_pfn totally useless.

Muli suggest to hard code TCE table size to max (8M) so that kdump
kernel could use this default size and kexec-tools doesn't need to pass
saved_max_pfn to kdump kernel in any way.

Signed-off-by: WANG Chao chaow...@redhat.com
---
 arch/x86/kernel/pci-calgary_64.c | 25 -
 1 file changed, 8 insertions(+), 17 deletions(-)

diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 299d493..b26ab94 100644
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -1207,25 +1207,17 @@ error:
return ret;
 }
 
-static inline int __init determine_tce_table_size(u64 ram)
+static inline int __init determine_tce_table_size(void)
 {
-   int ret;
-
if (specified_table_size != TCE_TABLE_SIZE_UNSPECIFIED)
return specified_table_size;
+   else
+   /*
+* Use 8M by default to get rid of saved_max_pfn,
+* suggested by Muli
+*/
+   return TCE_TABLE_SIZE_8M;
 
-   /*
-* Table sizes are from 0 to 7 (TCE_TABLE_SIZE_64K to
-* TCE_TABLE_SIZE_8M). Table size 0 has 8K entries and each
-* larger table size has twice as many entries, so shift the
-* max ram address by 13 to divide by 8K and then look at the
-* order of the result to choose between 0-7.
-*/
-   ret = get_order(ram  13);
-   if (ret  TCE_TABLE_SIZE_8M)
-   ret = TCE_TABLE_SIZE_8M;
-
-   return ret;
 }
 
 static int __init build_detail_arrays(void)
@@ -1418,8 +1410,7 @@ int __init detect_calgary(void)
return -ENOMEM;
}
 
-   specified_table_size = determine_tce_table_size((is_kdump_kernel() ?
-   saved_max_pfn : max_pfn) * PAGE_SIZE);
+   specified_table_size = determine_tce_table_size();
 
for (bus = 0; bus  MAX_PHB_BUS_NUM; bus++) {
struct calgary_bus_info *info = bus_info[bus];
-- 
1.8.5.3

--
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] staging: frontier: fix memory leak in usb_alphatrack_probe()

On Fri, Mar 07, 2014 at 05:02:25PM +0900, Daeseok Youn wrote:
 
 oldi_buffer and write_buffer need to free when usb_alphatrack_delete()
 is called.
 
 Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
 ---
  drivers/staging/frontier/alphatrack.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/staging/frontier/alphatrack.c 
 b/drivers/staging/frontier/alphatrack.c
 index edd5cef..4d630da 100644
 --- a/drivers/staging/frontier/alphatrack.c
 +++ b/drivers/staging/frontier/alphatrack.c
 @@ -208,6 +208,8 @@ static void usb_alphatrack_delete(struct usb_alphatrack 
 *dev)
   kfree(dev-ring_buffer);
   kfree(dev-interrupt_in_buffer);
   kfree(dev-interrupt_out_buffer);
 + kfree(dev-oldi_buffer);
 + kfree(dev-write_buffer);
   kfree(dev); /* fixme oldi_buffer */
   ^
Remove this comment now?

regards,
dan carpenter

--
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: [RFC] drm: add kernel-log renderer

Hi

 I don't think it makes sense to modify drm_log_ensure_size(). I mean,
 the worst that can happen is that the *text*-backlog is twice as big
 as required. But if you have a high-dpi display, you already require
 like 10x as much space for each framebuffer than for the entire
 log-buffer. The log-buffer requires 1 byte per *char*. The frambuffer
 requires at least 8*16*4=512 bytes per char.

 That's fair, especially as drm_log_ensure_size() is grow-only.

 Anyhow, integer-scaling should be fairly easy to get done.

 I thought providing the font to drm_log_draw() and express
 drm_log_ensure_size() in chars - or pass font to it as well - would be
 easier than scaling.

There are no real high-res fonts in ./lib/fonts/ so I don't think
that's an option. Besides, we don't want high-res fonts, we just want
bigger fonts so scaling seems fine.

Thanks
David
--
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/1] Drivers: hv: vmbus: Include the limit on the number of pfns we can handle

On Thu, Mar 06, 2014 at 11:15:08PM -0800, K. Y. Srinivasan wrote:
 Increase the maximum number of pfns we can handle is a single vmbus packet.
^^ in
 

What are the user visible effects of this patch?

regards,
dan carpenter

--
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: FlexCAN on i.MX28 interrupt flooding retrying send

2014-03-07 Thread Marc Kleine-Budde

Adding the linux-can mailinglist to Cc.

Marc

On 03/07/2014 09:08 AM, Stanislav Meduna wrote:
 Hi,
 
 I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
 If a packet is being sent when the bus is disconnected, I am getting
 an interrupt flooed that basically kills the machine.
 
 This is _not_ the same problem as [2] - my kernel already has
 the fix.
 
 The first interrupt comes with ESR 0x00028652, i.e.
 
 TXWRN_INT
 BIT1_ERR
 STF_ERR
 TX_WRN
 TXRX
 FLT_CONF error passive
 ERR_INT
 
 The next ones come the same without the acked TXWRN_INT.
 Reading the ESR again immediately after acking gives
 0x0250, i.e.
 
 TX_WRN
 TXRX
 FLT_CONF error passive
 
 so everything ackable has actually been acked.
 
 I think that the problem is that the FlexCAN tries to retransmit
 the frame indefinitely. Each retry senses the bus in the invalid
 state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
 this I aborted the transmitted frame in the error state in the
 interrupt handler
 
 #define FLEXCAN_ESR_ERR_TRANSMIT \
   (FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)
 
 if (reg_esr  FLEXCAN_ESR_ERR_TRANSMIT) {
 
   /* In case of a transmission error the packet is retried and
* if the error persists, we will get another interrupt right
* away. Abort the transmission - a lost packet is better than
* an irq storm.
*/
   if(printk_ratelimit())
   netdev_err(dev, Aborted transmission, ESR %08x\n, reg_esr);
 
   can_get_echo_skb(dev, 0);
   flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
   regs-cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
   netif_wake_queue(dev);
 }
 
 and the problem disappeared as expected. However, the correct
 way is probably to retry during some reasonable (configurable?)
 time interval.
 
 What puzzles me is that I did not found any other instance
 of this problem in the relevant mailing lists, only the original [2].
 
 I am using the 3.4.77 kernel with the realtime patches, but the
 code in the latest mainline looks the same in this respect.
 Maybe the realtime patches change some bevaviour, but I don't
 think they affect the core problem. I am not really an expert
 in the network devices, NAPI etc - maybe in that case the error
 interrupt should be disabled and re-enabled only if the
 error condition goes away? - I don't know...
 
 Please Cc: me when answering to the list.
 
 [1] 
 http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
 [2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa
 
 Thanks
 


-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] staging: frontier: fix memory leak in usb_alphatrack_probe()

2014-03-07 Thread DaeSeok Youn

OK. I will remove that comment and send again.

Thanks.
Daeseok Youn.

2014-03-07 17:14 GMT+09:00 Dan Carpenter dan.carpen...@oracle.com:
 On Fri, Mar 07, 2014 at 05:02:25PM +0900, Daeseok Youn wrote:

 oldi_buffer and write_buffer need to free when usb_alphatrack_delete()
 is called.

 Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
 ---
  drivers/staging/frontier/alphatrack.c |2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/drivers/staging/frontier/alphatrack.c 
 b/drivers/staging/frontier/alphatrack.c
 index edd5cef..4d630da 100644
 --- a/drivers/staging/frontier/alphatrack.c
 +++ b/drivers/staging/frontier/alphatrack.c
 @@ -208,6 +208,8 @@ static void usb_alphatrack_delete(struct usb_alphatrack 
 *dev)
   kfree(dev-ring_buffer);
   kfree(dev-interrupt_in_buffer);
   kfree(dev-interrupt_out_buffer);
 + kfree(dev-oldi_buffer);
 + kfree(dev-write_buffer);
   kfree(dev); /* fixme oldi_buffer */
^
 Remove this comment now?

 regards,
 dan carpenter

--
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: performance regression due to commit e82e0561(mm: vmscan: obey proportional scanning requirements for kswapd)

2014-03-07 Thread Yuanhan Liu

ping...

On Tue, Feb 18, 2014 at 04:01:22PM +0800, Yuanhan Liu wrote:
 Hi,
 
 Commit e82e0561(mm: vmscan: obey proportional scanning requirements for
 kswapd) caused a big performance regression(73%) for vm-scalability/
 lru-file-readonce testcase on a system with 256G memory without swap.
 
 That testcase simply looks like this:
  truncate -s 1T /tmp/vm-scalability.img
  mkfs.xfs -q /tmp/vm-scalability.img
  mount -o loop /tmp/vm-scalability.img /tmp/vm-scalability
 
  SPARESE_FILE=/tmp/vm-scalability/sparse-lru-file-readonce
  for i in `seq 1 120`; do
  truncate $SPARESE_FILE-$i -s 36G
  timeout --foreground -s INT 300 dd bs=4k if=$SPARESE_FILE-$i 
 of=/dev/null
  done
 
  wait
 
 Actually, it's not the newlly added code(obey proportional scanning)
 in that commit caused the regression. But instead, it's the following
 change:
 +
 +   if (nr_reclaimed  nr_to_reclaim || scan_adjusted)
 +   continue;
 +
 
 
 -   if (nr_reclaimed = nr_to_reclaim 
 -   sc-priority  DEF_PRIORITY)
 +   if (global_reclaim(sc)  !current_is_kswapd())
 break;
 
 The difference is that we might reclaim more than requested before
 in the first round reclaimming(sc-priority == DEF_PRIORITY).
 
 So, for a testcase like lru-file-readonce, the dirty rate is fast, and
 reclaimming SWAP_CLUSTER_MAX(32 pages) each time is not enough for catching
 up the dirty rate. And thus page allocation stalls, and performance drops:
 
O for e82e0561
* for parent commit
 
 proc-vmstat.allocstall
 
  2e+06 ++---+
1.8e+06 O+  OO   O   |
||
1.6e+06 ++   |
1.4e+06 ++   |
||
1.2e+06 ++   |
  1e+06 ++   |
 80 ++   |
||
 60 ++   |
 40 ++   |
||
 20 *+..**...*...*
  0 ++---+
 
vm-scalability.throughput
 
2.2e+07 ++---+
||
  2e+07 *+..**...*...*
1.8e+07 ++   |
||
1.6e+07 ++   |
||
1.4e+07 ++   |
||
1.2e+07 ++   |
  1e+07 ++   |
||
  8e+06 ++  OO   O   |
O|
  6e+06 ++---+
 
 I made a patch which simply keeps reclaimming more if sc-priority == 
 DEF_PRIORITY.
 I'm not sure it's the right way to go or not. Anyway, I pasted it here for 
 comments.
 
 ---
 diff --git a/mm/vmscan.c b/mm/vmscan.c
 index 26ad67f..37004a8 100644
 --- a/mm/vmscan.c
 +++ b/mm/vmscan.c
 @@ -1828,7 +1828,16 @@ static void shrink_lruvec(struct lruvec *lruvec, 
 struct scan_control *sc)
   unsigned long nr_reclaimed = 0;
   unsigned long nr_to_reclaim = sc-nr_to_reclaim;
   struct blk_plug plug;
 - bool scan_adjusted = false;
 + /*
 +  * On large memory systems, direct reclamming of SWAP_CLUSTER_MAX
 +  * each time may not catch up the dirty rate in some cases(say,
 +  * vm-scalability/lru-file-readonce), which may increase the
 +  * page allocation stall latency in the end.
 +  *
 +  * Here we try to reclaim more than requested for the first round
 +

[PATCH v2] staging: frontier: fix memory leak in usb_alphatrack_probe()

2014-03-07 Thread Daeseok Youn


oldi_buffer and write_buffer need to free when usb_alphatrack_delete()
is called.

Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
v2: remove the unneeded comment.

 drivers/staging/frontier/alphatrack.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/frontier/alphatrack.c 
b/drivers/staging/frontier/alphatrack.c
index edd5cef..e59ee51 100644
--- a/drivers/staging/frontier/alphatrack.c
+++ b/drivers/staging/frontier/alphatrack.c
@@ -208,7 +208,9 @@ static void usb_alphatrack_delete(struct usb_alphatrack 
*dev)
kfree(dev-ring_buffer);
kfree(dev-interrupt_in_buffer);
kfree(dev-interrupt_out_buffer);
-   kfree(dev); /* fixme oldi_buffer */
+   kfree(dev-oldi_buffer);
+   kfree(dev-write_buffer);
+   kfree(dev);
 }
 
 /** usb_alphatrack_interrupt_in_callback */
-- 
1.7.4.4


--
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] phy: omap-control: update dra7 and am437 usb2 Documentation bindings

2014-03-07 Thread Kishon Vijay Abraham I




On Friday 07 March 2014 01:55 PM, Kishon Vijay Abraham I wrote:

From: Felipe Balbi ba...@ti.com

From: Roger Quadros rog...@ti.com


There seems to be some problem with this patch. Pls ignore this.

Thanks
Kishon


The dra7-usb2 and am437-usb2 bindings have not yet been used.
Change them to be more elegant.

Acked-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
Changes from v3:
* changed the compatible name to 'ti,control-phy-usb2-dra7' and
   'ti,control-phy-usb2-am437'

  Documentation/devicetree/bindings/phy/ti-phy.txt | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 41dc132..8694aae 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -9,9 +9,9 @@ Required properties:
  e.g. USB2_PHY on OMAP5.
   ti,control-phy-pipe3 - if it has DPLL and individual Rx  Tx power control
  e.g. USB3 PHY and SATA PHY on OMAP5.
- ti,control-phy-dra7usb2 - if it has power down register like USB2 PHY on
+ ti,control-phy-usb2-dra7 - if it has power down register like USB2 PHY on
  DRA7 platform.
- ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on
+ ti,control-phy-usb2-am437 - if it has power down register like USB2 PHY on
  AM437 platform.
   - reg : Address and length of the register set for the device. It contains
 the address of otghs_control for control-phy-otghs or power register


--
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 5/5] Staging: comedi: addi-data: tidy up counter register map defines in hwdrv_apci1564.c

On Thursday, March 6, 2014 11:59 AM, Hartley Sweeten 
hartl...@visionengravers.com wrote:

On Thursday, March 06, 2014 12:26 AM, Chase Southwood wrote:

This patch for hwdrv_apci1564.c fixes the register map defines for the
digital input registers such that they are all the real offsets to each
register, rather than a mix of real offsets and adders to those offsets.

Signed-off-by: Chase Southwood chase.southw...@yahoo.com
---
 .../comedi/drivers/addi-data/hwdrv_apci1564.c      | 101 
 +
 1 file changed, 44 insertions(+), 57 deletions(-)

This one is incomplete and breaks the build.

 CC [M]  drivers/staging/comedi/drivers/addi_apci_1564.o
In file included from drivers/staging/comedi/drivers/addi_apci_1564.c:11:0:
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c: In function 
'i_APCI1564_ConfigTimerCounterWatchdog':
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c:352:4: error: 
'APCI1564_TCW_PROG' undeclared (first use in this function)
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c:352:4: note: each 
undeclared identifier is reported only once for each function it appears in
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c:359:4: error: 
'APCI1564_TCW_RELOAD_VALUE' undeclared (first use in this function)
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c: In function 
'i_APCI1564_StartStopWriteTimerCounterWatchdog':
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c:463:19: error: 
'APCI1564_TCW_PROG' undeclared (first use in this function)
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c: In function 
'i_APCI1564_ReadTimerCounterWatchdog':
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c:526:4: error: 
'APCI1564_TCW_SYNC_ENABLEDISABLE' undeclared (first use in this function)
drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c:529:19: error: 
'APCI1564_TCW_TRIG_STATUS' undeclared (first use in this function)
make[4]: *** [drivers/staging/comedi/drivers/addi_apci_1564.o] Error 1
make[3]: *** [drivers/staging/comedi/drivers] Error 2
make[2]: *** [drivers/staging/comedi] Error 2
make[1]: *** [drivers/staging] Error 2
make: *** [drivers] Error 2

Be sure to do a build after each patch to make sure it works.

Hartley,
I'm sorry for this, it appears that this whole patch series was sloppy
and quite untested by myself.  I have made up a fixed patchset and have
tested everything this time around, I trust that you should have a better
time reviewing this one.  I will not let this happen again in the future.

Thanks,
Chase


Regards,
Hartley

--
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/

[PATCH v4] phy: omap-control: update dra7 and am437 usb2 bindings

2014-03-07 Thread Kishon Vijay Abraham I

From: Roger Quadros rog...@ti.com

The dra7-usb2 and am437-usb2 bindings have not yet been used.
Change them to be more elegant.

Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Changes from v3:
Changed the compatible value to that suggested by Tony.
ti,control-phy-usb2-dra7 and ti,control-phy-usb2-am437.

Changes from v2:
Kept only the drivers/phy part in this patch

 drivers/phy/phy-omap-control.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-omap-control.c b/drivers/phy/phy-omap-control.c
index 17fc200..a7e2d7f 100644
--- a/drivers/phy/phy-omap-control.c
+++ b/drivers/phy/phy-omap-control.c
@@ -228,11 +228,11 @@ static const struct of_device_id 
omap_control_phy_id_table[] = {
.data = pipe3_data,
},
{
-   .compatible = ti,control-phy-dra7usb2,
+   .compatible = ti,control-phy-usb2-dra7,
.data = dra7usb2_data,
},
{
-   .compatible = ti,control-phy-am437usb2,
+   .compatible = ti,control-phy-usb2-am437,
.data = am437usb2_data,
},
{},
-- 
1.7.9.5

--
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 0/5] Add STiH407 SoC and reference board support

2014-03-07 Thread Maxime Coquelin


Hi Linus

On 03/07/2014 04:11 AM, Linus Walleij wrote:

On Fri, Feb 28, 2014 at 8:17 PM, Maxime COQUELIN maxime.coque...@st.com wrote:


This series adds basic support to the STMicroelectronics STiH407 SoC and its
B2120 reference board. The STiH407 is a dual-core ARM Cortex-A9 CPU aimed at
STB market.

Giuseppe Cavallaro (2):
   ARM: STi: add pinctrl support for the STiH407 SoC
   pinctrl: st: Enhance the controller to manage unavailable registers

Maxime Coquelin (3):
   ARM: STi: Add STiH407 SoC support
   ARM: dts: Add STiH407 SoC support
   ARM: dts: STiH407: Add B2120 board support


So I'd like to take the pinctrl patch through my tree and the rest through
ARM SoC but it seems it does not apply :-/


Sorry, the series was based on v3.14-rc4.

I split the series in two:
- pinctrl patches based on the linux-pinctrl/devel branch
- ARM patches on arm_soc

Regards,
Maxime



Yours,
Linus Walleij


--
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/5] pinctrl: st: Enhance the controller to manage unavailable registers

2014-03-07 Thread Maxime Coquelin




On 03/07/2014 04:10 AM, Linus Walleij wrote:

On Fri, Feb 28, 2014 at 8:17 PM, Maxime COQUELIN maxime.coque...@st.com wrote:


From: Giuseppe Cavallaro peppe.cavall...@st.com

This patch adds a new logic inside the st pinctrl to manage
an unsupported scenario: some sysconfig are not available!

This is the case of STiH407 where, although documented, the
following registers from SYSCFG_FLASH have been removed from the SoC.

SYSTEM_CONFIG3040
Output Enable pad control for all PIO Alternate Functions
and
SYSTEM_ CONFIG3050
Pull Up pad control for all PIO Alternate Functions

Without managing this condition an imprecise external abort
will be detect.

To do this the patch also reviews the st_parse_syscfgs
and other routines to manipulate the registers only if
actually available.
In any case, for example the st_parse_syscfgs detected
an error condition but no action was made in the
st_pctl_probe_dt.

Signed-off-by: Maxime Coquelin maxime.coque...@st.com
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com


Hm this does not apply to my tree at all. It appears this is not
a stand-alone, patch, so it depends on some other patch to
pinctrl-sti?


Yes, it depends on patch 2 of the series (which is based on v3.14-rc4).
This is my mistake, the title of patch 2 is wrong:
ARM: STi: add pinctrl support for the STiH407 SoC

Should be:

pinctrl: st: add pinctrl support for the STiH407 SoC

I will resend the pinctrl patches rebased on your tree.

Thanks,
Maxime



Yours,
Linus Walleij


--
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] drm/fb-helper: Do the mode_set.connectors ZERO_SIZE_PTR check

2014-03-07 Thread Jani Nikula

On Thu, 06 Mar 2014, Xiubo Li li.xi...@freescale.com wrote:
 Since we cannot make sure the 'max_conn_count' will always be none
 zero from the users, and then if max_conn_count equals to zero, the
 kcalloc() will return ZERO_SIZE_PTR, which equals to ((void *)16).

 So this patch fix this via doing the zero pionter check of it.

Please just add a check for max_conn_count == 0 up front and handle it.

BR,
Jani.



 Signed-off-by: Xiubo Li li.xi...@freescale.com
 ---
  drivers/gpu/drm/drm_fb_helper.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
 index 3d13ca6e2..c6680ef 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -536,7 +536,7 @@ int drm_fb_helper_init(struct drm_device *dev,
   sizeof(struct drm_connector *),
   GFP_KERNEL);
  
 - if (!fb_helper-crtc_info[i].mode_set.connectors)
 + if 
 (ZERO_OR_NULL_PTR(fb_helper-crtc_info[i].mode_set.connectors))
   goto out_free;
   fb_helper-crtc_info[i].mode_set.num_connectors = 0;
   }
 -- 
 1.8.4


 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center
--
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/

[PATCH v2 3/5] Staging: comedi: addi-data: tidy up watchdog register

This patch for fixes the register map defines for the watchdog registers
such that they are all the real offsets to each register, rather than a
mix of real offsets and adders to those offsets.

Signed-off-by: Chase Southwood chase.southw...@yahoo.com
---

2: Simplified commit message, fixed indentation and whitespace damage.
I have test applied this patch, it should work now.

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 48 --
 1 file changed, 18 insertions(+), 30 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index d493d01..8ff8693 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -65,7 +65,6 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define ADDIDATA_TIMER 0
 #define ADDIDATA_COUNTER   1
 #define ADDIDATA_WATCHDOG  2
-#define APCI1564_DIGITAL_OP_WATCHDOG   0x28
 #define APCI1564_TIMER 0x48
 #define APCI1564_COUNTER1  0x0
 #define APCI1564_COUNTER2  0x20
@@ -92,6 +91,14 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define APCI1564_DO_INT_CTRL_REG   0x1c
 #define APCI1564_DO_INT_STATUS_REG 0x20
 #define APCI1564_DO_IRQ_REG0x24
+#define APCI1564_WDOG_REG  0x28
+#define APCI1564_WDOG_RELOAD_REG   0x2c
+#define APCI1564_WDOG_TIMEBASE_REG 0x30
+#define APCI1564_WDOG_CTRL_REG 0x34
+#define APCI1564_WDOG_STATUS_REG   0x38
+#define APCI1564_WDOG_IRQ_REG  0x3c
+#define APCI1564_WDOG_WARN_TIMEVAL_REG 0x40
+#define APCI1564_WDOG_WARN_TIMEBASE_REG0x44
 
 /* Global variables */
 static unsigned int ui_InterruptStatus_1564;
@@ -285,13 +292,9 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct 
comedi_device *dev,
devpriv-b_TimerSelectMode = ADDIDATA_WATCHDOG;
 
/* Disable the watchdog */
-   outl(0x0,
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_OP_WATCHDOG +
-   APCI1564_TCW_PROG);
+   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_WDOG_CTRL_REG);
/* Loading the Reload value */
-   outl(data[3],
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_OP_WATCHDOG +
-   APCI1564_TCW_RELOAD_VALUE);
+   outl(data[3], devpriv-i_IobaseAmcc + APCI1564_WDOG_RELOAD_REG);
} else if (data[0] == ADDIDATA_TIMER) {
/* First Stop The Timer */
ul_Command1 =
@@ -305,10 +308,7 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct 
comedi_device *dev,
outl(0x02, devpriv-i_IobaseAmcc + APCI1564_TIMER + 
APCI1564_TCW_PROG); /* Enable TIMER int  DISABLE ALL THE OTHER int SOURCES */
outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DO_IRQ_REG);
-   outl(0x0,
-   devpriv-i_IobaseAmcc +
-   APCI1564_DIGITAL_OP_WATCHDOG +
-   APCI1564_TCW_IRQ);
+   outl(0x0, devpriv-i_IobaseAmcc + 
APCI1564_WDOG_IRQ_REG);
outl(0x0,
devpriv-iobase + APCI1564_COUNTER1 +
APCI1564_TCW_IRQ);
@@ -427,19 +427,14 @@ static int 
i_APCI1564_StartStopWriteTimerCounterWatchdog(struct comedi_device *d
if (devpriv-b_TimerSelectMode == ADDIDATA_WATCHDOG) {
switch (data[1]) {
case 0: /* stop the watchdog */
-   outl(0x0, devpriv-i_IobaseAmcc + 
APCI1564_DIGITAL_OP_WATCHDOG + APCI1564_TCW_PROG);/* disable the watchdog */
+   /* disable the watchdog */
+   outl(0x0, devpriv-i_IobaseAmcc + 
APCI1564_WDOG_CTRL_REG);
break;
case 1: /* start the watchdog */
-   outl(0x0001,
-   devpriv-i_IobaseAmcc +
-   APCI1564_DIGITAL_OP_WATCHDOG +
-   APCI1564_TCW_PROG);
+   outl(0x0001, devpriv-i_IobaseAmcc + 
APCI1564_WDOG_CTRL_REG);
break;
case 2: /* Software trigger */
-   outl(0x0201,
-   devpriv-i_IobaseAmcc +
-

[PATCH v2 1/5] Staging: comedi: addi-data: tidy up digital input register map defines in hwdrv_apci1564.c

This patch fixes the register map defines for the digital input registers
such that they are all the real offsets to each register, rather than a
mix of real offsets and adders to those offsets.

Further, some of the old defines were being used incorrectly in the
i_APCI1564_Reset() function.  Upon swapping the old defines out for the
new ones in this function, their use has been corrected.

Signed-off-by: Chase Southwood chase.southw...@yahoo.com
---

2: Simplified commit message, fixed indentation.

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 78 +-
 1 file changed, 31 insertions(+), 47 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 2b47fa1..2c2bbd8 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -47,11 +47,6 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define APCI1564_ADDRESS_RANGE 128
 
 /* DIGITAL INPUT-OUTPUT DEFINE */
-/* Input defines */
-#define APCI1564_DIGITAL_IP0x04
-#define APCI1564_DIGITAL_IP_INTERRUPT_MODE14
-#define APCI1564_DIGITAL_IP_INTERRUPT_MODE28
-#define APCI1564_DIGITAL_IP_IRQ16
 
 /* Output defines */
 #define APCI1564_DIGITAL_OP0x18
@@ -63,9 +58,6 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define ADDIDATA_OR0
 #define ADDIDATA_AND   1
 
-/* Digital Input Interrupt Status */
-#define APCI1564_DIGITAL_IP_INTERRUPT_STATUS   12
-
 /* Digital Output Interrupt Status */
 #define APCI1564_DIGITAL_OP_INTERRUPT_STATUS   8
 
@@ -99,6 +91,15 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define APCI1564_TCW_WARN_TIMEVAL  24
 #define APCI1564_TCW_WARN_TIMEBASE 28
 
+/*
+ * devpriv-i_IobaseAmcc Register Map
+ */
+#define APCI1564_DI_REG0x04
+#define APCI1564_DI_INT_MODE1_REG  0x08
+#define APCI1564_DI_INT_MODE2_REG  0x0c
+#define APCI1564_DI_INT_STATUS_REG 0x10
+#define APCI1564_DI_IRQ_REG0x14
+
 /* Global variables */
 static unsigned int ui_InterruptStatus_1564;
 static unsigned int ui_InterruptData, ui_Type;
@@ -143,31 +144,17 @@ static int i_APCI1564_ConfigDigitalInput(struct 
comedi_device *dev,
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2]  4;
data[3] = data[3]  4;
-   outl(data[2],
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_IP +
-   APCI1564_DIGITAL_IP_INTERRUPT_MODE1);
-   outl(data[3],
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_IP +
-   APCI1564_DIGITAL_IP_INTERRUPT_MODE2);
+   outl(data[2], devpriv-i_IobaseAmcc + 
APCI1564_DI_INT_MODE1_REG);
+   outl(data[3], devpriv-i_IobaseAmcc + 
APCI1564_DI_INT_MODE2_REG);
if (data[1] == ADDIDATA_OR) {
-   outl(0x4,
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_IP +
-   APCI1564_DIGITAL_IP_IRQ);
+   outl(0x4, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
} else {
-   outl(0x6,
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_IP +
-   APCI1564_DIGITAL_IP_IRQ);
+   outl(0x6, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
}
} else {
-   outl(0x0,
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_IP +
-   APCI1564_DIGITAL_IP_INTERRUPT_MODE1);
-   outl(0x0,
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_IP +
-   APCI1564_DIGITAL_IP_INTERRUPT_MODE2);
-   outl(0x0,
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_IP +
-   APCI1564_DIGITAL_IP_IRQ);
+   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_INT_MODE1_REG);
+   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_INT_MODE2_REG);
+   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
}
 
return insn-n;
@@ -180,7 +167,7 @@ static int apci1564_di_insn_bits(struct comedi_device *dev,
 {
struct addi_private *devpriv = dev-private;
 
-   data[1] = inl(devpriv-i_IobaseAmcc + APCI1564_DIGITAL_IP);
+   data[1] = inl(devpriv-i_IobaseAmcc + APCI1564_DI_REG);
 
return insn-n;
 }
@@ -329,9 +316,7 @@ static int

[PATCH v2 2/5] Staging: comedi: addi-data: tidy up digital output register map defines in hwdrv_apci1564.c

This patch fixes the register map defines for the digital output registers
such that they are all the real offsets to each register, rather than a
mix of real offsets and adders to those offsets.

Further, some of the old defines were being used incorrectly in the
i_APCI1564_Reset() function.  Upon swapping the old defines out for the
new ones in this function, their use has been corrected.

Signed-off-by: Chase Southwood chase.southw...@yahoo.com
---

2: Simplified commit message, fixed indentation and whitespace damage.
I have test applied this patch, it should work now.

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 50 +++---
 1 file changed, 16 insertions(+), 34 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 2c2bbd8..d493d01 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -46,21 +46,10 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 
 #define APCI1564_ADDRESS_RANGE 128
 
-/* DIGITAL INPUT-OUTPUT DEFINE */
-
-/* Output defines */
-#define APCI1564_DIGITAL_OP0x18
-#define APCI1564_DIGITAL_OP_RW 0
-#define APCI1564_DIGITAL_OP_INTERRUPT  4
-#define APCI1564_DIGITAL_OP_IRQ12
-
 /* Digital Input IRQ Function Selection */
 #define ADDIDATA_OR0
 #define ADDIDATA_AND   1
 
-/* Digital Output Interrupt Status */
-#define APCI1564_DIGITAL_OP_INTERRUPT_STATUS   8
-
 /* Digital Input Interrupt Enable Disable. */
 #define APCI1564_DIGITAL_IP_INTERRUPT_ENABLE   0x4
 #define APCI1564_DIGITAL_IP_INTERRUPT_DISABLE  0xfffb
@@ -99,6 +88,10 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define APCI1564_DI_INT_MODE2_REG  0x0c
 #define APCI1564_DI_INT_STATUS_REG 0x10
 #define APCI1564_DI_IRQ_REG0x14
+#define APCI1564_DO_REG0x18
+#define APCI1564_DO_INT_CTRL_REG   0x1c
+#define APCI1564_DO_INT_STATUS_REG 0x20
+#define APCI1564_DO_IRQ_REG0x24
 
 /* Global variables */
 static unsigned int ui_InterruptStatus_1564;
@@ -226,12 +219,8 @@ static int i_APCI1564_ConfigDigitalOutput(struct 
comedi_device *dev,
else
ul_Command = ul_Command  0xFFFD;
 
-   outl(ul_Command,
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_OP +
-   APCI1564_DIGITAL_OP_INTERRUPT);
-   ui_InterruptData =
-   inl(devpriv-i_IobaseAmcc + APCI1564_DIGITAL_OP +
-   APCI1564_DIGITAL_OP_INTERRUPT);
+   outl(ul_Command, devpriv-i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
+   ui_InterruptData = inl(devpriv-i_IobaseAmcc + 
APCI1564_DO_INT_CTRL_REG);
devpriv-tsk_Current = current;
return insn-n;
 }
@@ -243,12 +232,10 @@ static int apci1564_do_insn_bits(struct comedi_device 
*dev,
 {
struct addi_private *devpriv = dev-private;
 
-   s-state = inl(devpriv-i_IobaseAmcc + APCI1564_DIGITAL_OP +
-   APCI1564_DIGITAL_OP_RW);
+   s-state = inl(devpriv-i_IobaseAmcc + APCI1564_DO_REG);
 
if (comedi_dio_update_state(s, data))
-   outl(s-state, devpriv-i_IobaseAmcc + APCI1564_DIGITAL_OP +
-   APCI1564_DIGITAL_OP_RW);
+   outl(s-state, devpriv-i_IobaseAmcc + APCI1564_DO_REG);
 
data[1] = s-state;
 
@@ -317,9 +304,7 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct 
comedi_device *dev,
if (data[1] == 1) {
outl(0x02, devpriv-i_IobaseAmcc + APCI1564_TIMER + 
APCI1564_TCW_PROG); /* Enable TIMER int  DISABLE ALL THE OTHER int SOURCES */
outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
-   outl(0x0,
-   devpriv-i_IobaseAmcc + APCI1564_DIGITAL_OP +
-   APCI1564_DIGITAL_OP_IRQ);
+   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DO_IRQ_REG);
outl(0x0,
devpriv-i_IobaseAmcc +
APCI1564_DIGITAL_OP_WATCHDOG +
@@ -634,8 +619,7 @@ static void v_APCI1564_Interrupt(int irq, void *d)
unsigned int ul_Command2 = 0;
 
ui_DI = inl(devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG)  0x01;
-   ui_DO = inl(devpriv-i_IobaseAmcc + APCI1564_DIGITAL_OP +
-   APCI1564_DIGITAL_OP_IRQ)  0x01;
+   ui_DO = inl(devpriv-i_IobaseAmcc + APCI1564_DO_IRQ_REG)  0x01;
ui_Timer =

[PATCH v2 4/5] Staging: comedi: addi-data: tidy up timer register map defines in hwdrv_apci1564.c

This patch for fixes the register map defines for the timer registers such
that they are all the real offsets to each register, rather than a mix of
real offsets and adders to those offsets.

Signed-off-by: Chase Southwood chase.southw...@yahoo.com
---

2: Simplified commit message, fixed indentation and whitespace damage.
I have test applied this patch, it should work now.

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 82 +-
 1 file changed, 33 insertions(+), 49 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 8ff8693..2a3523f 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -65,7 +65,6 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define ADDIDATA_TIMER 0
 #define ADDIDATA_COUNTER   1
 #define ADDIDATA_WATCHDOG  2
-#define APCI1564_TIMER 0x48
 #define APCI1564_COUNTER1  0x0
 #define APCI1564_COUNTER2  0x20
 #define APCI1564_COUNTER3  0x40
@@ -99,6 +98,14 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define APCI1564_WDOG_IRQ_REG  0x3c
 #define APCI1564_WDOG_WARN_TIMEVAL_REG 0x40
 #define APCI1564_WDOG_WARN_TIMEBASE_REG0x44
+#define APCI1564_TIMER_REG 0x48
+#define APCI1564_TIMER_RELOAD_REG  0x4c
+#define APCI1564_TIMER_TIMEBASE_REG0x50
+#define APCI1564_TIMER_CTRL_REG0x54
+#define APCI1564_TIMER_STATUS_REG  0x58
+#define APCI1564_TIMER_IRQ_REG 0x5c
+#define APCI1564_TIMER_WARN_TIMEVAL_REG0x60
+#define APCI1564_TIMER_WARN_TIMEBASE_REG   0x64
 
 /* Global variables */
 static unsigned int ui_InterruptStatus_1564;
@@ -297,15 +304,15 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct 
comedi_device *dev,
outl(data[3], devpriv-i_IobaseAmcc + APCI1564_WDOG_RELOAD_REG);
} else if (data[0] == ADDIDATA_TIMER) {
/* First Stop The Timer */
-   ul_Command1 =
-   inl(devpriv-i_IobaseAmcc + APCI1564_TIMER +
-   APCI1564_TCW_PROG);
+   ul_Command1 = inl(devpriv-i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
ul_Command1 = ul_Command1  0xF9FEUL;
-   outl(ul_Command1, devpriv-i_IobaseAmcc + APCI1564_TIMER + 
APCI1564_TCW_PROG);  /* Stop The Timer */
+   /* Stop The Timer */
+   outl(ul_Command1, devpriv-i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
 
devpriv-b_TimerSelectMode = ADDIDATA_TIMER;
if (data[1] == 1) {
-   outl(0x02, devpriv-i_IobaseAmcc + APCI1564_TIMER + 
APCI1564_TCW_PROG); /* Enable TIMER int  DISABLE ALL THE OTHER int SOURCES */
+   /* Enable TIMER int  DISABLE ALL THE OTHER int SOURCES 
*/
+   outl(0x02, devpriv-i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DI_IRQ_REG);
outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DO_IRQ_REG);
outl(0x0, devpriv-i_IobaseAmcc + 
APCI1564_WDOG_IRQ_REG);
@@ -322,25 +329,20 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct 
comedi_device *dev,
devpriv-iobase + APCI1564_COUNTER4 +
APCI1564_TCW_IRQ);
} else {
-   outl(0x0, devpriv-i_IobaseAmcc + APCI1564_TIMER + 
APCI1564_TCW_PROG);  /* disable Timer interrupt */
+   /* disable Timer interrupt */
+   outl(0x0, devpriv-i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
}
 
/*  Loading Timebase */
-   outl(data[2],
-   devpriv-i_IobaseAmcc + APCI1564_TIMER +
-   APCI1564_TCW_TIMEBASE);
+   outl(data[2], devpriv-i_IobaseAmcc + 
APCI1564_TIMER_TIMEBASE_REG);
 
/* Loading the Reload value */
-   outl(data[3],
-   devpriv-i_IobaseAmcc + APCI1564_TIMER +
-   APCI1564_TCW_RELOAD_VALUE);
+   outl(data[3], devpriv-i_IobaseAmcc + 
APCI1564_TIMER_RELOAD_REG);
 
-   ul_Command1 =
-   inl(devpriv-i_IobaseAmcc + APCI1564_TIMER +
-   APCI1564_TCW_PROG);
-   ul_Command1 =
-   (ul_Command1  0xFFF719E2UL) | 2UL  13UL | 0x10UL;
-

[PATCH v2 5/5] Staging: comedi: addi-data: tidy up counter register map defines in hwdrv_apci1564.c

This patch fixes the register map defines for the counter registers such
that they are all the real offsets to each register, rather than a mix of
real offsets and adders to those offsets.

Signed-off-by: Chase Southwood chase.southw...@yahoo.com
---

2: Simplified commit message, fixed indentation and whitespace damage.
I have test applied this patch, it should work now.
v2 also fixes several build breakages, and I have compile tested as well.
Everything should be fixed.

 .../comedi/drivers/addi-data/hwdrv_apci1564.c  | 143 +
 1 file changed, 60 insertions(+), 83 deletions(-)

diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c 
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 2a3523f..e2d3433 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -61,22 +61,13 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define APCI1564_DIGITAL_OP_CC_INTERRUPT_DISABLE   0xfffd
 
 /* TIMER COUNTER WATCHDOG DEFINES */
-
 #define ADDIDATA_TIMER 0
 #define ADDIDATA_COUNTER   1
 #define ADDIDATA_WATCHDOG  2
-#define APCI1564_COUNTER1  0x0
-#define APCI1564_COUNTER2  0x20
-#define APCI1564_COUNTER3  0x40
-#define APCI1564_COUNTER4  0x60
-#define APCI1564_TCW_SYNC_ENABLEDISABLE0
-#define APCI1564_TCW_RELOAD_VALUE  4
-#define APCI1564_TCW_TIMEBASE  8
-#define APCI1564_TCW_PROG  12
-#define APCI1564_TCW_TRIG_STATUS   16
-#define APCI1564_TCW_IRQ   20
-#define APCI1564_TCW_WARN_TIMEVAL  24
-#define APCI1564_TCW_WARN_TIMEBASE 28
+#define APCI1564_COUNTER1  0
+#define APCI1564_COUNTER2  1
+#define APCI1564_COUNTER3  2
+#define APCI1564_COUNTER4  3
 
 /*
  * devpriv-i_IobaseAmcc Register Map
@@ -107,6 +98,18 @@ This program is distributed in the hope that it will be 
useful, but WITHOUT ANY
 #define APCI1564_TIMER_WARN_TIMEVAL_REG0x60
 #define APCI1564_TIMER_WARN_TIMEBASE_REG   0x64
 
+/*
+ * devpriv-iobase Register Map
+ */
+#define APCI1564_TCW_REG(x)(0x00 + ((x) * 
0x20))
+#define APCI1564_TCW_RELOAD_REG(x) (0x04 + ((x) * 
0x20))
+#define APCI1564_TCW_TIMEBASE_REG(x)   (0x08 + ((x) * 0x20))
+#define APCI1564_TCW_CTRL_REG(x)   (0x0c + ((x) * 
0x20))
+#define APCI1564_TCW_STATUS_REG(x) (0x10 + ((x) * 
0x20))
+#define APCI1564_TCW_IRQ_REG(x)(0x14 + ((x) * 
0x20))
+#define APCI1564_TCW_WARN_TIMEVAL_REG(x)   (0x18 + ((x) * 0x20))
+#define APCI1564_TCW_WARN_TIMEBASE_REG(x)  (0x1c + ((x) * 0x20))
+
 /* Global variables */
 static unsigned int ui_InterruptStatus_1564;
 static unsigned int ui_InterruptData, ui_Type;
@@ -317,17 +320,13 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct 
comedi_device *dev,
outl(0x0, devpriv-i_IobaseAmcc + APCI1564_DO_IRQ_REG);
outl(0x0, devpriv-i_IobaseAmcc + 
APCI1564_WDOG_IRQ_REG);
outl(0x0,
-   devpriv-iobase + APCI1564_COUNTER1 +
-   APCI1564_TCW_IRQ);
+   devpriv-iobase + 
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER1));
outl(0x0,
-   devpriv-iobase + APCI1564_COUNTER2 +
-   APCI1564_TCW_IRQ);
+   devpriv-iobase + 
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER2));
outl(0x0,
-   devpriv-iobase + APCI1564_COUNTER3 +
-   APCI1564_TCW_IRQ);
+   devpriv-iobase + 
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER3));
outl(0x0,
-   devpriv-iobase + APCI1564_COUNTER4 +
-   APCI1564_TCW_IRQ);
+   devpriv-iobase + 
APCI1564_TCW_IRQ_REG(APCI1564_COUNTER4));
} else {
/* disable Timer interrupt */
outl(0x0, devpriv-i_IobaseAmcc + 
APCI1564_TIMER_CTRL_REG);
@@ -348,16 +347,13 @@ static int i_APCI1564_ConfigTimerCounterWatchdog(struct 
comedi_device *dev,
devpriv-b_ModeSelectRegister = data[5];
 
/* First Stop The Counter */
-   ul_Command1 =
-

Re: [PATCH v4 1/4] pci: APM X-Gene PCIe controller driver

2014-03-07 Thread Jingoo Han

On Thursday, March 06, 2014 3:06 PM, Tanmay Inamdar wrote:
 

Hi Tanmay Inamdar,

I added some minor comments. :-)

 This patch adds the AppliedMicro X-Gene SOC PCIe controller driver.
 X-Gene PCIe controller supports maxmum upto 8 lanes and GEN3 speed.

Would you fix the followings?

s/maxmum/maximum
s/upto/up to

 X-Gene SOC supports maximum 5 PCIe ports.
 
 Signed-off-by: Tanmay Inamdar tinam...@apm.com
 ---
  drivers/pci/host/Kconfig |   10 +
  drivers/pci/host/Makefile|1 +
  drivers/pci/host/pci-xgene.c |  739 
 ++
  3 files changed, 750 insertions(+)
  create mode 100644 drivers/pci/host/pci-xgene.c

[.]

 --- /dev/null
 +++ b/drivers/pci/host/pci-xgene.c

[.]

 +
 +static int xgene_pcie_parse_map_dma_ranges(struct xgene_pcie_port *port)
 +{
 + struct device_node *np = port-node;
 + struct of_pci_range range;
 + struct of_pci_range_parser parser;
 + struct device *dev = port-dev;
 + u8 ib_reg_mask = 0;
 +
 + if (pci_dma_range_parser_init(parser, np)) {
 + dev_err(dev, missing dma-ranges property\n);
 + return -EINVAL;
 + }
 +
 + /* Get the dma-ranges from DT */
 + for_each_of_pci_range(parser, range) {
 + u64 end = range.cpu_addr + range.size - 1;
 + dev_dbg(port-dev, 0x%08x 0x%016llx..0x%016llx - 0x%016llx\n,
 + range.flags, range.cpu_addr, end, range.pci_addr);
 + xgene_pcie_setup_ib_reg(port, range, ib_reg_mask);
 + }
 + return 0;
 +}
 +
 +static int __init xgene_pcie_probe_bridge(struct platform_device *pdev)

Please, remove '__init' marker in order to fix section mismatch
warning.

 +{
 + struct device_node *np = of_node_get(pdev-dev.of_node);
 + struct xgene_pcie_port *port;
 + struct pci_host_bridge *bridge;
 + resource_size_t lastbus;
 + u32 lanes = 0, speed = 0;
 + u64 cfg_addr = 0;
 + int ret;
 +
 + port = devm_kzalloc(pdev-dev, sizeof(*port), GFP_KERNEL);
 + if (!port)
 + return -ENOMEM;
 + port-node = np;
 + port-dev = pdev-dev;
 +
 + ret = xgene_pcie_map_reg(port, pdev, cfg_addr);
 + if (ret)
 + return ret;
 +
 + ret = xgene_pcie_init_port(port);
 + if (ret)
 + return ret;
 + xgene_pcie_program_core(port-csr_base);
 + xgene_pcie_setup_root_complex(port);
 +
 + bridge = of_create_pci_host_bridge(pdev-dev, xgene_pcie_ops, port);
 + if (IS_ERR_OR_NULL(bridge))
 + return PTR_ERR(bridge);
 +
 + ret = xgene_pcie_map_ranges(port, bridge, cfg_addr);
 + if (ret)
 + return ret;
 +
 + ret = xgene_pcie_parse_map_dma_ranges(port);
 + if (ret)
 + return ret;
 +
 + xgene_pcie_poll_linkup(port, lanes, speed);
 + if (!port-link_up)
 + dev_info(port-dev, (rc) link down\n);
 + else
 + dev_info(port-dev, (rc) x%d gen-%d link up\n,
 + lanes, speed + 1);
 + platform_set_drvdata(pdev, port);
 + lastbus = pci_rescan_bus(bridge-bus);
 + pci_bus_update_busn_res_end(bridge-bus, lastbus);
 + return 0;
 +}
 +
 +static const struct of_device_id xgene_pcie_match_table[] __initconst = {

Please, remove '__initconst' marker in order to fix section mismatch
warning.

 + {.compatible = apm,xgene-pcie,},
 + {},
 +};
 +
 +static struct platform_driver xgene_pcie_driver = {
 + .driver = {
 +.name = xgene-pcie,
 +.owner = THIS_MODULE,
 +.of_match_table = of_match_ptr(xgene_pcie_match_table),
 +   },

Please fix this indent style, as below:

+   },

See you later. :-)

Best regards,
Jingoo Han

 + .probe = xgene_pcie_probe_bridge,
 +};
 +module_platform_driver(xgene_pcie_driver);
 +
 +MODULE_AUTHOR(Tanmay Inamdar tinam...@apm.com);
 +MODULE_DESCRIPTION(APM X-Gene PCIe driver);
 +MODULE_LICENSE(GPL v2);
 --
 1.7.9.5

--
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: FlexCAN on i.MX28 interrupt flooding retrying send

2014-03-07 Thread Matthias Klein

Hello Stanislav,

I made a similar observation on an i.MX537 with the 3.12.12-rt19 kernel:
I see the same interrupt flooed when the bus is disconnected.

What do you mean with kills the machine? I have a high interrupt load,
but the machine is still responsive.

Best regards,

Matthias

-- Originalnachricht --
Von: Stanislav Meduna st...@meduna.org
An: w...@grandegger.com; m...@pengutronix.de; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org;
linux-rt-us...@vger.kernel.org linux-rt-us...@vger.kernel.org

Gesendet: 07.03.2014 09:08:42
Betreff: FlexCAN on i.MX28 interrupt flooding retrying send

Hi,

I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
If a packet is being sent when the bus is disconnected, I am getting
an interrupt flooed that basically kills the machine.

This is _not_ the same problem as [2] - my kernel already has
the fix.

The first interrupt comes with ESR 0x00028652, i.e.

TXWRN_INT
BIT1_ERR
STF_ERR
TX_WRN
TXRX
FLT_CONF error passive
ERR_INT

The next ones come the same without the acked TXWRN_INT.
Reading the ESR again immediately after acking gives
0x0250, i.e.

TX_WRN
TXRX
FLT_CONF error passive

so everything ackable has actually been acked.

I think that the problem is that the FlexCAN tries to retransmit
the frame indefinitely. Each retry senses the bus in the invalid
state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
this I aborted the transmitted frame in the error state in the
interrupt handler

#define FLEXCAN_ESR_ERR_TRANSMIT \
(FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)

if (reg_esr FLEXCAN_ESR_ERR_TRANSMIT) {

/* In case of a transmission error the packet is retried and
* if the error persists, we will get another interrupt right
* away. Abort the transmission - a lost packet is better than
* an irq storm.
*/
if(printk_ratelimit())
netdev_err(dev, Aborted transmission, ESR %08x\n, reg_esr);

can_get_echo_skb(dev, 0);
flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
regs-cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
netif_wake_queue(dev);
}

and the problem disappeared as expected. However, the correct
way is probably to retry during some reasonable (configurable?)
time interval.

What puzzles me is that I did not found any other instance
of this problem in the relevant mailing lists, only the original [2].

I am using the 3.4.77 kernel with the realtime patches, but the
code in the latest mainline looks the same in this respect.
Maybe the realtime patches change some bevaviour, but I don't
think they affect the core problem. I am not really an expert
in the network devices, NAPI etc - maybe in that case the error
interrupt should be disabled and re-enabled only if the
error condition goes away? - I don't know...

Please Cc: me when answering to the list.

[1]
http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/

[2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa

Thanks
--
Stano
--
To unsubscribe from this list: send the line unsubscribe
linux-rt-users in

the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
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 4/4] x86: Fix order of warning messages when ftrace modifies code

2014-03-07 Thread Petr Mládek

On Thu 06-03-14 18:19:53, Steven Rostedt wrote:
 
 I'm digging through older email, and notice you dropped this patch
 from your last series. It is a rather trivial patch, and I don't really
 care if it gets applied or not. But was there a reason to drop it? Or
 do you not care either?

I wanted to keep the last patch set short and easy to apply, so I kept
only the most important changes in it.

This patch is nice to have but it is rather cosmetic. I do not mind
that much about it. Feel free to drop, accept, or just merge into
any other commit.

Best Regards,
Petr

 -- Steve
 
 
 On Mon, 17 Feb 2014 16:22:53 +0100
 Petr Mladek pmla...@suse.cz wrote:
 
  The colon at the end of the printk message suggests that it should get 
  printed
  before the details printed by ftrace_bug().
  
  When touching the line, let's use the preferred pr_warn() macro as suggested
  by checkpatch.pl.
  
  Signed-off-by: Petr Mladek pmla...@suse.cz
  ---
   arch/x86/kernel/ftrace.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
  index 525a9f954c8b..ad7c38f5206b 100644
  --- a/arch/x86/kernel/ftrace.c
  +++ b/arch/x86/kernel/ftrace.c
  @@ -622,8 +622,8 @@ void ftrace_replace_code(int enable)
  return;
   
remove_breakpoints:
  +   pr_warn(Failed on %s (%d):\n, report, count);
  ftrace_bug(ret, rec ? rec-ip : 0);
  -   printk(KERN_WARNING Failed on %s (%d):\n, report, count);
  for_ftrace_rec_iter(iter) {
  int err;
   
 
--
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: FlexCAN on i.MX28 interrupt flooding retrying send

2014-03-07 Thread Marc Kleine-Budde

On 03/07/2014 09:08 AM, Stanislav Meduna wrote:
 Hi,
 
 I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
 If a packet is being sent when the bus is disconnected, I am getting
 an interrupt flooed that basically kills the machine.
 
 This is _not_ the same problem as [2] - my kernel already has
 the fix.
 
 The first interrupt comes with ESR 0x00028652, i.e.
 
 TXWRN_INT
 BIT1_ERR
 STF_ERR
 TX_WRN
 TXRX
 FLT_CONF error passive
 ERR_INT
 
 The next ones come the same without the acked TXWRN_INT.
 Reading the ESR again immediately after acking gives
 0x0250, i.e.
 
 TX_WRN
 TXRX
 FLT_CONF error passive
 
 so everything ackable has actually been acked.
 
 I think that the problem is that the FlexCAN tries to retransmit
 the frame indefinitely. Each retry senses the bus in the invalid
 state (BIT1_ERR) and immediately fires a new ERR_INT. To verify
 this I aborted the transmitted frame in the error state in the
 interrupt handler
 
 #define FLEXCAN_ESR_ERR_TRANSMIT \
   (FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)
 
 if (reg_esr  FLEXCAN_ESR_ERR_TRANSMIT) {
 
   /* In case of a transmission error the packet is retried and
* if the error persists, we will get another interrupt right
* away. Abort the transmission - a lost packet is better than
* an irq storm.
*/
   if(printk_ratelimit())
   netdev_err(dev, Aborted transmission, ESR %08x\n, reg_esr);
 
   can_get_echo_skb(dev, 0);
   flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
   regs-cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
   netif_wake_queue(dev);
 }
 
 and the problem disappeared as expected. However, the correct
 way is probably to retry during some reasonable (configurable?)
 time interval.
 
 What puzzles me is that I did not found any other instance
 of this problem in the relevant mailing lists, only the original [2].
 
 I am using the 3.4.77 kernel with the realtime patches, but the
 code in the latest mainline looks the same in this respect.
 Maybe the realtime patches change some bevaviour, but I don't
 think they affect the core problem. I am not really an expert
 in the network devices, NAPI etc - maybe in that case the error
 interrupt should be disabled and re-enabled only if the
 error condition goes away? - I don't know...

Your kernel is missing the patch:

e358784 can: flexcan: fix mx28 detection by rearanging OF match table

With this patch the CAN core properly detected as an mx28, so that bus
errors stay disabled (unless you enable them). If you need bus errors to
detect not connected CAN busses, you need another patchset berr_limit,
which is not yet mainline. I can repost it here, if you need it.

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |



signature.asc
Description: OpenPGP digital signature

Re: FlexCAN on i.MX28 interrupt flooding retrying send

2014-03-07 Thread Wolfgang Grandegger

On 03/07/2014 09:16 AM, Marc Kleine-Budde wrote:
Adding the linux-can mailinglist to Cc.

Marc

On 03/07/2014 09:08 AM, Stanislav Meduna wrote:
Hi,

I am using a FlexCAN CAN controller on a Freescale i.MX28 platform [1].
If a packet is being sent when the bus is disconnected, I am getting
an interrupt flooed that basically kills the machine.

This is _not_ the same problem as [2] - my kernel already has
the fix.

The first interrupt comes with ESR 0x00028652, i.e.

TXWRN_INT
BIT1_ERR
STF_ERR
TX_WRN
TXRX
FLT_CONF error passive
ERR_INT

The next ones come the same without the acked TXWRN_INT.
Reading the ESR again immediately after acking gives
0x0250, i.e.

TX_WRN
TXRX
FLT_CONF error passive

so everything ackable has actually been acked.

#define FLEXCAN_ESR_ERR_TRANSMIT \
(FLEXCAN_ESR_BIT1_ERR | FLEXCAN_ESR_BIT0_ERR | FLEXCAN_ESR_ACK_ERR)

if (reg_esr FLEXCAN_ESR_ERR_TRANSMIT) {

can_get_echo_skb(dev, 0);
flexcan_write(FLEXCAN_MB_CNT_CODE(0x4),
regs-cantxfg[FLEXCAN_TX_BUF_ID].can_ctrl);
netif_wake_queue(dev);
}

and the problem disappeared as expected. However, the correct
way is probably to retry during some reasonable (configurable?)
time interval.

What puzzles me is that I did not found any other instance
of this problem in the relevant mailing lists, only the original [2].

Please Cc: me when answering to the list.

[1]
http://www.tq-group.com/en/products/product-details/prod/embedded-modul-tqma28/extb/Main/productdetail/
[2] https://gitorious.org/linux-can/wg-linux-can-next/commit/8ad94fa

If bus-error reporting is enabled, you will get an interrupt for each
TX retry. That's normal behavior. But for the i.MX28 it should not be
enabled:

$ cat flexcan.c
...
/*
* enable the error interrupt (FLEXCAN_CTRL_ERR_MSK),
* on most Flexcan cores, too. Otherwise we don't get
* any error warning or passive interrupts.
*/
if (priv-devtype_data-features FLEXCAN_HAS_BROKEN_ERR_STATE ||
priv-can.ctrlmode CAN_CTRLMODE_BERR_REPORTING)
reg_ctrl |= FLEXCAN_CTRL_ERR_MSK;

Maybe there is something wrong with you platform code or DTS file. What
kernel are you using and how is the DTS can node defined in your DTS file?

Wolfgang.

RE: [PATCH 1/1] Drivers: hv: vmbus: Include the limit on the number of pfns we can handle

2014-03-07 Thread KY Srinivasan

 -Original Message-
 From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
 Sent: Friday, March 7, 2014 1:46 PM
 To: KY Srinivasan
 Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
 de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
 jasow...@redhat.com
 Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Include the limit on the number
 of pfns we can handle

 On Thu, Mar 06, 2014 at 11:15:08PM -0800, K. Y. Srinivasan wrote:
  Increase the maximum number of pfns we can handle is a single vmbus
 packet.
 ^^ in

Thanks Dan. I am traveling in India and it shows. I have already sent a 
corrected patch.

 What are the user visible effects of this patch?
The current code will drop these packets that have more PFNs than the limit.
Upping the limit will mitigate this problem.

Regards,

K. Y

 regards,
 dan carpenter

--
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/

[V5 2/4] perf, tool: Conditional branch filter 'cond' added to perf record

Adding perf record support for new branch stack filter criteria
PERF_SAMPLE_BRANCH_COND.

Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Reviewed-by: Stephane Eranian eran...@google.com
---
 tools/perf/builtin-record.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 3c394bf..eb74bcd 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -589,6 +589,7 @@ static const struct branch_mode branch_modes[] = {
BRANCH_OPT(abort_tx, PERF_SAMPLE_BRANCH_ABORT_TX),
BRANCH_OPT(in_tx, PERF_SAMPLE_BRANCH_IN_TX),
BRANCH_OPT(no_tx, PERF_SAMPLE_BRANCH_NO_TX),
+   BRANCH_OPT(cond, PERF_SAMPLE_BRANCH_COND),
BRANCH_END
 };
 
-- 
1.7.11.7

--
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/

[V5 1/4] perf: Add PERF_SAMPLE_BRANCH_COND

This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which
will extend the existing perf ABI. Various architectures can provide
this functionality with either with HW filtering support (if present)
or with SW filtering of captured branch instructions.

Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Reviewed-by: Stephane Eranian eran...@google.com
---
 include/uapi/linux/perf_event.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index 853bc1c..696f69b4 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -163,8 +163,9 @@ enum perf_branch_sample_type {
PERF_SAMPLE_BRANCH_ABORT_TX = 1U  7, /* transaction aborts */
PERF_SAMPLE_BRANCH_IN_TX= 1U  8, /* in transaction */
PERF_SAMPLE_BRANCH_NO_TX= 1U  9, /* not in transaction */
+   PERF_SAMPLE_BRANCH_COND = 1U  10, /* conditional branches */
 
-   PERF_SAMPLE_BRANCH_MAX  = 1U  10, /* non-ABI */
+   PERF_SAMPLE_BRANCH_MAX  = 1U  11, /* non-ABI */
 };
 
 #define PERF_SAMPLE_BRANCH_PLM_ALL \
-- 
1.7.11.7

--
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/

[V5 0/4] perf: New conditional branch filter

Hello Arnaldo,

I had posted the V5 version of PowerPC SW branch filter enablement
patchset last month. Please find the patchset here at

https://lkml.org/lkml/2014/2/5/79

These following patches (2,4,5,6 patches from the original V5 version patchset)
are the ones which change code in the generic kernel, perf tool and X86 perf.
Basically this patchset adds one more branch filter for conditional branches.
In X86 code, this new filter has been implemented with the help of availble SW
filter X86_BR_JCC and LBR_JCC. We had some discussions in this regard before.
Please review these changes and if it's okay, please merge them. Other patches
in the series are powerpc specific and are being reviewed by Benjamin 
Herrenschmidt
and Michael Ellerman. Let me know if you need more information.

[1] https://lkml.org/lkml/2013/5/22/51
[2] https://lkml.org/lkml/2013/8/30/10
[3] https://lkml.org/lkml/2013/10/16/75
[4] https://lkml.org/lkml/2013/12/4/168
[5] https://lkml.org/lkml/2014/2/5/79

c: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Stephane Eranian eran...@google.com
Cc: Andi Kleen a...@linux.intel.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Michael Ellerman mich...@ellerman.id.au
Cc: Peter Zijlstra a.p.zijls...@chello.nl

Anshuman Khandual (4):
  perf: Add PERF_SAMPLE_BRANCH_COND
  perf, tool: Conditional branch filter 'cond' added to perf record
  x86, perf: Add conditional branch filtering support
  perf, documentation: Description for conditional branch filter

 arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 +
 include/uapi/linux/perf_event.h| 3 ++-
 tools/perf/Documentation/perf-record.txt   | 3 ++-
 tools/perf/builtin-record.c| 1 +
 4 files changed, 10 insertions(+), 2 deletions(-)

-- 
1.7.11.7

--
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/

[V5 4/4] perf, documentation: Description for conditional branch filter

Adding documentation support for conditional branch filter.

Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Reviewed-by: Stephane Eranian eran...@google.com
---
 tools/perf/Documentation/perf-record.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index c71b0f3..d460049 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -184,9 +184,10 @@ following filters are defined:
- in_tx: only when the target is in a hardware transaction
- no_tx: only when the target is not in a hardware transaction
- abort_tx: only when the target is a hardware transaction abort
+   - cond: conditional branches
 
 +
-The option requires at least one branch type among any, any_call, any_ret, 
ind_call.
+The option requires at least one branch type among any, any_call, any_ret, 
ind_call, cond.
 The privilege levels may be omitted, in which case, the privilege levels of 
the associated
 event are applied to the branch filter. Both kernel (k) and hypervisor (hv) 
privilege
 levels are subject to permissions.  When sampling on multiple events, branch 
stack sampling
-- 
1.7.11.7

--
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/

[V5 3/4] x86, perf: Add conditional branch filtering support

This patch adds conditional branch filtering support,
enabling it for PERF_SAMPLE_BRANCH_COND in perf branch
stack sampling framework by utilizing an available
software filter X86_BR_JCC.

Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Reviewed-by: Stephane Eranian eran...@google.com
---
 arch/x86/kernel/cpu/perf_event_intel_lbr.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/kernel/cpu/perf_event_intel_lbr.c 
b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
index d82d155..9dd2459 100644
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -384,6 +384,9 @@ static void intel_pmu_setup_sw_lbr_filter(struct perf_event 
*event)
if (br_type  PERF_SAMPLE_BRANCH_NO_TX)
mask |= X86_BR_NO_TX;
 
+   if (br_type  PERF_SAMPLE_BRANCH_COND)
+   mask |= X86_BR_JCC;
+
/*
 * stash actual user request into reg, it may
 * be used by fixup code for some CPU
@@ -678,6 +681,7 @@ static const int nhm_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
 * NHM/WSM erratum: must include IND_JMP to capture IND_CALL
 */
[PERF_SAMPLE_BRANCH_IND_CALL] = LBR_IND_CALL | LBR_IND_JMP,
+   [PERF_SAMPLE_BRANCH_COND] = LBR_JCC,
 };
 
 static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
@@ -689,6 +693,7 @@ static const int snb_lbr_sel_map[PERF_SAMPLE_BRANCH_MAX] = {
[PERF_SAMPLE_BRANCH_ANY_CALL]   = LBR_REL_CALL | LBR_IND_CALL
| LBR_FAR,
[PERF_SAMPLE_BRANCH_IND_CALL]   = LBR_IND_CALL,
+   [PERF_SAMPLE_BRANCH_COND]   = LBR_JCC,
 };
 
 /* core */
-- 
1.7.11.7

--
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: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

2014-03-07 Thread Fengguang Wu

Hi Stefani,

On Fri, Mar 07, 2014 at 09:47:14AM +0100, Stefani Seibold wrote:
 Hi Fengguang,
 
 i was now able to bring up the kernel on my KVM with some minior
 changes. I kick out the PARIDE, switched to IDE and activated the VT
 support. With this modifications the kernel boot and i get no BUG,
 everything is fine!
 
 So i can not reproduce the bug and i want ask you to check the attached
 kernel config. If this also works for you the problem is maybe located
 in the environment, f.e. gcc.

I'm using gcc 4.8.1, as you can see from the 2nd line of the below dmesg.
I can reproduce it reliably - see the screen dump below. You can find
the reproduce script at the end of this email.

wfg@bee 
/kernel/i386-randconfig-nh0-03070222/d478a960edf1ea61ca31a07a48a8771f043dba78% 
kvm-0day.sh vmlinuz-3.14.0-rc5-03765-gd478a96
early console in setup code
[0.00] Linux version 3.14.0-rc5-03765-gd478a96 (kbuild@nhm4) (gcc 
version 4.8.1 (Debian 4.8.1-8) ) #2 SMP PREEMPT Fri Mar 7 03:16:44 CST 2014
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0fffdfff] usable
[0.00] BIOS-e820: [mem 0x0fffe000-0x0fff] reserved
[0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] Hypervisor detected: KVM
[0.00] e820: update [mem 0x-0x0fff] usable == reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0xfffe max_arch_pfn = 0x100
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 008000 mask FF8000 uncachable
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] initial memory mapped: [mem 0x-0x023f]
[0.00] Base memory trampoline at [c009b000] 9b000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x000f]
[0.00]  [mem 0x-0x000f] page 4k
[0.00] init_memory_mapping: [mem 0x0fa0-0x0fbf]
[0.00]  [mem 0x0fa0-0x0fbf] page 4k
[0.00] BRK [0x01e02000, 0x01e02fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x0c00-0x0f9f]
[0.00]  [mem 0x0c00-0x0f9f] page 4k
[0.00] BRK [0x01e03000, 0x01e03fff] PGTABLE
[0.00] BRK [0x01e04000, 0x01e04fff] PGTABLE
[0.00] BRK [0x01e05000, 0x01e05fff] PGTABLE
[0.00] BRK [0x01e06000, 0x01e06fff] PGTABLE
[0.00] BRK [0x01e07000, 0x01e07fff] PGTABLE
[0.00] init_memory_mapping: [mem 0x0010-0x0bff]
[0.00]  [mem 0x0010-0x0bff] page 4k
[0.00] init_memory_mapping: [mem 0x0fc0-0x0fffdfff]
[0.00]  [mem 0x0fc0-0x0fffdfff] page 4k
[0.00] RAMDISK: [mem 0x0fce6000-0x0ffe]
[0.00] ACPI: RSDP 0x000F16B0 14 (v00 BOCHS )
[0.00] ACPI: RSDT 0x0FFFE3F0 34 (v01 BOCHS  BXPCRSDT 0001 BXPC 
0001)
[0.00] ACPI: FACP 0x0F80 74 (v01 BOCHS  BXPCFACP 0001 BXPC 
0001)
[0.00] ACPI: DSDT 0x0FFFE430 001137 (v01 BXPC   BXDSDT   0001 INTL 
20100528)
[0.00] ACPI: FACS 0x0F40 40
[0.00] ACPI: SSDT 0x06A0 000899 (v01 BOCHS  BXPCSSDT 0001 BXPC 
0001)
[0.00] ACPI: APIC 0x05B0 80 (v01 BOCHS  BXPCAPIC 0001 BXPC 
0001)
[0.00] ACPI: HPET 0x0570 38 (v01 BOCHS  BXPCHPET 0001 BXPC 
0001)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] mapped APIC to 9000 (fee0)
[0.00] 255MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0fffe000
[0.00]   low ram: 0 - 0fffe000
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.00] kvm-clock: cpu 0, msr 0:fffd001, primary cpu clock
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x1000-0x00ff]
[0.00]   Normal   [mem 0x0100-0x0fffdfff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x1000-0x0009efff]
[0.00]   node   0: [mem 0x0010-0x0fffdfff]
[0.00] On node 0 totalpages: 65436
[0.00] free_area_init_node: node 0, pgdat c17e5120,

[PATCH v2 0/5] Add USB nodes for am43xx epos and gp evm

The patch series adds USB dt nodes for am43xx epos and gp evm

Boot tested with  Benoit's for_3.15 + following patches

https://patchwork.kernel.org/patch/3600821/
https://patchwork.kernel.org/patch/3600831/
https://patchwork.kernel.org/patch/3600851/
https://patchwork.kernel.org/patch/3600841/


Changes from v1 - v2
* Reorder doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
* Address v1 coments on ARM: dts: AM4372: Add USB nodes  


George Cherian (5):
  doc: Add ti,am437x-dwc3 comaptible for dwc3 glue
  ARM: dts: am43xx clock data
  ARM: dts: AM4372: Add USB nodes
  ARM: dts: am437x-gp-evm: Enable USB
  ARM: dts: am43x-epos-evm: Enable USB

 Documentation/devicetree/bindings/usb/omap-usb.txt |  4 +-
 arch/arm/boot/dts/am4372.dtsi  | 95 ++
 arch/arm/boot/dts/am437x-gp-evm.dts| 28 +++
 arch/arm/boot/dts/am43x-epos-evm.dts   | 27 ++
 arch/arm/boot/dts/am43xx-clocks.dtsi   | 17 
 5 files changed, 170 insertions(+), 1 deletion(-)

-- 
1.8.3.1

--
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/

[PATCH v2 5/5] ARM: dts: am43x-epos-evm: Enable USB

Enable
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB

for am43x-epos-evm

Signed-off-by: George Cherian george.cher...@ti.com
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index a7d0db1..d2a5831 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -251,3 +251,30 @@
pinctrl-0 = spi1_pins;
status = okay;
 };
+
+
+usb2_phy1 {
+   status = okay;
+};
+
+dwc3_1 {
+   status = okay;
+};
+
+usb1 {
+   dr_mode = peripheral;
+   status = okay;
+};
+
+usb2_phy2 {
+   status = okay;
+};
+
+dwc3_2 {
+   status = okay;
+};
+
+usb2 {
+   dr_mode = host;
+   status = okay;
+};
-- 
1.8.3.1

--
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] tools/net/Makefile: Define PACKAGE to fix bfd build problems

2014-03-07 Thread Markos Chandras

On 03/06/2014 05:54 PM, David Miller wrote:

From: Markos Chandras markos.chand...@imgtec.com
Date: Thu, 6 Mar 2014 09:15:54 +

Fixes the following build problem with binutils-2.24

gcc -Wall -O2   -c -o bpf_jit_disasm.o bpf_jit_disasm.c
In file included from bpf_jit_disasm.c:25:0:
/usr/include/bfd.h:35:2: error: #error config.h must be included
before this header
  #error config.h must be included before this header

This is similar to commit 3ce711a6abc27abce1554e1d671a8762b7187690
perf tools: bfd.h/libbfd detection fails with recent binutils

See: https://sourceware.org/bugzilla/show_bug.cgi?id=14243

CC: David S. Miller da...@davemloft.net
CC: Daniel Borkmann dbork...@redhat.com
Signed-off-by: Markos Chandras markos.chand...@imgtec.com

I think your subject needs to be adjusted, this patch doesn't fix a bfd
build problem.

Hi David,

Thanks for the comment. Well it's problem caused by the bfd header. 
However, I suppose you can remove the 'bfd' word from the subject as I 
understand it's confusing. Would you be able to fix this before you 
apply this patch or should I send a new patch?

--
markos
--
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/

[PATCH v2 3/5] ARM: dts: AM4372: Add USB nodes

Add nodes for 2 instances each of
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB

for AM43xx.

Signed-off-by: George Cherian george.cher...@ti.com
---
 arch/arm/boot/dts/am4372.dtsi | 95 +++
 1 file changed, 95 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 5a7cc38..fdcdf1b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -698,6 +698,101 @@
   edma 11;
dma-names = tx, rx;
};
+
+   am43xx_control_usb2phy1: control-phy@44e10620 {
+   compatible = ti,control-phy-usb2-am437;
+   reg = 0x44e10620 0x4;
+   reg-names = power;
+   };
+
+   am43xx_control_usb2phy2: control-phy@0x44e10628 {
+   compatible = ti,control-phy-usb2-am437;
+   reg = 0x44e10628 0x4;
+   reg-names = power;
+   };
+
+   ocp2scp0: ocp2scp@483a8000 {
+   compatible = ti,omap-ocp2scp;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   ti,hwmods = ocp2scp0;
+
+   usb2_phy1: phy@483a8000 {
+   compatible = ti,am437x-usb2;
+   reg = 0x483a8000 0x8000;
+   ctrl-module = am43xx_control_usb2phy1;
+   clocks = clk_32768_ck,
+usb_otg_ss0_refclk960m;
+   clock-names = wkupclk, refclk;
+   #phy-cells = 0;
+   status = disabled;
+   };
+   };
+
+   ocp2scp1: ocp2scp@483e8000 {
+   compatible = ti,omap-ocp2scp;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   ti,hwmods = ocp2scp1;
+
+   usb2_phy2: phy@483e8000 {
+   compatible = ti,am437x-usb2;
+   reg = 0x483e8000 0x8000;
+   ctrl-module = am43xx_control_usb2phy2;
+   clocks = clk_32768_ck,
+usb_otg_ss1_refclk960m;
+   clock-names = wkupclk, refclk;
+   #phy-cells = 0;
+   status = disabled;
+   };
+   };
+
+   dwc3_1: omap_dwc3@4838 {
+   compatible = ti,am437x-dwc3;
+   ti,hwmods = usb_otg_ss0;
+   reg = 0x4838 0x1;
+   interrupts = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
+   #address-cells = 1;
+   #size-cells = 1;
+   utmi-mode = 1;
+   ranges;
+
+   usb1: usb@4839 {
+   compatible = synopsys,dwc3;
+   reg = 0x4839 0x17000;
+   interrupts = GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH;
+   phys = usb2_phy1;
+   phy-names = usb2-phy;
+   maximum-speed = high-speed;
+   dr_mode = otg;
+   status = disabled;
+   };
+   };
+
+   dwc3_2: omap_dwc3@483c {
+   compatible = ti,am437x-dwc3;
+   ti,hwmods = usb_otg_ss1;
+   reg = 0x483c 0x1;
+   interrupts = GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH;
+   #address-cells = 1;
+   #size-cells = 1;
+   utmi-mode = 1;
+   ranges;
+
+   usb2: usb@483d {
+   compatible = synopsys,dwc3;
+   reg = 0x483d 0x17000;
+   interrupts = GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH;
+   phys = usb2_phy2;
+   phy-names = usb2-phy;
+   maximum-speed = high-speed;
+   dr_mode = otg;
+   status = disabled;
+   };
+   };
+
};
 };
 
-- 
1.8.3.1

--
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/

[PATCH v2 4/5] ARM: dts: am437x-gp-evm: Enable USB

Enable
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
for am437x-gp-evm

Signed-off-by: George Cherian george.cher...@ti.com
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 4eb72b8..1d516a7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -98,3 +98,31 @@
 gpio4 {
status = okay;
 };
+
+
+usb2_phy1 {
+   status = okay;
+};
+
+dwc3_1 {
+   status = okay;
+};
+
+usb1 {
+   dr_mode = peripheral;
+   status = okay;
+};
+
+
+usb2_phy2 {
+   status = okay;
+};
+
+dwc3_2 {
+   status = okay;
+};
+
+usb2 {
+   dr_mode = host;
+   status = okay;
+};
-- 
1.8.3.1

--
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] spi/s3c64xx: Update DT binding documentation to match code

2014-03-07 Thread Charles Keepax

On Fri, Mar 07, 2014 at 10:48:41AM +0800, Mark Brown wrote:
 On Thu, Mar 06, 2014 at 05:05:39PM +, Charles Keepax wrote:
 
  The following patch added support for spi controllers with a dedicated
  chip select pin:
  
  commit 3146beec21b64f4551fcf0ac148381d54dc41b1b
  spi: s3c64xx: Added provision for dedicated cs pin
  
  It updated the device tree binding to require a cs-gpio property to be
  specified on the spi controller node if chip selects will be given as
  GPIOs per slave, rather than the controller having a dedicated internal
  chip select pin.
 
 No, it doesn't - it's saying that if the device has a cs-gpio property
 then to use that as the chip select.  It's not a boolean, it's a GPIO
 specifier.  Looking at the code it looks like the intention is to search
 all children for a cs-gpio during the controller probe, it's possible
 that this isn't working correctly.

That is basically part of my question is the current setup doing
what it is intended to? The Samsung binding has controller-data
blocks on each of the slaves that specify the gpio for that
slave.

@@ -1326,7 +1340,11 @@ static int s3c64xx_spi_probe(struct platform_device 
*pdev)
sdd-cntrlr_info = sci;
sdd-pdev = pdev;
sdd-sfr_start = mem_res-start;
+   sdd-cs_gpio = true;
if (pdev-dev.of_node) {
+   if (!of_find_property(pdev-dev.of_node, cs-gpio, NULL))
+   sdd-cs_gpio = false;

This part of the original patch adds the check, I guess the
mistake could be an assumption that of_find_property will
recursively check all the children, which it won't. This will
just check the controller node itself for a cs-gpio property but
as these are specified within sub-nodes they won't be found.
Hence currently you need to add one at the controller level.

Thanks,
Charles
--
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/

[PATCH v2 1/5] doc: Add ti,am437x-dwc3 comaptible for dwc3 glue

Add the compatible ti,am437x-dwc3 for dwc3 glue driver.

Signed-off-by: George Cherian george.cher...@ti.com
---
 Documentation/devicetree/bindings/usb/omap-usb.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38b2fae..38d9bb8 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -44,7 +44,9 @@ Board specific device node entry
 };
 
 OMAP DWC3 GLUE
- - compatible : Should be ti,dwc3
+ - compatible : Should be
+   * ti,dwc3 for OMAP5 and DRA7
+   * ti,am437x-dwc3 for AM437x
  - ti,hwmods : Should be usb_otg_ss
  - reg : Address and length of the register set for the device.
  - interrupts : The irq number of this device that is used to interrupt the
-- 
1.8.3.1

--
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/

[PATCH v2 2/5] ARM: dts: am43xx clock data

Add USB reference clock data

Signed-off-by: George Cherian george.cher...@ti.com
---
 arch/arm/boot/dts/am43xx-clocks.dtsi | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi 
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..506d036 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -653,4 +653,21 @@
clocks = clk_32768_ck, clk_32k_tpm_ck;
reg = 0x4260;
};
+
+   usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
+   #clock-cells = 0;
+   compatible = ti,gate-clock;
+   clocks = dpll_per_clkdcoldo;
+   ti,bit-shift = 8;
+   reg = 0x8a60;
+   };
+
+   usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
+   #clock-cells = 0;
+   compatible = ti,gate-clock;
+   clocks = dpll_per_clkdcoldo;
+   ti,bit-shift = 8;
+   reg = 0x8a68;
+   };
+
 };
-- 
1.8.3.1

--
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/1] Drivers: hv: vmbus: Include the limit on the number of pfns we can handle

On Fri, Mar 07, 2014 at 09:07:42AM +, KY Srinivasan wrote:

  -Original Message-
  From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
  Sent: Friday, March 7, 2014 1:46 PM
  To: KY Srinivasan
  Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
  de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
  jasow...@redhat.com
  Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Include the limit on the number
  of pfns we can handle

  On Thu, Mar 06, 2014 at 11:15:08PM -0800, K. Y. Srinivasan wrote:
   Increase the maximum number of pfns we can handle is a single vmbus
  packet.
  ^^ in

 Thanks Dan. I am traveling in India and it shows. I have already sent a 
 corrected patch.

Yeah.  I saw that.  Thanks.

  What are the user visible effects of this patch?
 The current code will drop these packets that have more PFNs than the limit.
 Upping the limit will mitigate this problem.

Meanwhile, the revised patch says that it is not a bugfix.  It sort of
sounds like upping the limit does improve performance for some people?

I am confused now.

regards,
dan carpenter

--
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] zram: propagate error to user

2014-03-07 Thread Sergey Senozhatsky

On (03/07/14 10:56), Minchan Kim wrote:
 When we initialized zcomp with single, we couldn't change
 max_comp_streams without zram reset but current interface doesn't
 show any error to user and even it changes max_comp_streams's value
 without any effect so it would make user very confusing.
 
 This patch prevents max_comp_streams's change when zcomp was
 initialized as single zcomp and emit the error to user(ex, echo).
 
 Signed-off-by: Minchan Kim minc...@kernel.org
 ---
  Documentation/blockdev/zram.txt |  9 +
  drivers/block/zram/zcomp.c  | 10 +-
  drivers/block/zram/zcomp.h  |  4 ++--
  drivers/block/zram/zram_drv.c   | 15 +++
  4 files changed, 23 insertions(+), 15 deletions(-)
 
 diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
 index 2604ffed51db..0595c3f56ccf 100644
 --- a/Documentation/blockdev/zram.txt
 +++ b/Documentation/blockdev/zram.txt
 @@ -37,10 +37,11 @@ Note:
  In order to enable compression backend's multi stream support 
 max_comp_streams
  must be initially set to desired concurrency level before ZRAM device
  initialisation. Once the device initialised as a single stream compression
 -backend (max_comp_streams equals to 0) changing the value of max_comp_streams
 -will not take any effect, because single stream compression backend 
 implemented
 -as a special case and does not support dynamic max_comp_streams. Only multi
 -stream backend supports dynamic max_comp_streams adjustment.
 +backend (max_comp_streams equals to 1), you will see error if you try to 
 change
 +the value of max_comp_streams because single stream compression backend
 +implemented as a special case by lock overhead issue and does not support
 +dynamic max_comp_streams. Only multi stream backend supports dynamic
 +max_comp_streams adjustment.
  
  3) Select compression algorithm
   Using comp_algorithm device attribute one can see available and
 diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
 index 92a83df40a27..15fe6a27781b 100644
 --- a/drivers/block/zram/zcomp.c
 +++ b/drivers/block/zram/zcomp.c
 @@ -152,7 +152,7 @@ static void zcomp_strm_multi_release(struct zcomp *comp, 
 struct zcomp_strm *zstr
  }
  
  /* change max_strm limit */
 -static int zcomp_strm_multi_set_max_streams(struct zcomp *comp, int num_strm)
 +static bool zcomp_strm_multi_set_max_streams(struct zcomp *comp, int 
 num_strm)
  {
   struct zcomp_strm_multi *zs = comp-stream;
   struct zcomp_strm *zstrm;
 @@ -171,7 +171,7 @@ static int zcomp_strm_multi_set_max_streams(struct zcomp 
 *comp, int num_strm)
   zs-avail_strm--;
   }
   spin_unlock(zs-strm_lock);
 - return 0;
 + return true;
  }
  
  static void zcomp_strm_multi_destroy(struct zcomp *comp)
 @@ -231,10 +231,10 @@ static void zcomp_strm_single_release(struct zcomp 
 *comp,
   mutex_unlock(zs-strm_lock);
  }
  
 -static int zcomp_strm_single_set_max_streams(struct zcomp *comp, int 
 num_strm)
 +static bool zcomp_strm_single_set_max_streams(struct zcomp *comp, int 
 num_strm)
  {
   /* zcomp_strm_single support only max_comp_streams == 1 */
 - return -ENOTSUPP;
 + return 0;
  }

IMHO, -ENOTSUPP for unsupported operation fits better than `false'.
yes, currently there are only two possible returns:
0 -- success
-ENOTSUPP - not supported operation

though, we can extend functions later and return additional codes, other
than `false' and `true'.

for example, -E2BIG if user requested extremly large number of streams,
like 5000 streams.

  
  static void zcomp_strm_single_destroy(struct zcomp *comp)
 @@ -283,7 +283,7 @@ ssize_t zcomp_available_show(const char *comp, char *buf)
   return sz;
  }
  
 -int zcomp_set_max_streams(struct zcomp *comp, int num_strm)
 +bool zcomp_set_max_streams(struct zcomp *comp, int num_strm)
  {
   return comp-set_max_streams(comp, num_strm);
  }
 diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
 index 8b8997f8613b..c59d1fca72c0 100644
 --- a/drivers/block/zram/zcomp.h
 +++ b/drivers/block/zram/zcomp.h
 @@ -46,7 +46,7 @@ struct zcomp {
  
   struct zcomp_strm *(*strm_find)(struct zcomp *comp);
   void (*strm_release)(struct zcomp *comp, struct zcomp_strm *zstrm);
 - int (*set_max_streams)(struct zcomp *comp, int num_strm);
 + bool (*set_max_streams)(struct zcomp *comp, int num_strm);
   void (*destroy)(struct zcomp *comp);
  };
  
 @@ -64,5 +64,5 @@ int zcomp_compress(struct zcomp *comp, struct zcomp_strm 
 *zstrm,
  int zcomp_decompress(struct zcomp *comp, const unsigned char *src,
   size_t src_len, unsigned char *dst);
  
 -int zcomp_set_max_streams(struct zcomp *comp, int num_strm);
 +bool zcomp_set_max_streams(struct zcomp *comp, int num_strm);
  #endif /* _ZCOMP_H_ */
 diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
 index 7631ef0cbc41..eead9db9b100 100644
 --- a/drivers/block/zram/zram_drv.c
 +++

Re: [PATCH] checkpatch: net and drivers/net: Warn on missing blank line after variable declaration

2014-03-07 Thread Joe Perches

On Fri, 2014-03-07 at 10:54 +0300, Dan Carpenter wrote:
 How many warnings does this generate does this generate when you run it
 across the whole tree?

A lot.

Check back with me after the week or so
it'll take to run on this little netboook.

Try this with both patches applied if you want
to know yourself...

$ git ls-files | grep \.[ch]$| \
  xargs ./scripts/checkpatch.pl -f --strict --types=spacing --emacs --terse | \
  grep Missing a blank



--
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 V1 2/2] rtc: da9063: RTC driver

2014-03-07 Thread Alessandro Zummo

On Thu, 6 Mar 2014 16:40:02 +
Opensource [Steve Twiss] stwiss.opensou...@diasemi.com wrote:

 Change History:
 
 Changes made to this driver since previous RFC V1
 Comments by Alessandro Zummo
 - http://www.kernelhub.org/?p=2msg=426327
 - Use return PTR_ERR(rtc-rtc_dev); instead of goto err; return err.
 - Request the interrupt before the RTC device is registered with the
   call to devm_rtc_device_register.


 Acked-by: Alessandro Zummo a.zu...@towertech.it

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

--
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] ath6kl: sdio: fix system panic when doing wifi stress test

2014-03-07 Thread Steffen Trumtrar

Hi!

On Fri, Nov 29, 2013 at 06:02:11AM +, Hui Liu wrote:
  -Original Message-
  From: Kalle Valo [mailto:kv...@qca.qualcomm.com]
  Sent: Tuesday, November 26, 2013 6:40 PM
  To: Liu Hui-R64343
  Cc: linux-arm-ker...@lists.infradead.org; linvi...@tuxdriver.com; linux-
  wirel...@vger.kernel.org; net...@vger.kernel.org; linux-
  ker...@vger.kernel.org; ath6kl-de...@qca.qualcomm.com
  Subject: Re: [PATCH] ath6kl: sdio: fix system panic when doing wifi
  stress test

  Hi Jason,

  Jason Liu r64...@freescale.com writes:

   When did the wifi iperf test, meet one following kernel panic:
   command: iperf -c $TARGET_IP -i 5 -t 50 -w 1M

   Unable to handle kernel paging request at virtual address 1a48 pgd
   = 80004000 [1a48] *pgd= Internal error: Oops: 805 [#1] SMP
   ARM

  [...]

   The kernel panic is caused by the sg_buf is not set correctly with the
   following code when compiled with Yocto GCC 4.8.1:

   drivers/net/wireless/ath/ath6kl/hif.h:
   struct hif_scatter_req {
   struct list_head list;
   /* address for the read/write operation */
   u32 addr;
 ...

   /* bounce buffer for upper layers to copy to/from */
   u8 *virt_dma_buf;

   struct hif_scatter_item scat_list[1];

   u32 scat_q_depth;
   };

   (Note: the scat_req.scat_list[] will dynamiclly grow with run-time)

  There's actually a major bug right there, scat_list can corrupt
  scat_q_depth.

   The GCC 4.8.1 compiler will not do the for-loop till scat_entries,
   instead, it only run one round loop. This may be caused by that the
   GCC 4.8.1 thought that the scat_list only have one item and then no
   need to do full iteration, but this is simply wrong by looking at the
   assebly code. This will cause the sg buffer not get set when
  scat_entries  1 and thus lead to kernel panic.

   This patch is a workaround to the GCC 4.8.1 complier issue by passing
   the entry address of the scat_req-scat_list to the for-loop and
   interate it, then, GCC 4.8.1 will do the full for-loop correctly.
   (Note: This issue not observed with GCC 4.7.2, only found on the GCC
   4.8.1)

   This patch does not change any function logic and no any performance
  downgrade.

  [...]

   + scat_list = scat_req-scat_list[0];
   +
 /* assemble SG list */
   - for (i = 0; i  scat_req-scat_entries; i++, sg++) {
   + for (i = 0; i  scat_req-scat_entries; i++, sg++, scat_list++) {
 ath6kl_dbg(ATH6KL_DBG_SCATTER, %d: addr:0x%p, len:%d\n,
   -i, scat_req-scat_list[i].buf,
   -scat_req-scat_list[i].len);
   +i, scat_list-buf, scat_list-len);

   - sg_set_buf(sg, scat_req-scat_list[i].buf,
   -scat_req-scat_list[i].len);
   + sg_set_buf(sg, scat_list-buf, scat_list-len);
 }

  Working around the problem by adding a temporary variable makes me a bit
  worried, I would rather fix the root cause. Is the root cause by that we
  define the field with scat_list[1]?

 Yes, this is what I assumed. 

  Does the patch below help? It would also fix the corruption with
  scat_q_depth. Please note that I have only compile tested it. And I might
  have also missed something important, so please review it carefully.

 Yes, Firstly, I have looked at the asm code and the compiler(gcc 4.8.1) works 
 correctly after applying
 the following patch. Secondly, I have tested the patch with compiler(gcc 
 4.8.1) on the real HW, and it
 works fine too. Without the patch, the kernel crash will happen 100%.

 Thus, for the patch:

 Acked-by: Jason Liu r64...@freescale.com
 Tested-by: Jason Liu r64...@freescale.com

 Jason Liu

  --- a/drivers/net/wireless/ath/ath6kl/hif.h
  +++ b/drivers/net/wireless/ath/ath6kl/hif.h
  @@ -197,9 +197,9 @@ struct hif_scatter_req {
  /* bounce buffer for upper layers to copy to/from */
  u8 *virt_dma_buf;

  -   struct hif_scatter_item scat_list[1];
  -
  u32 scat_q_depth;
  +
  +   struct hif_scatter_item scat_list[0];
   };

   struct ath6kl_irq_proc_registers {
  diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c
  b/drivers/net/wireless/ath/ath6kl/sdio.c
  index 7126bdd..6bf15a3 100644
  --- a/drivers/net/wireless/ath/ath6kl/sdio.c
  +++ b/drivers/net/wireless/ath/ath6kl/sdio.c
  @@ -348,7 +348,7 @@ static int ath6kl_sdio_alloc_prep_scat_req(struct
  ath6kl_sdio *ar_sdio,
  int i, scat_req_sz, scat_list_sz, size;
  u8 *virt_buf;

  -   scat_list_sz = (n_scat_entry - 1) * sizeof(struct hif_scatter_item);
  +   scat_list_sz = n_scat_entry * sizeof(struct hif_scatter_item);
  scat_req_sz = sizeof(*s_req) + scat_list_sz;

  if (!virt_scat)

  --
  Kalle Valo

What happend with this?
If I look in mainline, I don't find it. At least the reording of the struct
fields looks as if one definitely wants to have that.

Regards,
Steffen

-- 
Pengutronix e.K.

[RESEND] [PATCH] xhci: Switch Intel Lynx Point ports to EHCI on shutdown.

2014-03-07 Thread Denis Turischev

The same issue like with Panther Point chipsets. If the USB ports are
switched to xHCI on shutdown, the xHCI host will send a spurious interrupt,
which will wake the system. Some BIOS have work around for this, but not all.
One example is Compulab's mini-desktop, the Intense-PC2.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.

Signed-off-by: Denis Turischev de...@compulab.co.il
---
 drivers/usb/host/xhci-pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 3c898c1..9233d12 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -134,6 +134,8 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
 */
if (pdev-subsystem_vendor == PCI_VENDOR_ID_HP)
xhci-quirks |= XHCI_SPURIOUS_WAKEUP;
+
+   xhci-quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev-vendor == PCI_VENDOR_ID_ETRON 
pdev-device == PCI_DEVICE_ID_ASROCK_P67) {
-- 1.8.1.2

--
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: Slow I/O performance on SAS1064

2014-03-07 Thread markus

On Thu, Mar 06, 2014 at 12:51:27PM -0800, Mark Knecht wrote:
 On Wed, Mar 5, 2014 at 1:40 PM, markus mar...@kola.li wrote:
  On Wed, Mar 05, 2014 at 10:21:07AM -0800, Mark Knecht wrote:
  On Wed, Mar 5, 2014 at 9:50 AM, Markus mar...@kola.li wrote:
  SNIP
 I am not familiar with this message:
 
 Device supports SMART and is Disabled
 
 but there are lots of posts out there with folks asking about it.
 Possibly you can figure out what's causing smart not to turn on, get
 it turned on and get some info.
right , thats why i writing to the scsi and lsi devs , because die disk 
supports smart and lots of other features, but the controller driver failes to 
enable support for this.

Now i get that the mpt driver provides /dev/sg[0-1] 

root@outpost:~# smartctl -d scsi -x /dev/sg1
smartctl 6.2 2013-07-26 r3841 [sparc64-linux-3.13.5-mar] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

User Capacity:2,000,398,934,016 bytes [2.00 TB]
Logical block size:   512 bytes
Logical Unit id:  0x5394e2380537
Serial number:7365P4KNT
Device type:  disk
Local Time is:Fri Mar  7 09:54:47 2014 CET
SMART support is: Available - device has SMART capability.
SMART support is: Disabled
Temperature Warning:  Disabled or Not Supported
Read Cache is:Enabled
Writeback Cache is:   Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Error Counter logging not supported

Device does not support Self Test logging
Device does not support Background scan results logging
scsiPrintSasPhy Log Sense Failed [unsupported field in scsi command]

so i had read those posts and i tried but it won't work.

root@outpost:~/lsiutil# smartctl -r scsiioctl,3 -s on -d scsi /dev/sg1
smartctl 6.2 2013-07-26 r3841 [sparc64-linux-3.13.5-mar] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

 [inquiry: 12 01 00 01 fc 00 ]
  scsi_status=0x0, host_status=0x0, driver_status=0x0
  info=0x0  duration=0 milliseconds  resid=500
  Incoming data, len=8:
 00 00 00 00 04 00 80 83 89 
 [inquiry: 12 00 00 00 24 00 ]
  scsi_status=0x0, host_status=0x0, driver_status=0x0
  info=0x0  duration=4 milliseconds  resid=0
  Incoming data, len=36:
 00 00 00 05 12 45 00 00 02  41 54 41 20 20 20 20 20
 10 54 4f 53 48 49 42 41 20  4d 51 30 31 41 42 42 32
 20 30 55 20 20 
=== START OF ENABLE/DISABLE COMMANDS SECTION ===
 [mode sense(6): 1a 00 1c 00 40 00 ]
  scsi_status=0x0, host_status=0x0, driver_status=0x0
  info=0x0  duration=4 milliseconds  resid=40
  Incoming data, len=24:
 00 17 00 00 08 00 00 00 00  00 00 02 00 1c 0a 08 06
 10 08 00 00 00 00 00 00 00 
 [mode sense(6): 1a 00 5c 00 40 00 ]
  scsi_status=0x0, host_status=0x0, driver_status=0x0
  info=0x0  duration=0 milliseconds  resid=40
  Incoming data, len=24:
 00 17 00 00 08 00 00 00 00  00 00 02 00 1c 0a 00 00
 10 00 00 00 00 00 00 00 00 
 00 00 00 00 08 00 00 00 00  00 00 02 00 1c 0a 08 06
 10 08 00 00 00 00 00 00 00 
 [mode select(6): 15 10 00 00 18 00 ]
  Outgoing data, len=24:
  scsi_status=0x2, host_status=0x0, driver_status=0x8
  info=0x1  duration=0 milliseconds  resid=24
   Sense buffer, len=18:
 00 70 00 0b 00 00 00 00 0a  00 00 00 00 00 00 00 00
 10 00 00   
  status=2: sense_key=b asc=0 ascq=0
unable to enable Exception control and warning [aborted command]


 
 Sorry I cannot help more.
 
 Good luck,
 Mark


signature.asc
Description: Digital signature

[PATCH v2 5/5] ARM: dts: STiH407: Add B2120 board support

B2120 HDK is the reference board for STiH407 SoC.
It has the following characteristics:
 - 1GB DDR3
 - 8GB eMMC / SD-Card slot
 - 32MB NOR Flash
 - 1 x Gbit Ethernet
 - 1 x USB 3.0 port
 - 1 x Mini-PCIe
 - 1 x SATA
 - 1 x HDMI output
 - 1 x HDMI input
 - 1 x SPDIF

This patch only introduces basic functionnalities, such as I2C and UART.

Signed-off-by: Maxime Coquelin maxime.coque...@st.com
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
---
 arch/arm/boot/dts/Makefile  |  3 +-
 arch/arm/boot/dts/stih407-b2120.dts | 78 +
 2 files changed, 80 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/stih407-b2120.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d109908..c8ad5f5 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -310,7 +310,8 @@ dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb
 dtb-$(CONFIG_ARCH_STI)+= stih415-b2000.dtb \
stih416-b2000.dtb \
stih415-b2020.dtb \
-   stih416-b2020.dtb
+   stih416-b2020.dtb \
+   stih407-b2120.dtb
 dtb-$(CONFIG_ARCH_SUNXI) += \
sun4i-a10-a1000.dtb \
sun4i-a10-cubieboard.dtb \
diff --git a/arch/arm/boot/dts/stih407-b2120.dts 
b/arch/arm/boot/dts/stih407-b2120.dts
new file mode 100644
index 000..9c97da4
--- /dev/null
+++ b/arch/arm/boot/dts/stih407-b2120.dts
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics (RD) Limited.
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ *
+ * 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.
+ */
+/dts-v1/;
+#include stih407.dtsi
+/ {
+   model = STiH407 B2120;
+   compatible = st,stih407, st,stih407-b2120;
+
+   chosen {
+   bootargs = console=ttyAS0,115200;
+   linux,stdout-path = sbc_serial0;
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x4000 0x8000;
+   };
+
+   aliases {
+   ttyAS0 = sbc_serial0;
+   };
+
+   soc {
+   sbc_serial0: serial@953 {
+   status = okay;
+   };
+
+   leds {
+   compatible = gpio-leds;
+   red {
+   #gpio-cells = 2;
+   label = Front Panel LED;
+   gpios = PIO4 1 0;
+   linux,default-trigger = heartbeat;
+   };
+   green {
+   #gpio-cells = 2;
+   gpios = PIO1 3 0;
+   default-state = off;
+   };
+   };
+
+   i2c@9842000 {
+   status = okay;
+   };
+
+   i2c@9843000 {
+   status = okay;
+   };
+
+   i2c@9844000 {
+   status = okay;
+   };
+
+   i2c@9845000 {
+   status = okay;
+   };
+
+   i2c@954 {
+   status = okay;
+   };
+
+   /* SSC11 to HDMI */
+   i2c@9541000 {
+   status = okay;
+   /* HDMI V1.3a supports Standard mode only */
+   clock-frequency = 10;
+   st,i2c-min-scl-pulse-width-us = 0;
+   st,i2c-min-sda-pulse-width-us = 5;
+   };
+   };
+};
-- 
1.9.0

--
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/

[PATCH v2 3/5] pinctrl: st: Enhance the controller to manage unavailable registers

From: Giuseppe Cavallaro peppe.cavall...@st.com

This patch adds a new logic inside the st pinctrl to manage
an unsupported scenario: some sysconfig are not available!

This is the case of STiH407 where, although documented, the
following registers from SYSCFG_FLASH have been removed from the SoC.

SYSTEM_CONFIG3040
   Output Enable pad control for all PIO Alternate Functions
and
SYSTEM_ CONFIG3050
   Pull Up pad control for all PIO Alternate Functions

Without managing this condition an imprecise external abort
will be detect.

To do this the patch also reviews the st_parse_syscfgs
and other routines to manipulate the registers only if
actually available.
In any case, for example the st_parse_syscfgs detected
an error condition but no action was made in the
st_pctl_probe_dt.

Signed-off-by: Maxime Coquelin maxime.coque...@st.com
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
---
 drivers/pinctrl/pinctrl-st.c | 121 +++
 1 file changed, 75 insertions(+), 46 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
index 9e9b6ea..d1886b4 100644
--- a/drivers/pinctrl/pinctrl-st.c
+++ b/drivers/pinctrl/pinctrl-st.c
@@ -390,6 +390,19 @@ static const struct st_pctl_data  stih416_data = {
.alt = 0, .oe = 40, .pu = 50, .od = 60, .rt = 100,
 };
 
+static const struct st_pctl_data  stih407_flashdata = {
+   .rt_style   = st_retime_style_none,
+   .input_delays   = stih416_delays,
+   .ninput_delays  = 14,
+   .output_delays  = stih416_delays,
+   .noutput_delays = 14,
+   .alt = 0,
+   .oe = -1, /* Not Available */
+   .pu = -1, /* Not Available */
+   .od = 60,
+   .rt = 100,
+};
+
 /* Low level functions.. */
 static inline int st_gpio_bank(int gpio)
 {
@@ -410,25 +423,27 @@ static void st_pinconf_set_config(struct st_pio_control 
*pc,
unsigned int oe_value, pu_value, od_value;
unsigned long mask = BIT(pin);
 
-   regmap_field_read(output_enable, oe_value);
-   regmap_field_read(pull_up, pu_value);
-   regmap_field_read(open_drain, od_value);
-
-   /* Clear old values */
-   oe_value = ~mask;
-   pu_value = ~mask;
-   od_value = ~mask;
-
-   if (config  ST_PINCONF_OE)
-   oe_value |= mask;
-   if (config  ST_PINCONF_PU)
-   pu_value |= mask;
-   if (config  ST_PINCONF_OD)
-   od_value |= mask;
-
-   regmap_field_write(output_enable, oe_value);
-   regmap_field_write(pull_up, pu_value);
-   regmap_field_write(open_drain, od_value);
+   if (output_enable) {
+   regmap_field_read(output_enable, oe_value);
+   oe_value = ~mask;
+   if (config  ST_PINCONF_OE)
+   oe_value |= mask;
+   regmap_field_write(output_enable, oe_value);
+   }
+   if (pull_up) {
+   regmap_field_read(pull_up, pu_value);
+   pu_value = ~mask;
+   if (config  ST_PINCONF_PU)
+   pu_value |= mask;
+   regmap_field_write(pull_up, pu_value);
+   }
+   if (open_drain) {
+   regmap_field_read(open_drain, od_value);
+   od_value = ~mask;
+   if (config  ST_PINCONF_OD)
+   od_value |= mask;
+   regmap_field_write(open_drain, od_value);
+   }
 }
 
 static void st_pctl_set_function(struct st_pio_control *pc,
@@ -439,6 +454,9 @@ static void st_pctl_set_function(struct st_pio_control *pc,
int pin = st_gpio_pin(pin_id);
int offset = pin * 4;
 
+   if (!alt)
+   return;
+
regmap_field_read(alt, val);
val = ~(0xf  offset);
val |= function  offset;
@@ -571,22 +589,28 @@ static void st_pinconf_set_retime_dedicated(struct 
st_pinctrl *info,
regmap_field_write(rt_d-rt[pin], retime_config);
 }
 
-static void st_pinconf_get_direction(struct st_pio_control *pc,
-   int pin, unsigned long *config)
+static void st_pinconf_get_direction(struct st_pio_control *pc, int pin,
+unsigned long *config)
 {
unsigned int oe_value, pu_value, od_value;
 
-   regmap_field_read(pc-oe, oe_value);
-   regmap_field_read(pc-pu, pu_value);
-   regmap_field_read(pc-od, od_value);
+   if (pc-oe) {
+   regmap_field_read(pc-oe, oe_value);
+   if (oe_value  BIT(pin))
+   ST_PINCONF_PACK_OE(*config);
+   }
 
-   if (oe_value  BIT(pin))
-   ST_PINCONF_PACK_OE(*config);
-   if (pu_value  BIT(pin))
-   ST_PINCONF_PACK_PU(*config);
-   if (od_value  BIT(pin))
-   ST_PINCONF_PACK_OD(*config);
+   if (pc-pu) {
+   regmap_field_read(pc-pu, pu_value);
+   if (pu_value  BIT(pin))
+   ST_PINCONF_PACK_PU(*config);
+   }
 
+   if (pc-od) {
+

[PATCH v2 2/5] pinctrl: st: add pinctrl support for the STiH407 SoC

From: Giuseppe Cavallaro peppe.cavall...@st.com

This patch adds the initial support for pinctrl based on H407 SoC.

Signed-off-by: Maxime Coquelin maxime.coque...@st.com
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
---
 drivers/pinctrl/pinctrl-st.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
index 9fb66aa..9e9b6ea 100644
--- a/drivers/pinctrl/pinctrl-st.c
+++ b/drivers/pinctrl/pinctrl-st.c
@@ -1580,6 +1580,10 @@ static struct of_device_id st_pctl_of_match[] = {
{ .compatible = st,stih416-rear-pinctrl, .data = stih416_data},
{ .compatible = st,stih416-fvdp-fe-pinctrl, .data = stih416_data},
{ .compatible = st,stih416-fvdp-lite-pinctrl, .data = stih416_data},
+   { .compatible = st,stih407-sbc-pinctrl, .data = stih416_data},
+   { .compatible = st,stih407-front-pinctrl, .data = stih416_data},
+   { .compatible = st,stih407-rear-pinctrl, .data = stih416_data},
+   { .compatible = st,stih407-flash-pinctrl, .data = stih416_data},
{ /* sentinel */ }
 };
 
-- 
1.9.0

--
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/

[PATCH v2 4/5] ARM: dts: Add STiH407 SoC support

The STiH407 is advanced multi-HD AVC processor with 3D graphics acceleration
and 1.5-GHz ARM Cortex-A9 SMP CPU.

Signed-off-by: Maxime Coquelin maxime.coque...@st.com
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
---
 arch/arm/boot/dts/stih407-clock.dtsi   |  41 +++
 arch/arm/boot/dts/stih407-pinctrl.dtsi | 618 +
 arch/arm/boot/dts/stih407.dtsi | 250 +
 3 files changed, 909 insertions(+)
 create mode 100644 arch/arm/boot/dts/stih407-clock.dtsi
 create mode 100644 arch/arm/boot/dts/stih407-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stih407.dtsi

diff --git a/arch/arm/boot/dts/stih407-clock.dtsi 
b/arch/arm/boot/dts/stih407-clock.dtsi
new file mode 100644
index 000..f50ac6f
--- /dev/null
+++ b/arch/arm/boot/dts/stih407-clock.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics RD Limited
+ * stlinux-de...@stlinux.com
+ *
+ * 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.
+ */
+/ {
+   clocks {
+   /*
+* Fixed 30MHz oscillator inputs to SoC
+*/
+   CLK_SYSIN: CLK_SYSIN {
+   #clock-cells = 0;
+   compatible = fixed-clock;
+   clock-frequency = 3000;
+   clock-output-names = CLK_SYSIN;
+   };
+
+   /*
+* ARM Peripheral clock for timers
+*/
+   arm_periph_clk: arm_periph_clk {
+   #clock-cells = 0;
+   compatible = fixed-clock;
+   clock-frequency = 6;
+   };
+
+   /*
+* Bootloader initialized system infrastructure clock for
+* serial devices.
+*/
+   CLK_EXT2F_A9: clockgenC0@13 {
+   #clock-cells = 0;
+   compatible = fixed-clock;
+   clock-frequency = 2;
+   clock-output-names = CLK_S_ICN_REG_0;
+   };
+   };
+};
diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi 
b/arch/arm/boot/dts/stih407-pinctrl.dtsi
new file mode 100644
index 000..2d8543e
--- /dev/null
+++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi
@@ -0,0 +1,618 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited.
+ * Author: Giuseppe Cavallaro peppe.cavall...@st.com
+ *
+ * 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
+ * publishhed by the Free Software Foundation.
+ */
+#include st-pincfg.h
+#include dt-bindings/interrupt-controller/arm-gic.h
+/ {
+
+   aliases {
+   /* 0-5: PIO_SBC */
+   gpio0 = PIO0;
+   gpio1 = PIO1;
+   gpio2 = PIO2;
+   gpio3 = PIO3;
+   gpio4 = PIO4;
+   gpio5 = PIO5;
+   /* 10-19: PIO_FRONT0 */
+   gpio6 = PIO10;
+   gpio7 = PIO11;
+   gpio8 = PIO12;
+   gpio9 = PIO13;
+   gpio10 = PIO14;
+   gpio11 = PIO15;
+   gpio12 = PIO16;
+   gpio13 = PIO17;
+   gpio14 = PIO18;
+   gpio15 = PIO19;
+   /* 20: PIO_FRONT1 */
+   gpio16 = PIO20;
+   /* 30-35: PIO_REAR */
+   gpio17 = PIO30;
+   gpio18 = PIO31;
+   gpio19 = PIO32;
+   gpio20 = PIO33;
+   gpio21 = PIO34;
+   gpio22 = PIO35;
+   /* 40-42: PIO_FLASH */
+   gpio23 = PIO40;
+   gpio24 = PIO41;
+   gpio25 = PIO42;
+   };
+
+   soc {
+   pin-controller-sbc {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = st,stih407-sbc-pinctrl;
+   st,syscfg = syscfg_sbc;
+   reg = 0x0961f080 0x4;
+   reg-names = irqmux;
+   interrupts = GIC_SPI 188 IRQ_TYPE_NONE;
+   interrupts-names = irqmux;
+   ranges = 0 0x0961 0x6000;
+
+   PIO0: gpio@0961 {
+   gpio-controller;
+   #gpio-cells = 1;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   reg = 0x0 0x100;
+   st,bank-name = PIO0;
+   };
+   PIO1: gpio@09611000 {
+   gpio-controller;
+   #gpio-cells = 1;
+   interrupt-controller;
+

RE: [PATCH V1 1/2] mfd: da9063: Upgrade of register definitions to support production silicon

2014-03-07 Thread Opensource [Steve Twiss]



From: Lee Jones [mailto:lee.jo...@linaro.org]
Sent: 07 March 2014 03:32

 From: Opensource [Steve Twiss] stwiss.opensou...@diasemi.com

 This patch updates the register definitions for DA9063 to support the
 production silicon variant code ID (0x5). These changes are not backwards
 compatible with the previous register definitions and can only be used
 with the production variant of DA9063.

 Signed-off-by: Opensource [Steve Twiss] stwiss.opensou...@diasemi.com
 ---
 Checks performed with next-20140306/scripts/checkpatch.pl
  registers.h   total: 0 errors, 0 warnings, 1032 lines checked

 A brief summary of the changes include:

 - Introduction of a new DA9063_REG_ALARM_S register (now appearing at
   addr=0x46) allowing alarm second resolutions and which causes a shift
   in the register map for the RTC registers;
 - Two new configuration registers DA9063_REG_CONFIG_M/N at 0x112  0x113;
 - Modified register ranges for MON_REG_[1-6] which now appears at the
   addr=0x114 onwards;
 - New register addresses for the general purpose registers GP_ID_[0-19]
   (now appearing at 0x121 onwards);
 - Renaming of some definitions to match our hardware design conventions;
 - There are also some bit-pattern additions that define some functionality
   alterations of the registers. One notable addition is:
   DA9063_BUCK_SLOWSTART can also be found in the CONTROL_B register and
   enables a BUCK slow start (reduced inrush current; increased startup
   time);

 This patch applies against kernel version linux-next next-20140306

  include/linux/mfd/da9063/registers.h |  120 
 ++
  1 file changed, 62 insertions(+), 58 deletions(-)

What's the difference between this patch and the one you sent 2 days
ago?


Hi Lee,

There's no difference in the patch for the registers.h.

I resent the whole patch set and renamed it from RFC to PATCH after
making the changes requested by Alessandro in the RTC driver.

Regards,
Steve

[PATCH v2 1/5] ARM: STi: Add STiH407 SoC support

This patch adds support to STiH407 SoC.

Signed-off-by: Maxime Coquelin maxime.coque...@st.com
Signed-off-by: Giuseppe Cavallaro peppe.cavall...@st.com
---
 Documentation/arm/sti/stih407-overview.txt| 18 ++
 Documentation/devicetree/bindings/arm/sti.txt | 15 +++
 arch/arm/mach-sti/Kconfig |  9 +
 arch/arm/mach-sti/board-dt.c  |  1 +
 4 files changed, 43 insertions(+)
 create mode 100644 Documentation/arm/sti/stih407-overview.txt
 create mode 100644 Documentation/devicetree/bindings/arm/sti.txt

diff --git a/Documentation/arm/sti/stih407-overview.txt 
b/Documentation/arm/sti/stih407-overview.txt
new file mode 100644
index 000..3343f32
--- /dev/null
+++ b/Documentation/arm/sti/stih407-overview.txt
@@ -0,0 +1,18 @@
+   STiH407 Overview
+   
+
+Introduction
+
+
+The STiH407 is the new generation of SoC for Multi-HD, AVC set-top boxes
+and server/connected client application for satellite, cable, terrestrial
+and IP-STB markets.
+
+Features
+- ARM Cortex-A9 1.5 GHz dual core CPU (28nm)
+- SATA2, USB 3.0, PCIe, Gbit Ethernet
+
+  Document Author
+  ---
+
+  Maxime Coquelin maxime.coque...@st.com, (c) 2014 ST Microelectronics
diff --git a/Documentation/devicetree/bindings/arm/sti.txt 
b/Documentation/devicetree/bindings/arm/sti.txt
new file mode 100644
index 000..92f16c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/sti.txt
@@ -0,0 +1,15 @@
+ST STi Platforms Device Tree Bindings
+---
+
+Boards with the ST STiH415 SoC shall have the following properties:
+Required root node property:
+compatible = st,stih415;
+
+Boards with the ST STiH416 SoC shall have the following properties:
+Required root node property:
+compatible = st,stih416;
+
+Boards with the ST STiH407 SoC shall have the following properties:
+Required root node property:
+compatible = st,stih407;
+
diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index d2c13ba..c0a3f53 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -39,4 +39,13 @@ config SOC_STIH416
  and other digital audio/video applications using Flattened Device
  Trees.
 
+config SOC_STIH407
+   bool STiH407 STMicroelectronics Consumer Electronics family
+   default y
+   help
+ This enables support for STMicroelectronics Digital Consumer
+ Electronics family StiH407 parts, primarily targeted at set-top-box
+ and other digital audio/video applications using Flattened Device
+ Trees.
+
 endif
diff --git a/arch/arm/mach-sti/board-dt.c b/arch/arm/mach-sti/board-dt.c
index 1217fb5..df731f2 100644
--- a/arch/arm/mach-sti/board-dt.c
+++ b/arch/arm/mach-sti/board-dt.c
@@ -36,6 +36,7 @@ static void __init stih41x_machine_init(void)
 static const char *stih41x_dt_match[] __initdata = {
st,stih415,
st,stih416,
+   st,stih407,
NULL
 };
 
-- 
1.9.0

--
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/

[PATCH v2 0/5] Add STiH407 SoC and reference board support

This series adds basic support to the STMicroelectronics STiH407 SoC and its
B2120 reference board. The STiH407 is a dual-core ARM Cortex-A9 CPU aimed at
STB market.

Changes since v1:
-
- Changed patch 2 commit title
- Rebased pinctrl patches to linux-pinctrl/devel
- Rebased ARM patches to arm_soc/for-next

Giuseppe Cavallaro (2):
  pinctrl: st: add pinctrl support for the STiH407 SoC
  pinctrl: st: Enhance the controller to manage unavailable registers

Maxime Coquelin (3):
  ARM: STi: Add STiH407 SoC support
  ARM: dts: Add STiH407 SoC support
  ARM: dts: STiH407: Add B2120 board support

 Documentation/arm/sti/stih407-overview.txt|  18 +
 Documentation/devicetree/bindings/arm/sti.txt |  15 +
 arch/arm/boot/dts/Makefile|   3 +-
 arch/arm/boot/dts/stih407-b2120.dts   |  78 
 arch/arm/boot/dts/stih407-clock.dtsi  |  41 ++
 arch/arm/boot/dts/stih407-pinctrl.dtsi| 618 ++
 arch/arm/boot/dts/stih407.dtsi| 250 +++
 arch/arm/mach-sti/Kconfig |   9 +
 arch/arm/mach-sti/board-dt.c  |   1 +
 drivers/pinctrl/pinctrl-st.c  | 123 +++--
 10 files changed, 1110 insertions(+), 46 deletions(-)
 create mode 100644 Documentation/arm/sti/stih407-overview.txt
 create mode 100644 Documentation/devicetree/bindings/arm/sti.txt
 create mode 100644 arch/arm/boot/dts/stih407-b2120.dts
 create mode 100644 arch/arm/boot/dts/stih407-clock.dtsi
 create mode 100644 arch/arm/boot/dts/stih407-pinctrl.dtsi
 create mode 100644 arch/arm/boot/dts/stih407.dtsi

-- 
1.9.0

--
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/

[no subject]

2014-03-07 Thread Vineet Gupta

Hi Linus,

This patch fixes a subtle issue with cache flush which could potentially
cause random userspace crashes because of stale icache lines.

Please apply for 3.14, it's marked for stable as well.

Thx,
-Vineet

--8
From 036837642ed6df39f6a063ad10327787b60d4a0f Mon Sep 17 00:00:00 2001
From: Vineet Gupta vgu...@synopsys.com
Date: Fri, 7 Mar 2014 13:22:22 +0530
Subject: [PATCH] ARC: Use correct PTAG register for icache flush

This error crept in when consolidating the cache flush code

Fixes: bd12976c3664 (ARC: cacheflush refactor #3: Unify the {d,i}cache)
Signed-off-by: Vineet Gupta vgu...@synopsys.com
Cc: linux-kernel@vger.kernel.org
Cc: sta...@vger.kernel.org  # 3.13
Cc: arc-linux-...@synopsys.com
---
 arch/arc/mm/cache_arc700.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/mm/cache_arc700.c b/arch/arc/mm/cache_arc700.c
index 6b58c1de7577..400c663b21c2 100644
--- a/arch/arc/mm/cache_arc700.c
+++ b/arch/arc/mm/cache_arc700.c
@@ -282,7 +282,7 @@ static inline void __cache_line_loop(unsigned long paddr, 
unsigned long vaddr,
 #else
/* if V-P const for loop, PTAG can be written once outside loop */
if (full_page_op)
-   write_aux_reg(ARC_REG_DC_PTAG, paddr);
+   write_aux_reg(aux_tag, paddr);
 #endif
 
while (num_lines--  0) {
@@ -296,7 +296,7 @@ static inline void __cache_line_loop(unsigned long paddr, 
unsigned long vaddr,
write_aux_reg(aux_cmd, vaddr);
vaddr += L1_CACHE_BYTES;
 #else
-   write_aux_reg(aux, paddr);
+   write_aux_reg(aux_cmd, paddr);
paddr += L1_CACHE_BYTES;
 #endif
}
-- 
1.8.3.2

--
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 1/4] HID: cp2112: remove various hid_out_raw_report calls

Hi

On Wed, Mar 5, 2014 at 10:18 PM, Benjamin Tissoires
benjamin.tissoi...@redhat.com wrote:
 hid_out_raw_report is going to be obsoleted as it is not part of the
 unified HID low level transport documentation
 (Documentation/hid/hid-transport.txt)

   hid_output_raw_report(hdev, buf, sizeof(buf), HID_FEATURE_REPORT);
 is strictly equivalent to:
   hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf),
 HID_FEATURE_REPORT, HID_REQ_SET_REPORT);

This time you might be right that feature-reports always put the
report-id into the first byte, but I'd still prefer if we avoid using
this. Besides, the code is much nicer imho if we pass the ID directly,
see below..


 So use the new api.

 Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
 ---

 no changes since v1

  drivers/hid/hid-cp2112.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

 diff --git a/drivers/hid/hid-cp2112.c b/drivers/hid/hid-cp2112.c
 index 1025982..860db694 100644
 --- a/drivers/hid/hid-cp2112.c
 +++ b/drivers/hid/hid-cp2112.c
 @@ -185,8 +185,8 @@ static int cp2112_gpio_direction_input(struct gpio_chip 
 *chip, unsigned offset)
 buf[1] = ~(1  offset);
 buf[2] = gpio_push_pull;

 -   ret = hdev-hid_output_raw_report(hdev, buf, sizeof(buf),
 - HID_FEATURE_REPORT);
 +   ret = hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf),
 +HID_FEATURE_REPORT, HID_REQ_SET_REPORT);

buf[0] = CP2112_GPIO_CONFIG

 if (ret  0) {
 hid_err(hdev, error setting GPIO config: %d\n, ret);
 return ret;
 @@ -207,8 +207,8 @@ static void cp2112_gpio_set(struct gpio_chip *chip, 
 unsigned offset, int value)
 buf[1] = value ? 0xff : 0;
 buf[2] = 1  offset;

 -   ret = hdev-hid_output_raw_report(hdev, buf, sizeof(buf),
 - HID_FEATURE_REPORT);
 +   ret = hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf),
 +HID_FEATURE_REPORT, HID_REQ_SET_REPORT);

Here buf[0] seems fine as it is set explicitly just 3 lines above to
CP2112_GPIO_SET.

 if (ret  0)
 hid_err(hdev, error setting GPIO values: %d\n, ret);
  }
 @@ -253,8 +253,8 @@ static int cp2112_gpio_direction_output(struct gpio_chip 
 *chip,
 buf[1] |= 1  offset;
 buf[2] = gpio_push_pull;

 -   ret = hdev-hid_output_raw_report(hdev, buf, sizeof(buf),
 - HID_FEATURE_REPORT);
 +   ret = hid_hw_raw_request(hdev, buf[0], buf, sizeof(buf),
 +HID_FEATURE_REPORT, HID_REQ_SET_REPORT);

Here an explicit CP2112_GPIO_CONFIG seems nicer, imho.

Thanks
David

 if (ret  0) {
 hid_err(hdev, error setting GPIO config: %d\n, ret);
 return ret;
 --
 1.8.5.3

--
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: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing

2014-03-07 Thread Paul Bolle

Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
 I wouldn't start bisecting yet, but if you're in the mood, this
 commit: 96702be56037 Merge branch 'pci/resource' into next looks
 like a good place to start, so you could try the pre-merge commit:
 04f982beb900 Merge branch 'pci/msi' into next.  If 04f982beb900 is
 good, there are only about 15 commits on the pci/resource branch to
 look at.

This might end up not being relevant. And this is surely documented
somewhere, but anyhow:
- what git magic returns the hashes of the 15 commits that merge commit
  96702be56037 added to the tree; and
- how can I use the list of those hashes to limit the range of commits
  to do a git bisect?


Paul Bolle

--
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 RT] cpu_chill: Add a UNINTERRUPTIBLE hrtimer_nanosleep

2014-03-07 Thread Sebastian Andrzej Siewior

On 03/04/2014 06:28 PM, Steven Rostedt wrote:
 We hit another bug that was caused by switching cpu_chill() from
 msleep() to hrtimer_nanosleep().

Applied with a stable tag.

Sebastian

--
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: Linux does not use more than the startup RAM under Hyper-V with dynamic memory enabled RE: [PATCH 2/2] Drivers: hv: balloon: Online the hot-added memory in context Re: [PATCH 1/1] Drivers: hv:

2014-03-07 Thread Victor Miasnikov


Hi!

VVM
VVM  Question to Linux kernel team: may be patch
VVM  [PATCH 2/2] Drivers: hv: balloon: Online the hot-added memory in 
context
VVM can solve problems with dynamic memory hot add in Hyper-V VMs with 
Linux OS ?
VVM
K.Y.S
K.Y.S  I will try to get my in-context onlining patches accepted upstream.
K.Y.S

VVM
VVM Thanks! Feature dynamic memory hot add in Hyper-V VMs with Linux OS  -- 
is very usefull for Hyper-V sysadmins
VVM Stable work for this feature -- must be hi-priority task for developers
VVM
 +
B.W.
B.W. So can I expect to see this patched by the next kernel version?
B.W.


J.L.
J.L. I would hold your breath on this one.
J.L.


J.L.
J.L. The maintainers of the memory subsystem has rejected the patch exposing 
certain functions
J.L.

 When?

Please resend to me message from maintainer with reject

(
 I again search in my archive of messages from this mail list, and not found 
message[s],
about Brian Wong write
)

J.L.
J.L. so hv_balloon can online the newly added memory to the system.
J.L. They think that having udev to handle such events is a better place.
J.L.

 Look like You read Bug 979257 . . .


J.L. And in case if somebody hasn't posted it here, this is the udev rule that 
KY has given to me in the past:
==
SUBSYSTEM==memory, ACTION==add, RUN+=/bin/sh -c '[ -f /sys$devpath/state ]  echo 
online  /sys$devpath/state'
==

 Add to Youre collection of udev rules:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/21519c00-47d4-44a4-b2d3-64cd3098849e/rhel-70-centos-70-rhel-65-centos-65-rhel-64-centos-64-include-support-for-hyperv?forum=linuxintegrationservices
==
Michael Kelley:
The VM crash   . . . ( VVM: some details skipped by me ) should be fixed by 
adding the udev rule. The udev rule looks
like:
SUBSYSTEM==memory, ACTION==add, DEVPATH==/devices/system/memory/memory*[0-9], 
TEST==/sys$devpath/state,
RUN+=/bin/sh -c 'echo online  /sys$devpath/state'


Nikolay Pushkarev:
Following rule works slightly faster for me (assuming that memory0 bank always 
in online state):

SUBSYSTEM==memory, ACTION==add, DEVPATH==/devices/system/memory/memory[1-9]*, 
RUN+=/bin/cp
/sys$devpath/../memory0/state /sys$devpath/state
==


And another topic in russian:
http://social.technet.microsoft.com/Forums/ru-RU/addd8d0a-fe38-4679-b0be-c355e12b5b32/centos-65-?forum=virtualizationru
( But You can use Google translate service or vice versa )



Best regards, Victor Miasnikov
Blog:  http://vvm.blog.tut.by/


- Original Message - 
From: Jeff Leung

To: Brian Wong; Victor Miasnikov ; KY Srinivasan ( zz (at) 
microsoft.com ); linux-kernel@vger.kernel.org
Cc: Abhishek Gupta (LIS) ( z (at) microsoft.com)
Sent: Thursday, March 06, 2014 9:25 PM
Subject: RE: Linux does not use more than the startup RAM under Hyper-V with 
dynamic memory enabled RE: [PATCH 2/2]
Drivers: hv: balloon: Online the hot-added memory in context Re: [PATCH 1/1] 
Drivers: hv:


B.W. So can I expect to see this patched by the next kernel version?

I would hold your breath on this one.
The maintainers of the memory subsystem has rejected the patch exposing certain 
functions
so hv_balloon can online the newly added memory to the system.
They think that having udev to handle such events is a better place.

And in case if somebody hasn't posted it here, this is the udev rule that KY 
has given to me in the past:

SUBSYSTEM==memory, ACTION==add, RUN+=/bin/sh -c '[ -f
/sys$devpath/state ]  echo online  /sys$devpath/state'


--





- Original Message - 
From: Brian Wong

To: Victor Miasnikov; KY Srinivasan ( zz (at) microsoft.com ); 
linux-kernel@vger.kernel.org
Cc: Abhishek Gupta (LIS)  ( z (at) microsoft.com)
Sent: Thursday, March 06, 2014 9:11 PM
Subject: Re: Linux does not use more than the startup RAM under Hyper-V with 
dynamic memory enabled RE: [PATCH 2/2]
Drivers: hv: balloon: Online the hot-added memory in context Re: [PATCH 1/1] 
Drivers: hv:


 . . .

VVM
VVM  Question to Linux kernel team: may be patch
VVM  [PATCH 2/2] Drivers: hv: balloon: Online the hot-added memory in 
context
VVM can solve problems with dynamic memory hot add in Hyper-V VMs with Linux 
OS ?
VVM
K.Y.S
K.Y.S  I will try to get my in-context onlining patches accepted upstream.
K.Y.S
VVM
VVM Thanks!
VVM
VVM Feature dynamic memory hot add in Hyper-V VMs with Linux OS  -- is very 
usefull for Hyper-V sysadmins
VVM Stable work for this feature -- must be hi-priority task for developers
VVM


So can I expect to see this patched by the next kernel version?

--
Brian Wong
http://www.fierydragonlord.com
--





- Original Message - 
From: KY Srinivasan

To: Victor Miasnikov; linux-kernel@vger.kernel.org; Brian Wong
Cc: Abhishek Gupta (LIS)
Sent: Thursday, March 06, 2014 1:23 PM
Subject: RE: Linux does not use more than the startup RAM under Hyper-V with 
dynamic memory enabled RE: [PATCH 2/2]
Drivers: hv: balloon: Online the hot-added memory in context Re: [PATCH 1/1] 
Drivers: hv:


Victor,

I will try to get my

RE: [PATCH V1 2/2] rtc: da9063: RTC driver

2014-03-07 Thread Opensource [Steve Twiss]


From: Alessandro Zummo [mailto:a.zu...@towertech.it]
Sent: 07 March 2014 09:33

On Thu, 6 Mar 2014 16:40:02 +
Opensource [Steve Twiss] stwiss.opensou...@diasemi.com wrote:

 Change History:

 Changes made to this driver since previous RFC V1
 Comments by Alessandro Zummo
 - http://www.kernelhub.org/?p=2msg=426327
 - Use return PTR_ERR(rtc-rtc_dev); instead of goto err; return err.
 - Request the interrupt before the RTC device is registered with the
   call to devm_rtc_device_register.


 Acked-by: Alessandro Zummo a.zu...@towertech.it


Thank you.
Regards,
Steve
--
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] zram: propagate error to user

2014-03-07 Thread Minchan Kim

Hello Sergey!

On Fri, Mar 07, 2014 at 12:20:45PM +0300, Sergey Senozhatsky wrote:
 On (03/07/14 10:56), Minchan Kim wrote:
  When we initialized zcomp with single, we couldn't change
  max_comp_streams without zram reset but current interface doesn't
  show any error to user and even it changes max_comp_streams's value
  without any effect so it would make user very confusing.
  
  This patch prevents max_comp_streams's change when zcomp was
  initialized as single zcomp and emit the error to user(ex, echo).
  
  Signed-off-by: Minchan Kim minc...@kernel.org
  ---
   Documentation/blockdev/zram.txt |  9 +
   drivers/block/zram/zcomp.c  | 10 +-
   drivers/block/zram/zcomp.h  |  4 ++--
   drivers/block/zram/zram_drv.c   | 15 +++
   4 files changed, 23 insertions(+), 15 deletions(-)
  
  diff --git a/Documentation/blockdev/zram.txt 
  b/Documentation/blockdev/zram.txt
  index 2604ffed51db..0595c3f56ccf 100644
  --- a/Documentation/blockdev/zram.txt
  +++ b/Documentation/blockdev/zram.txt
  @@ -37,10 +37,11 @@ Note:
   In order to enable compression backend's multi stream support 
  max_comp_streams
   must be initially set to desired concurrency level before ZRAM device
   initialisation. Once the device initialised as a single stream compression
  -backend (max_comp_streams equals to 0) changing the value of 
  max_comp_streams
  -will not take any effect, because single stream compression backend 
  implemented
  -as a special case and does not support dynamic max_comp_streams. Only multi
  -stream backend supports dynamic max_comp_streams adjustment.
  +backend (max_comp_streams equals to 1), you will see error if you try to 
  change
  +the value of max_comp_streams because single stream compression backend
  +implemented as a special case by lock overhead issue and does not support
  +dynamic max_comp_streams. Only multi stream backend supports dynamic
  +max_comp_streams adjustment.
   
   3) Select compression algorithm
  Using comp_algorithm device attribute one can see available and
  diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
  index 92a83df40a27..15fe6a27781b 100644
  --- a/drivers/block/zram/zcomp.c
  +++ b/drivers/block/zram/zcomp.c
  @@ -152,7 +152,7 @@ static void zcomp_strm_multi_release(struct zcomp 
  *comp, struct zcomp_strm *zstr
   }
   
   /* change max_strm limit */
  -static int zcomp_strm_multi_set_max_streams(struct zcomp *comp, int 
  num_strm)
  +static bool zcomp_strm_multi_set_max_streams(struct zcomp *comp, int 
  num_strm)
   {
  struct zcomp_strm_multi *zs = comp-stream;
  struct zcomp_strm *zstrm;
  @@ -171,7 +171,7 @@ static int zcomp_strm_multi_set_max_streams(struct 
  zcomp *comp, int num_strm)
  zs-avail_strm--;
  }
  spin_unlock(zs-strm_lock);
  -   return 0;
  +   return true;
   }
   
   static void zcomp_strm_multi_destroy(struct zcomp *comp)
  @@ -231,10 +231,10 @@ static void zcomp_strm_single_release(struct zcomp 
  *comp,
  mutex_unlock(zs-strm_lock);
   }
   
  -static int zcomp_strm_single_set_max_streams(struct zcomp *comp, int 
  num_strm)
  +static bool zcomp_strm_single_set_max_streams(struct zcomp *comp, int 
  num_strm)
   {
  /* zcomp_strm_single support only max_comp_streams == 1 */
  -   return -ENOTSUPP;
  +   return 0;
   }
 
 IMHO, -ENOTSUPP for unsupported operation fits better than `false'.
 yes, currently there are only two possible returns:
   0 -- success
   -ENOTSUPP - not supported operation
 
 though, we can extend functions later and return additional codes, other
 than `false' and `true'.

Thing to expose to user isn't true and false but EINVAL.

 
 for example, -E2BIG if user requested extremly large number of streams,
 like 5000 streams.

I'm not sure it's right example for E2BIG.
When I read the comment, it says argument list too long.
Anyway, when I tried ENOTSUPP, echo doesn't show meaningful error to user
and I dont' know it's casual err number for userspace.
Pz, comment about that.

 
   
   static void zcomp_strm_single_destroy(struct zcomp *comp)
  @@ -283,7 +283,7 @@ ssize_t zcomp_available_show(const char *comp, char 
  *buf)
  return sz;
   }
   
  -int zcomp_set_max_streams(struct zcomp *comp, int num_strm)
  +bool zcomp_set_max_streams(struct zcomp *comp, int num_strm)
   {
  return comp-set_max_streams(comp, num_strm);
   }
  diff --git a/drivers/block/zram/zcomp.h b/drivers/block/zram/zcomp.h
  index 8b8997f8613b..c59d1fca72c0 100644
  --- a/drivers/block/zram/zcomp.h
  +++ b/drivers/block/zram/zcomp.h
  @@ -46,7 +46,7 @@ struct zcomp {
   
  struct zcomp_strm *(*strm_find)(struct zcomp *comp);
  void (*strm_release)(struct zcomp *comp, struct zcomp_strm *zstrm);
  -   int (*set_max_streams)(struct zcomp *comp, int num_strm);
  +   bool (*set_max_streams)(struct zcomp *comp, int num_strm);
  void (*destroy)(struct zcomp *comp);
   };
   
  @@ -64,5 +64,5 @@ int zcomp_compress(struct zcomp

Re: [PATCH v3 1/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Russell King - ARM Linux

On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote:
 The Allwinner A31 SoC using that IP has a reset controller maintaining
 it reset unless told otherwise.
 
 Add some optional reset support to the driver.
 
 Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
 Reviewed-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 Tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com

This appears to be causing some build errors in Olof's next builder
for many of the ARM platforms which make use of this:

drivers/i2c/busses/i2c-mv64xxx.c:924: undefined reference to 
`reset_control_assert'
drivers/i2c/busses/i2c-mv64xxx.c:904: undefined reference to 
`reset_control_assert'
drivers/i2c/busses/i2c-mv64xxx.c:771: undefined reference to 
`devm_reset_control_get'
drivers/i2c/busses/i2c-mv64xxx.c:778: undefined reference to 
`reset_control_deassert'

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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 0/4] HID: ll transport cleanup: final round

Hi

On Wed, Mar 5, 2014 at 10:18 PM, Benjamin Tissoires
benjamin.tissoi...@redhat.com wrote:
 Alright, this is the re-spin of the last round of transport cleanup.

 Some minor but important modifications are here, but nothing very 
 enthousiastic.

 Thanks for the reviews and the tests so far.

Apart from some minor comments on #1 and #2, this is:

Reviewed-by: David Herrmann dh.herrm...@gmail.com

Thanks
David

 Cheers,
 Benjamin

 Benjamin Tissoires (4):
   HID: cp2112: remove various hid_out_raw_report calls
   HID: cp2112: remove the last hid_output_raw_report() call
   HID: sony: do not rely on hid_output_raw_report
   HID: remove hid_output_raw_report transport implementations

  drivers/hid/hid-cp2112.c  | 19 +-
  drivers/hid/hid-sony.c| 60 
 ++-
  drivers/hid/hidraw.c  |  3 ++-
  drivers/hid/i2c-hid/i2c-hid.c | 14 --
  drivers/hid/uhid.c|  1 -
  drivers/hid/usbhid/hid-core.c | 19 +-
  include/linux/hid.h   | 21 ++-
  net/bluetooth/hidp/core.c | 14 --
  8 files changed, 36 insertions(+), 115 deletions(-)

 --
 1.8.5.3
--
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 RT 3/6] rt: Make cpu_chill() use hrtimer instead of msleep()

2014-03-07 Thread Sebastian Andrzej Siewior

On 03/05/2014 01:33 AM, Steven Rostedt wrote:
 3.2.55-rt79-rc1 stable review patch.
 If anyone has any objections, please let me know.

Now that you posted cpu_chill: Add a UNINTERRUPTIBLE
hrtimer_nanosleep wouldn't it make sense to delay this patches from
the stable series until we get them all in one go?

Sebastian

--
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: mvebu: add Device Tree for the Armada 385 RD board

2014-03-07 Thread Gregory CLEMENT

On 06/03/2014 20:17, Ezequiel Garcia wrote:
 On Mar 06, Andrew Lunn wrote:
 Can't we fix this so the probe order doesn't affect the name?

 Is that sane?

 You are not supposed to trust the device name, since probing can
 happen in parallel, on different buses. udev should have rules to name
 the interfaces based on the MAC address. On my Debian system i have:

 /etc/udev/rules.d/70-persistent-net.rules

 So what is important is that the MAC addresses are assigned correctly
 to the device. And DT does that based on MMIO address, so should be
 reliable, independent of probe order.


I was aware of this solution, and indeed for the end user it is the thing
to do.

However my concern was more about the people testing the kernel early or for
people bringing up a new board. I fear that we will have many false bug report
about it.

For the second category, I think we should at least point this in the dtsi.


Thanks,

Gregory


 
 Right, makes perfect sense!
 
 So we can just keep the nodes address-ordered, without caring about the name?
 




-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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] xtensa: enable sorting extable at build time

2014-03-07 Thread Max Filippov

On Tue, Feb 18, 2014 at 3:48 PM, Max Filippov jcmvb...@gmail.com wrote:
 Signed-off-by: Max Filippov jcmvb...@gmail.com
 ---
  arch/xtensa/Kconfig   | 1 +
  scripts/sortextable.c | 5 +
  2 files changed, 6 insertions(+)

Ping?
David, is this OK for scripts/sortextable.c?

 diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
 index 1ccaf91..381370d 100644
 --- a/arch/xtensa/Kconfig
 +++ b/arch/xtensa/Kconfig
 @@ -14,6 +14,7 @@ config XTENSA
 select GENERIC_PCI_IOMAP
 select ARCH_WANT_IPC_PARSE_VERSION
 select ARCH_WANT_OPTIONAL_GPIOLIB
 +   select BUILDTIME_EXTABLE_SORT
 select CLONE_BACKWARDS
 select IRQ_DOMAIN
 select HAVE_OPROFILE
 diff --git a/scripts/sortextable.c b/scripts/sortextable.c
 index cc49062..1052d48 100644
 --- a/scripts/sortextable.c
 +++ b/scripts/sortextable.c
 @@ -35,6 +35,10 @@
  #define EM_ARCOMPACT   93
  #endif

 +#ifndef EM_XTENSA
 +#define EM_XTENSA  94
 +#endif
 +
  #ifndef EM_AARCH64
  #define EM_AARCH64 183
  #endif
 @@ -281,6 +285,7 @@ do_file(char const *const fname)
 case EM_AARCH64:
 case EM_MICROBLAZE:
 case EM_MIPS:
 +   case EM_XTENSA:
 break;
 }  /* end switch */

 --
 1.8.1.4

-- 
Thanks.
-- Max
--
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: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

2014-03-07 Thread Stefani Seibold

Hi Fengguang,

did you test the config i had sent to you?

My test was all done with current 3.14-rc tree. And with this i have no
problem. 

I just cloned the tip tree and i figured out that the patch was dropped
again (BTW: git log does not show that it was ever applied).

Okay, that's enough for me. If it nearly impossible to cut this gordian
knot without support and test from the intel kernel developer group.

The origin code was not in the best shape too. I cannot understand why
this was going into mainline without 32 bit support.

So i tried my best, but without support it is impossible to find all
issues. But mostly what i get was bureaucracy afflictions

I complied, but now it is time to help finding the issues. And not only
do a complain, sit back and wait.

If i haed a  8192 core i7 XEON machine i would be able to test all
mutations of kernels. But i have not (despite i cannot pay the invoice).

Also i get no support by people who ask me to do this work. I am really
pissed of.

- Stefani

Am Freitag, den 07.03.2014, 17:15 +0800 schrieb Fengguang Wu:

 Hi Stefani,
 
 On Fri, Mar 07, 2014 at 09:47:14AM +0100, Stefani Seibold wrote:
  Hi Fengguang,
  
  i was now able to bring up the kernel on my KVM with some minior
  changes. I kick out the PARIDE, switched to IDE and activated the VT
  support. With this modifications the kernel boot and i get no BUG,
  everything is fine!
  
  So i can not reproduce the bug and i want ask you to check the attached
  kernel config. If this also works for you the problem is maybe located
  in the environment, f.e. gcc.
 
 I'm using gcc 4.8.1, as you can see from the 2nd line of the below dmesg.
 I can reproduce it reliably - see the screen dump below. You can find
 the reproduce script at the end of this email.
 
 wfg@bee 
 /kernel/i386-randconfig-nh0-03070222/d478a960edf1ea61ca31a07a48a8771f043dba78%
  kvm-0day.sh vmlinuz-3.14.0-rc5-03765-gd478a96
 early console in setup code
 [0.00] Linux version 3.14.0-rc5-03765-gd478a96 (kbuild@nhm4) (gcc 
 version 4.8.1 (Debian 4.8.1-8) ) #2 SMP PREEMPT Fri Mar 7 03:16:44 CST 2014
 [0.00] e820: BIOS-provided physical RAM map:
 [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
 [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
 [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
 [0.00] BIOS-e820: [mem 0x0010-0x0fffdfff] usable
 [0.00] BIOS-e820: [mem 0x0fffe000-0x0fff] reserved
 [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
 [0.00] BIOS-e820: [mem 0xfffc-0x] reserved
 [0.00] debug: ignoring loglevel setting.
 [0.00] NX (Execute Disable) protection: active
 [0.00] Hypervisor detected: KVM
 [0.00] e820: update [mem 0x-0x0fff] usable == reserved
 [0.00] e820: remove [mem 0x000a-0x000f] usable
 [0.00] e820: last_pfn = 0xfffe max_arch_pfn = 0x100
 [0.00] MTRR default type: write-back
 [0.00] MTRR fixed ranges enabled:
 [0.00]   0-9 write-back
 [0.00]   A-B uncachable
 [0.00]   C-F write-protect
 [0.00] MTRR variable ranges enabled:
 [0.00]   0 base 008000 mask FF8000 uncachable
 [0.00]   1 disabled
 [0.00]   2 disabled
 [0.00]   3 disabled
 [0.00]   4 disabled
 [0.00]   5 disabled
 [0.00]   6 disabled
 [0.00]   7 disabled
 [0.00] initial memory mapped: [mem 0x-0x023f]
 [0.00] Base memory trampoline at [c009b000] 9b000 size 16384
 [0.00] init_memory_mapping: [mem 0x-0x000f]
 [0.00]  [mem 0x-0x000f] page 4k
 [0.00] init_memory_mapping: [mem 0x0fa0-0x0fbf]
 [0.00]  [mem 0x0fa0-0x0fbf] page 4k
 [0.00] BRK [0x01e02000, 0x01e02fff] PGTABLE
 [0.00] init_memory_mapping: [mem 0x0c00-0x0f9f]
 [0.00]  [mem 0x0c00-0x0f9f] page 4k
 [0.00] BRK [0x01e03000, 0x01e03fff] PGTABLE
 [0.00] BRK [0x01e04000, 0x01e04fff] PGTABLE
 [0.00] BRK [0x01e05000, 0x01e05fff] PGTABLE
 [0.00] BRK [0x01e06000, 0x01e06fff] PGTABLE
 [0.00] BRK [0x01e07000, 0x01e07fff] PGTABLE
 [0.00] init_memory_mapping: [mem 0x0010-0x0bff]
 [0.00]  [mem 0x0010-0x0bff] page 4k
 [0.00] init_memory_mapping: [mem 0x0fc0-0x0fffdfff]
 [0.00]  [mem 0x0fc0-0x0fffdfff] page 4k
 [0.00] RAMDISK: [mem 0x0fce6000-0x0ffe]
 [0.00] ACPI: RSDP 0x000F16B0 14 (v00 BOCHS )
 [0.00] ACPI: RSDT 0x0FFFE3F0 34 (v01 BOCHS  BXPCRSDT 0001 
 BXPC 0001)
 [0.00] ACPI: FACP 0x0F80 74 (v01 BOCHS  BXPCFACP 0001 
 BXPC 0001)
 [0.00] ACPI: DSDT 0x0FFFE430 001137 (v01 BXPC   BXDSDT

Re: [PATCH 0/3] gfs: More logging neatening

2014-03-07 Thread Steven Whitehouse

Hi,

On Thu, 2014-03-06 at 12:10 -0800, Joe Perches wrote:
 Joe Perches (3):
   gfs2: Use pr_level more consistently
   gfs2: Use fs_level more often
   gfs2: Convert gfs2_lm_withdraw to use fs_err
 
  fs/gfs2/dir.c| 14 
  fs/gfs2/glock.c  |  8 +++--
  fs/gfs2/lock_dlm.c   |  9 +++--
  fs/gfs2/main.c   |  2 ++
  fs/gfs2/ops_fstype.c | 25 ++---
  fs/gfs2/quota.c  | 10 +++---
  fs/gfs2/rgrp.c   | 24 +++--
  fs/gfs2/super.c  | 16 -
  fs/gfs2/sys.c|  6 ++--
  fs/gfs2/trans.c  | 19 +-
  fs/gfs2/util.c   | 99 
 +---
  fs/gfs2/util.h   | 31 
  12 files changed, 138 insertions(+), 125 deletions(-)
 

Thanks for the patches. I've added them to the -nmw tree, and I did spot
the V2 patch of the third one,

Steve.


--
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/

[PATCH] MAINTAINERS: add xtensa irqchips to xtensa port entry

2014-03-07 Thread Max Filippov

Now that irqchip drivers for xtensa live outside arch/xtensa we'd like
to add them to our maintenance list.

Signed-off-by: Max Filippov jcmvb...@gmail.com
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c6d0e93..a30b047 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8690,6 +8690,7 @@ M:Max Filippov jcmvb...@gmail.com
 L: linux-xte...@linux-xtensa.org
 S: Maintained
 F: arch/xtensa/
+F: drivers/irqchip/irq-xtensa-*
 
 THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
 M: Hans Verkuil hverk...@xs4all.nl
-- 
1.8.1.4

--
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/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Maxime Ripard

Hi Russell,

On Fri, Mar 07, 2014 at 09:52:23AM +, Russell King - ARM Linux wrote:
 On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote:
  The Allwinner A31 SoC using that IP has a reset controller maintaining
  it reset unless told otherwise.
  
  Add some optional reset support to the driver.
  
  Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
  Reviewed-by: Gregory CLEMENT gregory.clem...@free-electrons.com
  Tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 
 This appears to be causing some build errors in Olof's next builder
 for many of the ARM platforms which make use of this:
 
 drivers/i2c/busses/i2c-mv64xxx.c:924: undefined reference to 
 `reset_control_assert'
 drivers/i2c/busses/i2c-mv64xxx.c:904: undefined reference to 
 `reset_control_assert'
 drivers/i2c/busses/i2c-mv64xxx.c:771: undefined reference to 
 `devm_reset_control_get'
 drivers/i2c/busses/i2c-mv64xxx.c:778: undefined reference to 
 `reset_control_deassert'

The reset framework doesn't define its functions when its not
selected, and somehow I think it was not here. What's odd is that
there is an explicit select on RESET_CONTROLLER in the Kconfig. Maybe
it's the circular dependency issue that has been reported that cause
this and Wolfram sent a patch for: http://patchwork.ozlabs.org/patch/327573/

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[PATCH v2 0/3] regulator: s2mps11: Add support for S2MPS14 regulators

Hi,

This patchset adds support for the S2MPS14 device to the s2mps11 regulator
driver. It's a subset of previously sent patches for S2MPS14 device:
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/27194/focus=1649217
along with one new patch:
 - PATCH 2/3: regulator: s2mps11: Add set_suspend_disable for S2MPS14
which replaces previous opmode idea.


These patches are rebased against linux-next tree (next-20140305) because
they depend on changes in main MFD sec-core and s2mps11 regulator driver.


Changes since v1

1. Patch 2/3: Store information that regulator was suspended.


Best regards,
Krzysztof


Krzysztof Kozlowski (3):
  regulator: s2mps11: Add support for S2MPS14 regulators
  regulator: s2mps11: Add set_suspend_disable for S2MPS14
  Documentation: mfd: s2mps11: Document support for S2MPS14

 Documentation/devicetree/bindings/mfd/s2mps11.txt |   12 +-
 drivers/regulator/Kconfig |9 +-
 drivers/regulator/s2mps11.c   |  301 -
 include/linux/mfd/samsung/s2mps14.h   |2 +
 4 files changed, 255 insertions(+), 69 deletions(-)

-- 
1.7.9.5

--
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/

[PATCH v2 3/3] Documentation: mfd: s2mps11: Document support for S2MPS14

Add bindings documentation for S2MPS14 device to the s2mps11 driver.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Mark Brown broo...@kernel.org
Cc: Liam Girdwood lgirdw...@gmail.com
Cc: Tomasz Figa t.f...@samsung.com
Cc: devicet...@vger.kernel.org
Cc: Rob Herring robh...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Acked-by: Tomasz Figa t.f...@samsung.com
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt |   12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 15ee89c3cc7b..f69bec294f02 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -1,5 +1,5 @@
 
-* Samsung S2MPS11 Voltage and Current Regulator
+* Samsung S2MPS11 and S2MPS14 Voltage and Current Regulator
 
 The Samsung S2MPS11 is a multi-function device which includes voltage and
 current regulators, RTC, charger controller and other sub-blocks. It is
@@ -7,7 +7,7 @@ interfaced to the host controller using an I2C interface. Each 
sub-block is
 addressed by the host system using different I2C slave addresses.
 
 Required properties:
-- compatible: Should be samsung,s2mps11-pmic.
+- compatible: Should be samsung,s2mps11-pmic or samsung,s2mps14-pmic.
 - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
 
 Optional properties:
@@ -59,10 +59,14 @@ supports. Note: The 'n' in LDOn and BUCKn represents the 
LDO or BUCK number
 as per the datasheet of s2mps11.
 
- LDOn
- - valid values for n are 1 to 38
+ - valid values for n are:
+   - S2MPS11: 1 to 38
+   - S2MPS14: 1 to 25
  - Example: LDO1, LD02, LDO28
- BUCKn
- - valid values for n are 1 to 10.
+ - valid values for n are:
+   - S2MPS11: 1 to 10
+   - S2MPS14: 1 to 5
  - Example: BUCK1, BUCK2, BUCK9
 
 Example:
-- 
1.7.9.5

--
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/

[PATCH v2 2/3] regulator: s2mps11: Add set_suspend_disable for S2MPS14

S2MPS14 regulators support suspend mode where their status is controlled
by PWREN coming from SoC. This patch implements the set_suspend_disable
for S2MPS14 regulators.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
 drivers/regulator/s2mps11.c |   51 ++-
 include/linux/mfd/samsung/s2mps14.h |2 ++
 2 files changed, 52 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index 1a732e54cd70..94901c47397e 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -39,6 +39,11 @@ struct s2mps11_info {
int ramp_delay16;
int ramp_delay7810;
int ramp_delay9;
+   /*
+* One bit for each S2MPS14 regulator whether the suspend mode
+* was enabled.
+*/
+   unsigned int s2mps14_suspend_state:30;
 };
 
 static int get_ramp_delay(int ramp_delay)
@@ -399,15 +404,59 @@ static const struct regulator_desc s2mps11_regulators[] = 
{
regulator_desc_s2mps11_buck10,
 };
 
+static int s2mps14_regulator_enable(struct regulator_dev *rdev)
+{
+   struct s2mps11_info *s2mps11 = rdev_get_drvdata(rdev);
+   unsigned int val;
+
+   if (s2mps11-s2mps14_suspend_state  (1  rdev_get_id(rdev)))
+   val = S2MPS14_ENABLE_SUSPEND;
+   else
+   val = rdev-desc-enable_mask;
+
+   return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+   rdev-desc-enable_mask, val);
+}
+
+static int s2mps14_regulator_set_suspend_disable(struct regulator_dev *rdev)
+{
+   int ret;
+   unsigned int val;
+   struct s2mps11_info *s2mps11 = rdev_get_drvdata(rdev);
+
+   /* LDO3 should be always on and does not support suspend mode */
+   if (rdev_get_id(rdev) == S2MPS14_LDO3)
+   return 0;
+
+   ret = regmap_read(rdev-regmap, rdev-desc-enable_reg, val);
+   if (ret  0)
+   return ret;
+
+   s2mps11-s2mps14_suspend_state |= (1  rdev_get_id(rdev));
+   /*
+* Don't enable suspend mode if regulator is already disabled because
+* this would effectively for a short time turn on the regulator after
+* resuming.
+* However we still want to toggle the suspend_state bit for regulator
+* in case if it got enabled before suspending the system.
+*/
+   if (!(val  rdev-desc-enable_mask))
+   return 0;
+
+   return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
+   rdev-desc-enable_mask, S2MPS14_ENABLE_SUSPEND);
+}
+
 static struct regulator_ops s2mps14_reg_ops = {
.list_voltage   = regulator_list_voltage_linear,
.map_voltage= regulator_map_voltage_linear,
.is_enabled = regulator_is_enabled_regmap,
-   .enable = regulator_enable_regmap,
+   .enable = s2mps14_regulator_enable,
.disable= regulator_disable_regmap,
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel   = regulator_set_voltage_time_sel,
+   .set_suspend_disable= s2mps14_regulator_set_suspend_disable,
 };
 
 #define regulator_desc_s2mps14_ldo1(num) { \
diff --git a/include/linux/mfd/samsung/s2mps14.h 
b/include/linux/mfd/samsung/s2mps14.h
index ec1e0857ddde..4b449b8ac548 100644
--- a/include/linux/mfd/samsung/s2mps14.h
+++ b/include/linux/mfd/samsung/s2mps14.h
@@ -146,6 +146,8 @@ enum s2mps14_regulators {
 #define S2MPS14_BUCK_VSEL_MASK 0xFF
 #define S2MPS14_ENABLE_MASK(0x03  S2MPS14_ENABLE_SHIFT)
 #define S2MPS14_ENABLE_SHIFT   6
+/* On/Off controlled by PWREN */
+#define S2MPS14_ENABLE_SUSPEND (0x01  S2MPS14_ENABLE_SHIFT)
 #define S2MPS14_LDO_N_VOLTAGES (S2MPS14_LDO_VSEL_MASK + 1)
 #define S2MPS14_BUCK_N_VOLTAGES(S2MPS14_BUCK_VSEL_MASK + 1)
 
-- 
1.7.9.5

--
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/13] EFI mixed mode

2014-03-07 Thread David Rientjes

On Thu, 6 Mar 2014, Matt Fleming wrote:

 Thanks for the report David.
 
 I sent a pull request that fixes these errors up. Looks like it got
 pulled into tip:x86/efi,
 
 commit 617b3c37da78
 Merge: 994448f1afa6 3db4cafdfd05
 Author: Matt Fleming matt.flem...@intel.com
 Date:   Wed Mar 5 18:18:50 2014 +
 
 Merge branch 'mixed-mode' into efi-for-mingo
 
 So everything should be working in tip:x86/efi which includes
 tip:x86/efi-mixed.
 

You're absolutely right, x86/efi looks good!  Thanks Matt.
--
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/

[PATCH v2 1/3] regulator: s2mps11: Add support for S2MPS14 regulators

Add support for S2MPS14 PMIC regulators to s2mps11 driver. The S2MPS14
has fewer BUCK-s and LDO-s than S2MPS11. It also does not support
controlling the BUCK ramp delay.

Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Mark Brown broo...@kernel.org
Cc: Liam Girdwood lgirdw...@gmail.com
Reviewed-by: Yadwinder Singh Brar yadi.b...@samsung.com
---
 drivers/regulator/Kconfig   |9 +-
 drivers/regulator/s2mps11.c |  252 ---
 2 files changed, 196 insertions(+), 65 deletions(-)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 4ddfb6c065c7..14ff714a25fb 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -426,12 +426,13 @@ config REGULATOR_RC5T583
  outputs which can be controlled by i2c communication.
 
 config REGULATOR_S2MPS11
-   tristate Samsung S2MPS11 voltage regulator
+   tristate Samsung S2MPS11/S2MPS14 voltage regulator
depends on MFD_SEC_CORE
help
-This driver supports a Samsung S2MPS11 voltage output regulator
-via I2C bus. S2MPS11 is comprised of high efficient Buck converters
-including Dual-Phase Buck converter, Buck-Boost converter, various 
LDOs.
+This driver supports a Samsung S2MPS11/S2MPS14 voltage output
+regulator via I2C bus. The chip is comprised of high efficient Buck
+converters including Dual-Phase Buck converter, Buck-Boost converter,
+various LDOs.
 
 config REGULATOR_S5M8767
tristate Samsung S5M8767A voltage regulator
diff --git a/drivers/regulator/s2mps11.c b/drivers/regulator/s2mps11.c
index b51ccf534a7c..1a732e54cd70 100644
--- a/drivers/regulator/s2mps11.c
+++ b/drivers/regulator/s2mps11.c
@@ -1,13 +1,18 @@
 /*
  * s2mps11.c
  *
- * Copyright (c) 2012 Samsung Electronics Co., Ltd
+ * Copyright (c) 2012-2014 Samsung Electronics Co., Ltd
  *  http://www.samsung.com
  *
- *  This program is free software; you can redistribute  it and/or modify it
- *  under  the terms of  the GNU General  Public License as published by the
- *  Free Software Foundation;  either version 2 of the  License, or (at your
- *  option) any later version.
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
  *
  */
 
@@ -24,6 +29,7 @@
 #include linux/regulator/of_regulator.h
 #include linux/mfd/samsung/core.h
 #include linux/mfd/samsung/s2mps11.h
+#include linux/mfd/samsung/s2mps14.h
 
 struct s2mps11_info {
unsigned int rdev_num;
@@ -233,7 +239,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.set_ramp_delay = s2mps11_set_ramp_delay,
 };
 
-#define regulator_desc_ldo1(num)   {   \
+#define regulator_desc_s2mps11_ldo1(num)   {   \
.name   = LDO#num,\
.id = S2MPS11_LDO##num, \
.ops= s2mps11_ldo_ops, \
@@ -247,7 +253,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_reg = S2MPS11_REG_L1CTRL + num - 1, \
.enable_mask= S2MPS11_ENABLE_MASK   \
 }
-#define regulator_desc_ldo2(num)   {   \
+#define regulator_desc_s2mps11_ldo2(num) { \
.name   = LDO#num,\
.id = S2MPS11_LDO##num, \
.ops= s2mps11_ldo_ops, \
@@ -262,7 +268,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK   \
 }
 
-#define regulator_desc_buck1_4(num){   \
+#define regulator_desc_s2mps11_buck1_4(num) {  \
.name   = BUCK#num,   \
.id = S2MPS11_BUCK##num,\
.ops= s2mps11_buck_ops,\
@@ -278,7 +284,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK   \
 }
 
-#define regulator_desc_buck5   {   \
+#define regulator_desc_s2mps11_buck5 { \
.name   = BUCK5,  \
.id = S2MPS11_BUCK5,\
.ops= s2mps11_buck_ops,\
@@ -294,7 +300,7 @@ static struct regulator_ops s2mps11_buck_ops = {
.enable_mask= S2MPS11_ENABLE_MASK   \
 }
 
-#define regulator_desc_buck6_8(num){   \
+#define

Re: [PATCH 2/3] regulator: s2mps11: Add set_suspend_disable for S2MPS14

On Fri, 2014-03-07 at 10:37 +0800, Mark Brown wrote:
 On Thu, Mar 06, 2014 at 03:42:22PM +0100, Krzysztof Kozlowski wrote:
 
  However in that case the driver won't be able later to change that value
  back to normal enable (enable_mask). Consider such flow:
  1. System is going to suspend.
  2. Some regulator has rstate-disabled so set_suspend_disable() is
  called on it.
  3. The suspend value is written to the device for given regulator and
  it is stored as enable value.
  4. If regulator is enabled during here then the same suspend value
  will be written.
  5. System is suspended.
  6. After resuming regulator_suspend_finish() calls
  _regulator_do_enable() on the regulator... which will write the
  suspend value because the driver cannot differentiate between this
  enable and previous.
 
  I assume that this may not be a problem because:
  1. Regulator will be still turned on (the suspend value tells PMIC to
  enable the regulator when SoC enables power).
  2. The first disable of regulator may bring back enable value back to
  normal mode.
 
  Am I thinking here correctly? 
 
 I'm not entirely sure I follow here.  Why would a disable reset the
 enable value?  My understanding is that this is a bitfield with several
 values, off, on always and on when they system is active.  The suspend
 state is being tracked with a variable so I'm not sure why disabling
 would reset it?
 
 There is a bit of an issue if the regulator is disabled during runtime
 but enabled in suspend but that's hard to resolve and I'm not sure that
 it's a realistic issue.

OK, I think I understand it... I sent v2 of the set_suspend_disable
patch.

Best regards,
Krzysztof


--
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/

[PATCH] lib: remove FBCON dependency for fonts

Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
aren't checked by most higher-level options.

It's a relict of the times when fonts where exclusive to the VT layer and
fbcon.

Signed-off-by: David Herrmann dh.herrm...@gmail.com
---
 lib/fonts/Kconfig | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
index 4dc1b99..0ca66a3 100644
--- a/lib/fonts/Kconfig
+++ b/lib/fonts/Kconfig
@@ -9,7 +9,6 @@ if FONT_SUPPORT
 
 config FONTS
bool Select compiled-in fonts
-   depends on FRAMEBUFFER_CONSOLE
help
  Say Y here if you would like to use fonts other than the default
  your frame buffer console usually use.
@@ -22,7 +21,6 @@ config FONTS
 
 config FONT_8x8
bool VGA 8x8 font if FONTS
-   depends on FRAMEBUFFER_CONSOLE
default y if !SPARC  !FONTS
help
  This is the high resolution font for the VGA frame buffer (the one
@@ -45,7 +43,6 @@ config FONT_8x16
 
 config FONT_6x11
bool Mac console 6x11 font (not supported by all drivers) if FONTS
-   depends on FRAMEBUFFER_CONSOLE
default y if !SPARC  !FONTS  MAC
help
  Small console font with Macintosh-style high-half glyphs.  Some Mac
@@ -53,7 +50,6 @@ config FONT_6x11
 
 config FONT_7x14
bool console 7x14 font (not supported by all drivers) if FONTS
-   depends on FRAMEBUFFER_CONSOLE
help
  Console font with characters just a bit smaller than the default.
  If the standard 8x16 font is a little too big for you, say Y.
@@ -61,7 +57,6 @@ config FONT_7x14
 
 config FONT_PEARL_8x8
bool Pearl (old m68k) console 8x8 font if FONTS
-   depends on FRAMEBUFFER_CONSOLE
default y if !SPARC  !FONTS  AMIGA
help
  Small console font with PC-style control-character and high-half
@@ -69,7 +64,6 @@ config FONT_PEARL_8x8
 
 config FONT_ACORN_8x8
bool Acorn console 8x8 font if FONTS
-   depends on FRAMEBUFFER_CONSOLE
default y if !SPARC  !FONTS  ARM  ARCH_ACORN
help
  Small console font with PC-style control characters and high-half
@@ -81,13 +75,13 @@ config FONT_MINI_4x6
 
 config FONT_SUN8x16
bool Sparc console 8x16 font
-   depends on FRAMEBUFFER_CONSOLE  (!SPARC  FONTS || SPARC)
+   depends on !SPARC  FONTS || SPARC
help
  This is the high resolution console font for Sun machines. Say Y.
 
 config FONT_SUN12x22
bool Sparc console 12x22 font (not supported by all drivers)
-   depends on FRAMEBUFFER_CONSOLE  (!SPARC  FONTS || SPARC)
+   depends on !SPARC  FONTS || SPARC
help
  This is the high resolution console font for Sun machines with very
  big letters (like the letters used in the SPARC PROM). If the
@@ -95,7 +89,6 @@ config FONT_SUN12x22
 
 config FONT_10x18
bool console 10x18 font (not supported by all drivers) if FONTS
-   depends on FRAMEBUFFER_CONSOLE
help
  This is a high resolution console font for machines with very
  big letters. It fits between the sun 12x22 and the normal 8x16 font.
-- 
1.9.0

--
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/

[PATCH v3 3/8] phy: ti-pipe3: Add SATA compatible to Documentation binding

SATA PHY needs a new compatible ID. Add it to the DT binding documentation.

Acked-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 Documentation/devicetree/bindings/phy/ti-phy.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 96ba29e..4ab9cb1 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -53,7 +53,8 @@ usb2phy@4a0ad080 {
 TI PIPE3 PHY
 
 Required properties:
- - compatible: Should be ti,phy-usb3. ti,omap-usb3 is deprecated.
+ - compatible: Should be ti,phy-usb3 or ti,phy-pipe3-sata.
+   ti,omap-usb3 is deprecated.
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the 
registers
filled in reg.
-- 
1.8.3.2

--
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/

[PATCH v3 6/8] ARM: dts: omap5: add sata node

From: Balaji T K balaj...@ti.com

Add support for sata.

[Roger Q] Clean up.

CC: Benoit Cousson bcous...@baylibre.com
CC: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi | 40 
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 88bd327..521caab 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -829,6 +829,46 @@
 
#thermal-sensor-cells = 1;
};
+
+   omap_control_sata: control-phy@4a002374 {
+   compatible = ti,control-phy-pipe3;
+   reg = 0x4a002374 0x4;
+   reg-names = power;
+   clocks = sys_clkin;
+   clock-names = sysclk;
+   };
+
+   /* OCP2SCP3 */
+   ocp2scp@4a09 {
+   compatible = ti,omap-ocp2scp;
+   #address-cells = 1;
+   #size-cells = 1;
+   reg = 0x4a09 0x20;
+   ranges;
+   ti,hwmods = ocp2scp3;
+   sata_phy: phy@4a096000 {
+   compatible = ti,phy-pipe3-sata;
+   reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+   reg-names = phy_rx, phy_tx, pll_ctrl;
+   ctrl-module = omap_control_sata;
+   clocks = sys_clkin;
+   clock-names = sysclk;
+   #phy-cells = 0;
+   };
+   };
+
+   sata: sata@4a141100 {
+   compatible = snps,dwc-ahci;
+   reg = 0x4a14 0x1100, 0x4a141100 0x7;
+   interrupts = GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH;
+   phys = sata_phy;
+   phy-names = sata-phy;
+   clocks = sata_ref_clk;
+   ti,hwmods = sata;
+   };
+
};
 };
 
-- 
1.8.3.2

--
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/

[PATCH v3 0/8] ARM: OMAP: SATA support for OMAP5 DRA7

Hi Tony  Felipe,

Kishon has pulled in the relevant PHY patches into his tree.
These are the remaining patches from the series.

Patches 1 to 3 need to go through Felipe's USB tree.
Patches 4 to 8 need to go through Tony's OMAP tree.

Thanks.

Patches are based on 3.14-rc4 with balbi/next, linux-phy/next and
omap-for-v3.15/dt merged on top.

To test SATA you will also need [1].

[1] - http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7285

Changelog:
v3
- Removed PHY patches and rebased.

v2
- use 'depends on' instead of 'select' OCP2SCP bus driver.
- Changed DT bindings for dra7-usb2 and am437-usb2 phy.

cheers,
-roger

---
Balaji T K (2):
  ARM: dts: omap5: add sata node
  ARM: dts: dra7: add OCP2SCP3 and SATA nodes

Keshava Munegowda (1):
  ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods

Nikhil Devshatwar (1):
  ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods

Roger Quadros (4):
  phy: omap-control: update dra7 and am437 usb2 Documentation bindings
  phy: ti-pipe3: Add clocks to PIPE3 PHY Documentation binding
  phy: ti-pipe3: Add SATA compatible to Documentation binding
  ARM: dts: omap5: Add clocks to USB3 PHY node

 Documentation/devicetree/bindings/phy/ti-phy.txt | 19 +-
 arch/arm/boot/dts/dra7.dtsi  | 39 +
 arch/arm/boot/dts/omap5.dtsi | 46 +++
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c   | 73 
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 31 --
 5 files changed, 200 insertions(+), 8 deletions(-)

-- 
1.8.3.2

--
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/

[PATCH v3 8/8] ARM: dts: dra7: add OCP2SCP3 and SATA nodes

From: Balaji T K balaj...@ti.com

Add nodes for OCP2SCP3 bus, SATA controller and SATA PHY.

[Roger Q] Clean up.

CC: Benoit Cousson bcous...@baylibre.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/dra7.dtsi | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 9e3caf3..597979b 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -772,6 +772,45 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+   omap_control_sata: control-phy@4a002374 {
+   compatible = ti,control-phy-pipe3;
+   reg = 0x4a002374 0x4;
+   reg-names = power;
+   clocks = sys_clkin1;
+   clock-names = sysclk;
+   };
+
+   /* OCP2SCP3 */
+   ocp2scp@4a09 {
+   compatible = ti,omap-ocp2scp;
+   #address-cells = 1;
+   #size-cells = 1;
+   ranges;
+   reg = 0x4a09 0x20;
+   ti,hwmods = ocp2scp3;
+   sata_phy: phy@4A096000 {
+   compatible = ti,phy-pipe3-sata;
+   reg = 0x4A096000 0x80, /* phy_rx */
+ 0x4A096400 0x64, /* phy_tx */
+ 0x4A096800 0x40; /* pll_ctrl */
+   reg-names = phy_rx, phy_tx, pll_ctrl;
+   ctrl-module = omap_control_sata;
+   clocks = sys_clkin1;
+   clock-names = sysclk;
+   #phy-cells = 0;
+   };
+   };
+
+   sata: sata@4a141100 {
+   compatible = snps,dwc-ahci;
+   reg = 0x4a14 0x1100, 0x4a141100 0x7;
+   interrupts = GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH;
+   phys = sata_phy;
+   phy-names = sata-phy;
+   clocks = sata_ref_clk;
+   ti,hwmods = sata;
+   };
};
 };
 
-- 
1.8.3.2

--
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/

[PATCH v3 7/8] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods

From: Nikhil Devshatwar nikhil...@ti.com

Add hwmods for ocp2scp3 and sata modules.

[Roger Q] Clean up.

CC: Benoit Cousson bcous...@baylibre.com
CC: Paul Walmsley p...@pwsan.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Nikhil Devshatwar nikhil...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 18f333c..3c9a430 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
},
 };
 
+/* ocp2scp3 */
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
+
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
+   .master = dra7xx_l4_cfg_hwmod,
+   .slave  = dra7xx_ocp2scp3_hwmod,
+   .clk= l4_root_clk_div,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
+   .name   = ocp2scp3,
+   .class  = dra7xx_ocp2scp_hwmod_class,
+   .clkdm_name = l3init_clkdm,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = 
DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+   .context_offs = 
DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
 /*
  * 'qspi' class
  *
@@ -1268,9 +1292,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class = {
 };
 
 /* sata */
-static struct omap_hwmod_opt_clk sata_opt_clks[] = {
-   { .role = ref_clk, .clk = sata_ref_clk },
-};
 
 static struct omap_hwmod dra7xx_sata_hwmod = {
.name   = sata,
@@ -1278,6 +1299,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.clkdm_name = l3init_clkdm,
.flags  = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk   = func_48m_fclk,
+   .mpu_rt_idx = 1,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
@@ -1285,8 +1307,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.modulemode   = MODULEMODE_SWCTRL,
},
},
-   .opt_clks   = sata_opt_clks,
-   .opt_clks_cnt   = ARRAY_SIZE(sata_opt_clks),
 };
 
 /*
@@ -2683,6 +2703,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
dra7xx_l4_per1__mmc4,
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
+   dra7xx_l4_cfg__ocp2scp3,
dra7xx_l3_main_1__qspi,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
-- 
1.8.3.2

--
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/

[PATCH v3 5/8] ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods

From: Keshava Munegowda keshava_mgo...@ti.com

Create hwmods for ocp2scp3 and sata modules.

[Roger Q] Clean up.

CC: Benoit Cousson bcous...@baylibre.com
CC: Paul Walmsley p...@pwsan.com
CC: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..227a69f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1726,6 +1726,77 @@ static struct omap_hwmod omap54xx_wd_timer2_hwmod = {
},
 };
 
+/*
+ * 'ocp2scp' class
+ * bridge to transform ocp interface protocol to scp (serial control port)
+ * protocol
+ */
+/* ocp2scp3 */
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod;
+/* l4_cfg - ocp2scp3 */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__ocp2scp3 = {
+   .master = omap54xx_l4_cfg_hwmod,
+   .slave  = omap54xx_ocp2scp3_hwmod,
+   .clk= l4_root_clk_div,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap54xx_ocp2scp3_hwmod = {
+   .name   = ocp2scp3,
+   .class  = omap54xx_ocp2scp_hwmod_class,
+   .clkdm_name = l3init_clkdm,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = 
OMAP54XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+   .context_offs = 
OMAP54XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_HWCTRL,
+   },
+   },
+};
+
+/*
+ * 'sata' class
+ * sata:  serial ata interface  gen2 compliant   ( 1 rx/ 1 tx)
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_sata_sysc = {
+   .sysc_offs  = 0x,
+   .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+  SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+  MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+   .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_sata_hwmod_class = {
+   .name   = sata,
+   .sysc   = omap54xx_sata_sysc,
+};
+
+/* sata */
+static struct omap_hwmod omap54xx_sata_hwmod = {
+   .name   = sata,
+   .class  = omap54xx_sata_hwmod_class,
+   .clkdm_name = l3init_clkdm,
+   .flags  = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+   .main_clk   = func_48m_fclk,
+   .mpu_rt_idx = 1,
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = OMAP54XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
+   .context_offs = OMAP54XX_RM_L3INIT_SATA_CONTEXT_OFFSET,
+   .modulemode   = MODULEMODE_SWCTRL,
+   },
+   },
+};
+
+/* l4_cfg - sata */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__sata = {
+   .master = omap54xx_l4_cfg_hwmod,
+   .slave  = omap54xx_sata_hwmod,
+   .clk= l3_iclk_div,
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
 
 /*
  * Interfaces
@@ -2399,6 +2470,8 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[] 
__initdata = {
omap54xx_l4_cfg__usb_tll_hs,
omap54xx_l4_cfg__usb_otg_ss,
omap54xx_l4_wkup__wd_timer2,
+   omap54xx_l4_cfg__ocp2scp3,
+   omap54xx_l4_cfg__sata,
NULL,
 };
 
-- 
1.8.3.2

--
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/

Purchase Order ... Kindly download to view our purchasing order?

2014-03-07 Thread Newton brothers trade group

Good Day,
We already made the balance payment on friday, find attachment tt Slip please 
courier us Bill of landing 

asap. waiting for your reply urgently.


John lander
purchase manager
sales.departm...@techie.com


Purchase Order List.html
Description: Binary data

[PATCH v3 2/8] phy: ti-pipe3: Add clocks to PIPE3 PHY Documentation binding

Add wakeup, system and reference clocks to DT binding documentation.

Acked-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 Documentation/devicetree/bindings/phy/ti-phy.txt | 12 
 1 file changed, 12 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 073a623..96ba29e 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -59,6 +59,12 @@ Required properties:
filled in reg.
  - #phy-cells: determine the number of cells that should be given in the
phandle while referencing this phy.
+ - clocks: a list of phandles and clock-specifier pairs, one for each entry in
+   clock-names.
+ - clock-names: should include:
+   * wkupclk - wakeup clock.
+   * sysclk - system clock.
+   * refclk - reference clock.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -74,4 +80,10 @@ usb3phy@4a084400 {
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb;
#phy-cells = 0;
+   clocks = usb_phy_cm_clk32k,
+sys_clkin,
+usb_otg_ss_refclk960m;
+   clock-names =   wkupclk,
+   sysclk,
+   refclk;
 };
-- 
1.8.3.2

--
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/

[PATCH v3 4/8] ARM: dts: omap5: Add clocks to USB3 PHY node

The USB3 PHY driver now expects named clocks. Add the
relevant clocks to the USB3 PHY node.

Signed-off-by: Roger Quadros rog...@ti.com
---
 arch/arm/boot/dts/omap5.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 859a800..88bd327 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -779,6 +779,12 @@
  0x4a084c00 0x40;
reg-names = phy_rx, phy_tx, pll_ctrl;
ctrl-module = omap_control_usb3phy;
+   clocks = usb_phy_cm_clk32k,
+sys_clkin,
+usb_otg_ss_refclk960m;
+   clock-names =   wkupclk,
+   sysclk,
+   refclk;
#phy-cells = 0;
};
};
-- 
1.8.3.2

--
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: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

2014-03-07 Thread Fengguang Wu

Hi Stefani,

On Fri, Mar 07, 2014 at 10:57:28AM +0100, Stefani Seibold wrote:
 Hi Fengguang,
 
 did you test the config i had sent to you?
 
 My test was all done with current 3.14-rc tree. And with this i have no
 problem. 

The regression is found on commit 4dea8e4824b363c53f320d328040d7c6c5921419
(x86, vdso: Add 32 bit VDSO time support for 32 bit kernel) in tip tree.

In the bisect log, you can see that next-20140306 is GOOD. So there's
no way you can find the bug in 3.14-rcX.

 I just cloned the tip tree and i figured out that the patch was dropped
 again (BTW: git log does not show that it was ever applied).

You can still access that specific commit:

wfg@bee /tmp% git clone --reference /c/linux 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
Cloning into 'tip'...
remote: Counting objects: 27506, done.
remote: Compressing objects: 100% (7812/7812), done.
remote: Total 25517 (delta 18365), reused 23335 (delta 16786)
Receiving objects: 100% (25517/25517), 7.76 MiB | 31.00 KiB/s, done.
Resolving deltas: 100% (18365/18365), completed with 1321 local objects.
Checking connectivity... done.
Checking out files: 100% (46209/46209), done.
wfg@bee /tmp% cd tip
wfg@bee /tmp/tip% git show 4dea8e4824b363c53f320d328040d7c6c5921419|head   
commit 4dea8e4824b363c53f320d328040d7c6c5921419
Author: Stefani Seibold stef...@seibold.net
Date:   Mon Mar 3 22:12:20 2014 +0100

x86, vdso: Add 32 bit VDSO time support for 32 bit kernel

 Okay, that's enough for me. If it nearly impossible to cut this gordian
 knot without support and test from the intel kernel developer group.
 
 The origin code was not in the best shape too. I cannot understand why
 this was going into mainline without 32 bit support.
 
 So i tried my best, but without support it is impossible to find all
 issues. But mostly what i get was bureaucracy afflictions
 
 I complied, but now it is time to help finding the issues. And not only
 do a complain, sit back and wait.
 
 If i haed a  8192 core i7 XEON machine i would be able to test all
 mutations of kernels. But i have not (despite i cannot pay the invoice).
 
 Also i get no support by people who ask me to do this work. I am really
 pissed of.
 
 - Stefani
 
 Am Freitag, den 07.03.2014, 17:15 +0800 schrieb Fengguang Wu:
 
  Hi Stefani,
  
  On Fri, Mar 07, 2014 at 09:47:14AM +0100, Stefani Seibold wrote:
   Hi Fengguang,
   
   i was now able to bring up the kernel on my KVM with some minior
   changes. I kick out the PARIDE, switched to IDE and activated the VT
   support. With this modifications the kernel boot and i get no BUG,
   everything is fine!
   
   So i can not reproduce the bug and i want ask you to check the attached
   kernel config. If this also works for you the problem is maybe located
   in the environment, f.e. gcc.
  
  I'm using gcc 4.8.1, as you can see from the 2nd line of the below dmesg.
  I can reproduce it reliably - see the screen dump below. You can find
  the reproduce script at the end of this email.
  
  wfg@bee 
  /kernel/i386-randconfig-nh0-03070222/d478a960edf1ea61ca31a07a48a8771f043dba78%
   kvm-0day.sh vmlinuz-3.14.0-rc5-03765-gd478a96
  early console in setup code
  [0.00] Linux version 3.14.0-rc5-03765-gd478a96 (kbuild@nhm4) (gcc 
  version 4.8.1 (Debian 4.8.1-8) ) #2 SMP PREEMPT Fri Mar 7 03:16:44 CST 2014
  [0.00] e820: BIOS-provided physical RAM map:
  [0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
  [0.00] BIOS-e820: [mem 0x0009fc00-0x0009] 
  reserved
  [0.00] BIOS-e820: [mem 0x000f-0x000f] 
  reserved
  [0.00] BIOS-e820: [mem 0x0010-0x0fffdfff] usable
  [0.00] BIOS-e820: [mem 0x0fffe000-0x0fff] 
  reserved
  [0.00] BIOS-e820: [mem 0xfeffc000-0xfeff] 
  reserved
  [0.00] BIOS-e820: [mem 0xfffc-0x] 
  reserved
  [0.00] debug: ignoring loglevel setting.
  [0.00] NX (Execute Disable) protection: active
  [0.00] Hypervisor detected: KVM
  [0.00] e820: update [mem 0x-0x0fff] usable == reserved
  [0.00] e820: remove [mem 0x000a-0x000f] usable
  [0.00] e820: last_pfn = 0xfffe max_arch_pfn = 0x100
  [0.00] MTRR default type: write-back
  [0.00] MTRR fixed ranges enabled:
  [0.00]   0-9 write-back
  [0.00]   A-B uncachable
  [0.00]   C-F write-protect
  [0.00] MTRR variable ranges enabled:
  [0.00]   0 base 008000 mask FF8000 uncachable
  [0.00]   1 disabled
  [0.00]   2 disabled
  [0.00]   3 disabled
  [0.00]   4 disabled
  [0.00]   5 disabled
  [0.00]   6 disabled
  [0.00]   7 disabled
  [0.00] initial memory mapped: [mem 0x-0x023f]
  [0.00] Base memory trampoline at [c009b000] 9b000 size

Re: [PATCH v3 2/5] i2c: mv64xxx: Add support for the Allwinner A31 I2C driver

2014-03-07 Thread Maxime Ripard

Hi Wolfram,

On Wed, Mar 05, 2014 at 05:34:30PM +0100, Wolfram Sang wrote:
 On Tue, Mar 04, 2014 at 05:28:38PM +0100, Maxime Ripard wrote:
  The Allwinner A31 I2C controller is almost identical to the one used in the
  other Allwinner SoCs, except for the fact that it needs to clear the 
  interrupt
  by setting the INT_FLAGS bit in the control register, instead of clearing 
  it.
  
  Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
  Reviewed-by: Gregory CLEMENT gregory.clem...@free-electrons.com
  Tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 
 Applied to for-next, thanks!
 
 Still...
 
  +   if (of_device_is_compatible(np, allwinner,sun6i-a31-i2c))
  +   drv_data-irq_clear_inverted = true;
 
 ... next time an errata is needed, I think it makes sense to refactor all
 these checks into one struct which can be used as match-data directly.

Yep, it makes sense. Thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[PATCH v3 1/8] phy: omap-control: update dra7 and am437 usb2 Documentation bindings

The dra7-usb2 and am437-usb2 bindings have not yet been used.
Change them to be more elegant.

Acked-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
 Documentation/devicetree/bindings/phy/ti-phy.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt 
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 5c5b1b0..073a623 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -9,9 +9,9 @@ Required properties:
 e.g. USB2_PHY on OMAP5.
  ti,control-phy-pipe3 - if it has DPLL and individual Rx  Tx power control
 e.g. USB3 PHY and SATA PHY on OMAP5.
- ti,control-phy-dra7usb2 - if it has power down register like USB2 PHY on
+ ti,control-phy-usb2-dra7 - if it has power down register like USB2 PHY on
 DRA7 platform.
- ti,control-phy-am437usb2 - if it has power down register like USB2 PHY on
+ ti,control-phy-usb2-am437 - if it has power down register like USB2 PHY on
 AM437 platform.
  - reg : Address and length of the register set for the device. It contains
the address of otghs_control for control-phy-otghs or power register
-- 
1.8.3.2

--
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 3/5] ARM: dts: AM4372: Add USB nodes

On 03/07/2014 11:15 AM, George Cherian wrote:
 Add nodes for 2 instances each of
   - ocp2scp
   - USB PHY control module
   - USB PHY
   - dwc3_omap
   - USB
 
 for AM43xx.
 
 Signed-off-by: George Cherian george.cher...@ti.com

Acked-by: Roger Quadros rog...@ti.com

cheers,
-roger

 ---
  arch/arm/boot/dts/am4372.dtsi | 95 
 +++
  1 file changed, 95 insertions(+)
 
 diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
 index 5a7cc38..fdcdf1b 100644
 --- a/arch/arm/boot/dts/am4372.dtsi
 +++ b/arch/arm/boot/dts/am4372.dtsi
 @@ -698,6 +698,101 @@
  edma 11;
   dma-names = tx, rx;
   };
 +
 + am43xx_control_usb2phy1: control-phy@44e10620 {
 + compatible = ti,control-phy-usb2-am437;
 + reg = 0x44e10620 0x4;
 + reg-names = power;
 + };
 +
 + am43xx_control_usb2phy2: control-phy@0x44e10628 {
 + compatible = ti,control-phy-usb2-am437;
 + reg = 0x44e10628 0x4;
 + reg-names = power;
 + };
 +
 + ocp2scp0: ocp2scp@483a8000 {
 + compatible = ti,omap-ocp2scp;
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 + ti,hwmods = ocp2scp0;
 +
 + usb2_phy1: phy@483a8000 {
 + compatible = ti,am437x-usb2;
 + reg = 0x483a8000 0x8000;
 + ctrl-module = am43xx_control_usb2phy1;
 + clocks = clk_32768_ck,
 +  usb_otg_ss0_refclk960m;
 + clock-names = wkupclk, refclk;
 + #phy-cells = 0;
 + status = disabled;
 + };
 + };
 +
 + ocp2scp1: ocp2scp@483e8000 {
 + compatible = ti,omap-ocp2scp;
 + #address-cells = 1;
 + #size-cells = 1;
 + ranges;
 + ti,hwmods = ocp2scp1;
 +
 + usb2_phy2: phy@483e8000 {
 + compatible = ti,am437x-usb2;
 + reg = 0x483e8000 0x8000;
 + ctrl-module = am43xx_control_usb2phy2;
 + clocks = clk_32768_ck,
 +  usb_otg_ss1_refclk960m;
 + clock-names = wkupclk, refclk;
 + #phy-cells = 0;
 + status = disabled;
 + };
 + };
 +
 + dwc3_1: omap_dwc3@4838 {
 + compatible = ti,am437x-dwc3;
 + ti,hwmods = usb_otg_ss0;
 + reg = 0x4838 0x1;
 + interrupts = GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH;
 + #address-cells = 1;
 + #size-cells = 1;
 + utmi-mode = 1;
 + ranges;
 +
 + usb1: usb@4839 {
 + compatible = synopsys,dwc3;
 + reg = 0x4839 0x17000;
 + interrupts = GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH;
 + phys = usb2_phy1;
 + phy-names = usb2-phy;
 + maximum-speed = high-speed;
 + dr_mode = otg;
 + status = disabled;
 + };
 + };
 +
 + dwc3_2: omap_dwc3@483c {
 + compatible = ti,am437x-dwc3;
 + ti,hwmods = usb_otg_ss1;
 + reg = 0x483c 0x1;
 + interrupts = GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH;
 + #address-cells = 1;
 + #size-cells = 1;
 + utmi-mode = 1;
 + ranges;
 +
 + usb2: usb@483d {
 + compatible = synopsys,dwc3;
 + reg = 0x483d 0x17000;
 + interrupts = GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH;
 + phys = usb2_phy2;
 + phy-names = usb2-phy;
 + maximum-speed = high-speed;
 + dr_mode = otg;
 + status = disabled;
 + };
 + };
 +
   };
  };
  
 

--
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

Re: [PATCH v2 4/5] ARM: dts: am437x-gp-evm: Enable USB

Hi George,

On 03/07/2014 11:15 AM, George Cherian wrote:
 Enable
   - ocp2scp
   - USB PHY control module
   - USB PHY
   - dwc3_omap
   - USB
 for am437x-gp-evm
 
 Signed-off-by: George Cherian george.cher...@ti.com
 ---
  arch/arm/boot/dts/am437x-gp-evm.dts | 28 
  1 file changed, 28 insertions(+)
 
 diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
 b/arch/arm/boot/dts/am437x-gp-evm.dts
 index 4eb72b8..1d516a7 100644
 --- a/arch/arm/boot/dts/am437x-gp-evm.dts
 +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
 @@ -98,3 +98,31 @@
  gpio4 {
   status = okay;
  };
 +
 +
 +usb2_phy1 {
 + status = okay;
 +};
 +
 +dwc3_1 {
 + status = okay;
 +};

Do you need to explicitly enable dwc3_1 nand dwc3_2?

 +
 +usb1 {
 + dr_mode = peripheral;
 + status = okay;
 +};
 +
 +
 +usb2_phy2 {
 + status = okay;
 +};
 +
 +dwc3_2 {
 + status = okay;
 +};
 +
 +usb2 {
 + dr_mode = host;
 + status = okay;
 +};
 

cheers,
-roger
--
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 4/5] ARM: dts: am437x-gp-evm: Enable USB


On 3/7/2014 3:55 PM, Roger Quadros wrote:

Hi George,

On 03/07/2014 11:15 AM, George Cherian wrote:

Enable
- ocp2scp
- USB PHY control module
- USB PHY
- dwc3_omap
- USB
for am437x-gp-evm

Signed-off-by: George Cherian george.cher...@ti.com
---
  arch/arm/boot/dts/am437x-gp-evm.dts | 28 
  1 file changed, 28 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 4eb72b8..1d516a7 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -98,3 +98,31 @@
  gpio4 {
status = okay;
  };
+
+
+usb2_phy1 {
+   status = okay;
+};
+
+dwc3_1 {
+   status = okay;
+};

Do you need to explicitly enable dwc3_1 nand dwc3_2?


Ahhh... Fixed only in am4372.dtsi
Same with patch 5, I will resend the series fixing it.




+
+usb1 {
+   dr_mode = peripheral;
+   status = okay;
+};
+
+
+usb2_phy2 {
+   status = okay;
+};
+
+dwc3_2 {
+   status = okay;
+};
+
+usb2 {
+   dr_mode = host;
+   status = okay;
+};


cheers,
-roger



--
-George

--
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/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Russell King - ARM Linux

On Fri, Mar 07, 2014 at 11:07:51AM +0100, Maxime Ripard wrote:
 Hi Russell,
 
 On Fri, Mar 07, 2014 at 09:52:23AM +, Russell King - ARM Linux wrote:
  On Tue, Mar 04, 2014 at 05:28:37PM +0100, Maxime Ripard wrote:
   The Allwinner A31 SoC using that IP has a reset controller maintaining
   it reset unless told otherwise.
   
   Add some optional reset support to the driver.
   
   Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
   Reviewed-by: Gregory CLEMENT gregory.clem...@free-electrons.com
   Tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com
  
  This appears to be causing some build errors in Olof's next builder
  for many of the ARM platforms which make use of this:
  
  drivers/i2c/busses/i2c-mv64xxx.c:924: undefined reference to 
  `reset_control_assert'
  drivers/i2c/busses/i2c-mv64xxx.c:904: undefined reference to 
  `reset_control_assert'
  drivers/i2c/busses/i2c-mv64xxx.c:771: undefined reference to 
  `devm_reset_control_get'
  drivers/i2c/busses/i2c-mv64xxx.c:778: undefined reference to 
  `reset_control_deassert'
 
 The reset framework doesn't define its functions when its not
 selected, and somehow I think it was not here. What's odd is that
 there is an explicit select on RESET_CONTROLLER in the Kconfig. Maybe
 it's the circular dependency issue that has been reported that cause
 this and Wolfram sent a patch for: http://patchwork.ozlabs.org/patch/327573/

If that patch has been taken, then yes, it will have caused the above -
because now we have Dove and Kirkwood platforms trying to build this
driver without RESET_CONTROLLER being set.

The problem with depending on RESET_CONTROLLER is that then these
platforms end up without their I2C controller - because there's nothing
which enables RESET_CONTROLLER in their configuration.

Since RESET_CONTROLLER is not required for those platforms, it really
should be optional - and I think the real fix is for the reset controller
support to provide stub functions.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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/5] i2c: mv64xxx: Add reset deassert call

2014-03-07 Thread Wolfram Sang


 Since RESET_CONTROLLER is not required for those platforms, it really
 should be optional - and I think the real fix is for the reset controller
 support to provide stub functions.

I agree; and I assumed it already does. Will resend a patch posted
earlier [1] to fix the issue. And still debugging why my build-tests
didn't get it :(

[1] https://lkml.org/lkml/2013/8/9/442



signature.asc
Description: Digital signature

Re: [PATCH] lib: remove FBCON dependency for fonts

2014-03-07 Thread Geert Uytterhoeven

On Fri, Mar 7, 2014 at 11:14 AM, David Herrmann dh.herrm...@gmail.com wrote:
 Fonts don't depend on CONFIG_FRAMEBUFFER_CONSOLE at all. Remove that.
 Besides, CONFIG_FONT_SUPPORT is 'select'ed anyway, so the dependencies
 aren't checked by most higher-level options.

CONFIG_FONT_SUPPORT is indeed selected, but the other options are about
which fonts to include by default. No dependencies are bypassed by the select.

Without the depends on FRAMEBUFFER_CONSOLE, people who don't
have FRAMEBUFFER_CONSOLE set, but have set any of these:

config EARLY_PRINTK_EFI
select FONT_SUPPORT

config VIDEO_VIVI
select FONT_SUPPORT
select FONT_8x16

config SOLO6X10
select FONT_SUPPORT
select FONT_8x16

config USB_SISUSBVGA
select FONT_SUPPORT
...
select FONT_8x16

config SGI_NEWPORT_CONSOLE
select FONT_SUPPORT

config STI_CONSOLE
select FONT_SUPPORT

will now get more (unused) fonts in their kernel image.

 It's a relict of the times when fonts where exclusive to the VT layer and
 fbcon.

 Signed-off-by: David Herrmann dh.herrm...@gmail.com
 ---
  lib/fonts/Kconfig | 11 ++-
  1 file changed, 2 insertions(+), 9 deletions(-)

 diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
 index 4dc1b99..0ca66a3 100644
 --- a/lib/fonts/Kconfig
 +++ b/lib/fonts/Kconfig
 @@ -9,7 +9,6 @@ if FONT_SUPPORT

  config FONTS
 bool Select compiled-in fonts
 -   depends on FRAMEBUFFER_CONSOLE
 help
   Say Y here if you would like to use fonts other than the default
   your frame buffer console usually use.
 @@ -22,7 +21,6 @@ config FONTS

  config FONT_8x8
 bool VGA 8x8 font if FONTS
 -   depends on FRAMEBUFFER_CONSOLE
 default y if !SPARC  !FONTS
 help
   This is the high resolution font for the VGA frame buffer (the one
 @@ -45,7 +43,6 @@ config FONT_8x16

  config FONT_6x11
 bool Mac console 6x11 font (not supported by all drivers) if FONTS
 -   depends on FRAMEBUFFER_CONSOLE
 default y if !SPARC  !FONTS  MAC
 help
   Small console font with Macintosh-style high-half glyphs.  Some Mac
 @@ -53,7 +50,6 @@ config FONT_6x11

  config FONT_7x14
 bool console 7x14 font (not supported by all drivers) if FONTS
 -   depends on FRAMEBUFFER_CONSOLE
 help
   Console font with characters just a bit smaller than the default.
   If the standard 8x16 font is a little too big for you, say Y.
 @@ -61,7 +57,6 @@ config FONT_7x14

  config FONT_PEARL_8x8
 bool Pearl (old m68k) console 8x8 font if FONTS
 -   depends on FRAMEBUFFER_CONSOLE
 default y if !SPARC  !FONTS  AMIGA
 help
   Small console font with PC-style control-character and high-half
 @@ -69,7 +64,6 @@ config FONT_PEARL_8x8

  config FONT_ACORN_8x8
 bool Acorn console 8x8 font if FONTS
 -   depends on FRAMEBUFFER_CONSOLE
 default y if !SPARC  !FONTS  ARM  ARCH_ACORN
 help
   Small console font with PC-style control characters and high-half
 @@ -81,13 +75,13 @@ config FONT_MINI_4x6

  config FONT_SUN8x16
 bool Sparc console 8x16 font
 -   depends on FRAMEBUFFER_CONSOLE  (!SPARC  FONTS || SPARC)
 +   depends on !SPARC  FONTS || SPARC
 help
   This is the high resolution console font for Sun machines. Say Y.

  config FONT_SUN12x22
 bool Sparc console 12x22 font (not supported by all drivers)
 -   depends on FRAMEBUFFER_CONSOLE  (!SPARC  FONTS || SPARC)
 +   depends on !SPARC  FONTS || SPARC
 help
   This is the high resolution console font for Sun machines with very
   big letters (like the letters used in the SPARC PROM). If the
 @@ -95,7 +89,6 @@ config FONT_SUN12x22

  config FONT_10x18
 bool console 10x18 font (not supported by all drivers) if FONTS
 -   depends on FRAMEBUFFER_CONSOLE
 help
   This is a high resolution console font for machines with very
   big letters. It fits between the sun 12x22 and the normal 8x16 font.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] lib: remove FBCON dependency for fonts