Re: [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show

2016-09-13 Thread hejianet

Hi Marcelo


On 9/13/16 2:57 AM, Marcelo wrote:

On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote:

This is to use the generic interface snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.
Then snmp_seq_show and netstat_seq_show are split into 2 parts to avoid build
warning "the frame size" larger than 1024 on s390.

Yeah about that, did you test it with stack overflow detection?
These arrays can be quite large.

One more below..

Do you think it is acceptable if the stack usage is a little larger than 1024?
e.g. 1120
I can't find any other way to reduce the stack usage except use "static" before
unsigned long buff[TCP_MIB_MAX]

PS. sizeof buff is about TCP_MIB_MAX(116)*8=928
B.R.

Signed-off-by: Jia He 
---
  net/ipv4/proc.c | 106 +++-
  1 file changed, 74 insertions(+), 32 deletions(-)

diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 9f665b6..c6fc80e 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -46,6 +46,8 @@
  #include 
  #include 
  
+#define TCPUDP_MIB_MAX max_t(u32, UDP_MIB_MAX, TCP_MIB_MAX)

+
  /*
   *Report socket allocation statistics [m...@utu.fi]
   */
@@ -378,13 +380,15 @@ static void icmp_put(struct seq_file *seq)
  /*
   *Called from the PROCfs module. This outputs /proc/net/snmp.
   */
-static int snmp_seq_show(struct seq_file *seq, void *v)
+static int snmp_seq_show_ipstats(struct seq_file *seq, void *v)
  {
int i;
+   u64 buff64[IPSTATS_MIB_MAX];
struct net *net = seq->private;
  
-	seq_puts(seq, "Ip: Forwarding DefaultTTL");

+   memset(buff64, 0, IPSTATS_MIB_MAX * sizeof(u64));
  
+	seq_puts(seq, "Ip: Forwarding DefaultTTL");

for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_ipstats_list[i].name);
  
@@ -393,57 +397,77 @@ static int snmp_seq_show(struct seq_file *seq, void *v)

   net->ipv4.sysctl_ip_default_ttl);
  
  	BUILD_BUG_ON(offsetof(struct ipstats_mib, mibs) != 0);

+   snmp_get_cpu_field64_batch(buff64, snmp4_ipstats_list,
+  net->mib.ip_statistics,
+  offsetof(struct ipstats_mib, syncp));
for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
-   seq_printf(seq, " %llu",
-  snmp_fold_field64(net->mib.ip_statistics,
-snmp4_ipstats_list[i].entry,
-offsetof(struct ipstats_mib, 
syncp)));
+   seq_printf(seq, " %llu", buff64[i]);
  
-	icmp_put(seq);	/* RFC 2011 compatibility */

-   icmpmsg_put(seq);
+   return 0;
+}
+
+static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
+{
+   int i;
+   unsigned long buff[TCPUDP_MIB_MAX];
+   struct net *net = seq->private;
+
+   memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
  
  	seq_puts(seq, "\nTcp:");

for (i = 0; snmp4_tcp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_tcp_list[i].name);
  
  	seq_puts(seq, "\nTcp:");

+   snmp_get_cpu_field_batch(buff, snmp4_tcp_list,
+net->mib.tcp_statistics);
for (i = 0; snmp4_tcp_list[i].name != NULL; i++) {
/* MaxConn field is signed, RFC 2012 */
if (snmp4_tcp_list[i].entry == TCP_MIB_MAXCONN)
-   seq_printf(seq, " %ld",
-  snmp_fold_field(net->mib.tcp_statistics,
-  snmp4_tcp_list[i].entry));
+   seq_printf(seq, " %ld", buff[i]);
else
-   seq_printf(seq, " %lu",
-  snmp_fold_field(net->mib.tcp_statistics,
-  snmp4_tcp_list[i].entry));
+   seq_printf(seq, " %lu", buff[i]);
}
  
+	memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));

