Re: [PATCH] sm750fb: coding style fixes lines over 80 chars

[Vinay Simha]

#if 0, but it's also obviously incorrect

It supposed to be some tag #ifdef CONFIG_** .
Could anybody in the loop can reply?

i was just checking on style checks.
Will skip this file , will take up later

On Thu, Jul 16, 2015 at 9:27 AM, Joe Perches  wrote:
> On Thu, 2015-07-16 at 00:16 +0530, Vinay Simha BN wrote:
>> scripts/checkpatch.pl kernel coding style fixes of WARNING
>
> Please don't be a checkpatch robot.
>
> Use tools to prompt your brain, but don't ever turn
> your brain off.
>
>> diff --git a/drivers/staging/sm750fb/ddk750_help.h 
>> b/drivers/staging/sm750fb/ddk750_help.h
>
>
>> +/* if 718 big endian turned on,be aware that don't use this driver for 
>> general
>> +  use,only for ppc big-endian */
>> +#warning "big endian on target cpu and enable nature big endian support of 
>> 718
>> + capability !"
>
> Yes, this if #if 0, but it's also obviously incorrect
>
> I didn't look at the rest.
>
>



-- 
Regards,

Vinay Simha.B.N.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] sm750fb: coding style fixes lines over 80 chars

[Vinay Simha BN]

scripts/checkpatch.pl kernel coding style fixes of WARNING

WARNING: line over 80 characters

Signed-off-by: Vinay Simha BN 
---
 drivers/staging/sm750fb/ddk750_display.h | 10 +-
 drivers/staging/sm750fb/ddk750_hwi2c.h   |  6 --
 drivers/staging/sm750fb/ddk750_power.h   |  6 +++---
 drivers/staging/sm750fb/ddk750_sii164.h  | 12 +++-
 drivers/staging/sm750fb/sm750.h  | 13 -
 drivers/staging/sm750fb/sm750_accel.h| 19 ---
 drivers/staging/sm750fb/sm750_help.h | 21 ++---
 drivers/staging/sm750fb/sm750_hw.h   | 21 +
 8 files changed, 66 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_display.h 
b/drivers/staging/sm750fb/ddk750_display.h
index abccf84..9afa366 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -110,19 +110,19 @@ typedef enum _disp_output_t {
 
/* LCD1 show secondary and DSUB show primary */
LCD1_DSUB_DUAL_SWAP = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|
-   
CRT_2_PRI|PRI_TP_ON|DAC_ON,
+   CRT_2_PRI|PRI_TP_ON|DAC_ON,
 
LCD1_LCD2_PRI = PNL_2_PRI|PRI_TP_ON|PNL_SEQ_ON|
-   
CRT_2_PRI|SEC_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
+   CRT_2_PRI|SEC_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
 
LCD1_LCD2_SEC = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|
-   
CRT_2_SEC|PRI_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
+   CRT_2_SEC|PRI_TP_OFF|DPMS_OFF|DUAL_TFT_ON,
 
LCD1_LCD2_DSUB_PRI = PNL_2_PRI|PRI_TP_ON|PNL_SEQ_ON|DAC_ON|
-   
CRT_2_PRI|SEC_TP_OFF|DPMS_ON|DUAL_TFT_ON,
+   CRT_2_PRI|SEC_TP_OFF|DPMS_ON|DUAL_TFT_ON,
 
LCD1_LCD2_DSUB_SEC = PNL_2_SEC|SEC_TP_ON|PNL_SEQ_ON|DAC_ON|
-   
CRT_2_SEC|PRI_TP_OFF|DPMS_ON|DUAL_TFT_ON,
+   CRT_2_SEC|PRI_TP_OFF|DPMS_ON|DUAL_TFT_ON,
 
 
 }
diff --git a/drivers/staging/sm750fb/ddk750_hwi2c.h 
b/drivers/staging/sm750fb/ddk750_hwi2c.h
index 0b830ba6..3d4e48b 100644
--- a/drivers/staging/sm750fb/ddk750_hwi2c.h
+++ b/drivers/staging/sm750fb/ddk750_hwi2c.h
@@ -5,6 +5,8 @@
 int hwI2CInit(unsigned char busSpeedMode);
 void hwI2CClose(void);
 
-unsigned char hwI2CReadReg(unsigned char deviceAddress, unsigned char 
registerIndex);
-int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex, 
unsigned char data);
+unsigned char hwI2CReadReg(unsigned char deviceAddress,
+   unsigned char registerIndex);
+int hwI2CWriteReg(unsigned char deviceAddress, unsigned char registerIndex,
+   unsigned char data);
 #endif
diff --git a/drivers/staging/sm750fb/ddk750_power.h 
b/drivers/staging/sm750fb/ddk750_power.h
index b7cf6b2..abad4fe 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -12,9 +12,9 @@ DPMS_t;
 #define setDAC(off) \
{   \
POKE32(MISC_CTRL, FIELD_VALUE(PEEK32(MISC_CTRL), \
-   
MISC_CTRL,  \
-   
DAC_POWER,  \
-   off));  
\
+   MISC_CTRL,  \
+   DAC_POWER,  \
+   off));  \
}
 
 void ddk750_setDPMS(DPMS_t);
diff --git a/drivers/staging/sm750fb/ddk750_sii164.h 
b/drivers/staging/sm750fb/ddk750_sii164.h
index f2610c9..a5246bd 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.h
+++ b/drivers/staging/sm750fb/ddk750_sii164.h
@@ -5,10 +5,11 @@
 
 /* Hot Plug detection mode structure */
 typedef enum _sii164_hot_plug_mode_t {
-   SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit 
(always high). */
-   SII164_HOTPLUG_USE_MDI, /* Use Monitor Detect Interrupt 
bit. */
-   SII164_HOTPLUG_USE_RSEN,/* Use Receiver Sense detect bit. */
-   SII164_HOTPLUG_USE_HTPLG/* Use Hot Plug detect bit. */
+   SII164_HOTPLUG_DISABLE = 0, /* Disable Hot Plug output bit
+   (always high) */
+   SII164_HOTPLUG_USE_MDI, /* Use Monitor Detect Interrupt bit. */
+   SII164_HOTPLUG_USE_RSEN,/* Use Receiver Sense detect bit. */
+   SII164_HOTPLUG_USE_HTPLG/* Use Hot Plug detect bit. */
 } sii164_hot_plug_mode_t;
 
 
@@ -39,7 +40,8 @@ unsigned char sii164IsConnected(void);
 unsigned char sii164CheckInterrupt(void);
 void sii164ClearInterrupt(void);
 #endif
-/* below register definination is used for Silicon Image SiI164 DVI controller 
chip */
+/* below register definination is used for Silicon Image
+   SiI164 DVI controller chip */
 /*
  * Vendor ID registers
 

Re: [PATCH] sm750fb: coding style fixes lines over 80 chars

[Joe Perches]

On Fri, 2015-07-17 at 12:58 +0530, Vinay Simha BN wrote:
> scripts/checkpatch.pl kernel coding style fixes of WARNING

Please use checkpatch's --strict option until you know
kernel style much better.

> diff --git a/drivers/staging/sm750fb/sm750_accel.h 
> b/drivers/staging/sm750fb/sm750_accel.h
[]
> @@ -259,17 +259,22 @@ unsigned int height, /* width and height of rectangle 
> in pixel value */
>  unsigned int rop2);
>  
>  int hw_imageblit(struct lynx_accel *accel,
> -  const char *pSrcbuf, /* pointer to start of source buffer in 
> system memory */
> -  u32 srcDelta,  /* Pitch value (in bytes) of the source 
> buffer, +ive means top down and -ive mean button up */
> -  u32 startBit, /* Mono data can start at any bit in a byte, 
> this value should be 0 to 7 */
> -  u32 dBase,/* Address of destination: offset in frame 
> buffer */
> +  const char *pSrcbuf, /* pointer to start of source
> + buffer in system memory */

If you change these lines, please use normal kernel comment style.
/*
 * comment block
 */

> diff --git a/drivers/staging/sm750fb/sm750_help.h 
> b/drivers/staging/sm750fb/sm750_help.h
[]
> @@ -49,17 +49,23 @@
>  /* Field Macros */
>  #define FIELD_START(field)  (0 ? field)
>  #define FIELD_END(field)(1 ? field)

Odd statements.

> -#define FIELD_SIZE(field)   (1 + FIELD_END(field) - 
> FIELD_START(field))
> -#define FIELD_MASK(field)   (((1 << (FIELD_SIZE(field)-1)) | ((1 
> << (FIELD_SIZE(field)-1)) - 1)) << FIELD_START(field))
> -#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> 
> FIELD_START(field))
> -#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & 
> FIELD_MASK(field))
> +#define FIELD_SIZE(field)   (1 + FIELD_END(field) - \
> + FIELD_START(field))
> +#define FIELD_MASK(field)   (((1 << (FIELD_SIZE(field)-1)) \
> + | ((1 << (FIELD_SIZE(field)-1)) - 1)) \
> + << FIELD_START(field))
> +#define FIELD_NORMALIZE(reg, field) (((reg) & FIELD_MASK(field)) >> \
> + FIELD_START(field))
> +#define FIELD_DENORMALIZE(field, value) (((value) << FIELD_START(field)) & \
> +  FIELD_MASK(field))
>  
>  #define FIELD_INIT(reg, field, value)   FIELD_DENORMALIZE(reg ## _ ## field, 
> \
> -   reg ## _ ## field ## 
> _ ## value)
> +   reg ## _ ## field ## _ ## value)
>  #define FIELD_INIT_VAL(reg, field, value) \
>   (FIELD_DENORMALIZE(reg ## _ ## field, value))
>  #define FIELD_VAL_SET(x, r, f, v)   x = x & ~FIELD_MASK(r ## _ ## f) \
> - | FIELD_DENORMALIZE(r ## _ ## f, r ## _ 
> ## f ## _ ## v)
> + | FIELD_DENORMALIZE(r ## _ ## f, \
> +  r ## _ ## f ## _ ## v)

I think _none_ of these are actually used so it'd
be better to delete them instead.

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4] staging: rtl8192u: remove bool comparisons

[Luis de Bethencourt]

On Fri, Jul 17, 2015 at 11:34:45AM +0530, Sudip Mukherjee wrote:
> On Thu, Jul 16, 2015 at 03:49:49PM +0200, Luis de Bethencourt wrote:
> > Remove explicit true/false comparisons to bool variables.
> > 
> > Signed-off-by: Luis de Bethencourt 
> > ---
> 
> >
> > diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> > b/drivers/staging/rtl8192u/r8192U_core.c
> > index b852396..41cf99d 100644
> > --- a/drivers/staging/rtl8192u/r8192U_core.c
> > +++ b/drivers/staging/rtl8192u/r8192U_core.c
> > @@ -2043,16 +2043,10 @@ static bool GetNmodeSupportBySecCfg8192(struct 
> > net_device *dev)
> >  
> >  static bool GetHalfNmodeSupportByAPs819xUsb(struct net_device *dev)
> >  {
> > -   boolReval;
> > struct r8192_priv *priv = ieee80211_priv(dev);
> > struct ieee80211_device *ieee = priv->ieee80211;
> >  
> > -   if (ieee->bHalfWirelessN24GMode == true)
> > -   Reval = true;
> > -   else
> > -   Reval =  false;
> > -
> > -   return Reval;
> > +   return ieee->bHalfWirelessN24GMode;
> I think this should have been in a separate patch.
> 
> regards
> sudip

That's a good point. It is related but a different fix than removing booolean
comparisons.

Thanks once again for review Sudip :)

Going to send a new version soon,
Luis
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[patch 2/2] Staging: rtl8192e: pointer math bug in rtllib_rx_DELBA()

[Dan Carpenter]

The "delba" variable is a pointer to struct rtllib_hdr_3addr so this
pointer math bug means that we read nonsense data from beyond the end of
the buffer.  It could result in a oops if the memory is not mapped.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c 
b/drivers/staging/rtl8192e/rtl819x_BAProc.c
index 60f536c..98e6c4e 100644
--- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
@@ -453,7 +453,7 @@ int rtllib_rx_DELBA(struct rtllib_device *ieee, struct 
sk_buff *skb)
 #endif
delba = (struct rtllib_hdr_3addr *)skb->data;
dst = (u8 *)(&delba->addr2[0]);
-   delba += sizeof(struct rtllib_hdr_3addr);
+   delba++;
pDelBaParamSet = (union delba_param_set *)(delba+2);
pReasonCode = (u16 *)(delba+4);
 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[patch 1/2] Staging: rtl8192u: pointer math bug in ieee80211_rx_DELBA()

[Dan Carpenter]

The "delba" variable is a pointer to struct rtl_80211_hdr_3addr so this
addition here means we read nonsense data from beyond the end of the
buffer.  It could result in an oops if the memory is not mapped.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index 9ff8e05..c1c1a1e 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -592,7 +592,7 @@ int ieee80211_rx_DELBA(struct ieee80211_device *ieee, 
struct sk_buff *skb)
IEEE80211_DEBUG_DATA(IEEE80211_DL_DATA|IEEE80211_DL_BA, skb->data, 
skb->len);
delba = (struct rtl_80211_hdr_3addr *)skb->data;
dst = (u8 *)(&delba->addr2[0]);
-   delba += sizeof(struct rtl_80211_hdr_3addr);
+   delba++;
pDelBaParamSet = (PDELBA_PARAM_SET)(delba+2);
pReasonCode = (u16 *)(delba+4);
 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] staging: dgap: fix error path

[Dan Carpenter]

I don't think I like these at all.  remove_one has always been buggy in
that it removes everything.  We should fix it to only remove one instead
of formalizing the currect terrible behavior.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v5 1/2] staging: rtl8192u: remove bool comparisons

[Luis de Bethencourt]

Remove explicit true/false comparisons to bool variables.

Signed-off-by: Luis de Bethencourt 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c  |  4 ++--
 drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c |  2 +-
 drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c  |  4 ++--
 drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c| 12 ++--
 drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c| 14 +++---
 drivers/staging/rtl8192u/ieee80211/rtl819x_TSProc.c|  2 +-
 drivers/staging/rtl8192u/r8192U_core.c |  7 ---
 drivers/staging/rtl8192u/r8192U_dm.c   |  8 
 8 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
index b374088..0aa9021 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_rx.c
@@ -1014,7 +1014,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
goto rx_dropped;
 
// if QoS enabled, should check the sequence for each of the AC
-   if( (ieee->pHTInfo->bCurRxReorderEnable == false) || 
!ieee->current_network.qos_data.active|| !IsDataFrame(skb->data) || 
IsLegacyDataFrame(skb->data)){
+   if ((!ieee->pHTInfo->bCurRxReorderEnable) || 
!ieee->current_network.qos_data.active|| !IsDataFrame(skb->data) || 
IsLegacyDataFrame(skb->data)) {
if (is_duplicate_packet(ieee, hdr))
goto rx_dropped;
 
@@ -1307,7 +1307,7 @@ int ieee80211_rx(struct ieee80211_device *ieee, struct 
sk_buff *skb,
}
 
 //added by amy for reorder
-   if(ieee->pHTInfo->bCurRxReorderEnable == false ||pTS == NULL){
+   if (!ieee->pHTInfo->bCurRxReorderEnable || pTS == NULL){
 //added by amy for reorder
for(i = 0; inr_subframes; i++) {
struct sk_buff *sub_skb = rxb->subframes[i];
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
index a1f9d42..39e9892 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_softmac.c
@@ -1964,7 +1964,7 @@ static void ieee80211_check_auth_response(struct 
ieee80211_device *ieee,
}
 
if (ieee->current_network.mode == IEEE_N_24G &&
-   bHalfSupportNmode == true) {
+   bHalfSupportNmode) {
netdev_dbg(ieee->dev, "enter half N mode\n");
ieee->bHalfWirelessN24GMode = true;
} else
diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
index 5353a45..fff8d58 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c
@@ -336,12 +336,12 @@ static void ieee80211_tx_query_agg_cap(struct 
ieee80211_device *ieee,
printk("===>can't get TS\n");
return;
}
-   if (pTxTs->TxAdmittedBARecord.bValid == false)
+   if (!pTxTs->TxAdmittedBARecord.bValid)
{
TsStartAddBaProcess(ieee, pTxTs);
goto FORCED_AGG_SETTING;
}
-   else if (pTxTs->bUsingBa == false)
+   else if (!pTxTs->bUsingBa)
{
if 
(SN_LESS(pTxTs->TxAdmittedBARecord.BaStartSeqCtrl.field.SeqNum, 
(pTxTs->TxCurSeq+1)%4096))
pTxTs->bUsingBa = true;
diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c 
b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
index 9ff8e05..4fb77e5 100644
--- a/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
+++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_BAProc.c
@@ -364,8 +364,8 @@ int ieee80211_rx_ADDBAReq(struct ieee80211_device *ieee, 
struct sk_buff *skb)
printk(">rx ADDBAREQ from :%pM\n", dst);
 //some other capability is not ready now.
if ((ieee->current_network.qos_data.active == 0) ||
-   (ieee->pHTInfo->bCurrentHTSupport == false)) //||
-   //  (ieee->pStaQos->bEnableRxImmBA == false))
+   (!ieee->pHTInfo->bCurrentHTSupport)) //||
+   //  (!ieee->pStaQos->bEnableRxImmBA))
{
rc = ADDBA_STATUS_REFUSED;
IEEE80211_DEBUG(IEEE80211_DL_ERR, "Failed to reply on ADDBA_REQ 
as some capability is not ready(%d, %d)\n", 
ieee->current_network.qos_data.active, ieee->pHTInfo->bCurrentHTSupport);
@@ -462,8 +462,8 @@ int ieee80211_rx_ADDBARsp(struct ieee80211_device *ieee, 
struct sk_buff *skb)
// Check the capability
// Since we can always receive A-MPDU, we just check if it is

[PATCH v5 2/2] staging: rtl8192u: remove unneeded bool

[Luis de Bethencourt]

bool Reval is set to match the value of bHalfWirelessN24GMode just to
this. The value can be returned directly. Removing uneeded bool.

Signed-off-by: Luis de Bethencourt 
---
 drivers/staging/rtl8192u/r8192U_core.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index dd74813..41cf99d 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2043,16 +2043,10 @@ static bool GetNmodeSupportBySecCfg8192(struct 
net_device *dev)
 
 static bool GetHalfNmodeSupportByAPs819xUsb(struct net_device *dev)
 {
-   boolReval;
struct r8192_priv *priv = ieee80211_priv(dev);
struct ieee80211_device *ieee = priv->ieee80211;
 
-   if (ieee->bHalfWirelessN24GMode)
-   Reval = true;
-   else
-   Reval =  false;
-
-   return Reval;
+   return ieee->bHalfWirelessN24GMode;
 }
 
 static void rtl8192_refresh_supportrate(struct r8192_priv *priv)
-- 
2.1.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] staging: dgap: fix error path

[Sudip Mukherjee]

On Fri, Jul 17, 2015 at 12:30:03PM +0300, Dan Carpenter wrote:
> I don't think I like these at all.  remove_one has always been buggy in
> that it removes everything.  We should fix it to only remove one instead
> of formalizing the currect terrible behavior.
Its already applied.
I thought after the full series the code became a little better than the
original one.
Now dgap_stop() is being called from dgap_remove_one(). How do you suggest
it should be?

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

[Dexuan Cui]

> From: K. Y. Srinivasan 
> Sent: Friday, July 17, 2015 3:17
> Subject: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed
> during probe
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> ...
> @@ -1116,6 +1127,9 @@ int rndis_filter_device_add(struct hv_device *dev,
>   num_possible_rss_qs = cpumask_weight(node_cpu_mask);
>   net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
> 
> + num_rss_qs = net_device->num_chn - 1;
> + net_device->num_sc_offered = num_rss_qs;
> +
>   if (net_device->num_chn == 1)
>   goto out;
> 
> @@ -1157,11 +1171,22 @@ int rndis_filter_device_add(struct hv_device *dev,
> 
>   ret = rndis_filter_set_rss_param(rndis_device, net_device->num_chn);
> 
> + /*
> +  * Wait for the host to send us the sub-channel offers.
> +  */
> + spin_lock_irqsave(&net_device->sc_lock, flags);
> + sc_delta = net_device->num_chn - 1 - num_rss_qs;
> + net_device->num_sc_offered -= sc_delta;

Hi KY,
IMO here the "-= " should be "+="?

I think sc_delta is usually <= 0, meaning the host may allocate less 
subchannels than
we expect.
With "-=", net_device->num_sc_offered can become bigger -- this doesn't seem 
correct.

Why not use 
"net_device->num_sc_offered = net_device->num_chn - 1;" directly?
At this point, net_device->num_chn has been the number of the actual channels.


> + spin_unlock_irqrestore(&net_device->sc_lock, flags);
> +
> + if (net_device->num_sc_offered != 0)
> + wait_for_completion(&net_device->channel_init_wait);

BTW, I also tested the patch and I can confirm the panic I saw disappeared with 
the patch.

-- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] staging: dgap: fix error path

[Dan Carpenter]

On Fri, Jul 17, 2015 at 03:21:28PM +0530, Sudip Mukherjee wrote:
> On Fri, Jul 17, 2015 at 12:30:03PM +0300, Dan Carpenter wrote:
> > I don't think I like these at all.  remove_one has always been buggy in
> > that it removes everything.  We should fix it to only remove one instead
> > of formalizing the currect terrible behavior.
> Its already applied.
> I thought after the full series the code became a little better than the
> original one.

It looks nicer but it's wrong.


> Now dgap_stop() is being called from dgap_remove_one(). How do you suggest
> it should be?

dgap_remove_one() should mirror dgap_init_one().  dgap_stop() should
only be called from dgap_cleanup_module().  dgap_cleanup_module() should
mirror dgap_init_module().

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

[Dexuan Cui]

> From: K. Y. Srinivasan
> Sent: Friday, July 17, 2015 3:17
> Subject: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed
> during probe
> 
> The current code returns from probe without waiting for the proper handling
> of subchannels that may be requested. If the netvsc driver were to be rapidly
> loaded/unloaded, we can  trigger a panic as the unload will be tearing
> down state that may not have been fully setup yet. We fix this issue by making
> sure that we return from the probe call only after ensuring that the
> sub-channel offers in flight are properly handled.
> 
> ---
>  drivers/net/hyperv/hyperv_net.h   |2 ++
>  drivers/net/hyperv/rndis_filter.c |   25 +
>  2 files changed, 27 insertions(+), 0 deletions(-)

BTW, not sure if we should make the same fix to storvsc.

IMO storvsc should have the same issue, at least in theory, though usually it's
unlikely to unload storvsc.  :-)

Thanks,
-- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] staging: dgap: fix error path

[Sudip Mukherjee]

On Fri, Jul 17, 2015 at 01:05:55PM +0300, Dan Carpenter wrote:
> On Fri, Jul 17, 2015 at 03:21:28PM +0530, Sudip Mukherjee wrote:
> > On Fri, Jul 17, 2015 at 12:30:03PM +0300, Dan Carpenter wrote:
> > > I don't think I like these at all.  remove_one has always been buggy in
> > > that it removes everything.  We should fix it to only remove one instead
> > > of formalizing the currect terrible behavior.
> > Its already applied.
> > I thought after the full series the code became a little better than the
> > original one.
> 
> It looks nicer but it's wrong.
> 
> 
> > Now dgap_stop() is being called from dgap_remove_one(). How do you suggest
> > it should be?
> 
> dgap_remove_one() should mirror dgap_init_one().  dgap_stop() should
> only be called from dgap_cleanup_module().  dgap_cleanup_module() should
> mirror dgap_init_module().
But if dgap_stop() is only called from dgap_cleanup_module() then what
will happen if the pci device is suddenly removed?
Currently if the pci device is removed then the remove callback will be
executed and it will stop and unregister everything properly.

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/4] staging: dgap: fix error path

[Dan Carpenter]

On Fri, Jul 17, 2015 at 03:57:21PM +0530, Sudip Mukherjee wrote:
> On Fri, Jul 17, 2015 at 01:05:55PM +0300, Dan Carpenter wrote:
> > On Fri, Jul 17, 2015 at 03:21:28PM +0530, Sudip Mukherjee wrote:
> > > On Fri, Jul 17, 2015 at 12:30:03PM +0300, Dan Carpenter wrote:
> > > > I don't think I like these at all.  remove_one has always been buggy in
> > > > that it removes everything.  We should fix it to only remove one instead
> > > > of formalizing the currect terrible behavior.
> > > Its already applied.
> > > I thought after the full series the code became a little better than the
> > > original one.
> > 
> > It looks nicer but it's wrong.
> > 
> > 
> > > Now dgap_stop() is being called from dgap_remove_one(). How do you suggest
> > > it should be?
> > 
> > dgap_remove_one() should mirror dgap_init_one().  dgap_stop() should
> > only be called from dgap_cleanup_module().  dgap_cleanup_module() should
> > mirror dgap_init_module().
> But if dgap_stop() is only called from dgap_cleanup_module() then what
> will happen if the pci device is suddenly removed?
> Currently if the pci device is removed then the remove callback will be
> executed and it will stop and unregister everything properly.

It shouldn't be unregistering everything when one thing is removed, it
should only unregister the stuff that is removed.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2] Drivers: Staging: dgnc: Fix Style Issues

[Craig Inches]

On Thu, Jul 16, 2015 at 11:13:43PM +0300, Dan Carpenter wrote:
> On Fri, Jul 17, 2015 at 03:03:24AM +, Craig Inches wrote:
> > Fixed multiple instances of:
> > 
> > CHECK: Alignment should match open parenthesis
> > CHECK: Blank lines aren't necessary before a close brace '}'
> > CHECK: Please don't use multiple blank lines
> > CHECK: Blank lines aren't necessary after an open brace '{'
> > WARNING: line over 80 characters
> > 
> 
> Split the patch into 5 patches.
Sorry.. I dont know why I didnt do that.

> > @@ -186,18 +191,23 @@ int dgnc_tty_register(struct dgnc_board *brd)
> > brd->SerialDriver.subtype = SERIAL_TYPE_NORMAL;
> > brd->SerialDriver.init_termios = DgncDefaultTermios;
> > brd->SerialDriver.driver_name = DRVSTR;
> > -   brd->SerialDriver.flags = (TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV 
> > | TTY_DRIVER_HARDWARE_BREAK);
> > +   brd->SerialDriver.flags = (TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV
> > + | TTY_DRIVER_HARDWARE_BREAK);
> 
> The operator goes on the end.
> 
>   brd->SerialDriver.flags = (TTY_DRIVER_REAL_RAW |
>  TTY_DRIVER_DYNAMIC_DEV |
>  TTY_DRIVER_HARDWARE_BREAK);
Thanks I saw a combination of either, I will take another look.

> > kref_init(&brd->PrintDriver.kref);
> > -   brd->PrintDriver.termios = kcalloc(brd->maxports, 
> > sizeof(*brd->PrintDriver.termios), GFP_KERNEL);
> > +   brd->PrintDriver.termios = kcalloc(brd->maxports,
> > +   sizeof(*brd->PrintDriver.termios),
> > +   GFP_KERNEL);
> 
> Not aligned correctly.
> 
> > if (ch->ch_tun.un_flags & UN_ISOPEN) {
> > if ((ch->ch_tun.un_tty->flags & (1 << TTY_DO_WRITE_WAKEUP)) &&
> > -   ch->ch_tun.un_tty->ldisc->ops->write_wakeup) {
> > -   spin_unlock_irqrestore(&ch->ch_lock, flags);
> > -   
> > (ch->ch_tun.un_tty->ldisc->ops->write_wakeup)(ch->ch_tun.un_tty);
> > -   spin_lock_irqsave(&ch->ch_lock, flags);
> > +   ch->ch_tun.un_tty->ldisc->ops->write_wakeup) {
> > +   spin_unlock_irqrestore(&ch->ch_lock, flags);
> > +   (ch->ch_tun.un_tty->ldisc->ops->write_wakeup)
> > +   (ch->ch_tun.un_tty);
> > +   spin_lock_irqsave(&ch->ch_lock, flags);
> > }
> 
> This isn't correct at all.
OK, Ill another look at this aswell. Thank you for the feedback
Dan.
> regards,
> dan carpenter
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/6] staging: rtl8188eu: remove goto label

[Dan Carpenter]

On Thu, Jul 16, 2015 at 04:58:09PM +0530, Sudip Mukherjee wrote:
> By checking for the success of kzalloc we were able to remove the goto
> label thus making the code more readable.
> 

No...  You've just changed error handling to success handling and added
some new indent levels and made a tangled spaghetti exit path even more
tangled.  Spoderman wants to know, "Why u do dis?"

It should look like:

diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c 
b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index d0d4335..7617a22 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -120,16 +120,13 @@ static struct dvobj_priv *usb_dvobj_init(struct 
usb_interface *usb_intf)
 
usb_get_dev(pusbd);
 
-   status = _SUCCESS;
+   return pdvobjpriv;
 
 free_dvobj:
-   if (status != _SUCCESS && pdvobjpriv) {
-   usb_set_intfdata(usb_intf, NULL);
-   kfree(pdvobjpriv);
-   pdvobjpriv = NULL;
-   }
-exit:
-   return pdvobjpriv;
+   usb_set_intfdata(usb_intf, NULL);
+   kfree(pdvobjpriv);
+
+   return NULL;
 }
 
 static void usb_dvobj_deinit(struct usb_interface *usb_intf)


See?  No indenting, no if statements.  Just one statement after another.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable

[Jon Medhurst (Tixy)]

Use dma_get_sgtable rather than dma_common_get_sgtable so a device's
dma_ops aren't bypassed. This is essential in situations where a device
uses an IOMMU and the physical memory is not contiguous (as the common
function assumes).

Signed-off-by: Jon Medhurst 
---

This also begs the question as to what happens if the memory region _is_
contiguous but is in highmem or an ioremapped region. Should a device
always provide dma_ops for that case? Because I believe the current
implementation of dma_common_get_sgtable won't work for those as it uses
virt_to_page.

I see that this point has been raised before [1] by Zeng Tao, and I
myself have been given a different fix to apply to a Linaro kernel tree.
However, both solutions looked wrong to me as they treat a dma_addr_t as
a physical address, so should at least be using dma_to_phys.

So, should we fix dma_common_get_sgtable or mandate that the device
has dma_ops? The latter seems to be implied by the commit message which
introduced the function:

This patch provides a generic implementation based on
virt_to_page() call. Architectures which require more
sophisticated translation might provide their own get_sgtable()
methods.

Note, I don't have a system where any of this code is used to test
things, and have never looked at this area before yesterday, so I may
have misunderstood what’s going on in the code.

[1] https://lkml.org/lkml/2014/12/1/584

 drivers/staging/android/ion/ion_cma_heap.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index f4211f1..86b91fd 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -73,8 +73,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (!info->table)
goto free_mem;
 
-   if (dma_common_get_sgtable
-   (dev, info->table, info->cpu_addr, info->handle, len))
+   if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle, 
len))
goto free_table;
/* keep this for memory release */
buffer->priv_virt = info;
-- 
2.1.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/6] staging: rtl8188eu: remove goto label

[Sudip Mukherjee]

On Fri, Jul 17, 2015 at 02:03:48PM +0300, Dan Carpenter wrote:
> On Thu, Jul 16, 2015 at 04:58:09PM +0530, Sudip Mukherjee wrote:
> > By checking for the success of kzalloc we were able to remove the goto
> > label thus making the code more readable.
> > 
> 
> No...  You've just changed error handling to success handling and added
> some new indent levels and made a tangled spaghetti exit path even more
> tangled.  Spoderman wants to know, "Why u do dis?"
I had to go for google to lookup Spoderman or Spiderman. :)
At the end of the series, isn't the code better looking and simpler
than the original code?

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/6] staging: rtl8188eu: remove goto label

[Dan Carpenter]

On Fri, Jul 17, 2015 at 04:55:12PM +0530, Sudip Mukherjee wrote:
> On Fri, Jul 17, 2015 at 02:03:48PM +0300, Dan Carpenter wrote:
> > On Thu, Jul 16, 2015 at 04:58:09PM +0530, Sudip Mukherjee wrote:
> > > By checking for the success of kzalloc we were able to remove the goto
> > > label thus making the code more readable.
> > > 
> > 
> > No...  You've just changed error handling to success handling and added
> > some new indent levels and made a tangled spaghetti exit path even more
> > tangled.  Spoderman wants to know, "Why u do dis?"
> I had to go for google to lookup Spoderman or Spiderman. :)
> At the end of the series, isn't the code better looking and simpler
> than the original code?

Yes, but that's not a very high bar to clear.

What I'm trying to explain is the beauty of writing one statement after
the other without indenting.  The simplest kind of code looks like this
without error handling.


int some_function(void)
{
do_thing_one();
do_thing_two();
do_thing_three();

return 0;
}

When you add canonical error handling it looks like this:

int some_function(void)
{
do_thing_one();
if (failure)
return -ERROR;

do_thing_two();
if (failure)
goto undo_one;

do_thing_three();
if (failure)
goto undo_two;

return 0;

undo_two:
undo_two_thing();
undo_one:
undo_one_thing();

return -ERROR;
}

But with success handling it look like this:

int some_function(void)
{
do_thing_one();
if (success) {
do_thing_two();
if (success) {
do_thing_three();
if (success)
return 0;
}
}
return -ERROR;
}

Fewer lines, but terrible code.  In this patch we only make the last
condition success handling but it's still messier than need be.

if (fail)
if (fail)
if (fail)
if (success)
else

The canonical method is more consistent and simplest to read.

regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 3/6] staging: rtl8188eu: remove goto label

[Sudip Mukherjee]

On Fri, Jul 17, 2015 at 02:47:55PM +0300, Dan Carpenter wrote:
> On Fri, Jul 17, 2015 at 04:55:12PM +0530, Sudip Mukherjee wrote:
> > On Fri, Jul 17, 2015 at 02:03:48PM +0300, Dan Carpenter wrote:
> > > On Thu, Jul 16, 2015 at 04:58:09PM +0530, Sudip Mukherjee wrote:
> > > > By checking for the success of kzalloc we were able to remove the goto
> > > > label thus making the code more readable.
> > > > 
> > > 
> > > No...  You've just changed error handling to success handling and added
> > > some new indent levels and made a tangled spaghetti exit path even more
> > > tangled.  Spoderman wants to know, "Why u do dis?"
> > I had to go for google to lookup Spoderman or Spiderman. :)
> > At the end of the series, isn't the code better looking and simpler
> > than the original code?
> 
> Yes, but that's not a very high bar to clear.
> 
> What I'm trying to explain is the beauty of writing one statement after
> the other without indenting.
understood.
I was planning another series for that file so i will include one for
this also. But before that I am going to send in the patch for sm7xxfb
to move out of staging. Please check that.

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: sm750fb: ddk750_power.c: Remove optionnal parentheses.

[Antoine BLIN]

Fix up "return is not a function, parentheses are not required" error found by
the checkpatch.pl script.

Signed-off-by: Antoine BLIN 
---
 drivers/staging/sm750fb/ddk750_power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/sm750fb/ddk750_power.c 
b/drivers/staging/sm750fb/ddk750_power.c
index c8c51be..3c04447 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -20,7 +20,7 @@ unsigned int getPowerMode(void)
 {
if (getChipType() == SM750LE)
return 0;
-   return (FIELD_GET(PEEK32(POWER_MODE_CTRL), POWER_MODE_CTRL, MODE));
+   return FIELD_GET(PEEK32(POWER_MODE_CTRL), POWER_MODE_CTRL, MODE);
 }
 
 
-- 
2.4.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: sm750fb: ddk750_power.c: Split lines over 80 characters.

[Antoine BLIN]

Fix up "line over 80 characters" warning found by the checkpatch.pl script.

Signed-off-by: Antoine BLIN 
---
 drivers/staging/sm750fb/ddk750_power.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_power.c 
b/drivers/staging/sm750fb/ddk750_power.c
index 3c04447..e580dab 100644
--- a/drivers/staging/sm750fb/ddk750_power.c
+++ b/drivers/staging/sm750fb/ddk750_power.c
@@ -8,7 +8,8 @@ void ddk750_setDPMS(DPMS_t state)
 
if (getChipType() == SM750LE) {
value = PEEK32(CRT_DISPLAY_CTRL);
-   POKE32(CRT_DISPLAY_CTRL, FIELD_VALUE(value, CRT_DISPLAY_CTRL, 
DPMS, state));
+   POKE32(CRT_DISPLAY_CTRL, FIELD_VALUE(value, CRT_DISPLAY_CTRL,
+DPMS, state));
} else {
value = PEEK32(SYSTEM_CTRL);
value = FIELD_VALUE(value, SYSTEM_CTRL, DPMS, state);
@@ -39,15 +40,18 @@ void setPowerMode(unsigned int powerMode)
 
switch (powerMode) {
case POWER_MODE_CTRL_MODE_MODE0:
-   control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, 
MODE0);
+   control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ MODE0);
break;
 
case POWER_MODE_CTRL_MODE_MODE1:
-   control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, 
MODE1);
+   control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ MODE1);
break;
 
case POWER_MODE_CTRL_MODE_SLEEP:
-   control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE, 
SLEEP);
+   control_value = FIELD_SET(control_value, POWER_MODE_CTRL, MODE,
+ SLEEP);
break;
 
default:
@@ -138,8 +142,9 @@ void enableZVPort(unsigned int enable)
gate = FIELD_SET(gate, CURRENT_GATE, I2C,ON);
 #endif
} else {
-   /* Disable ZV Port Gate. There is no way to know whether the 
GPIO pins are being used
-or not. Therefore, do not disable the GPIO gate. */
+   /* Disable ZV Port Gate. There is no way to know whether the
+   GPIO pins are being used or not. Therefore, do not disable the
+   GPIO gate. */
gate = FIELD_SET(gate, CURRENT_GATE, ZVPORT, OFF);
}
 
-- 
2.4.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] staging: sm7xxfb: move sm712fb out of staging

[Sudip Mukherjee]

Now since all cleanups are done and the code is ready to be merged lets
move it out of staging into fbdev location.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/Kconfig|  2 --
 drivers/staging/Makefile   |  1 -
 drivers/staging/sm7xxfb/Kconfig| 13 -
 drivers/staging/sm7xxfb/Makefile   |  1 -
 drivers/staging/sm7xxfb/TODO   | 12 
 drivers/video/fbdev/Kconfig| 14 ++
 drivers/video/fbdev/Makefile   |  1 +
 drivers/{staging/sm7xxfb/sm7xx.h => video/fbdev/sm712.h}   |  0
 .../{staging/sm7xxfb/sm7xxfb.c => video/fbdev/sm712fb.c}   |  2 +-
 9 files changed, 16 insertions(+), 30 deletions(-)
 delete mode 100644 drivers/staging/sm7xxfb/Kconfig
 delete mode 100644 drivers/staging/sm7xxfb/Makefile
 delete mode 100644 drivers/staging/sm7xxfb/TODO
 rename drivers/{staging/sm7xxfb/sm7xx.h => video/fbdev/sm712.h} (100%)
 rename drivers/{staging/sm7xxfb/sm7xxfb.c => video/fbdev/sm712fb.c} (99%)

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 7f6cae5..a969276 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -56,8 +56,6 @@ source "drivers/staging/vt6656/Kconfig"
 
 source "drivers/staging/iio/Kconfig"
 
-source "drivers/staging/sm7xxfb/Kconfig"
-
 source "drivers/staging/sm750fb/Kconfig"
 
 source "drivers/staging/xgifb/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 347f647..2747c82 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -22,7 +22,6 @@ obj-$(CONFIG_VT6655)  += vt6655/
 obj-$(CONFIG_VT6656)   += vt6656/
 obj-$(CONFIG_VME_BUS)  += vme/
 obj-$(CONFIG_IIO)  += iio/
-obj-$(CONFIG_FB_SM7XX) += sm7xxfb/
 obj-$(CONFIG_FB_SM750) += sm750fb/
 obj-$(CONFIG_FB_XGI)   += xgifb/
 obj-$(CONFIG_USB_EMXX) += emxx_udc/
diff --git a/drivers/staging/sm7xxfb/Kconfig b/drivers/staging/sm7xxfb/Kconfig
deleted file mode 100644
index e2922ae..000
--- a/drivers/staging/sm7xxfb/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config FB_SM7XX
-   tristate "Silicon Motion SM7XX framebuffer support"
-   depends on FB && PCI
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   help
- Frame buffer driver for the Silicon Motion SM710, SM712, SM721
- and SM722 chips.
-
- This driver is also available as a module. The module will be
- called sm7xxfb. If you want to compile it as a module, say M
- here and read .
diff --git a/drivers/staging/sm7xxfb/Makefile b/drivers/staging/sm7xxfb/Makefile
deleted file mode 100644
index 48f471c..000
--- a/drivers/staging/sm7xxfb/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_FB_SM7XX) += sm7xxfb.o
diff --git a/drivers/staging/sm7xxfb/TODO b/drivers/staging/sm7xxfb/TODO
deleted file mode 100644
index 7cb0b24..000
--- a/drivers/staging/sm7xxfb/TODO
+++ /dev/null
@@ -1,12 +0,0 @@
-TODO:
-- Dual head support
-- 2D acceleration support
-- use kernel coding style
-- refine the code and remove unused code
-- move it to drivers/video/fbdev/sm7xxfb.c
-
-Please send any patches to
-   Greg Kroah-Hartman 
-   Sudip Mukherjee 
-   Teddy Wang 
-   Sudip Mukherjee 
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2d98de5..2307909 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2475,3 +2475,17 @@ config FB_SSD1307
help
  This driver implements support for the Solomon SSD1307
  OLED controller over I2C.
+
+config FB_SM712
+   tristate "Silicon Motion SM712 framebuffer support"
+   depends on FB && PCI
+   select FB_CFB_FILLRECT
+   select FB_CFB_COPYAREA
+   select FB_CFB_IMAGEBLIT
+   help
+ Frame buffer driver for the Silicon Motion SM710, SM712, SM721
+ and SM722 chips.
+
+ This driver is also available as a module. The module will be
+ called sm712fb. If you want to compile it as a module, say M
+ here and read .
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index cecea50..50ed1b4 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -131,6 +131,7 @@ obj-$(CONFIG_FB_JZ4740)   += jz4740_fb.o
 obj-$(CONFIG_FB_PUV3_UNIGFX)  += fb-puv3.o
 obj-$(CONFIG_FB_HYPERV)  += hyperv_fb.o
 obj-$(CONFIG_FB_OPENCORES)   += ocfb.o
+obj-$(CONFIG_FB_SM712)   += sm712fb.o
 
 # Platform or fallback drivers go here
 obj-$(CONFIG_FB_UVESA)+= uvesafb.o
diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/video/fbdev/sm712.h
similarity index 100%
rename from drivers/staging/sm7xxfb/sm7xx.h
rename to drivers/video/fbdev/sm712.h
diff --git a/drivers/staging/sm7xxfb/sm7x

[PATCH 2/3] Documentation/fb: add documentation for sm712fb

[Sudip Mukherjee]

Create the documentation for SM712. Mention all the supported modes and
how to use.

Signed-off-by: Sudip Mukherjee 
---
 Documentation/fb/sm712fb.txt | 31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/fb/sm712fb.txt

diff --git a/Documentation/fb/sm712fb.txt b/Documentation/fb/sm712fb.txt
new file mode 100644
index 000..c388442
--- /dev/null
+++ b/Documentation/fb/sm712fb.txt
@@ -0,0 +1,31 @@
+What is sm712fb?
+=
+
+This is a graphics framebuffer driver for Silicon Motion SM712 based 
processors.
+
+How to use it?
+==
+
+Switching modes is done using the video=sm712fb:... boot parameter.
+
+If you want, for example, enable a resolution of 1280x1024x24bpp you should
+pass to the kernel this command line: "video=sm712fb:0x31B".
+
+You should not compile-in vesafb.
+
+Currently supported video modes are:
+
+[Graphic modes]
+
+bpp | 640x480  800x600  1024x768  1280x1024
++
+  8 | 0x3010x3030x3050x307
+ 16 | 0x3110x3140x3170x31A
+ 24 | 0x3120x3150x3180x31B
+
+Missing Features
+
+(alias TODO list)
+
+   * 2D acceleratrion
+   * dual-head support
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/3] MAINTAINERS: update maintainers list

[Sudip Mukherjee]

Now since sm712fb has moved out of staging update the maintainers list
accordingly.

Signed-off-by: Sudip Mukherjee 
---
 MAINTAINERS | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..2c77c30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9301,6 +9301,15 @@ S:   Maintained
 F: drivers/media/i2c/ov2659.c
 F: include/media/ov2659.h
 
+SILICON MOTION SM712 FRAME BUFFER DRIVER
+M: Sudip Mukherjee 
+M: Teddy Wang 
+M: Sudip Mukherjee 
+L: linux-fb...@vger.kernel.org
+S: Maintained
+F: drivers/video/fbdev/sm712*
+F: Documentation/fb/sm712fb.txt
+
 SIS 190 ETHERNET DRIVER
 M: Francois Romieu 
 L: net...@vger.kernel.org
@@ -9721,14 +9730,6 @@ L:   linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/staging/rtl8723au/
 
-STAGING - SILICON MOTION SM7XX FRAME BUFFER DRIVER
-M: Sudip Mukherjee 
-M: Teddy Wang 
-M: Sudip Mukherjee 
-L: linux-fb...@vger.kernel.org
-S: Maintained
-F: drivers/staging/sm7xxfb/
-
 STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER
 M: Sudip Mukherjee 
 M: Teddy Wang 
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/5] drivers: staging: rtl8192u: removed pointer check for kfree in r8192U_core.c

[Joseph-Eugene Winzer]

kfree() can handle NULL pointers itself, so the check is unnecessary.

Signed-off-by: Joseph-Eugene Winzer 
---
 drivers/staging/rtl8192u/r8192U_core.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 89b627f..34dc4af 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1803,10 +1803,8 @@ static void rtl8192_usb_deleteendpoints(struct 
net_device *dev)
}
kfree(priv->oldaddr);
priv->oldaddr = NULL;
-   if (priv->pp_rxskb) {
-   kfree(priv->pp_rxskb);
-   priv->pp_rxskb = NULL;
-   }
+   kfree(priv->pp_rxskb);
+   priv->pp_rxskb = NULL;
 }
 #else
 void rtl8192_usb_deleteendpoints(struct net_device *dev)