+
+   snmp_get_cpu_field_batch(buff, snmp4_udp_list,
+net->mib.udp_statistics);
seq_puts(seq, "\nUdp:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
-
seq_puts(seq, "\nUdp:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
-   seq_printf(seq, " %lu",
-  snmp_fold_field(net->mib.udp_statistics,
-  snmp4_udp_list[i].entry));
+   seq_printf(seq, " %lu", buff[i]);
+
+   memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
  
  	/* the UDP and UDP-Lite MIBs are the same */

seq_puts(seq, "\nUdpLite:");
+   snmp_get_cpu_field_batch(buff, snmp4_udp_list,
+net->mib.udplite_statistics);
for (i = 0; snmp4_udp_list[i].name != 

[PATCH/REBASED] usb: chipidea: Properly mark little endian descriptors

2016-09-13 Thread Stephen Boyd
The DMA descriptors are little endian, and we do a pretty good
job of handling them with the proper le32_to_cpu() markings, but
we don't actually mark them as __le32. This means checkers like
sparse can't easily find new bugs. Let's mark the members of
structures properly and fix the few places where we're missing
conversions.

Cc: Peter Chen 
Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---

Peter Chen wrote:
>
> I am afraid I can't apply for testing
> 
> Applying: usb: chipidea: Properly mark little endian descriptors
> fatal: sha1 information is lacking or useless
> (drivers/usb/chipidea/udc.c).
> error: could not build fake ancestor
> Patch failed at 0001 usb: chipidea: Properly mark little endian
> descriptors
> The copy of the patch that failed is found in: .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
> 
> Would you please rebase my ci-for-usb-next branch?

Sure no problem. Maybe you shouldn't specify a 3 way merge so that
it attempts to apply without building a fake ancestor? Anyway, here
it is.

 drivers/usb/chipidea/udc.c |  6 +++---
 drivers/usb/chipidea/udc.h | 12 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 661f43fe0f9e..a9b07befd398 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -365,7 +365,7 @@ static int add_td_to_list(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq,
if (hwreq->req.length == 0
|| hwreq->req.length % hwep->ep.maxpacket)
mul++;
-   node->ptr->token |= mul << __ffs(TD_MULTO);
+   node->ptr->token |= cpu_to_le32(mul << __ffs(TD_MULTO));
}
 
temp = (u32) (hwreq->req.dma + hwreq->req.actual);
@@ -504,7 +504,7 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, struct 
ci_hw_req *hwreq)
if (hwreq->req.length == 0
|| hwreq->req.length % hwep->ep.maxpacket)
mul++;
-   hwep->qh.ptr->cap |= mul << __ffs(QH_MULT);
+   hwep->qh.ptr->cap |= cpu_to_le32(mul << __ffs(QH_MULT));
}
 
ret = hw_ep_prime(ci, hwep->num, hwep->dir,
@@ -529,7 +529,7 @@ static void free_pending_td(struct ci_hw_ep *hwep)
 static int reprime_dtd(struct ci_hdrc *ci, struct ci_hw_ep *hwep,
   struct td_node *node)
 {
-   hwep->qh.ptr->td.next = node->dma;
+   hwep->qh.ptr->td.next = cpu_to_le32(node->dma);
hwep->qh.ptr->td.token &=
cpu_to_le32(~(TD_STATUS_HALTED | TD_STATUS_ACTIVE));
 
diff --git a/drivers/usb/chipidea/udc.h b/drivers/usb/chipidea/udc.h
index e66df0020bd4..2ecd1174d66c 100644
--- a/drivers/usb/chipidea/udc.h
+++ b/drivers/usb/chipidea/udc.h
@@ -22,11 +22,11 @@
 /* DMA layout of transfer descriptors */
 struct ci_hw_td {
/* 0 */
-   u32 next;
+   __le32 next;
 #define TD_TERMINATE  BIT(0)
 #define TD_ADDR_MASK  (0xFFEUL << 5)
/* 1 */
-   u32 token;
+   __le32 token;
 #define TD_STATUS (0x00FFUL <<  0)
 #define TD_STATUS_TR_ERR  BIT(3)
 #define TD_STATUS_DT_ERR  BIT(5)
@@ -36,7 +36,7 @@ struct ci_hw_td {
 #define TD_IOCBIT(15)
 #define TD_TOTAL_BYTES(0x7FFFUL << 16)
/* 2 */
-   u32 page[5];
+   __le32 page[5];
 #define TD_CURR_OFFSET(0x0FFFUL <<  0)
 #define TD_FRAME_NUM  (0x07FFUL <<  0)
 #define TD_RESERVED_MASK  (0x0FFFUL <<  0)
@@ -45,18 +45,18 @@ struct ci_hw_td {
 /* DMA layout of queue heads */
 struct ci_hw_qh {
/* 0 */
-   u32 cap;
+   __le32 cap;
 #define QH_IOSBIT(15)
 #define QH_MAX_PKT(0x07FFUL << 16)
 #define QH_ZLTBIT(29)
 #define QH_MULT   (0x0003UL << 30)
 #define QH_ISO_MULT(x) ((x >> 11) & 0x03)
/* 1 */
-   u32 curr;
+   __le32 curr;
/* 2 - 8 */
struct ci_hw_td td;
/* 9 */
-   u32 RESERVED;
+   __le32 RESERVED;
struct usb_ctrlrequest   setup;
 } __attribute__ ((packed, aligned(4)));
 
-- 
2.9.0.rc2.8.ga28705d



Re: [PATCH v20 00/20] perf, tools: Add support for PMU events in JSON format

2016-09-13 Thread Ingo Molnar

* Michael Ellerman  wrote:

> Jiri Olsa  writes:
> 
> > On Wed, Aug 31, 2016 at 09:15:30AM -0700, Andi Kleen wrote:
> >> > > 
> >> > > > 
> >> > > > I've already made some changes in pmu-events/* to support
> >> > > > this hierarchy to see how bad the change would be.. and
> >> > > > it's not that bad ;-)
> >> > > 
> >> > > Everything has to be automated, please no manual changes.
> >> > 
> >> > sure
> >> > 
> >> > so, if you're ok with the layout, how do you want to proceed further?
> >> 
> >> If the split version is acceptable it's fine for me to merge it.
> >> 
> >> I'll add split-json to my scripting, so the next update would
> >> be split too.
> >
> > ook, I'll wait for patches then
> 
> Who are you waiting for patches from?
> 
> Would be great if this could go in for 4.9 still.

No objections from me - the latest bits were good:

  Acked-by: Ingo Molnar 

Thanks,

Ingo


Re: [PATCH v8 8/9] drm/mediatek: update DSI sub driver flow

2016-09-13 Thread CK Hu
Hi, YT:

On Mon, 2016-09-12 at 20:01 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module and MIPI TX module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
> 
> Signed-off-by: shaoming chen 
> Signed-off-by: YT Shen 
> ---
>  

[snip...]

>  
> +static void mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi)
> +{
> + s32 ret = 0;
> + unsigned long timeout = msecs_to_jiffies(500);
> +
> + mtk_dsi_irq_data_clear(dsi, VM_DONE_INT_FLAG);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +dsi->irq_data & VM_DONE_INT_FLAG,
> +timeout);
> + if (ret == 0) {
> + dev_info(dsi->dev, "dsi wait engine idle timeout\n");
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }

I think you should replace this event-waiting with
mtk_dsi_wait_for_irq_done(). And this is a reason for moving
mtk_dsi_wait_for_irq_done() to the patch of irq control.

> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>   if (WARN_ON(dsi->refcount == 0))
> @@ -528,6 +574,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>   if (--dsi->refcount != 0)
>   return;
>  
> + mtk_dsi_switch_to_cmd_mode(dsi);
> +
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel)) {
> + DRM_ERROR("failed to unprepare the panel\n");
> + return;
> + }
> + }

I think drm_panel_unprepare should be placed after dsi is disabled. So
move this part after calling mtk_dsi_poweroff() in
mtk_output_dsi_disable().

> +
> + mtk_dsi_reset_engine(dsi);
> +
>   mtk_dsi_lane0_ulp_mode_enter(dsi);
>   mtk_dsi_clk_ulp_mode_enter(dsi);
>  
> @@ -546,29 +603,37 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>   if (dsi->enabled)
>   return;
>  
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
>   ret = mtk_dsi_poweron(dsi);
>   if (ret < 0) {
>   DRM_ERROR("failed to power on dsi\n");
>   return;
>   }
>  
> + usleep_range(2, 21000);
> +
>   mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_phy_timconfig(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>  
> + mtk_dsi_enable(dsi);
>   mtk_dsi_clk_ulp_mode_leave(dsi);
>   mtk_dsi_lane0_ulp_mode_leave(dsi);
>   mtk_dsi_clk_hs_mode(dsi, 0);
> - mtk_dsi_set_mode(dsi);
>  
> - mtk_dsi_ps_control_vact(dsi);
> - mtk_dsi_config_vdo_timing(dsi);
> - mtk_dsi_set_interrupt_enable(dsi);
> + if (dsi->panel) {
> + if (drm_panel_prepare(dsi->panel)) {
> + DRM_ERROR("failed to prepare the panel\n");
> + return;
> + }
> +
> + if (drm_panel_enable(dsi->panel)) {
> + DRM_ERROR("failed to enable the panel\n");
> + return;
> + }
> + }

I think drm_panel_prepare() should be called before DSI is enabled and
drm_panel_enable() should be called after DSI is enabled. But you may
encounter the problem that panel need transfer data when prepare and you
can refer to [1].

[1]
http://lxr.free-electrons.com/source/drivers/gpu/drm/exynos/exynos_drm_dsi.c#L1431

>  
>   mtk_dsi_set_mode(dsi);
>   mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -590,6 +655,7 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
>   }
>   }
>  
> + mtk_dsi_stop(dsi);
>   mtk_dsi_poweroff(dsi);
>  
>   dsi->enabled = false;
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c 
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index 108d31a..34e95c6 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -177,7 +177,9 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>  
>   dev_dbg(mipi_tx->dev, "prepare: %u Hz\n", mipi_tx->data_rate);
>  
> - if (mipi_tx->data_rate >= 5) {
> + if (mipi_tx->data_rate > 125000) {
> + return -EINVAL;
> + } else if (mipi_tx->data_rate >= 5) {

What is the relationship of this part and "DSI driver flow"? Would this
be an independent patch?

>   txdiv = 1;
>   txdiv0 = 0;
>   txdiv1 = 0;
> @@ -201,6 +203,10 @@ static int mtk_mipi_tx_pll_prepare(struct clk_hw *hw)
>   return -EINVAL;
>   }
>  
> + 

RE: [PATCH 1/3] PCI: Xilinx NWL PCIe: Expanding PCIe core errors and printing event occurred.

2016-09-13 Thread Bharat Kumar Gogada
> Hi Bharat,
> 
> On Tue, Aug 30, 2016 at 04:09:16PM +0530, Bharat Kumar Gogada wrote:
> > The current driver prints pcie core error, for all core events.
> > Instead of just printing PCIe core error, now adding prints to show
> > individual core events occurred.
> >
> > Signed-off-by: Bharat Kumar Gogada 
> > ---
> >  drivers/pci/host/pcie-xilinx-nwl.c | 48
> > +++---
> >  1 file changed, 40 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/pci/host/pcie-xilinx-nwl.c
> > b/drivers/pci/host/pcie-xilinx-nwl.c
> > index 3479d30..86c1834 100644
> > --- a/drivers/pci/host/pcie-xilinx-nwl.c
> > +++ b/drivers/pci/host/pcie-xilinx-nwl.c
> > @@ -85,10 +85,15 @@
> >  #define MSGF_MISC_SR_MASTER_ERRBIT(5)
> >  #define MSGF_MISC_SR_I_ADDR_ERRBIT(6)
> >  #define MSGF_MISC_SR_E_ADDR_ERRBIT(7)
> > -#define MSGF_MISC_SR_UR_DETECT  BIT(20)
> > -
> > -#define MSGF_MISC_SR_PCIE_CORE GENMASK(18, 16)
> > -#define MSGF_MISC_SR_PCIE_CORE_ERR GENMASK(31, 22)
> > +#define MSGF_MISC_SR_FATAL_AER BIT(16)
> > +#define MSGF_MISC_SR_NON_FATAL_AER BIT(17)
> > +#define MSGF_MISC_SR_CORR_AER  BIT(18)
> > +#define MSGF_MISC_SR_UR_DETECT BIT(20)
> > +#define MSGF_MISC_SR_NON_FATAL_DEV BIT(22)
> > +#define MSGF_MISC_SR_FATAL_DEV BIT(23)
> > +#define MSGF_MISC_SR_LINK_DOWN BIT(24)
> > +#define MSGF_MSIC_SR_LINK_AUTO_BWIDTH  BIT(25)
> > +#define MSGF_MSIC_SR_LINK_BWIDTH   BIT(26)
> >
> >  #define MSGF_MISC_SR_MASKALL
>   (MSGF_MISC_SR_RXMSG_AVAIL | \
> > MSGF_MISC_SR_RXMSG_OVER | \
> > @@ -96,9 +101,15 @@
> > MSGF_MISC_SR_MASTER_ERR | \
> > MSGF_MISC_SR_I_ADDR_ERR | \
> > MSGF_MISC_SR_E_ADDR_ERR | \
> > +   MSGF_MISC_SR_FATAL_AER | \
> > +   MSGF_MISC_SR_NON_FATAL_AER | \
> > +   MSGF_MISC_SR_CORR_AER | \
> > MSGF_MISC_SR_UR_DETECT | \
> > -   MSGF_MISC_SR_PCIE_CORE | \
> > -   MSGF_MISC_SR_PCIE_CORE_ERR)
> > +   MSGF_MISC_SR_NON_FATAL_DEV | \
> > +   MSGF_MISC_SR_FATAL_DEV | \
> > +   MSGF_MISC_SR_LINK_DOWN | \
> > +   MSGF_MSIC_SR_LINK_AUTO_BWIDTH
> | \
> > +   MSGF_MSIC_SR_LINK_BWIDTH)
> >
> >  /* Legacy interrupt status mask bits */
> >  #define MSGF_LEG_SR_INTA   BIT(0)
> > @@ -291,8 +302,29 @@ static irqreturn_t nwl_pcie_misc_handler(int irq, void
> *data)
> > dev_err(pcie->dev,
> > "In Misc Egress address translation error\n");
> >
> > -   if (misc_stat & MSGF_MISC_SR_PCIE_CORE_ERR)
> > -   dev_err(pcie->dev, "PCIe Core error\n");
> > +   if (misc_stat & MSGF_MISC_SR_FATAL_AER)
> > +   dev_err(pcie->dev, "Fatal Error in AER Capability\n");
> > +
> > +   if (misc_stat & MSGF_MISC_SR_NON_FATAL_AER)
> > +   dev_err(pcie->dev, "Non-Fatal Error in AER Capability\n");
> > +
> > +   if (misc_stat & MSGF_MISC_SR_CORR_AER)
> > +   dev_err(pcie->dev, "Correctable Error in AER Capability\n");
> > +
> > +   if (misc_stat & MSGF_MISC_SR_UR_DETECT)
> > +   dev_err(pcie->dev, "Unsupported request Detected\n");
> > +
> > +   if (misc_stat & MSGF_MISC_SR_NON_FATAL_DEV)
> > +   dev_err(pcie->dev, "Non-Fatal Error Detected\n");
> > +
> > +   if (misc_stat & MSGF_MISC_SR_FATAL_DEV)
> > +   dev_err(pcie->dev, "Fatal Error Detected\n");
> > +
> > +   if (misc_stat & MSGF_MSIC_SR_LINK_AUTO_BWIDTH)
> > +   dev_info(pcie->dev, "Link Autonomous Bandwidth Management
> Status
> > +bit set\n");
> > +
> > +   if (misc_stat & MSGF_MSIC_SR_LINK_BWIDTH)
> > +   dev_info(pcie->dev, "Link Bandwidth Management Status bit
> set\n");
> >
> > /* Clear misc interrupt status */
> > nwl_bridge_writel(pcie, misc_stat, MSGF_MISC_STATUS);
> 
> This patch looks fine, but looking at the code as a whole, I have a question. 
>  You
> basically have this:
> 
>   misc_stat = nwl_bridge_readl(pcie, MSGF_MISC_STATUS) &
> MSGF_MISC_SR_MASKALL;
>   if (!misc_stat)
> return IRQ_NONE;
>   ...
>   nwl_bridge_writel(pcie, misc_stat, MSGF_MISC_STATUS);
> 
> The masking with MSGF_MISC_SR_MASKALL seems wrong.  Let's say
> MSGF_MISC_STATUS had some other bit set, e.g., BIT(31), indicating some yet-
> unsupported interrupt cause.  BIT(31) is not in MSGF_MISC_SR_MASKALL, so we
> return IRQ_NONE without clearing the interrupt bit in MSGF_MISC_STATUS.
> Won't that cause an interrupt storm where the interrupt is continually re-
> asserted because we never clear it?
> 
> It seems like it would make more 

Re: [PATCH] xen: consolidate swiotbl_xen dma_ops

2016-09-13 Thread Christoph Hellwig
On Tue, Sep 13, 2016 at 08:37:27PM +0200, Ingo Molnar wrote:
> I can be passive-aggressive too, so:
> 
>   NAKed-by: Ingo Molnar 
> 
> If the ugliness that makes the patch much harder to review than it should be 
> is 

How about not beeing a dick?  If you ask _nicely_ to respin it anyway
I'd be happy to do it, but if you get up on a bad foot please let it out
on someone else.


RE: [PATCH 3/3] PCI: Xilinx NWL PCIe: Fix Error for multi function device for legacy interrupts.

2016-09-13 Thread Bharat Kumar Gogada
> [+cc Ley Foon (altera), Thomas (aardvark), Kishon (dra7xx), Murali (keystone)]
> 
> On Tue, Sep 13, 2016 at 10:05:11AM -0500, Bjorn Helgaas wrote:
> > On Tue, Sep 13, 2016 at 08:41:28AM +0100, Marc Zyngier wrote:
> > > On 12/09/16 23:02, Bjorn Helgaas wrote:
> > > > On Thu, Sep 01, 2016 at 05:19:55AM +, Bharat Kumar Gogada wrote:
> > > >>> Hi Bharat,
> > >  @@ -561,7 +561,7 @@ static int
> > >  nwl_pcie_init_irq_domain(struct nwl_pcie
> > > >>> *pcie)
> > >  }
> > > 
> > >  pcie->legacy_irq_domain =
> irq_domain_add_linear(legacy_intc_node,
> > >  -   INTX_NUM,
> > >  +
> > >  + INTX_NUM + 1,
> > >  
> > >  _domain_ops,
> > >  pcie);
> > > >>>
> > > >>> This feels like the wrong thing to do. You have INTX_NUM
> > > >>> irqs, so the domain allocation should reflect this. On the
> > > >>> other hand, the way the driver currently deals with mappings
> > > >>> is quite broken (consistently adding 1 to
> > > > the HW interrupt).
> > > >>>
> > > >> Hi Marc,
> > > >>
> > > >> Without above change I get following crash in kernel while booting.
> > > >>
> > > >> [2.441684] error: hwirq 0x4 is too large for dummy
> > > >>
> > > >> [2.441694] [ cut here ]
> > > >>
> > > >> [2.441698] WARNING: at kernel/irq/irqdomain.c:344
> > > >>
> > > >> [2.441702] Modules linked in:
> > > >>
> > > >> [2.441706]
> > > >>
> > > >> [2.441714] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.4.0 #8
> > > >>
> > > >> [2.441718] Hardware name: xlnx,zynqmp (DT)
> > > >>
> > > >> [2.441723] task: ffc071886b80 ti: ffc071888000 task.ti:
> > > > ffc071888000
> > > >>
> > > >> [2.441732] PC is at irq_domain_associate+0x138/0x1c0
> > > >>
> > > >> [2.441738] LR is at irq_domain_associate+0x138/0x1c0
> > > >>
> > > >> In kernel/irq/irqdomain.c function irq_domain_associate
> > > >>
> > > >> if (WARN(hwirq >= domain->hwirq_max,
> > > >>  "error: hwirq 0x%x is too large for %s\n",
> > > >> (int)hwirq, domain-
> > >  name))
> > > >> return -EINVAL;
> > > >>
> > > >> Here the hwirq and hwirq_max are equal to 4 without the above
> > > >> condition
> > > > (INTX_NUM + 1) due to which crash is coming.
> > > >> This is happening as the legacy interrupts are starting from 1 
> > > >> (INTA).
> > > >
> > > > I understood that. I'm still persisting in saying that you have the 
> > > > wrong
> fix.
> > > >
> > > > Your domain should always allocate many interrupts as you have
> > > > interrupt sources. These interrupts (hwirq) should be numbered
> > > > from 0 to (n-
> > > >>> 1).
> > > 
> > >  Agreed, but here comes the problem the hwirq for legacy
> > >  interrupts will start at 0x1 to 0x4 (INTA to INTD) and these
> > >  values are as per PCIe specification for legacy interrupts. So
> > >  these cannot be numbered from 0. So when 0x4 (INTD) for a
> > >  multi-function device comes the crash occurs.
> > > >>>
> > > >>> So who provides this hwirq? Who calls irq_domain_associate()
> > > >>> with hwirq set to 4?
> > > >>>
> > > >> PCIe subsystem invokes pcibios_add_device function in
> arch/arm64/kernel/pci.c for every pci device.
> > > >> The purpose of this function is to assign dev->irq using
> of_irq_parse_and_map_pci.
> > > >> of_irq_parse_and_map_pci invokes of_irq_parse_pci where it reads
> > > >> PCI_INTERRUPT_PIN from configuration space and saves it in parameter
> of struct of_phandle_args.
> > > >> This structure is passed to irq_create_of_mapping where it invokes
> irq_create_fwspec_mapping.
> > > >> irq_create_fwspec_mapping invokes irq_domain_translate and gets
> > > >> hwirq, here the above saved PCI_INTERRUPT_PIN value is assigned to
> hwirq (*hwirq = fwspec->param[0]).
> > > >> And then using this hwirq irq_create_mapping -> irq_domain_associate
> were invoked and mapping is created for virtual irq with this hwirq.
> > > >> So for any end point PCI_INTERRUPT_PIN value starts from 0x1 to 0x4
> and so hwirq starts from 0x1 to 0x4.
> > > >>
> > > >> So the values are more generic w.r.t to protocol, that's why hwirq will
> range from 0x1 to 0x4.
> > > >> And then if you check pcie-altera.c they are doing this adding one in 
> > > >> their
> handler and while creating legacy domain.
> > > >
> > > > Is this resolved yet?  Marc, are you happy, or should we iterate
> > > > on this again?
> > >
> > > Ah, sorry to have dropped the ball on this patch.
> >
> > No problem, I wasn't making forward progress anyway.
> >
> > > I guess that given that the infrastructure 

Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

2016-09-13 Thread Kishon Vijay Abraham I


On Saturday 10 September 2016 05:48 PM, Kishon Vijay Abraham I wrote:
> 
> On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
>> The high-speed phy on qcom SoCs is controlled via the ULPI
>> viewport.
>>
>> Cc: Kishon Vijay Abraham I 
>> Cc: 
>> Signed-off-by: Stephen Boyd 
> 
> merged this and the previous patch to linux-phy.

since there are pending discussions, I'll drop this patch for now.

Thanks
Kishon
> 
> Thanks
> Kishon
> 
>> ---
>>  .../devicetree/bindings/phy/qcom,usb-hs-phy.txt|  83 ++
>>  drivers/phy/Kconfig|   8 +
>>  drivers/phy/Makefile   |   1 +
>>  drivers/phy/phy-qcom-usb-hs.c  | 289 
>> +
>>  4 files changed, 381 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>>  create mode 100644 drivers/phy/phy-qcom-usb-hs.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt 
>> b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> new file mode 100644
>> index ..d7eacd63d06b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt
>> @@ -0,0 +1,83 @@
>> +Qualcomm's USB HS PHY
>> +
>> +PROPERTIES
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "qcom,usb-hs-phy" and more specifically one 
>> of the
>> +following:
>> +
>> +"qcom,usb-hs-phy-apq8064"
>> +"qcom,usb-hs-phy-msm8916"
>> +"qcom,usb-hs-phy-msm8974"
>> +
>> +- #phy-cells:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain 0
>> +
>> +- clocks:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain clock specifier for the reference and sleep
>> +clocks
>> +
>> +- clock-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "ref" and "sleep" for the reference and sleep
>> +clocks respectively
>> +
>> +- resets:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the phy and POR resets
>> +
>> +- reset-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain "phy" and "por" for the phy and POR resets
>> +respectively
>> +
>> +- v3p3-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain a reference to the 3.3V supply
>> +
>> +- v1p8-supply:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain a reference to the 1.8V supply
>> +
>> +- extcon:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain the vbus and ID extcons in the first and 
>> second
>> +cells respectively
>> +
>> +- qcom,init-seq:
>> +Usage: optional
>> +Value type: 
>> +Definition: Should contain a sequence of ULPI register and address 
>> pairs to
>> +program into the ULPI_EXT_VENDOR_SPECIFIC area. This is 
>> related
>> +to Device Mode Eye Diagram test.
>> +
>> +EXAMPLE
>> +
>> +otg: usb-controller {
>> +ulpi {
>> +phy {
>> +compatible = "qcom,usb-hs-phy-msm8974", 
>> "qcom,usb-hs-phy";
>> +#phy-cells = <0>;
>> +clocks = <_board>, < GCC_USB2A_PHY_SLEEP_CLK>;
>> +clock-names = "ref", "sleep";
>> +resets = < GCC_USB2A_PHY_BCR>, < 0>;
>> +reset-names = "phy", "por";
>> +v3p3-supply = <_l24>;
>> +v1p8-supply = <_l6>;
>> +extcon = <>, <_id>;
>> +qcom,init-seq = /bits/ 8 <0x81 0x63>;
>> +};
>> +};
>> +};
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 830c443eeabf..ee0ec021a98c 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -417,6 +417,14 @@ config PHY_QCOM_UFS
>>  help
>>Support for UFS PHY on QCOM chipsets.
>>  
>> +config PHY_QCOM_USB_HS
>> +tristate "Qualcomm USB HS PHY module"
>> +depends on USB_ULPI_BUS
>> +select GENERIC_PHY
>> +help
>> +  Support for the USB high-speed ULPI compliant phy on Qualcomm
>> +  chipsets.
>> +
>>  config PHY_QCOM_USB_HSIC
>>  tristate "Qualcomm USB HSIC ULPI PHY module"
>>  depends on USB_ULPI_BUS
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index 5422f543d17d..31c84faa07fa 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_STIH41X_USB)  += 
>> phy-stih41x-usb.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-20nm.o
>>  obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-14nm.o
>> +obj-$(CONFIG_PHY_QCOM_USB_HS)   += 

RE: [PATCH 1/3] PCI: Xilinx NWL PCIe: Expanding PCIe core errors and printing event occurred.

2016-09-13 Thread Bharat Kumar Gogada
> On Tue, Aug 30, 2016 at 04:09:16PM +0530, Bharat Kumar Gogada wrote:
> > The current driver prints pcie core error, for all core events.
> > Instead of just printing PCIe core error, now adding prints to show
> > individual core events occurred.
> >
> > Signed-off-by: Bharat Kumar Gogada 
> 
> I applied the first two patches to pci/host-xilinx for v4.9, thanks!
> 
> I'd like to work on the third one a little more, as I mentioned in my 
> response to
> it.
> 
Thanks Bjorn, yes I agree that third one needs better way of handling.


[RFC PATCH 01/11] pci: endpoint: add EP core layer to enable EP controller and EP functions

2016-09-13 Thread Kishon Vijay Abraham I
Introduce a new EP core layer in order to support endpoint functions
in linux kernel. This comprises of EPC library
(Endpoint Controller Library) and EPF library (Endpoint
Function Library). EPC library implements functions that is specific
to an endpoint controller and EPF library implements functions
that is specific to an endpoint function.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/Makefile|1 +
 drivers/pci/Kconfig |1 +
 drivers/pci/endpoint/Kconfig|   21 ++
 drivers/pci/endpoint/Makefile   |5 +
 drivers/pci/endpoint/pci-epc-core.c |  389 +++
 drivers/pci/endpoint/pci-epf-core.c |  338 ++
 include/linux/mod_devicetable.h |   10 +
 include/linux/pci-epc.h |  100 +
 include/linux/pci-epf.h |  159 ++
 9 files changed, 1024 insertions(+)
 create mode 100644 drivers/pci/endpoint/Kconfig
 create mode 100644 drivers/pci/endpoint/Makefile
 create mode 100644 drivers/pci/endpoint/pci-epc-core.c
 create mode 100644 drivers/pci/endpoint/pci-epf-core.c
 create mode 100644 include/linux/pci-epc.h
 create mode 100644 include/linux/pci-epf.h

diff --git a/drivers/Makefile b/drivers/Makefile
index 53abb4a..8c070ad 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy/
 obj-$(CONFIG_PINCTRL)  += pinctrl/
 obj-$(CONFIG_GPIOLIB)  += gpio/
 obj-y  += pwm/
+obj-$(CONFIG_PCI_ENDPOINT) += pci/endpoint/
 obj-$(CONFIG_PCI)  += pci/
 obj-$(CONFIG_PARISC)   += parisc/
 obj-$(CONFIG_RAPIDIO)  += rapidio/
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 67f9916..5f116a6 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -133,3 +133,4 @@ config PCI_HYPERV
 
 source "drivers/pci/hotplug/Kconfig"
 source "drivers/pci/host/Kconfig"
+source "drivers/pci/endpoint/Kconfig"
diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
new file mode 100644
index 000..a6d827c
--- /dev/null
+++ b/drivers/pci/endpoint/Kconfig
@@ -0,0 +1,21 @@
+#
+# PCI Endpoint Support
+#
+
+menu "PCI Endpoint"
+
+config PCI_ENDPOINT
+   tristate "PCI Endpoint Support"
+   help
+  Enable this configuration option to support configurable PCI
+  endpoint. This should be enabled if the platform has a PCI
+  controller that can operate in endpoint mode.
+
+  Enabling this option will build the endpoint library, which
+  includes endpoint controller library and endpoint function
+  library.
+
+  If in doubt, say "N" to disable Endpoint support.
+
+endmenu
+
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
new file mode 100644
index 000..dbc5517
--- /dev/null
+++ b/drivers/pci/endpoint/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for PCI Endpoint Support
+#
+
+obj-$(CONFIG_PCI_ENDPOINT) := pci-epc-core.o pci-epf-core.o
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
new file mode 100644
index 000..003d2ee
--- /dev/null
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -0,0 +1,389 @@
+/**
+ * pci-epc-core.c - PCI Endpoint *Controller* (EPC) library
+ *
+ * Copyright (C) 2016 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct class *pci_epc_class;
+
+static void devm_pci_epc_release(struct device *dev, void *res)
+{
+   struct pci_epc *epc = *(struct pci_epc **)res;
+
+   pci_epc_destroy(epc);
+}
+
+static int devm_pci_epc_match(struct device *dev, void *res, void *match_data)
+{
+   struct pci_epc **epc = res;
+
+   return *epc == match_data;
+}
+
+/**
+ * pci_epc_unbind_epf() - unbind the endpoint function and endpoint controller
+ * @epf: the endpoint function which has requested for unbinding
+ *
+ * Invoke to unbind the endpoint function and endpoint controller
+ */
+void pci_epc_unbind_epf(struct pci_epf *epf)
+{
+   struct pci_epc *epc = epf->epc;
+
+   pci_epf_unbind(epf);
+   module_put(epc->ops->owner);
+   epf->epc = NULL;
+   epc->epf = NULL;
+}
+EXPORT_SYMBOL_GPL(pci_epc_unbind_epf);
+
+/**
+ * pci_epc_bind_epf() - bind the 

[RFC PATCH 09/11] misc: add a new host side PCI endpoint test driver

2016-09-13 Thread Kishon Vijay Abraham I
Add PCI endpoint test driver that can verify base address
register and legacy interrupt. (TODO: buffer tests and
MSI interrupt). The corresponding pci-epf-test function driver
should be used on the EP side.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/misc/Kconfig |7 +
 drivers/misc/Makefile|1 +
 drivers/misc/pci_endpoint_test.c |  291 ++
 3 files changed, 299 insertions(+)
 create mode 100644 drivers/misc/pci_endpoint_test.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index d002528..c578f97 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -794,6 +794,13 @@ config PANEL_BOOT_MESSAGE
  An empty message will only clear the display at driver init time. Any 
other
  printf()-formatted message is valid with newline and escape codes.
 
+config PCI_ENDPOINT_TEST
+   depends on PCI
+   tristate "PCI Endpoint Test driver"
+   ---help---
+   Enable this configuration option to enable the host side test driver
+   for PCI Endpoint.
+
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
 source "drivers/misc/cb710/Kconfig"
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index fb32516..fe6ff69 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_ECHO)+= echo/
 obj-$(CONFIG_VEXPRESS_SYSCFG)  += vexpress-syscfg.o
 obj-$(CONFIG_CXL_BASE) += cxl/
 obj-$(CONFIG_PANEL) += panel.o
+obj-$(CONFIG_PCI_ENDPOINT_TEST)+= pci_endpoint_test.o
 
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_core.o
 lkdtm-$(CONFIG_LKDTM)  += lkdtm_bugs.o
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
new file mode 100644
index 000..221a2ce
--- /dev/null
+++ b/drivers/misc/pci_endpoint_test.c
@@ -0,0 +1,291 @@
+/**
+ * ep_f_test.c - Host side test driver to test endpoint functionality
+ *
+ * Copyright (C) 2016 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRV_MODULE_NAME"pci-endpoint-test"
+
+#define PCI_ENDPOINT_TEST_COMMAND  0x0
+#define COMMAND_RESET  BIT(0)
+#define COMMAND_RAISE_IRQ  BIT(1)
+#define COMMAND_COPY   BIT(2)
+
+#define PCI_ENDPOINT_TEST_STATUS   0x4
+#define STATUS_INITIALIZED BIT(0)
+#define STATUS_COPY_PROGRESS   BIT(1)
+#define STATUS_COPY_DONE   BIT(2)
+#define STATUS_IRQ_RAISED  BIT(3)
+#define STATUS_SOURCE_ADDR_INVALID BIT(4)
+#define STATUS_DEST_ADDR_INVALID   BIT(5)
+
+#define PCI_ENDPOINT_TEST_SRC_ADDR 0x8
+#define PCI_ENDPOINT_TEST_DST_ADDR 0x10
+
+enum pci_barno {
+   BAR_0,
+   BAR_1,
+   BAR_2,
+   BAR_3,
+   BAR_4,
+   BAR_5,
+};
+
+struct pci_endpoint_test {
+   struct pci_dev  *pdev;
+   void*base;
+   void*bar[5];
+   struct completion irq_raised;
+};
+
+static char *result[] = { "NOT OKAY", "OKAY" };
+static int bar_size[] = { 512, 1024, 16384, 131072, 1048576 };
+
+static inline u32 pci_endpoint_test_readl(struct pci_endpoint_test *test,
+ u32 offset)
+{
+   return readl(test->base + offset);
+}
+
+static inline void pci_endpoint_test_writel(struct pci_endpoint_test *test,
+   u32 offset, u32 value)
+{
+   writel(value, test->base + offset);
+}
+
+static inline u32 pci_endpoint_test_bar_readl(struct pci_endpoint_test *test,
+ int bar, int offset)
+{
+   return readl(test->bar[bar] + offset);
+}
+
+static inline void pci_endpoint_test_bar_writel(struct pci_endpoint_test *test,
+   int bar, u32 offset, u32 value)
+{
+   writel(value, test->bar[bar] + offset);
+}
+
+static irqreturn_t pci_endpoint_test_irqhandler(int irq, void *dev_id)
+{
+   struct pci_endpoint_test *test = dev_id;
+   u32 reg;
+
+   reg = pci_endpoint_test_readl(test, PCI_ENDPOINT_TEST_STATUS);
+   if (reg & STATUS_IRQ_RAISED) {
+   complete(>irq_raised);
+   reg &= 

[RFC PATCH 00/11] pci: support for configurable PCI endpoint

2016-09-13 Thread Kishon Vijay Abraham I
This patch series
*) adds PCI endpoint core layer
*) modifies designware/dra7xx driver to be configured in EP mode
*) adds a PCI endpoint *test* function driver

Known Limitation:
*) Does not support multi-function devices

TODO:
*) access buffers in RC
*) raise MSI interrupts
*) Enable user space control for the RC side PCI driver
*) Adapt all other users of designware to use the new design (only
   dra7xx has been adapted)

HOW TO:

ON THE EP SIDE:
***

/* EP function is configured using configfs */
# mount -t configfs none /sys/kernel/config

/* PCI EP core layer creates "pci_ep" entry in configfs */
# cd /sys/kernel/config/pci_ep/

/*
 * This is the 1st step in creating an endpoint function. This
 * creates the endpoint function device *instance*. The string
 * before the . suffix will identify the driver this
 * EP function will bind to.
 * Just pci_epf_test is also valid. The . suffix is used
 * if there are multiple PCI controllers and all of them wants
 * to use the same function.
 */
# mkdir pci_epf_test.0

/*
 * When the above command is given, the function device will
 * also be bound to a function driver. To find the list of
 * function drivers available in the system, use the following
 * command. To create a new driver, the following can be referred
 * drivers/pci/endpoint/functions/pci-epf-test.c
 */
# ls /sys/bus/pci-epf/drivers
pci_epf_test

/* Now configure the endpoint function */
# cd pci_epf_test.0

/* These are the fields that can be configured */
# ls
baseclass_codefunction  revid vendorid
cache_line_size   interrupt_pin subclass_code
deviceid  peripheralsubsys_id
epc   progif_code   subsys_vendor_id

/* The function driver will populate these fields with default values */
# cat vendorid 
0x

# cat interrupt_pin 
0x0001

/* The user can configure any of these fields */
# echo 0x104c > vendorid

/*
 * Next is binding this function driver to the controller driver. In
 * order to find the possible controller drivers that this function
 * driver can be bound to, the following sysfs entry can be used
 */
# ls /sys/class/pci_epc/
5100.pci

/* Now bind the function driver to the controller driver */
# echo "5100.pcie" > epc
[  494.743487] dra7-pcie 5100.pcie: no free inbound window
[  494.749367] pci_epf_test pci_epf_test.0: failed to set BAR4
[  494.755238] dra7-pcie 5100.pcie: no free inbound window
[  494.761451] pci_epf_test pci_epf_test.0: failed to set BAR5

/*
 * the above error messages are due to non availability of free
 * inbound windows. So the function drivers in dra7xx can use
 * only 4 (BAR0..BAR3) BARs
 */

/** PCI endpoint is configured **/

ON THE HOST SIDE:
*
# modprobe pci_endpoint_test
[8.197560] ** Testing pci-endpoint-test Device **
[9.056990] Reset: OKAY
[9.059753] BAR1 OKAY
[9.062419] BAR2 OKAY
[9.069506] BAR3 OKAY
[9.071880] BAR4 NOT OKAY
[9.074618] BAR5 NOT OKAY
[9.379257] Legacy IRQ: OKAY
[9.382281] ** End Test **

/*
 * Rightnow these tests gets executed as soon as the pci_endpoint_test
 * module gets inserted. These will be modified so that user/user script
 * can control this. Once the functionality for EP to access RC buffer
 * is added, more tests can be added including throughput measurement tests.
 */ 

Kishon Vijay Abraham I (11):
  pci: endpoint: add EP core layer to enable EP controller and EP
functions
  pci: endpoint: introduce configfs entry for configuring EP functions
  Documentation: PCI: guide to use PCI Endpoint Core Layer
  pci: endpoint: functions: add an EP function to test PCI
  pci: rename *host* directory to *controller*
  pci: controller: split designware into *core* and *host*
  pci: controller: designware: Add EP mode support
  pci: controller: dra7xx: Add EP mode support
  misc: add a new host side PCI endpoint test driver
  ARM: dts: DRA7: Modify pcie1 dt node for EP mode
  HACK: pci: controller: dra7xx: disable smart idle

 Documentation/PCI/00-INDEX |5 +
 Documentation/PCI/pci-endpoint.txt |  199 ++
 Documentation/PCI/pci-test.txt |   79 
 .../devicetree/bindings/pci/designware-pcie.txt|   26 +-
 Documentation/devicetree/bindings/pci/ti-pci.txt   |   30 +-
 MAINTAINERS|   50 +--
 arch/arm/boot/dts/dra7.dtsi|   43 +--
 drivers/Makefile   |4 +
 drivers/misc/Kconfig   |7 +
 drivers/misc/Makefile  |1 +
 drivers/misc/pci_endpoint_test.c   |  291 +++
 drivers/pci/Kconfig|3 +-
 drivers/pci/Makefile   |3 -
 drivers/pci/{host => controller}/Kconfig   |  109 

[RFC PATCH 05/11] pci: rename *host* directory to *controller*

2016-09-13 Thread Kishon Vijay Abraham I
No functional change. Renamed the *host* directory present inside
drivers/pci to *controller*. Some of the controllers present in
drivers/pci/host is capable of operating in endpoint mode.
So having these drivers in *host* directory might not be appropriate.
This is in preparation for adding endpoint mode support for some of
controller drivers present here.

Signed-off-by: Kishon Vijay Abraham I 
---
 MAINTAINERS|   50 ++--
 drivers/Makefile   |3 ++
 drivers/pci/Kconfig|2 +-
 drivers/pci/Makefile   |3 --
 drivers/pci/{host => controller}/Kconfig   |   35 +-
 drivers/pci/{host => controller}/Makefile  |0
 drivers/pci/{host => controller}/pci-aardvark.c|0
 drivers/pci/{host => controller}/pci-dra7xx.c  |0
 drivers/pci/{host => controller}/pci-exynos.c  |0
 drivers/pci/{host => controller}/pci-host-common.c |0
 .../pci/{host => controller}/pci-host-generic.c|0
 drivers/pci/{host => controller}/pci-hyperv.c  |0
 drivers/pci/{host => controller}/pci-imx6.c|0
 drivers/pci/{host => controller}/pci-keystone-dw.c |0
 drivers/pci/{host => controller}/pci-keystone.c|0
 drivers/pci/{host => controller}/pci-keystone.h|0
 drivers/pci/{host => controller}/pci-layerscape.c  |0
 drivers/pci/{host => controller}/pci-mvebu.c   |0
 drivers/pci/{host => controller}/pci-rcar-gen2.c   |0
 drivers/pci/{host => controller}/pci-tegra.c   |0
 .../pci/{host => controller}/pci-thunder-ecam.c|0
 drivers/pci/{host => controller}/pci-thunder-pem.c |0
 drivers/pci/{host => controller}/pci-versatile.c   |0
 drivers/pci/{host => controller}/pci-xgene-msi.c   |0
 drivers/pci/{host => controller}/pci-xgene.c   |0
 drivers/pci/{host => controller}/pcie-altera-msi.c |0
 drivers/pci/{host => controller}/pcie-altera.c |0
 drivers/pci/{host => controller}/pcie-armada8k.c   |0
 drivers/pci/{host => controller}/pcie-artpec6.c|0
 .../{host => controller}/pcie-designware-plat.c|0
 drivers/pci/{host => controller}/pcie-designware.c |0
 drivers/pci/{host => controller}/pcie-designware.h |0
 drivers/pci/{host => controller}/pcie-hisi.c   |0
 drivers/pci/{host => controller}/pcie-iproc-bcma.c |0
 drivers/pci/{host => controller}/pcie-iproc-msi.c  |0
 .../pci/{host => controller}/pcie-iproc-platform.c |0
 drivers/pci/{host => controller}/pcie-iproc.c  |0
 drivers/pci/{host => controller}/pcie-iproc.h  |0
 drivers/pci/{host => controller}/pcie-qcom.c   |0
 drivers/pci/{host => controller}/pcie-rcar.c   |0
 drivers/pci/{host => controller}/pcie-spear13xx.c  |0
 drivers/pci/{host => controller}/pcie-xilinx-nwl.c |0
 drivers/pci/{host => controller}/pcie-xilinx.c |0
 43 files changed, 62 insertions(+), 31 deletions(-)
 rename drivers/pci/{host => controller}/Kconfig (93%)
 rename drivers/pci/{host => controller}/Makefile (100%)
 rename drivers/pci/{host => controller}/pci-aardvark.c (100%)
 rename drivers/pci/{host => controller}/pci-dra7xx.c (100%)
 rename drivers/pci/{host => controller}/pci-exynos.c (100%)
 rename drivers/pci/{host => controller}/pci-host-common.c (100%)
 rename drivers/pci/{host => controller}/pci-host-generic.c (100%)
 rename drivers/pci/{host => controller}/pci-hyperv.c (100%)
 rename drivers/pci/{host => controller}/pci-imx6.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone-dw.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.c (100%)
 rename drivers/pci/{host => controller}/pci-keystone.h (100%)
 rename drivers/pci/{host => controller}/pci-layerscape.c (100%)
 rename drivers/pci/{host => controller}/pci-mvebu.c (100%)
 rename drivers/pci/{host => controller}/pci-rcar-gen2.c (100%)
 rename drivers/pci/{host => controller}/pci-tegra.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-ecam.c (100%)
 rename drivers/pci/{host => controller}/pci-thunder-pem.c (100%)
 rename drivers/pci/{host => controller}/pci-versatile.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene-msi.c (100%)
 rename drivers/pci/{host => controller}/pci-xgene.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera-msi.c (100%)
 rename drivers/pci/{host => controller}/pcie-altera.c (100%)
 rename drivers/pci/{host => controller}/pcie-armada8k.c (100%)
 rename drivers/pci/{host => controller}/pcie-artpec6.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware-plat.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware.c (100%)
 rename drivers/pci/{host => controller}/pcie-designware.h (100%)
 rename drivers/pci/{host => controller}/pcie-hisi.c (100%)
 rename drivers/pci/{host => controller}/pcie-iproc-bcma.c (100%)
 rename drivers/pci/{host => 

[RFC PATCH 07/11] pci: controller: designware: Add EP mode support

2016-09-13 Thread Kishon Vijay Abraham I
Add endpoint mode support to designware driver. This uses the
EP Core layer introduced recently to add endpoint mode support.
*Any* function driver can now use this designware device
to achieve the EP functionality.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../devicetree/bindings/pci/designware-pcie.txt|   26 ++-
 drivers/pci/controller/Kconfig |5 +
 drivers/pci/controller/Makefile|1 +
 drivers/pci/controller/pcie-designware-ep.c|  228 
 drivers/pci/controller/pcie-designware.c   |   30 +++
 drivers/pci/controller/pcie-designware.h   |   45 
 6 files changed, 324 insertions(+), 11 deletions(-)
 create mode 100644 drivers/pci/controller/pcie-designware-ep.c

diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index 6c5322c..bb0b789 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -6,23 +6,27 @@ Required properties:
 - reg-names: Must be "config" for the PCIe configuration space.
 (The old way of getting the configuration address space from "ranges"
 is deprecated and should be avoided.)
-- #address-cells: set to <3>
-- #size-cells: set to <2>
-- device_type: set to "pci"
-- ranges: ranges for the PCI memory and I/O regions
-- #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map: standard PCI properties
-   to define the mapping of the PCIe interface to interrupt
+- #address-cells (only for host mode): set to <3>
+- #size-cells (only for host mode): set to <2>
+- device_type (only for host mode): set to "pci"
+- ranges (only for host mode): ranges for the PCI memory and I/O regions
+- num-ib-windows (only for EP mode): number of inbound address translation
+   windows
+- num-ob-windows (only for EP mode): number of outbound address translation
+   windows
+- #interrupt-cells (only for host mode): set to <1>
+- interrupt-map-mask and interrupt-map (only for host mode): standard PCI
+   properties to define the mapping of the PCIe interface to interrupt
numbers.
 - num-lanes: number of lanes to use
 
 Optional properties:
 - num-lanes: number of lanes to use (this property should be specified unless
   the link is brought already up in BIOS)
-- reset-gpio: gpio pin number of power good signal
-- bus-range: PCI bus numbers covered (it is recommended for new devicetrees to
-  specify this property, to keep backwards compatibility a range of 0x00-0xff
-  is assumed if not present)
+- reset-gpio (only for host mode): gpio pin number of power good signal
+- bus-range (only for host mode): PCI bus numbers covered (it is recommended
+  for new devicetrees to specify this property, to keep backwards compatibility
+  a range of 0x00-0xff is assumed if not present)
 - clocks: Must contain an entry for each entry in clock-names.
See ../clocks/clock-bindings.txt for details.
 - clock-names: Must include the following entries:
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 249db74..8574828 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -78,6 +78,11 @@ config PCIE_DW_HOST
depends on PCI
select PCIE_DW
 
+config PCIE_DW_EP
+   bool
+   depends on PCI_ENDPOINT
+   select PCIE_DW
+
 config PCI_EXYNOS
bool "Samsung Exynos PCIe controller"
depends on SOC_EXYNOS5440
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index ee6bb85..11ef1e6 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_PCIE_DW) += pcie-designware.o
 obj-$(CONFIG_PCIE_DW_HOST) += pcie-designware-host.o
+obj-$(CONFIG_PCIE_DW_EP) += pcie-designware-ep.o
 obj-$(CONFIG_PCIE_DW_PLAT) += pcie-designware-plat.o
 obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
 obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
diff --git a/drivers/pci/controller/pcie-designware-ep.c 
b/drivers/pci/controller/pcie-designware-ep.c
new file mode 100644
index 000..f683be9
--- /dev/null
+++ b/drivers/pci/controller/pcie-designware-ep.c
@@ -0,0 +1,228 @@
+/**
+ * pci-designware-ep.c - Synopsys Designware PCIe Endpoint controller driver
+ *
+ * Copyright (C) 2016 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * 

[RFC PATCH 04/11] pci: endpoint: functions: add an EP function to test PCI

2016-09-13 Thread Kishon Vijay Abraham I
This adds a new endpoint function driver (to program the virtual
test device) making use of the EP-core library. The complete
usage of the test function is described in
Documentation/PCI/pci-test.txt (included in this commit).

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX|3 +
 Documentation/PCI/pci-test.txt|   79 +++
 drivers/pci/endpoint/Kconfig  |2 +
 drivers/pci/endpoint/Makefile |2 +-
 drivers/pci/endpoint/functions/Kconfig|   12 ++
 drivers/pci/endpoint/functions/Makefile   |5 +
 drivers/pci/endpoint/functions/pci-epf-test.c |  272 +
 7 files changed, 374 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/PCI/pci-test.txt
 create mode 100644 drivers/pci/endpoint/functions/Kconfig
 create mode 100644 drivers/pci/endpoint/functions/Makefile
 create mode 100644 drivers/pci/endpoint/functions/pci-epf-test.c

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index e422b8151..e5a583c 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -14,3 +14,6 @@ pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO
 pci-endpoint.txt
- guide to add endpoint controller driver and endpoint function driver.
+pci-test.txt
+   - description of the PCI EP function that can be used to test PCI
+ functionality
diff --git a/Documentation/PCI/pci-test.txt b/Documentation/PCI/pci-test.txt
new file mode 100644
index 000..2bc796b
--- /dev/null
+++ b/Documentation/PCI/pci-test.txt
@@ -0,0 +1,79 @@
+   PCI TEST
+   Kishon Vijay Abraham I 
+
+Traditionally PCI RC has always been validated by using standard
+PCI cards like ethernet PCI cards or USB PCI cards or SATA PCI cards.
+However with the addition of EP-core in linux kernel, it is possible
+to configure a PCI controller that can operate in EP mode to work as
+a test device.
+
+The PCI endpoint test device is a completely software device used to
+test the endpoint functionality and serve as a sample driver for other
+PCI endpoint devices.
+
+The PCI endpoint test device has four registers:
+
+   1) PCI_ENDPOINT_TEST_COMMAND
+   2) PCI_ENDPOINT_TEST_STATUS
+   3) PCI_ENDPOINT_TEST_SRC_ADDR
+   4) PCI_ENDPOINT_TEST_DST_ADDR
+
+Since this is a virtual device, all these registers will be present
+in RAM and will be allocated using one of the standard memory allocation
+API (in this case dma_alloc_coherent)
+
+*) PCI_ENDPOINT_TEST_COMMAND:
+
+This register will be used by the host driver to indicate the function
+that the endpoint device must perform.
+
+Bitfield Description:
+  Bit 0: reset the PCI endpoint device
+  Bit 1: raise irq
+  Bit 2: Copy the data from source addr to destination address
+
+*) PCI_ENDPOINT_TEST_STATUS
+
+This register reflects the status of the PCI endpoint device.
+
+Bitfield Description:
+  Bit 0: PCI endpoint device is in initialized state
+  Bit 1: Copy is in progress
+  Bit 2: Copy is done
+  Bit 3: IRQ is raised
+  Bit 4: Source address is invalid
+  Bit 5: Destination address is invalid
+
+*) PCI_ENDPOINT_TEST_SRC_ADDR
+
+This register contains the source address for the COPY command.
+
+*) PCI_ENDPOINT_TEST_DST_ADDR
+
+This register contains the destination address for the COPY command.
+
+PCI ENDPOINT TEST DRIVER (EP SIDE)
+==
+
+The Endpoint side function driver is present in
+drivers/pci/endpoint/functions/pci-epf-test.c
+
+This function driver creates the PCI endpoint test device and then
+waits for commands from the host driver. If the host driver sets
+Bit 1 (raise irq) in the COMMAND register, the endpoint driver
+will raise an irq. Similarly it resets the device if Bit 0 is set
+and starts copying the data if Bit 2 is set.
+
+The function driver is also responsible for updating the STATUS
+register.
+
+PCI ENDPOINT TEST DRIVER (HOST SIDE)
+
+
+The host side PCI driver is present in
+drivers/misc/pci_endpoint_test.c
+
+The PCI driver for the test device performs 3 tests
+   *) Verifying addresses programmed in BAR
+   *) Raise legacy IRQ
+   *) Copy data from source address to destination address (TODO)
diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index f1dd206..0e3dc8c 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -19,5 +19,7 @@ config PCI_ENDPOINT
 
   If in doubt, say "N" to disable Endpoint support.
 
+source "drivers/pci/endpoint/functions/Kconfig"
+
 endmenu
 
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
index 67c88bf..89310d1 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -3,4 +3,4 @@
 #
 
 obj-$(CONFIG_PCI_ENDPOINT) := pci-epc-core.o pci-epf-core.o \
-  

[RFC PATCH 08/11] pci: controller: dra7xx: Add EP mode support

2016-09-13 Thread Kishon Vijay Abraham I
The PCIe controller integrated in dra7xx SoCs is capable of operating
in endpoint mode. Add support for dra7xx SoCs to operate in endpoint
mode.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/devicetree/bindings/pci/ti-pci.txt |   30 ++-
 drivers/pci/controller/Kconfig   |   21 +++
 drivers/pci/controller/pci-dra7xx.c  |  211 +++---
 3 files changed, 225 insertions(+), 37 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/ti-pci.txt 
b/Documentation/devicetree/bindings/pci/ti-pci.txt
index 60e2516..b0e76f6 100644
--- a/Documentation/devicetree/bindings/pci/ti-pci.txt
+++ b/Documentation/devicetree/bindings/pci/ti-pci.txt
@@ -1,17 +1,22 @@
 TI PCI Controllers
 
 PCIe Designware Controller
- - compatible: Should be "ti,dra7-pcie""
- - reg : Two register ranges as listed in the reg-names property
- - reg-names : The first entry must be "ti-conf" for the TI specific registers
-  The second entry must be "rc-dbics" for the designware pcie
-  registers
-  The third entry must be "config" for the PCIe configuration space
+ - compatible: Should be "ti,dra7-pcie" for RC
+  Should be "ti,dra7-pcie-ep" for EP
  - phys : list of PHY specifiers (used by generic PHY framework)
  - phy-names : must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the
   number of PHYs as specified in *phys* property.
  - ti,hwmods : Name of the hwmod associated to the pcie, "pcie",
   where  is the instance number of the pcie from the HW spec.
+ - num-lanes as specified in ../designware-pcie.txt
+
+HOST MODE
+=
+ - reg : Two register ranges as listed in the reg-names property
+ - reg-names : The first entry must be "ti-conf" for the TI specific registers
+  The second entry must be "rc-dbics" for the designware pcie
+  registers
+  The third entry must be "config" for the PCIe configuration space
  - interrupts : Two interrupt entries must be specified. The first one is for
main interrupt line and the second for MSI interrupt line.
  - #address-cells,
@@ -19,13 +24,24 @@ PCIe Designware Controller
#interrupt-cells,
device_type,
ranges,
-   num-lanes,
interrupt-map-mask,
interrupt-map : as specified in ../designware-pcie.txt
 
 Optional Property:
  - gpios : Should be added if a gpio line is required to drive PERST# line
 
+DEVICE MODE
+===
+ - reg : Two register ranges as listed in the reg-names property
+ - reg-names : "ti-conf" for the TI specific registers
+  "ep_dbics" for the standard configuration registers as
+   they are locally accessed within the DIF CS space
+  "ep_dbics2" for the standard configuration registers as
+   they are locally accessed within the DIF CS2 space
+ - interrupts : one interrupt entries must be specified for main interrupt.
+ - num-ib-windows : number of inbound address translation windows
+ - num-ob-windows : number of outbound address translation windows
+
 Example:
 axi {
compatible = "simple-bus";
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 8574828..4d70981 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -23,6 +23,27 @@ config PCI_DRA7XX_HOST
 Enables support for the PCIe controller in the DRA7xx SoC to work in
 host mode.
 
+config PCI_DRA7XX_EP
+   bool "Endpoint Only Mode"
+   depends on PCI_ENDPOINT
+   select PCIE_DW_EP
+   help
+Enables support for the PCIe controller in the DRA7xx SoC to work in
+endpoint mode.
+
+config PCI_DRA7XX_HOST_EP
+   bool "Both Host and Endpoint Mode"
+   depends on PCI_MSI_IRQ_DOMAIN
+   depends on PCI
+   depends on PCI_ENDPOINT
+   select PCIE_DW_HOST
+   select PCIE_DW_EP
+   help
+Enables support for the PCIe controller in the DRA7xx SoC to work in
+both endpoint mode and host mode. If the board has 2 PCIe ports and
+one of them has to work in host mode and the other has to work in
+EP mode then this option has to be enabled.
+
 endchoice
 
 endif
diff --git a/drivers/pci/controller/pci-dra7xx.c 
b/drivers/pci/controller/pci-dra7xx.c
index dc5b8ef..5b49367 100644
--- a/drivers/pci/controller/pci-dra7xx.c
+++ b/drivers/pci/controller/pci-dra7xx.c
@@ -10,6 +10,7 @@
  * published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -17,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +58,11 @@
 #defineMSI BIT(4)
 #defineLEG_EP_INTERRUPTS (INTA | INTB | INTC | INTD)
 
+#definePCIECTRL_TI_CONF_DEVICE_TYPE0x0100
+#defineDEVICE_TYPE_EP  0x0
+#defineDEVICE_TYPE_LEG_EP

Re: [PATCH] staging: lustre: lustre/ldlm: Fixed sparse warnings

2016-09-13 Thread Dilger, Andreas
On Sep 12, 2016, at 04:27, Greg KH  wrote:
> 
> On Fri, Sep 09, 2016 at 08:50:35PM +0530, Nayeemahmed Badebade wrote:
>> Added __acquires / __releases sparse locking annotations
>> to lock_res_and_lock and unlock_res_and_lock functions in
>> l_lock.c, to fix below sparse warnings:
>> 
>> l_lock.c:47:22: warning: context imbalance in 'lock_res_and_lock' - wrong 
>> count at exit
>> l_lock.c:62:6: warning: context imbalance in 'unlock_res_and_lock' - 
>> unexpected unlock
>> 
>> Signed-off-by: Nayeemahmed Badebade 
>> ---
>> drivers/staging/lustre/lustre/ldlm/l_lock.c | 4 
>> 1 file changed, 4 insertions(+)
>> 
>> diff --git a/drivers/staging/lustre/lustre/ldlm/l_lock.c 
>> b/drivers/staging/lustre/lustre/ldlm/l_lock.c
>> index ea8840c..c4b9612 100644
>> --- a/drivers/staging/lustre/lustre/ldlm/l_lock.c
>> +++ b/drivers/staging/lustre/lustre/ldlm/l_lock.c
>> @@ -45,6 +45,8 @@
>>  * being an atomic operation.
>>  */
>> struct ldlm_resource *lock_res_and_lock(struct ldlm_lock *lock)
>> +__acquires(>l_lock)
>> +__acquires(lock->l_resource)
> 
> Hm, these are tricky, I don't want to take this type of change without
> an ack from the lustre developers...

The "__acquires(>l_lock)" line here looks correct, along with the
corresponding "__releases(>l_lock)" at unlock_res_and_lock().

The problem, however, is that "l_resource" is not a lock, but rather a
struct.  The call to "lock_res(lock->l_resource)" is actually locking
"lr_lock" internally.

It would be better to add "__acquires(>lr_lock)" at lock_res() and
"__releases(>lr_lock)" at unlock_res().  That will also forestall
any other warnings about an imbalance with lock_res()/unlock_res() or
their callsites.

Cheers, Andreas


[RFC PATCH 10/11] ARM: dts: DRA7: Modify pcie1 dt node for EP mode

2016-09-13 Thread Kishon Vijay Abraham I
Modify pcie1 dt node in order for the controller to operate in
endpoint mode. This is used only for testing EP mode.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |   43 +++
 1 file changed, 11 insertions(+), 32 deletions(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d9bfb94..73f63d1 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -283,38 +283,17 @@
};
};
 