@@ -1831,11 +1829,8 @@ void rtl8192_usb_deleteendpoints(struct net_device *dev)
priv->rx_urb = NULL;
kfree(priv->oldaddr);
priv->oldaddr = NULL;
-   if (priv->pp_rxskb) {
-   kfree(priv->pp_rxskb);
-   priv->pp_rxskb = 0;
-
-   }
+   kfree(priv->pp_rxskb);
+   priv->pp_rxskb = 0;
 
 #endif
 }
-- 
2.4.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/5] drivers: staging: rtl8192u: fixing coding style issues in r8192U_core.c

[Joseph-Eugene Winzer]

Reformatting the code without introducing other warnings
like 'Avoid unnecessary line continuations' or breaking strings.

Signed-off-by: Joseph-Eugene Winzer 
---
 drivers/staging/rtl8192u/r8192U_core.c | 809 ++---
 1 file changed, 536 insertions(+), 273 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 273a56c..89b627f 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -143,17 +143,35 @@ struct CHANNEL_LIST {
 };
 
 static struct CHANNEL_LIST ChannelPlan[] = {
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 
149, 153, 157, 161, 165}, 24}, /* FCC */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11}, /* IC */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56, 
60, 64}, 21}, /* ETSI */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* Spain. Change to 
ETSI. */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* France. Change to 
ETSI. */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22}, /* MKK //MKK */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22}, /* MKK1 */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* Israel. */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22}, /*  For 11a , TELEC */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22}, /* MIC */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14} /* For Global 
Domain. 1-11:active scan, 12-14 passive scan. //+YJ, 080626 */
+   /* FCC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64,
+ 149, 153, 157, 161, 165}, 24},
+   /* IC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},
+   /* ETSI */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56,
+ 60, 64}, 21},
+   /* Spain. Change to ETSI. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
+   /* France. Change to ETSI. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
+   /* MKK //MKK */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
+ 56, 60, 64}, 22},
+   /* MKK1 */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
+ 56, 60, 64}, 22},
+   /* Israel. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},
+   /*  For 11a , TELEC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
+ 56, 60, 64}, 22},
+   /* MIC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52,
+ 56, 60, 64}, 22},
+   /* For Global Domain. 1-11:active scan, 12-14 passive scan.
+* //+YJ, 080626 */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14}
 };
 
 static void rtl819x_set_channel_map(u8 channel_plan, struct r8192_priv *priv)
@@ -179,7 +197,9 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct 
r8192_priv *priv)
min_chan = 1;
max_chan = 14;
} else {
-   RT_TRACE(COMP_ERR, "unknown rf chip, can't set channel 
map in function:%s()\n", __func__);
+   RT_TRACE(COMP_ERR,
+"unknown rf chip, can't set channel map in 
function:%s()\n"
+, __func__);
}
if (ChannelPlan[channel_plan].Len != 0) {
/*  Clear old channel map */
@@ -187,7 +207,10 @@ static void rtl819x_set_channel_map(u8 channel_plan, 
struct r8192_priv *priv)
   sizeof(GET_DOT11D_INFO(ieee)->channel_map));
/*  Set new channel map */
for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
-   if (ChannelPlan[channel_plan].Channel[i] < 
min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
+   if (ChannelPlan[channel_plan].Channel[i] <
+   min_chan ||
+   ChannelPlan[channel_plan].Channel[i] >
+   max_chan)
break;

GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1;
}
@@ -619,8 +642,8 @@ static void rtl8192_proc_init_one(struct net_device *dev)
for (f = rtl8192_proc_files; f->name[0]; f++) {
if (!proc_create_data(f->name, S_IFREG | S_IRUGO, dir,
  &rtl8192_proc_fops, f->show)) {
-   RT_TRACE(COMP_ERR, "Unable to init

[PATCH 5/5] drivers: staging: rtl8192u: fixed coding style issues in r8192U_core.c

[Joseph-Eugene Winzer]

Fixed a few lines that were longer than 80 chars.

Signed-off-by: Joseph-Eugene Winzer 
---
 drivers/staging/rtl8192u/r8192U_core.c | 61 +++---
 1 file changed, 41 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 134a6ed..9bf6248 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -212,7 +212,9 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct 
r8192_priv *priv)
ChannelPlan[channel_plan].Channel[i] >
max_chan)
break;
-   
GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1;
+   GET_DOT11D_INFO(ieee)->
+   channel_map[ChannelPlan[channel_plan].
+   Channel[i]] = 1;
}
}
break;
@@ -1092,7 +1094,8 @@ static void rtl8192_tx_isr(struct urb *tx_urb)
/* Don't send data frame during scanning.*/
if ((skb_queue_len(&priv->ieee80211->skb_waitQ[queue_index]) !=
 0) && (!(priv->ieee80211->queue_stop))) {
-   skb = 
skb_dequeue(&(priv->ieee80211->skb_waitQ[queue_index]));
+   skb = skb_dequeue(&(priv->ieee80211->
+  skb_waitQ[queue_index]));
if (skb)
priv->ieee80211->softmac_hard_start_xmit(skb,
 dev);
@@ -1712,7 +1715,10 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
status = usb_submit_urb(tx_urb_zero, GFP_ATOMIC);
if (status) {
RT_TRACE(COMP_ERR,
-"Error TX URB for zero byte %d, error 
%d", atomic_read(&priv->tx_pending[tcb_desc->queue_index]), status);
+ "Error TX URB for zero byte %d, error %d",
+ atomic_read(&priv->tx_pending[tcb_desc->
+ queue_index]),
+ status);
return -1;
}
}
@@ -1893,7 +1899,9 @@ static void rtl8192_update_beacon(struct work_struct 
*work)
 /*
  * background support to run QoS activate functionality
  */
-static int WDCAPARA_ADD[] = {EDCAPARA_BE, EDCAPARA_BK, EDCAPARA_VI, 
EDCAPARA_VO};
+static int WDCAPARA_ADD[] = {EDCAPARA_BE, EDCAPARA_BK,
+EDCAPARA_VI, EDCAPARA_VO};
+
 static void rtl8192_qos_activate(struct work_struct *work)
 {
struct r8192_priv *priv =
@@ -2627,27 +2635,34 @@ static void rtl8192_read_eeprom_info(struct net_device 
*dev)
if (priv->EEPROM_Def_Ver == 0) {
if (i <= 3)
priv->TxPowerLevelCCK[i] =
-   
priv->EEPROMTxPowerLevelOFDM24G[0] +
+   priv->
+ EEPROMTxPowerLevelOFDM24G[0] +
(priv->EEPROMTxPowerLevelCCK -
-
priv->EEPROMTxPowerLevelOFDM24G[1]);
+priv->
+ EEPROMTxPowerLevelOFDM24G[1]);
else if (i >= 4 && i <= 9)
priv->TxPowerLevelCCK[i] =
priv->EEPROMTxPowerLevelCCK;
else
priv->TxPowerLevelCCK[i] =
-   
priv->EEPROMTxPowerLevelOFDM24G[2] +
+   priv->
+ EEPROMTxPowerLevelOFDM24G[2] +
(priv->EEPROMTxPowerLevelCCK -
-
priv->EEPROMTxPowerLevelOFDM24G[1]);
+priv->
+ EEPROMTxPowerLevelOFDM24G[1]);
} else if (priv->EEPROM_Def_Ver == 1) {
if (i <= 3)
priv->TxPowerLevelCCK[i] =
-   
priv->EEPROMTxPowerLevelCCK_V1[0];
+   priv->
+   EEPROMTxPowerLevelCCK

[PATCH 1/5] drivers: staging: rtl8192u: fixing coding style issues in r8192U_core.c

[Joseph-Eugene Winzer]

Fixing several coding style issues, like
C99 Comment Style
Trailing whitespaces
Inconsistent spacing of operators
Started to reformat comments/expressions for 80 character limit

Signed-off-by: Joseph-Eugene Winzer 
---
 drivers/staging/rtl8192u/r8192U_core.c | 1323 ++--
 1 file changed, 749 insertions(+), 574 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index b852396..273a56c 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -64,7 +64,7 @@ double __extendsfdf2(float a)
 #include "r8190_rtl8256.h" /* RTL8225 Radio frontend */
 #include "r8180_93cx6.h"   /* Card EEPROM */
 #include "r8192U_wx.h"
-#include "r819xU_phy.h" //added by WB 4.30.2008
+#include "r819xU_phy.h" /* added by WB 4.30.2008 */
 #include "r819xU_phyreg.h"
 #include "r819xU_cmdpkt.h"
 #include "r8192U_dm.h"
@@ -72,13 +72,13 @@ double __extendsfdf2(float a)
 #include 
 #include 
 #include 
-// FIXME: check if 2.6.7 is ok
+/* FIXME: check if 2.6.7 is ok */
 
 #include "dot11d.h"
-//set here to open your trace code. //WB
+/* set here to open your trace code. //WB */
 u32 rt_global_debug_component = COMP_DOWN  |
COMP_SEC|
-   COMP_ERR; //always open err flags on
+   COMP_ERR; /* always open err flags on */
 
 #define TOTAL_CAM_ENTRY 32
 #define CAM_CONTENT_COUNT 8
@@ -109,7 +109,7 @@ MODULE_DEVICE_TABLE(usb, rtl8192_usb_id_tbl);
 MODULE_DESCRIPTION("Linux driver for Realtek RTL8192 USB WiFi cards");
 
 static char *ifname = "wlan%d";
-static int hwwep = 1;  //default use hw. set 0 to use software security
+static int hwwep = 1;  /* default use hw. set 0 to use software security */
 static int channels = 0x3fff;
 
 
@@ -143,23 +143,24 @@ struct CHANNEL_LIST {
 };
 
 static struct CHANNEL_LIST ChannelPlan[] = {
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 
149, 153, 157, 161, 165}, 24}, //FCC
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},  
//IC
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56, 
60, 64}, 21},  //ETSI
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},//Spain. Change 
to ETSI.
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  //France. 
Change to ETSI.
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  //MKK   //MKK
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},//MKK1
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  //Israel.
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  // For 11a , TELEC
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},//MIC
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14}   
//For Global Domain. 1-11:active scan, 12-14 passive scan. 
//+YJ, 080626
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 
149, 153, 157, 161, 165}, 24}, /* FCC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11}, /* IC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56, 
60, 64}, 21}, /* ETSI */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* Spain. Change to 
ETSI. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* France. Change to 
ETSI. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22}, /* MKK //MKK */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22}, /* MKK1 */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* Israel. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22}, /*  For 11a , TELEC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22}, /* MIC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14} /* For Global 
Domain. 1-11:active scan, 12-14 passive scan. //+YJ, 080626 */
 };
 
 static void rtl819x_set_channel_map(u8 channel_plan, struct r8192_priv *priv)
 {
int i, max_chan = -1, min_chan = -1;
struct ieee80211_device *ieee = priv->ieee80211;
+
switch (channel_plan) {
case COUNTRY_CODE_FCC:
case COUNTRY_CODE_IC:
@@ -173,7 +174,7 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct 
r8192_priv *priv)
case COUNTRY_CODE_MIC:
Dot11d_Init(ieee);
ieee->bGlobalDomain = false;
-   //actually 8225 & 8256 rf chips only support B,G,24N mode
+   /* actually 8225 & 8256 rf chips only support B,G,24N mode */
if ((priv->rf_

[PATCH 4/5] drivers: staging: rtl8192u: included linux/uaccess.h instead of asm/uaccess.h

[Joseph-Eugene Winzer]

Checkpatch didn't stop complaining about it and as linux/uaccess.h also
includes asm/uaccess.h, there shouldn't be a problem.

Signed-off-by: Joseph-Eugene Winzer 
---
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 34dc4af..134a6ed 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -58,7 +58,7 @@ double __extendsfdf2(float a)
 
 #define CONFIG_RTL8192_IO_MAP
 
-#include 
+#include 
 #include "r8192U_hw.h"
 #include "r8192U.h"
 #include "r8190_rtl8256.h" /* RTL8225 Radio frontend */
-- 
2.4.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

[Vitaly Kuznetsov]

"K. Y. Srinivasan"  writes:

> The current code returns from probe without waiting for the proper handling
> of subchannels that may be requested. If the netvsc driver were to be rapidly
> loaded/unloaded, we can  trigger a panic as the unload will be tearing
> down state that may not have been fully setup yet. We fix this issue by making
> sure that we return from the probe call only after ensuring that the
> sub-channel offers in flight are properly handled.
>
> Signed-off-by: K. Y. Srinivasan 
> Reviewed-and-tested-by: Haiyang Zhang  ---
>  drivers/net/hyperv/hyperv_net.h   |2 ++
>  drivers/net/hyperv/rndis_filter.c |   25 +
>  2 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
> index 26cd14c..925b75d 100644
> --- a/drivers/net/hyperv/hyperv_net.h
> +++ b/drivers/net/hyperv/hyperv_net.h
> @@ -671,6 +671,8 @@ struct netvsc_device {
>   u32 send_table[VRSS_SEND_TAB_SIZE];
>   u32 max_chn;
>   u32 num_chn;
> + spinlock_t sc_lock; /* Protects num_sc_offered variable */
> + u32 num_sc_offered;
>   atomic_t queue_sends[NR_CPUS];
>
>   /* Holds rndis device info */
> diff --git a/drivers/net/hyperv/rndis_filter.c 
> b/drivers/net/hyperv/rndis_filter.c
> index 2e40417..2e09f3f 100644
> --- a/drivers/net/hyperv/rndis_filter.c
> +++ b/drivers/net/hyperv/rndis_filter.c
> @@ -984,9 +984,16 @@ static void netvsc_sc_open(struct vmbus_channel *new_sc)
>   struct netvsc_device *nvscdev;
>   u16 chn_index = new_sc->offermsg.offer.sub_channel_index;
>   int ret;
> + unsigned long flags;
>
>   nvscdev = hv_get_drvdata(new_sc->primary_channel->device_obj);
>
> + spin_lock_irqsave(&nvscdev->sc_lock, flags);
> + nvscdev->num_sc_offered--;
> + spin_unlock_irqrestore(&nvscdev->sc_lock, flags);
> + if (nvscdev->num_sc_offered == 0)
> + complete(&nvscdev->channel_init_wait);
> +
>   if (chn_index >= nvscdev->num_chn)
>   return;
>
> @@ -1015,8 +1022,10 @@ int rndis_filter_device_add(struct hv_device *dev,
>   u32 rsscap_size = sizeof(struct ndis_recv_scale_cap);
>   u32 mtu, size;
>   u32 num_rss_qs;
> + u32 sc_delta;
>   const struct cpumask *node_cpu_mask;
>   u32 num_possible_rss_qs;
> + unsigned long flags;
>
>   rndis_device = get_rndis_device();
>   if (!rndis_device)
> @@ -1039,6 +1048,8 @@ int rndis_filter_device_add(struct hv_device *dev,
>   net_device->max_chn = 1;
>   net_device->num_chn = 1;
>
> + spin_lock_init(&net_device->sc_lock);
> +
>   net_device->extension = rndis_device;
>   rndis_device->net_dev = net_device;
>
> @@ -1116,6 +1127,9 @@ int rndis_filter_device_add(struct hv_device *dev,
>   num_possible_rss_qs = cpumask_weight(node_cpu_mask);
>   net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
>
> + num_rss_qs = net_device->num_chn - 1;
> + net_device->num_sc_offered = num_rss_qs;
> +
>   if (net_device->num_chn == 1)
>   goto out;
>
> @@ -1157,11 +1171,22 @@ int rndis_filter_device_add(struct hv_device *dev,
>
>   ret = rndis_filter_set_rss_param(rndis_device, net_device->num_chn);
>
> + /*
> +  * Wait for the host to send us the sub-channel offers.
> +  */
> + spin_lock_irqsave(&net_device->sc_lock, flags);
> + sc_delta = net_device->num_chn - 1 - num_rss_qs;
> + net_device->num_sc_offered -= sc_delta;
> + spin_unlock_irqrestore(&net_device->sc_lock, flags);
> +
> + if (net_device->num_sc_offered != 0)
> + wait_for_completion(&net_device->channel_init_wait);

I'd suggest we add an essentian timeout (big, let's say 30 sec.)
here. In case something goes wrong we don't really want to hang the
whole kernel for forever. Such bugs are hard to debug as if a 'kernel
hangs' is reported we can't be sure which wait caused it. We can even
have something like:

 t = wait_for_completion_timeout(&net_device->channel_init_wait, 30*HZ);
 BUG_ON(t == 0);

This is much better as we'll be sure what went wrong. (I know other
pieces of hyper-v code use wait_for_completion() without a timeout, this
is rather a general suggestion for all of them).

>  out:
>   if (ret) {
>   net_device->max_chn = 1;
>   net_device->num_chn = 1;
>   }
> +
>   return 0; /* return 0 because primary channel can be used alone */
>
>  err_dev_remv:

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC 2/9] android: add sync_fence_create_dma

[John . C . Harrison]

From: Maarten Lankhorst 

This allows users of dma fences to create a android fence.

v2: Added kerneldoc. (Tvrtko Ursulin).

Signed-off-by: Maarten Lankhorst 
Signed-off-by: Tvrtko Ursulin 
Cc: Maarten Lankhorst 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
Cc: de...@driverdev.osuosl.org
Cc: Riley Andrews 
Cc: Greg Kroah-Hartman 
Cc: Arve Hjønnevåg 
---
 drivers/staging/android/sync.c | 13 +
 drivers/staging/android/sync.h | 12 +++-
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index f83e00c..7f0e919 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -188,7 +188,7 @@ static void fence_check_cb_func(struct fence *f, struct 
fence_cb *cb)
 }
 
 /* TODO: implement a create which takes more that one sync_pt */
-struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
+struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt)
 {
struct sync_fence *fence;
 
@@ -199,16 +199,21 @@ struct sync_fence *sync_fence_create(const char *name, 
struct sync_pt *pt)
fence->num_fences = 1;
atomic_set(&fence->status, 1);
 
-   fence->cbs[0].sync_pt = &pt->base;
+   fence->cbs[0].sync_pt = pt;
fence->cbs[0].fence = fence;
-   if (fence_add_callback(&pt->base, &fence->cbs[0].cb,
-  fence_check_cb_func))
+   if (fence_add_callback(pt, &fence->cbs[0].cb, fence_check_cb_func))
atomic_dec(&fence->status);
 
sync_fence_debug_add(fence);
 
return fence;
 }
+EXPORT_SYMBOL(sync_fence_create_dma);
+
+struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt)
+{
+   return sync_fence_create_dma(name, &pt->base);
+}
 EXPORT_SYMBOL(sync_fence_create);
 
 struct sync_fence *sync_fence_fdget(int fd)
diff --git a/drivers/staging/android/sync.h b/drivers/staging/android/sync.h
index a21b79f..0f1299e 100644
--- a/drivers/staging/android/sync.h
+++ b/drivers/staging/android/sync.h
@@ -250,10 +250,20 @@ void sync_pt_free(struct sync_pt *pt);
  * @pt:sync_pt to add to the fence
  *
  * Creates a fence containg @pt.  Once this is called, the fence takes
- * ownership of @pt.
+ * a reference on @pt.
  */
 struct sync_fence *sync_fence_create(const char *name, struct sync_pt *pt);
 
+/**
+ * sync_fence_create_dma() - creates a sync fence from dma-fence
+ * @name:  name of fence to create
+ * @pt:dma-fence to add to the fence
+ *
+ * Creates a fence containg @pt.  Once this is called, the fence takes
+ * a reference on @pt.
+ */
+struct sync_fence *sync_fence_create_dma(const char *name, struct fence *pt);
+
 /*
  * API for sync_fence consumers
  */
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[RFC 1/9] staging/android/sync: Support sync points created from dma-fences

[John . C . Harrison]

From: Tvrtko Ursulin 

Debug output assumes all sync points are built on top of Android sync points
and when we start creating them from dma-fences will NULL ptr deref unless
taught about this.

Signed-off-by: Tvrtko Ursulin 
Cc: Maarten Lankhorst 
Cc: de...@driverdev.osuosl.org
Cc: Riley Andrews 
Cc: Greg Kroah-Hartman 
Cc: Arve Hjønnevåg 
---
 drivers/staging/android/sync_debug.c | 42 +++-
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index 91ed2c4..f45d13c 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -82,36 +82,42 @@ static const char *sync_status_str(int status)
return "error";
 }
 
-static void sync_print_pt(struct seq_file *s, struct sync_pt *pt, bool fence)
+static void sync_print_pt(struct seq_file *s, struct fence *pt, bool fence)
 {
int status = 1;
-   struct sync_timeline *parent = sync_pt_parent(pt);
 
-   if (fence_is_signaled_locked(&pt->base))
-   status = pt->base.status;
+   if (fence_is_signaled_locked(pt))
+   status = pt->status;
 
seq_printf(s, "  %s%spt %s",
-  fence ? parent->name : "",
+  fence && pt->ops->get_timeline_name ?
+  pt->ops->get_timeline_name(pt) : "",
   fence ? "_" : "",
   sync_status_str(status));
 
if (status <= 0) {
struct timespec64 ts64 =
-   ktime_to_timespec64(pt->base.timestamp);
+   ktime_to_timespec64(pt->timestamp);
 
seq_printf(s, "@%lld.%09ld", (s64)ts64.tv_sec, ts64.tv_nsec);
}
 
-   if (parent->ops->timeline_value_str &&
-   parent->ops->pt_value_str) {
+   if ((!fence || pt->ops->timeline_value_str) &&
+   pt->ops->fence_value_str) {
char value[64];
+   bool success;
 
-   parent->ops->pt_value_str(pt, value, sizeof(value));
-   seq_printf(s, ": %s", value);
-   if (fence) {
-   parent->ops->timeline_value_str(parent, value,
-   sizeof(value));
-   seq_printf(s, " / %s", value);
+   pt->ops->fence_value_str(pt, value, sizeof(value));
+   success = strlen(value);
+
+   if (success)
+   seq_printf(s, ": %s", value);
+
+   if (success && fence) {
+   pt->ops->timeline_value_str(pt, value, sizeof(value));
+
+   if (strlen(value))
+   seq_printf(s, " / %s", value);
}
}
 
@@ -138,7 +144,7 @@ static void sync_print_obj(struct seq_file *s, struct 
sync_timeline *obj)
list_for_each(pos, &obj->child_list_head) {
struct sync_pt *pt =
container_of(pos, struct sync_pt, child_list);
-   sync_print_pt(s, pt, false);
+   sync_print_pt(s, &pt->base, false);
}
spin_unlock_irqrestore(&obj->child_list_lock, flags);
 }
@@ -153,11 +159,7 @@ static void sync_print_fence(struct seq_file *s, struct 
sync_fence *fence)
   sync_status_str(atomic_read(&fence->status)));
 
for (i = 0; i < fence->num_fences; ++i) {
-   struct sync_pt *pt =
-   container_of(fence->cbs[i].sync_pt,
-struct sync_pt, base);
-
-   sync_print_pt(s, pt, true);
+   sync_print_pt(s, fence->cbs[i].sync_pt, true);
}
 
spin_lock_irqsave(&fence->wq.lock, flags);
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Intel-gfx] [RFC 1/9] staging/android/sync: Support sync points created from dma-fences

[Tvrtko Ursulin]

On 07/17/2015 03:31 PM, john.c.harri...@intel.com wrote:

From: Tvrtko Ursulin 

Debug output assumes all sync points are built on top of Android sync points
and when we start creating them from dma-fences will NULL ptr deref unless
taught about this.


This is Maarten's code, just the patch had a troubled history where it 
got misplaced, forgotten and then resurrected but with the commit 
message lost.


Tvrtko
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [V2 6/7] hvsock: introduce Hyper-V VM Sockets feature

[Vitaly Kuznetsov]

Dexuan Cui  writes:

>> From: David Miller
>> Sent: Thursday, July 16, 2015 12:19
>> 
>> From: Dexuan Cui
>> Date: Tue, 14 Jul 2015 03:00:48 -0700
>> 
>> > +  pr_debug("hvsock_sk_destruct: called\n");
>> 
>> Debug logging just to state that a function is called is not appropriate,
>> we have very sophisticated tracing facilities in the kernel that can do
>> that transparently, and more.
>> 
>> Please remove this.
> OK. 
>
>> > +  if (hvsk->channel) {
>> > +  pr_debug("hvsock_sk_destruct: calling vmbus_close()\n");
>> 
>> Likewise, these kinds of debug logs are totally inappropriate.
> OK, I'll remove all the pr_debug() in the patch.
>

I'd suggest we rather use something like net_dbg_ratelimited()
intead. The driver is new so issues are expected. Some debugging may
be useful)

[...]

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable

[Robin Murphy]

Hi Tixy,

On 17/07/15 12:01, Jon Medhurst (Tixy) wrote:

Use dma_get_sgtable rather than dma_common_get_sgtable so a device's
dma_ops aren't bypassed. This is essential in situations where a device
uses an IOMMU and the physical memory is not contiguous (as the common
function assumes).

Signed-off-by: Jon Medhurst 


The lack of obvious users of this code makes it hard to tell if "dev" 
here is always the right, real, device pointer and never null or some 
dummy device with the wrong dma_ops, but the rest of the calls in this 
file are to the proper DMA API interface so at least this patch 
definitely makes things less wrong in that respect.


Reviewed-by: Robin Murphy 


---

This also begs the question as to what happens if the memory region _is_
contiguous but is in highmem or an ioremapped region. Should a device
always provide dma_ops for that case? Because I believe the current
implementation of dma_common_get_sgtable won't work for those as it uses
virt_to_page.

I see that this point has been raised before [1] by Zeng Tao, and I
myself have been given a different fix to apply to a Linaro kernel tree.
However, both solutions looked wrong to me as they treat a dma_addr_t as
a physical address, so should at least be using dma_to_phys.
So, should we fix dma_common_get_sgtable or mandate that the device
has dma_ops? The latter seems to be implied by the commit message which
introduced the function:

 This patch provides a generic implementation based on
 virt_to_page() call. Architectures which require more
 sophisticated translation might provide their own get_sgtable()
 methods.


Given that we're largely here due to having poked this on arm64 systems, 
I'm inclined to think that implementing our own get_sgtable as per 
arch/arm is the right course of action. Since a lot of architectures 
using dma_common_get_sgtable don't even implement dma_to_phys, I don't 
think it would be right to try complicating the common code for a case 
that seems to be all but common. I can spin an arm64 patch if you like.


Robin.


Note, I don't have a system where any of this code is used to test
things, and have never looked at this area before yesterday, so I may
have misunderstood what’s going on in the code.

[1] https://lkml.org/lkml/2014/12/1/584

  drivers/staging/android/ion/ion_cma_heap.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index f4211f1..86b91fd 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -73,8 +73,7 @@ static int ion_cma_allocate(struct ion_heap *heap, struct 
ion_buffer *buffer,
if (!info->table)
goto free_mem;

-   if (dma_common_get_sgtable
-   (dev, info->table, info->cpu_addr, info->handle, len))
+   if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle, 
len))
goto free_table;
/* keep this for memory release */
buffer->priv_virt = info;



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

[KY Srinivasan]

> -Original Message-
> From: Dexuan Cui
> Sent: Friday, July 17, 2015 3:01 AM
> To: KY Srinivasan; da...@davemloft.net; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; vkuzn...@redhat.com
> Cc: KY Srinivasan
> Subject: RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> processed during probe
> 
> > From: K. Y. Srinivasan
> > Sent: Friday, July 17, 2015 3:17
> > Subject: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> processed
> > during probe
> > diff --git a/drivers/net/hyperv/hyperv_net.h
> b/drivers/net/hyperv/hyperv_net.h
> > ...
> > @@ -1116,6 +1127,9 @@ int rndis_filter_device_add(struct hv_device
> *dev,
> > num_possible_rss_qs = cpumask_weight(node_cpu_mask);
> > net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
> >
> > +   num_rss_qs = net_device->num_chn - 1;
> > +   net_device->num_sc_offered = num_rss_qs;
> > +
> > if (net_device->num_chn == 1)
> > goto out;
> >
> > @@ -1157,11 +1171,22 @@ int rndis_filter_device_add(struct hv_device
> *dev,
> >
> > ret = rndis_filter_set_rss_param(rndis_device, net_device-
> >num_chn);
> >
> > +   /*
> > +* Wait for the host to send us the sub-channel offers.
> > +*/
> > +   spin_lock_irqsave(&net_device->sc_lock, flags);
> > +   sc_delta = net_device->num_chn - 1 - num_rss_qs;
> > +   net_device->num_sc_offered -= sc_delta;
> 
> Hi KY,
> IMO here the "-= " should be "+="?
> 
> I think sc_delta is usually <= 0, meaning the host may allocate less
> subchannels than
> we expect.
> With "-=", net_device->num_sc_offered can become bigger -- this doesn't
> seem correct.
We control how many sub-channels we want the host to offer (say sc_requested). 
Based on this
number we begin to track how many have actually been processed - we decrement 
sc_requested
each time a sub-channel offer is processed. If the host were to actually offer 
all that we have requested,
then checking for sc_requested to be zero is sufficient to ensure that we have 
processed all the
potentially in-flight sub-channels. However, the host  may choose to offer less 
than what we had asked for
and the variable "delta" is tracking this difference. Since we are counting 
down from what we had asked for
we have to subtract "delta" for proper accounting.
  
> 
> Why not use
> "net_device->num_sc_offered = net_device->num_chn - 1;" directly?
> At this point, net_device->num_chn has been the number of the actual
> channels.

I am not sure what the question here is. num_sc_offered is initialized to the 
number we
are going to ask and this is the number that will be decremented each time a 
sub-channel 
is processed. Since the host may decide to offer us less than what we had asked 
and some 
sub-channels may have already been processed (num_sc_offerred decremented 
accordingly)
by the time we discover that the host has offered us less than what we asked 
for, we adjust
num_sc_offered accordingly.

> 
> 
> > +   spin_unlock_irqrestore(&net_device->sc_lock, flags);
> > +
> > +   if (net_device->num_sc_offered != 0)
> > +   wait_for_completion(&net_device->channel_init_wait);
> 
> BTW, I also tested the patch and I can confirm the panic I saw disappeared
> with the patch.

Thank you.

K. Y
> 
> -- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 5/6] staging: rtl8188eu: stop using DBG_88E

[Jakub Sitnicki]

On Thu, Jul 16, 2015 at 01:28 PM CEST, Sudip Mukherjee 
 wrote:
> Stop using DBG_88E which is a custom macro for printing debugging
> messages. Instead start using pr_debug and in the process define
> pr_fmt.

In the end, don't we want to use netdev_dbg() everywhere where we work
with a struct net_device? And use dev_dbg() everywhere where we work
with a struct device (or a struct usb_interface)?

At least that's how I understand commit 8f26b8376faa ("checkpatch:
update suggested printk conversions") description:

Direct conversion of printk(KERN_...  to pr_ isn't the
preferred conversion when a struct net_device or struct device is
available.

Do you think it is worth going straight for netdev_dbg()/dev_dbg() to
avoid redoing it later?

>
> Signed-off-by: Sudip Mukherjee 
> ---
>  drivers/staging/rtl8188eu/os_dep/usb_intf.c | 39 
> +++--
>  1 file changed, 20 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c 
> b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> index 2d75c77..b245e9c 100644
> --- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> +++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
> @@ -19,6 +19,7 @@
>   
> **/
>  #define _HCI_INTF_C_
>  
> +#define pr_fmt(fmt) "R8188EU: " fmt
>  #include 
>  #include 
>  #include 

If we're going to stay with pr_debug(), using KBUILD_MODNAME seems to be
the convention among drivers when defining pr_fmt():

#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt

Cheers,
Jakub
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

[KY Srinivasan]

> -Original Message-
> From: Dexuan Cui
> Sent: Friday, July 17, 2015 3:07 AM
> To: KY Srinivasan; da...@davemloft.net; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; vkuzn...@redhat.com
> Cc: KY Srinivasan
> Subject: RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> processed during probe
> 
> > From: K. Y. Srinivasan
> > Sent: Friday, July 17, 2015 3:17
> > Subject: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> processed
> > during probe
> >
> > The current code returns from probe without waiting for the proper
> handling
> > of subchannels that may be requested. If the netvsc driver were to be
> rapidly
> > loaded/unloaded, we can  trigger a panic as the unload will be tearing
> > down state that may not have been fully setup yet. We fix this issue by
> making
> > sure that we return from the probe call only after ensuring that the
> > sub-channel offers in flight are properly handled.
> >
> > ---
> >  drivers/net/hyperv/hyperv_net.h   |2 ++
> >  drivers/net/hyperv/rndis_filter.c |   25 +
> >  2 files changed, 27 insertions(+), 0 deletions(-)
> 
> BTW, not sure if we should make the same fix to storvsc.
> 
> IMO storvsc should have the same issue, at least in theory, though usually 
> it's
> unlikely to unload storvsc.  :-)

You are right; I am planning to submit a similar patch for storvsc. As you note,
this scenario is unlikely for sorvsc.

K. Y
> 
> Thanks,
> -- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

[KY Srinivasan]

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Friday, July 17, 2015 7:13 AM
> To: KY Srinivasan
> Cc: da...@davemloft.net; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; Dexuan Cui
> Subject: Re: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> processed during probe
> 
> "K. Y. Srinivasan"  writes:
> 
> > The current code returns from probe without waiting for the proper
> handling
> > of subchannels that may be requested. If the netvsc driver were to be
> rapidly
> > loaded/unloaded, we can  trigger a panic as the unload will be tearing
> > down state that may not have been fully setup yet. We fix this issue by
> making
> > sure that we return from the probe call only after ensuring that the
> > sub-channel offers in flight are properly handled.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > Reviewed-and-tested-by: Haiyang Zhang  > ---
> >  drivers/net/hyperv/hyperv_net.h   |2 ++
> >  drivers/net/hyperv/rndis_filter.c |   25 +
> >  2 files changed, 27 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/hyperv/hyperv_net.h
> b/drivers/net/hyperv/hyperv_net.h
> > index 26cd14c..925b75d 100644
> > --- a/drivers/net/hyperv/hyperv_net.h
> > +++ b/drivers/net/hyperv/hyperv_net.h
> > @@ -671,6 +671,8 @@ struct netvsc_device {
> > u32 send_table[VRSS_SEND_TAB_SIZE];
> > u32 max_chn;
> > u32 num_chn;
> > +   spinlock_t sc_lock; /* Protects num_sc_offered variable */
> > +   u32 num_sc_offered;
> > atomic_t queue_sends[NR_CPUS];
> >
> > /* Holds rndis device info */
> > diff --git a/drivers/net/hyperv/rndis_filter.c
> b/drivers/net/hyperv/rndis_filter.c
> > index 2e40417..2e09f3f 100644
> > --- a/drivers/net/hyperv/rndis_filter.c
> > +++ b/drivers/net/hyperv/rndis_filter.c
> > @@ -984,9 +984,16 @@ static void netvsc_sc_open(struct vmbus_channel
> *new_sc)
> > struct netvsc_device *nvscdev;
> > u16 chn_index = new_sc->offermsg.offer.sub_channel_index;
> > int ret;
> > +   unsigned long flags;
> >
> > nvscdev = hv_get_drvdata(new_sc->primary_channel->device_obj);
> >
> > +   spin_lock_irqsave(&nvscdev->sc_lock, flags);
> > +   nvscdev->num_sc_offered--;
> > +   spin_unlock_irqrestore(&nvscdev->sc_lock, flags);
> > +   if (nvscdev->num_sc_offered == 0)
> > +   complete(&nvscdev->channel_init_wait);
> > +
> > if (chn_index >= nvscdev->num_chn)
> > return;
> >
> > @@ -1015,8 +1022,10 @@ int rndis_filter_device_add(struct hv_device
> *dev,
> > u32 rsscap_size = sizeof(struct ndis_recv_scale_cap);
> > u32 mtu, size;
> > u32 num_rss_qs;
> > +   u32 sc_delta;
> > const struct cpumask *node_cpu_mask;
> > u32 num_possible_rss_qs;
> > +   unsigned long flags;
> >
> > rndis_device = get_rndis_device();
> > if (!rndis_device)
> > @@ -1039,6 +1048,8 @@ int rndis_filter_device_add(struct hv_device
> *dev,
> > net_device->max_chn = 1;
> > net_device->num_chn = 1;
> >
> > +   spin_lock_init(&net_device->sc_lock);
> > +
> > net_device->extension = rndis_device;
> > rndis_device->net_dev = net_device;
> >
> > @@ -1116,6 +1127,9 @@ int rndis_filter_device_add(struct hv_device
> *dev,
> > num_possible_rss_qs = cpumask_weight(node_cpu_mask);
> > net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
> >
> > +   num_rss_qs = net_device->num_chn - 1;
> > +   net_device->num_sc_offered = num_rss_qs;
> > +
> > if (net_device->num_chn == 1)
> > goto out;
> >
> > @@ -1157,11 +1171,22 @@ int rndis_filter_device_add(struct hv_device
> *dev,
> >
> > ret = rndis_filter_set_rss_param(rndis_device, net_device-
> >num_chn);
> >
> > +   /*
> > +* Wait for the host to send us the sub-channel offers.
> > +*/
> > +   spin_lock_irqsave(&net_device->sc_lock, flags);
> > +   sc_delta = net_device->num_chn - 1 - num_rss_qs;
> > +   net_device->num_sc_offered -= sc_delta;
> > +   spin_unlock_irqrestore(&net_device->sc_lock, flags);
> > +
> > +   if (net_device->num_sc_offered != 0)
> > +   wait_for_completion(&net_device->channel_init_wait);
> 
> I'd suggest we add an essentian timeout (big, let's say 30 sec.)
> here. In case something goes wrong we don't really want to hang the
> whole kernel for forever. Such bugs are hard to debug as if a 'kernel
> hangs' is reported we can't be sure which wait caused it. We can even
> have something like:
> 
>  t = wait_for_completion_timeout(&net_device->channel_init_wait, 30*HZ);
>  BUG_ON(t == 0);
> 
> This is much better as we'll be sure what went wrong. (I know other
> pieces of hyper-v code use wait_for_completion() without a timeout, this
> is rather a general suggestion for all of them).

There is some history here. Initially, I had timeout for calls where we could 
reasonably
rollback state if we timed out. Some calls were subsequently changed to 
unconditional
wait bec

Re: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

[Vitaly Kuznetsov]

KY Srinivasan  writes:

>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Friday, July 17, 2015 7:13 AM
>> To: KY Srinivasan
>> Cc: da...@davemloft.net; net...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
>> a...@canonical.com; jasow...@redhat.com; Dexuan Cui
>> Subject: Re: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
>> processed during probe
>> 
>> "K. Y. Srinivasan"  writes:
>> 
>> > The current code returns from probe without waiting for the proper
>> handling
>> > of subchannels that may be requested. If the netvsc driver were to be
>> rapidly
>> > loaded/unloaded, we can  trigger a panic as the unload will be tearing
>> > down state that may not have been fully setup yet. We fix this issue by
>> making
>> > sure that we return from the probe call only after ensuring that the
>> > sub-channel offers in flight are properly handled.
>> >
>> > Signed-off-by: K. Y. Srinivasan 
>> > Reviewed-and-tested-by: Haiyang Zhang > > ---
>> >  drivers/net/hyperv/hyperv_net.h   |2 ++
>> >  drivers/net/hyperv/rndis_filter.c |   25 +
>> >  2 files changed, 27 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/drivers/net/hyperv/hyperv_net.h
>> b/drivers/net/hyperv/hyperv_net.h
>> > index 26cd14c..925b75d 100644
>> > --- a/drivers/net/hyperv/hyperv_net.h
>> > +++ b/drivers/net/hyperv/hyperv_net.h
>> > @@ -671,6 +671,8 @@ struct netvsc_device {
>> >u32 send_table[VRSS_SEND_TAB_SIZE];
>> >u32 max_chn;
>> >u32 num_chn;
>> > +  spinlock_t sc_lock; /* Protects num_sc_offered variable */
>> > +  u32 num_sc_offered;
>> >atomic_t queue_sends[NR_CPUS];
>> >
>> >/* Holds rndis device info */
>> > diff --git a/drivers/net/hyperv/rndis_filter.c
>> b/drivers/net/hyperv/rndis_filter.c
>> > index 2e40417..2e09f3f 100644
>> > --- a/drivers/net/hyperv/rndis_filter.c
>> > +++ b/drivers/net/hyperv/rndis_filter.c
>> > @@ -984,9 +984,16 @@ static void netvsc_sc_open(struct vmbus_channel
>> *new_sc)
>> >struct netvsc_device *nvscdev;
>> >u16 chn_index = new_sc->offermsg.offer.sub_channel_index;
>> >int ret;
>> > +  unsigned long flags;
>> >
>> >nvscdev = hv_get_drvdata(new_sc->primary_channel->device_obj);
>> >
>> > +  spin_lock_irqsave(&nvscdev->sc_lock, flags);
>> > +  nvscdev->num_sc_offered--;
>> > +  spin_unlock_irqrestore(&nvscdev->sc_lock, flags);
>> > +  if (nvscdev->num_sc_offered == 0)
>> > +  complete(&nvscdev->channel_init_wait);
>> > +
>> >if (chn_index >= nvscdev->num_chn)
>> >return;
>> >
>> > @@ -1015,8 +1022,10 @@ int rndis_filter_device_add(struct hv_device
>> *dev,
>> >u32 rsscap_size = sizeof(struct ndis_recv_scale_cap);
>> >u32 mtu, size;
>> >u32 num_rss_qs;
>> > +  u32 sc_delta;
>> >const struct cpumask *node_cpu_mask;
>> >u32 num_possible_rss_qs;
>> > +  unsigned long flags;
>> >
>> >rndis_device = get_rndis_device();
>> >if (!rndis_device)
>> > @@ -1039,6 +1048,8 @@ int rndis_filter_device_add(struct hv_device
>> *dev,
>> >net_device->max_chn = 1;
>> >net_device->num_chn = 1;
>> >
>> > +  spin_lock_init(&net_device->sc_lock);
>> > +
>> >net_device->extension = rndis_device;
>> >rndis_device->net_dev = net_device;
>> >
>> > @@ -1116,6 +1127,9 @@ int rndis_filter_device_add(struct hv_device
>> *dev,
>> >num_possible_rss_qs = cpumask_weight(node_cpu_mask);
>> >net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
>> >
>> > +  num_rss_qs = net_device->num_chn - 1;
>> > +  net_device->num_sc_offered = num_rss_qs;
>> > +
>> >if (net_device->num_chn == 1)
>> >goto out;
>> >
>> > @@ -1157,11 +1171,22 @@ int rndis_filter_device_add(struct hv_device
>> *dev,
>> >
>> >ret = rndis_filter_set_rss_param(rndis_device, net_device-
>> >num_chn);
>> >
>> > +  /*
>> > +   * Wait for the host to send us the sub-channel offers.
>> > +   */
>> > +  spin_lock_irqsave(&net_device->sc_lock, flags);
>> > +  sc_delta = net_device->num_chn - 1 - num_rss_qs;
>> > +  net_device->num_sc_offered -= sc_delta;
>> > +  spin_unlock_irqrestore(&net_device->sc_lock, flags);
>> > +
>> > +  if (net_device->num_sc_offered != 0)
>> > +  wait_for_completion(&net_device->channel_init_wait);
>> 
>> I'd suggest we add an essentian timeout (big, let's say 30 sec.)
>> here. In case something goes wrong we don't really want to hang the
>> whole kernel for forever. Such bugs are hard to debug as if a 'kernel
>> hangs' is reported we can't be sure which wait caused it. We can even
>> have something like:
>> 
>>  t = wait_for_completion_timeout(&net_device->channel_init_wait, 30*HZ);
>>  BUG_ON(t == 0);
>> 
>> This is much better as we'll be sure what went wrong. (I know other
>> pieces of hyper-v code use wait_for_completion() without a timeout, this
>> is rather a general suggestion for all of them).
>
> There is some history here. Initially, I had timeout for calls where we could 
> 

[PATCH v9 0/7] FPGA Manager Framework and Simple FPGA Bus

[atull]

From: Alan Tull 

This patchset adds two chunks plus documentation:
 * fpga manager core: exports ABI functions that write an image to a FPGA
 * DT Overlay support: simple-fpga-bus to handle FPGA from a DT overlay

The core's ABI is minimal to start with: only 6 functions.  This gives a
common interface for programming various FPGA such that any higher level
interfaces such as the DT Overlays or anything else that is added can be
shared and not be manufacturor-specific.

The DT Overlays support exists for the usage where the FPGA will contain
some "hardware" that will need drivers.  Where that use model is not
appealing, the core ABI can be used to add a different use model such as
using an FPGA as acceleration as has been discussed.

This patchset gets rid of the sysfs controls that allowed direct
control of a FPGA from userspace.

This patchset is under drivers/staging as the interface could change.

The bindings for the socpfga fpga manager already are upstreamed as
1b4e119 Alan Tull : doc: add bindings document for altera fpga manager

The DT Support is dependent on Pantelis's dtc overlay patches from
https://github.com/pantoniou/dtc.git
and his DT overlays configfs interface patches and fixes from
https://github.com/pantoniou/linux-beagle-track-mainline

efb0c04 Pantelis Antoniou : gcl: Fix resource linking
85e785e Pantelis Antoniou : ARM: DT: Enable symbols when CONFIG_OF_OVERLAY is 
used
af0321f Pantelis Antoniou : OF: DT-Overlay configfs interface (v5)
4c1c675 Pantelis Antoniou : configfs: Implement binary attributes (v4)


Alan Tull (7):
  staging: usage documentation for FPGA manager core
  staging: usage documentation for simple fpga bus
  staging: add bindings document for simple fpga bus
  staging: fpga manager: add sysfs interface document
  staging: fpga manager core
  staging: add simple-fpga-bus
  staging: fpga manager: add driver for socfpga fpga manager

 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 .../Documentation/ABI/sysfs-class-fpga-manager |   26 +
 .../Documentation/bindings/simple-fpga-bus.txt |   61 ++
 drivers/staging/fpga/Documentation/fpga-mgr.txt|  117 
 .../staging/fpga/Documentation/simple-fpga-bus.txt |   48 ++
 drivers/staging/fpga/Kconfig   |   31 +
 drivers/staging/fpga/Makefile  |   10 +
 drivers/staging/fpga/fpga-mgr.c|  373 
 drivers/staging/fpga/simple-fpga-bus.c |  323 ++
 drivers/staging/fpga/socfpga.c |  616 
 include/linux/fpga/fpga-mgr.h  |  127 
 12 files changed, 1735 insertions(+)
 create mode 100644 
drivers/staging/fpga/Documentation/ABI/sysfs-class-fpga-manager
 create mode 100644 
drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
 create mode 100644 drivers/staging/fpga/Documentation/fpga-mgr.txt
 create mode 100644 drivers/staging/fpga/Documentation/simple-fpga-bus.txt
 create mode 100644 drivers/staging/fpga/Kconfig
 create mode 100644 drivers/staging/fpga/Makefile
 create mode 100644 drivers/staging/fpga/fpga-mgr.c
 create mode 100644 drivers/staging/fpga/simple-fpga-bus.c
 create mode 100644 drivers/staging/fpga/socfpga.c
 create mode 100644 include/linux/fpga/fpga-mgr.h

-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v9 1/7] staging: usage documentation for FPGA manager core

[atull]

From: Alan Tull 

Add a document on the new FPGA manager core.

Signed-off-by: Alan Tull 
---
 drivers/staging/fpga/Documentation/fpga-mgr.txt |  117 +++
 1 file changed, 117 insertions(+)
 create mode 100644 drivers/staging/fpga/Documentation/fpga-mgr.txt

diff --git a/drivers/staging/fpga/Documentation/fpga-mgr.txt 
b/drivers/staging/fpga/Documentation/fpga-mgr.txt
new file mode 100644
index 000..b5b6ed4
--- /dev/null
+++ b/drivers/staging/fpga/Documentation/fpga-mgr.txt
@@ -0,0 +1,117 @@
+  FPGA Manager Core
+
+  Alan Tull 2015
+
+  Overview
+  
+The FPGA manager core exports a set of functions for programming an image to a
+FPGA.  All manufacturor specifics are hidden away in a low level driver.  The
+API is manufacturor agnostic.  Of course the FPGA image data itself is very
+manufacturor specific but for our purposes it's just data in a buffer or file
+or something.  The FPGA manager core won't parse it or know anything about it.
+
+
+  Files
+  -
+drivers/staging/fpga/fpga-mgr.c
+include/linux/fpga/fpga-mgr.h
+
+
+  The API Functions
+  
+The API that is exported is currently 6 functions:
+
+   int fpga_mgr_buf_load(struct fpga_manager *mgr,
+ u32 flags,
+ const char *buf,
+ size_t count);
+
+An FPGA image exists as a buffer in memory.  Load it into the FPGA.  The FPGA
+ends up in operating mode or return a negative error code.
+
+   int fpga_mgr_firmware_load(struct fpga_manager *mgr,
+  u32 flags,
+  const char *image_name);
+
+An FPGA image exists as a file that is on the firmware search path (see the
+firmware class documentation).  Load as above.
+
+   struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
+
+Given a DT node, get a reference to a fpga manager.
+
+   void fpga_mgr_put(struct fpga_manager *mgr);
+
+Release the reference to the fpga manager.
+
+   int fpga_mgr_register(struct device *dev,
+ const char *name,
+ const struct fpga_manager_ops *mops,
+ void *priv);
+   void fpga_mgr_unregister(struct device *dev);
+
+Register/unregister the lower level device specific driver.
+
+
+  How To Write an Image Buffer to a supported FPGA
+  
+/* device node that specifies the fpga manager to use */
+struct device_node *mgr_node;
+
+/* FPGA image is in this buffer.  count is size of buf. */
+char *buf;
+int count;
+int ret;
+
+struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
+ret = fpga_mgr_buf_load(mgr, flags, buf, count);
+fpga_mgr_put(mgr);
+
+
+  How To Write an Image File to a supported FPGA
+  
+/* device node that specifies the fpga manager to use */
+struct device_node *mgr_node;
+
+/* FPGA image is in this buffer.  count is size of buf. */
+const char *path = "fpga-image-9.rbf"
+int ret;
+
+struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
+ret = fpga_mgr_firmware_load(mgr, flags, path);
+fpga_mgr_put(mgr);
+
+
+  How To Support a new FPGA device
+  
+To add another fpga manager, look at the bottom part of socfpga.c for an
+example, starting with the declaration of socfpga_fpga_ops.
+
+static const struct fpga_manager_ops socfpga_fpga_ops = {
+   .write_init = socfpga_fpga_ops_configure_init,
+   .write = socfpga_fpga_ops_configure_write,
+   .write_complete = socfpga_fpga_ops_configure_complete,
+   .state = socfpga_fpga_ops_state,
+};
+
+You will want to create a platform driver that has a set of ops like that
+and then register it with fpga_mgr_register in your probe function.  Your
+ops will implement whatever device specific register writes needed and
+will return negative error codes if things don't go well.
+
+The programming seqence is:
+ 1. .write_init
+ 2. .write (may be called once or multiple times)
+ 3. .write_complete
+
+The .write_init function will prepare the FPGA to receive the image data.
+
+The .write function receives an image buffer or a chunk of the image and
+writes it the FPGA.  The buffer may arrive as one chunk or a bunck of
+small chunks through this function being called multiple times.
+
+The .write_complete function is called after all the image has been written
+to put the FPGA into operating mode.
+
+The .state function will read your hardware and return a code of type
+"enum fpga_mgr_states".  It doesn't result in a change in hardware state.
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v9 2/7] staging: usage documentation for simple fpga bus

[atull]

From: Alan Tull 

Add a document spelling out usage of the simple fpga bus.

Signed-off-by: Alan Tull 
---
 .../staging/fpga/Documentation/simple-fpga-bus.txt |   48 
 1 file changed, 48 insertions(+)
 create mode 100644 drivers/staging/fpga/Documentation/simple-fpga-bus.txt

diff --git a/drivers/staging/fpga/Documentation/simple-fpga-bus.txt 
b/drivers/staging/fpga/Documentation/simple-fpga-bus.txt
new file mode 100644
index 000..9df519f
--- /dev/null
+++ b/drivers/staging/fpga/Documentation/simple-fpga-bus.txt
@@ -0,0 +1,48 @@
+   Simple FPGA Bus
+
+   Alan Tull 2015
+
+   Overview
+   
+The simple FPGA bus adds device tree overlay support for FPGA's.  Loading a
+DT overlay will result in the FGPA getting an image loaded, its bridges will
+be released, and the DT populated for nodes below the simple-fpga-bus.  This
+results in drivers getting probed for the hardware that just got added.  This
+is intended to support the FPGA usage where the FPGA has hardware that
+requires drivers.  Removing the overlay will result in the drivers getting
+removed and the bridges being disabled.
+
+
+   Requirements
+   
+ 1. An FPGA image that has a hardware block or blocks that use drivers that are
+supported in the kernel.
+ 2. A device tree overlay.
+ 3. A FPGA manager driver supporting writing the FPGA.
+ 4. FPGA bridge resets supported as reset controllers.
+
+The DT overlay includes bindings (documented in bindings/simple-fpga-bus.txt)
+that specify:
+ * Which fpga manager to use
+ * Which image file to load
+ * Flags indicating whether this this image is for full reconfiguration or
+   partial.
+ * a list of resets that should be released.  These enable the FPGA bridges.
+ * child nodes specifying the devices that will be added with appropriate
+   compatible strings, etc.
+
+Since this code uses the firmware interface to get the image and DT overlay,
+they currently have to be files on the filesystem.  It doesn't have to be that
+way forever as DT bindings could be added to point to other sources for the
+image.
+
+
+   Sequence
+   
+ 1. Load the DT overlay.  One convenient way to do that is to use Pantelis'
+handy configfs interface (more below).
+ 2. The simple FPGA bus gets probed and will do the following:
+a. call the fpga manager core to program the FPGA
+b. release the FPGA bridges
+c. call of_platform_populate resulting in device drivers getting probed.
+
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v9 6/7] staging: add simple-fpga-bus

[atull]

From: Alan Tull 

Add simple fpga bus.  This is a bus that configures an fpga and its
bridges before populating the devices below it.  This is intended
for use with device tree overlays.

Note that FPGA bridges are seen as reset controllers so no special
framework for FPGA bridges will need to be added.

This supports fpga use where hardware blocks on a fpga will need
drivers (as opposed to fpga used as an acceleration without drivers.)

Signed-off-by: Alan Tull 
---
 drivers/staging/fpga/Kconfig   |   11 ++
 drivers/staging/fpga/Makefile  |1 +
 drivers/staging/fpga/simple-fpga-bus.c |  323 
 3 files changed, 335 insertions(+)
 create mode 100644 drivers/staging/fpga/simple-fpga-bus.c

diff --git a/drivers/staging/fpga/Kconfig b/drivers/staging/fpga/Kconfig
index 8254ca0..8d003e3 100644
--- a/drivers/staging/fpga/Kconfig
+++ b/drivers/staging/fpga/Kconfig
@@ -11,4 +11,15 @@ config FPGA
  kernel.  The FPGA framework adds a FPGA manager class and FPGA
  manager drivers.
 
+if FPGA
+
+config SIMPLE_FPGA_BUS
+   bool "Simple FPGA Bus"
+   depends on OF
+   help
+ Simple FPGA Bus allows loading FPGA images under control of
+Device Tree.
+
+endif # FPGA
+
 endmenu
diff --git a/drivers/staging/fpga/Makefile b/drivers/staging/fpga/Makefile
index 3313c52..6115213 100644
--- a/drivers/staging/fpga/Makefile
+++ b/drivers/staging/fpga/Makefile
@@ -4,5 +4,6 @@
 
 # Core FPGA Manager Framework
 obj-$(CONFIG_FPGA) += fpga-mgr.o
+obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
 
 # FPGA Manager Drivers
diff --git a/drivers/staging/fpga/simple-fpga-bus.c 
b/drivers/staging/fpga/simple-fpga-bus.c
new file mode 100644
index 000..bf178d8
--- /dev/null
+++ b/drivers/staging/fpga/simple-fpga-bus.c
@@ -0,0 +1,323 @@
+/*
+ * Simple FPGA Bus
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+/**
+ * struct simple_fpga_bus - simple fpga bus private data
+ * @dev:   device from pdev
+ * @mgr:   the fpga manager associated with this bus
+ * @bridges:   an array of reset controls for controlling FPGA bridges
+ * associated with this bus
+ * @num_bridges: size of the bridges array
+ */
+struct simple_fpga_bus {
+   struct device *dev;
+   struct fpga_manager *mgr;
+   struct reset_control **bridges;
+   int num_bridges;
+};
+
+/**
+ * simple_fpga_bus_get_mgr - get associated fpga manager
+ * @priv: simple fpga bus private data
+ * pointer to fpga manager in priv->mgr on success
+ *
+ * Given a simple fpga bus, get a reference to its the fpga manager specified
+ * by its "fpga-mgr" device tree property.
+ *
+ * Return: 0 if success or if the fpga manager is not specified.
+ * Negative error code otherwise.
+ */
+static int simple_fpga_bus_get_mgr(struct simple_fpga_bus *priv)
+{
+   struct device *dev = priv->dev;
+   struct device_node *np = dev->of_node;
+   struct fpga_manager *mgr;
+   struct device_node *mgr_node;
+
+   /*
+* Return 0 (not an error) if fpga manager is not specified.
+* This supports the case where fpga was already configured.
+*/
+   mgr_node = of_parse_phandle(np, "fpga-mgr", 0);
+   if (!mgr_node) {
+   dev_dbg(dev, "could not find fpga-mgr DT property\n");
+   return 0;
+   }
+
+   mgr = of_fpga_mgr_get(mgr_node);
+   if (IS_ERR(mgr))
+   return PTR_ERR(mgr);
+
+   priv->mgr = mgr;
+
+   return 0;
+}
+
+/**
+ * simple_fpga_bus_load_image - load an fpga image under device tree control
+ * @priv: simple fpga bus private data
+ *
+ * Given a simple fpga bus, load the fpga image specified in its device
+ * tree node.
+ *
+ * Return: 0 on success, negative error code otherwise.
+ */
+static int simple_fpga_bus_load_image(struct simple_fpga_bus *priv)
+{
+   struct device *dev = priv->dev;
+   struct device_node *np = dev->of_node;
+   struct fpga_manager *mgr = priv->mgr;
+   u32 flags = 0;
+   const char *path;
+
+   if (of_property_read_bool(np, "partial-reconfig"))
+   flags |= FPGA_MGR_PARTIAL_RECONFIG;
+
+   /* If firmware image is specified in the DT, load it */
+   if (!of_property_read_string(np, "fpga-firmware", &p

[PATCH v9 4/7] staging: fpga manager: add sysfs interface document

[atull]

From: Alan Tull 

Add documentation under drivers/staging for new fpga manager's
sysfs interface.

Signed-off-by: Alan Tull 
---
v5  : (actually second version, but keeping version numbers
  aligned with rest of patch series)
  Move document to drivers/staging/fpga/Documentation/ABI

v6  : No change in this patch for v6 of the patch set

v7  : No change in this patch for v7 of the patch set

v8  : No change in this patch for v8 of the patch set

v9  : Remove 'firmware' and 'reset' files
  Update state strings
---
 .../Documentation/ABI/sysfs-class-fpga-manager |   26 
 1 file changed, 26 insertions(+)
 create mode 100644 
drivers/staging/fpga/Documentation/ABI/sysfs-class-fpga-manager

diff --git a/drivers/staging/fpga/Documentation/ABI/sysfs-class-fpga-manager 
b/drivers/staging/fpga/Documentation/ABI/sysfs-class-fpga-manager
new file mode 100644
index 000..470905e
--- /dev/null
+++ b/drivers/staging/fpga/Documentation/ABI/sysfs-class-fpga-manager
@@ -0,0 +1,26 @@
+What:  /sys/class/fpga_manager//name
+Date:  July 2015
+KernelVersion: 4.2
+Contact:   Alan Tull 
+Description:   Name of low level fpga manager driver.
+
+What:  /sys/class/fpga_manager//state
+Date:  July 2015
+KernelVersion: 4.2
+Contact:   Alan Tull 
+Description:   Read fpga manager state as a string.
+   Valid states may vary by manufacturer; superset is:
+   * unknown   = can't determine state
+   * power off = FPGA power is off
+   * power up  = FPGA reports power is up
+   * reset = FPGA held in reset state
+   * firmware request  = firmware class request in progress
+   * firmware request error = firmware request failed
+   * write init= FPGA being prepared for programming
+   * write init error  = Error while preparing FPGA for
+ programming
+   * write = FPGA ready to receive image data
+   * write error   = Error while programming
+   * write complete= Doing post programming steps
+   * write complete error  = Error while doing post programming
+   * operating = FPGA is programmed and operating
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v9 5/7] staging: fpga manager core

[atull]

From: Alan Tull 

API to support programming FPGA.

The following functions are exported as GPL:
* fpga_mgr_buf_load
   Load fpga from image in buffer

* fpga_mgr_firmware_load
   Request firmware and load it to the FPGA.

* fpga_mgr_register
* fpga_mgr_unregister
   FPGA device drivers can be added by calling
   fpga_mgr_register() to register a set of
   fpga_manager_ops to do device specific stuff.

* of_fpga_mgr_get
* fpga_mgr_put
   Get/put a reference to a fpga manager.

The following sysfs files are created:
* /sys/class/fpga_manager//name
  Name of low level driver.

* /sys/class/fpga_manager//state
  State of fpga manager

Signed-off-by: Alan Tull 
Acked-by: Michal Simek 
---
v2: s/mangager/manager/
check for invalid request_nr
add fpga reset interface
rework the state code
remove FPGA_MGR_FAIL flag
add _ERR states to fpga manager states enum
low level state op now returns a state enum value
initialize framework state from driver state op
remove unused fpga read stuff
merge sysfs.c into fpga-mgr.c
move suspend/resume from bus.c to fpga-mgr.c

v3: Add struct device to fpga_manager (not as a pointer)
Add to_fpga_manager
Don't get irq in fpga-mgr.c (let low level driver do it)
remove from struct fpga_manager: nr, np, parent
get rid of fpga_mgr_get_new_minor()
simplify fpga_manager_register:
  reorder parameters
  use dev instead of pdev
get rid of code that used to make more sense when this
  was a char driver, don't alloc_chrdev_region
use a mutex instead of flags

v4: Move to drivers/staging

v5: Make some things be static
Kconfig: add 'if FPGA'
Makefile: s/fpga-mgr-core.o/fpga-mgr.o/
clean up includes
use enum fpga_mgr_states instead of int
static const char *state_str
use DEVICE_ATTR_RO/RW/WO and ATTRIBUTE_GROUPS
return -EINVAL instead of BUG_ON
move ida_simple_get after kzalloc
clean up fpga_mgr_remove
fpga-mgr.h: remove '#if IS_ENABLED(CONFIG_FPGA)'
add kernel-doc documentation
Move header to new include/linux/fpga folder
static const struct fpga_mgr_ops
dev_info msg simplified

v6: no statically allocated string for image_name
kernel doc fixes
changes regarding enabling SYSFS for fpga mgr
Makefile cleanup

v7: no change in this patch for v7 of the patchset

v8: no change in this patch for v8 of the patchset

v9: remove writable attributes 'firmware' and 'reset'
remove suspend/resume support for now
remove list of fpga managers; use class device iterators instead
simplify locking by giving out only one ref exclusively
add device tree support
add flags
par down API into fewer functions
update copyright year
rename some functions for clarity
clean up unnecessary #includes
add some error messages
write_init may need to look at buffer header, so add to params
---
 drivers/staging/Kconfig |2 +
 drivers/staging/Makefile|1 +
 drivers/staging/fpga/Kconfig|   14 ++
 drivers/staging/fpga/Makefile   |8 +
 drivers/staging/fpga/fpga-mgr.c |  373 +++
 include/linux/fpga/fpga-mgr.h   |  127 +
 6 files changed, 525 insertions(+)
 create mode 100644 drivers/staging/fpga/Kconfig
 create mode 100644 drivers/staging/fpga/Makefile
 create mode 100644 drivers/staging/fpga/fpga-mgr.c
 create mode 100644 include/linux/fpga/fpga-mgr.h

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 7f6cae5..89c089c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -112,4 +112,6 @@ source "drivers/staging/fsl-mc/Kconfig"
 
 source "drivers/staging/wilc1000/Kconfig"
 
+source "drivers/staging/fpga/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 347f647..e129940 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -48,3 +48,4 @@ obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clocking-wizard/
 obj-$(CONFIG_FB_TFT)   += fbtft/
 obj-$(CONFIG_FSL_MC_BUS)   += fsl-mc/
 obj-$(CONFIG_WILC1000) += wilc1000/
+obj-$(CONFIG_FPGA) += fpga/
diff --git a/drivers/staging/fpga/Kconfig b/drivers/staging/fpga/Kconfig
new file mode 100644
index 000..8254ca0
--- /dev/null
+++ b/drivers/staging/fpga/Kconfig
@@ -0,0 +1,14 @@
+#
+# FPGA framework configuration
+#
+
+menu "FPGA Configuration Support"
+
+config FPGA
+   bool "FPGA Configuration Framework"
+   help
+ Say Y here if you want support for configuring FPGAs from the
+ kernel.  The FPGA framework adds a FPGA manager class and FPGA
+ manager drivers.
+
+endmenu
diff --git a/drivers/staging/fpga/Makefile b/drivers/staging/fpga/Makefile
new file mode 100644
index 000..3313c52
--- /dev/null
+++ b/drivers/staging/fpga/Makefile
@@ -0,0 +1,8 @@
+#
+# Makefile for the fpga framework and fpga manager drivers.
+#
+
+# Core FPGA Manager Framework
+obj-$(CONFIG_FPGA)   

[PATCH v9 3/7] staging: add bindings document for simple fpga bus

[atull]

From: Alan Tull 

New bindings document for simple fpga bus.

Signed-off-by: Alan Tull 
---
 .../Documentation/bindings/simple-fpga-bus.txt |   61 
 1 file changed, 61 insertions(+)
 create mode 100644 
drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt

diff --git a/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt 
b/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
new file mode 100644
index 000..221e781
--- /dev/null
+++ b/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
@@ -0,0 +1,61 @@
+Simple FPGA Bus
+===
+
+A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
+before populating the devices below its node.
+
+Required properties:
+- compatible : should contain "simple-fpga-bus"
+- #address-cells, #size-cells, ranges: must be present to handle address space
+  mapping for children.
+
+Optional properties:
+- fpga-mgr : should contain a phandle to a fpga manager.
+- fpga-firmware : should contain the name of a fpga image file located on the
+  firmware search path.
+- partial-reconfig : boolean property should be defined if partial
+  reconfiguration is to be done.
+- resets : should contain a list of resets that should be released after the
+  fpga has been programmed i.e. fpga bridges.
+- reset-names : should contain a list of the names of the resets.
+
+Example:
+
+/dts-v1/;
+/plugin/;
+/ {
+   fragment@0 {
+   target-path="/soc";
+   __overlay__ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   bridge@0xff20 {
+   compatible = "simple-fpga-bus";
+   #address-cells = <0x2>;
+   #size-cells = <0x1>;
+   ranges = <0x1 0x10040 0xff210040 0x20>;
+
+   clocks = <0x2 0x2>;
+   clock-names = "h2f_lw_axi_clock", 
"f2h_sdram0_clock";
+
+   fpga-mgr = <&hps_0_fpgamgr>;
+   fpga-firmware = "soc_system.rbf";
+
+   resets = <&hps_fpgabridge0 0>, 
<&hps_fpgabridge1 0>, <&hps_fpgabridge2 0>;
+   reset-names = "hps2fpga", "lwhps2fpga", 
"fpga2hps";
+
+   gpio@0x100010040 {
+   compatible = "altr,pio-14.0", 
"altr,pio-1.0";
+   reg = <0x1 0x10040 0x20>;
+   clocks = <0x2>;
+   altr,gpio-bank-width = <0x4>;
+   resetvalue = <0x0>;
+   #gpio-cells = <0x2>;
+   gpio-controller;
+   };
+   };
+   };
+   };
+};
+
-- 
1.7.9.5

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v9 7/7] staging: fpga manager: add driver for socfpga fpga manager

[atull]

From: Alan Tull 

Add driver to fpga manager framework to allow configuration
of FPGA in Altera SoCFPGA parts.

Signed-off-by: Alan Tull 
Acked-by: Michal Simek 
---
v2: fpga_manager struct now contains struct device
fpga_manager_register parameters now take device

v3: skip a version to align versions

v4: move to drivers/staging

v5: fix array_size.cocci warnings
fix platform_no_drv_owner.cocci warnings
Remove .owner = THIS_MODULE
include asm/irq.h
clean up list of includes
use altera_fpga_reset for ops
use enum fpga_mgr_states or u32 as needed
use devm_request_irq
check irq <= 0 instead of == NO_IRQ
Use ARRAY_SIZE
rename altera -> socfpga
static const socfpga_fpga_ops
header moved to linux/fpga/ folder
remove ifdef'ed code
use platform_get_resource and platform_get_irq
move .probe and .remove lines adjacent
use module_platform_driver
use __maybe_unused
only need to 'if (IS_ENABLED(CONFIG_REGULATOR))' in one fn
fix "unsigned 'mode' is never < 0"

v6: return error for (unused) default of case statement

v7: PTR_ERR should access the value just tested by IS_ERR

v8: change compatible string to be more chip specific

v9: update copyright year
remove suspend/resume support and regulators
use updated fn names for register/unregister
use updated params for write_init
check for partial reconfiguration request
---
 drivers/staging/fpga/Kconfig   |6 +
 drivers/staging/fpga/Makefile  |1 +
 drivers/staging/fpga/socfpga.c |  616 
 3 files changed, 623 insertions(+)
 create mode 100644 drivers/staging/fpga/socfpga.c

diff --git a/drivers/staging/fpga/Kconfig b/drivers/staging/fpga/Kconfig
index 8d003e3..36dd7b6 100644
--- a/drivers/staging/fpga/Kconfig
+++ b/drivers/staging/fpga/Kconfig
@@ -13,6 +13,12 @@ config FPGA
 
 if FPGA
 
+config FPGA_MGR_SOCFPGA
+   bool "Altera SOCFPGA FPGA Manager"
+   depends on ARCH_SOCFPGA
+   help
+ FPGA manager driver support for Altera SOCFPGA.
+
 config SIMPLE_FPGA_BUS
bool "Simple FPGA Bus"
depends on OF
diff --git a/drivers/staging/fpga/Makefile b/drivers/staging/fpga/Makefile
index 6115213..d1f9406 100644
--- a/drivers/staging/fpga/Makefile
+++ b/drivers/staging/fpga/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
 
 # FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
diff --git a/drivers/staging/fpga/socfpga.c b/drivers/staging/fpga/socfpga.c
new file mode 100644
index 000..38276f9
--- /dev/null
+++ b/drivers/staging/fpga/socfpga.c
@@ -0,0 +1,616 @@
+/*
+ * FPGA Manager Driver for Altera SOCFPGA
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+
+/* Register offsets */
+#define SOCFPGA_FPGMGR_STAT_OFST   0x0
+#define SOCFPGA_FPGMGR_CTL_OFST0x4
+#define SOCFPGA_FPGMGR_DCLKCNT_OFST0x8
+#define SOCFPGA_FPGMGR_DCLKSTAT_OFST   0xc
+#define SOCFPGA_FPGMGR_GPIO_INTEN_OFST 0x830
+#define SOCFPGA_FPGMGR_GPIO_INTMSK_OFST0x834
+#define SOCFPGA_FPGMGR_GPIO_INTTYPE_LEVEL_OFST 0x838
+#define SOCFPGA_FPGMGR_GPIO_INT_POL_OFST   0x83c
+#define SOCFPGA_FPGMGR_GPIO_INTSTAT_OFST   0x840
+#define SOCFPGA_FPGMGR_GPIO_RAW_INTSTAT_OFST   0x844
+#define SOCFPGA_FPGMGR_GPIO_PORTA_EOI_OFST 0x84c
+#define SOCFPGA_FPGMGR_GPIO_EXT_PORTA_OFST 0x850
+
+/* Register bit defines */
+/* SOCFPGA_FPGMGR_STAT register mode field values */
+#define SOCFPGA_FPGMGR_STAT_POWER_UP   0x0 /*ramping*/
+#define SOCFPGA_FPGMGR_STAT_RESET  0x1
+#define SOCFPGA_FPGMGR_STAT_CFG0x2
+#define SOCFPGA_FPGMGR_STAT_INIT   0x3
+#define SOCFPGA_FPGMGR_STAT_USER_MODE  0x4
+#define SOCFPGA_FPGMGR_STAT_UNKNOWN0x5
+#define SOCFPGA_FPGMGR_STAT_STATE_MASK 0x7
+/*

RE: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be processed during probe

[KY Srinivasan]

> -Original Message-
> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> Sent: Friday, July 17, 2015 9:10 AM
> To: KY Srinivasan
> Cc: da...@davemloft.net; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonical.com; jasow...@redhat.com; Dexuan Cui
> Subject: Re: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> processed during probe
> 
> KY Srinivasan  writes:
> 
> >> -Original Message-
> >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
> >> Sent: Friday, July 17, 2015 7:13 AM
> >> To: KY Srinivasan
> >> Cc: da...@davemloft.net; net...@vger.kernel.org; linux-
> >> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> >> a...@canonical.com; jasow...@redhat.com; Dexuan Cui
> >> Subject: Re: [PATCH net-next 1/1] hv_netvsc: Wait for sub-channels to be
> >> processed during probe
> >>
> >> "K. Y. Srinivasan"  writes:
> >>
> >> > The current code returns from probe without waiting for the proper
> >> handling
> >> > of subchannels that may be requested. If the netvsc driver were to be
> >> rapidly
> >> > loaded/unloaded, we can  trigger a panic as the unload will be tearing
> >> > down state that may not have been fully setup yet. We fix this issue by
> >> making
> >> > sure that we return from the probe call only after ensuring that the
> >> > sub-channel offers in flight are properly handled.
> >> >
> >> > Signed-off-by: K. Y. Srinivasan 
> >> > Reviewed-and-tested-by: Haiyang Zhang  >> > ---
> >> >  drivers/net/hyperv/hyperv_net.h   |2 ++
> >> >  drivers/net/hyperv/rndis_filter.c |   25 +
> >> >  2 files changed, 27 insertions(+), 0 deletions(-)
> >> >
> >> > diff --git a/drivers/net/hyperv/hyperv_net.h
> >> b/drivers/net/hyperv/hyperv_net.h
> >> > index 26cd14c..925b75d 100644
> >> > --- a/drivers/net/hyperv/hyperv_net.h
> >> > +++ b/drivers/net/hyperv/hyperv_net.h
> >> > @@ -671,6 +671,8 @@ struct netvsc_device {
> >> >  u32 send_table[VRSS_SEND_TAB_SIZE];
> >> >  u32 max_chn;
> >> >  u32 num_chn;
> >> > +spinlock_t sc_lock; /* Protects num_sc_offered variable */
> >> > +u32 num_sc_offered;
> >> >  atomic_t queue_sends[NR_CPUS];
> >> >
> >> >  /* Holds rndis device info */
> >> > diff --git a/drivers/net/hyperv/rndis_filter.c
> >> b/drivers/net/hyperv/rndis_filter.c
> >> > index 2e40417..2e09f3f 100644
> >> > --- a/drivers/net/hyperv/rndis_filter.c
> >> > +++ b/drivers/net/hyperv/rndis_filter.c
> >> > @@ -984,9 +984,16 @@ static void netvsc_sc_open(struct
> vmbus_channel
> >> *new_sc)
> >> >  struct netvsc_device *nvscdev;
> >> >  u16 chn_index = new_sc->offermsg.offer.sub_channel_index;
> >> >  int ret;
> >> > +unsigned long flags;
> >> >
> >> >  nvscdev = hv_get_drvdata(new_sc->primary_channel->device_obj);
> >> >
> >> > +spin_lock_irqsave(&nvscdev->sc_lock, flags);
> >> > +nvscdev->num_sc_offered--;
> >> > +spin_unlock_irqrestore(&nvscdev->sc_lock, flags);
> >> > +if (nvscdev->num_sc_offered == 0)
> >> > +complete(&nvscdev->channel_init_wait);
> >> > +
> >> >  if (chn_index >= nvscdev->num_chn)
> >> >  return;
> >> >
> >> > @@ -1015,8 +1022,10 @@ int rndis_filter_device_add(struct hv_device
> >> *dev,
> >> >  u32 rsscap_size = sizeof(struct ndis_recv_scale_cap);
> >> >  u32 mtu, size;
> >> >  u32 num_rss_qs;
> >> > +u32 sc_delta;
> >> >  const struct cpumask *node_cpu_mask;
> >> >  u32 num_possible_rss_qs;
> >> > +unsigned long flags;
> >> >
> >> >  rndis_device = get_rndis_device();
> >> >  if (!rndis_device)
> >> > @@ -1039,6 +1048,8 @@ int rndis_filter_device_add(struct hv_device
> >> *dev,
> >> >  net_device->max_chn = 1;
> >> >  net_device->num_chn = 1;
> >> >
> >> > +spin_lock_init(&net_device->sc_lock);
> >> > +
> >> >  net_device->extension = rndis_device;
> >> >  rndis_device->net_dev = net_device;
> >> >
> >> > @@ -1116,6 +1127,9 @@ int rndis_filter_device_add(struct hv_device
> >> *dev,
> >> >  num_possible_rss_qs = cpumask_weight(node_cpu_mask);
> >> >  net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
> >> >
> >> > +num_rss_qs = net_device->num_chn - 1;
> >> > +net_device->num_sc_offered = num_rss_qs;
> >> > +
> >> >  if (net_device->num_chn == 1)
> >> >  goto out;
> >> >
> >> > @@ -1157,11 +1171,22 @@ int rndis_filter_device_add(struct hv_device
> >> *dev,
> >> >
> >> >  ret = rndis_filter_set_rss_param(rndis_device, net_device-
> >> >num_chn);
> >> >
> >> > +/*
> >> > + * Wait for the host to send us the sub-channel offers.
> >> > + */
> >> > +spin_lock_irqsave(&net_device->sc_lock, flags);
> >> > +sc_delta = net_device->num_chn - 1 - num_rss_qs;
> >> > 

Re: [PATCH] staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable

[Jon Medhurst (Tixy)]

On Fri, 2015-07-17 at 16:21 +0100, Robin Murphy wrote:
> This also begs the question as to what happens if the memory region _is_
> > contiguous but is in highmem or an ioremapped region. Should a device
> > always provide dma_ops for that case? Because I believe the current
> > implementation of dma_common_get_sgtable won't work for those as it uses
> > virt_to_page.
> >
> > I see that this point has been raised before [1] by Zeng Tao, and I
> > myself have been given a different fix to apply to a Linaro kernel tree.
> > However, both solutions looked wrong to me as they treat a dma_addr_t as
> > a physical address, so should at least be using dma_to_phys.
> > So, should we fix dma_common_get_sgtable or mandate that the device
> > has dma_ops? The latter seems to be implied by the commit message which
> > introduced the function:
> >
> >  This patch provides a generic implementation based on
> >  virt_to_page() call. Architectures which require more
> >  sophisticated translation might provide their own get_sgtable()
> >  methods.
> 
> Given that we're largely here due to having poked this on arm64 systems, 
> I'm inclined to think that implementing our own get_sgtable as per 
> arch/arm is the right course of action. Since a lot of architectures 
> using dma_common_get_sgtable don't even implement dma_to_phys,

I had another check and that seems to be true.

>  I don't 
> think it would be right to try complicating the common code for a case 
> that seems to be all but common.

I'm inclined to agree, however I'm rather new to this area.

>  I can spin an arm64 patch if you like.

That would be good. Especially as from what I see on the arm kernel
lists you are already working in that area... And my inbox has just
pinged with that patch from you, so I'll add a reference here [2] so
people coming across this thread can find it easily.

For 32-bit arm my $subject patch should fix ION as that already has the
DMA ops.

-- 
Tixy

[1] https://lkml.org/lkml/2014/12/1/584
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/357561.html


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: ion: ion_cma_heap: Don't directly use dma_common_get_sgtable

[Laura Abbott]

On 07/17/2015 08:21 AM, Robin Murphy wrote:

Hi Tixy,

On 17/07/15 12:01, Jon Medhurst (Tixy) wrote:

Use dma_get_sgtable rather than dma_common_get_sgtable so a device's
dma_ops aren't bypassed. This is essential in situations where a device
uses an IOMMU and the physical memory is not contiguous (as the common
function assumes).

Signed-off-by: Jon Medhurst 


The lack of obvious users of this code makes it hard to tell if "dev"
 hereis always the right, real, device pointer and never null or some
 dummy device with the wrong dma_ops, but the rest of the calls in this
 file are to the proper DMA API interface so at least this patch definitely
 makes things less wrong in that respect.




Ion currently lacks any standard way to set up heaps and associate a device
with a heap. This means it's basically a free for all for what devices get
associated (getting something mainlined might help...). I agree that using
the proper DMA APIs is a step in the right direction.



Reviewed-by: Robin Murphy 


---

This also begs the question as to what happens if the memory region _is_
contiguous but is in highmem or an ioremapped region. Should a device
always provide dma_ops for that case? Because I believe the current
implementation of dma_common_get_sgtable won't work for those as it uses
virt_to_page.

I see that this point has been raised before [1] by Zeng Tao, and I
myself have been given a different fix to apply to a Linaro kernel tree.
However, both solutions looked wrong to me as they treat a dma_addr_t as
a physical address, so should at least be using dma_to_phys.
So, should we fix dma_common_get_sgtable or mandate that the device
has dma_ops? The latter seems to be implied by the commit message which
introduced the function:

 This patch provides a generic implementation based on
 virt_to_page() call. Architectures which require more
 sophisticated translation might provide their own get_sgtable()
 methods.


Given that we're largely here due to having poked this on arm64 systems,
 I'm inclined to think that implementing our own get_sgtable as per arch/arm
 is the right course of action. Since a lot of architectures using
 dma_common_get_sgtable don't even implement dma_to_phys, I don't think it
 would be right to try complicating the common code for a case that seems to
 be all but common. I can spin an arm64 patch if you like.



This would be hit on any system that has non-coherent DMA or highmem. I'm
not sure I agree this isn't a common case. How many of the other
architectures are actually using the dma_get_sgtable and would have the
potential to find a problem?

Thanks,
Laura

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] staging: sm7xxfb: move sm712fb out of staging

[Greg Kroah-Hartman]

On Fri, Jul 17, 2015 at 06:51:18PM +0530, Sudip Mukherjee wrote:
> Now since all cleanups are done and the code is ready to be merged lets
> move it out of staging into fbdev location.

This is really hard for the fbdev developers to review.  Care to just
make up a single patch that adds the driver to the tree in that location
so they can read the code and review it?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v9 5/7] staging: fpga manager core

[Randy Dunlap]

On 07/17/15 08:51, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> ---
>  drivers/staging/Kconfig |2 +
>  drivers/staging/Makefile|1 +
>  drivers/staging/fpga/Kconfig|   14 ++
>  drivers/staging/fpga/Makefile   |8 +
>  drivers/staging/fpga/fpga-mgr.c |  373 
> +++
>  include/linux/fpga/fpga-mgr.h   |  127 +
>  6 files changed, 525 insertions(+)
>  create mode 100644 drivers/staging/fpga/Kconfig
>  create mode 100644 drivers/staging/fpga/Makefile
>  create mode 100644 drivers/staging/fpga/fpga-mgr.c
>  create mode 100644 include/linux/fpga/fpga-mgr.h

> diff --git a/drivers/staging/fpga/Kconfig b/drivers/staging/fpga/Kconfig
> new file mode 100644
> index 000..8254ca0
> --- /dev/null
> +++ b/drivers/staging/fpga/Kconfig
> @@ -0,0 +1,14 @@
> +#
> +# FPGA framework configuration
> +#
> +
> +menu "FPGA Configuration Support"
> +
> +config FPGA
> + bool "FPGA Configuration Framework"
> + help
> +   Say Y here if you want support for configuring FPGAs from the
> +   kernel.  The FPGA framework adds a FPGA manager class and FPGA
> +   manager drivers.
> +
> +endmenu

Is there some good reason why this is 'bool' instead of 'tristate'?
I.e., why can't it be built as a loadable module?

Thanks.

-- 
~Randy
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v9 0/7] FPGA Manager Framework and Simple FPGA Bus

[Jason Gunthorpe]

On Fri, Jul 17, 2015 at 10:51:10AM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> This patchset adds two chunks plus documentation:
>  * fpga manager core: exports ABI functions that write an image to a FPGA
>  * DT Overlay support: simple-fpga-bus to handle FPGA from a DT overlay

I didn't read super closely, but overall it makes sense to me..

Providing an in-kernel API will let someone else figure out how to
expose that to user space. The DT based scheme seems pretty nice.

Can you use this without DT overlay? Ie if I provide the FGPA
description as part of my boot time DT will it just work?

Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[GIT PULL] Staging driver fixes for 4.2-rc3

[Greg KH]

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

  Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-4.2-rc3

for you to fetch changes up to d309509f84725f99326cc73d3b00aae096b374ae:

  staging: vt6656: check ieee80211_bss_conf bssid not NULL (2015-07-14 19:34:57 
-0700)


Staging/IIO driver fixes for 4.2-rc3

Here's some staging and IIO driver fixes for 4.2-rc3.

Nothing major, the majority are IIO issues that were reported, with a
few other minor staging driver fixes.  All have been in linux-next for a
while with no reported issues.

Signed-off-by: Greg Kroah-Hartman 


Adriana Reus (1):
  iio: inv-mpu: Specify the expected format/precision for write channels

Daniel Baluta (2):
  iio: ABI: Clarify proximity output value
  iio: proximity: sx9500: Fix proximity value

Fabio Estevam (1):
  iio: twl4030-madc: Pass the IRQF_ONESHOT flag

Geert Uytterhoeven (1):
  iio: sx9500: Add missing init in sx9500_buffer_pre{en,dis}able()

Greg Kroah-Hartman (2):
  Merge tag 'iio-fixes-for-4.2a' of git://git.kernel.org/.../jic23/iio into 
staging-linus
  Merge tag 'iio-fixes-for-4.2b' of git://git.kernel.org/.../jic23/iio into 
staging-linus

Hartmut Knaack (6):
  iio:light:cm3323: clear bitmask before set
  iio:accel:bmc150-accel: fix counting direction
  iio:adc:cc10001_adc: fix Kconfig dependency
  iio:light:stk3310: Fix REGMAP_I2C dependency
  iio:light:ltr501: fix variable in ltr501_init
  iio:light:ltr501: fix regmap dependency

Heiko Stuebner (1):
  iio: adc: rockchip_saradc: add missing MODULE_* data

JM Friedt (1):
  iio: DAC: ad5624r_spi: fix bit shift of output data value

James Simmons (1):
  staging:lustre: remove irq.h from socklnd.h

Jan Leupold (1):
  iio: adc: at91_adc: allow to use full range of startup time

Malcolm Priestley (2):
  staging: vt6655: check ieee80211_bss_conf bssid not NULL
  staging: vt6656: check ieee80211_bss_conf bssid not NULL

Paul Gortmaker (1):
  staging: make board support depend on OF_IRQ and CLKDEV_LOOKUP

Peter Meerwald (2):
  iio: light: tcs3414: Fix bug preventing to set integration time
  iio: tmp006: Check channel info on write

Srinivas Pandruvada (1):
  hid-sensor: Fix suspend/resume delay

Teodora Baluta (1):
  iio: magnetometer: mmc35240: fix available sampling frequencies

Tiberiu Breana (1):
  iio: light: STK3310: un-invert proximity values

Vlad Dogaru (2):
  iio: sx9500: rework error handling of raw readings
  iio: sx9500: fix bug in compensation code

 Documentation/ABI/testing/sysfs-bus-iio|  6 +--
 drivers/iio/accel/bmc150-accel.c   |  2 +-
 drivers/iio/adc/Kconfig|  3 +-
 drivers/iio/adc/at91_adc.c |  8 ++--
 drivers/iio/adc/rockchip_saradc.c  |  4 ++
 drivers/iio/adc/twl4030-madc.c |  3 +-
 .../iio/common/hid-sensors/hid-sensor-trigger.c| 11 -
 drivers/iio/dac/ad5624r_spi.c  |  4 +-
 drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 18 
 drivers/iio/light/Kconfig  |  2 +
 drivers/iio/light/cm3323.c |  2 +-
 drivers/iio/light/ltr501.c |  2 +-
 drivers/iio/light/stk3310.c| 53 +++---
 drivers/iio/light/tcs3414.c|  2 +-
 drivers/iio/magnetometer/mmc35240.c| 35 --
 drivers/iio/proximity/sx9500.c | 28 ++--
 drivers/iio/temperature/tmp006.c   |  3 ++
 drivers/staging/board/Kconfig  |  2 +-
 .../staging/lustre/lnet/klnds/socklnd/socklnd.h|  1 -
 drivers/staging/vt6655/device_main.c   |  2 +-
 drivers/staging/vt6656/main_usb.c  |  2 +-
 include/linux/hid-sensor-hub.h |  1 +
 22 files changed, 109 insertions(+), 85 deletions(-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v9 0/7] FPGA Manager Framework and Simple FPGA Bus

[atull]

On Fri, 17 Jul 2015, Jason Gunthorpe wrote:

> On Fri, Jul 17, 2015 at 10:51:10AM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > This patchset adds two chunks plus documentation:
> >  * fpga manager core: exports ABI functions that write an image to a FPGA
> >  * DT Overlay support: simple-fpga-bus to handle FPGA from a DT overlay
> 
> I didn't read super closely, but overall it makes sense to me..
> 
> Providing an in-kernel API will let someone else figure out how to
> expose that to user space. The DT based scheme seems pretty nice.
> 

Thanks!

> Can you use this without DT overlay? Ie if I provide the FGPA
> description as part of my boot time DT will it just work?

The simple fpga bus would need to defer probing until after the fpga 
manager driver and bridge drivers are probed (that's easy).  Since it is 
using firmware, it will also have to defer until the filesystem is 
available so it can get the fpga image to load.  I'll work on it.

Alan

> 
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v9 5/7] staging: fpga manager core

[atull]

On Fri, 17 Jul 2015, Randy Dunlap wrote:

> On 07/17/15 08:51, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > ---
> >  drivers/staging/Kconfig |2 +
> >  drivers/staging/Makefile|1 +
> >  drivers/staging/fpga/Kconfig|   14 ++
> >  drivers/staging/fpga/Makefile   |8 +
> >  drivers/staging/fpga/fpga-mgr.c |  373 
> > +++
> >  include/linux/fpga/fpga-mgr.h   |  127 +
> >  6 files changed, 525 insertions(+)
> >  create mode 100644 drivers/staging/fpga/Kconfig
> >  create mode 100644 drivers/staging/fpga/Makefile
> >  create mode 100644 drivers/staging/fpga/fpga-mgr.c
> >  create mode 100644 include/linux/fpga/fpga-mgr.h
> 
> > diff --git a/drivers/staging/fpga/Kconfig b/drivers/staging/fpga/Kconfig
> > new file mode 100644
> > index 000..8254ca0
> > --- /dev/null
> > +++ b/drivers/staging/fpga/Kconfig
> > @@ -0,0 +1,14 @@
> > +#
> > +# FPGA framework configuration
> > +#
> > +
> > +menu "FPGA Configuration Support"
> > +
> > +config FPGA
> > +   bool "FPGA Configuration Framework"
> > +   help
> > + Say Y here if you want support for configuring FPGAs from the
> > + kernel.  The FPGA framework adds a FPGA manager class and FPGA
> > + manager drivers.
> > +
> > +endmenu
> 
> Is there some good reason why this is 'bool' instead of 'tristate'?
> I.e., why can't it be built as a loadable module?

Hi Randy,

The simple fpga bus probe function will need probe deferral added for it to
work with that if it gets probed before the fpga manager is loaded.  But I 
think it needed that anyway.  I'll work on it.

Thanks,
Alan


> 
> Thanks.
> 
> -- 
> ~Randy
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 00/23] staging: rtl8192e: Various cleanups

[Mateusz Kulikowski]

On 16.07.2015 11:58, Dan Carpenter wrote:
> On Tue, Jul 14, 2015 at 10:04:03PM +0200, Mateusz Kulikowski wrote:
>> This series does some more cleanup for driver.
>>
>> Changes in V2:
>> - Added patch 6/23 (Remove rtllib_stats structure as suggested by Dan)
>> - Updated patch 22/23 (remove whitespace - hint by Sudip)
>> - Rebased into current staging next (6fdb302c)
>> - Retested
> 
> Was there really a need to redo this patch?  The things that Sudip and I
> mentioned could have been done in follow on patches.
> 
> It's slightly easier for me to just review the follow on patches instead
> of looking at a whole patchset.

Ok, I'll keep that in mind for next patches.

Regards,
Mateusz

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v9 3/7] staging: add bindings document for simple fpga bus

[Steffen Trumtrar]

Hi!

On Fri, Jul 17, 2015 at 10:51:13AM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> New bindings document for simple fpga bus.
> 
> Signed-off-by: Alan Tull 
> ---
>  .../Documentation/bindings/simple-fpga-bus.txt |   61 
> 
>  1 file changed, 61 insertions(+)
>  create mode 100644 
> drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
> 
> diff --git a/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt 
> b/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
> new file mode 100644
> index 000..221e781
> --- /dev/null
> +++ b/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
> @@ -0,0 +1,61 @@
> +Simple FPGA Bus
> +===
> +
> +A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
> +before populating the devices below its node.
> +
> +Required properties:
> +- compatible : should contain "simple-fpga-bus"
> +- #address-cells, #size-cells, ranges: must be present to handle address 
> space
> +  mapping for children.
> +
> +Optional properties:
> +- fpga-mgr : should contain a phandle to a fpga manager.
> +- fpga-firmware : should contain the name of a fpga image file located on the
> +  firmware search path.
> +- partial-reconfig : boolean property should be defined if partial
> +  reconfiguration is to be done.
> +- resets : should contain a list of resets that should be released after the
> +  fpga has been programmed i.e. fpga bridges.
> +- reset-names : should contain a list of the names of the resets.
> +
> +Example:
> +
> +/dts-v1/;
> +/plugin/;
> +/ {
> + fragment@0 {
> + target-path="/soc";
> + __overlay__ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bridge@0xff20 {
> + compatible = "simple-fpga-bus";
> + #address-cells = <0x2>;
> + #size-cells = <0x1>;
> + ranges = <0x1 0x10040 0xff210040 0x20>;
> +
> + clocks = <0x2 0x2>;
> + clock-names = "h2f_lw_axi_clock", 
> "f2h_sdram0_clock";
> +
> + fpga-mgr = <&hps_0_fpgamgr>;
> + fpga-firmware = "soc_system.rbf";
> +
> + resets = <&hps_fpgabridge0 0>, 
> <&hps_fpgabridge1 0>, <&hps_fpgabridge2 0>;
> + reset-names = "hps2fpga", "lwhps2fpga", 
> "fpga2hps";
> +
> + gpio@0x100010040 {
> + compatible = "altr,pio-14.0", 
> "altr,pio-1.0";
> + reg = <0x1 0x10040 0x20>;
> + clocks = <0x2>;
> + altr,gpio-bank-width = <0x4>;
> + resetvalue = <0x0>;
> + #gpio-cells = <0x2>;
> + gpio-controller;
> + };
> + };
> + };
> + };
> +};
> +

Just some quick thougths for the Socfpga case:

What you are describing here is a virtual bus, that is not existing on
at least the Socfpga, right? I don't like this.
You are mixing different independent busses/devices into one and I don't
see why. I see that this is just an example, but why
  a) isn't the fpga-mgr the one knowing about the bitstream ?
 You can't have two of these busses with different bitstreams anyway
 And if you have multipe FPGAs you have multiple fpga-mgrs, no?
  b) shouldn't the h2f/lwh2f/f2h bridges be the "simple-bus devices" instead of
 just reset-controllers ? What about e.g. the bus width of the bridges?
 It can change depending on the bitstream. When I have an IP core that does
 DMA I might want my driver to be able to configure the bus width 