-   axi@0 {
-   compatible = "simple-bus";
-   #size-cells = <1>;
-   #address-cells = <1>;
-   ranges = <0x5100 0x5100 0x3000
- 0x00x2000 0x1000>;
-   pcie1: pcie@5100 {
-   compatible = "ti,dra7-pcie";
-   reg = <0x5100 0x2000>, <0x51002000 0x14c>, 
<0x1000 0x2000>;
-   reg-names = "rc_dbics", "ti_conf", "config";
-   interrupts = <0 232 0x4>, <0 233 0x4>;
-   #address-cells = <3>;
-   #size-cells = <2>;
-   device_type = "pci";
-   ranges = <0x8100 0 0  0x03000 0 
0x0001
- 0x8200 0 0x20013000 0x13000 0 
0xffed000>;
-   #interrupt-cells = <1>;
-   num-lanes = <1>;
-   ti,hwmods = "pcie1";
-   phys = <_phy>;
-   phy-names = "pcie-phy0";
-   interrupt-map-mask = <0 0 0 7>;
-   interrupt-map = <0 0 0 1 _intc 1>,
-   <0 0 0 2 _intc 2>,
-   <0 0 0 3 _intc 3>,
-   <0 0 0 4 _intc 4>;
-   pcie1_intc: interrupt-controller {
-   interrupt-controller;
-   #address-cells = <0>;
-   #interrupt-cells = <1>;
-   };
-   };
+   pcie1: pcie@5100 {
+   compatible = "ti,dra7-pcie-ep";
+   reg = <0x5100 0x28>, <0x51002000 0x14c>, 
<0x51001000 0x28>;
+   reg-names = "ep_dbics", "ti_conf", "ep_dbics2";
+   interrupts = <0 232 0x4>;
+   num-lanes = <1>;
+   num-ib-windows = <4>;
+   num-ob-windows = <16>;
+   ti,hwmods = "pcie1";
+   phys = <_phy>;
+   phy-names = "pcie-phy0";
};
 
axi@1 {
-- 
1.7.9.5



[RFC PATCH 11/11] HACK: pci: controller: dra7xx: disable smart idle

2016-09-13 Thread Kishon Vijay Abraham I
Smart idle prevents RC to access the memory space of this
controller. Set the idle mode to smart idle wakeup. This
should ideally be done in hwmod. Till it's figured out how
to configure it in hwmod, mark this as HACK.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/controller/pci-dra7xx.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/pci/controller/pci-dra7xx.c 
b/drivers/pci/controller/pci-dra7xx.c
index 5b49367..31211e6 100644
--- a/drivers/pci/controller/pci-dra7xx.c
+++ b/drivers/pci/controller/pci-dra7xx.c
@@ -30,6 +30,14 @@
 
 /* PCIe controller wrapper DRA7XX configuration registers */
 
+#definePCIECTRL_DRA7XX_CONF_SYSCONFIG  0x0010
+#define SIDLE_MASK 3
+#define SIDLE_SHIFT2
+#define SIDLE_FORCE0x0
+#define SIDLE_NO   0x1
+#define SIDLE_SMART0x2
+#define SIDLE_SMART_WKUP   0x3
+
 #definePCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN 0x0024
 #definePCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN 0x0028
 #defineERR_SYS BIT(0)
@@ -606,6 +614,10 @@ static int __init dra7xx_pcie_probe(struct platform_device 
*pdev)
goto err_gpio;
break;
case DW_PCIE_EP_TYPE:
+   reg = dra7xx_pcie_readl(dra7xx, PCIECTRL_DRA7XX_CONF_SYSCONFIG);
+   reg &= ~(SIDLE_MASK << SIDLE_SHIFT);
+   reg |= SIDLE_SMART_WKUP << SIDLE_SHIFT;
+   dra7xx_pcie_writel(dra7xx, PCIECTRL_DRA7XX_CONF_SYSCONFIG, reg);
dra7xx_pcie_writel(dra7xx, PCIECTRL_TI_CONF_DEVICE_TYPE,
   DEVICE_TYPE_EP);
ret = dra7xx_add_pcie_ep(dra7xx, pdev);
-- 
1.7.9.5



[RFC PATCH 06/11] pci: controller: split designware into *core* and *host*

2016-09-13 Thread Kishon Vijay Abraham I
No functional change. Split the designware core driver into
*core* driver and *host* only driver. This is in preparation
to add endpoint support in designware. The *endpoint* driver will
reuse the *core* driver.

This also modifies the dra7xx code to use the new architecture.
TODO: All other platforms using designware core should also
be modified accordingly.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/controller/Kconfig |   48 +-
 drivers/pci/controller/Makefile|1 +
 drivers/pci/controller/pci-dra7xx.c|  117 +++-
 .../{pcie-designware.c => pcie-designware-host.c}  |  294 ++--
 drivers/pci/controller/pcie-designware.c   |  741 ++--
 drivers/pci/controller/pcie-designware.h   |  158 -
 6 files changed, 367 insertions(+), 992 deletions(-)
 copy drivers/pci/controller/{pcie-designware.c => pcie-designware-host.c} (64%)

diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 4c55c2d..249db74 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -3,13 +3,29 @@ menu "PCI controller drivers"
 config PCI_DRA7XX
bool "TI DRA7xx PCIe controller"
depends on OF && HAS_IOMEM && TI_PIPE3
+   help
+Enables support for the PCIe controller in the DRA7xx SoC. There
+are two instances of PCIe controller in DRA7xx. This controller can
+work either as EP or RC. In order to enable host specific features
+PCI_DRA7XX_HOST must be selected. This reuses the Designware core.
+
+if PCI_DRA7XX
+
+choice
+   bool "PCIe Mode"
+
+config PCI_DRA7XX_HOST
+   bool "Host Only Mode"
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
-   select PCIE_DW
+   select PCIE_DW_HOST
help
-Enables support for the PCIe controller in the DRA7xx SoC.  There
-are two instances of PCIe controller in DRA7xx.  This controller can
-act both as EP and RC.  This reuses the Designware core.
+Enables support for the PCIe controller in the DRA7xx SoC to work in
+host mode.
+
+endchoice
+
+endif
 
 config PCI_MVEBU
bool "Marvell EBU PCIe controller"
@@ -44,7 +60,7 @@ config PCIE_DW_PLAT
bool "Platform bus based DesignWare PCIe Controller"
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
-   select PCIE_DW
+   select PCIE_DW_HOST
---help---
 This selects the DesignWare PCIe controller support. Select this if
 you have a PCIe controller on Platform bus.
@@ -55,16 +71,20 @@ config PCIE_DW_PLAT
 
 config PCIE_DW
bool
+
+config PCIE_DW_HOST
+   bool
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
+   select PCIE_DW
 
 config PCI_EXYNOS
bool "Samsung Exynos PCIe controller"
depends on SOC_EXYNOS5440
depends on PCI_MSI_IRQ_DOMAIN
select PCIEPORTBUS
-   select PCIE_DW
depends on PCI
+   select PCIE_DW_HOST
 
 config PCI_IMX6
bool "Freescale i.MX6 PCIe controller"
@@ -72,7 +92,7 @@ config PCI_IMX6
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
select PCIEPORTBUS
-   select PCIE_DW
+   select PCIE_DW_HOST
 
 config PCI_TEGRA
bool "NVIDIA Tegra PCIe controller"
@@ -121,7 +141,7 @@ config PCIE_SPEAR13XX
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
select PCIEPORTBUS
-   select PCIE_DW
+   select PCIE_DW_HOST
help
  Say Y here if you want PCIe support on SPEAr13XX SoCs.
 
@@ -130,7 +150,7 @@ config PCI_KEYSTONE
depends on ARCH_KEYSTONE
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
-   select PCIE_DW
+   select PCIE_DW_HOST
select PCIEPORTBUS
help
  Say Y here if you want to enable PCI controller support on Keystone
@@ -172,7 +192,7 @@ config PCI_LAYERSCAPE
depends on OF && (ARM || ARCH_LAYERSCAPE)
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
-   select PCIE_DW
+   select PCIE_DW_HOST
select MFD_SYSCON
help
  Say Y here if you want PCIe controller support on Layerscape SoCs.
@@ -248,7 +268,7 @@ config PCI_HISI
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
select PCIEPORTBUS
-   select PCIE_DW
+   select PCIE_DW_HOST
help
  Say Y here if you want PCIe controller support on HiSilicon
  Hip05 and Hip06 SoCs
@@ -258,7 +278,7 @@ config PCIE_QCOM
depends on ARCH_QCOM && OF
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
-   select PCIE_DW
+   select PCIE_DW_HOST
select PCIEPORTBUS
help
  Say Y here to enable PCIe controller support on Qualcomm SoCs. The
@@ -286,7 +306,7 @@ config PCIE_ARMADA_8K
depends on ARCH_MVEBU
depends on PCI_MSI_IRQ_DOMAIN
depends on PCI
-   select PCIE_DW
+   select PCIE_DW_HOST
   

[RFC PATCH 03/11] Documentation: PCI: guide to use PCI Endpoint Core Layer

2016-09-13 Thread Kishon Vijay Abraham I
Add Documentation to let users enable endpoint mode in the PCI
controller and add new PCI endpoint function.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/00-INDEX |2 +
 Documentation/PCI/pci-endpoint.txt |  199 
 2 files changed, 201 insertions(+)
 create mode 100644 Documentation/PCI/pci-endpoint.txt

diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 147231f..e422b8151 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -12,3 +12,5 @@ pci.txt
- info on the PCI subsystem for device driver authors
 pcieaer-howto.txt
- the PCI Express Advanced Error Reporting Driver Guide HOWTO
+pci-endpoint.txt
+   - guide to add endpoint controller driver and endpoint function driver.
diff --git a/Documentation/PCI/pci-endpoint.txt 
b/Documentation/PCI/pci-endpoint.txt
new file mode 100644
index 000..a453aaa
--- /dev/null
+++ b/Documentation/PCI/pci-endpoint.txt
@@ -0,0 +1,199 @@
+   PCI ENDPOINT FRAMEWORK
+   Kishon Vijay Abraham I 
+
+This document is a guide to use the PCI Endpoint Framework in order to create
+endpoint controller driver, endpoint function driver and using configfs
+interface to bind the function driver to the controller driver.
+
+1. Introduction
+
+*Linux* has a comprehensive PCI subsystem to support PCI controllers that
+operates in Root Complex mode. The subsystem has capability to scan PCI bus,
+assign memory resources and irq resources, load PCI driver (based on
+vendorid, deviceid), support other services like hot-plug, power management,
+advanced error reporting and virtual channels.
+
+However PCI controller IPs integrated in certain SoC is capable of operating
+either in Root Complex mode or Endpoint mode. PCI Endpoint Framework will
+add endpoint mode support in *Linux*. This will help to run Linux in an
+EP system which can have a wide variety of use cases from testing or
+validation, co-processor accelerator etc..
+
+2. PCI Endpoint Core
+
+The PCI Endpoint Core layer comprises of 3 components: the Endpoint Controller
+library, the Endpoint Function library and the configfs layer to bind the
+endpoint function with the endpoint controller.
+
+2.1 PCI Endpoint Controller(EPC) Library
+
+The EPC library provides APIs to be used by the controller that can operate
+in endpoint mode. It also provides APIs to be used by function driver/library
+in order to implement a particular endpoint function.
+
+2.1.1 APIs for the PCI controller Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI controller driver.
+
+*) devm_pci_epc_create()/pci_epc_create()
+
+   The PCI controller driver should implement the following ops:
+* write_header: ops to populate configuration space header
+* set_bar: ops to configure the BAR
+* clear_bar: ops to reset the BAR
+* alloc_addr_space: ops to allocate *in* PCI controller address space
+* free_addr_space: ops to free the allocated address space
+* raise_irq: ops to raise a legacy or MSI interrupt
+* start: ops to start the PCI link
+* stop: ops to stop the PCI link
+
+   The PCI controller driver can then create a new EPC device by invoking
+   devm_pci_epc_create/pci_epc_create.
+
+*) devm_pci_epc_destroy()/pci_epc_destroy()
+
+   The PCI controller driver can destroy the EPC device created by either
+   devm_pci_epc_create or pci_epc_create using devm_pci_epc_destroy() or
+   /pci_epc_destroy()
+
+2.1.2 APIs for the PCI Endpoint Function Driver
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI endpoint function driver.
+
+*) pci_epc_write_header()
+
+   The PCI endpoint function driver should use pci_epc_write_header() to
+   write the standard configuration header to the endpoint controller.
+
+*) pci_epc_set_bar()
+
+   The PCI endpoint function driver should use pci_epc_set_bar() to configure
+   the Base Address Register in order for the host to assign PCI addr space.
+   Register space of the function driver is usually configured
+   using this API.
+
+*) pci_epc_clear_bar()
+
+   The PCI endpoint function driver should use pci_epc_clear_bar() to reset
+   the BAR.
+
+*) pci_epc_raise_irq()
+
+   The PCI endpoint function driver should use pci_epc_raise_irq() to raise
+   Legacy Interrupt or MSI Interrupt.
+
+*) pci_epc_start()
+
+   The PCI endpoint function driver should invoke pci_epc_start() once it
+   has configured the endpoint function and wants to start the PCI link.
+
+*) pci_epc_stop()
+
+   The PCI endpoint function driver should invoke pci_epc_stop() to stop
+   the PCI LINK.
+
+2.1.3 APIs for the PCI Endpoint Function Library
+
+This section lists the APIs that the PCI Endpoint core provides to be used
+by the PCI endpoint function library.
+
+*) pci_epc_bind_epf()
+
+   The PCI endpoint function 

[RFC PATCH 02/11] pci: endpoint: introduce configfs entry for configuring EP functions

2016-09-13 Thread Kishon Vijay Abraham I
Introduce a new configfs entry to configure the EP function (like
configuring the standard configuration header entries) and to
bind the function with a controller.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/Kconfig  |4 +-
 drivers/pci/endpoint/Makefile |3 +-
 drivers/pci/endpoint/pci-ep-cfs.c |  275 +
 3 files changed, 280 insertions(+), 2 deletions(-)
 create mode 100644 drivers/pci/endpoint/pci-ep-cfs.c

diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index a6d827c..f1dd206 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -13,7 +13,9 @@ config PCI_ENDPOINT
 
   Enabling this option will build the endpoint library, which
   includes endpoint controller library and endpoint function
-  library.
+  library. This will also enable the configfs entry required to
+  configure the endpoint function and used to bind the
+  function with a endpoint controller.
 
   If in doubt, say "N" to disable Endpoint support.
 
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
index dbc5517..67c88bf 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -2,4 +2,5 @@
 # Makefile for PCI Endpoint Support
 #
 
-obj-$(CONFIG_PCI_ENDPOINT) := pci-epc-core.o pci-epf-core.o
+obj-$(CONFIG_PCI_ENDPOINT) := pci-epc-core.o pci-epf-core.o \
+  pci-ep-cfs.o
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
new file mode 100644
index 000..d11ae34
--- /dev/null
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -0,0 +1,275 @@
+/**
+ * pci-ep-cfs.c - configfs to configure the PCI endpoint
+ *
+ * Copyright (C) 2016 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct pci_epf_info {
+   struct config_item pci_epf;
+   struct pci_epf *epf;
+};
+
+static inline struct pci_epf_info *to_pci_epf_info(struct config_item *item)
+{
+   return container_of(item, struct pci_epf_info, pci_epf);
+}
+
+#define PCI_EPF_HEADER_R(_name)\
+static ssize_t pci_epf_##_name##_show(struct config_item *item,
\
+   char *page)\
+{ \
+   return sprintf(page, "0x%04x\n",   \
+  to_pci_epf_info(item)->epf->header->_name); \
+}
+
+#define PCI_EPF_HEADER_W_u32(_name)\
+static ssize_t pci_epf_##_name##_store(struct config_item *item,  \
+const char *page, size_t len) \
+{ \
+   u32 val;   \
+   int ret;   \
+   ret = kstrtou32(page, 0, );\
+   if (ret)   \
+   return ret;\
+   to_pci_epf_info(item)->epf->header->_name = val;   \
+   return len;\
+}
+
+#define PCI_EPF_HEADER_W_u16(_name)\
+static ssize_t pci_epf_##_name##_store(struct config_item *item,  \
+const char *page, size_t len) \
+{ \
+   u16 val;   \
+   int ret;   \
+   ret = kstrtou16(page, 0, );\
+   if (ret)   \
+   return ret;\
+   to_pci_epf_info(item)->epf->header->_name = val;   \
+   return len;

linux-next: Tree for Sep 14

2016-09-13 Thread Stephen Rothwell
Hi all,

Changes since 20160913:

The pm tree gained a build failure for which I partially reverted
a commit.

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit.

Non-merge commits (relative to Linus' tree): 6956
 6884 files changed, 325027 insertions(+), 205547 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (5924bbecd026 Merge branch 'x86-urgent-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (1a57c286d8ce ARM: pxa/lubbock: add pcmcia clock)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (ffed15d3ce3f powerpc/kernel: Fix size of 
NUM_CPU_FTR_KEYS on 32-bit)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (440f895aa97f drivers: net: phy: xgene: Fix 'remove' 
function)
Merging ipsec/master (1fb81e09d487 vti: use right inner_mode for inbound inter 
address family policy checks)
Merging netfilter/master (440f895aa97f drivers: net: phy: xgene: Fix 'remove' 
function)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git)
Merging mac80211/master (ad5987b47e96 nl80211: validate number of probe 
response CSA counters)
Merging sound-current/for-linus (3f640970a414 ALSA: hda - Fix headset mic 
detection problem for several Dell laptops)
Merging pci-current/for-linus (035ee288ae7a PCI: Fix bridge_d3 update on device 
removal)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (9395452b4aab Linux 4.8-rc6)
Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning 
on !PM_SLEEP)
Merging usb-serial-fixes/usb-linus (f190fd92458d USB: serial: simple: add 
support for another Infineon flashloader)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (9395452b4aab Linux 4.8-rc6)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (4af2ff91ec3f Input: silead_gsl1680 - use 
"silead/" prefix for firmware loading)
Merging crypto-current/master (2db34e78f126 crypto: arm64/aes-ctr - fix NULL 
dereference in tail processing)
Merging ide/master (797cee982eef Merge branch 'stable-4.8' of 
git://git.infradead.org/users/pcmoore/audit)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (c8952a707556 vfio/pci: Fix NULL pointer oops in 
error interrupt setup handling)
Merging kselftest-fixes/fixes (29b4817d4018 Linux 4.8-rc1)
Merging backlight-fixes/for-backlight-fixe

Re: [RFC PATCH] pci: support for configurable PCI endpoint

2016-09-13 Thread Kishon Vijay Abraham I
Hi,

Will resend the series with patch numbering.

Thanks
Kishon

On Tuesday 13 September 2016 10:40 PM, Kishon Vijay Abraham I wrote:
> This patch series
>   *) adds PCI endpoint core layer
>   *) modifies designware/dra7xx driver to be configured in EP mode
>   *) adds a PCI endpoint *test* function driver
> 
> Known Limitation:
>   *) Does not support multi-function devices
> 
> TODO:
>   *) access buffers in RC
>   *) MSI interrupts
>   *) Enable user space control for the RC side PCI driver
>   *) Adapt all other users of designware to use the new design
> 
> HOW TO:
> 
> ON THE EP SIDE:
> ***
> 
> /* EP function is configured using configfs */
> # mount -t configfs none /sys/kernel/config
> 
> /* PCI EP core layer creates "pci_ep" entry in configfs */
> # cd /sys/kernel/config/pci_ep/
> 
> /*
>  * This is the 1st step in creating an endpoint function. This
>  * creates the endpoint function device *instance*. The string
>  * before the . suffix will identify the driver this
>  * EP function will bind to.
>  * Just pci_epf_test is also valid. The . suffix is used
>  * if there are multiple PCI controllers and all of them wants
>  * to use the same function.
>  */
> # mkdir pci_epf_test.0
> 
> /*
>  * When the above command is given, the function device will
>  * also be bound to a function driver. To find the list of
>  * function drivers available in the system, use the following
>  * command. To create a new driver, the following can be referred
>  * drivers/pci/endpoint/functions/pci-epf-test.c
>  */
> # ls /sys/bus/pci-epf/drivers
> pci_epf_test
> 
> /* Now configure the endpoint function */
> # cd pci_epf_test.0
> 
> /* These are the fields that can be configured */
> # ls
> baseclass_codefunction  revid vendorid
> cache_line_size   interrupt_pin subclass_code
> deviceid  peripheralsubsys_id
> epc   progif_code   subsys_vendor_id
> 
> /* The function driver will populate these fields with default values */
> # cat vendorid 
> 0x
> 
> # cat interrupt_pin 
> 0x0001
> 
> /* The user can configure any of these fields */
> # echo 0x104c > vendorid
> 
> /*
>  * Next is binding this function driver to the controller driver. In
>  * order to find the possible controller drivers that this function
>  * driver can be bound to, the following sysfs entry can be used
>  */
> # ls /sys/class/pci_epc/
> 5100.pci
> 
> /* Now bind the function driver to the controller driver */
> # echo "5100.pcie" > epc
> [  494.743487] dra7-pcie 5100.pcie: no free inbound window
> [  494.749367] pci_epf_test pci_epf_test.0: failed to set BAR4
> [  494.755238] dra7-pcie 5100.pcie: no free inbound window
> [  494.761451] pci_epf_test pci_epf_test.0: failed to set BAR5
> 
> /*
>  * the above error messages are due to non availability of free
>  * inbound windows. So the function drivers in dra7xx can use
>  * only 4 (BAR0..BAR3) BARs
>  */
> 
> /** PCI endpoint is configured **/
> 
> ON THE HOST SIDE:
> *
> # modprobe pci_endpoint_test
> [8.197560] ** Testing pci-endpoint-test Device **
> [9.056990] Reset: OKAY
> [9.059753] BAR1 OKAY
> [9.062419] BAR2 OKAY
> [9.069506] BAR3 OKAY
> [9.071880] BAR4 NOT OKAY
> [9.074618] BAR5 NOT OKAY
> [9.379257] Legacy IRQ: OKAY
> [9.382281] ** End Test **
> 
> /*
>  * Rightnow these tests gets executed as soon as the pci_endpoint_test
>  * module gets inserted. These will be modified so that user/user script
>  * can control this. Once the functionality for EP to access RC buffer
>  * is added, more tests can be added including throughput measurement tests.
>  */ 
> 
> 
> Kishon Vijay Abraham I (11):
>   pci: endpoint: add EP core layer to enable EP controller and EP
> functions
>   pci: endpoint: introduce configfs entry for configuring EP functions
>   Documentation: PCI: guide to use PCI Endpoint Core Layer
>   pci: endpoint: functions: add an EP function to test PCI
>   pci: rename *host* directory to *controller*
>   pci: controller: split designware into *core* and *host*
>   pci: controller: designware: Add EP mode support
>   pci: controller: dra7xx: Add EP mode support
>   misc: add a new host side PCI endpoint test driver
>   ARM: dts: DRA7: Modify pcie1 dt node for EP mode
>   HACK: pci: controller: dra7xx: disable smart idle
> 
>  Documentation/PCI/00-INDEX |5 +
>  Documentation/PCI/pci-endpoint.txt |  199 ++
>  Documentation/PCI/pci-test.txt |   79 
>  .../devicetree/bindings/pci/designware-pcie.txt|   26 +-
>  Documentation/devicetree/bindings/pci/ti-pci.txt   |   30 +-
>  MAINTAINERS|   50 +--
>  arch/arm/boot/dts/dra7.dtsi|   43 +--
>  drivers/Makefile   |4 +
>  drivers/misc/Kconfig   

Re: [PATCH for-next 10/20] IB/hns: Modify the init of iboe lock

2016-09-13 Thread Leon Romanovsky
On Wed, Sep 14, 2016 at 02:09:37AM +, Salil Mehta wrote:
>
>
> > -Original Message-
> > From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> > ow...@vger.kernel.org] On Behalf Of Leon Romanovsky
> > Sent: Tuesday, September 13, 2016 7:50 AM
> > To: Salil Mehta
> > Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> > xuwei (O); mehta.salil@gmail.com; linux-r...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Linuxarm; Huangdongdong (Donald)
> > Subject: Re: [PATCH for-next 10/20] IB/hns: Modify the init of iboe
> > lock
> >
> > On Fri, Sep 09, 2016 at 06:30:41PM +0800, Salil Mehta wrote:
> > > From: Lijun Ou 
> > >
> > > This lock will be used in query port interface, and will be called
> > > while IB device was registered to OFED frame. So, the lock of iboe
> > > must be initiated before IB device was registered.
> >
> > Sorry,
> > what did you mean by writing "OFED frame"?
> It is a typo. It was OFED framework but I guess more appropriate word
> might have been 'IB core' layer of Infiniband. Will fix this. Thanks!

As a general note, and I understand that these contributors are not
native English speakers, and I understand the desire to submit the right
code and code should speak by itself, but can you invest more time in
commit messages and write them in English?

Thanks