accordingly.
 There are other settings in the bridges that I can not set when they are 
just
 reset controllers.

I can understand that this is just an example, but again for the Socfpga case it
is IMHO wrong. I don't know about e.g. the Zynq without researching, though.

Regards,
Steffen

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [patch 2/2] Staging: rtl8192e: pointer math bug in rtllib_rx_DELBA()

[Mateusz Kulikowski]

n 17.07.2015 11:24, Dan Carpenter wrote:
> The "delba" variable is a pointer to struct rtllib_hdr_3addr so this
> pointer math bug means that we read nonsense data from beyond the end of
> the buffer.  It could result in a oops if the memory is not mapped.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/staging/rtl8192e/rtl819x_BAProc.c 
> b/drivers/staging/rtl8192e/rtl819x_BAProc.c
> index 60f536c..98e6c4e 100644
> --- a/drivers/staging/rtl8192e/rtl819x_BAProc.c
> +++ b/drivers/staging/rtl8192e/rtl819x_BAProc.c
> @@ -453,7 +453,7 @@ int rtllib_rx_DELBA(struct rtllib_device *ieee, struct 
> sk_buff *skb)
>  #endif
>   delba = (struct rtllib_hdr_3addr *)skb->data;
>   dst = (u8 *)(&delba->addr2[0]);
> - delba += sizeof(struct rtllib_hdr_3addr);
> + delba++;
>   pDelBaParamSet = (union delba_param_set *)(delba+2);
>   pReasonCode = (u16 *)(delba+4);
>  
> 

Ack/+1, 

It's not the last fix for 'delba' unfortunately :(

Next lines should use delba as u8 if I see correctly
See rtllib_DELBA() (line 141) - It first fills skb with rtllib_hdr_3_addr,
and then adds skb delbaparam_set and reasonCode (as a 6 bytes).
Or I'm tired - will re-check tomorrow.

Funniest thing is - it is processed like that since at least 2011..

Good thing is - this code seems not to be executed
at least not on my 'ordinary' test configuration (WPA2, 2.5G N).

I will try to figure out - perhaps it can be safely 
removed (conditions for it's execution may be never never met).

Bad thing is - this driver(s) are probably full of bugs like that :/

M.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/2] staging: lirc: mostly checkpatch cleanups

[Maciek Borzecki]

A tiny patch series that addresses warnings identified by
checkpatch. The first patch fixes minor warning with unnecessary
brakes around single statement block.

The second patch does away with a custom dprintk() in favor of dev_dbg
and pr_debug(). The patch is sent separately as the change is more
'invasive' than the first one.

Maciek Borzecki (2):
  staging: media: lirc: fix various checkpatch warnings
  staging: media: lirc: lirc_serial: use dynamic debugs

 drivers/staging/media/lirc/lirc_imon.c   |  8 
 drivers/staging/media/lirc/lirc_sasem.c  |  4 ++--
 drivers/staging/media/lirc/lirc_serial.c | 25 +++--
 3 files changed, 13 insertions(+), 24 deletions(-)