>
> Best regards
> Salil
> >
> > >
> > > Signed-off-by: Lijun Ou 
> > > Signed-off-by: Dongdong Huang(Donald) 
> > > Reviewed-by:  Wei Hu (Xavier) 
> > > Signed-off-by: Salil Mehta 
> > > ---
> > >  drivers/infiniband/hw/hns/hns_roce_main.c |3 +--
> > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c
> > b/drivers/infiniband/hw/hns/hns_roce_main.c
> > > index 2704076..4721c0c 100644
> > > --- a/drivers/infiniband/hw/hns/hns_roce_main.c
> > > +++ b/drivers/infiniband/hw/hns/hns_roce_main.c
> > > @@ -615,6 +615,7 @@ static int hns_roce_register_device(struct
> > hns_roce_dev *hr_dev)
> > >   struct device *dev = _dev->pdev->dev;
> > >
> > >   iboe = _dev->iboe;
> > > + spin_lock_init(>lock);
> > >
> > >   ib_dev = _dev->ib_dev;
> > >   strlcpy(ib_dev->name, "hisi_%d", IB_DEVICE_NAME_MAX);
> > > @@ -701,8 +702,6 @@ static int hns_roce_register_device(struct
> > hns_roce_dev *hr_dev)
> > >   goto error_failed_setup_mtu_gids;
> > >   }
> > >
> > > - spin_lock_init(>lock);
> > > -
> > >   iboe->nb.notifier_call = hns_roce_netdev_event;
> > >   ret = register_netdevice_notifier(>nb);
> > >   if (ret) {
> > > --
> > > 1.7.9.5
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> > in
> > > the body of a message to majord...@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature


Re: [PATCH v14 13/15] selftests/powerpc: Add ptrace tests for TM SPR registers

2016-09-13 Thread Cyril Bur
On Mon, 2016-09-12 at 15:33 +0800, wei.guo.si...@gmail.com wrote:
> From: Anshuman Khandual 
> 
> This patch adds ptrace interface test for TM SPR registers. This
> also adds ptrace interface based helper functions related to TM
> SPR registers access.
> 

I'm seeing this one fail a lot, it does occasionally succeed but fails
a lot on my test setup.

I use qemu on a power8 for most of my testing:
qemu-system-ppc64 --enable-kvm -machine pseries,accel=kvm,usb=off -m
4096 -realtime mlock=off -smp 4,sockets=1,cores=2,threads=2 -nographic
-vga none


> Signed-off-by: Anshuman Khandual 
> Signed-off-by: Simon Guo 
> ---
>  tools/testing/selftests/powerpc/ptrace/Makefile|   3 +-
>  .../selftests/powerpc/ptrace/ptrace-tm-spr.c   | 186
> +
>  tools/testing/selftests/powerpc/ptrace/ptrace.h|  35 
>  3 files changed, 223 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/powerpc/ptrace/ptrace-tm-
> spr.c
> 
> diff --git a/tools/testing/selftests/powerpc/ptrace/Makefile
> b/tools/testing/selftests/powerpc/ptrace/Makefile
> index 797840a..f34670e 100644
> --- a/tools/testing/selftests/powerpc/ptrace/Makefile
> +++ b/tools/testing/selftests/powerpc/ptrace/Makefile
> @@ -1,7 +1,8 @@
>  TEST_PROGS := ptrace-ebb ptrace-gpr ptrace-tm-gpr ptrace-tm-spd-gpr
> \
>  ptrace-tar ptrace-tm-tar ptrace-tm-spd-tar ptrace-vsx ptrace-tm-vsx
> \
> -ptrace-tm-spd-vsx
> +ptrace-tm-spd-vsx ptrace-tm-spr
>  
> +include ../../lib.mk
>  
>  all: $(TEST_PROGS)
>  CFLAGS += -m64
> diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spr.c
> b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spr.c
> new file mode 100644
> index 000..2863070
> --- /dev/null
> +++ b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-spr.c
> @@ -0,0 +1,186 @@
> +/*
> + * Ptrace test TM SPR registers
> + *
> + * Copyright (C) 2015 Anshuman Khandual, IBM Corporation.
> + *
> + * 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.
> + */
> +#include "ptrace.h"
> +
> +/* Tracee and tracer shared data */
> +struct shared {
> + int flag;
> + struct tm_spr_regs regs;
> +};
> +unsigned long tfhar;
> +
> +int shm_id;
> +volatile struct shared *cptr, *pptr;
> +
> +int shm_id1;
> +volatile int *cptr1, *pptr1;
> +
> +#define TM_SCHED 0xde018c01
> +#define TM_KVM_SCHED 0xe001ac01
> +
> +int validate_tm_spr(struct tm_spr_regs *regs)
> +{
> + if (regs->tm_tfhar != tfhar)
> + return TEST_FAIL;
> +
> + if ((regs->tm_texasr != TM_SCHED) && (regs->tm_texasr !=
> TM_KVM_SCHED))
> + return TEST_FAIL;

The above condition fails, should this test try again if this condition
is true, rather than fail?

> +
> + if ((regs->tm_texasr == TM_KVM_SCHED) && (regs->tm_tfiar !=
> 0))
> + return TEST_FAIL;
> +
> + return TEST_PASS;
> +}
> +

[snip]



Re: [PATCH] powerpc/powernv: Initialise nest mmu

2016-09-13 Thread Alistair Popple
On Mon, 15 Aug 2016 04:51:59 PM Alistair Popple wrote:
> POWER9 contains an off core mmu called the nest mmu (NMMU). This is
> used by other hardware units on the chip to translate virtual
> addresses into real addresses. The unit attempting an address
> translation provides the majority of the context required for the
> translation request except for the base address of the partition table
> (ie. the PTCR) which needs to be programmed into the NMMU.
> 
> This patch adds a call to OPAL to set the PTCR for the nest mmu in
> opal_init().
> 
> Signed-off-by: Alistair Popple 
> ---
> 
> This patch depends on a new OPAL call which has yet to be added to
> skiboot, although the patch to do so has been posted to
> http://patchwork.ozlabs.org/patch/659106/

This has now gone into skiboot with the same OPAL call number :-
https://github.com/open-power/skiboot/commit/84e63a8d4fd9eb3efc872099d579c49fef6a5810

>  arch/powerpc/include/asm/opal-api.h| 3 ++-
>  arch/powerpc/include/asm/opal.h| 1 +
>  arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
>  arch/powerpc/platforms/powernv/opal.c  | 3 +++
>  4 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/include/asm/opal-api.h 
> b/arch/powerpc/include/asm/opal-api.h
> index 0e2e57b..a0aa285 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -167,7 +167,8 @@
>  #define OPAL_INT_EOI 124
>  #define OPAL_INT_SET_MFRR125
>  #define OPAL_PCI_TCE_KILL126
> -#define OPAL_LAST126
> +#define OPAL_NMMU_SET_PTCR   127
> +#define OPAL_LAST127
> 
>  /* Device tree flags */
> 
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index ee05bd2..433df5e 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -228,6 +228,7 @@ int64_t opal_pci_tce_kill(uint64_t phb_id, uint32_t 
> kill_type,
>  int64_t opal_rm_pci_tce_kill(uint64_t phb_id, uint32_t kill_type,
>uint32_t pe_num, uint32_t tce_size,
>uint64_t dma_addr, uint32_t npages);
> +int64_t opal_nmmu_set_ptcr(uint64_t chip_id, uint64_t ptcr);
> 
>  /* Internal functions */
>  extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
> diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S 
> b/arch/powerpc/platforms/powernv/opal-wrappers.S
> index 3d29d40..a955649 100644
> --- a/arch/powerpc/platforms/powernv/opal-wrappers.S
> +++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
> @@ -308,3 +308,4 @@ OPAL_CALL(opal_int_eoi,   
> OPAL_INT_EOI);
>  OPAL_CALL(opal_int_set_mfrr, OPAL_INT_SET_MFRR);
>  OPAL_CALL(opal_pci_tce_kill, OPAL_PCI_TCE_KILL);
>  OPAL_CALL_REAL(opal_rm_pci_tce_kill, OPAL_PCI_TCE_KILL);
> +OPAL_CALL(opal_nmmu_set_ptcr,OPAL_NMMU_SET_PTCR);
> diff --git a/arch/powerpc/platforms/powernv/opal.c 
> b/arch/powerpc/platforms/powernv/opal.c
> index 8b4fc68..b533245 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -762,6 +762,9 @@ static int __init opal_init(void)
>   /* Initialise OPAL kmsg dumper for flushing console on panic */
>   opal_kmsg_init();
> 
> + /* Update partition table control register on all Nest MMUs */
> + opal_nmmu_set_ptcr(-1UL, __pa(partition_tb) | (PATB_SIZE_SHIFT - 12));
> +
>   return 0;
>  }
>  machine_subsys_initcall(powernv, opal_init);
> --
> 2.1.4



Re: [PATCH v14 15/15] selftests/powerpc: Fix a build issue

2016-09-13 Thread Cyril Bur
On Mon, 2016-09-12 at 15:33 +0800, wei.guo.si...@gmail.com wrote:
> From: Anshuman Khandual 
> 
> Fixes the following build failure -
> 
> cp_abort.c:90:3: error: ‘for’ loop initial declarations are only
> allowed in C99 or C11 mode
>    for (int i = 0; i < NUM_LOOPS; i++) {
>    ^
> cp_abort.c:90:3: note: use option -std=c99, -std=gnu99, -std=c11 or
> -std=gnu11 to compile your code
> cp_abort.c:97:3: error: ‘for’ loop initial declarations are only
> allowed in C99 or C11 mode
>    for (int i = 0; i < NUM_LOOPS; i++) {
> 
> Signed-off-by: Anshuman Khandual 
> Signed-off-by: Simon Guo 

Reviewed-by: Cyril Bur 

> ---
>  tools/testing/selftests/powerpc/context_switch/cp_abort.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git
> a/tools/testing/selftests/powerpc/context_switch/cp_abort.c
> b/tools/testing/selftests/powerpc/context_switch/cp_abort.c
> index 5a5b55a..1ce7dce 100644
> --- a/tools/testing/selftests/powerpc/context_switch/cp_abort.c
> +++ b/tools/testing/selftests/powerpc/context_switch/cp_abort.c
> @@ -67,7 +67,7 @@ int test_cp_abort(void)
>   /* 128 bytes for a full cache line */
>   char buf[128] __cacheline_aligned;
>   cpu_set_t cpuset;
> - int fd1[2], fd2[2], pid;
> + int fd1[2], fd2[2], pid, i;
>   char c;
>  
>   /* only run this test on a P9 or later */
> @@ -87,14 +87,14 @@ int test_cp_abort(void)
>   FAIL_IF(pid < 0);
>  
>   if (!pid) {
> - for (int i = 0; i < NUM_LOOPS; i++) {
> + for (i = 0; i < NUM_LOOPS; i++) {
>   FAIL_IF((write(fd1[WRITE_FD], , 1)) != 1);
>   FAIL_IF((read(fd2[READ_FD], , 1)) != 1);
>   /* A paste succeeds if CR0 EQ bit is set */
>   FAIL_IF(paste(buf) & 0x2000);
>   }
>   } else {
> - for (int i = 0; i < NUM_LOOPS; i++) {
> + for (i = 0; i < NUM_LOOPS; i++) {
>   FAIL_IF((read(fd1[READ_FD], , 1)) != 1);
>   copy(buf);
>   FAIL_IF((write(fd2[WRITE_FD], , 1) != 1));


Re: [PATCH 0/4] Add V4L2_PIX_FMT_MT21C format for MT8173 codec driver

2016-09-13 Thread Tiffany Lin
Hi Hans,

On Thu, 2016-09-08 at 11:27 +0200, Hans Verkuil wrote:
> On 09/08/16 11:11, Tiffany Lin wrote:
> > Hi Hans,
> >
> > On Thu, 2016-09-08 at 09:21 +0200, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> On 09/07/2016 08:56 AM, Tiffany Lin wrote:
> >>> This patch series add Mediatek compressed block format 
> >>> V4L2_PIX_FMT_MT21C, the
> >>> decoder driver will decoded bitstream to V4L2_PIX_FMT_MT21C format.
> >>>
> >>> User space applications could use MT8173 MDP driver to convert 
> >>> V4L2_PIX_FMT_MT21C to
> >>> V4L2_PIX_FMT_NV12M, V4L2_PIX_FMT_YUV420M and V4L2_PIX_FMT_YVU420.
> >>>
> >>> MDP driver[1] is stand alone driver.
> >>>
> >>> Usage:
> >>> MT21C -> MT8173 MDP -> NV12M/YUV420M/YVU420
> >>> NV12M/NV21M/YUV420M/YVU420M -> mt8173 Encoder -> H264/VP8
> >>> H264/VP8/VP9 -> mtk8173 Decoder -> MT21C
> >>>
> >>> When encode with MT21 source, the pipeline will be:
> >>> MT21C -> MDP driver-> NV12M/NV21M/YUV420M/YVU420M -> Encoder -> H264/VP8
> >>>
> >>> When playback, the pipeline will be:
> >>> H264/VP8/VP9 -> Decoder driver -> MT21C -> MDP Driver -> DRM
> >>>
> >>> [1]https://patchwork.kernel.org/patch/9305329/
> >>>
> >>> Tiffany Lin (4):
> >>>   v4l: add Mediatek compressed video block format
> >>>   docs-rst: Add compressed video formats used on MT8173 codec driver
> >>>   vcodec: mediatek: Add V4L2_PIX_FMT_MT21C support for v4l2 decoder
> >>>   arm64: dts: mediatek: Add Video Decoder for MT8173
> >>>
> >>>  Documentation/media/uapi/v4l/pixfmt-reserved.rst   |6 +++
> >>>  arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   44 
> >>> 
> >>>  drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c |7 +++-
> >>>  drivers/media/v4l2-core/v4l2-ioctl.c   |1 +
> >>>  include/uapi/linux/videodev2.h |1 +
> >>>  5 files changed, 58 insertions(+), 1 deletion(-)
> >>>
> >>
> >> So basically the video decoder is useless without support for this format 
> >> and
> >> without the MDP driver, right?
> >>
> > Yes. It also require new vpu firmware.
> > Andrew will help release new vpu firmware include encode/decode/mdp
> > capability.
> 
> OK, then I'll park this until:
> 
> - the MT21C patch series is OK
> - the MDP patch series is OK
> - the new firmware is released
> 

> For the record: the decoder patch series is OK as far as I am concerned.
> It's in my mtkdec branch.
> 

Appreciated for your help.
We had upstream new MT21C, MDP and new VPU firmware.

MT21C patch series: https://patchwork.kernel.org/patch/9323883/
MDP patch series: https://patchwork.kernel.org/patch/9321343/
VPU firmware: https://patchwork.linuxtv.org/patch/36968/


best regards,
Tiffany



> Regards,
> 
>   Hans




Re: [PATCH v14 07/15] selftests/powerpc: Add ptrace tests for TAR, PPR, DSCR registers

2016-09-13 Thread Cyril Bur
On Mon, 2016-09-12 at 15:33 +0800, wei.guo.si...@gmail.com wrote:
> From: Anshuman Khandual 
> 
> This patch adds ptrace interface test for TAR, PPR, DSCR
> registers. This also adds ptrace interface based helper
> functions related to TAR, PPR, DSCR register access.
> 
> Signed-off-by: Anshuman Khandual 
> Signed-off-by: Simon Guo 
> ---
>  tools/testing/selftests/powerpc/ptrace/Makefile|   3 +-
>  .../testing/selftests/powerpc/ptrace/ptrace-tar.c  | 159
> ++
>  .../testing/selftests/powerpc/ptrace/ptrace-tar.h  |  50 ++
>  tools/testing/selftests/powerpc/ptrace/ptrace.h| 181
> +
>  4 files changed, 392 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/powerpc/ptrace/ptrace-
> tar.c
>  create mode 100644 tools/testing/selftests/powerpc/ptrace/ptrace-
> tar.h
> 

[snip]

> +
> +void tar(void)
> +{
> + unsigned long reg[3];
> + int ret;
> +
> + cptr = (int *)shmat(shm_id, NULL, 0);
> + printf("%-30s TAR: %u PPR: %lx DSCR: %u\n",
> + user_write, TAR_1, PPR_1, DSCR_1);
> +
> + mtspr(SPRN_TAR, TAR_1);
> + mtspr(SPRN_PPR, PPR_1);
> + mtspr(SPRN_DSCR, DSCR_1);
> +
> + cptr[2] = 1;
> +
> + /* Wait on parent */
> + while (!cptr[0]);
asm volatile("" ::: "memory");

> +
> + reg[0] = mfspr(SPRN_TAR);
> + reg[1] = mfspr(SPRN_PPR);
> + reg[2] = mfspr(SPRN_DSCR);
> +
> + printf("%-30s TAR: %lu PPR: %lx DSCR: %lu\n",
> + user_read, reg[0], reg[1], reg[2]);
> +
> + /* Unblock the parent now */
> + cptr[1] = 1;
> + shmdt((int *)cptr);
> +
> + ret = validate_tar_registers(reg, TAR_2, PPR_2, DSCR_2);
> + if (ret)
> + exit(1);
> + exit(0);
> +}
> +
> +int trace_tar(pid_t child)
> +{
> + unsigned long reg[3];
> + int ret;
> +
> + ret = start_trace(child);
> + if (ret)
> + return TEST_FAIL;
> +
> + ret = show_tar_registers(child, reg);
> + if (ret)
> + return TEST_FAIL;
> +
> + printf("%-30s TAR: %lu PPR: %lx DSCR: %lu\n",
> + ptrace_read_running, reg[0], reg[1],
> reg[2]);
> +
> + ret = validate_tar_registers(reg, TAR_1, PPR_1, DSCR_1);
> + if (ret)
> + return TEST_FAIL;
> +
> + ret = stop_trace(child);
> + if (ret)
> + return TEST_FAIL;
> +
> + return TEST_PASS;
> +}
> +
> +int trace_tar_write(pid_t child)
> +{
> + int ret;
> +
> + ret = start_trace(child);
> + if (ret)
> + return TEST_FAIL;
> +
> + ret = write_tar_registers(child, TAR_2, PPR_2, DSCR_2);
> + if (ret)
> + return TEST_FAIL;
> +
> + printf("%-30s TAR: %u PPR: %lx DSCR: %u\n",
> + ptrace_write_running, TAR_2, PPR_2, DSCR_2);
> +
> + ret = stop_trace(child);
> + if (ret)
> + return TEST_FAIL;
> +
> + return TEST_PASS;
> +}

More comments about calling TEST_FAIL(x)

> +
> +int ptrace_tar(void)
> +{
> + pid_t pid;
> + int ret, status;
> +
> + shm_id = shmget(IPC_PRIVATE, sizeof(int) * 3,
> 0777|IPC_CREAT);
> + pid = fork();
> + if (pid < 0) {
> + perror("fork() failed");
> + return TEST_FAIL;
> + }
> +
> + if (pid == 0)
> + tar();
> +
> + if (pid) {
> 

[snip]


Re: [PATCH v14 04/15] selftests/powerpc: Add ptrace tests for GPR/FPR registers

2016-09-13 Thread Cyril Bur
On Mon, 2016-09-12 at 15:33 +0800, wei.guo.si...@gmail.com wrote:
> From: Anshuman Khandual 
> 
> This patch adds ptrace interface test for GPR/FPR registers.
> This adds ptrace interface based helper functions related to
> GPR/FPR access and some assembly helper functions related to
> GPR/FPR registers.
> 
> Signed-off-by: Anshuman Khandual 
> Signed-off-by: Simon Guo 
> ---
>  tools/testing/selftests/powerpc/ptrace/Makefile|   3 +-
>  .../testing/selftests/powerpc/ptrace/ptrace-gpr.c  | 196
> +++
>  .../testing/selftests/powerpc/ptrace/ptrace-gpr.h  |  74 
>  tools/testing/selftests/powerpc/ptrace/ptrace.S| 131
> +
>  tools/testing/selftests/powerpc/ptrace/ptrace.h| 211
> +
>  5 files changed, 614 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/powerpc/ptrace/ptrace-
> gpr.c
>  create mode 100644 tools/testing/selftests/powerpc/ptrace/ptrace-
> gpr.h
>  create mode 100644 tools/testing/selftests/powerpc/ptrace/ptrace.S
> 

[snip]

> new file mode 100644
> index 000..193beea
> --- /dev/null
> +++ b/tools/testing/selftests/powerpc/ptrace/ptrace.S
> @@ -0,0 +1,131 @@
> +/*
> + * Ptrace interface test helper assembly functions
> + *
> + * Copyright (C) 2015 Anshuman Khandual, IBM Corporation.
> + *
> + * 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.
> + */
> +#include 
> +#include "../reg.h"
> +
> +
> +/* Non volatile GPR - unsigned long buf[18] */
> +FUNC_START(load_gpr)
> + ld  14, 0*8(3)
> + ld  15, 1*8(3)
> + ld  16, 2*8(3)
> + ld  17, 3*8(3)
> + ld  18, 4*8(3)
> + ld  19, 5*8(3)
> + ld  20, 6*8(3)
> + ld  21, 7*8(3)
> + ld  22, 8*8(3)
> + ld  23, 9*8(3)
> + ld  24, 10*8(3)
> + ld  25, 11*8(3)
> + ld  26, 12*8(3)
> + ld  27, 13*8(3)
> + ld  28, 14*8(3)
> + ld  29, 15*8(3)
> + ld  30, 16*8(3)
> + ld  31, 17*8(3)
> + blr
> +FUNC_END(load_gpr)
> +
> +FUNC_START(store_gpr)
> + std 14, 0*8(3)
> + std 15, 1*8(3)
> + std 16, 2*8(3)
> + std 17, 3*8(3)
> + std 18, 4*8(3)
> + std 19, 5*8(3)
> + std 20, 6*8(3)
> + std 21, 7*8(3)
> + std 22, 8*8(3)
> + std 23, 9*8(3)
> + std 24, 10*8(3)
> + std 25, 11*8(3)
> + std 26, 12*8(3)
> + std 27, 13*8(3)
> + std 28, 14*8(3)
> + std 29, 15*8(3)
> + std 30, 16*8(3)
> + std 31, 17*8(3)
> + blr
> +FUNC_END(store_gpr)
> +
> +/* Single Precision Float - float buf[32] */
> +FUNC_START(load_fpr)
> + lfs 0, 0*4(3)
> + lfs 1, 1*4(3)
> + lfs 2, 2*4(3)
> + lfs 3, 3*4(3)
> + lfs 4, 4*4(3)
> + lfs 5, 5*4(3)
> + lfs 6, 6*4(3)
> + lfs 7, 7*4(3)
> + lfs 8, 8*4(3)
> + lfs 9, 9*4(3)
> + lfs 10, 10*4(3)
> + lfs 11, 11*4(3)
> + lfs 12, 12*4(3)
> + lfs 13, 13*4(3)
> + lfs 14, 14*4(3)
> + lfs 15, 15*4(3)
> + lfs 16, 16*4(3)
> + lfs 17, 17*4(3)
> + lfs 18, 18*4(3)
> + lfs 19, 19*4(3)
> + lfs 20, 20*4(3)
> + lfs 21, 21*4(3)
> + lfs 22, 22*4(3)
> + lfs 23, 23*4(3)
> + lfs 24, 24*4(3)
> + lfs 25, 25*4(3)
> + lfs 26, 26*4(3)
> + lfs 27, 27*4(3)
> + lfs 28, 28*4(3)
> + lfs 29, 29*4(3)
> + lfs 30, 30*4(3)
> + lfs 31, 31*4(3)
> + blr
> +FUNC_END(load_fpr)
> +
> +FUNC_START(store_fpr)
> + stfs 0, 0*4(3)
> + stfs 1, 1*4(3)
> + stfs 2, 2*4(3)
> + stfs 3, 3*4(3)
> + stfs 4, 4*4(3)
> + stfs 5, 5*4(3)
> + stfs 6, 6*4(3)
> + stfs 7, 7*4(3)
> + stfs 8, 8*4(3)
> + stfs 9, 9*4(3)
> + stfs 10, 10*4(3)
> + stfs 11, 11*4(3)
> + stfs 12, 12*4(3)
> + stfs 13, 13*4(3)
> + stfs 14, 14*4(3)
> + stfs 15, 15*4(3)
> + stfs 16, 16*4(3)
> + stfs 17, 17*4(3)
> + stfs 18, 18*4(3)
> + stfs 19, 19*4(3)
> + stfs 20, 20*4(3)
> + stfs 21, 21*4(3)
> + stfs 22, 22*4(3)
> + stfs 23, 23*4(3)
> + stfs 24, 24*4(3)
> + stfs 25, 25*4(3)
> + stfs 26, 26*4(3)
> + stfs 27, 27*4(3)
> + stfs 28, 28*4(3)
> + stfs 29, 29*4(3)
> + stfs 30, 30*4(3)
> + stfs 31, 31*4(3)
> + blr
> +FUNC_END(store_fpr)

I wrote similar functions in math/fpu_asm.S perhaps it would be time
consolidate those and these into an fpu_asm.S file at a higher level,
TM related tests would benefit as well.

> diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace.h
> b/tools/testing/selftests/powerpc/ptrace/ptrace.h
> index fbf73ca..1019004 100644
> --- a/tools/testing/selftests/powerpc/ptrace/ptrace.h
> +++ 

Re: [PATCH v14 05/15] selftests/powerpc: Add ptrace tests for GPR/FPR registers in TM

2016-09-13 Thread Cyril Bur
On Mon, 2016-09-12 at 15:33 +0800, wei.guo.si...@gmail.com wrote:
> From: Anshuman Khandual 
> 
> This patch adds ptrace interface test for GPR/FPR registers
> inside TM context. This adds ptrace interface based helper
> functions related to checkpointed GPR/FPR access.
> 
> Signed-off-by: Anshuman Khandual 
> Signed-off-by: Simon Guo 
> ---
>  tools/testing/selftests/powerpc/ptrace/Makefile|   3 +-
>  .../selftests/powerpc/ptrace/ptrace-tm-gpr.c   | 296
> +
>  2 files changed, 298 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/powerpc/ptrace/ptrace-tm-
> gpr.c
> 
> diff --git a/tools/testing/selftests/powerpc/ptrace/Makefile
> b/tools/testing/selftests/powerpc/ptrace/Makefile
> index 31e8e33..170683a 100644
> --- a/tools/testing/selftests/powerpc/ptrace/Makefile
> +++ b/tools/testing/selftests/powerpc/ptrace/Makefile
> @@ -1,8 +1,9 @@
> -TEST_PROGS := ptrace-ebb ptrace-gpr
> +TEST_PROGS := ptrace-ebb ptrace-gpr ptrace-tm-gpr
>  
>  all: $(TEST_PROGS)
>  CFLAGS += -m64
>  $(TEST_PROGS): ../harness.c ptrace.S ../utils.c ptrace.h
>  ptrace-ebb: ../pmu/event.c ../pmu/lib.c ../pmu/ebb/ebb_handler.S
> ../pmu/ebb/busy_loop.S
> +
>  clean:
>   rm -f $(TEST_PROGS) *.o
> diff --git a/tools/testing/selftests/powerpc/ptrace/ptrace-tm-gpr.c
> b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-gpr.c
> new file mode 100644
> index 000..8417d04
> --- /dev/null
> +++ b/tools/testing/selftests/powerpc/ptrace/ptrace-tm-gpr.c
> @@ -0,0 +1,296 @@
> +/*
> + * Ptrace test for GPR/FPR registers in TM context
> + *
> + * Copyright (C) 2015 Anshuman Khandual, IBM Corporation.
> + *
> + * 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.
> + */
> +#include "ptrace.h"
> +#include "ptrace-gpr.h"
> +
> +/* Tracer and Tracee Shared Data */
> +int shm_id;
> +volatile unsigned long *cptr, *pptr;
> +
> +float a = FPR_1;
> +float b = FPR_2;
> +float c = FPR_3;
> +
> +void tm_gpr(void)
> +{
> + unsigned long gpr_buf[18];
> + unsigned long result, texasr;
> + float fpr_buf[32];
> +
> + printf("Starting the child\n");
> + cptr = (unsigned long *)shmat(shm_id, NULL, 0);
> +
> +trans:
> + cptr[1] = 0;
> + asm __volatile__(
> +
> + "li 14, %[gpr_1];"
> + "li 15, %[gpr_1];"
> + "li 16, %[gpr_1];"
> + "li 17, %[gpr_1];"
> + "li 18, %[gpr_1];"
> + "li 19, %[gpr_1];"
> + "li 20, %[gpr_1];"
> + "li 21, %[gpr_1];"
> + "li 22, %[gpr_1];"
> + "li 23, %[gpr_1];"
> + "li 24, %[gpr_1];"
> + "li 25, %[gpr_1];"
> + "li 26, %[gpr_1];"
> + "li 27, %[gpr_1];"
> + "li 28, %[gpr_1];"
> + "li 29, %[gpr_1];"
> + "li 30, %[gpr_1];"
> + "li 31, %[gpr_1];"
> +
> + "lfs 0, 0(%[flt_1]);"
> + "lfs 1, 0(%[flt_1]);"
> + "lfs 2, 0(%[flt_1]);"
> + "lfs 3, 0(%[flt_1]);"
> + "lfs 4, 0(%[flt_1]);"
> + "lfs 5, 0(%[flt_1]);"
> + "lfs 6, 0(%[flt_1]);"
> + "lfs 7, 0(%[flt_1]);"
> + "lfs 8, 0(%[flt_1]);"
> + "lfs 9, 0(%[flt_1]);"
> + "lfs 10, 0(%[flt_1]);"
> + "lfs 11, 0(%[flt_1]);"
> + "lfs 12, 0(%[flt_1]);"
> + "lfs 13, 0(%[flt_1]);"
> + "lfs 14, 0(%[flt_1]);"
> + "lfs 15, 0(%[flt_1]);"
> + "lfs 16, 0(%[flt_1]);"
> + "lfs 17, 0(%[flt_1]);"
> + "lfs 18, 0(%[flt_1]);"
> + "lfs 19, 0(%[flt_1]);"
> + "lfs 20, 0(%[flt_1]);"
> + "lfs 21, 0(%[flt_1]);"
> + "lfs 22, 0(%[flt_1]);"
> + "lfs 23, 0(%[flt_1]);"
> + "lfs 24, 0(%[flt_1]);"
> + "lfs 25, 0(%[flt_1]);"
> + "lfs 26, 0(%[flt_1]);"
> + "lfs 27, 0(%[flt_1]);"
> + "lfs 28, 0(%[flt_1]);"
> + "lfs 29, 0(%[flt_1]);"
> + "lfs 30, 0(%[flt_1]);"
> + "lfs 31, 0(%[flt_1]);"
> +

There was this in the previous patch? Can we consolidate?

> + "1: ;"
> + TBEGIN

tbegin. is probably fine

> + "beq 2f;"
> +
> + "li 14, %[gpr_2];"
> + "li 15, %[gpr_2];"
> + "li 16, %[gpr_2];"
> + "li 17, %[gpr_2];"
> + "li 18, %[gpr_2];"
> + "li 19, %[gpr_2];"
> + "li 20, %[gpr_2];"
> + "li 21, %[gpr_2];"
> + "li 22, %[gpr_2];"
> + "li 23, %[gpr_2];"
> + "li 24, %[gpr_2];"
> + "li 25, %[gpr_2];"
> + "li 26, 

Re: [PATCH v3 07/15] lockdep: Implement crossrelease feature

2016-09-13 Thread Byungchul Park
On Wed, Sep 14, 2016 at 11:27 AM, Byungchul Park
 wrote:
> On Wed, Sep 14, 2016 at 4:38 AM, Peter Zijlstra  wrote:
>> On Wed, Sep 14, 2016 at 02:12:51AM +0900, Byungchul Park wrote:
>>> On Wed, Sep 14, 2016 at 12:05 AM, Peter Zijlstra  
>>> wrote:
>>> >
>>> >
>>> > So the idea is to add support for non-owner serialization primitives,
>>> > like completions/semaphores, and so far I've not looked at the code yet.
>>> > I did spend 2+ hours trying to decipher your documentation thing, but am
>>> > still confused, that thing is exceedingly hard to parse/read.
>>> >
>>> > So the typical scenario would be something like:
>>> >
>>> > L a L a
>>> > U a
>>> > W b C b
>>> >
>>> > where L := lock, U := unlock, W := wait_for_completion and C :=
>>> > complete.
>>> >
>>> > On the left, the blocking thread we can easily observe the 'b depends on
>>> > a' relation, since we block while holding a.
>>>
>>> I think 'a depends on b' relation.
>>>
>>> Why does b depend on a? b depends on a's what?
>>
>> b blocks while holding a. In any case, for the graph it doesn't matter,
>> its not a directed graph as such, all we care about is acyclic.
>
> It's a directed graph.The meaning of backward traverse is different
> from the meaning of forward traverse, isn't it?
>
>>> > On the right however that same relation is hard to see, since by the
>>>
>>> Yes, there's no dependency on the right side of your example.
>>
>> Well, there is, its just not trivially observable. We must be able to
>> acquire a in order to complete b, therefore there is a dependency.
>
> No. We cannot say there is a dependency unconditionally. There can
> be a dependency or not.
>
> L a L a
> U a
> ~ what if serialized by something?
> W b C b
>
> If something we don't recognize serializes locks, which ensures
> 'W b' happens after 'L a , U a' in the other context, then there's
> no dependency here.
>
> We should say 'b depends on a' in only case that the sequence
> 'W b and then L a and then C b, where last two ops are in same
> context' _actually_ happened at least once. Otherwise, it might
> add a false dependency.
>
> It's same as how original lockdep works with typical locks. It adds
> a dependency only when a lock is actually hit.
>
>>> > time we would run complete, a has already been released.
>>>
>>> I will change your example a little bit.
>>>
>>> W b
>>> ~~~ <- serialized
>>> L a
>>> U a
>>> C b
>>>
>>> (Remind crossrelease considers dependencies in only case that
>>> lock sequence serialized is observable.)
>>
>> What does that mean? Any why? This is a random point in time without
>> actual meaning.
>
> It's not random point. We have to consider meaningful sequences among
> those which are globally observable. That's why we need to serialize
> those locks. For example,
>
> W b
> L a
> U a
> C b
>
> Once this sequence is observable globally, we can say 'It's possible to
> run in this sequence. Is this sequence problematic or not?'.
>
> L a
> U a
> W b
> C b
>
> If only this sequence can be observable, we should not assume
> this sequence can be changed. However once the former sequence
> happens, it has a possibility to hit the same sequence again later.
> So we can check deadlock possibility with the sequence,
>
> _not randomly_.
>
>>> There's a dependency in this case, like 'b depends on a' relation.
>>> 'C b' may not be hit, depending on the result of 'L a', that is,
>>> acquired or not.
>>
>> With or without a random reference point, the dependency is there.
>
> The dependency might not be there.
>
>>> > I _think_ you propose to keep track of all prior held locks and then use
>>> > the union of the held list on the block-chain with the prior held list
>>> > from the complete context.
>>>
>>> Almost right. Only thing we need to do to consider the union is to
>>> connect two chains of two contexts by adding one dependency 'b -> a'.
>>
>> Sure, but how do you arrive at which connection to make. The document is
>> entirely silent on this crucial point.
>
> We need to connect between the crosslock and the first lock among
> locks having been acquired since the crosslock was held. Others will be
> connected each other by original lockdep.
>
> By the way, does my document miss this description? If so, sorry.
> I will check and update it.
>
>> The union between the held-locks of the blocked and prev-held-locks of
>> the release should give a fair indication I think, but then, I've not
>> thought too hard on this yet.
>
> I make the union only If actually the lock sequence happened once so
> that it's globally visible.
>
>>> > The document describes you have a prior held list, and that its a
>>> > circular thing, but it then completely fails to specify what gets added
>>> > and how its used.
>>>
>>> Why does it fail? It keeps them in the form of hlock. This data is enough
>>> to generate dependencies.
>>
>> It fails to 

Re: [PATCH v14 01/15] selftests/powerpc: Add more SPR numbers, TM & VMX instructions to 'reg.h'

2016-09-13 Thread Cyril Bur
On Mon, 2016-09-12 at 15:33 +0800, wei.guo.si...@gmail.com wrote:
> From: Anshuman Khandual 
> 
> This patch adds SPR number for TAR, PPR, DSCR special
> purpose registers. It also adds TM, VSX, VMX related
> instructions which will then be used by patches later
> in the series.
> 
> Signed-off-by: Anshuman Khandual 
> Signed-off-by: Simon Guo 
> ---
>  tools/testing/selftests/powerpc/reg.h | 42
> ---
>  1 file changed, 39 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/testing/selftests/powerpc/reg.h
> b/tools/testing/selftests/powerpc/reg.h
> index fddf368..fee7be9 100644
> --- a/tools/testing/selftests/powerpc/reg.h
> +++ b/tools/testing/selftests/powerpc/reg.h
> @@ -18,6 +18,19 @@
>  
>  #define mb() asm volatile("sync" : : : "memory");
>  
> +/* Vector Instructions */
> +#define VSX_XX1(xs, ra, rb)  (((xs) & 0x1f) << 21 | ((ra) <<
> 16) |  \
> +  ((rb) << 11) | (((xs) >> 5)))
> +#define STXVD2X(xs, ra, rb)  .long (0x7c000798 | VSX_XX1((xs),
> (ra), (rb)))
> +#define LXVD2X(xs, ra, rb)   .long (0x7c000698 | VSX_XX1((xs),
> (ra), (rb)))

Theres an instructions.h file in tools/testing/selftests/powerpc/ would
these be better suited there?

> +
> +/* TM instructions */
> +#define TBEGIN   ".long 0x7C00051D;"
> +#define TABORT   ".long 0x7C00071D;"
> +#define TEND ".long 0x7C00055D;"
> +#define TSUSPEND ".long 0x7C0005DD;"
> +#define TRESUME  ".long 0x7C2005DD;"
> +

These are only useful on old compilers that don't know about TM. For
selftests I would discourage creating these and using the actual
instructions, they are fairly well known today by most compilers.

>  #define SPRN_MMCR2 769
>  #define SPRN_MMCRA 770
>  #define SPRN_MMCR0 779
> @@ -51,10 +64,33 @@
>  #define SPRN_SDAR  781
>  #define SPRN_SIER  768
>  
> -#define SPRN_TEXASR 0x82
> +#define SPRN_TEXASR 0x82/* Transaction Exception and Status
> Register */
>  #define SPRN_TFIAR  0x81/* Transaction Failure Inst
> Addr*/
>  #define SPRN_TFHAR  0x80/* Transaction Failure Handler Addr
> */
> -#define TEXASR_FS   0x0800
> -#define SPRN_TAR0x32f
> +#define SPRN_TAR0x32f/* Target Address Register */
> +
> +#define SPRN_DSCR_PRIV 0x11  /* Privilege State DSCR */
> +#define SPRN_DSCR  0x03  /* Data Stream Control Register
> */
> +#define SPRN_PPR   896   /* Program Priority Register */
> +
> +/* TEXASR register bits */
> +#define TEXASR_FC0xFE00
> +#define TEXASR_FP0x0100
> +#define TEXASR_DA0x0080
> +#define TEXASR_NO0x0040
> +#define TEXASR_FO0x0020
> +#define TEXASR_SIC   0x0010
> +#define TEXASR_NTC   0x0008
> +#define TEXASR_TC0x0004
> +#define TEXASR_TIC   0x0002
> +#define TEXASR_IC0x0001
> +#define TEXASR_IFC   0x8000
> +#define TEXASR_ABT   0x0001
> +#define TEXASR_SPD   0x8000
> +#define TEXASR_HV0x2000
> +#define TEXASR_PR0x1000
> +#define TEXASR_FS0x0800
> +#define TEXASR_TE0x0400
> +#define TEXASR_ROT   0x0200
>  
>  #endif /* _SELFTESTS_POWERPC_REG_H */


Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz

2016-09-13 Thread H. Nikolaus Schaller
Hi,

> Am 14.09.2016 um 00:07 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [160910 02:10]:
>>> Am 10.09.2016 um 10:20 schrieb Matthijs van Duin 
>>> :
>> 
>> But with the patch submitted, I just want to give the dts of a single
>> device I have even designed a more reasonable value than in current
>> linux/master and don't really want to make it a fundamental discussion...
> 
> So what's the verdict here on this patch? Should we wait for the driver
> to get fixed?

No, because it are indeed two issues which can (and should) be fixed 
independently.
This one just makes the urgency of the other bug smaller.

BR and thanks,
Nikolaus



linux-next: build failure after merge of the pm tree

2016-09-13 Thread Stephen Rothwell
Hi Rafael,

After merging the pm tree, today's linux-next build (powerpc allyesconfig)
failed like this:

drivers/devfreq/tegra-devfreq.c: In function 'tegra_devfreq_target':
drivers/devfreq/tegra-devfreq.c:500:2: error: implicit declaration of function 
'clk_set_min_rate' [-Werror=implicit-function-declaration]
  clk_set_min_rate(tegra->emc_clock, rate);
  ^

Caused by commit

  797da5598f3a ("PM / devfreq: Add COMPILE_TEST for build coverage")

clk_set_min_rate() usage depends on CONFIG_HAVE_CLK.

I added the following for today:

From: Stephen Rothwell 
Date: Wed, 14 Sep 2016 14:22:25 +1000
Subject: [PATCH] partial revert of 797da5598f3a ("PM / devfreq: Add
 COMPILE_TEST for build coverage")

Signed-off-by: Stephen Rothwell 
---
 drivers/devfreq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index cadd56e50b2c..93b6ada06676 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -92,7 +92,7 @@ config ARM_EXYNOS_BUS_DEVFREQ
 
 config ARM_TEGRA_DEVFREQ
tristate "Tegra DEVFREQ Driver"
-   depends on ARCH_TEGRA_124_SOC || COMPILE_TEST
+   depends on ARCH_TEGRA_124_SOC
select DEVFREQ_GOV_SIMPLE_ONDEMAND
select PM_OPP
help
-- 
2.8.1




-- 
Cheers,
Stephen Rothwell


Re: kvm-unit-test fail for split irqchip

2016-09-13 Thread Wanpeng Li
2016-09-14 4:43 GMT+08:00 Paolo Bonzini :
>
>
> On 13/09/2016 21:01, Radim Krcmar wrote:
>> kvm_handle_interrupt() does
>>
>>   interrupt_request |= CPU_INTERRUPT_HARD
>>
>> which later calls cpu_get_pic_interrupt() in kvm_arch_pre_run(), but
>> that function uses stale information from APIC and injects 62 again.
>> If we synchronized the APIC, then the test would #GP, because there
>> would be no injectable interrupt in LAPIC or PIC, so pic_read_irq()
>> would return 15, thinking it was spurious.
>>
>> I think the bug starts in pic_irq_request(), which should not touch
>> LAPIC.  The patch below makes it work (just the second hunk is
>> sufficient), but it's still far from sane code ...
>
> This makes sense.  Most of the functions exported by hw/intc/apic.c
> should only be used with a userspace APIC:
>
> 0b70 T apic_accept_pic_intr
> 10f0 T apic_deliver_irq
> 11e0 T apic_deliver_pic_intr
> 1310 T apic_get_interrupt
> 1270 T apic_poll_irq
> 0a40 T apic_sipi
>
> The patch is okay, though for consistency with other code I'd use
> !kvm_irqchip_in_kernel() rather than !kvm_irqchip_is_split().
>
> Wanpeng, can you do that,

Yeah, I just sent out a patch to fix the bug. Thanks for the long
discussion with me and thanks Radim's proposal. :)

> and change hw/intc/apic.c to use a new casting
> macro
>
> APICCommonState *s = APIC(dev);
>
> instead of APIC_COMMON?
>

I'm not familiar with QOM too much, what APIC macro do you like?

Regards,
Wanpeng Li


Re: kvm-unit-test fail for split irqchip

2016-09-13 Thread Wanpeng Li
2016-09-14 3:01 GMT+08:00 Radim Krcmar :
> 2016-09-13 19:06+0800, Wanpeng Li:
>> Add -kernel_irqchip=split
>> ./x86-run x86/eventinj.flat
>>
>> qemu-system-x86_64 -enable-kvm -machine kernel_irqchip=split -cpu host
>> -device pc-testdev -device isa-debug-exit,iobase=0xf4,iosize=0x4 -vnc
>> none -serial stdio -device pci-testdev -kernel x86/eventinj.flat
>> enabling apic
>> paging enabled
>> cr0 = 80010011
>> cr3 = 7fff000
>> cr4 = 20
>> Sending vec 33 and 62 and mask one with TPR
>> irq1 running
>> irq1 running
>> After 33/62 TPR test
>> FAIL: TPR
>> irq0 running
>> irq0 running
>>
>> Both irq1 and irq0 are executing twice.
>>
>>  qemu-system-x86-22794 [001] d..2 34591.708476: kvm_entry: vcpu 0
>>  qemu-system-x86-22794 [001] ...1 34591.708478: kvm_exit: reason
>> MSR_WRITE rip 0x401f33 info 0 0
>>  qemu-system-x86-22794 [001] ...1 34591.708478: kvm_apic: apic_write
>> APIC_EOI = 0x0
>>  qemu-system-x86-22794 [001] ...1 34591.708479: kvm_eoi: apicid 0 vector 62
>>  qemu-system-x86-22794 [001] ...1 34591.708479: kvm_msr: msr_write 80b = 0x0
>>  qemu-system-x86-22794 [001] d..2 34591.708480: kvm_entry: vcpu 0
>>  qemu-system-x86-22794 [001] ...1 34591.708482: kvm_exit: reason
>> PENDING_INTERRUPT rip 0x401f35 info 0 0
>>  qemu-system-x86-22794 [001] ...1 34591.708482: kvm_userspace_exit:
>> reason KVM_EXIT_IRQ_WINDOW_OPEN (7)
>>  qemu-system-x86-22794 [001] ...1 34591.708491: kvm_inj_virq: irq 62
>>  qemu-system-x86-22794 [001] d..2 34591.708492: kvm_entry: vcpu 0
>>  qemu-system-x86-22794 [001] ...1 34591.708493: kvm_exit: reason
>> IO_INSTRUCTION rip 0x4016ec info 3fd0008 0
>>
>> From the trace we can see there is an interrupt window exit after the
>> first interrupt EOI(irq 62), and the same irq(62) is injected
>> duplicately after the interrupt window.
>>
>> The bug can disappear if kernel_irqchip is on or -x2apic, the virtual
>> x2apic mode will not be set due to commit (8d14695f9542 x86, apicv:
>> add virtual x2apic support), so that tpr shadow in the x2apic doesn't
>> work and wrmsr TPR register will trigger vmexit, and then kvmvapic
>> will be used to optimize flexpriority=N or AMD. The
>> report_trp_access() which is called in kvm_lapic_reg_write() will
>> trigger a userspace exit.
>>
>> TPR report access callbacks in qemu, kvm_handle_tpr_access() ->
>> apic_handle_tpr_access_report() -> vapic_report_tpr_access() ->
>> cpu_synchronize_state() will get apic register states from kvm.
>>
>> Later, kvm_arch_pre_run -> cpu_get_pic_interrupt(if there is a pic
>> interrupt) -> apic_get_interrupt,  it is a pic interrupt, however it
>> gets the stale irq from apic register sync by report tpr access and
>> KVM_INTERRUPT the second duplicate interrupt.
>>
>> Paolo pointed out it is not the TPR associated bug, and we should
>> figure out why there is an interrupt window exit after the first EOI.
>
> Yeah, seems like QEMU bug.  QEMU does KVM_INTERRUPT(62) ioctl after KVM
> exits with KVM_EXIT_IRQ_WINDOW_OPEN, which QEMU requested while the
> guest was printing.  The printing calls
>
>   serial_update_irq() -> qemu_irq_lower() -> qemu_set_irq() ->
>   gsi_handler() -> qemu_set_irq() -> pic_irq_request() ->
>   apic_deliver_pic_intr() -> kvm_handle_interrupt()
>
> kvm_handle_interrupt() does
>
>   interrupt_request |= CPU_INTERRUPT_HARD
>
> which later calls cpu_get_pic_interrupt() in kvm_arch_pre_run(), but
> that function uses stale information from APIC and injects 62 again.
> If we synchronized the APIC, then the test would #GP, because there
> would be no injectable interrupt in LAPIC or PIC, so pic_read_irq()
> would return 15, thinking it was spurious.
>
> I think the bug starts in pic_irq_request(), which should not touch
> LAPIC.  The patch below makes it work (just the second hunk is
> sufficient), but it's still far from sane code ...

Thanks for the analysis, Radim! :)

Regards,
Wanpeng Li


Re: [PATCH 2/2] tools/testing/nvdimm: test get_config_size DSM failures

2016-09-13 Thread kbuild test robot
Hi Dan,

[auto build test WARNING on next-20160913]
[cannot apply to pm/linux-next linus/master linux/master v4.8-rc6 v4.8-rc5 
v4.8-rc4 v4.8-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Dan-Williams/nfit-fail-DSMs-that-return-non-zero-status-by-default/20160914-093545
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   tools/testing/nvdimm//test/nfit.c: In function 'handle_show':
>> tools/testing/nvdimm//test/nfit.c:609:26: warning: format '%lx' expects 
>> argument of type 'long unsigned int', but argument 3 has type 'u32 {aka 
>> unsigned int}' [-Wformat=]
 return sprintf(buf, "%#lx", handle[dimm]);
 ^

vim +609 tools/testing/nvdimm//test/nfit.c

   593  
   594  if (sscanf(dev_name(dev), "test_dimm%d", ) != 1
   595  || dimm >= NUM_DCR || dimm < 0)
   596  return -ENXIO;
   597  return dimm;
   598  }
   599  
   600  
   601  static ssize_t handle_show(struct device *dev, struct device_attribute 
*attr,
   602  char *buf)
   603  {
   604  int dimm = dimm_name_to_id(dev);
   605  
   606  if (dimm < 0)
   607  return dimm;
   608  
 > 609  return sprintf(buf, "%#lx", handle[dimm]);
   610  }
   611  DEVICE_ATTR_RO(handle);
   612  
   613  static ssize_t fail_cmd_show(struct device *dev, struct 
device_attribute *attr,
   614  char *buf)
   615  {
   616  int dimm = dimm_name_to_id(dev);
   617  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


[PATCH] driver-core: platform: Catch errors from calls to irq_get_irq_data

2016-09-13 Thread Guenter Roeck
irq_get_irq_data() can return NULL, which results in a nasty crash.
Check its return value before passing it on to irqd_set_trigger_type().

Signed-off-by: Guenter Roeck 
---
 drivers/base/platform.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 6482d47deb50..521c8ff28158 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -108,9 +108,14 @@ int platform_get_irq(struct platform_device *dev, unsigned 
int num)
 * IORESOURCE_BITS correspond 1-to-1 to the IRQF_TRIGGER*
 * settings.
 */
-   if (r && r->flags & IORESOURCE_BITS)
-   irqd_set_trigger_type(irq_get_irq_data(r->start),
- r->flags & IORESOURCE_BITS);
+   if (r && r->flags & IORESOURCE_BITS) {
+   struct irq_data *irqd;
+
+   irqd = irq_get_irq_data(r->start);
+   if (!irqd)
+   return -ENXIO;
+   irqd_set_trigger_type(irqd, r->flags & IORESOURCE_BITS);
+   }
 
return r ? r->start : -ENXIO;
 #endif
-- 
2.5.0



Re: [PATCH v4 2/5] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support

2016-09-13 Thread Fabio Estevam
On Sun, Sep 11, 2016 at 3:30 PM, Jagan Teki  wrote:

> + {
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_gpmi_nand>;
> +   fsl,legacy-bch-geometry;

I don't see this property documented nor used anywhere.


Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

2016-09-13 Thread Peter Chen
On Tue, Sep 13, 2016 at 06:42:46PM -0700, Stephen Boyd wrote:
> On the db410c 96boards platform we have a TC7USB40MU[1] on the
> board to mux the D+/D- lines from the SoC between a micro usb
> "device" port and a USB hub for "host" roles. Upon a role switch,
> we need to change this mux to forward the D+/D- lines to either
> the port or the hub. Therefore, introduce a driver for this
> device that intercepts extcon USB_HOST events and logically
> asserts a gpio to mux the "host" D+/D- lines when a host cable is
> attached. When the cable goes away, it will logically deassert
> the gpio and mux the "device" lines.

Would you please draw the design? It can also help me review your
chipidea patch well.

1. How many ports on the board?
2. How the lines are connected on the board?

Peter
> 
> [1] 
> https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> 
> Cc: MyungJoo Ham 
> Cc: Chanwoo Choi 
> Cc: 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Should I make the extcon part optional? I could see a case where there are two
> "OTG" ports connected to the mux (or two hubs), and for some reason the
> software may want to mux between them at runtime. If we mandate an extcon,
> that won't be possible to support. Perhaps it would be better to have
> the node, but connect it to the usb controller with a phandle (maybe of_graph
> endpoints would be useful too) so that when the controller wants to mux over
> a port it can do so.
> 
> Muxing the ports this way based on ID cable is pretty much a software
> design decision. We could mux the ports during the role switch, and the
> role switch can be entirely userspace driven with the chipidea controller
> that I'm using (see the role switching support in the "role" file for
> debugfs support in that driver). So extcon cables don't come into the picture
> in that scenario.
> 
>  .../devicetree/bindings/usb/toshiba,tc7usb40mu.txt |  34 +++
>  drivers/usb/misc/Kconfig   |   9 ++
>  drivers/usb/misc/Makefile  |   1 +
>  drivers/usb/misc/tc7usb40mu.c  | 107 
> +
>  4 files changed, 151 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt
>  create mode 100644 drivers/usb/misc/tc7usb40mu.c
> 
> diff --git a/Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt 
> b/Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt
> new file mode 100644
> index ..18e6607408fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt
> @@ -0,0 +1,34 @@
> +Toshiba TC7USB40MU
> +
> +This device muxes USB D+/D- lines between two outputs called 1D+/1D- and 
> 2D+/2D-.
> +When the switch pin is asserted, we mux out 2D+/2D-, and when it's 
> deasserted we
> +select 1D+/1D-.
> +
> +This can be used to mux USB D+/D- lines between a USB hub and an OTG port.
> +
> +PROPERTIES
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "toshiba,tc7usb40mu"
> +
> +- switch-gpios:
> +Usage: required
> +Value type: 
> +Definition: Should contain the gpio used to toggle the switch. Logically
> +asserting the gpio will cause the device to mux the "host"
> +D+/D- lines instead of the "device" lines.
> +
> +- extcon:
> +Usage: required
> +Value type: 
> +Definition: Should contain the extcon device for USB_HOST cable events
> +
> +Example:
> +
> + usb-switch {
> + compatible = "toshiba,tc7usb40mu";
> + switch-gpios = < 10 GPIO_ACTIVE_HIGH>;
> + extcon = <_id>;
> + };
> diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
> index 47b357760afc..3da568c751d2 100644
> --- a/drivers/usb/misc/Kconfig
> +++ b/drivers/usb/misc/Kconfig
> @@ -46,6 +46,15 @@ config USB_SEVSEG
> To compile this driver as a module, choose M here: the
> module will be called usbsevseg.
>  
> +config USB_TC7USB40MU
> + tristate "TC7USB40MU USB mux support"
> + depends on (GPIOLIB && EXTCON) || COMPILE_TEST
> + help
> +   Say Y here if you have a TC7USB40MU by Toshiba. If a USB ID cable is
> +   present, a gpio will be asserted to mux out "host" D+/D- lines and 
> when
> +   the ID cable is removed, a gpio will be deasserted to mux out "device"
> +   D+/D- lines.
> +
>  config USB_RIO500
>   tristate "USB Diamond Rio500 support"
>   help
> diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
> index 3d1992750da4..d8f9ad1dee13 100644
> --- a/drivers/usb/misc/Makefile
> +++ b/drivers/usb/misc/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_USB_LEGOTOWER) += legousbtower.o
>  obj-$(CONFIG_USB_RIO500) += rio500.o
>  obj-$(CONFIG_USB_TEST)   += usbtest.o
>  

Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

2016-09-13 Thread Guenter Roeck

Hi Vladimir,

your commit e188cbf7564f ("gpio: mxc: shift gpio_mxc_init() to subsys_initcall 
level")
in -next causes the following crash when running the 'kzm' target (and most 
likely
the real thing) with qemu.

[1.211426] Unable to handle kernel NULL pointer dereference at virtual 
address 000c
[1.211600] pgd = c0004000
[1.211680] [000c] *pgd=
[1.212067] Internal error: Oops: 5 [#1] SMP ARM
[1.212245] Modules linked in:
[1.212542] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.8.0-rc6-next-20160913 #1
[1.212671] Hardware name: Kyoto Microcomputer Co., Ltd. KZM-ARM11-01
[1.212825] task: c6848000 task.stack: c683e000
[1.213231] PC is at platform_get_irq+0xc0/0xe8

See 
http://kerneltests.org/builders/qemu-arm-next/builds/525/steps/qemubuildcommand/logs/stdio
for a complete log.

Problem is quite subtle. The change causes the gpio driver to be installed 
later.
As a result, kzm_init_smsc9118() fails to initialize the gpio pins correctly.
gpio_request() in that function returns -EPROBE_DEFER, which is ignored,
gpio_to_irq() then returns -22 which is unconditionally assigned as interrupt 
number.
platform_get_irq(), as called from the smsc driver, gets this negative interrupt
number, and passes it unconditionally to irq_get_irq_data(), which returns NULL.
The NULL pointer is then passed to irqd_set_trigger_type() which, not entirely
surprisingly, crashes.

So, in other words, lots of bugs here. Nevertheless, I would suggest to keep 
using
postcore_initcall(), at least until it is sure that all gpio clients handle 
-EPROBE_DEFER
correctly.

Thanks,
Guenter


RE: [PATCH] ACPICA / Interpreter: Remove redundant newline

2016-09-13 Thread Zheng, Lv
Hi,

> From: Joe Perches [mailto:j...@perches.com]
> Subject: Re: [PATCH] ACPICA / Interpreter: Remove redundant newline
> 
> On Fri, 2016-09-09 at 20:40 +0200, Borislav Petkov wrote:
> > On Fri, Sep 09, 2016 at 06:26:17PM +, Moore, Robert wrote:
> > > Is this a big deal?
> > > We do this on purpose for AcpiExec, to make the screen output more 
> > > readable.
> []
> > What do you mean "big deal"? All other ACPI_INFO calls don't have a "\n"
> > at the end except this one. How does one "\n" make some output more
> > readable?
> 
> Blank lines in logging/dmesg generally don't add value.
> 
> I would prefer if the unnecessary double parentheses also
> were removed in these macro uses and ##__VA_ARGS__ was
> used instead.

Ideally correct.
But __VA_ARGS__ is not portable.
And ACPICA is used in other environment.
I'd prefer to eliminate debugging/logging macros, but implement 
debugging/logging functions instead.
As stdarg is more portable than __VA_ARGS__.

Thanks and best regards
Lv

> 
> /*
>  * Error reporting. Callers module and line number are inserted by AE_INFO,
>  * the plist contains a set of parens to allow variable-length lists.
>  * These macros are used for both the debug and non-debug versions of the 
> code.
>  */
> #define ACPI_INFO(plist)acpi_info plist
> #define ACPI_WARNING(plist) acpi_warning plist
> #define ACPI_EXCEPTION(plist)   acpi_exception plist
> #define ACPI_ERROR(plist)   acpi_error plist
> #define ACPI_BIOS_WARNING(plist)acpi_bios_warning plist
> #define ACPI_BIOS_ERROR(plist)  acpi_bios_error plist
> 
> It would also be good if format/argument verification
> was done here and in the non-debug macro variants.
> 
> #define ACPI_INFO(plist)
> #define ACPI_WARNING(plist)
> #define ACPI_EXCEPTION(plist)
> #define ACPI_ERROR(plist)
> #define ACPI_BIOS_WARNING(plist)
> #define ACPI_BIOS_ERROR(plist)



Re: [RFC PATCH v3 3/7] proc: Reduce cache miss in snmp6_seq_show

2016-09-13 Thread hejianet



On 9/13/16 3:05 AM, Marcelo wrote:

On Fri, Sep 09, 2016 at 02:33:58PM +0800, Jia He wrote:

This is to use the generic interface snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.

Signed-off-by: Jia He 
---
  net/ipv6/proc.c | 32 +++-
  1 file changed, 23 insertions(+), 9 deletions(-)

diff --git a/net/ipv6/proc.c b/net/ipv6/proc.c
index 679253d0..50ba2c3 100644
--- a/net/ipv6/proc.c
+++ b/net/ipv6/proc.c
@@ -30,6 +30,11 @@
  #include 
  #include 
  
+#define MAX4(a, b, c, d) \

+   max_t(u32, max_t(u32, a, b), max_t(u32, c, d))
+#define SNMP_MIB_MAX MAX4(UDP_MIB_MAX, TCP_MIB_MAX, \
+   IPSTATS_MIB_MAX, ICMP_MIB_MAX)
+
  static int sockstat6_seq_show(struct seq_file *seq, void *v)
  {
struct net *net = seq->private;
@@ -192,13 +197,19 @@ static void snmp6_seq_show_item(struct seq_file *seq, 
void __percpu *pcpumib,
const struct snmp_mib *itemlist)
  {
int i;
-   unsigned long val;
-
-   for (i = 0; itemlist[i].name; i++) {
-   val = pcpumib ?
-   snmp_fold_field(pcpumib, itemlist[i].entry) :
-   atomic_long_read(smib + itemlist[i].entry);
-   seq_printf(seq, "%-32s\t%lu\n", itemlist[i].name, val);
+   unsigned long buff[SNMP_MIB_MAX];
+
+   memset(buff, 0, sizeof(unsigned long) * SNMP_MIB_MAX);

This memset() could be moved...


+
+   if (pcpumib) {

... here, so it's not executed if it hits the else block.

Thanks for the suggestion
B.R.
Jia

+   snmp_get_cpu_field_batch(buff, itemlist, pcpumib);
+   for (i = 0; itemlist[i].name; i++)
+   seq_printf(seq, "%-32s\t%lu\n",
+  itemlist[i].name, buff[i]);
+   } else {
+   for (i = 0; itemlist[i].name; i++)
+   seq_printf(seq, "%-32s\t%lu\n", itemlist[i].name,
+  atomic_long_read(smib + itemlist[i].entry));
}
  }
  
@@ -206,10 +217,13 @@ static void snmp6_seq_show_item64(struct seq_file *seq, void __percpu *mib,

  const struct snmp_mib *itemlist, size_t 
syncpoff)
  {
int i;
+   u64 buff64[SNMP_MIB_MAX];
+
+   memset(buff64, 0, sizeof(unsigned long) * SNMP_MIB_MAX);
  
+	snmp_get_cpu_field64_batch(buff64, itemlist, mib, syncpoff);

for (i = 0; itemlist[i].name; i++)
-   seq_printf(seq, "%-32s\t%llu\n", itemlist[i].name,
-  snmp_fold_field64(mib, itemlist[i].entry, syncpoff));
+   seq_printf(seq, "%-32s\t%llu\n", itemlist[i].name, buff64[i]);
  }
  
  static int snmp6_seq_show(struct seq_file *seq, void *v)

--
1.8.3.1

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





RE: [PATCH] ACPICA / Interpreter: Remove redundant newline

2016-09-13 Thread Zheng, Lv
Hi,

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Moore,
> Robert
> David E 
> Subject: RE: [PATCH] ACPICA / Interpreter: Remove redundant newline
> 
> Well, I never thought I would write a couple lines of code like this, but 
> here is a solution that
> should make everyone happy.
> 
> diff --git a/source/components/tables/tbxfload.c 
> b/source/components/tables/tbxfload.c
> index 6a937b1..73ee1a2 100644
> --- a/source/components/tables/tbxfload.c
> +++ b/source/components/tables/tbxfload.c
> @@ -334,7 +334,7 @@ AcpiTbLoadNamespace (
>  if (!TablesFailed)
>  {
>  ACPI_INFO ((
> -"%u ACPI AML tables successfully acquired and loaded\n",
> +"%u ACPI AML tables successfully acquired and loaded",
>  TablesLoaded));
>  }
>  else
> @@ -348,6 +348,11 @@ AcpiTbLoadNamespace (
>  Status = AE_CTRL_TERMINATE;
>  }
> 
> +#ifdef ACPI_APPLICATION
> +ACPI_DEBUG_PRINT_RAW ((ACPI_DB_INIT, "\n"));
> +#endif
> +
> +

IMO, these lines should be in ACPICA upstream, in a file under tools/acpiexec.

Thanks
Lv

>  UnlockAndExit:
>  (void) AcpiUtReleaseMutex (ACPI_MTX_TABLES);
>  return_ACPI_STATUS (Status);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show

2016-09-13 Thread hejianet

Hi Marcelo


On 9/13/16 2:57 AM, Marcelo wrote:

On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote:

This is to use the generic interface snmp_get_cpu_field{,64}_batch to
aggregate the data by going through all the items of each cpu sequentially.
Then snmp_seq_show and netstat_seq_show are split into 2 parts to avoid build
warning "the frame size" larger than 1024 on s390.

Yeah about that, did you test it with stack overflow detection?
These arrays can be quite large.

One more below..

I found scripts/checkstack.pl could analyze the stack usage statically.
[root@tian-lp1 kernel]# objdump -d vmlinux | scripts/checkstack.pl ppc64|grep 
seq
0xc07d4b18 netstat_seq_show_tcpext.isra.7 [vmlinux]:1120
0xc07ccbe8 fib_triestat_seq_show [vmlinux]: 496
0xc083e7a4 tcp6_seq_show [vmlinux]: 480
0xc07d4908 snmp_seq_show_ipstats.isra.6 [vmlinux]:464
0xc07d4d18 netstat_seq_show_ipext.isra.8 [vmlinux]:464
0xc06f5bd8 proto_seq_show [vmlinux]:416
0xc07f5718 xfrm_statistics_seq_show [vmlinux]:  416
0xc07405b4 dev_seq_printf_stats [vmlinux]:  400

seems the stack usage in netstat_seq_show_tcpext is too big.
Will consider how to reduce it

B.R.
Jia

Signed-off-by: Jia He 
---
  net/ipv4/proc.c | 106 +++-
  1 file changed, 74 insertions(+), 32 deletions(-)

diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 9f665b6..c6fc80e 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -46,6 +46,8 @@
  #include 
  #include 
  
+#define TCPUDP_MIB_MAX max_t(u32, UDP_MIB_MAX, TCP_MIB_MAX)

+
  /*
   *Report socket allocation statistics [m...@utu.fi]
   */
@@ -378,13 +380,15 @@ static void icmp_put(struct seq_file *seq)
  /*
   *Called from the PROCfs module. This outputs /proc/net/snmp.
   */
-static int snmp_seq_show(struct seq_file *seq, void *v)
+static int snmp_seq_show_ipstats(struct seq_file *seq, void *v)
  {
int i;
+   u64 buff64[IPSTATS_MIB_MAX];
struct net *net = seq->private;
  
-	seq_puts(seq, "Ip: Forwarding DefaultTTL");

+   memset(buff64, 0, IPSTATS_MIB_MAX * sizeof(u64));
  
+	seq_puts(seq, "Ip: Forwarding DefaultTTL");

for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_ipstats_list[i].name);
  
@@ -393,57 +397,77 @@ static int snmp_seq_show(struct seq_file *seq, void *v)

   net->ipv4.sysctl_ip_default_ttl);
  
  	BUILD_BUG_ON(offsetof(struct ipstats_mib, mibs) != 0);

+   snmp_get_cpu_field64_batch(buff64, snmp4_ipstats_list,
+  net->mib.ip_statistics,
+  offsetof(struct ipstats_mib, syncp));
for (i = 0; snmp4_ipstats_list[i].name != NULL; i++)
-   seq_printf(seq, " %llu",
-  snmp_fold_field64(net->mib.ip_statistics,
-snmp4_ipstats_list[i].entry,
-offsetof(struct ipstats_mib, 
syncp)));
+   seq_printf(seq, " %llu", buff64[i]);
  
-	icmp_put(seq);	/* RFC 2011 compatibility */

-   icmpmsg_put(seq);
+   return 0;
+}
+
+static int snmp_seq_show_tcp_udp(struct seq_file *seq, void *v)
+{
+   int i;
+   unsigned long buff[TCPUDP_MIB_MAX];
+   struct net *net = seq->private;
+
+   memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));
  
  	seq_puts(seq, "\nTcp:");

for (i = 0; snmp4_tcp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_tcp_list[i].name);
  
  	seq_puts(seq, "\nTcp:");

+   snmp_get_cpu_field_batch(buff, snmp4_tcp_list,
+net->mib.tcp_statistics);
for (i = 0; snmp4_tcp_list[i].name != NULL; i++) {
/* MaxConn field is signed, RFC 2012 */
if (snmp4_tcp_list[i].entry == TCP_MIB_MAXCONN)
-   seq_printf(seq, " %ld",
-  snmp_fold_field(net->mib.tcp_statistics,
-  snmp4_tcp_list[i].entry));
+   seq_printf(seq, " %ld", buff[i]);
else
-   seq_printf(seq, " %lu",
-  snmp_fold_field(net->mib.tcp_statistics,
-  snmp4_tcp_list[i].entry));
+   seq_printf(seq, " %lu", buff[i]);
}
  
+	memset(buff, 0, TCPUDP_MIB_MAX * sizeof(unsigned long));

+
+   snmp_get_cpu_field_batch(buff, snmp4_udp_list,
+net->mib.udp_statistics);
seq_puts(seq, "\nUdp:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
seq_printf(seq, " %s", snmp4_udp_list[i].name);
-
seq_puts(seq, "\nUdp:");
for (i = 0; snmp4_udp_list[i].name != NULL; i++)
-   seq_printf(seq, " %lu",
-   

RE: [PATCH] ACPICA / Interpreter: Remove redundant newline

2016-09-13 Thread Zheng, Lv
The newline is intentional for acpiexec.
So you should fix this issue in acpiexec, aka, in ACPICA upstream.

Thanks
Lv

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Borislav
> Petkov
> Subject: [PATCH] ACPICA / Interpreter: Remove redundant newline
> 
> From: Borislav Petkov 
> 
> acpi_info() already issues a '\n' so remove it in the call.
> 
> Signed-off-by: Borislav Petkov 
> Cc: Robert Moore 
> Cc: Lv Zheng 
> Cc: "Rafael J. Wysocki" 
> Cc: Len Brown 
> Cc: linux-a...@vger.kernel.org
> Cc: de...@acpica.org
> ---
>  drivers/acpi/acpica/tbxfload.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
> index ac71abcd32bb..e7119b7ccd79 100644
> --- a/drivers/acpi/acpica/tbxfload.c
> +++ b/drivers/acpi/acpica/tbxfload.c
> @@ -240,7 +240,7 @@ acpi_status acpi_tb_load_namespace(void)
>   }
> 
>   if (!tables_failed) {
> - ACPI_INFO(("%u ACPI AML tables successfully acquired and 
> loaded\n", tables_loaded));
> + ACPI_INFO(("%u ACPI AML tables successfully acquired and 
> loaded", tables_loaded));
>   } else {
>   ACPI_ERROR((AE_INFO,
>   "%u table load failures, %u successful",
> --
> 2.10.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 02/10] staging: slicoss: slic.h: add a macro IOMEM_GET_FIELD32 to fix sparse warnings

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slic.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 7c23190..ff71070 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -546,6 +546,13 @@ static inline void slic_flush_write(struct adapter 
*adapter)
(void __iomem *)_base;  \
 })
 
+#define IOMEM_GET_FIELD32(base, member)
\
+({ \
+   char __iomem *_base = (char __iomem *)base; \
+   _base += offsetof(typeof(*base), member);   \
+   ioread32(_base);\
+})
+
 #define UPDATE_STATS(largestat, newstat, oldstat)\
 {\
if ((newstat) < (oldstat))   \
-- 
2.7.4



[PATCH 03/10] staging: slicoss: slic.h: add a macro IOMEM_SET_FIELD32 to fix sparse warnings

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slic.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index ff71070..4c22863 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -553,6 +553,13 @@ static inline void slic_flush_write(struct adapter 
*adapter)
ioread32(_base);\
 })
 
+#define IOMEM_SET_FIELD32(value, base, member) \
+({ \
+   char __iomem *_base = (char __iomem *)base; \
+   _base += offsetof(typeof(*base), member);   \
+   iowrite32(value, _base);\
+})
+
 #define UPDATE_STATS(largestat, newstat, oldstat)\
 {\
if ((newstat) < (oldstat))   \
-- 
2.7.4



[PATCH 06/10] staging: slicoss: slicoss.c: fix different address space sparse warning

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slicoss.c | 49 +--
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 929a0d5..03b01c5 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -1004,8 +1004,9 @@ static void slic_upr_request_complete(struct adapter 
*adapter, u32 isr)
switch (upr->upr_request) {
case SLIC_UPR_STATS: {
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
-   struct slic_stats *stats = _data->stats;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
+   struct slic_stats __iomem *stats =
+   IOMEM_GET_FIELDADDR(sm_data, stats);
struct slic_stats *old = >inicstats_prev;
struct slicnet_stats *stst = >slic_stats;
 
@@ -1015,48 +1016,62 @@ static void slic_upr_request_complete(struct adapter 
*adapter, u32 isr)
break;
}
 
-   UPDATE_STATS_GB(stst->tcp.xmit_tcp_segs, stats->xmit_tcp_segs,
+   UPDATE_STATS_GB(stst->tcp.xmit_tcp_segs,
+   IOMEM_GET_FIELD64(stats, xmit_tcp_segs),
old->xmit_tcp_segs);
 
-   UPDATE_STATS_GB(stst->tcp.xmit_tcp_bytes, stats->xmit_tcp_bytes,
+   UPDATE_STATS_GB(stst->tcp.xmit_tcp_bytes,
+   IOMEM_GET_FIELD64(stats, xmit_tcp_bytes),
old->xmit_tcp_bytes);
 
-   UPDATE_STATS_GB(stst->tcp.rcv_tcp_segs, stats->rcv_tcp_segs,
+   UPDATE_STATS_GB(stst->tcp.rcv_tcp_segs,
+   IOMEM_GET_FIELD64(stats, rcv_tcp_segs),
old->rcv_tcp_segs);
 
-   UPDATE_STATS_GB(stst->tcp.rcv_tcp_bytes, stats->rcv_tcp_bytes,
+   UPDATE_STATS_GB(stst->tcp.rcv_tcp_bytes,
+   IOMEM_GET_FIELD64(stats, rcv_tcp_bytes),
old->rcv_tcp_bytes);
 
-   UPDATE_STATS_GB(stst->iface.xmt_bytes, stats->xmit_bytes,
+   UPDATE_STATS_GB(stst->iface.xmt_bytes,
+   IOMEM_GET_FIELD64(stats, xmit_bytes),
old->xmit_bytes);
 
-   UPDATE_STATS_GB(stst->iface.xmt_ucast, stats->xmit_unicasts,
+   UPDATE_STATS_GB(stst->iface.xmt_ucast,
+   IOMEM_GET_FIELD64(stats, xmit_unicasts),
old->xmit_unicasts);
 
-   UPDATE_STATS_GB(stst->iface.rcv_bytes, stats->rcv_bytes,
+   UPDATE_STATS_GB(stst->iface.rcv_bytes,
+   IOMEM_GET_FIELD64(stats, rcv_bytes),
old->rcv_bytes);
 
-   UPDATE_STATS_GB(stst->iface.rcv_ucast, stats->rcv_unicasts,
+   UPDATE_STATS_GB(stst->iface.rcv_ucast,
+   IOMEM_GET_FIELD64(stats, rcv_unicasts),
old->rcv_unicasts);
 
-   UPDATE_STATS_GB(stst->iface.xmt_errors, stats->xmit_collisions,
+   UPDATE_STATS_GB(stst->iface.xmt_errors,
+   IOMEM_GET_FIELD64(stats, xmit_collisions),
old->xmit_collisions);
 
UPDATE_STATS_GB(stst->iface.xmt_errors,
-   stats->xmit_excess_collisions,
+   IOMEM_GET_FIELD64(stats,
+ xmit_excess_collisions),
old->xmit_excess_collisions);
 
-   UPDATE_STATS_GB(stst->iface.xmt_errors, stats->xmit_other_error,
+   UPDATE_STATS_GB(stst->iface.xmt_errors,
+   IOMEM_GET_FIELD64(stats, xmit_other_error),
old->xmit_other_error);
 
-   UPDATE_STATS_GB(stst->iface.rcv_errors, stats->rcv_other_error,
+   UPDATE_STATS_GB(stst->iface.rcv_errors,
+   IOMEM_GET_FIELD64(stats, rcv_other_error),
old->rcv_other_error);
 
-   UPDATE_STATS_GB(stst->iface.rcv_discards, stats->rcv_drops,
+   UPDATE_STATS_GB(stst->iface.rcv_discards,
+   IOMEM_GET_FIELD64(stats, rcv_drops),
old->rcv_drops);
 
-   if (stats->rcv_drops > old->rcv_drops)
-   adapter->rcv_drops += (stats->rcv_drops -
+   if (IOMEM_GET_FIELD64(stats, rcv_drops) > old->rcv_drops)
+   adapter->rcv_drops +=
+   (IOMEM_GET_FIELD64(stats, rcv_drops) -
  

[PATCH 09/10] staging: slicoss: slicoss.c: fix different address space sparse warning

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slicoss.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index a2d9c77..6ecf71c 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2230,7 +2230,7 @@ static int slic_if_init(struct adapter *adapter, unsigned 
long *flags)
struct sliccard *card = adapter->card;
struct net_device *dev = adapter->netdev;
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
int rc;
 
/* adapter should be down at this point */
@@ -2314,7 +2314,7 @@ static int slic_if_init(struct adapter *adapter, unsigned 
long *flags)
/*
 *clear any pending events, then enable interrupts
 */
-   sm_data->isr = 0;
+   IOMEM_SET_FIELD32(0, sm_data, isr);
slic_write32(adapter, SLIC_REG_ISR, 0);
slic_write32(adapter, SLIC_REG_ICR, ICR_INT_ON);
 
@@ -2603,7 +2603,7 @@ static void slic_config_pci(struct pci_dev *pcidev)
 static int slic_card_init(struct sliccard *card, struct adapter *adapter)
 {
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
struct slic_eeprom *peeprom;
struct oslic_eeprom *pOeeprom;
dma_addr_t phys_config;
@@ -2666,9 +2666,9 @@ static int slic_card_init(struct sliccard *card, struct 
adapter *adapter)
}
 
for (;;) {
-   if (sm_data->isr) {
-   if (sm_data->isr & ISR_UPC) {
-   sm_data->isr = 0;
+   if (IOMEM_GET_FIELD32(sm_data, isr)) {
+   if (IOMEM_GET_FIELD32(sm_data, isr) & ISR_UPC) {
+   IOMEM_SET_FIELD32(0, sm_data, isr);
slic_write64(adapter, SLIC_REG_ISP, 0,
 0);
slic_write32(adapter, SLIC_REG_ISR, 0);
@@ -2678,7 +2678,7 @@ static int slic_card_init(struct sliccard *card, struct 
adapter *adapter)
break;
}
 
-   sm_data->isr = 0;
+   IOMEM_SET_FIELD32(0, sm_data, isr);
slic_write32(adapter, SLIC_REG_ISR, 0);
slic_flush_write(adapter);
} else {
-- 
2.7.4



[PATCH 07/10] staging: slicoss: slicoss.c: fix different address space sparse warning

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slicoss.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 03b01c5..2097d64 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -1697,9 +1697,10 @@ static void slic_init_cleanup(struct adapter *adapter)
 
if (adapter->shmem.shmem_data) {
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
 
-   pci_free_consistent(adapter->pcidev, sizeof(*sm_data), sm_data,
+   pci_free_consistent(adapter->pcidev, sizeof(*sm_data),
+   (void __force *)sm_data,
sm->isr_phaddr);
}
 
-- 
2.7.4



[PATCH 10/10] staging: slicoss: slicoss.c: fix different address space sparse warning

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slicoss.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 6ecf71c..e94dbd4 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2883,7 +2883,7 @@ static int slic_init_adapter(struct net_device *netdev,
if (!sm_data)
return -ENOMEM;
 
-   sm->shmem_data = sm_data;
+   sm->shmem_data = (struct slic_shmem_data __force __iomem *)sm_data;
sm->isr_phaddr = phaddr;
sm->lnkstatus_phaddr = phaddr + offsetof(struct slic_shmem_data,
 lnkstatus);
-- 
2.7.4



[PATCH 08/10] staging: slicoss: slicoss.c: fix different address space sparse warning

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slicoss.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 2097d64..a2d9c77 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -2087,15 +2087,15 @@ static irqreturn_t slic_interrupt(int irq, void *dev_id)
struct net_device *dev = dev_id;
struct adapter *adapter = netdev_priv(dev);
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
u32 isr;
 
-   if (sm_data->isr) {
+   if (IOMEM_GET_FIELD32(sm_data, isr)) {
slic_write32(adapter, SLIC_REG_ICR, ICR_INT_MASK);
slic_flush_write(adapter);
 
-   isr = sm_data->isr;
-   sm_data->isr = 0;
+   isr = IOMEM_GET_FIELD32(sm_data, isr);
+   IOMEM_SET_FIELD32(0, sm_data, isr);
adapter->num_isrs++;
switch (adapter->card->state) {
case CARD_UP:
-- 
2.7.4



[PATCH 04/10] staging: slicoss: slic.h: add a macro IOMEM_GET_FIELD64 to fix sparse warnings

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slic.h | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index 4c22863..b9595c4 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -560,6 +560,31 @@ static inline void slic_flush_write(struct adapter 
*adapter)
iowrite32(value, _base);\
 })
 
+#ifdef CONFIG_64BIT
+#define IOMEM_GET_FIELD64(base, member)
\
+({ \
+   char __iomem *_base = (char __iomem *)base; \
+   _base += offsetof(typeof(*base), member);   \
+   readq(_base);   \
+})
+#else
+#define IOMEM_GET_FIELD64(base, member)
\
+({ \
+   char __iomem *_base = (char __iomem *)base; \
+   u64 val;\
+   _base += offsetof(typeof(*base), member);   \
+   val = ((u64)ioread8(_base + 7)) << 56;  \
+   val += ((u64)ioread8(_base + 6)) << 48; \
+   val += ((u64)ioread8(_base + 5)) << 40; \
+   val += ((u64)ioread8(_base + 4)) << 32; \
+   val += ((u64)ioread8(_base + 3)) << 24; \
+   val += ((u64)ioread8(_base + 2)) << 16; \
+   val += ((u64)ioread8(_base + 1)) << 8;  \
+   val += ioread8(_base);  \
+   le64_to_cpu(val);   \
+})
+#endif
+
 #define UPDATE_STATS(largestat, newstat, oldstat)\
 {\
if ((newstat) < (oldstat))   \
-- 
2.7.4



[PATCH 05/10] staging: slicoss: slicoss.c: fix different address space sparse warning

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slicoss.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/slicoss/slicoss.c 
b/drivers/staging/slicoss/slicoss.c
index 21280a3..929a0d5 100644
--- a/drivers/staging/slicoss/slicoss.c
+++ b/drivers/staging/slicoss/slicoss.c
@@ -924,8 +924,8 @@ err_unlock_irq:
 static void slic_link_upr_complete(struct adapter *adapter, u32 isr)
 {
struct slic_shmemory *sm = >shmem;
-   struct slic_shmem_data *sm_data = sm->shmem_data;
-   u32 lst = sm_data->lnkstatus;
+   struct slic_shmem_data __iomem *sm_data = sm->shmem_data;
+   u32 lst = IOMEM_GET_FIELD32(sm_data, lnkstatus);
uint linkup;
unsigned char linkspeed;
unsigned char linkduplex;
-- 
2.7.4



[PATCH 01/10] staging: slicoss: slic.h: add a macro IOMEM_GET_FIELDADDR to fix sparse warnings

2016-09-13 Thread Peng Sun
Signed-off-by: Peng Sun 
---
 drivers/staging/slicoss/slic.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/staging/slicoss/slic.h b/drivers/staging/slicoss/slic.h
index fe1d2ce..7c23190 100644
--- a/drivers/staging/slicoss/slic.h
+++ b/drivers/staging/slicoss/slic.h
@@ -539,6 +539,13 @@ static inline void slic_flush_write(struct adapter 
*adapter)
ioread32(adapter->regs + SLIC_REG_HOSTID);
 }
 
+#define IOMEM_GET_FIELDADDR(base, member)  \
+({ \
+   char __iomem *_base = (char __iomem *)base; \
+   _base += offsetof(typeof(*base), member);   \
+   (void __iomem *)_base;  \
+})
+
 #define UPDATE_STATS(largestat, newstat, oldstat)\
 {\
if ((newstat) < (oldstat))   \
-- 
2.7.4



[PATCH 00/10] staging: slicoss: fix different address space sparse warnings

2016-09-13 Thread Peng Sun
base commit-id d221eb9f14f9

Peng Sun (10):
  staging: slicoss: slic.h: add a macro IOMEM_GET_FIELDADDR to fix
sparse warnings
  staging: slicoss: slic.h: add a macro IOMEM_GET_FIELD32 to fix sparse
warnings
  staging: slicoss: slic.h: add a macro IOMEM_SET_FIELD32 to fix sparse
warnings
  staging: slicoss: slic.h: add a macro IOMEM_GET_FIELD64 to fix sparse
warnings
  staging: slicoss: slicoss.c: fix different address space sparse
warning
  staging: slicoss: slicoss.c: fix different address space sparse
warning
  staging: slicoss: slicoss.c: fix different address space sparse
warning
  staging: slicoss: slicoss.c: fix different address space sparse
warning
  staging: slicoss: slicoss.c: fix different address space sparse
warning
  staging: slicoss: slicoss.c: fix different address space sparse
warning

 drivers/staging/slicoss/slic.h| 46 ++
 drivers/staging/slicoss/slicoss.c | 82 +++
 2 files changed, 95 insertions(+), 33 deletions(-)

-- 
2.7.4



Re: [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi

2016-09-13 Thread Chen-Yu Tsai
Hi Linus,

On Mon, Sep 12, 2016 at 8:40 PM, Linus Walleij  wrote:
> On Thu, Sep 8, 2016 at 9:37 AM, Maxime Ripard
>  wrote:
>> On Thu, Sep 08, 2016 at 12:46:14PM +0800, Chen-Yu Tsai wrote:
>
>>> Also, I think we are needlessly using pin groups, 1 pin per group.
>>> Can pinconf/pinctrl work without them? Would there be any harm
>>> converting the sunxi driver to work directly with pins? This would
>>> make it match generic pinconf parsing, and make it easier to get
>>> both working together.
>>
>> I think it comes from a requirement that you had to have groups at
>> some point (I don't know if it's still the case), which is why we
>> ended up with single-pin groups, because we can mux each pins entirely
>> separately.
>>
>> If it's not required anymore, then yes, it makes total sense to remove
>> it.
>
> The groups vs individual pins is an eternal debate that has
> been going on since the inception of pinctrl.
>
> If you see it from the point of the programmer, you may just see
> a register for each pin and they seem all independent. This is
> why pinctrl-single exist, and that driver is for this purpose: one
> register per pin, software-wise independent.
>
> HOWEVER it often turns out that while you can programmatically
> and individually set pins to any function (and biasing etc), the
> person designing the hardware was not thinking that you should
> be able to do whatever you like, e.g. even if it is possible to
> take two pins and use one of them for half an SPI bus and the
> other for half an I2C bus, that doesn't mean that this is useful
> or makes any kind of electronic sense, it just makes "software
> sense".
>
> So for a deeper understanding, several SoCs (amongst them
> my own and Qualcomm etc) define groups that are not really
> about software restrictions for what you can do with the pins, but
> about usecase and electronic restrictions for what can be done
> with the pins.
>
> E.g. it makes *sense* to have a group for muxing I2C on two
> pins, and not allow one of them to be muxed to I2C and the other
> not, because it does not make electronic sense.
>
> One-group-per-pin groups is usually coming from a failure or
> inability to identify these electronically sound and usecase
> oriented pingroups.
>
> Some (like pinctrl-single) say they don't care, and wish to
> see things as the world is just software and one register per
> pin, removing those electric usecase restrictions, and only
> keeping the muxing restrictions to e.g. the four different functions
> that can be muxed on that pin, disregarding the bigger picture.
>
> I don't know about this driver or the pins it manages,
> I seldom have time or brains to dive in and review things
> deeply enough :(

Thanks for the explanation. I suppose sunxi falls into the "don't
care" group. We mainly enforce proper use cases through the DT
pinmux settings. Of course this doesn't prevent the user from
using weird settings out of tree, but then again what's preventing
them from hacking the kernel anyway.

Back to my original question: is it possible to drop the pin group
support completely? Looking at struct pinctrl_ops the answer seems
to be no.

Regards
ChenYu


Re: [PATCH] usb: chipidea: Properly mark little endian descriptors

2016-09-13 Thread Peter Chen
On Wed, Sep 14, 2016 at 10:37:40AM +0800, Peter Chen wrote:
> On Tue, Sep 13, 2016 at 04:06:31PM -0700, Stephen Boyd wrote:
> > The DMA descriptors are little endian, and we do a pretty good
> > job of handling them with the proper le32_to_cpu() markings, but
> > we don't actually mark them as __le32. This means checkers like
> > sparse can't easily find new bugs. Let's mark the members of
> > structures properly and fix the few places where we're missing
> > conversions.
> > 
> > Cc: Peter Chen 
> > Cc: Greg Kroah-Hartman 
> > Signed-off-by: Stephen Boyd 
> > ---
> >  drivers/usb/chipidea/udc.c |  6 +++---
> >  drivers/usb/chipidea/udc.h | 12 ++--
> >  2 files changed, 9 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> > index 6acf4dba395e..61a65d1d05f2 100644
> > --- a/drivers/usb/chipidea/udc.c
> > +++ b/drivers/usb/chipidea/udc.c
> > @@ -364,7 +364,7 @@ static int add_td_to_list(struct ci_hw_ep *hwep, struct 
> > ci_hw_req *hwreq,
> > if (hwreq->req.length == 0
> > || hwreq->req.length % hwep->ep.maxpacket)
> > mul++;
> > -   node->ptr->token |= mul << __ffs(TD_MULTO);
> > +   node->ptr->token |= cpu_to_le32(mul << __ffs(TD_MULTO));
> > }
> >  
> > temp = (u32) (hwreq->req.dma + hwreq->req.actual);
> > @@ -503,7 +503,7 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, 
> > struct ci_hw_req *hwreq)
> > if (hwreq->req.length == 0
> > || hwreq->req.length % hwep->ep.maxpacket)
> > mul++;
> > -   hwep->qh.ptr->cap |= mul << __ffs(QH_MULT);
> > +   hwep->qh.ptr->cap |= cpu_to_le32(mul << __ffs(QH_MULT));
> > }
> >  
> > wmb();   /* synchronize before ep prime */
> > @@ -530,7 +530,7 @@ static void free_pending_td(struct ci_hw_ep *hwep)
> >  static int reprime_dtd(struct ci_hdrc *ci, struct ci_hw_ep *hwep,
> >struct td_node *node)
> >  {
> > -   hwep->qh.ptr->td.next = node->dma;
> > +   hwep->qh.ptr->td.next = cpu_to_le32(node->dma);
> > hwep->qh.ptr->td.token &=
> > cpu_to_le32(~(TD_STATUS_HALTED | TD_STATUS_ACTIVE));
> >  
> > diff --git a/drivers/usb/chipidea/udc.h b/drivers/usb/chipidea/udc.h
> > index e66df0020bd4..2ecd1174d66c 100644
> > --- a/drivers/usb/chipidea/udc.h
> > +++ b/drivers/usb/chipidea/udc.h
> > @@ -22,11 +22,11 @@
> >  /* DMA layout of transfer descriptors */
> >  struct ci_hw_td {
> > /* 0 */
> > -   u32 next;
> > +   __le32 next;
> >  #define TD_TERMINATE  BIT(0)
> >  #define TD_ADDR_MASK  (0xFFEUL << 5)
> > /* 1 */
> > -   u32 token;
> > +   __le32 token;
> >  #define TD_STATUS (0x00FFUL <<  0)
> >  #define TD_STATUS_TR_ERR  BIT(3)
> >  #define TD_STATUS_DT_ERR  BIT(5)
> > @@ -36,7 +36,7 @@ struct ci_hw_td {
> >  #define TD_IOCBIT(15)
> >  #define TD_TOTAL_BYTES(0x7FFFUL << 16)
> > /* 2 */
> > -   u32 page[5];
> > +   __le32 page[5];
> >  #define TD_CURR_OFFSET(0x0FFFUL <<  0)
> >  #define TD_FRAME_NUM  (0x07FFUL <<  0)
> >  #define TD_RESERVED_MASK  (0x0FFFUL <<  0)
> > @@ -45,18 +45,18 @@ struct ci_hw_td {
> >  /* DMA layout of queue heads */
> >  struct ci_hw_qh {
> > /* 0 */
> > -   u32 cap;
> > +   __le32 cap;
> >  #define QH_IOSBIT(15)
> >  #define QH_MAX_PKT(0x07FFUL << 16)
> >  #define QH_ZLTBIT(29)
> >  #define QH_MULT   (0x0003UL << 30)
> >  #define QH_ISO_MULT(x) ((x >> 11) & 0x03)
> > /* 1 */
> > -   u32 curr;
> > +   __le32 curr;
> > /* 2 - 8 */
> > struct ci_hw_td td;
> > /* 9 */
> > -   u32 RESERVED;
> > +   __le32 RESERVED;
> > struct usb_ctrlrequest   setup;
> >  } __attribute__ ((packed, aligned(4)));
> >  
> > -- 

I am afraid I can't apply for testing

Applying: usb: chipidea: Properly mark little endian descriptors
fatal: sha1 information is lacking or useless
(drivers/usb/chipidea/udc.c).
error: could not build fake ancestor
Patch failed at 0001 usb: chipidea: Properly mark little endian
descriptors
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Would you please rebase my ci-for-usb-next branch?

-- 

Best Regards,
Peter Chen


Re: [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi

2016-09-13 Thread Chen-Yu Tsai
On Thu, Sep 8, 2016 at 3:41 PM, Maxime Ripard
 wrote:
> On Thu, Sep 08, 2016 at 12:32:48AM +0800, Chen-Yu Tsai wrote:
>> On Wed, Sep 7, 2016 at 10:53 PM, Maxime Ripard
>>  wrote:
>> > From: Mylène Josserand 
>> >
>> > The GR8 is an SoC made by Nextthing loosely based on the sun5i family.
>> >
>> > Since it's not clear yet what we can factor out and merge with the A10s and
>> > A13 support, let's keep it out of the sun5i.dtsi include tree. We will
>> > figure out what can be shared when things settle down.
>> >
>> > Signed-off-by: Mylène Josserand 
>> > Signed-off-by: Maxime Ripard 
>> > ---
>> >  arch/arm/boot/dts/ntc-gr8.dtsi | 1080 
>> > 
>> >  1 file changed, 1080 insertions(+)
>> >  create mode 100644 arch/arm/boot/dts/ntc-gr8.dtsi
>> >
>> > diff --git a/arch/arm/boot/dts/ntc-gr8.dtsi 
>> > b/arch/arm/boot/dts/ntc-gr8.dtsi
>> > new file mode 100644
>> > index ..d21cfa3f3c14
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/ntc-gr8.dtsi
>> > @@ -0,0 +1,1080 @@
>>
>> [...]
>>
>> > +   pll3x2: pll3x2_clk {
>> > +   compatible = "fixed-factor-clock";
>>
>> I think you want "allwinner,sun4i-a10-pll3-2x-clk"?
>
> Indeed.
>
>> > +   tcon_ch1_clk: clk@01c2012c {
>> > +   #clock-cells = <0>;
>> > +   compatible = "allwinner,sun4i-a10-tcon-ch1-clk";
>> > +   reg = <0x01c2012c 0x4>;
>> > +   clocks = <>, <>, <>, <>;
>> > +   clock-output-names = "tcon-ch1-sclk";
>> > +   };
>>
>> Nit: Is there a ve_clk we could add?
>
> I don't know. No one uses it, and the next item on my todo list is to
> move the sun5i SoCs to sunxi-ng, so it seems a bit useless to add that
> one.

Makes sense. Thanks!

ChenYu

>
>>
>> [...]
>>
>> > +   pio: pinctrl@01c20800 {
>> > +   compatible = "nextthing,gr8-pinctrl";
>> > +   reg = <0x01c20800 0x400>;
>> > +   interrupts = <28>;
>> > +   clocks = <_gates 5>;
>> > +   gpio-controller;
>> > +   interrupt-controller;
>> > +   #interrupt-cells = <3>;
>> > +   #gpio-cells = <3>;
>> > +
>> > +   i2c0_pins_a: i2c0@0 {
>> > +   allwinner,pins = "PB0", "PB1";
>> > +   allwinner,function = "i2c0";
>> > +   allwinner,drive = ;
>> > +   allwinner,pull = ;
>> > +   };
>> > +
>> > +   i2c1_pins_a: i2c1@0 {
>> > +   allwinner,pins = "PB15", "PB16";
>> > +   allwinner,function = "i2c1";
>> > +   allwinner,drive = ;
>> > +   allwinner,pull = ;
>> > +   };
>> > +
>> > +   i2c2_pins_a: i2c2@0 {
>> > +   allwinner,pins = "PB17", "PB18";
>> > +   allwinner,function = "i2c2";
>> > +   allwinner,drive = ;
>> > +   allwinner,pull = ;
>> > +   };
>> > +
>> > +   i2s0_pins_a: i2s0@0 {
>> > +   allwinner,pins = "PB5", "PB6", "PB7", 
>> > "PB8", "PB9";
>> > +   allwinner,function = "i2s0";
>> > +   allwinner,drive = ;
>> > +   allwinner,pull = ;
>> > +   };
>>
>> You may want to split out the MCLK pin. Some codecs don't need it, and the
>> pin can be allocated for other uses.
>
> ACK.
>
>>
>> > +
>> > +   ir0_rx_pins_a: ir0@0 {
>> > +   allwinner,pins = "PB4";
>> > +   allwinner,function = "ir0";
>> > +   allwinner,drive = ;
>> > +   allwinner,pull = ;
>> > +   };
>> > +
>> > +   lcd_rgb666_pins: lcd_rgb666@0 {
>> > +   allwinner,pins = "PD2", "PD3", "PD4", 
>> > "PD5", "PD6", "PD7",
>> > +"PD10", "PD11", "PD12", 
>> > "PD13", "PD14", "PD15",
>> > +"PD18", "PD19", "PD20", 
>> > "PD21", "PD22", "PD23",
>> > +"PD24", "PD25", "PD26", 
>> > "PD27";
>> > +   allwinner,function = "lcd0";
>> > +   allwinner,drive = ;
>> > +   allwinner,pull = ;
>> > +

Re: [RFC] fs: add userspace critical mounts event support

2016-09-13 Thread Rob Landley
On 09/02/2016 07:20 PM, Luis R. Rodriguez wrote:
> kernel_read_file_from_path() can try to read a file from
> the system's filesystem. This is typically done for firmware
> for instance, which lives in /lib/firmware. One issue with
> this is that the kernel cannot know for sure when the real
> final /lib/firmare/ is ready, and even if you use initramfs
> drivers are currently initialized *first* prior to the initramfs
> kicking off.

Why?

> During init we run through all init calls first
> (do_initcalls()) and finally the initramfs is processed via
> prepare_namespace():

What's the downside of moving initramfs cpio extraction earlier in the boot?

I did some shuffling around of those code to make initmpfs work, does
anybody know why initramfs extraction _before_ we initialize drivers
would be a bad thing? (The cpio is in memory, either linked into the
kernel or from the bootloader. No drivers are needed to extract it,
that's sort of the point.)

The only things I can think of are memory churn (large contiguous
physical page allocations), or if a driver somehow got us access to more
physical memory?

Rob


Re: [PATCH] usb: chipidea: Properly mark little endian descriptors

2016-09-13 Thread Peter Chen
On Tue, Sep 13, 2016 at 04:06:31PM -0700, Stephen Boyd wrote:
> The DMA descriptors are little endian, and we do a pretty good
> job of handling them with the proper le32_to_cpu() markings, but
> we don't actually mark them as __le32. This means checkers like
> sparse can't easily find new bugs. Let's mark the members of
> structures properly and fix the few places where we're missing
> conversions.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/udc.c |  6 +++---
>  drivers/usb/chipidea/udc.h | 12 ++--
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 6acf4dba395e..61a65d1d05f2 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -364,7 +364,7 @@ static int add_td_to_list(struct ci_hw_ep *hwep, struct 
> ci_hw_req *hwreq,
>   if (hwreq->req.length == 0
>   || hwreq->req.length % hwep->ep.maxpacket)
>   mul++;
> - node->ptr->token |= mul << __ffs(TD_MULTO);
> + node->ptr->token |= cpu_to_le32(mul << __ffs(TD_MULTO));
>   }
>  
>   temp = (u32) (hwreq->req.dma + hwreq->req.actual);
> @@ -503,7 +503,7 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep, 
> struct ci_hw_req *hwreq)
>   if (hwreq->req.length == 0
>   || hwreq->req.length % hwep->ep.maxpacket)
>   mul++;
> - hwep->qh.ptr->cap |= mul << __ffs(QH_MULT);
> + hwep->qh.ptr->cap |= cpu_to_le32(mul << __ffs(QH_MULT));
>   }
>  
>   wmb();   /* synchronize before ep prime */
> @@ -530,7 +530,7 @@ static void free_pending_td(struct ci_hw_ep *hwep)
>  static int reprime_dtd(struct ci_hdrc *ci, struct ci_hw_ep *hwep,
>  struct td_node *node)
>  {
> - hwep->qh.ptr->td.next = node->dma;
> + hwep->qh.ptr->td.next = cpu_to_le32(node->dma);
>   hwep->qh.ptr->td.token &=
>   cpu_to_le32(~(TD_STATUS_HALTED | TD_STATUS_ACTIVE));
>  
> diff --git a/drivers/usb/chipidea/udc.h b/drivers/usb/chipidea/udc.h
> index e66df0020bd4..2ecd1174d66c 100644
> --- a/drivers/usb/chipidea/udc.h
> +++ b/drivers/usb/chipidea/udc.h
> @@ -22,11 +22,11 @@
>  /* DMA layout of transfer descriptors */
>  struct ci_hw_td {
>   /* 0 */
> - u32 next;
> + __le32 next;
>  #define TD_TERMINATE  BIT(0)
>  #define TD_ADDR_MASK  (0xFFEUL << 5)
>   /* 1 */
> - u32 token;
> + __le32 token;
>  #define TD_STATUS (0x00FFUL <<  0)
>  #define TD_STATUS_TR_ERR  BIT(3)
>  #define TD_STATUS_DT_ERR  BIT(5)
> @@ -36,7 +36,7 @@ struct ci_hw_td {
>  #define TD_IOCBIT(15)
>  #define TD_TOTAL_BYTES(0x7FFFUL << 16)
>   /* 2 */
> - u32 page[5];
> + __le32 page[5];
>  #define TD_CURR_OFFSET(0x0FFFUL <<  0)
>  #define TD_FRAME_NUM  (0x07FFUL <<  0)
>  #define TD_RESERVED_MASK  (0x0FFFUL <<  0)
> @@ -45,18 +45,18 @@ struct ci_hw_td {
>  /* DMA layout of queue heads */
>  struct ci_hw_qh {
>   /* 0 */
> - u32 cap;
> + __le32 cap;
>  #define QH_IOSBIT(15)
>  #define QH_MAX_PKT(0x07FFUL << 16)
>  #define QH_ZLTBIT(29)
>  #define QH_MULT   (0x0003UL << 30)
>  #define QH_ISO_MULT(x)   ((x >> 11) & 0x03)
>   /* 1 */
> - u32 curr;
> + __le32 curr;
>   /* 2 - 8 */
>   struct ci_hw_td td;
>   /* 9 */
> - u32 RESERVED;
> + __le32 RESERVED;
>   struct usb_ctrlrequest   setup;
>  } __attribute__ ((packed, aligned(4)));
>  
> -- 

Good catch, thanks.

-- 

Best Regards,
Peter Chen


Re: Build failure in -next due to 'kbuild: allow archs to select link dead code/data elimination'

2016-09-13 Thread Nicholas Piggin
On Tue, 13 Sep 2016 13:25:22 -0700
Guenter Roeck  wrote:

> On 09/12/2016 08:51 PM, Nicholas Piggin wrote:
> > On Mon, 12 Sep 2016 20:17:30 -0700
> > Guenter Roeck  wrote:
> >  
> >> Hi Nicholas,
> >>
> >> On 09/12/2016 07:00 PM, Nicholas Piggin wrote:  
> >>> On Mon, 12 Sep 2016 15:24:43 -0700
> >>> Guenter Roeck  wrote:
> >>>  
>  Hi,
> 
>  your commit 'kbuild: allow archs to select link dead code/data 
>  elimination'
>  is causing the following build failure in -next when building 
>  score:defconfig.
> 
>  arch/score/kernel/built-in.o: In function `work_resched':
>  arch/score/kernel/entry.o:(.text+0xe84):
>   relocation truncated to fit: R_SCORE_PC19 against `schedule'
> 
>  Reverting the commit fixes the problem.
> 
>  Please let me know if I can help tracking down the problem.
>  In case you need a score toochain, you can find the one I use at
>  http://server.roeck-us.net/toolchains/score.tgz.
> 
>  Thanks,
>  Guenter  
> >>>
> >>> It's not supposed to have any real effect unless the
> >>> option is selected, but there are a few changes to linker
> >>> script which must be causing it.
> >>>
> >>> There are two changes to vmlinux.lds.h. One is to KEEP a
> >>> few input sections, that *should* be kept anyway. The other
> >>> is to bring in additional sections into their correct output
> >>> section.
> >>>
> >>> Could you try reverting those lines of vmlinux.lds.h that
> >>> change the latter, i.e.:
> >>>
> >>> - *(.text.hot .text .text.fixup .text.unlikely)   \
> >>> + *(.text.hot .text .text.fixup .text.unlikely .text.*)   \  
> >>
> >> This is the culprit. After removing " .text.*" it builds fine.  
> >
> > Thanks for testing it. Some architectures have .text.x sections
> > not included here, I should have seen that. We should possibly
> > just revert that line and require implementing archs to do the
> > right thing.
> >  
> I would call the build failure a regression, so it should either be
> reverted, or we'll need some other solution to fix the build failure.

Yes it's definitely a regression and that part should be reverted.
To confirm, the following patch fixes your build?

Thanks,
Nick

commit 0ae28be83b4d6cd03ef5b481487d042f2b91954e
Author: Nicholas Piggin 
Date:   Wed Sep 14 12:24:03 2016 +1000

kbuild: -ffunction-sections fix for archs with conflicting sections

Enabling -ffunction-sections modified the generic linker script to
pull .text.* sections into regular TEXT_TEXT section, conflicting
with some architectures. Revert that change and require archs that
enable the option to ensure they have no conflicting section names,
and do the appropriate merging.

Signed-off-by: Nicholas Piggin 

diff --git a/arch/Kconfig b/arch/Kconfig
index 6d5b631..8248037 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -487,7 +487,9 @@ config LD_DEAD_CODE_DATA_ELIMINATION
  This requires that the arch annotates or otherwise protects
  its external entry points from being discarded. Linker scripts
  must also merge .text.*, .data.*, and .bss.* correctly into
- output sections.
+ output sections. Care must be taken not to pull in unrelated
+ sections (e.g., '.text.init'). Typically '.' in section names
+ is used to distinguish them from label names / C identifiers.
 
 config HAVE_CONTEXT_TRACKING
bool
diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index ad9d8f9..48dd44f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -198,9 +198,9 @@
 
 /*
  * .data section
- * -fdata-sections generates .data.identifier which needs to be pulled in
- * with .data, but don't want to pull in .data..stuff which has its own
- * requirements. Same for bss.
+ * LD_DEAD_CODE_DATA_ELIMINATION option enables -fdata-sections generates
+ * .data.identifier which needs to be pulled in with .data, but don't want to
+ * pull in .data..stuff which has its own requirements. Same for bss.
  */
 #define DATA_DATA  \
*(.data .data.[0-9a-zA-Z_]*)\
@@ -434,10 +434,15 @@
}
 
 /* .text section. Map to function alignment to avoid address changes
- * during second ld run in second ld pass when generating System.map */
+ * during second ld run in second ld pass when generating System.map
+ * LD_DEAD_CODE_DATA_ELIMINATION option enables -ffunction-sections generates
+ * .text.identifier which needs to be pulled in with .text , but some
+ * architectures define .text.foo which is not intended to be pulled in here.
+ * Those enabling LD_DEAD_CODE_DATA_ELIMINATION must ensure they don't have
+ * conflicting section names, and must pull in .text.[0-9a-zA-Z_]* */
 #define TEXT_TEXT 

Re: [PATCH] crypto: squash lines for simple wrapper functions

2016-09-13 Thread Joe Perches
On Wed, 2016-09-14 at 11:10 +0900, Masahiro Yamada wrote:
> 2016-09-13 4:44 GMT+09:00 Joe Perches :
> > On Tue, 2016-09-13 at 04:27 +0900, Masahiro Yamada wrote:
> > > Remove unneeded variables and assignments.
> > Was this found by visual inspection or some tool?
> > If it's via a tool, it's good to mention that in the changelog.
> I used Coccinelle, but I did not mention it
> in case somebody may say "then, please provide your semantic patch".
> As a Coccinelle beginner, I do not want to expose my stupid semantic patch.

If you get it "exposed", you'd likely learn something from others
that would give a few suggestions/tips on how to improve it.




Re: [PATCH v3 07/15] lockdep: Implement crossrelease feature

2016-09-13 Thread Byungchul Park
On Wed, Sep 14, 2016 at 4:38 AM, Peter Zijlstra  wrote:
> On Wed, Sep 14, 2016 at 02:12:51AM +0900, Byungchul Park wrote:
>> On Wed, Sep 14, 2016 at 12:05 AM, Peter Zijlstra  
>> wrote:
>> >
>> >
>> > So the idea is to add support for non-owner serialization primitives,
>> > like completions/semaphores, and so far I've not looked at the code yet.
>> > I did spend 2+ hours trying to decipher your documentation thing, but am
>> > still confused, that thing is exceedingly hard to parse/read.
>> >
>> > So the typical scenario would be something like:
>> >
>> > L a L a
>> > U a
>> > W b C b
>> >
>> > where L := lock, U := unlock, W := wait_for_completion and C :=
>> > complete.
>> >
>> > On the left, the blocking thread we can easily observe the 'b depends on
>> > a' relation, since we block while holding a.
>>
>> I think 'a depends on b' relation.
>>
>> Why does b depend on a? b depends on a's what?
>
> b blocks while holding a. In any case, for the graph it doesn't matter,
> its not a directed graph as such, all we care about is acyclic.

It's a directed graph.The meaning of backward traverse is different
from the meaning of forward traverse, isn't it?

>> > On the right however that same relation is hard to see, since by the
>>
>> Yes, there's no dependency on the right side of your example.
>
> Well, there is, its just not trivially observable. We must be able to
> acquire a in order to complete b, therefore there is a dependency.

No. We cannot say there is a dependency unconditionally. There can
be a dependency or not.

L a L a
U a
~ what if serialized by something?
W b C b

If something we don't recognize serializes locks, which ensures
'W b' happens after 'L a , U a' in the other context, then there's
no dependency here.

We should say 'b depends on a' in only case that the sequence
'W b and then L a and then C b, where last two ops are in same
context' _actually_ happened at least once. Otherwise, it might
add a false dependency.

It's same as how original lockdep works with typical locks. It adds
a dependency only when a lock is actually hit.

>> > time we would run complete, a has already been released.
>>
>> I will change your example a little bit.
>>
>> W b
>> ~~~ <- serialized
>> L a
>> U a
>> C b
>>
>> (Remind crossrelease considers dependencies in only case that
>> lock sequence serialized is observable.)
>
> What does that mean? Any why? This is a random point in time without
> actual meaning.

It's not random point. We have to consider meaningful sequences among
those which are globally observable. That's why we need to serialize
those locks. For example,

W b
L a
U a
C b

Once this sequence is observable globally, we can say 'It's possible to
run in this sequence. Is this sequence problematic or not?'.

L a
U a
W b
C b

If only this sequence can be observable, we should not assume
this sequence can be changed. However once the former sequence
happens, it has a possibility to hit the same sequence again later.
So we can check deadlock possibility with the sequence,

_not randomly_.

>> There's a dependency in this case, like 'b depends on a' relation.
>> 'C b' may not be hit, depending on the result of 'L a', that is,
>> acquired or not.
>
> With or without a random reference point, the dependency is there.

The dependency might not be there.

>> > I _think_ you propose to keep track of all prior held locks and then use
>> > the union of the held list on the block-chain with the prior held list
>> > from the complete context.
>>
>> Almost right. Only thing we need to do to consider the union is to
>> connect two chains of two contexts by adding one dependency 'b -> a'.
>
> Sure, but how do you arrive at which connection to make. The document is
> entirely silent on this crucial point.

We need to connect between the crosslock and the first lock among
locks having been acquired since the crosslock was held. Others will be
connected each other by original lockdep.

By the way, does my document miss this description? If so, sorry.
I will check and update it.

> The union between the held-locks of the blocked and prev-held-locks of
> the release should give a fair indication I think, but then, I've not
> thought too hard on this yet.

I make the union only If actually the lock sequence happened once so
that it's globally visible.

>> > The document describes you have a prior held list, and that its a
>> > circular thing, but it then completely fails to specify what gets added
>> > and how its used.
>>
>> Why does it fail? It keeps them in the form of hlock. This data is enough
>> to generate dependencies.
>
> It fails to explain. It just barely mentions you keep them, it doesn't
> mention how they're used or why.

Okay. I need to explain more about that.

>> > Also, by it being a circular list (of indeterminate, but finite size),
>> > there is the possibility of missing dependencies if 

[PATCH v2] sched/core: remove unnecessary initialization in sched_init()

2016-09-13 Thread Cheng Chao
init_idle() is called immediately after current->sched_class
= _sched_class, init_idle() sets current->sched_class
= _sched_class.

Signed-off-by: Cheng Chao 
Cc: sta...@vger.kernel.org
---
 kernel/sched/core.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a0086a5..ed4f4fe 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7557,11 +7557,6 @@ void __init sched_init(void)
enter_lazy_tlb(_mm, current);
 
/*
-* During early bootup we pretend to be a normal task:
-*/
-   current->sched_class = _sched_class;
-
-   /*
 * Make us the idle thread. Technically, schedule() should not be
 * called from this thread, however somewhere below it might be,
 * but because we are the idle thread, we just pick up running again
-- 
2.4.11



[PATCH] sched/core: emove unnecessary initialization in sched_init()

2016-09-13 Thread Cheng Chao
init_idle() is called immediately after current->sched_class
= _sched_class, init_idle() sets current->sched_class
= _sched_class.

Signed-off-by: Cheng Chao 
Cc: sta...@vger.kernel.org
---
 kernel/sched/core.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a0086a5..ed4f4fe 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -7557,11 +7557,6 @@ void __init sched_init(void)
enter_lazy_tlb(_mm, current);
 
/*
-* During early bootup we pretend to be a normal task:
-*/
-   current->sched_class = _sched_class;
-
-   /*
 * Make us the idle thread. Technically, schedule() should not be
 * called from this thread, however somewhere below it might be,
 * but because we are the idle thread, we just pick up running again
-- 
2.4.11



Re: [PATCH v4 22/22] phy: Add support for Qualcomm's USB HS phy

2016-09-13 Thread Peter Chen
On Tue, Sep 13, 2016 at 01:41:44PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-13 00:03:58)
> > On Wed, Sep 07, 2016 at 02:35:19PM -0700, Stephen Boyd wrote:
> > > The high-speed phy on qcom SoCs is controlled via the ULPI
> > > viewport.
> > > 
> > 
> > Hi Stephen, I am a little puzzled how this driver co-work with chipidea
> > driver. According to nxp IC guys, the ULPI PHY's clock needs to be enabled
> > before access portsc.pts (calling hw_phymode_configure), otherwise,
> > the system will hang. But I find you call hw_phymode_configure before
> > phy->power_on, doesn't your design have this requirement?
> 
> Which clk needs to be enabled? The xcvr_clk? I believe that clk
> corresponds to the "core" clk that we enable in the msm glue driver
> layer. When that clk is enabled, the ULPI phy is able to respond to
> register read/writes via the ULPI viewport.
> 

The input clock for ULPI PHY, maybe it is ref_clk at this PHY driver, 
so in your platform, even PHY clock is gated, you can still access
portsc.pts to configure PHY mode at controller register?

> >
> > Besides, you read ulpi id before phy->power_on, how can read work before
> > phy power on?
> > 
> 
> I've found that even having the link clk enabled before phy->power_on
> doesn't mean it's possible to read the id registers though. That's
> because there can be other power supplies, like regulators, which need
> to be on for the phy to operate properly.
> 

Then I am puzzled the current initialization for your case, in my mind,
it should like below:

qcom_usb_hs_phy_probe->qcom_usb_hs_phy_power_on->ci_ulpi_init

Like other PHYs, it should get PHY first, then power on it, after that,
you can access its register.

-- 

Best Regards,
Peter Chen


Re: [PATCH] crypto: squash lines for simple wrapper functions

2016-09-13 Thread Masahiro Yamada
Hi Joe,

2016-09-13 4:44 GMT+09:00 Joe Perches :
> On Tue, 2016-09-13 at 04:27 +0900, Masahiro Yamada wrote:
>> Remove unneeded variables and assignments.
>
> Was this found by visual inspection or some tool?
>
> If it's via a tool, it's good to mention that in the changelog.


I used Coccinelle, but I did not mention it
in case somebody may say "then, please provide your semantic patch".

As a Coccinelle beginner, I do not want to expose my stupid semantic patch.



-- 
Best Regards
Masahiro Yamada


RE: [PATCH for-next 10/20] IB/hns: Modify the init of iboe lock

2016-09-13 Thread Salil Mehta


> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-
> ow...@vger.kernel.org] On Behalf Of Leon Romanovsky
> Sent: Tuesday, September 13, 2016 7:50 AM
> To: Salil Mehta
> Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> xuwei (O); mehta.salil@gmail.com; linux-r...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Linuxarm; Huangdongdong (Donald)
> Subject: Re: [PATCH for-next 10/20] IB/hns: Modify the init of iboe
> lock
> 
> On Fri, Sep 09, 2016 at 06:30:41PM +0800, Salil Mehta wrote:
> > From: Lijun Ou 
> >
> > This lock will be used in query port interface, and will be called
> > while IB device was registered to OFED frame. So, the lock of iboe
> > must be initiated before IB device was registered.
> 
> Sorry,
> what did you mean by writing "OFED frame"?
It is a typo. It was OFED framework but I guess more appropriate word 
might have been 'IB core' layer of Infiniband. Will fix this. Thanks! 

Best regards
Salil
> 
> >
> > Signed-off-by: Lijun Ou 
> > Signed-off-by: Dongdong Huang(Donald) 
> > Reviewed-by:  Wei Hu (Xavier) 
> > Signed-off-by: Salil Mehta 
> > ---
> >  drivers/infiniband/hw/hns/hns_roce_main.c |3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_main.c
> b/drivers/infiniband/hw/hns/hns_roce_main.c
> > index 2704076..4721c0c 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_main.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_main.c
> > @@ -615,6 +615,7 @@ static int hns_roce_register_device(struct
> hns_roce_dev *hr_dev)
> > struct device *dev = _dev->pdev->dev;
> >
> > iboe = _dev->iboe;
> > +   spin_lock_init(>lock);
> >
> > ib_dev = _dev->ib_dev;
> > strlcpy(ib_dev->name, "hisi_%d", IB_DEVICE_NAME_MAX);
> > @@ -701,8 +702,6 @@ static int hns_roce_register_device(struct
> hns_roce_dev *hr_dev)
> > goto error_failed_setup_mtu_gids;
> > }
> >
> > -   spin_lock_init(>lock);
> > -
> > iboe->nb.notifier_call = hns_roce_netdev_event;
> > ret = register_netdevice_notifier(>nb);
> > if (ret) {
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH for-next 16/20] IB/hns: Validate mtu when modified qp

2016-09-13 Thread Salil Mehta


> -Original Message-
> From: Leon Romanovsky [mailto:l...@kernel.org]
> Sent: Tuesday, September 13, 2016 7:33 AM
> To: Salil Mehta
> Cc: dledf...@redhat.com; Huwei (Xavier); oulijun; Zhuangyuzeng (Yisen);
> xuwei (O); mehta.salil@gmail.com; linux-r...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Linuxarm; chenguolong (A)
> Subject: Re: [PATCH for-next 16/20] IB/hns: Validate mtu when modified
> qp
> 
> On Fri, Sep 09, 2016 at 06:30:47PM +0800, Salil Mehta wrote:
> > From: Lijun Ou 
> >
> > The mtu should be validated when modify qp,so we check it.
> >
> > Signed-off-by: Lijun Ou 
> > Signed-off-by: Peter Chen 
> > Reviewed-by:  Wei Hu (Xavier) 
> > Signed-off-by: Salil Mehta 
> > ---
> >  drivers/infiniband/hw/hns/hns_roce_qp.c |   15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_qp.c
> b/drivers/infiniband/hw/hns/hns_roce_qp.c
> > index 51fefbf..1c5be59 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_qp.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_qp.c
> > @@ -32,6 +32,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include "hns_roce_common.h"
> >  #include "hns_roce_device.h"
> > @@ -658,6 +659,7 @@ int hns_roce_modify_qp(struct ib_qp *ibqp, struct
> ib_qp_attr *attr,
> > struct device *dev = _dev->pdev->dev;
> > int ret = -EINVAL;
> > int p;
> > +   u32 active_mtu = 0;
> 
> There is no need to assign value to a variable which will be
> overwritten.
Agreed. This initialization seems redundant. Will remove. Thanks!

Best regards
Salil
> 
> >
> > mutex_lock(_qp->mutex);
> >
> > @@ -688,6 +690,19 @@ int hns_roce_modify_qp(struct ib_qp *ibqp,
> struct ib_qp_attr *attr,
> > }
> > }
> >
> > +   if (attr_mask & IB_QP_PATH_MTU) {
> > +   p = attr_mask & IB_QP_PORT ? (attr->port_num - 1) : hr_qp-
> >port;
> > +   active_mtu = iboe_get_mtu(hr_dev->iboe.netdevs[p]->mtu);
> 
> ib_mtu iboe_get_mtu returns "enum ib_mtu" and not u32.
Ok. This can be converted to 'enum'. Will change. Thanks!

Best regards
Salil 
> 
> > +
> > +   if (attr->path_mtu > IB_MTU_2048 ||
> > +   attr->path_mtu < IB_MTU_256 ||
> > +   attr->path_mtu > active_mtu) {
> > +   dev_err(dev, "attr path_mtu(%d)invalid while modify
> qp",
> > +   attr->path_mtu);
> > +   goto out;
> > +   }
> > +   }
> > +
> > if (attr_mask & IB_QP_MAX_QP_RD_ATOMIC &&
> > attr->max_rd_atomic > hr_dev->caps.max_qp_init_rdma) {
> > dev_err(dev, "attr max_rd_atomic invalid.attr-
> >max_rd_atomic=%d\n",
> > --
> > 1.7.9.5
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-rdma"
> in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3] stop_machine: Make migration_cpu_stop() does useful works for CONFIG_PREEMPT_NONE

2016-09-13 Thread Cheng Chao

great, __schedule() doesn't need pay any attention to the TASK_DEAD now.

on 09/14/2016 12:37 AM, Peter Zijlstra wrote:
> On Tue, Sep 13, 2016 at 06:14:27PM +0200, Oleg Nesterov wrote:
> 
>> Me too, and I failed to find something which could be broken... So
>> perhaps should make it nop and investigate the new bug reports after
>> that.
> 
> Works for me :-)
> 
>>
>> Hmm. And  preempt_enable_no_resched_notrace() under TASK_DEAD in
>> __schedule() should be removed it seems, do_exit() can call __schedule()
>> directly.
> 
> 
> something like so?
> 
> ---
> 
>  include/linux/kernel.h |  2 +-
>  include/linux/sched.h  |  2 ++
>  kernel/exit.c  | 11 ++-
>  kernel/sched/core.c| 23 ---
>  4 files changed, 17 insertions(+), 21 deletions(-)
> 
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index d96a6118d26a..e5bd9cdd2e24 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -266,7 +266,7 @@ extern void oops_enter(void);
>  extern void oops_exit(void);
>  void print_oops_end_marker(void);
>  extern int oops_may_print(void);
> -void do_exit(long error_code)
> +void __noreturn do_exit(long error_code)
>   __noreturn;
>  void complete_and_exit(struct completion *, long)
>   __noreturn;
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index eb64fcd89e68..b0c818a05b2e 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -448,6 +448,8 @@ static inline void io_schedule(void)
>   io_schedule_timeout(MAX_SCHEDULE_TIMEOUT);
>  }
>  
> +void __noreturn do_task_dead(void);
> +
>  struct nsproxy;
>  struct user_namespace;
>  
> diff --git a/kernel/exit.c b/kernel/exit.c
> index 091a78be3b09..d4c12692f766 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -725,7 +725,7 @@ static void check_stack_usage(void)
>  static inline void check_stack_usage(void) {}
>  #endif
>  
> -void do_exit(long code)
> +void __noreturn do_exit(long code)
>  {
>   struct task_struct *tsk = current;
>   int group_dead;
> @@ -897,14 +897,7 @@ void do_exit(long code)
>   smp_mb();
>   raw_spin_unlock_wait(>pi_lock);
>  
> - /* causes final put_task_struct in finish_task_switch(). */
> - tsk->state = TASK_DEAD;
> - tsk->flags |= PF_NOFREEZE;  /* tell freezer to ignore us */
> - schedule();
> - BUG();
> - /* Avoid "noreturn function does return".  */
> - for (;;)
> - cpu_relax();/* For when BUG is null */
> + do_task_dead();
>  }
>  EXPORT_SYMBOL_GPL(do_exit);
>  
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a0086a5fc008..6034f269000f 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -3327,17 +3327,6 @@ static void __sched notrace __schedule(bool preempt)
>   rq = cpu_rq(cpu);
>   prev = rq->curr;
>  
> - /*
> -  * do_exit() calls schedule() with preemption disabled as an exception;
> -  * however we must fix that up, otherwise the next task will see an
> -  * inconsistent (higher) preempt count.
> -  *
> -  * It also avoids the below schedule_debug() test from complaining
> -  * about this.
> -  */
> - if (unlikely(prev->state == TASK_DEAD))
> - preempt_enable_no_resched_notrace();
> -
>   schedule_debug(prev);
>  
>   if (sched_feat(HRTICK))
> @@ -3404,6 +3393,18 @@ static void __sched notrace __schedule(bool preempt)
>   balance_callback(rq);
>  }
>  
> +void __noreturn do_task_dead(void)
> +{
> + /* causes final put_task_struct in finish_task_switch(). */
> + __set_current_state(TASK_DEAD);
> + current->flags |= PF_NOFREEZE;  /* tell freezer to ignore us */
> + __schedule(false);
> + BUG();
> + /* Avoid "noreturn function does return".  */
> + for (;;)
> + cpu_relax();/* For when BUG is null */
> +}
> +
>  static inline void sched_submit_work(struct task_struct *tsk)
>  {
>   if (!tsk->state || tsk_is_pi_blocked(tsk))
> 


[PATCH v4] stop_machine: Avoid a sleep and wakeup in the stop_one_cpu()

2016-09-13 Thread Cheng Chao
In case @cpu == smp_proccessor_id(), we can avoid a sleep+wakeup
by doing a preemption.

the caller such as sched_exec can benefit from this change.

Signed-off-by: Cheng Chao 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
---
 kernel/sched/core.c   | 8 ++--
 kernel/stop_machine.c | 5 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a0086a5..283b662 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1063,8 +1063,12 @@ static int migration_cpu_stop(void *data)
 * holding rq->lock, if p->on_rq == 0 it cannot get enqueued because
 * we're holding p->pi_lock.
 */
-   if (task_rq(p) == rq && task_on_rq_queued(p))
-   rq = __migrate_task(rq, p, arg->dest_cpu);
+   if (task_rq(p) == rq) {
+   if (task_on_rq_queued(p))
+   rq = __migrate_task(rq, p, arg->dest_cpu);
+   else
+   p->wake_cpu = arg->dest_cpu;
+   }
raw_spin_unlock(>lock);
raw_spin_unlock(>pi_lock);
 
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 4a1ca5f..1a24890 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -126,6 +126,11 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, void 
*arg)
cpu_stop_init_done(, 1);
if (!cpu_stop_queue_work(cpu, ))
return -ENOENT;
+   /*
+* In case @cpu == smp_proccessor_id() we can avoid a sleep+wakeup
+* by doing a preemption.
+*/
+   cond_resched();
wait_for_completion();
return done.ret;
 }
-- 
2.4.11



Re: [PATCH v20 00/20] perf, tools: Add support for PMU events in JSON format

2016-09-13 Thread Michael Ellerman
Jiri Olsa  writes:

> On Wed, Aug 31, 2016 at 09:15:30AM -0700, Andi Kleen wrote:
>> > > 
>> > > > 
>> > > > I've already made some changes in pmu-events/* to support
>> > > > this hierarchy to see how bad the change would be.. and
>> > > > it's not that bad ;-)
>> > > 
>> > > Everything has to be automated, please no manual changes.
>> > 
>> > sure
>> > 
>> > so, if you're ok with the layout, how do you want to proceed further?
>> 
>> If the split version is acceptable it's fine for me to merge it.
>> 
>> I'll add split-json to my scripting, so the next update would
>> be split too.
>
> ook, I'll wait for patches then

Who are you waiting for patches from?

Would be great if this could go in for 4.9 still.

cheers


[RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

2016-09-13 Thread Stephen Boyd
On the db410c 96boards platform we have a TC7USB40MU[1] on the
board to mux the D+/D- lines from the SoC between a micro usb
"device" port and a USB hub for "host" roles. Upon a role switch,
we need to change this mux to forward the D+/D- lines to either
the port or the hub. Therefore, introduce a driver for this
device that intercepts extcon USB_HOST events and logically
asserts a gpio to mux the "host" D+/D- lines when a host cable is
attached. When the cable goes away, it will logically deassert
the gpio and mux the "device" lines.

[1] 
https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html

Cc: MyungJoo Ham 
Cc: Chanwoo Choi 
Cc: 
Signed-off-by: Stephen Boyd 
---

Should I make the extcon part optional? I could see a case where there are two
"OTG" ports connected to the mux (or two hubs), and for some reason the
software may want to mux between them at runtime. If we mandate an extcon,
that won't be possible to support. Perhaps it would be better to have
the node, but connect it to the usb controller with a phandle (maybe of_graph
endpoints would be useful too) so that when the controller wants to mux over
a port it can do so.

Muxing the ports this way based on ID cable is pretty much a software
design decision. We could mux the ports during the role switch, and the
role switch can be entirely userspace driven with the chipidea controller
that I'm using (see the role switching support in the "role" file for
debugfs support in that driver). So extcon cables don't come into the picture
in that scenario.

 .../devicetree/bindings/usb/toshiba,tc7usb40mu.txt |  34 +++
 drivers/usb/misc/Kconfig   |   9 ++
 drivers/usb/misc/Makefile  |   1 +
 drivers/usb/misc/tc7usb40mu.c  | 107 +
 4 files changed, 151 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt
 create mode 100644 drivers/usb/misc/tc7usb40mu.c

diff --git a/Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt 
b/Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt
new file mode 100644
index ..18e6607408fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/toshiba,tc7usb40mu.txt
@@ -0,0 +1,34 @@
+Toshiba TC7USB40MU
+
+This device muxes USB D+/D- lines between two outputs called 1D+/1D- and 
2D+/2D-.
+When the switch pin is asserted, we mux out 2D+/2D-, and when it's deasserted 
we
+select 1D+/1D-.
+
+This can be used to mux USB D+/D- lines between a USB hub and an OTG port.
+
+PROPERTIES
+
+- compatible:
+Usage: required
+Value type: 
+Definition: Should contain "toshiba,tc7usb40mu"
+
+- switch-gpios:
+Usage: required
+Value type: 
+Definition: Should contain the gpio used to toggle the switch. Logically
+asserting the gpio will cause the device to mux the "host"
+D+/D- lines instead of the "device" lines.
+
+- extcon:
+Usage: required
+Value type: 
+Definition: Should contain the extcon device for USB_HOST cable events
+
+Example:
+
+   usb-switch {
+   compatible = "toshiba,tc7usb40mu";
+   switch-gpios = < 10 GPIO_ACTIVE_HIGH>;
+   extcon = <_id>;
+   };
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 47b357760afc..3da568c751d2 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -46,6 +46,15 @@ config USB_SEVSEG
  To compile this driver as a module, choose M here: the
  module will be called usbsevseg.
 
+config USB_TC7USB40MU
+   tristate "TC7USB40MU USB mux support"
+   depends on (GPIOLIB && EXTCON) || COMPILE_TEST
+   help
+ Say Y here if you have a TC7USB40MU by Toshiba. If a USB ID cable is
+ present, a gpio will be asserted to mux out "host" D+/D- lines and 
when
+ the ID cable is removed, a gpio will be deasserted to mux out "device"
+ D+/D- lines.
+
 config USB_RIO500
tristate "USB Diamond Rio500 support"
help
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 3d1992750da4..d8f9ad1dee13 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_USB_LEGOTOWER)   += legousbtower.o
 obj-$(CONFIG_USB_RIO500)   += rio500.o
 obj-$(CONFIG_USB_TEST) += usbtest.o
 obj-$(CONFIG_USB_EHSET_TEST_FIXTURE)+= ehset.o
+obj-$(CONFIG_USB_TC7USB40MU)   += tc7usb40mu.o
 obj-$(CONFIG_USB_TRANCEVIBRATOR)   += trancevibrator.o
 obj-$(CONFIG_USB_USS720)   += uss720.o
 obj-$(CONFIG_USB_SEVSEG)   += usbsevseg.o
diff --git a/drivers/usb/misc/tc7usb40mu.c b/drivers/usb/misc/tc7usb40mu.c
new file mode 100644
index ..9edcfe577ae4
--- /dev/null
+++ b/drivers/usb/misc/tc7usb40mu.c
@@ -0,0 

[PATCH 0/2] nfit: fail DSMs that return an unknown status value

2016-09-13 Thread Dan Williams
When the kernel knows the format of a DSM and is consuming the data
internal to the kernel, it needs to be careful to fail DSMs that return
an error.  Recall that DSMs, ACPI Device Specific Methods, are used by
the kernel to manipulate namespace label data, and scan for media
errors.  For example, if a namespace label read command fails the
returned data is undefined and should not be consumed by the libnvdimm
core to make namespace provisioning decisions.

Also, add new unit test capability to allow dynamic failure injection
for DSMs sent to nfit_test devices.

---

Dan Williams (2):
  nfit: fail DSMs that return non-zero status by default
  tools/testing/nvdimm: test get_config_size DSM failures


 drivers/acpi/nfit/core.c |   48 +--
 tools/testing/nvdimm/test/nfit.c |   79 +-
 2 files changed, 105 insertions(+), 22 deletions(-)


[PATCH 1/2] nfit: fail DSMs that return non-zero status by default

2016-09-13 Thread Dan Williams
For the DSMs where the kernel knows the format of the output buffer and
originates those DSMs from within the kernel, return -EIO for any
non-zero status.  If the BIOS is indicating a status that we do not know
how to handle, fail the DSM.

Signed-off-by: Dan Williams 
---
 drivers/acpi/nfit/core.c |   48 +++---
 1 file changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c
index ceb6671ab355..8d7cbecd7cce 100644
--- a/drivers/acpi/nfit/core.c
+++ b/drivers/acpi/nfit/core.c
@@ -94,54 +94,50 @@ static struct acpi_device *to_acpi_dev(struct 
acpi_nfit_desc *acpi_desc)
return to_acpi_device(acpi_desc->dev);
 }
 
-static int xlat_status(void *buf, unsigned int cmd)
+static int xlat_status(void *buf, unsigned int cmd, u32 status)
 {
struct nd_cmd_clear_error *clear_err;
struct nd_cmd_ars_status *ars_status;
-   struct nd_cmd_ars_start *ars_start;
-   struct nd_cmd_ars_cap *ars_cap;
u16 flags;
 
switch (cmd) {
case ND_CMD_ARS_CAP:
-   ars_cap = buf;
-   if ((ars_cap->status & 0x) == NFIT_ARS_CAP_NONE)
+   if ((status & 0x) == NFIT_ARS_CAP_NONE)
return -ENOTTY;
 
/* Command failed */
-   if (ars_cap->status & 0x)
+   if (status & 0x)
return -EIO;
 
/* No supported scan types for this range */
flags = ND_ARS_PERSISTENT | ND_ARS_VOLATILE;
-   if ((ars_cap->status >> 16 & flags) == 0)
+   if ((status >> 16 & flags) == 0)
return -ENOTTY;
break;
case ND_CMD_ARS_START:
-   ars_start = buf;
/* ARS is in progress */
-   if ((ars_start->status & 0x) == NFIT_ARS_START_BUSY)
+   if ((status & 0x) == NFIT_ARS_START_BUSY)
return -EBUSY;
 
/* Command failed */
-   if (ars_start->status & 0x)
+   if (status & 0x)
return -EIO;
break;
case ND_CMD_ARS_STATUS:
ars_status = buf;
/* Command failed */
-   if (ars_status->status & 0x)
+   if (status & 0x)
return -EIO;
/* Check extended status (Upper two bytes) */
-   if (ars_status->status == NFIT_ARS_STATUS_DONE)
+   if (status == NFIT_ARS_STATUS_DONE)
return 0;
 
/* ARS is in progress */
-   if (ars_status->status == NFIT_ARS_STATUS_BUSY)
+   if (status == NFIT_ARS_STATUS_BUSY)
return -EBUSY;
 
/* No ARS performed for the current boot */
-   if (ars_status->status == NFIT_ARS_STATUS_NONE)
+   if (status == NFIT_ARS_STATUS_NONE)
return -EAGAIN;
 
/*
@@ -149,19 +145,19 @@ static int xlat_status(void *buf, unsigned int cmd)
 * agent wants the scan to stop.  If we didn't overflow
 * then just continue with the returned results.
 */
-   if (ars_status->status == NFIT_ARS_STATUS_INTR) {
+   if (status == NFIT_ARS_STATUS_INTR) {
if (ars_status->flags & NFIT_ARS_F_OVERFLOW)
return -ENOSPC;
return 0;
}
 
/* Unknown status */
-   if (ars_status->status >> 16)
+   if (status >> 16)
return -EIO;
break;
case ND_CMD_CLEAR_ERROR:
clear_err = buf;
-   if (clear_err->status & 0x)
+   if (status & 0x)
return -EIO;
if (!clear_err->cleared)
return -EIO;
@@ -172,6 +168,9 @@ static int xlat_status(void *buf, unsigned int cmd)
break;
}
 
+   /* all other non-zero status results in an error */
+   if (status)
+   return -EIO;
return 0;
 }
 
@@ -186,10 +185,10 @@ static int acpi_nfit_ctl(struct nvdimm_bus_descriptor 
*nd_desc,
struct nd_cmd_pkg *call_pkg = NULL;
const char *cmd_name, *dimm_name;
unsigned long cmd_mask, dsm_mask;
+   u32 offset, fw_status = 0;
acpi_handle handle;
unsigned int func;
const u8 *uuid;
-   u32 offset;
int rc, i;
 
func = cmd;
@@ -317,6 +316,15 @@ static int acpi_nfit_ctl(struct nvdimm_bus_descriptor 
*nd_desc,
out_obj->buffer.pointer + offset, out_size);
offset += out_size;
}
+
+   /*
+* Set fw_status for all the commands with a known format to be
+

[PATCH 2/2] tools/testing/nvdimm: test get_config_size DSM failures

2016-09-13 Thread Dan Williams
Add an nfit_test specific attribute for gating whether a get_config_size
DSM, or any DSM for that matter, succeeds or fails.  The get_config_size
DSM is initial motivation since that is the first command libnvdimm core
issues to determine the state of the namespace label area.

Signed-off-by: Dan Williams 
---
 tools/testing/nvdimm/test/nfit.c |   79 +-
 1 file changed, 77 insertions(+), 2 deletions(-)

diff --git a/tools/testing/nvdimm/test/nfit.c b/tools/testing/nvdimm/test/nfit.c
index 99ea68674f0a..e5404f1b8f90 100644
--- a/tools/testing/nvdimm/test/nfit.c
+++ b/tools/testing/nvdimm/test/nfit.c
@@ -132,6 +132,8 @@ static u32 handle[NUM_DCR] = {
[4] = NFIT_DIMM_HANDLE(0, 1, 0, 0, 0),
 };
 
+static unsigned long dimm_fail_cmd_flags[NUM_DCR];
+
 struct nfit_test {
struct acpi_nfit_desc acpi_desc;
struct platform_device pdev;
@@ -414,6 +416,9 @@ static int nfit_test_ctl(struct nvdimm_bus_descriptor 
*nd_desc,
if (i >= ARRAY_SIZE(handle))
return -ENXIO;
 
+   if ((1 << func) & dimm_fail_cmd_flags[i])
+   return -EIO;
+
switch (func) {
case ND_CMD_GET_CONFIG_SIZE:
rc = nfit_test_cmd_get_config_size(buf, buf_len);
@@ -582,6 +587,74 @@ static void put_dimms(void *data)
 
 static struct class *nfit_test_dimm;
 
+static int dimm_name_to_id(struct device *dev)
+{
+   int dimm;
+
+   if (sscanf(dev_name(dev), "test_dimm%d", ) != 1
+   || dimm >= NUM_DCR || dimm < 0)
+   return -ENXIO;
+   return dimm;
+}
+
+
+static ssize_t handle_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   int dimm = dimm_name_to_id(dev);
+
+   if (dimm < 0)
+   return dimm;
+
+   return sprintf(buf, "%#lx", handle[dimm]);
+}
+DEVICE_ATTR_RO(handle);
+
+static ssize_t fail_cmd_show(struct device *dev, struct device_attribute *attr,
+   char *buf)
+{
+   int dimm = dimm_name_to_id(dev);
+
+   if (dimm < 0)
+   return dimm;
+
+   return sprintf(buf, "%#lx\n", dimm_fail_cmd_flags[dimm]);
+}
+
+static ssize_t fail_cmd_store(struct device *dev, struct device_attribute 
*attr,
+   const char *buf, size_t size)
+{
+   int dimm = dimm_name_to_id(dev);
+   unsigned long val;
+   ssize_t rc;
+
+   if (dimm < 0)
+   return dimm;
+
+   rc = kstrtol(buf, 0, );
+   if (rc)
+   return rc;
+
+   dimm_fail_cmd_flags[dimm] = val;
+   return size;
+}
+static DEVICE_ATTR_RW(fail_cmd);
+
+static struct attribute *nfit_test_dimm_attributes[] = {
+   _attr_fail_cmd.attr,
+   _attr_handle.attr,
+   NULL,
+};
+
+static struct attribute_group nfit_test_dimm_attribute_group = {
+   .attrs = nfit_test_dimm_attributes,
+};
+
+static const struct attribute_group *nfit_test_dimm_attribute_groups[] = {
+   _test_dimm_attribute_group,
+   NULL,
+};
+
 static int nfit_test0_alloc(struct nfit_test *t)
 {
size_t nfit_size = sizeof(struct acpi_nfit_system_address) * NUM_SPA
@@ -640,8 +713,10 @@ static int nfit_test0_alloc(struct nfit_test *t)
if (devm_add_action_or_reset(>pdev.dev, put_dimms, t->dimm_dev))
return -ENOMEM;
for (i = 0; i < NUM_DCR; i++) {
-   t->dimm_dev[i] = device_create(nfit_test_dimm, >pdev.dev, 0,
-   NULL, "test_dimm%d", i);
+   t->dimm_dev[i] = device_create_with_groups(nfit_test_dimm,
+   >pdev.dev, 0, NULL,
+   nfit_test_dimm_attribute_groups,
+   "test_dimm%d", i);
if (!t->dimm_dev[i])
return -ENOMEM;
}



Re: KVM patches applied in weird order in -stable

2016-09-13 Thread Greg KH
On Tue, Sep 13, 2016 at 06:58:40PM +0200, Paolo Bonzini wrote:
> 
> 
> On 13/09/2016 18:57, Greg KH wrote:
>  > >>  [0] commit 4e422bdd2f84 ("KVM: x86: fix missed hardware 
>  > >> breakpoints")
>  > >>  [1] commit 172b2386ed16 ("KVM: x86: fix missed hardware 
>  > >> breakpoints")
>  > >>  [2] commit 70e4da7a8ff6 ("KVM: x86: fix root cause for missed 
>  > >> hardware breakpoints")
>  > >>
>  > >> but this is the order for linux-4.4.y
>  > >>
>  > >>  [1] commit fc90441e728a ("KVM: x86: fix missed hardware 
>  > >> breakpoints")
>  > >>  [2] commit 25e8618619a5 ("KVM: x86: fix root cause for missed 
>  > >> hardware breakpoints")
>  > >>  [0] commit 0f6e5e26e68f ("KVM: x86: fix missed hardware 
>  > >> breakpoints")
>  > >>
>  > >> The upshot is that KVM_DEBUGREG_RELOAD is always set when returning
>  > >> from kvm_arch_vcpu_load() in stable, but not in Linus' tree.
> >>> > > 
> >>> > > How would applying these in a different order cause breakage?
> >> > 
> >> > [2] is reverting [0]+[1].  Stable is not due to the different order.
> > Really?  Are you sure that [0] and [1] isn't just the same commit?  It
> > looks like that to me.
> 
> It is; "git" automatically resolved the conflicts when merging [1], and
> then [2] reverted the change.  In stable, changing the order created a
> different conflict resolution.

Yes, given that I turn them into individual patches, the order I used
was really the only one that would work, and is how this happened :)

thanks,

greg k-h


Re: [RFC/RFT][PATCH v2 2/7] driver core: Functional dependencies tracking support

2016-09-13 Thread Rafael J. Wysocki
On Sunday, September 11, 2016 10:43:36 PM Lukas Wunner wrote:
> On Sun, Sep 11, 2016 at 03:40:58PM +0200, Lukas Wunner wrote:
> > On Thu, Sep 08, 2016 at 11:27:45PM +0200, Rafael J. Wysocki wrote:
> > > +/**
> > > + * device_is_dependent - Check if one device depends on another one
> > > + * @dev: Device to check dependencies for.
> > > + * @target: Device to check against.
> > > + *
> > > + * Check if @dev or any device dependent on it (its child or its 
> > > consumer etc)
> > > + * depends on @target.  Return 1 if that is the case or 0 otherwise.
> > > + */
> > > +static int device_is_dependent(struct device *dev, void *target)
> > > +{
> > > + struct device_link *link;
> > > + int ret;
> > > +
> > > + ret = device_for_each_child(dev, target, device_is_dependent);
> > > + list_for_each_entry(link, >links_to_consumers, s_node) {
> > > + if (WARN_ON(link->consumer == target))
> > > + return 1;
> > > +
> > > + ret = ret || device_is_dependent(link->consumer, target);
> > > + }
> > > + return ret;
> > > +}
> > 
> > What happens if someone tries to add a device link from a parent
> > (as the consumer) to a child (as a supplier)?  You're only checking
> > if target is a consumer of dev, for full correctness you'd also have
> > to check if target is a parent of dev.  (Or grandparent, or great-
> > grandparent, ... you need to walk the tree up to the root.)
> > 
> > 
> > The function can be sped up by returning immediately if a match
> > is found instead of continuing searching and accumulating the
> > result in ret, i.e.:
> > 
> > if (device_for_each_child(dev, target, device_is_dependent))
> > return 1;
> > 
> > and in the list_for_each_entry block:
> > 
> > if (device_is_dependent(link->consumer, target))
> > return 1;
> > 
> > Then at the end of the function "return 0".
> > 
> > 
> > I'd move the WARN_ON() to the single invocation of this function in
> > device_link_add(), that way it's possible to use the function as a
> > helper elsewhere should the need arise.
> 
> Oh I'm grasping only now, you want to emit a WARN for *every*
> infringing child/consumer. That could lead to a WARN flood if
> a developer accidentally does something really dumb, like linking
> the PCI root to some PCI endpoint device, but fair enough.
> 
> The point about linking a parent to a child still stands however.
> I think a simple way to check this is to just add
> 
>   if (WARN_ON(dev == target))
>   return 1;
> 
> at the top of the function, because when someone tries to link
> a parent to a child, when recursing from the parent downward
> one will eventually hit that child. This will also prevent
> someone from linking a device to itself.

I actually would prefer to make it impossible to link a parent to
a child at all.

Thanks,
Rafael



Re: [RFC/RFT][PATCH v2 6/7] PM / runtime: Use device links

2016-09-13 Thread Rafael J. Wysocki
On Monday, September 12, 2016 03:57:02 PM Rafael J. Wysocki wrote:
> On Monday, September 12, 2016 11:47:58 AM Lukas Wunner wrote:
> > On Thu, Sep 08, 2016 at 11:30:26PM +0200, Rafael J. Wysocki wrote:
> > > Modify the runtime PM framework to use device links to ensure that
> > > supplier devices will not be suspended if any of their consumer
> > > devices are active.
> > 
> > I think it's inconsistent to runtime resume/suspend suppliers in
> > __rpm_callback() whereas the parent is treated in rpm_suspend()
> > and rpm_resume().
> 
> The reason why I did that this way is the rollback needed in case of
> errors and that led to duplicated code if done elsewhere.
> 
> > Instead I'd suggest to amend struct dev_pm_ops with:
> > atomic_tconsumer_count;
> > 
> > Amend rpm_check_suspend_allowed() with:
> > else if (atomic_read(>power.consumer_count) > 0)
> > retval = -EBUSY;
> 
> That is a good idea, though (from the first look at least).

No, I actually don't like it.

Suppliers are not parents and even the separate counter we have for
parents is somewhat artificial.

For parents it may be argued that they are always there, so handling them
in a special way is justified, but for suppliers I really don't see why
adding a new counter would be better.

Thanks,
Rafael



Re: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix user space reporting

2016-09-13 Thread Rafael J. Wysocki
On Wednesday, July 20, 2016 03:10:04 PM Al Stone wrote:
> When CPPC is being used by ACPI on arm64, user space tools such as
> cpupower report CPU frequency values from sysfs that are incorrect.
> 
> What the driver was doing was reporting the values given by ACPI tables
> in whatever scale was used to provide them.  However, the ACPI spec
> defines the CPPC values as unitless abstract numbers.  Internal kernel
> structures such as struct perf_cap, in contrast, expect these values
> to be in KHz.  When these struct values get reported via sysfs, the
> user space tools also assume they are in KHz, causing them to report
> incorrect values (for example, reporting a CPU frequency of 1MHz when
> it should be 1.8GHz).
> 
> The downside is that this approach has some assumptions:
> 
>(1) It relies on SMBIOS3 being used, *and* that the Max Frequency
>value for a processor is set to a non-zero value.
> 
>(2) It assumes that all processors run at the same speed, or that
>the CPPC values have all been scaled to reflect relative speed.
>This patch retrieves the largest CPU Max Frequency from a type 4 DMI
>record that it can find.  This may not be an issue, however, as a
>sampling of DMI data on x86 and arm64 indicates there is often only
>one such record regardless.  Since CPPC is relatively new, it is
>unclear if the ACPI ASL will always be written to reflect any sort
>of relative performance of processors of differing speeds.
> 
>(3) It assumes that performance and frequency both scale linearly.
> 
> For arm64 servers, this may be sufficient, but it does rely on
> firmware values being set correctly.  Hence, other approaches will
> be considered in the future.
> 
> This has been tested on three arm64 servers, with and without DMI, with
> and without CPPC support.
> 
> Changes for v5:
> -- Move code to cpufreq/cppc_cpufreq.c from acpi/cppc_acpi.c to keep
>frequency-related code together, and keep the CPPC abstract scale
>in ACPI (Prashanth Prakash)
> -- Fix the scaling to remove the incorrect assumption that frequency
>was always a range from zero to max; as a practical matter, it is
>not (Prasanth Prakash); this also allowed us to remove an over-
>engineered function to do this math.
> 
> Changes for v4:
> -- Replaced magic constants with #defines (Rafael Wysocki)
> -- Renamed cppc_unitless_to_khz() to cppc_to_khz() (Rafael Wysocki)
> -- Replaced hidden initialization with a clearer form (Rafael Wysocki)
> -- Instead of picking up the first Max Speed value from DMI, we will
>now get the largest Max Speed; still an approximation, but slightly
>less subject to error (Rafael Wysocki)
> -- Kconfig for cppc_cpufreq now depends on DMI, instead of selecting
>it, in order to make sure DMI is set up properly (Rafael Wysocki)
> 
> Changes for v3:
> -- Added clarifying commentary re short-term vs long-term fix (Alexey
>Klimov)
> -- Added range checking code to ensure proper arithmetic occurs,
>especially no division by zero (Alexey Klimov)
> 
> Changes for v2:
> -- Corrected thinko: needed to have DEPENDS on DMI in Kconfig.arm,
>not SELECT DMI (found by build daemon)
> 
> Signed-off-by: Al Stone 
> Signed-off-by: Prashanth Prakash 

Applied.

Thanks,
Rafael



Re: [PATCH v5 0/3] arm64: hibernate: Resume when hibernate image created on non-boot CPU

2016-09-13 Thread Rafael J. Wysocki
On Wednesday, August 17, 2016 01:50:24 PM James Morse wrote:
> Hi all,
> 
> These patches allow arm64 to hibernate on any CPU saving the cpu-id in the
> arch header, then switch to it during resume using
> hibernate_resume_nonboot_cpu_disable().
> 
> I hoped to avoid patch 1 by duplicating the logic in the arch code, but
> Lorenzo pointed out using cpu_down() indicates that tasks are not frozen,
> whereas in reality they are. [0]
> Patch 1 lets us specify which cpu disable_nonboot_cpus() should leave
> standing.
> 
> (All three patches need to be merged together, this series doesn't conflict
>  with [1].)
> 
> Comments welcome,
> 
> This series is based on v4.8-rc2 and can be retrieved from:
> git://linux-arm.org/linux-jm.git hibernate/cpuN/v5
> 
> Changes since v4:
>  * Added freeze_secondary_cpus().
>  * Wired up hibernate_resume_nonboot_cpu_disable(), removing macros and
>kconfig symbols from previous approaches.
>  * Added check for sleep_cpu being uninitialised when we come to save the
>arch header.
> 
> Changes since v3:
>  * Split series, at the PM/Hibernate patch, merged arm64 patches to remove
>dependencies.
>  * Changed Kconfig symbol name.
>  * Fixed logic error '<= 0' when testing for an unrecognised CPU.
> 
> Changes since v2:
>  * Split wrong-CPU logic into an earlier patch that just returns an error.
>  * Changed core code patch to use macros instead of a weak function.
>CONFIG_ARCH_HIBERNATION_HEADER now implies an asm/suspend.h header.
>  * Wording in error messages 'hibernate' not 'suspend'.
> 
> Changes since v1:
>  * Fixed 'Brining' typo.
> 
> 
> 
> [v1] http://www.spinics.net/lists/arm-kernel/msg507805.html
> [v2] https://www.spinics.net/lists/arm-kernel/msg511654.html
> [v3] https://www.spinics.net/lists/arm-kernel/msg514644.html
> [v4] https://www.spinics.net/lists/arm-kernel/msg515978.html
> 
> [0] 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/441305.html
> [1] https://www.spinics.net/lists/arm-kernel/msg523933.html
> [2] hotplug cpu0, kexec, hibernate, resume
> -%<-
> root@ubuntu:~# echo disk > /sys/power/state
> [   76.768682] PM: Syncing filesystems ... done.
> [   76.774872] Freezing user space processes ... (elapsed 0.001 seconds) done.
> [   76.783253] Double checking all user space processes after OOM killer 
> disable
> ... (elapsed 0.000 seconds)
> [   76.794214] PM: Preallocating image memory... done (allocated 84746 pages)
> [   80.454878] PM: Allocated 338984 kbytes in 3.65 seconds (92.87 MB/s)
> [   80.461269] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
> done.
> [   80.491476] PM: freeze of devices complete after 21.037 msecs
> [   80.498053] PM: late freeze of devices complete after 0.789 msecs
> [   80.505563] PM: noirq freeze of devices complete after 1.387 msecs
> [   80.511777] Disabling non-boot CPUs ...
> [   80.540044] CPU1: shutdown
> [   80.542755] psci: CPU1 killed.
> [   80.611931] CPU2: shutdown
> [   80.614646] psci: CPU2 killed.
> [   80.687816] IRQ11 no longer affine to CPU3
> [   80.687831] IRQ20 no longer affine to CPU3
> [   80.687872] CPU3: shutdown
> [   80.698806] psci: CPU3 killed.
> [   80.725600] PM: Creating hibernation image:
> [   80.725600] PM: Need to copy 84054 pages
> [   80.725600] PM: Hibernation image created (84054 pages copied)
> [   80.725609] Enabling non-boot CPUs ...
> [   80.758320] Detected VIPT I-cache on CPU1
> [   80.758381] CPU1: Booted secondary processor [410fd033]
> [   80.758946] CPU1 is up
> [   80.810889] Detected VIPT I-cache on CPU2
> [   80.810932] CPU2: Booted secondary processor [410fd033]
> [   80.811598] CPU2 is up
> [   80.863596] Detected VIPT I-cache on CPU3
> [   80.863640] CPU3: Booted secondary processor [410fd033]
> [   80.864256] CPU3 is up
> [   80.876712] PM: noirq thaw of devices complete after 0.802 msecs
> [   80.883475] PM: early thaw of devices complete after 0.699 msecs
> [   80.947177] PM: thaw of devices complete after 57.665 msecs
> [   80.953222] hibernate: Hibernating on CPU 0 [mpidr:0x101]
> [   80.961099] PM: Using 3 thread(s) for compression.
> [   80.961099] PM: Compressing and saving image data (84219 pages)...
> [   80.972154] PM: Image saving progress:   0%
> [   81.270381] PM: Image saving progress:  10%
> [   81.498242] PM: Image saving progress:  20%
> [   81.789014] PM: Image saving progress:  30%
> [   84.844984] PM: Image saving progress:  40%
> [   87.657013] PM: Image saving progress:  50%
> [   88.933987] PM: Image saving progress:  60%
> [   90.597472] PM: Image saving progress:  70%
> [   92.362916] PM: Image saving progress:  80%
> [   93.622648] PM: Image saving progress:  90%
> [   95.468855] PM: Image saving progress: 100%
> [   99.073785] PM: Image saving done.
> [   99.077240] PM: Wrote 336876 kbytes in 18.10 seconds (18.61 MB/s)
> [   99.092099] PM: S|
> [   99.370393] kvm: exiting hardware virtualization
> [   99.535936] reboot: Restarting system
> 
> [ ... ]

Re: [PATCH v3 07/15] lockdep: Implement crossrelease feature

2016-09-13 Thread Byungchul Park
On Wed, Sep 14, 2016 at 6:42 AM, Peter Zijlstra  wrote:
> On Tue, Sep 13, 2016 at 09:38:29PM +0200, Peter Zijlstra wrote:
>
>> > > I _think_ you propose to keep track of all prior held locks and then use
>> > > the union of the held list on the block-chain with the prior held list
>> > > from the complete context.
>> >
>> > Almost right. Only thing we need to do to consider the union is to
>> > connect two chains of two contexts by adding one dependency 'b -> a'.
>>
>> Sure, but how do you arrive at which connection to make. The document is
>> entirely silent on this crucial point.
>>
>> The union between the held-locks of the blocked and prev-held-locks of
>> the release should give a fair indication I think, but then, I've not
>> thought too hard on this yet.
>
> s/union/intersection/
>
> those that are in both sets.

Precisely speaking, I introduces separate chains.

For example,

1. Held-locks of the blocked,
A -> B -> C (which original lockdep builds)

2. Prev-held-locks of the release
G -> H -> I (which original lockdep builds, too)

3. Cross chain (which I introduced newly)
C -> G

Then the 'A -> B -> C -> G -> H -> I' can be traversed
when bfs is performed.

-- 
Thanks,
Byungchul


Re: [PATCH v3] PM / sleep: enable suspend-to-idle even without registered suspend_ops

2016-09-13 Thread Rafael J. Wysocki
On Friday, August 19, 2016 02:41:00 PM Sudeep Holla wrote:
> Suspend-to-idle (aka the "freeze" sleep state) is a system sleep state
> in which all of the processors enter deepest possible idle state and
> wait for interrupts right after suspending all the devices.
> 
> There is no hard requirement for a platform to support and register
> platform specific suspend_ops to enter suspend-to-idle/freeze state.
> Only deeper system sleep states like PM_SUSPEND_STANDBY and
> PM_SUSPEND_MEM rely on such low level support/implementation.
> 
> suspend-to-idle can be entered as along as all the devices can be
> suspended. This patch enables the support for suspend-to-idle even on
> systems that don't have any low level support for deeper system sleep
> states and/or don't register any platform specific suspend_ops.
> 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Sudeep Holla 

Applied.

Thanks,
Rafael



Re: [PATCH][v2] PM / sleep: Increase default DPM watchdog timeout to 120

2016-09-13 Thread Rafael J. Wysocki
On Friday, August 19, 2016 09:19:55 AM Pavel Machek wrote:
> On Fri 2016-08-19 12:37:23, Chen Yu wrote:
> > Recently we have a new report that, the harddisk can not
> > resume on time due to firmware issues, and got a kernel
> > panic because of DPM watchdog timeout. So adjust the
> > default timeout from 60 to 120 to survive on this platform,
> > and make DPM_WATCHDOG depending on EXPERT.
> > 
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=117971
> 
> Acked-by: Pavel Machek 

Patch applied.

Thanks,
Rafael



Re: [PATCH v3 4/7] palmetto: Request relevant mux functions in devicetree

2016-09-13 Thread Joel Stanley
On Wed, Sep 14, 2016 at 6:28 AM, Benjamin Herrenschmidt
 wrote:
> On Tue, 2016-09-13 at 22:11 +0930, Joel Stanley wrote:
>> It's not clear that all systems use these pins in that way. I will
>> not
>> include this one for now.
>
> Well, it has VGA so the VGA hsync, vsync and DDC should be there at
> least...

True. When we enable VGA in our tree these pins will be requested as
part of the VGA driver's device node, so they don't need to be hogged
by the pinctrl node like this.

The ones I'm not clear on are bmc_flack and bmc_int. Andrew, do you
have a recommendation here?

Cheers,

Joel


Re: [PATCH 0/2] minor x86 PM source file cleanup

2016-09-13 Thread Rafael J. Wysocki
On Saturday, August 20, 2016 06:15:10 PM Al Stone wrote:
> On 08/20/2016 04:55 AM, Pavel Machek wrote:
> > On Fri 2016-08-19 17:24:00, Al Stone wrote:
> >> Really minor patches: one to cleanup whitespace, the second just makes
> >> the code a wee bit more maintainable by correcting some variable names
> >> without changing functionality.
> > 
> > Acked-by: Pavel Machek 
> > 
> > (for both)
> > 
> >> Al Stone (2):
> >>   x86: ACPI: remove extraneous white space after semicolon
> >>   x86: ACPI: make variable names clearer in
> >> acpi_parse_madt_lapic_entries()
> >>
> >>  arch/x86/kernel/acpi/boot.c | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> > 
> 
> Thanks, Pavel.

Both applied.

Thanks,
Rafael



Re: [PATCH 1/3] cpufreq: dt: Remove unused code

2016-09-13 Thread Rafael J. Wysocki
On Friday, September 09, 2016 04:48:06 PM Viresh Kumar wrote:
> This is leftover from an earlier patch which removed the usage of
> platform data but forgot to remove this line. Remove it now.
> 
> Signed-off-by: Viresh Kumar 

All [1-3/3] applied.

Thanks,
Rafael



Re: [PATCH V2] cpufreq: create link to policy only for registered CPUs

2016-09-13 Thread Rafael J. Wysocki
On Monday, September 12, 2016 12:07:05 PM Viresh Kumar wrote:
> If a cpufreq driver is registered very early in the boot stage (e.g.
> registered from postcore_initcall()), then cpufreq core may generate
> kernel warnings for it.
> 
> In this case, the CPUs are brought online, then the cpufreq driver is
> registered, and then the CPU topology devices are registered. However,
> by the time cpufreq_add_dev() gets called, the cpu device isn't stored
> in the per-cpu variable (cpu_sys_devices,) which is read by
> get_cpu_device().
> 
> So the cpufreq core fails to get device for the CPU, for which
> cpufreq_add_dev() was called in the first place and we will hit a
> WARN_ON(!cpu_dev).
> 
> Even if we reuse the 'dev' parameter passed to cpufreq_add_dev() to
> avoid that warning, there might be other CPUs online that share the
> policy with the cpu for which cpufreq_add_dev() is called. Eventually
> get_cpu_device() will return NULL for them as well, and we will hit the
> same WARN_ON() again.
> 
> In order to fix these issues, change cpufreq core to create links to the
> policy for a cpu only when cpufreq_add_dev() is called for that CPU.
> 
> Reuse the 'real_cpus' mask to track that as well.
> 
> Note that cpufreq_remove_dev() already handles removal of the links for
> individual CPUs and cpufreq_add_dev() has aligned with that now.
> 
> Reported-by: Russell King 
> Tested-by: Russell King 
> Signed-off-by: Viresh Kumar 

Applied.

Thanks,
Rafael



Re: [PATCH] PM / Hibernate: allow hibernation with PAGE_POISONING_ZERO

2016-09-13 Thread Rafael J. Wysocki
On Friday, September 09, 2016 10:43:32 AM Anisse Astier wrote:
> PAGE_POISONING_ZERO disables zeroing new pages on alloc, they are
> poisoned (zeroed) as they become available.
> In the hibernate use case, free pages will appear in the system without
> being cleared, left there by the loading kernel.
> 
> This patch will make sure free pages are cleared on resume when
> PAGE_POISONING_ZERO is enabled. We free the pages just after resume
> because we can't do it later: going through any device resume code might
> allocate some memory and invalidate the free pages bitmap.
> 
> Thus we don't need to disable hibernation when PAGE_POISONING_ZERO is
> enabled.
> 
> Signed-off-by: Anisse Astier 
> Cc: Kirill A. Shutemov 
> Cc: Laura Abbott 
> Cc: Mel Gorman 
> Cc: Rafael J. Wysocki 

Applied (with the tags from Pavel and Kees).

Thanks,
Rafael



Re: [PATCH 19/26] intel_pstate: constify local structures

2016-09-13 Thread Rafael J. Wysocki
On Monday, September 12, 2016 12:12:30 PM Viresh Kumar wrote:
> On 11-09-16, 15:06, Julia Lawall wrote:
> > For structure types defined in the same file or local header files, find
> > top-level static structure declarations that have the following
> > properties:
> > 1. Never reassigned.
> > 2. Address never taken
> > 3. Not passed to a top-level macro call
> > 4. No pointer or array-typed field passed to a function or stored in a
> > variable.
> > Declare structures having all of these properties as const.
> > 
> > Done using Coccinelle.
> > Based on a suggestion by Joe Perches .
> > 
> > Signed-off-by: Julia Lawall 
> > 
> > ---
> > The semantic patch seems too long for a commit log, but is in the cover
> > letter.
> > 
> >  drivers/cpufreq/intel_pstate.c |8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> > index bdbe936..4b5f8c3 100644
> > --- a/drivers/cpufreq/intel_pstate.c
> > +++ b/drivers/cpufreq/intel_pstate.c
> > @@ -1029,7 +1029,7 @@ static struct cpu_defaults core_params = {
> > },
> >  };
> >  
> > -static struct cpu_defaults silvermont_params = {
> > +static const struct cpu_defaults silvermont_params = {
> > .pid_policy = {
> > .sample_rate_ms = 10,
> > .deadband = 0,
> > @@ -1050,7 +1050,7 @@ static struct cpu_defaults silvermont_params = {
> > },
> >  };
> >  
> > -static struct cpu_defaults airmont_params = {
> > +static const struct cpu_defaults airmont_params = {
> > .pid_policy = {
> > .sample_rate_ms = 10,
> > .deadband = 0,
> > @@ -1071,7 +1071,7 @@ static struct cpu_defaults airmont_params = {
> > },
> >  };
> >  
> > -static struct cpu_defaults knl_params = {
> > +static const struct cpu_defaults knl_params = {
> > .pid_policy = {
> > .sample_rate_ms = 10,
> > .deadband = 0,
> > @@ -1091,7 +1091,7 @@ static struct cpu_defaults knl_params = {
> > },
> >  };
> >  
> > -static struct cpu_defaults bxt_params = {
> > +static const struct cpu_defaults bxt_params = {
> > .pid_policy = {
> > .sample_rate_ms = 10,
> > .deadband = 0,
> 
> Acked-by: Viresh Kumar 

Applied.

Thanks,
Rafael



Re: [PATCH] rk808: fix RK818_IRQ_DISCHG_ILIM initializer

2016-09-13 Thread Andy Yan

Hi:


On 2016年09月13日 18:48, Lee Jones wrote:

On Tue, 06 Sep 2016, Arnd Bergmann wrote:


When building with -Woverride-init, we get a warning about an incorrect
initializer:

drivers/mfd/rk808.c:244:8: error: initialized field overwritten 
[-Werror=override-init]
   [RK818_IRQ_DISCHG_ILIM] = {

This is clearly a mistake, as both RK818_IRQ_DISCHG_ILIM and RK818_IRQ_USB_OV
are defined as '7', but they refer to different register bits. Changing
RK818_IRQ_DISCHG_ILIM to 15 is consistent with how all other 14 interrupts are
handled here, so I'm assuming this is what it should have been.

Signed-off-by: Arnd Bergmann 
Fixes: 2eedcbfc0612 ("mfd: rk808: Add RK818 support")
---
  include/linux/mfd/rk808.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

I would like someone who is in possession of a datasheet to confirm
this.


According to the datasheet, the RK818_IRQ_USB_OV is in bit 7 of 
INT_STS_REG1(0x4c) and RK818_IRQ_DISCHG_ILIM is in bit 7 of 
INT_STS_REG2(0x4e), so  Arnd's change is right.



Thanks.

diff --git a/include/linux/mfd/rk808.h b/include/linux/mfd/rk808.h
index fc5db6fcb57d..6d435a3c06bc 100644
--- a/include/linux/mfd/rk808.h
+++ b/include/linux/mfd/rk808.h
@@ -244,7 +244,7 @@ enum rk818_reg {
  #define RK818_IRQ_CHG_TS1 12
  #define RK818_IRQ_TS2 13
  #define RK818_IRQ_CHG_CVTLIM  14
-#define RK818_IRQ_DISCHG_ILIM  7
+#define RK818_IRQ_DISCHG_ILIM  15
  
  #define RK818_IRQ_VOUT_LO_MSK		BIT(0)

  #define RK818_IRQ_VB_LO_MSK   BIT(1)





Re: [PATCH 24/26] ACPI / APD: constify local structures

2016-09-13 Thread Rafael J. Wysocki
On Sunday, September 11, 2016 03:06:06 PM Julia Lawall wrote:
> For structure types defined in the same file or local header files, find
> top-level static structure declarations that have the following
> properties:
> 1. Never reassigned.
> 2. Address never taken
> 3. Not passed to a top-level macro call
> 4. No pointer or array-typed field passed to a function or stored in a
> variable.
> Declare structures having all of these properties as const.
> 
> Done using Coccinelle.
> Based on a suggestion by Joe Perches .
> 
> Signed-off-by: Julia Lawall 

Applied.

Thanks,
Rafael



STRICTLY CONFIDENTIAL

2016-09-13 Thread Acct. Dept.
I have important transaction for you as next of kin to claim US$18.37m  Mail me 
on my private email:   chimwia...@gmail.com
 so i can send you more details

Thanks

Mr.Chim Wai Kim










===

DISCLAIMER: This email and any files it contains are confidential and intended 
for the use of the recipient(s) only. If you are not the intended recipient you 
should notify the sender immediately and destroy the material from your system. 





[RFC/PATCH] usb: chipidea: Emulate OTGSC interrupt enable path

2016-09-13 Thread Stephen Boyd
In the case of an extcon-usb-gpio device being used with the
chipidea driver we'll sometimes miss the BSVIS event in the OTGSC
register. Consider the case where we don't have a cable attached
and the id pin is indicating "host" mode. When we plug in the usb
cable for "device" mode a gpio goes high and indicates that we
should do the role switch and that vbus is high. When we're in
"host" mode the OTGSC register doesn't have BSVIE set.

The following scenario can happen:

CPU0


 ci_cable_notifier()
  update id cable state
  ci_irq()
   if (ci->is_otg && (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) { // true
ci->id_event = true;
ci_otg_queue_work()
 schedule()

 // same task as before
 ci_cable_notifier()
  update vbus cable state
   ci_irq()
if (ci->is_otg && (otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) // false
   return IRQ_NONE

ci_otg_work() // switch task to the workqueue now
 if (ci->id_event)
  ci_handle_id_switch()
   ci_role_stop()
host_stop()
   hw_wait_vbus_lower_bsv(ci); // this times out because vbus is already set
   ci_role_start()
udc_id_switch_for_device()
 hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE, OTGSC_BSVIS | OTGSC_BSVIE);

At this point, we don't replay the vbus connect event because the
vbus event has already happened. This causes things like gadget
instances to never see vbus appear, and thus the gadget is never
started. Furthermore, we see timeout messages like:

timeout waiting for 800 in OTGSC

Let's workaround this by skiping the wait for BSV when we're
using an extcon for the vbus notification and let's properly
emulate the BSVIS event that would happen when we enable the
vbus interrupt while enabling "device" mode.

Cc: Greg Kroah-Hartman 
Signed-off-by: Stephen Boyd 
---

This is on top of my patch series that modifies how we handle the extcon
events here. The extcon handling looks racy in this driver even after
this patch. I think we may need to add a spinlock around the cable
state changes and the otgsc register read/write functions. The driver
doesn't seem to expect that the extcon notifiers could run in parallel
with the OTG state machine, and emulating the interrupts is "weird"
in the sense that most of the irq handler in core.c assumes that there's
only one interrupt and so we couldn't possibly be in the irq handler 
at the same time on different CPUs (which it can!).

Also, can we just remove the BSV waiting part? From what I can tell, that
is racy if someone can get the workqueue to be delayed significantly enough
to have vbus go high (again) during the role switch. I understand that we're
doing it to prevent a vbus event from happening when we switch to the device
role even though there isn't a cable attached. It just doesn't seem like it's
safe to assume a high-low-high transition won't happen and be reflected in
the status bits. It's really easy to trigger this with an extcon-usb-gpio device
like can be found on 96boards platforms like db410c.

 drivers/usb/chipidea/ci.h   |  2 ++
 drivers/usb/chipidea/core.c | 23 +--
 drivers/usb/chipidea/otg.c  | 31 ---
 3 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 59e22389c10b..e099b8bc79e2 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -437,6 +437,8 @@ static inline void ci_ulpi_exit(struct ci_hdrc *ci) { }
 static inline int ci_ulpi_resume(struct ci_hdrc *ci) { return 0; }
 #endif
 
+irqreturn_t __ci_irq(int irq, struct ci_hdrc *ci);
+
 u32 hw_read_intr_enable(struct ci_hdrc *ci);
 
 u32 hw_read_intr_status(struct ci_hdrc *ci);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index ba3a43bbe0ea..fbef1c961572 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -528,9 +528,8 @@ int hw_device_reset(struct ci_hdrc *ci)
return 0;
 }
 
-static irqreturn_t ci_irq(int irq, void *data)
+irqreturn_t __ci_irq(int irq, struct ci_hdrc *ci)
 {
-   struct ci_hdrc *ci = data;
irqreturn_t ret = IRQ_NONE;
u32 otgsc = 0;
 
@@ -574,9 +573,20 @@ static irqreturn_t ci_irq(int irq, void *data)
return IRQ_HANDLED;
}
 
-   /* Handle device/host interrupt */
-   if (ci->role != CI_ROLE_END)
-   ret = ci_role(ci)->irq(ci);
+   return ret;
+}
+
+static irqreturn_t ci_irq(int irq, void *data)
+{
+   irqreturn_t ret;
+   struct ci_hdrc *ci = data;
+
+   ret = __ci_irq(irq, ci);
+   if (ret == IRQ_NONE) {
+   /* Handle device/host interrupt */
+   if (ci->role != CI_ROLE_END)
+   ret = ci_role(ci)->irq(ci);
+   }
 
return ret;
 }
@@ -590,7 +600,8 @@ static int ci_cable_notifier(struct notifier_block *nb, 
unsigned long event,
cbl->connected = event;
cbl->changed = true;
 
-   

Re: [RFC/RFT][PATCH v2 5/7] PM / runtime: Flag to indicate PM sleep transitions in progress

2016-09-13 Thread Rafael J. Wysocki
On Tuesday, September 13, 2016 09:21:23 AM Marek Szyprowski wrote:
> Hi Rafael,
> 
> 
> On 2016-09-12 23:25, Rafael J. Wysocki wrote:
> > On Monday, September 12, 2016 04:07:27 PM Lukas Wunner wrote:
> >> On Thu, Sep 08, 2016 at 11:29:48PM +0200, Rafael J. Wysocki wrote:
> >>> Introduce a new flag in struct dev_pm_info, pm_sleep_in_progress, to
> >>> indicate that runtime PM has been disabled because of a PM sleep
> >>> transition in progress.
> >> [...]
> >>> That will allow helpers like pm_runtime_get_sync() to be called
> >>> during system sleep transitions without worrying about possible
> >>> error codes they may return because runtime PM is disabled at
> >>> that point.
> >> I have a suspicion that this patch papers over the direct_complete bug
> >> I reported Sep 10 and that the patch is unnecessary once that bug is
> >> fixed.
> > It doesn't paper over anything, but it may not be necessary anyway.
> >
> >> AFAICS, runtime PM is only disabled in two places during the system
> >> sleep process: In __device_suspend() for devices using direct_complete,
> >> and __device_suspend_late() for all devices.
> >>
> >> In both of these phases (dpm_suspend() and dpm_suspend_late()), the
> >> device tree is walked bottom-up. Since we've reordered consumers to
> >> the back of dpm_list, they will be treated *before* their suppliers.
> >> Thus, runtime PM is disabled on the consumers first, and only later
> >> on the suppliers.
> >>
> >> Then how can it be that runtime PM is already disabled on the supplier?
> > Actually, I think that this was a consequence of a bug in 
> > device_reorder_to_tail()
> > that was present in the previous iteration of the patchset (it walked 
> > suppliers
> > instead of consumers).
> >
> >> The only scenario I can imagine is that the supplier chose to exercise
> >> direct_complete, thus was pm_runtime_disabled() in the __device_suspend()
> >> phase, and the consumer did *not* choose to exercise direct_complete and
> >> later tried to runtime resume its suppliers and itself.
> >>
> >> I assume this patch is a replacement for Marek's [v2 08/10].
> >> @Marek, does this scenario match with what you witnessed?
> > It is not strictly a replacement for it.  The Marek's patch was the
> > reason to post it, but I started to think about this earlier.
> >
> > Some people have complained to me about having to deal with error codes
> > returned by the runtime PM framework during system suspend, so I thought
> > it might be useful to deal with that too.
> >
> > That said it probably is not necessary right now.
> 
> I've tested this patchset without this patch and system sleep with 
> device link
> enabled worked fine. However this might be also a consequence of 
> enabling runtime
> pm during system sleep since v4.8-rc1.
> 
> It looks that for now this patch can be skipped until a real use case for it
> appears.

OK, thanks!



[Update][PATCH 3/3] cpufreq: intel_pstate: Use IOWAIT flag in Atom algorithm

2016-09-13 Thread Rafael J. Wysocki
From: Rafael J. Wysocki 

Modify the P-state selection algorithm for Atom processors to use
the new SCHED_CPUFREQ_IOWAIT flag instead of the questionable
get_cpu_iowait_time_us() function.

Signed-off-by: Rafael J. Wysocki 
---

The PID uses percents not fractions, so pass sample->busy_scaled instead of
busy_frac to it in get_target_pstate_use_cpu_load().

---
 drivers/cpufreq/intel_pstate.c |   58 +
 1 file changed, 31 insertions(+), 27 deletions(-)

Index: linux-pm/drivers/cpufreq/intel_pstate.c
===
--- linux-pm.orig/drivers/cpufreq/intel_pstate.c
+++ linux-pm/drivers/cpufreq/intel_pstate.c
@@ -181,6 +181,8 @@ struct _pid {
  * @cpu:   CPU number for this instance data
  * @update_util:   CPUFreq utility callback information
  * @update_util_set:   CPUFreq utility callback is set
+ * @iowait_boost:  iowait-related boost fraction
+ * @last_update:   Time of the last update.
  * @pstate:Stores P state limits for this CPU
  * @vid:   Stores VID limits for this CPU
  * @pid:   Stores PID parameters for this CPU
@@ -206,6 +208,7 @@ struct cpudata {
struct vid_data vid;
struct _pid pid;
 
+   u64 last_update;
u64 last_sample_time;
u64 prev_aperf;
u64 prev_mperf;
@@ -216,6 +219,7 @@ struct cpudata {
struct acpi_processor_performance acpi_perf_data;
bool valid_pss_table;
 #endif
+   unsigned int iowait_boost;
 };
 
 static struct cpudata **all_cpu_data;
@@ -229,6 +233,7 @@ static struct cpudata **all_cpu_data;
  * @p_gain_pct:PID proportional gain
  * @i_gain_pct:PID integral gain
  * @d_gain_pct:PID derivative gain
+ * @boost_iowait:  Whether or not to use iowait boosting.
  *
  * Stores per CPU model static PID configuration data.
  */
@@ -240,6 +245,7 @@ struct pstate_adjust_policy {
int p_gain_pct;
int d_gain_pct;
int i_gain_pct;
+   bool boost_iowait;
 };
 
 /**
@@ -1037,6 +1043,7 @@ static struct cpu_defaults silvermont_pa
.p_gain_pct = 14,
.d_gain_pct = 0,
.i_gain_pct = 4,
+   .boost_iowait = true,
},
.funcs = {
.get_max = atom_get_max_pstate,
@@ -1058,6 +1065,7 @@ static struct cpu_defaults airmont_param
.p_gain_pct = 14,
.d_gain_pct = 0,
.i_gain_pct = 4,
+   .boost_iowait = true,
},
.funcs = {
.get_max = atom_get_max_pstate,
@@ -1099,6 +1107,7 @@ static struct cpu_defaults bxt_params =
.p_gain_pct = 14,
.d_gain_pct = 0,
.i_gain_pct = 4,
+   .boost_iowait = true,
},
.funcs = {
.get_max = core_get_max_pstate,
@@ -1222,36 +1231,18 @@ static inline int32_t get_avg_pstate(str
 static inline int32_t get_target_pstate_use_cpu_load(struct cpudata *cpu)
 {
struct sample *sample = >sample;
-   u64 cummulative_iowait, delta_iowait_us;
-   u64 delta_iowait_mperf;
-   u64 mperf, now;
-   int32_t cpu_load;
+   int32_t busy_frac, boost;
 
-   cummulative_iowait = get_cpu_iowait_time_us(cpu->cpu, );
+   busy_frac = div_fp(sample->mperf, sample->tsc);
 
-   /*
-* Convert iowait time into number of IO cycles spent at max_freq.
-* IO is considered as busy only for the cpu_load algorithm. For
-* performance this is not needed since we always try to reach the
-* maximum P-State, so we are already boosting the IOs.
-*/
-   delta_iowait_us = cummulative_iowait - cpu->prev_cummulative_iowait;
-   delta_iowait_mperf = div64_u64(delta_iowait_us * cpu->pstate.scaling *
-   cpu->pstate.max_pstate, MSEC_PER_SEC);
+   boost = cpu->iowait_boost;
+   cpu->iowait_boost >>= 1;
 
-   mperf = cpu->sample.mperf + delta_iowait_mperf;
-   cpu->prev_cummulative_iowait = cummulative_iowait;
-
-   /*
-* The load can be estimated as the ratio of the mperf counter
-* running at a constant frequency during active periods
-* (C0) and the time stamp counter running at the same frequency
-* also during C-states.
-*/
-   cpu_load = div64_u64(int_tofp(100) * mperf, sample->tsc);
-   cpu->sample.busy_scaled = cpu_load;
+   if (busy_frac < boost)
+   busy_frac = boost;
 
-   return get_avg_pstate(cpu) - pid_calc(>pid, cpu_load);
+   sample->busy_scaled = busy_frac * 100;
+   return get_avg_pstate(cpu) - pid_calc(>pid, sample->busy_scaled);
 }
 
 static inline int32_t get_target_pstate_use_performance(struct cpudata *cpu)
@@ -1332,8 +1323,21 @@ static void intel_pstate_update_util(str
   

  1   2   3   4   5   6   7   8   9   >