-- 
2.4.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: media: lirc: lirc_serial: use dynamic debugs

[Maciek Borzecki]

Replace custom debug macro dprintk() with pr_debug() or
dev_dbg(). Remove unused module param `debug`.

This removes the following checkpatch warning:
WARNING: Prefer [subsystem eg: netdev]_dbg([subsystem]dev, ... then 
dev_dbg(dev, ... then pr_debug(...  to printk(KERN_DEBUG ...
+   printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \

Signed-off-by: Maciek Borzecki 
---
 drivers/staging/media/lirc/lirc_serial.c | 25 +++--
 1 file changed, 7 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_serial.c 
b/drivers/staging/media/lirc/lirc_serial.c
index 
dc7984455c3a7a051ea8db668c2fbeb9f64b43f3..c427202665d221cf1a2cbb6f446110fe43652a1d
 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -109,17 +109,9 @@ static bool iommap;
 static int ioshift;
 static bool softcarrier = true;
 static bool share_irq;
-static bool debug;
 static int sense = -1; /* -1 = auto, 0 = active high, 1 = active low */
 static bool txsense;   /* 0 = active high, 1 = active low */
 
-#define dprintk(fmt, args...)  \
-   do {\
-   if (debug)  \
-   printk(KERN_DEBUG LIRC_DRIVER_NAME ": " \
-  fmt, ## args);   \
-   } while (0)
-
 /* forward declarations */
 static long send_pulse_irdeo(unsigned long length);
 static long send_pulse_homebrew(unsigned long length);
@@ -356,7 +348,7 @@ static int init_timing_params(unsigned int new_duty_cycle,
/* Derive pulse and space from the period */
pulse_width = period * duty_cycle / 100;
space_width = period - pulse_width;
-   dprintk("in init_timing_params, freq=%d, duty_cycle=%d, "
+   pr_debug("in init_timing_params, freq=%d, duty_cycle=%d, "
"clk/jiffy=%ld, pulse=%ld, space=%ld, "
"conv_us_to_clocks=%ld\n",
freq, duty_cycle, __this_cpu_read(cpu_info.loops_per_jiffy),
@@ -382,7 +374,7 @@ static int init_timing_params(unsigned int new_duty_cycle,
period = 256 * 100L / freq;
pulse_width = period * duty_cycle / 100;
space_width = period - pulse_width;
-   dprintk("in init_timing_params, freq=%d pulse=%ld, space=%ld\n",
+   pr_debug("in init_timing_params, freq=%d pulse=%ld, space=%ld\n",
freq, pulse_width, space_width);
return 0;
 }
@@ -555,7 +547,7 @@ static void rbwrite(int l)
 {
if (lirc_buffer_full(&rbuf)) {
/* no new signals will be accepted */
-   dprintk("Buffer overrun\n");
+   pr_debug("Buffer overrun\n");
return;
}
lirc_buffer_write(&rbuf, (void *)&l);
@@ -845,7 +837,7 @@ static int lirc_serial_probe(struct platform_device *dev)
dev_info(&dev->dev, "Manually using active %s receiver\n",
 sense ? "low" : "high");
 
-   dprintk("Interrupt %d, port %04x obtained\n", irq, io);
+   dev_dbg(&dev->dev, "Interrupt %d, port %04x obtained\n", irq, io);
return 0;
 }
 
@@ -950,7 +942,7 @@ static long lirc_ioctl(struct file *filep, unsigned int 
cmd, unsigned long arg)
return -ENOIOCTLCMD;
 
case LIRC_SET_SEND_DUTY_CYCLE:
-   dprintk("SET_SEND_DUTY_CYCLE\n");
+   pr_debug("SET_SEND_DUTY_CYCLE\n");
if (!(hardware[type].features&LIRC_CAN_SET_SEND_DUTY_CYCLE))
return -ENOIOCTLCMD;
 
@@ -962,7 +954,7 @@ static long lirc_ioctl(struct file *filep, unsigned int 
cmd, unsigned long arg)
return init_timing_params(value, freq);
 
case LIRC_SET_SEND_CARRIER:
-   dprintk("SET_SEND_CARRIER\n");
+   pr_debug("SET_SEND_CARRIER\n");
if (!(hardware[type].features&LIRC_CAN_SET_SEND_CARRIER))
return -ENOIOCTLCMD;
 
@@ -1157,7 +1149,7 @@ static void __exit lirc_serial_exit_module(void)
 {
lirc_unregister_driver(driver.minor);
lirc_serial_exit();
-   dprintk("cleaned up module\n");
+   pr_debug("cleaned up module\n");
 }
 
 
@@ -1208,6 +1200,3 @@ MODULE_PARM_DESC(txsense, "Sense of transmitter circuit"
 
 module_param(softcarrier, bool, S_IRUGO);
 MODULE_PARM_DESC(softcarrier, "Software carrier (0 = off, 1 = on, default 
on)");
-
-module_param(debug, bool, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(debug, "Enable debugging messages");
-- 
2.4.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: media: lirc: fix various checkpatch warnings

[Maciek Borzecki]

Remove unnecessary brakes where appropriate.

This removes the following checkpatch warning:
WARNING: braces {} are not necessary for single statement blocks

Signed-off-by: Maciek Borzecki 
---
 drivers/staging/media/lirc/lirc_imon.c  | 8 
 drivers/staging/media/lirc/lirc_sasem.c | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_imon.c 
b/drivers/staging/media/lirc/lirc_imon.c
index 
62ec9f70dae4cd87dcf6fb60b1dd81df3d568b19..05d47dc8ffb8a987dc65287d36096a78cd5f96cd
 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -785,13 +785,13 @@ static int imon_probe(struct usb_interface *interface,
}
 
driver = kzalloc(sizeof(struct lirc_driver), GFP_KERNEL);
-   if (!driver) {
+   if (!driver)
goto free_context;
-   }
+
rbuf = kmalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
-   if (!rbuf) {
+   if (!rbuf)
goto free_driver;
-   }
+
if (lirc_buffer_init(rbuf, BUF_CHUNK_SIZE, BUF_SIZE)) {
dev_err(dev, "%s: lirc_buffer_init failed\n", __func__);
goto free_rbuf;
diff --git a/drivers/staging/media/lirc/lirc_sasem.c 
b/drivers/staging/media/lirc/lirc_sasem.c
index 
9e5674341abe7368e5ec228f737e4c2d766f7d80..8113c999ee00dbdb065aa100f27956a922f36bf9
 100644
--- a/drivers/staging/media/lirc/lirc_sasem.c
+++ b/drivers/staging/media/lirc/lirc_sasem.c
@@ -181,10 +181,10 @@ static void deregister_from_lirc(struct sasem_context 
*context)
if (retval)
dev_err(&context->dev->dev,
"%s: unable to deregister from lirc (%d)\n",
-  __func__, retval);
+   __func__, retval);
else
dev_info(&context->dev->dev,
-"Deregistered Sasem driver (minor:%d)\n", minor);
+   "Deregistered Sasem driver (minor:%d)\n", minor);
 
 }
 
-- 
2.4.6

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v9 3/7] staging: add bindings document for simple fpga bus

[Jason Gunthorpe]

On Fri, Jul 17, 2015 at 09:49:13PM +0200, Steffen Trumtrar wrote:
> What you are describing here is a virtual bus, that is not existing on
> at least the Socfpga, right?

I wouldn't get too hung up on bus or not bus, the HW these days
doesn't even use busses.

For AXI systems, which is all the ARM designs, the the bridge between
the CPU and FPGA is always a physical AXI link hanging off one of the
CPU block's internal AXI switches.

I choose to model these ports in DT explicitly, because they represent
swappable attachment points, and often the switch ports have
programmable registers related to that port.

FPGA logic is always hanging off one of these physical ports.

Usually there are multiple independent links between the CPU and the
FPGA (ie Xilinx Virtex 4 has at least 4 CPU to FPGA bus links, Zynq
has something like 7)

Ie on Zynq, I do things like this:

/ {
/* This is a simplification of the 5 AXI interconnect switches
   hardwired inside the CPU block */
ps7_axi_interconnect_0: amba@0 {
// This is the register block that programs the FPGA
ps7-dev-cfg@f8007000 {
clock-names = "ref_clk", "fclk0", "fclk1", "fclk2", 
"fclk3";
clocks = <&clkc 12>, <&clkc 15>, <&clkc 16>, <&clkc 
17>, <&clkc 18>;
compatible = "xlnx,zynq-devcfg-1.0";
interrupt-parent = <&ps7_scugic_0>;
interrupts = <0 8 4>;
reg = <0xf8007000 0x100>;
};

// This node bundles the entire FPGA side
programmable: fpga@pl {
// This is a physical port on one of the CPU core's AXI swithces
gp0_axi: axi@4000 {
k_gpio@8 {
k_sysmon@81000 {
gpio3: klina_gpio@80010 {
i2c_qsfp1 {
}

// This is another physical port on one of the CPU core's AXI 
swithces
gp1_axi: axi@8000 {
}

// The FPGA bitstream also hooks up to a 3rd AXI port for 
initiating DMA
// hp0_axi ...
}
}

Zynq has 5 internal AXI switches, but the typical Linux DT models them
all as single DT 'bus'

I've brought the FPGA exposed AXI ports out under the programmable
node, purely for convenience of coding the dynamic load/unload of all
the FPGA elements. We do full hot swap of the FPGA during system
operation.

The physical ports could be located someplace within the amba@0, but
since amba@0 is basically already a lie, I don't really mind this
slight divergence as it makes logical sense and life easier.

Usually what my FPGA designs do is take the AXI port(s) and then fan
out to something else, either more AXI ports through yet another AXI
switch, or convert to a low speed multi-drop bus and fan that out to a
number of devices. I don't usually model this, because it provide no
value to Linux to know these details.

Ultimately the gp0_axi/gp1_axi have a number of peripheral childern,
each with their own drivers, interrupts, etc.

In this particular design gp1_axi bridges to a FPGA soft-core which
provides a physical bus to another FPGA, which is represented as more
nested nodes, and another FPGA programmable node.

DMA for the brdige side flows through the hp0_axi port. (it consumes 3
AXI ports IIRC)

I think the simplified DT modeling is a reasonable compromise.

>   b) shouldn't the h2f/lwh2f/f2h bridges be the "simple-bus devices" instead 
> of
>  just reset-controllers ? What about e.g. the bus width of the
>  bridges?

On Zynq there are a variety of resets and clocks going from the CPU
block to the FPGA, they all need to be configured properly to run
correctly, and they need a home. The control registers for these are
located someplace under amba@0, but I'd be happy to see the actual
values to program contained under the programming node. That fits much
better with the overlay scheme.

There is also some AXI port-specific registers that may need tuning as
well, but they can naturally fit under the axi port nodes..

>  It can change depending on the bitstream. When I have an IP core that 
> does
>  DMA I might want my driver to be able to configure the bus width 
> accordingly.
>  There are other settings in the bridges that I can not set when they are 
> just
>  reset controllers.

bridge@0xff20 should be the bus port and it can have configuration...

AXI negotiates things like link width dynamically, and for AXI, DMA
doesn't flow through the same AXI port as the control registers
anyhow.

DT is a very poor fit for a modeling a modern AXI interconnect system,
so there is often some irrelevant lossage..

Jason
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v9 3/7] staging: add bindings document for simple fpga bus

[atull]

On Fri, 17 Jul 2015, Steffen Trumtrar wrote:

> Hi!
> 
> On Fri, Jul 17, 2015 at 10:51:13AM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > New bindings document for simple fpga bus.
> > 
> > Signed-off-by: Alan Tull 
> > ---
> >  .../Documentation/bindings/simple-fpga-bus.txt |   61 
> > 
> >  1 file changed, 61 insertions(+)
> >  create mode 100644 
> > drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
> > 
> > diff --git 
> > a/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt 
> > b/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
> > new file mode 100644
> > index 000..221e781
> > --- /dev/null
> > +++ b/drivers/staging/fpga/Documentation/bindings/simple-fpga-bus.txt
> > @@ -0,0 +1,61 @@
> > +Simple FPGA Bus
> > +===
> > +
> > +A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
> > +before populating the devices below its node.
> > +
> > +Required properties:
> > +- compatible : should contain "simple-fpga-bus"
> > +- #address-cells, #size-cells, ranges: must be present to handle address 
> > space
> > +  mapping for children.
> > +
> > +Optional properties:
> > +- fpga-mgr : should contain a phandle to a fpga manager.
> > +- fpga-firmware : should contain the name of a fpga image file located on 
> > the
> > +  firmware search path.
> > +- partial-reconfig : boolean property should be defined if partial
> > +  reconfiguration is to be done.
> > +- resets : should contain a list of resets that should be released after 
> > the
> > +  fpga has been programmed i.e. fpga bridges.
> > +- reset-names : should contain a list of the names of the resets.
> > +
> > +Example:
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +/ {
> > +   fragment@0 {
> > +   target-path="/soc";
> > +   __overlay__ {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   bridge@0xff20 {
> > +   compatible = "simple-fpga-bus";
> > +   #address-cells = <0x2>;
> > +   #size-cells = <0x1>;
> > +   ranges = <0x1 0x10040 0xff210040 0x20>;
> > +
> > +   clocks = <0x2 0x2>;
> > +   clock-names = "h2f_lw_axi_clock", 
> > "f2h_sdram0_clock";
> > +
> > +   fpga-mgr = <&hps_0_fpgamgr>;
> > +   fpga-firmware = "soc_system.rbf";
> > +
> > +   resets = <&hps_fpgabridge0 0>, 
> > <&hps_fpgabridge1 0>, <&hps_fpgabridge2 0>;
> > +   reset-names = "hps2fpga", "lwhps2fpga", 
> > "fpga2hps";
> > +
> > +   gpio@0x100010040 {
> > +   compatible = "altr,pio-14.0", 
> > "altr,pio-1.0";
> > +   reg = <0x1 0x10040 0x20>;
> > +   clocks = <0x2>;
> > +   altr,gpio-bank-width = <0x4>;
> > +   resetvalue = <0x0>;
> > +   #gpio-cells = <0x2>;
> > +   gpio-controller;
> > +   };
> > +   };
> > +   };
> > +   };
> > +};
> > +
> 
> Just some quick thougths for the Socfpga case:
> 
> What you are describing here is a virtual bus, that is not existing on
> at least the Socfpga, right? I don't like this.
> You are mixing different independent busses/devices into one and I don't
> see why.

Hi Steffen,

It is a multi-interface bridge.  It is likely that a device will use more than
one at a time.  This is normal in the kernel and the device tree supports it.
My example is too simplistic.  It is common for a device to use the lwh2f
bridge for register access and the h2f bridge for data.  So you'd have

   reg = <0xc000 0x2000>,
 <0xff20 0x0020>;

and ranges that map from those areas.

> I see that this is just an example, but why
>   a) isn't the fpga-mgr the one knowing about the bitstream ?

The fpga-mgr doesn't know much.  Someone has to tell it what to load.  I think
that is a good thing.

>  You can't have two of these busses with different bitstreams anyway
>  And if you have multipe FPGAs you have multiple fpga-mgrs, no?

You would have one fpga-mgr and a separate set of bridges per fpga.

>   b) shouldn't the h2f/lwh2f/f2h bridges be the "simple-bus devices" instead 
> of
>  just reset-controllers ?

That's an artificial division of things.  These aren't really separate busses.
You would have a device that needs to be the child of two separate bridges then.

> What about e.g. the bus width of the bridges?
>  It can change depending on the bitstream. When I have an IP core that 
> does
>  DMA I might want my driver to be able to configure the bus width 
> accordingly.
>  There are other 

Re: [PATCH v9 7/7] staging: fpga manager: add driver for socfpga fpga manager

[Moritz Fischer]

Alan,

it looks pretty good so far. I have worked with Michal and developed a
Zynq equivalent against your last
patchset which can be found in the Xilinx tree now.

I just briefly glanced the changes below just two nits that caught my eye.
I'll take a closer look while trying to update the zynq-fpga driver to
work with your changes.

On Fri, Jul 17, 2015 at 8:51 AM,   wrote:
> From: Alan Tull 
>
> Add driver to fpga manager framework to allow configuration
> of FPGA in Altera SoCFPGA parts.
>
> Signed-off-by: Alan Tull 
> Acked-by: Michal Simek 
> ---
> v2: fpga_manager struct now contains struct device
> fpga_manager_register parameters now take device
>
> v3: skip a version to align versions
>
> v4: move to drivers/staging
>
> v5: fix array_size.cocci warnings
> fix platform_no_drv_owner.cocci warnings
> Remove .owner = THIS_MODULE
> include asm/irq.h
> clean up list of includes
> use altera_fpga_reset for ops
> use enum fpga_mgr_states or u32 as needed
> use devm_request_irq
> check irq <= 0 instead of == NO_IRQ
> Use ARRAY_SIZE
> rename altera -> socfpga
> static const socfpga_fpga_ops
> header moved to linux/fpga/ folder
> remove ifdef'ed code
> use platform_get_resource and platform_get_irq
> move .probe and .remove lines adjacent
> use module_platform_driver
> use __maybe_unused
> only need to 'if (IS_ENABLED(CONFIG_REGULATOR))' in one fn
> fix "unsigned 'mode' is never < 0"
>
> v6: return error for (unused) default of case statement
>
> v7: PTR_ERR should access the value just tested by IS_ERR
>
> v8: change compatible string to be more chip specific
>
> v9: update copyright year
> remove suspend/resume support and regulators
> use updated fn names for register/unregister
> use updated params for write_init
> check for partial reconfiguration request
> ---
>  drivers/staging/fpga/Kconfig   |6 +
>  drivers/staging/fpga/Makefile  |1 +
>  drivers/staging/fpga/socfpga.c |  616 
> 
>  3 files changed, 623 insertions(+)
>  create mode 100644 drivers/staging/fpga/socfpga.c
>
> diff --git a/drivers/staging/fpga/Kconfig b/drivers/staging/fpga/Kconfig
> index 8d003e3..36dd7b6 100644
> --- a/drivers/staging/fpga/Kconfig
> +++ b/drivers/staging/fpga/Kconfig
> @@ -13,6 +13,12 @@ config FPGA
>
>  if FPGA
>
> +config FPGA_MGR_SOCFPGA
> +   bool "Altera SOCFPGA FPGA Manager"
> +   depends on ARCH_SOCFPGA
> +   help
> + FPGA manager driver support for Altera SOCFPGA.
> +
>  config SIMPLE_FPGA_BUS
> bool "Simple FPGA Bus"
> depends on OF
> diff --git a/drivers/staging/fpga/Makefile b/drivers/staging/fpga/Makefile
> index 6115213..d1f9406 100644
> --- a/drivers/staging/fpga/Makefile
> +++ b/drivers/staging/fpga/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
>  obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
>
>  # FPGA Manager Drivers
> +obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> diff --git a/drivers/staging/fpga/socfpga.c b/drivers/staging/fpga/socfpga.c
> new file mode 100644
> index 000..38276f9
> --- /dev/null
> +++ b/drivers/staging/fpga/socfpga.c
> @@ -0,0 +1,616 @@
> +/*
> + * FPGA Manager Driver for Altera SOCFPGA
> + *
> + *  Copyright (C) 2013-2015 Altera Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 
As you removed the suspend / resume part, do you still need this?
> +#include 
> +
> +/* Register offsets */
> +#define SOCFPGA_FPGMGR_STAT_OFST   0x0
> +#define SOCFPGA_FPGMGR_CTL_OFST0x4
> +#define SOCFPGA_FPGMGR_DCLKCNT_OFST0x8
> +#define SOCFPGA_FPGMGR_DCLKSTAT_OFST   0xc
> +#define SOCFPGA_FPGMGR_GPIO_INTEN_OFST 0x830
> +#define SOCFPGA_FPGMGR_GPIO_INTMSK_OFST0x834
> +#define SOCFPGA_FPGMGR_GPIO_INTTYPE_LEVEL_OFST 0x838
> +#define SOCFPGA_FPGMGR_GPIO_INT_POL_OFST   0x83c
> +#define SOCFPGA_FPGMGR_GPIO_INTSTAT_OFST   0x840
> +#define SOCFPGA_FPGMGR_GPIO_RAW_INTSTAT_OFST   0x844
> +#define SOCFPGA_FPGMGR_GPIO_PORTA_EO

Re: [PATCH v9 7/7] staging: fpga manager: add driver for socfpga fpga manager

[atull]

On Fri, 17 Jul 2015, Moritz Fischer wrote:

Hi Moritz,

> Alan,
> 
> it looks pretty good so far. I have worked with Michal and developed a
> Zynq equivalent against your last
> patchset which can be found in the Xilinx tree now.
> 
> I just briefly glanced the changes below just two nits that caught my eye.
> I'll take a closer look while trying to update the zynq-fpga driver to
> work with your changes.
> 
...
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> As you removed the suspend / resume part, do you still need this?
> > +#include 

Yep, I can take out this include.

> > +
> > +/*
> > + * Prepare the FPGA to receive the configuration data.
> > + */
> > +static int socfpga_fpga_ops_configure_init(struct fpga_manager *mgr, u32 
> > flags,
> > +  const char *buf, size_t count)
> Is there a reason buf and count need to be passed here?
> > +{
> > +   struct socfpga_fpga_priv *priv = mgr->priv;
> > +   int ret;

Its to allow .write_init to look at the image header if it needs to.
Not every FPGA manager is going to need buf and count.  This one doesn't
(cyclone5).  Your .write_init can ignore them if you don't need them.

But Arria10 does (that's a separate driver that I didn't include in this
patchset). In that case I need to parse the image header to know whether
the bitstream is compressed, etc. to know how to configure the FPGA
manager registers before the FPGA can receive image data.

Thanks for reviewing!

Alan

> >
> > ___
> > devel mailing list
> > de...@linuxdriverproject.org
> > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
> 
> Overall good job, and thanks for pushing this!
> 
> Cheers,
> 
> Moritz
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 5/5] drivers: staging: rtl8192u: fixed coding style issues in r8192U_core.c

[Joe Perches]

On Fri, 2015-07-17 at 15:59 +0200, Joseph-Eugene Winzer wrote:
> Fixed a few lines that were longer than 80 chars.
[]
> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
[]
> @@ -212,7 +212,9 @@ static void rtl819x_set_channel_map(u8 channel_plan, 
> struct r8192_priv *priv)
>   ChannelPlan[channel_plan].Channel[i] >
>   max_chan)
>   break;
> - 
> GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1;
> + GET_DOT11D_INFO(ieee)->
> + channel_map[ChannelPlan[channel_plan].
> + Channel[i]] = 1;

That's _very_ not nice to read.

Try using more temporaries instead.

index = ChannelPlan[channel_plan].Channel[i];
GET_DOT11D_INFO(ieee)->channel_map[index] = 1;

etc...

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 2/5] drivers: staging: rtl8192u: fixing coding style issues in r8192U_core.c

[Joe Perches]

On Fri, 2015-07-17 at 15:59 +0200, Joseph-Eugene Winzer wrote:
> Reformatting the code without introducing other warnings
> like 'Avoid unnecessary line continuations' or breaking strings.

Very few of these seem to be improvements and many
of them should likely be in separate patches.

> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
[]
> @@ -143,17 +143,35 @@ struct CHANNEL_LIST {
>  };
>  
>  static struct CHANNEL_LIST ChannelPlan[] = {
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 
> 149, 153, 157, 161, 165}, 24}, /* FCC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11}, /* IC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56, 
> 60, 64}, 21}, /* ETSI */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* Spain. Change to 
> ETSI. */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* France. Change to 
> ETSI. */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
> 56, 60, 64}, 22}, /* MKK //MKK */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
> 56, 60, 64}, 22}, /* MKK1 */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13}, /* Israel. */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
> 56, 60, 64}, 22}, /*  For 11a , TELEC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
> 56, 60, 64}, 22}, /* MIC */
> - {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14} /* For Global 
> Domain. 1-11:active scan, 12-14 passive scan. //+YJ, 080626 */

If these were to be reformatted, it'd probably be better
to use 10 per line so that the Len value that follows is
more obvious.  Likely this struct should be const too.
Maybe something like:

static const struct CHANNEL_LIST ChannelPlan[] = {
{
.Channel = {
  1,  2,  3,  4,  5,  6,  7,  8,  9, 10,
 11, 36, 40, 44, 48, 52, 56, 60, 64,149,
153,157,161,165
},
.Len = 24,
},

etc.  Add more spaces between channels if you really want.

> @@ -179,7 +197,9 @@ static void rtl819x_set_channel_map(u8 channel_plan, 
> struct r8192_priv *priv)
>   min_chan = 1;
>   max_chan = 14;
>   } else {
> - RT_TRACE(COMP_ERR, "unknown rf chip, can't set channel 
> map in function:%s()\n", __func__);
> + RT_TRACE(COMP_ERR,
> +  "unknown rf chip, can't set channel map in 
> function:%s()\n"
> +  , __func__);

No leading commas please.  Put the comma after the format.

> @@ -187,7 +207,10 @@ static void rtl819x_set_channel_map(u8 channel_plan, 
> struct r8192_priv *priv)
>  sizeof(GET_DOT11D_INFO(ieee)->channel_map));
>   /*  Set new channel map */
>   for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
> - if (ChannelPlan[channel_plan].Channel[i] < 
> min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
> + if (ChannelPlan[channel_plan].Channel[i] <
> + min_chan ||
> + ChannelPlan[channel_plan].Channel[i] >
> + max_chan)

Likely better to use a temporary for ChannelPlan[channel_plan]
so these could become:

if (cp->Channel[i] < min_chan ||
cp->Channel[i] > max_chan)
etc...

> @@ -1490,7 +1523,8 @@ static u8 QueryIsShort(u8 TxHT, u8 TxRate, cb_desc 
> *tcb_desc)
>  {
>   u8   tmp_Short;
>  
> - tmp_Short = (TxHT == 1) ? ((tcb_desc->bUseShortGI) ? 1 : 0) : 
> ((tcb_desc->bUseShortPreamble) ? 1 : 0);
> + tmp_Short = (TxHT == 1) ? ((tcb_desc->bUseShortGI) ? 1 : 0) :
> +   ((tcb_desc->bUseShortPreamble) ? 1 : 0);
>  
>   if (TxHT == 1 && TxRate != DESC90_RATEMCS15)
>   tmp_Short = 0;

Maybe using bool would be better.

> @@ -1673,7 +1711,8 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
> *skb)
> 0, tx_zero_isr, dev);
>   status = usb_submit_urb(tx_urb_zero, GFP_ATOMIC);
>   if (status) {
> - RT_TRACE(COMP_ERR, "Error TX URB for zero byte 
> %d, error %d", atomic_read(&priv->tx_pending[tcb_desc->queue_index]), status);
> + RT_TRACE(COMP_ERR,
> +  "Error TX URB for zero byte %d, error 
> %d", atomic_read(&priv->tx_pending[tcb_desc->queue_index]), status);

Probably better line wrapped after format

etc...

_

Re: [PATCH v5 2/2] staging: rtl8192u: remove unneeded bool

[Joe Perches]

On Fri, 2015-07-17 at 11:35 +0200, Luis de Bethencourt wrote:
> bool Reval is set to match the value of bHalfWirelessN24GMode just to
> this. The value can be returned directly. Removing uneeded bool.

trivia:

> diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
> b/drivers/staging/rtl8192u/r8192U_core.c
[]
> @@ -2043,16 +2043,10 @@ static bool GetNmodeSupportBySecCfg8192(struct 
> net_device *dev) 
>  static bool GetHalfNmodeSupportByAPs819xUsb(struct net_device *dev)
>  {
> - boolReval;
>   struct r8192_priv *priv = ieee80211_priv(dev);
>   struct ieee80211_device *ieee = priv->ieee80211;

There doesn't seem to be much value in this temporary.

> - if (ieee->bHalfWirelessN24GMode)
> - Reval = true;
> - else
> - Reval =  false;
> -
> - return Reval;
> + return ieee->bHalfWirelessN24GMode;

return priv->ieee80211->bHalfWirelessN24GMode;

would work as well.  But no doubt the compiler does the
same thing in any case.


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 2/3] Documentation/fb: add documentation for sm712fb

[Sudip Mukherjee]

Create the documentation for SM712. Mention all the supported modes and
how to use.

Signed-off-by: Sudip Mukherjee 
---
 Documentation/fb/sm712fb.txt | 31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/fb/sm712fb.txt

diff --git a/Documentation/fb/sm712fb.txt b/Documentation/fb/sm712fb.txt
new file mode 100644
index 000..c388442
--- /dev/null
+++ b/Documentation/fb/sm712fb.txt
@@ -0,0 +1,31 @@
+What is sm712fb?
+=
+
+This is a graphics framebuffer driver for Silicon Motion SM712 based 
processors.
+
+How to use it?
+==
+
+Switching modes is done using the video=sm712fb:... boot parameter.
+
+If you want, for example, enable a resolution of 1280x1024x24bpp you should
+pass to the kernel this command line: "video=sm712fb:0x31B".
+
+You should not compile-in vesafb.
+
+Currently supported video modes are:
+
+[Graphic modes]
+
+bpp | 640x480  800x600  1024x768  1280x1024
++
+  8 | 0x3010x3030x3050x307
+ 16 | 0x3110x3140x3170x31A
+ 24 | 0x3120x3150x3180x31B
+
+Missing Features
+
+(alias TODO list)
+
+   * 2D acceleratrion
+   * dual-head support
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/3] staging: sm7xxfb: move sm712fb out of staging

[Sudip Mukherjee]

Now since all cleanups are done and the code is ready to be merged lets
move it out of staging into fbdev location.

Signed-off-by: Sudip Mukherjee 
---
 drivers/staging/Kconfig   |2 -
 drivers/staging/Makefile  |1 -
 drivers/staging/sm7xxfb/Kconfig   |   13 -
 drivers/staging/sm7xxfb/Makefile  |1 -
 drivers/staging/sm7xxfb/TODO  |   12 -
 drivers/staging/sm7xxfb/sm7xx.h   |  116 ---
 drivers/staging/sm7xxfb/sm7xxfb.c | 1653 -
 drivers/video/fbdev/Kconfig   |   14 +
 drivers/video/fbdev/Makefile  |1 +
 drivers/video/fbdev/sm712.h   |  116 +++
 drivers/video/fbdev/sm712fb.c | 1653 +
 11 files changed, 1784 insertions(+), 1798 deletions(-)
 delete mode 100644 drivers/staging/sm7xxfb/Kconfig
 delete mode 100644 drivers/staging/sm7xxfb/Makefile
 delete mode 100644 drivers/staging/sm7xxfb/TODO
 delete mode 100644 drivers/staging/sm7xxfb/sm7xx.h
 delete mode 100644 drivers/staging/sm7xxfb/sm7xxfb.c
 create mode 100644 drivers/video/fbdev/sm712.h
 create mode 100644 drivers/video/fbdev/sm712fb.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 7f6cae5..a969276 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -56,8 +56,6 @@ source "drivers/staging/vt6656/Kconfig"
 
 source "drivers/staging/iio/Kconfig"
 
-source "drivers/staging/sm7xxfb/Kconfig"
-
 source "drivers/staging/sm750fb/Kconfig"
 
 source "drivers/staging/xgifb/Kconfig"
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 347f647..2747c82 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -22,7 +22,6 @@ obj-$(CONFIG_VT6655)  += vt6655/
 obj-$(CONFIG_VT6656)   += vt6656/
 obj-$(CONFIG_VME_BUS)  += vme/
 obj-$(CONFIG_IIO)  += iio/
-obj-$(CONFIG_FB_SM7XX) += sm7xxfb/
 obj-$(CONFIG_FB_SM750) += sm750fb/
 obj-$(CONFIG_FB_XGI)   += xgifb/
 obj-$(CONFIG_USB_EMXX) += emxx_udc/
diff --git a/drivers/staging/sm7xxfb/Kconfig b/drivers/staging/sm7xxfb/Kconfig
deleted file mode 100644
index e2922ae..000
--- a/drivers/staging/sm7xxfb/Kconfig
+++ /dev/null
@@ -1,13 +0,0 @@
-config FB_SM7XX
-   tristate "Silicon Motion SM7XX framebuffer support"
-   depends on FB && PCI
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   help
- Frame buffer driver for the Silicon Motion SM710, SM712, SM721
- and SM722 chips.
-
- This driver is also available as a module. The module will be
- called sm7xxfb. If you want to compile it as a module, say M
- here and read .
diff --git a/drivers/staging/sm7xxfb/Makefile b/drivers/staging/sm7xxfb/Makefile
deleted file mode 100644
index 48f471c..000
--- a/drivers/staging/sm7xxfb/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_FB_SM7XX) += sm7xxfb.o
diff --git a/drivers/staging/sm7xxfb/TODO b/drivers/staging/sm7xxfb/TODO
deleted file mode 100644
index 7cb0b24..000
--- a/drivers/staging/sm7xxfb/TODO
+++ /dev/null
@@ -1,12 +0,0 @@
-TODO:
-- Dual head support
-- 2D acceleration support
-- use kernel coding style
-- refine the code and remove unused code
-- move it to drivers/video/fbdev/sm7xxfb.c
-
-Please send any patches to
-   Greg Kroah-Hartman 
-   Sudip Mukherjee 
-   Teddy Wang 
-   Sudip Mukherjee 
diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
deleted file mode 100644
index aad1cc4..000
--- a/drivers/staging/sm7xxfb/sm7xx.h
+++ /dev/null
@@ -1,116 +0,0 @@
-/*
- * Silicon Motion SM712 frame buffer device
- *
- * Copyright (C) 2006 Silicon Motion Technology Corp.
- * Authors:Ge Wang, gew...@siliconmotion.com
- * Boyod boyod.y...@siliconmotion.com.cn
- *
- * Copyright (C) 2009 Lemote, Inc.
- * Author: Wu Zhangjin, wuzhang...@gmail.com
- *
- *  This file is subject to the terms and conditions of the GNU General Public
- *  License. See the file COPYING in the main directory of this archive for
- *  more details.
- */
-
-#define FB_ACCEL_SMI_LYNX 88
-
-#define SCREEN_X_RES  1024
-#define SCREEN_Y_RES  600
-#define SCREEN_BPP16
-
-/*Assume SM712 graphics chip has 4MB VRAM */
-#define SM712_VIDEOMEMORYSIZE0x0040
-/*Assume SM722 graphics chip has 8MB VRAM */
-#define SM722_VIDEOMEMORYSIZE0x0080
-
-#define dac_reg(0x3c8)
-#define dac_val(0x3c9)
-
-extern void __iomem *smtc_regbaseaddress;
-#define smtc_mmiowb(dat, reg)  writeb(dat, smtc_regbaseaddress + reg)
-
-#define smtc_mmiorb(reg)   readb(smtc_regbaseaddress + reg)
-
-#define SIZE_SR00_SR04  (0x04 - 0x00 + 1)
-#define SIZE_SR10_SR24  (0x24 - 0x10 + 1)
-#define SIZE_SR30_SR75  (0x75 - 0x30 + 1)
-#define SIZE_SR80_SR93  (0x93 - 0x80 + 1)
-#define SIZE_SRA0_SRAF  (0xAF - 0xA0 + 1)
-#define SIZE_GR00_GR08  (0x08 - 0x00 + 1)
-#define SIZE_AR00_AR14  (0x14 - 0x00 + 1)
-#define

[PATCH v2 3/3] MAINTAINERS: update maintainers list

[Sudip Mukherjee]

Now since sm712fb has moved out of staging update the maintainers list
accordingly.

Signed-off-by: Sudip Mukherjee 
---
 MAINTAINERS | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..2c77c30 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9301,6 +9301,15 @@ S:   Maintained
 F: drivers/media/i2c/ov2659.c
 F: include/media/ov2659.h
 
+SILICON MOTION SM712 FRAME BUFFER DRIVER
+M: Sudip Mukherjee 
+M: Teddy Wang 
+M: Sudip Mukherjee 
+L: linux-fb...@vger.kernel.org
+S: Maintained
+F: drivers/video/fbdev/sm712*
+F: Documentation/fb/sm712fb.txt
+
 SIS 190 ETHERNET DRIVER
 M: Francois Romieu 
 L: net...@vger.kernel.org
@@ -9721,14 +9730,6 @@ L:   linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/staging/rtl8723au/
 
-STAGING - SILICON MOTION SM7XX FRAME BUFFER DRIVER
-M: Sudip Mukherjee 
-M: Teddy Wang 
-M: Sudip Mukherjee 
-L: linux-fb...@vger.kernel.org
-S: Maintained
-F: drivers/staging/sm7xxfb/
-
 STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER
 M: Sudip Mukherjee 
 M: Teddy Wang 
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 5/6] staging: rtl8188eu: stop using DBG_88E

[Sudip Mukherjee]

On Fri, Jul 17, 2015 at 05:33:55PM +0200, Jakub Sitnicki wrote:
> On Thu, Jul 16, 2015 at 01:28 PM CEST, Sudip Mukherjee 
>  wrote:
> > Stop using DBG_88E which is a custom macro for printing debugging
> > messages. Instead start using pr_debug and in the process define
> > pr_fmt.
> 
> In the end, don't we want to use netdev_dbg() everywhere where we work
> with a struct net_device? And use dev_dbg() everywhere where we work
> with a struct device (or a struct usb_interface)?
Looks like in some places we can get net_device from usb_interface.

struct dvobj_priv *dvobj = usb_get_intfdata(pusb_intf);
struct adapter *padapter = dvobj->if1;
struct net_device *pnetdev = padapter->pnetdev;
> 
> At least that's how I understand commit 8f26b8376faa ("checkpatch:
> update suggested printk conversions") description:
> 
> Direct conversion of printk(KERN_...  to pr_ isn't the
> preferred conversion when a struct net_device or struct device is
> available.
> 
> Do you think it is worth going straight for netdev_dbg()/dev_dbg() to
> avoid redoing it later?
At the end it should be netdev_* or dev_* and if both are not available
then pr_*. Here my main intention was to remove the custom defined
macro. And while doing this it is easier to use a script to reduce the
chances of error. Now that the custom macro is out of the way we can
concentrate on converting it to netdev_* or dev_*.
> 
> >

> >  
> > +#define pr_fmt(fmt) "R8188EU: " fmt
> >  #include 
> >  #include 
> >  #include 
> 
> If we're going to stay with pr_debug(), using KBUILD_MODNAME seems to be
> the convention among drivers when defining pr_fmt():
> 
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
yes, KBUILD_MODNAME is the usual convention but you will also find many
places where that has not been used. Here I have used R8188EU to keep it
same for all the messages that will be printed from the other files of
this driver else it might be confusing for the user.

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] staging: sm7xxfb: move sm712fb out of staging

[Sudip Mukherjee]

On Fri, Jul 17, 2015 at 09:52:35AM -0700, Greg Kroah-Hartman wrote:
> On Fri, Jul 17, 2015 at 06:51:18PM +0530, Sudip Mukherjee wrote:
> > Now since all cleanups are done and the code is ready to be merged lets
> > move it out of staging into fbdev location.
> 
> This is really hard for the fbdev developers to review.  Care to just
> make up a single patch that adds the driver to the tree in that location
> so they can read the code and review it?
I think i misunderstood you. I sent the v2 which was generated with git
format-patch. So the part about deleting it from staging is also there.
Did you mean to only send the part which is adding to the fbdev or is v2
ok?

regards
sudip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: lirc: sasem: fix whitespace style issue

[Adi Ratiu]

Signed-off-by: Adi Ratiu 
---
 drivers/staging/media/lirc/lirc_sasem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/media/lirc/lirc_sasem.c
b/drivers/staging/media/lirc/lirc_sasem.c index 8ebee96..c14ca7e 100644
--- a/drivers/staging/media/lirc/lirc_sasem.c
+++ b/drivers/staging/media/lirc/lirc_sasem.c
@@ -185,7 +185,7 @@ static void deregister_from_lirc(struct sasem_context
*context) __func__, retval);
else
dev_info(&context->dev->dev,
-"Deregistered Sasem driver (minor:%d)\n", minor);
+"Deregistered Sasem driver (minor:%d)\n", minor);
 
 }
 
-- 
2.4.6
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel