* [PATCH 07/12] staging: r8188eu: Remove wrappers around vmalloc and vzalloc
From: Larry Finger @ 2014-02-07 2:45 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
In-Reply-To: <1391741147-3047-1-git-send-email-Larry.Finger@lwfinger.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/core/rtw_mlme.c | 4 ++--
drivers/staging/rtl8188eu/core/rtw_mp.c | 2 +-
drivers/staging/rtl8188eu/core/rtw_recv.c | 2 +-
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 2 +-
drivers/staging/rtl8188eu/core/rtw_xmit.c | 8 ++++----
drivers/staging/rtl8188eu/hal/odm_interface.c | 2 +-
drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c | 2 +-
drivers/staging/rtl8188eu/include/osdep_service.h | 4 ----
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 2 +-
drivers/staging/rtl8188eu/os_dep/osdep_service.c | 18 +-----------------
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 2 +-
11 files changed, 14 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme.c b/drivers/staging/rtl8188eu/core/rtw_mlme.c
index c738230..c85fcfe 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme.c
@@ -45,7 +45,7 @@ int _rtw_init_mlme_priv (struct adapter *padapter)
_func_enter_;
- /* We don't need to memset padapter->XXX to zero, because adapter is allocated by rtw_zvmalloc(). */
+ /* We don't need to memset padapter->XXX to zero, because adapter is allocated by vzalloc(). */
pmlmepriv->nic_hdl = (u8 *)padapter;
@@ -62,7 +62,7 @@ _func_enter_;
_rtw_memset(&pmlmepriv->assoc_ssid, 0, sizeof(struct ndis_802_11_ssid));
- pbuf = rtw_zvmalloc(MAX_BSS_CNT * (sizeof(struct wlan_network)));
+ pbuf = vzalloc(MAX_BSS_CNT * (sizeof(struct wlan_network)));
if (pbuf == NULL) {
res = _FAIL;
diff --git a/drivers/staging/rtl8188eu/core/rtw_mp.c b/drivers/staging/rtl8188eu/core/rtw_mp.c
index 6451efd..a88c5f1 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mp.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mp.c
@@ -956,7 +956,7 @@ void _rtw_mp_xmit_priv(struct xmit_priv *pxmitpriv)
/* Init xmit extension buff */
_rtw_init_queue(&pxmitpriv->free_xmit_extbuf_queue);
- pxmitpriv->pallocated_xmit_extbuf = rtw_zvmalloc(num_xmit_extbuf * sizeof(struct xmit_buf) + 4);
+ pxmitpriv->pallocated_xmit_extbuf = vzalloc(num_xmit_extbuf * sizeof(struct xmit_buf) + 4);
if (pxmitpriv->pallocated_xmit_extbuf == NULL) {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_, ("alloc xmit_extbuf fail!\n"));
diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c b/drivers/staging/rtl8188eu/core/rtw_recv.c
index c9c1806..b2e00f9 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -77,7 +77,7 @@ _func_enter_;
rtw_os_recv_resource_init(precvpriv, padapter);
- precvpriv->pallocated_frame_buf = rtw_zvmalloc(NR_RECVFRAME * sizeof(union recv_frame) + RXFRAME_ALIGN_SZ);
+ precvpriv->pallocated_frame_buf = vzalloc(NR_RECVFRAME * sizeof(union recv_frame) + RXFRAME_ALIGN_SZ);
if (precvpriv->pallocated_frame_buf == NULL) {
res = _FAIL;
diff --git a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
index 02e1e1f..21b205f 100644
--- a/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
+++ b/drivers/staging/rtl8188eu/core/rtw_sta_mgt.c
@@ -79,7 +79,7 @@ u32 _rtw_init_sta_priv(struct sta_priv *pstapriv)
_func_enter_;
- pstapriv->pallocated_stainfo_buf = rtw_zvmalloc(sizeof(struct sta_info) * NUM_STA + 4);
+ pstapriv->pallocated_stainfo_buf = vzalloc(sizeof(struct sta_info) * NUM_STA + 4);
if (!pstapriv->pallocated_stainfo_buf)
return _FAIL;
diff --git a/drivers/staging/rtl8188eu/core/rtw_xmit.c b/drivers/staging/rtl8188eu/core/rtw_xmit.c
index 24182fb..e98c038 100644
--- a/drivers/staging/rtl8188eu/core/rtw_xmit.c
+++ b/drivers/staging/rtl8188eu/core/rtw_xmit.c
@@ -65,7 +65,7 @@ s32 _rtw_init_xmit_priv(struct xmit_priv *pxmitpriv, struct adapter *padapter)
_func_enter_;
- /* We don't need to memset padapter->XXX to zero, because adapter is allocated by rtw_zvmalloc(). */
+ /* We don't need to memset padapter->XXX to zero, because adapter is allocated by vzalloc(). */
spin_lock_init(&pxmitpriv->lock);
sema_init(&pxmitpriv->xmit_sema, 0);
@@ -91,7 +91,7 @@ _func_enter_;
Please also apply free_txobj to link_up all the xmit_frames...
*/
- pxmitpriv->pallocated_frame_buf = rtw_zvmalloc(NR_XMITFRAME * sizeof(struct xmit_frame) + 4);
+ pxmitpriv->pallocated_frame_buf = vzalloc(NR_XMITFRAME * sizeof(struct xmit_frame) + 4);
if (pxmitpriv->pallocated_frame_buf == NULL) {
pxmitpriv->pxmit_frame_buf = NULL;
@@ -129,7 +129,7 @@ _func_enter_;
_rtw_init_queue(&pxmitpriv->free_xmitbuf_queue);
_rtw_init_queue(&pxmitpriv->pending_xmitbuf_queue);
- pxmitpriv->pallocated_xmitbuf = rtw_zvmalloc(NR_XMITBUFF * sizeof(struct xmit_buf) + 4);
+ pxmitpriv->pallocated_xmitbuf = vzalloc(NR_XMITBUFF * sizeof(struct xmit_buf) + 4);
if (pxmitpriv->pallocated_xmitbuf == NULL) {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_, ("alloc xmit_buf fail!\n"));
@@ -171,7 +171,7 @@ _func_enter_;
/* Init xmit extension buff */
_rtw_init_queue(&pxmitpriv->free_xmit_extbuf_queue);
- pxmitpriv->pallocated_xmit_extbuf = rtw_zvmalloc(num_xmit_extbuf * sizeof(struct xmit_buf) + 4);
+ pxmitpriv->pallocated_xmit_extbuf = vzalloc(num_xmit_extbuf * sizeof(struct xmit_buf) + 4);
if (pxmitpriv->pallocated_xmit_extbuf == NULL) {
RT_TRACE(_module_rtl871x_xmit_c_, _drv_err_, ("alloc xmit_extbuf fail!\n"));
diff --git a/drivers/staging/rtl8188eu/hal/odm_interface.c b/drivers/staging/rtl8188eu/hal/odm_interface.c
index b84b111..5ba95ab 100644
--- a/drivers/staging/rtl8188eu/hal/odm_interface.c
+++ b/drivers/staging/rtl8188eu/hal/odm_interface.c
@@ -23,7 +23,7 @@
/* ODM Memory relative API. */
void ODM_AllocateMemory(struct odm_dm_struct *pDM_Odm, void **pPtr, u32 length)
{
- *pPtr = rtw_zvmalloc(length);
+ *pPtr = vzalloc(length);
}
/* length could be ignored, used to detect memory leakage. */
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
index 5921db8..d364abc 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
@@ -365,7 +365,7 @@ void rtw_IOL_cmd_tx_pkt_buf_dump(struct adapter *Adapter, int data_len)
u32 fifo_data, reg_140;
u32 addr, rstatus, loop = 0;
u16 data_cnts = (data_len/8)+1;
- u8 *pbuf = rtw_zvmalloc(data_len+10);
+ u8 *pbuf = vzalloc(data_len+10);
DBG_88E("###### %s ######\n", __func__);
rtw_write8(Adapter, REG_PKT_BUFF_ACCESS_CTRL, TXPKT_BUF_SELECT);
diff --git a/drivers/staging/rtl8188eu/include/osdep_service.h b/drivers/staging/rtl8188eu/include/osdep_service.h
index 7956f0c..0d34c36 100644
--- a/drivers/staging/rtl8188eu/include/osdep_service.h
+++ b/drivers/staging/rtl8188eu/include/osdep_service.h
@@ -230,14 +230,10 @@ extern unsigned char WPA_TKIP_CIPHER[4];
extern unsigned char RSN_TKIP_CIPHER[4];
#define rtw_update_mem_stat(flag, sz) do {} while (0)
-u8 *_rtw_vmalloc(u32 sz);
-u8 *_rtw_zvmalloc(u32 sz);
void _rtw_vmfree(u8 *pbuf, u32 sz);
u8 *_rtw_zmalloc(u32 sz);
u8 *_rtw_malloc(u32 sz);
void _rtw_mfree(u8 *pbuf, u32 sz);
-#define rtw_vmalloc(sz) _rtw_vmalloc((sz))
-#define rtw_zvmalloc(sz) _rtw_zvmalloc((sz))
#define rtw_vmfree(pbuf, sz) _rtw_vmfree((pbuf), (sz))
#define rtw_malloc(sz) _rtw_malloc((sz))
#define rtw_zmalloc(sz) _rtw_zmalloc((sz))
diff --git a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
index 4ad80ae..50c61c3 100644
--- a/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/ioctl_linux.c
@@ -5648,7 +5648,7 @@ static int rtw_wx_set_priv(struct net_device *dev,
return -EFAULT;
len = dwrq->length;
- ext = rtw_vmalloc(len);
+ ext = vmalloc(len);
if (!ext)
return -ENOMEM;
diff --git a/drivers/staging/rtl8188eu/os_dep/osdep_service.c b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
index 8c3b077..02f5e0c 100644
--- a/drivers/staging/rtl8188eu/os_dep/osdep_service.c
+++ b/drivers/staging/rtl8188eu/os_dep/osdep_service.c
@@ -55,22 +55,6 @@ u32 rtw_atoi(u8 *s)
return num;
}
-inline u8 *_rtw_vmalloc(u32 sz)
-{
- u8 *pbuf;
- pbuf = vmalloc(sz);
- return pbuf;
-}
-
-inline u8 *_rtw_zvmalloc(u32 sz)
-{
- u8 *pbuf;
- pbuf = _rtw_vmalloc(sz);
- if (pbuf != NULL)
- memset(pbuf, 0, sz);
- return pbuf;
-}
-
inline void _rtw_vmfree(u8 *pbuf, u32 sz)
{
vfree(pbuf);
@@ -252,7 +236,7 @@ struct net_device *rtw_alloc_etherdev(int sizeof_priv)
pnpi = netdev_priv(pnetdev);
- pnpi->priv = rtw_zvmalloc(sizeof_priv);
+ pnpi->priv = vzalloc(sizeof_priv);
if (!pnpi->priv) {
free_netdev(pnetdev);
pnetdev = NULL;
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_intf.c b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
index 0a341d6..e5539dd 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_intf.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_intf.c
@@ -646,7 +646,7 @@ static struct adapter *rtw_usb_if1_init(struct dvobj_priv *dvobj,
struct net_device *pnetdev = NULL;
int status = _FAIL;
- padapter = (struct adapter *)rtw_zvmalloc(sizeof(*padapter));
+ padapter = (struct adapter *)vzalloc(sizeof(*padapter));
if (padapter == NULL)
goto exit;
padapter->dvobj = dvobj;
--
1.8.4.5
^ permalink raw reply related
* [PATCH 06/12] staging: r8188eu: Remove ODM_Write4Byte
From: Larry Finger @ 2014-02-07 2:45 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
In-Reply-To: <1391741147-3047-1-git-send-email-Larry.Finger@lwfinger.net>
This routine is the equivalent of rtw_write32.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c | 2 +-
drivers/staging/rtl8188eu/hal/odm_interface.c | 7 -------
drivers/staging/rtl8188eu/include/odm_interface.h | 2 --
3 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c b/drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c
index bb80b8a..6af70ce 100644
--- a/drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c
+++ b/drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c
@@ -870,7 +870,7 @@ _PHY_ReloadMACRegisters(
for (i = 0; i < (IQK_MAC_REG_NUM - 1); i++) {
rtw_write8(adapt, MACReg[i], (u8)MACBackup[i]);
}
- ODM_Write4Byte(dm_odm, MACReg[i], MACBackup[i]);
+ rtw_write32(adapt, MACReg[i], MACBackup[i]);
}
void
diff --git a/drivers/staging/rtl8188eu/hal/odm_interface.c b/drivers/staging/rtl8188eu/hal/odm_interface.c
index 202790c..b84b111 100644
--- a/drivers/staging/rtl8188eu/hal/odm_interface.c
+++ b/drivers/staging/rtl8188eu/hal/odm_interface.c
@@ -19,13 +19,6 @@
******************************************************************************/
#include "odm_precomp.h"
-/* ODM IO Relative API. */
-
-void ODM_Write4Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u32 Data)
-{
- struct adapter *Adapter = pDM_Odm->Adapter;
- rtw_write32(Adapter, RegAddr, Data);
-}
/* ODM Memory relative API. */
void ODM_AllocateMemory(struct odm_dm_struct *pDM_Odm, void **pPtr, u32 length)
diff --git a/drivers/staging/rtl8188eu/include/odm_interface.h b/drivers/staging/rtl8188eu/include/odm_interface.h
index f45f172..9284eb8 100644
--- a/drivers/staging/rtl8188eu/include/odm_interface.h
+++ b/drivers/staging/rtl8188eu/include/odm_interface.h
@@ -77,8 +77,6 @@ typedef void (*RT_WORKITEM_CALL_BACK)(void *pContext);
/* =========== EXtern Function Prototype */
-void ODM_Write4Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u32 Data);
-
/* Memory Relative Function. */
void ODM_AllocateMemory(struct odm_dm_struct *pDM_Odm, void **pPtr, u32 length);
void ODM_FreeMemory(struct odm_dm_struct *pDM_Odm, void *pPtr, u32 length);
--
1.8.4.5
^ permalink raw reply related
* [PATCH 05/12] staging: r8188eu: Remove ODM_Write2Byte
From: Larry Finger @ 2014-02-07 2:45 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
In-Reply-To: <1391741147-3047-1-git-send-email-Larry.Finger@lwfinger.net>
This routine is the equivalent of rtw_write16.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c | 4 +++-
drivers/staging/rtl8188eu/hal/odm_interface.c | 6 ------
drivers/staging/rtl8188eu/include/odm_interface.h | 2 --
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
index 908a2c0..dea220b 100644
--- a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
+++ b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
@@ -668,7 +668,9 @@ void ODM_RA_SetRSSI_8188E(struct odm_dm_struct *dm_odm, u8 macid, u8 Rssi)
void ODM_RA_Set_TxRPT_Time(struct odm_dm_struct *dm_odm, u16 minRptTime)
{
- ODM_Write2Byte(dm_odm, REG_TX_RPT_TIME, minRptTime);
+ struct adapter *adapt = dm_odm->Adapter;
+
+ rtw_write16(adapt, REG_TX_RPT_TIME, minRptTime);
}
void ODM_RA_TxRPT2Handle_8188E(struct odm_dm_struct *dm_odm, u8 *TxRPT_Buf, u16 TxRPT_Len, u32 macid_entry0, u32 macid_entry1)
diff --git a/drivers/staging/rtl8188eu/hal/odm_interface.c b/drivers/staging/rtl8188eu/hal/odm_interface.c
index 76c54dc..202790c 100644
--- a/drivers/staging/rtl8188eu/hal/odm_interface.c
+++ b/drivers/staging/rtl8188eu/hal/odm_interface.c
@@ -21,12 +21,6 @@
#include "odm_precomp.h"
/* ODM IO Relative API. */
-void ODM_Write2Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u16 Data)
-{
- struct adapter *Adapter = pDM_Odm->Adapter;
- rtw_write16(Adapter, RegAddr, Data);
-}
-
void ODM_Write4Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u32 Data)
{
struct adapter *Adapter = pDM_Odm->Adapter;
diff --git a/drivers/staging/rtl8188eu/include/odm_interface.h b/drivers/staging/rtl8188eu/include/odm_interface.h
index a11dec1..f45f172 100644
--- a/drivers/staging/rtl8188eu/include/odm_interface.h
+++ b/drivers/staging/rtl8188eu/include/odm_interface.h
@@ -77,8 +77,6 @@ typedef void (*RT_WORKITEM_CALL_BACK)(void *pContext);
/* =========== EXtern Function Prototype */
-void ODM_Write2Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u16 Data);
-
void ODM_Write4Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u32 Data);
/* Memory Relative Function. */
--
1.8.4.5
^ permalink raw reply related
* [PATCH 03/12] staging: r8188eu: Remove ODM_Read4Byte
From: Larry Finger @ 2014-02-07 2:45 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
In-Reply-To: <1391741147-3047-1-git-send-email-Larry.Finger@lwfinger.net>
This routine is essentially a duplicate of rtw_read32.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c | 9 +++++----
drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c | 2 +-
drivers/staging/rtl8188eu/hal/odm.c | 8 ++++----
drivers/staging/rtl8188eu/hal/odm_interface.c | 6 ------
drivers/staging/rtl8188eu/include/odm_interface.h | 2 --
5 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
index 3df33bc..908a2c0 100644
--- a/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
+++ b/drivers/staging/rtl8188eu/hal/Hal8188ERateAdaptive.c
@@ -331,6 +331,7 @@ static void odm_RateDecision_8188E(struct odm_dm_struct *dm_odm,
static int odm_ARFBRefresh_8188E(struct odm_dm_struct *dm_odm, struct odm_ra_info *pRaInfo)
{ /* Wilson 2011/10/26 */
+ struct adapter *adapt = dm_odm->Adapter;
u32 MaskFromReg;
s8 i;
@@ -357,19 +358,19 @@ static int odm_ARFBRefresh_8188E(struct odm_dm_struct *dm_odm, struct odm_ra_inf
pRaInfo->RAUseRate = (pRaInfo->RateMask)&0x0000000d;
break;
case 12:
- MaskFromReg = ODM_Read4Byte(dm_odm, REG_ARFR0);
+ MaskFromReg = rtw_read32(adapt, REG_ARFR0);
pRaInfo->RAUseRate = (pRaInfo->RateMask)&MaskFromReg;
break;
case 13:
- MaskFromReg = ODM_Read4Byte(dm_odm, REG_ARFR1);
+ MaskFromReg = rtw_read32(adapt, REG_ARFR1);
pRaInfo->RAUseRate = (pRaInfo->RateMask)&MaskFromReg;
break;
case 14:
- MaskFromReg = ODM_Read4Byte(dm_odm, REG_ARFR2);
+ MaskFromReg = rtw_read32(adapt, REG_ARFR2);
pRaInfo->RAUseRate = (pRaInfo->RateMask)&MaskFromReg;
break;
case 15:
- MaskFromReg = ODM_Read4Byte(dm_odm, REG_ARFR3);
+ MaskFromReg = rtw_read32(adapt, REG_ARFR3);
pRaInfo->RAUseRate = (pRaInfo->RateMask)&MaskFromReg;
break;
default:
diff --git a/drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c b/drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c
index 6581a27..9f907f8 100644
--- a/drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c
+++ b/drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c
@@ -841,7 +841,7 @@ static void _PHY_SaveMACRegisters(
for (i = 0; i < (IQK_MAC_REG_NUM - 1); i++) {
MACBackup[i] = rtw_read8(adapt, MACReg[i]);
}
- MACBackup[i] = ODM_Read4Byte(dm_odm, MACReg[i]);
+ MACBackup[i] = rtw_read32(adapt, MACReg[i]);
}
static void reload_adda_reg(struct adapter *adapt, u32 *ADDAReg, u32 *ADDABackup, u32 RegiesterNum)
diff --git a/drivers/staging/rtl8188eu/hal/odm.c b/drivers/staging/rtl8188eu/hal/odm.c
index 3555ffa..5d41ef9 100644
--- a/drivers/staging/rtl8188eu/hal/odm.c
+++ b/drivers/staging/rtl8188eu/hal/odm.c
@@ -1433,10 +1433,10 @@ void ODM_EdcaTurboInit(struct odm_dm_struct *pDM_Odm)
pDM_Odm->DM_EDCA_Table.bIsCurRDLState = false;
Adapter->recvpriv.bIsAnyNonBEPkts = false;
- ODM_RT_TRACE(pDM_Odm, ODM_COMP_EDCA_TURBO, ODM_DBG_LOUD, ("Orginial VO PARAM: 0x%x\n", ODM_Read4Byte(pDM_Odm, ODM_EDCA_VO_PARAM)));
- ODM_RT_TRACE(pDM_Odm, ODM_COMP_EDCA_TURBO, ODM_DBG_LOUD, ("Orginial VI PARAM: 0x%x\n", ODM_Read4Byte(pDM_Odm, ODM_EDCA_VI_PARAM)));
- ODM_RT_TRACE(pDM_Odm, ODM_COMP_EDCA_TURBO, ODM_DBG_LOUD, ("Orginial BE PARAM: 0x%x\n", ODM_Read4Byte(pDM_Odm, ODM_EDCA_BE_PARAM)));
- ODM_RT_TRACE(pDM_Odm, ODM_COMP_EDCA_TURBO, ODM_DBG_LOUD, ("Orginial BK PARAM: 0x%x\n", ODM_Read4Byte(pDM_Odm, ODM_EDCA_BK_PARAM)));
+ ODM_RT_TRACE(pDM_Odm, ODM_COMP_EDCA_TURBO, ODM_DBG_LOUD, ("Orginial VO PARAM: 0x%x\n", rtw_read32(Adapter, ODM_EDCA_VO_PARAM)));
+ ODM_RT_TRACE(pDM_Odm, ODM_COMP_EDCA_TURBO, ODM_DBG_LOUD, ("Orginial VI PARAM: 0x%x\n", rtw_read32(Adapter, ODM_EDCA_VI_PARAM)));
+ ODM_RT_TRACE(pDM_Odm, ODM_COMP_EDCA_TURBO, ODM_DBG_LOUD, ("Orginial BE PARAM: 0x%x\n", rtw_read32(Adapter, ODM_EDCA_BE_PARAM)));
+ ODM_RT_TRACE(pDM_Odm, ODM_COMP_EDCA_TURBO, ODM_DBG_LOUD, ("Orginial BK PARAM: 0x%x\n", rtw_read32(Adapter, ODM_EDCA_BK_PARAM)));
} /* ODM_InitEdcaTurbo */
void odm_EdcaTurboCheck(struct odm_dm_struct *pDM_Odm)
diff --git a/drivers/staging/rtl8188eu/hal/odm_interface.c b/drivers/staging/rtl8188eu/hal/odm_interface.c
index f8d1692..ae4f30c 100644
--- a/drivers/staging/rtl8188eu/hal/odm_interface.c
+++ b/drivers/staging/rtl8188eu/hal/odm_interface.c
@@ -21,12 +21,6 @@
#include "odm_precomp.h"
/* ODM IO Relative API. */
-u32 ODM_Read4Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr)
-{
- struct adapter *Adapter = pDM_Odm->Adapter;
- return rtw_read32(Adapter, RegAddr);
-}
-
void ODM_Write1Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u8 Data)
{
struct adapter *Adapter = pDM_Odm->Adapter;
diff --git a/drivers/staging/rtl8188eu/include/odm_interface.h b/drivers/staging/rtl8188eu/include/odm_interface.h
index 84c6449..adcdc39 100644
--- a/drivers/staging/rtl8188eu/include/odm_interface.h
+++ b/drivers/staging/rtl8188eu/include/odm_interface.h
@@ -77,8 +77,6 @@ typedef void (*RT_WORKITEM_CALL_BACK)(void *pContext);
/* =========== EXtern Function Prototype */
-u32 ODM_Read4Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr);
-
void ODM_Write1Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u8 Data);
void ODM_Write2Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u16 Data);
--
1.8.4.5
^ permalink raw reply related
* [PATCH 02/12] staging: r8188eu: Remove ODM_Read2Byte
From: Larry Finger @ 2014-02-07 2:45 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
In-Reply-To: <1391741147-3047-1-git-send-email-Larry.Finger@lwfinger.net>
This routine is never used.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
drivers/staging/rtl8188eu/hal/odm_interface.c | 6 ------
drivers/staging/rtl8188eu/include/odm_interface.h | 2 --
2 files changed, 8 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/odm_interface.c b/drivers/staging/rtl8188eu/hal/odm_interface.c
index 5b29067..f8d1692 100644
--- a/drivers/staging/rtl8188eu/hal/odm_interface.c
+++ b/drivers/staging/rtl8188eu/hal/odm_interface.c
@@ -21,12 +21,6 @@
#include "odm_precomp.h"
/* ODM IO Relative API. */
-u16 ODM_Read2Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr)
-{
- struct adapter *Adapter = pDM_Odm->Adapter;
- return rtw_read16(Adapter, RegAddr);
-}
-
u32 ODM_Read4Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr)
{
struct adapter *Adapter = pDM_Odm->Adapter;
diff --git a/drivers/staging/rtl8188eu/include/odm_interface.h b/drivers/staging/rtl8188eu/include/odm_interface.h
index ba06101..84c6449 100644
--- a/drivers/staging/rtl8188eu/include/odm_interface.h
+++ b/drivers/staging/rtl8188eu/include/odm_interface.h
@@ -77,8 +77,6 @@ typedef void (*RT_WORKITEM_CALL_BACK)(void *pContext);
/* =========== EXtern Function Prototype */
-u16 ODM_Read2Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr);
-
u32 ODM_Read4Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr);
void ODM_Write1Byte(struct odm_dm_struct *pDM_Odm, u32 RegAddr, u8 Data);
--
1.8.4.5
^ permalink raw reply related
* [PATCH 00/12] Remove several pointless wrapper routines
From: Larry Finger @ 2014-02-07 2:45 UTC (permalink / raw)
To: gregkh; +Cc: devel, netdev, Larry Finger
The driver contains a large number of wrapper routines. None of them are
needed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry Finger (12):
staging: r8188eu: Remove ODM_Read1Byte
staging: r8188eu: Remove ODM_Read2Byte
staging: r8188eu: Remove ODM_Read4Byte
staging: r8188eu: Remove ODM_Write1Byte
staging: r8188eu: Remove ODM_Write2Byte
staging: r8188eu: Remove ODM_Write4Byte
staging: r8188eu: Remove wrappers around vmalloc and vzalloc
staging: r8188eu: Remove wrappers around vfree
staging: r8188eu: Remove ODM_AllocateMemory
staging: r8188eu: Remove ODM_CompareMemory
staging: r8188eu: Remove ODM_SetTimer
staging: r8188eu: Remove ODM_InitializeTimer
drivers/staging/rtl8188eu/core/rtw_mlme.c | 9 ++-
drivers/staging/rtl8188eu/core/rtw_mp.c | 4 +-
drivers/staging/rtl8188eu/core/rtw_recv.c | 4 +-
drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 4 +-
drivers/staging/rtl8188eu/core/rtw_xmit.c | 14 ++---
.../staging/rtl8188eu/hal/Hal8188ERateAdaptive.c | 13 +++--
drivers/staging/rtl8188eu/hal/HalPhyRf_8188e.c | 37 ++++++------
drivers/staging/rtl8188eu/hal/odm.c | 11 ++--
drivers/staging/rtl8188eu/hal/odm_RegConfig8188E.c | 4 +-
drivers/staging/rtl8188eu/hal/odm_interface.c | 67 ----------------------
drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c | 4 +-
drivers/staging/rtl8188eu/include/odm_interface.h | 23 --------
drivers/staging/rtl8188eu/include/osdep_service.h | 6 --
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 6 +-
drivers/staging/rtl8188eu/os_dep/osdep_service.c | 25 +-------
drivers/staging/rtl8188eu/os_dep/usb_intf.c | 4 +-
16 files changed, 59 insertions(+), 176 deletions(-)
--
1.8.4.5
^ permalink raw reply
* Re: [PATCH iproute2 net-next-for-3.13] iplink_bond: fix parameter value matching
From: Ding Tianhong @ 2014-02-07 2:45 UTC (permalink / raw)
To: Michal Kubecek, Stephen Hemminger; +Cc: netdev
In-Reply-To: <20140206125901.A95E2E5A97@unicorn.suse.cz>
On 2014/2/6 20:59, Michal Kubecek wrote:
> Lookup function get_index() compares argument with table entries
> only up to the length of the table entry so that if an entry
> with lower index is a substring of a later one, earlier entry is
> used even if the argument is equal to the other. For example,
>
> ip link set bond0 type bond xmit_hash_policy layer2+3
>
> sets xmit_hash_policy to 0 (layer2) as this is found before
> "layer2+3" can be checked.
>
> I believe the reason for using strncmp() rather than simple
> strcmp() was to allow abbreviations which means maximum length
> for comparison should be length of the string looked up.
> However, this would cause a problem if shorter value follows
> longer one and shorter one is entered (there is no such case now
> but it might happen in the future). So let's try to find an
> exact match first and only if none is found, do a second pass
> with checking for abbreviated values.
>
> Fixes: 63d127b0 ("iproute2: finish support for bonding attributes")
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> ---
> ip/iplink_bond.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/ip/iplink_bond.c b/ip/iplink_bond.c
> index f22151e..4cd6843 100644
> --- a/ip/iplink_bond.c
> +++ b/ip/iplink_bond.c
> @@ -105,8 +105,14 @@ static int get_index(const char **tbl, char *name)
> if (i == index)
> return i;
>
> + /* first check for an exact match */
> for (i = 0; tbl[i]; i++)
> - if (strncmp(tbl[i], name, strlen(tbl[i])) == 0)
> + if (strcmp(tbl[i], name) == 0)
> + return i;
> +
Yes, I think strcmp is more better here.
> + /* no exact match, try to interpret as an abbreviation */
> + for (i = 0; tbl[i]; i++)
> + if (strncmp(tbl[i], name, strlen(name)) == 0)
> return i;
>
I don't think it is needed here, if no match, just return the result.
> return -1;
>
^ permalink raw reply
* Re: [PATCH] net: use __GFP_NORETRY for high order allocations
From: Eric Dumazet @ 2014-02-07 2:09 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David Miller, netdev, David Rientjes,
linux-kernel@vger.kernel.org
In-Reply-To: <87txcbisr8.fsf@xmission.com>
On Thu, 2014-02-06 at 18:03 -0800, Eric W. Biederman wrote:
> Eric Dumazet <eric.dumazet@gmail.com> writes:
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > sock_alloc_send_pskb() & sk_page_frag_refill()
> > have a loop trying high order allocations to prepare
> > skb with low number of fragments as this increases performance.
> >
> > Problem is that under memory pressure/fragmentation, this can
> > trigger OOM while the intent was only to try the high order
> > allocations, then fallback to order-0 allocations.
> >
> > We had various reports from unexpected regressions.
> >
> > According to David, setting __GFP_NORETRY should be fine,
> > as the asynchronous compaction is still enabled, and this
> > will prevent OOM from kicking as in :
> >
> > CFSClientEventm invoked oom-killer: gfp_mask=0x42d0, order=3, oom_adj=0,
> > oom_score_adj=0, oom_score_badness=2 (enabled),memcg_scoring=disabled
> > CFSClientEventm
> >
> > Call Trace:
> > [<ffffffff8043766c>] dump_header+0xe1/0x23e
> > [<ffffffff80437a02>] oom_kill_process+0x6a/0x323
> > [<ffffffff80438443>] out_of_memory+0x4b3/0x50d
> > [<ffffffff8043a4a6>] __alloc_pages_may_oom+0xa2/0xc7
> > [<ffffffff80236f42>] __alloc_pages_nodemask+0x1002/0x17f0
> > [<ffffffff8024bd23>] alloc_pages_current+0x103/0x2b0
> > [<ffffffff8028567f>] sk_page_frag_refill+0x8f/0x160
> > [<ffffffff80295fa0>] tcp_sendmsg+0x560/0xee0
> > [<ffffffff802a5037>] inet_sendmsg+0x67/0x100
> > [<ffffffff80283c9c>] __sock_sendmsg_nosec+0x6c/0x90
> > [<ffffffff80283e85>] sock_sendmsg+0xc5/0xf0
> > [<ffffffff802847b6>] __sys_sendmsg+0x136/0x430
> > [<ffffffff80284ec8>] sys_sendmsg+0x88/0x110
> > [<ffffffff80711472>] system_call_fastpath+0x16/0x1b
> > Out of Memory: Kill process 2856 (bash) score 9999 or sacrifice child
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Acked-by: David Rientjes <rientjes@google.com>
> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> I have seen similiar order 3 allocation failures as well and reached the
> same conclusion that __GFP_NORETRY was the solution.
Thanks Eric !
^ permalink raw reply
* Re: [PATCH] net: use __GFP_NORETRY for high order allocations
From: Eric W. Biederman @ 2014-02-07 2:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, netdev, David Rientjes,
linux-kernel@vger.kernel.org
In-Reply-To: <1391712162.10160.8.camel@edumazet-glaptop2.roam.corp.google.com>
Eric Dumazet <eric.dumazet@gmail.com> writes:
> From: Eric Dumazet <edumazet@google.com>
>
> sock_alloc_send_pskb() & sk_page_frag_refill()
> have a loop trying high order allocations to prepare
> skb with low number of fragments as this increases performance.
>
> Problem is that under memory pressure/fragmentation, this can
> trigger OOM while the intent was only to try the high order
> allocations, then fallback to order-0 allocations.
>
> We had various reports from unexpected regressions.
>
> According to David, setting __GFP_NORETRY should be fine,
> as the asynchronous compaction is still enabled, and this
> will prevent OOM from kicking as in :
>
> CFSClientEventm invoked oom-killer: gfp_mask=0x42d0, order=3, oom_adj=0,
> oom_score_adj=0, oom_score_badness=2 (enabled),memcg_scoring=disabled
> CFSClientEventm
>
> Call Trace:
> [<ffffffff8043766c>] dump_header+0xe1/0x23e
> [<ffffffff80437a02>] oom_kill_process+0x6a/0x323
> [<ffffffff80438443>] out_of_memory+0x4b3/0x50d
> [<ffffffff8043a4a6>] __alloc_pages_may_oom+0xa2/0xc7
> [<ffffffff80236f42>] __alloc_pages_nodemask+0x1002/0x17f0
> [<ffffffff8024bd23>] alloc_pages_current+0x103/0x2b0
> [<ffffffff8028567f>] sk_page_frag_refill+0x8f/0x160
> [<ffffffff80295fa0>] tcp_sendmsg+0x560/0xee0
> [<ffffffff802a5037>] inet_sendmsg+0x67/0x100
> [<ffffffff80283c9c>] __sock_sendmsg_nosec+0x6c/0x90
> [<ffffffff80283e85>] sock_sendmsg+0xc5/0xf0
> [<ffffffff802847b6>] __sys_sendmsg+0x136/0x430
> [<ffffffff80284ec8>] sys_sendmsg+0x88/0x110
> [<ffffffff80711472>] system_call_fastpath+0x16/0x1b
> Out of Memory: Kill process 2856 (bash) score 9999 or sacrifice child
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Acked-by: David Rientjes <rientjes@google.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
I have seen similiar order 3 allocation failures as well and reached the
same conclusion that __GFP_NORETRY was the solution.
Eric
> ---
> net/core/sock.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 0c127dcdf6a8..5b6a9431b017 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1775,7 +1775,9 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
> while (order) {
> if (npages >= 1 << order) {
> page = alloc_pages(sk->sk_allocation |
> - __GFP_COMP | __GFP_NOWARN,
> + __GFP_COMP |
> + __GFP_NOWARN |
> + __GFP_NORETRY,
> order);
> if (page)
> goto fill_page;
> @@ -1845,7 +1847,7 @@ bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t prio)
> gfp_t gfp = prio;
>
> if (order)
> - gfp |= __GFP_COMP | __GFP_NOWARN;
> + gfp |= __GFP_COMP | __GFP_NOWARN | __GFP_NORETRY;
> pfrag->page = alloc_pages(gfp, order);
> if (likely(pfrag->page)) {
> pfrag->offset = 0;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC PATCH v2 tip 0/7] 64-bit BPF insn set and tracing filters
From: Alexei Starovoitov @ 2014-02-07 1:20 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Ingo Molnar, David S. Miller, Steven Rostedt, Peter Zijlstra,
H. Peter Anvin, Thomas Gleixner, Masami Hiramatsu, Tom Zanussi,
Jovi Zhangwei, Eric Dumazet, Linus Torvalds, Andrew Morton,
Frederic Weisbecker, Arnaldo Carvalho de Melo, Pekka Enberg,
Arjan van de Ven, Christoph Hellwig, linux-kernel, netdev
In-Reply-To: <52F3670D.5090608@redhat.com>
On Thu, Feb 6, 2014 at 2:42 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> Hi Alexei,
>
>
> On 02/06/2014 02:10 AM, Alexei Starovoitov wrote:
>>
>> Hi All,
>>
>> this patch set addresses main sticking points of the previous discussion:
>> http://thread.gmane.org/gmane.linux.kernel/1605783
>>
>> Main difference:
>> . all components are now in one place
>> tools/bpf/llvm - standalone LLVM backend for extended BPF instruction
>> set
>>
>> . regs.si, regs.di accessors are replaced with arg1, arg2
>>
>> . compiler enforces presence of 'license' string in source C code
>> kernel enforces GPL compatibility of BPF program
>>
>> Why bother with it?
>> Current 32-bit BPF is safe, but limited.
>> kernel modules are 'all-goes', but not-safe.
>> Extended 64-bit BPF provides safe and restricted kernel modules.
>>
>> Just like the first two, extended BPF can be used for all sorts of things.
>> Initially for tracing/debugging/[ks]tap-like without vmlinux around,
>> then for networking, security, etc
>>
>> To make exising kernel modules safe the x86 disassembler and code analyzer
>> are needed. We've tried to follow that path. Disassembler was straight
>> forward,
>> but x86 analyzer was becoming unbearably complex due to variety of
>> addressing
>> modes, so we started to hack GCC to reduce output x86 insns and facing
>> the headache of redoing disasm/analyzer for arm and other arhcs.
>> Plus there is old 32-bit bpf insn set already.
>> On one side extended BPF is a 64-bit extension to current BPF.
>> On the other side it's a common subset of x86-64/aarch64/... ISAs:
>> a generic 64-bit insn set that can be JITed to native HW one to one.
Hi Daniel,
Thank you for taking a look. Good questions. I had the same concerns.
Old BPF was carefully extended in specific places.
End result may look big at first glance, but every extension has specific
reason behind it. I tried to explain the reasoning in Documentation/bpf_jit.txt
I'm planning to write an on-the-fly converter from old BPF to BPF64
when BPF64 manages to demonstrate that it is equally safe.
It is straight forward to convert. Encoding is very similar.
Core concepts are the same.
Try diff include/uapi/linux/filter.h include/linux/bpf.h
to see how much is reused.
I believe that old BPF outlived itself and BPF64 should
replace it in all current use cases plus a lot more.
It just cannot happen at once.
BPF64 can come in. bpf32->bpf64 converter functioning.
JIT from bpf64->aarch64 and may be sparc64 needs to be in place.
Then old bpf can fade away.
> First of all, I think it's very interesting work ! I'm just a bit concerned
> that this _huge_ patchset with 64 bit BPF, or however we call it, will line
Huge?
kernel is only 2k
the rest is 6k of userspace LLVM backend where most of it is llvm's
boilerplate code. GCC backend for BPF is 3k.
The goal is to have both GCC and LLVM backends to be upstreamed
when kernel pieces are agreed upon.
For comparison existing tools/net/bpf* is 2.5k
but here with 6k we get optimizing compiler from C and assembler.
> up in one row next to the BPF code we currently have and next to new
> nftables
> engine and we will end up with three such engines which do quite similar
> things and are all exposed to user space thus they need to be maintained
> _forever_, adding up legacy even more. What would be the long-term future
> use
> cases where the 64 bit engine comes into place compared to the current BPF
> engine? What are the concrete killer features? I didn't went through your
killer features vs old bpf are:
- zero-cost function calls
- 32-bit vs 64-bit
- optimizing compiler that can compile C into BPF64
Why call kernel function from BPF?
So that BPF instruction set has to be extended only once and JITs are
written only once.
Over the years many extensions crept into old BPF as 'negative offsets'.
but JITs don't support all of them and assume bpf input as 'skb' only.
seccomp is using old bpf, but, because of these limitations, cannot use JIT.
BPF64 allows seccomp to be JITed, since bpf input is generalized
as 'struct bpf_context'.
New 'negative offset' extension for old bpf would mean implementing it in
JITs of all architectures? Painful, but doable. We can do better.
Fixed instruction set that allows zero-overhead calls into kernel functions
is much more flexible and extendable in a clean way.
Take a look at kernel/trace/bpf_trace_callbacks.c
It is a customization of generic BPF64 core for 'tracing filters'.
The set of functions for networking and definition of 'bpf_context'
will be different.
So BPF64 for tracing need X extensions, BPF64 for networking needs Y
extensions, but core framework stays the same and JIT stays the same.
How to do zero-overhead call?
Map BPF registers to native registers one to one
and have compatible calling convention between BPF and native.
Then BPF asm code:
mov R1, 1
mov R2, 2
call foo
will be JITed into x86-64:
mov rdi, 1
mov rsi, 2
call foo
That makes BPF64 calls into kernel as fast as possible.
Especially for networking we don't want overhead of FFI mechanisms.
That's why A and X regs and lack of callee-saved regs make old BPF
impractical to support generic function calls.
BPF64 defines R1-R5 as function arguments and R6-R9 as
callee-saved, so kernel can natively call into JIT-ed BPF and back
with no extra argument shuffling.
gcc/llvm backends know that R6-R9 will be preserved while BPF is
calling into kernel functions and can make proper optimizations.
R6-R9 map to rbx-r15 on x86-64. On aarch64 we have
even more freedom of mapping.
> code
> in detail, but although we might/could have _some_ performance benefits but
> at
> the _huge_ cost of adding complexity. The current BPF I find okay to debug
> and
> to follow, but how would be debug'ability of 64 bit programs end up, as you
> mention, it becomes "unbearably complex"?
"unbearably complex" was the reference to x86 static analyzer :)
It's difficult to reconstruct and verify control and data flow of x86 asm code.
Binary compilers do that (like transmeta and others), but that's not suitable
for kernel.
Both old bpf asm and bpf64 asm code I find equivalent in readability.
clang dropmon.c ...|llc -filetype=asm
will produce the following bpf64 asm code:
mov r6, r1
ldd r1, 8(r6)
std -8(r10), r1
mov r7, 0
mov r3, r10
addi r3, -8
mov r1, r6
mov r2, r7
call bpf_table_lookup
jeqi r0, 0 goto .LBB0_2
which corresponds to C:
void dropmon(struct bpf_context *ctx)
{ void *loc;
uint64_t *drop_cnt;
loc = (void *)ctx->arg2;
drop_cnt = bpf_table_lookup(ctx, 0, &loc);
if (drop_cnt) ...
I think restricted C is easier to program and debug.
Which is another killer feature of bpf64.
Interesting use case would be if some kernel subsystem
decides to generate BPF64 insns on the fly and JIT them.
Sort of self-modifieable kernel code.
It's certainly easier to generate BPF64 binary with macroses
from linux/bpf.h instead of x86 binary...
I may be dreaming here :)
> Did you instead consider to
> replace
> the current BPF engine instead, and add a sort of built-in compatibility
> mode for current BPF programs? I think that this would be the way better
> option to go with instead of adding a new engine next to the other. For
> maintainability, trying to replace the old one might be harder to do on the
> short term but better to maintain on the long run for everyone, no?
Exactly. I think on-the-fly converter from bpf32->bpf64 is this built-in
compatibility layer. I completely agree that replacing bpf32 is hard
short term, since it will raise too many concerns about
stability/safety, but long term it's a way to go.
I'm open to all suggestions on how to make it more generic, useful,
faster.
Thank you for feedback.
Regards,
Alexei
^ permalink raw reply
* Re: [PATCH net] tg3: Fix deadlock in tg3_change_mtu()
From: David Miller @ 2014-02-07 1:10 UTC (permalink / raw)
To: nsujir; +Cc: netdev, david.vrabel, stable, mchan
In-Reply-To: <52F43219.8010809@broadcom.com>
From: Nithin Nayak Sujir <nsujir@broadcom.com>
Date: Thu, 6 Feb 2014 17:08:41 -0800
> I apologize. For some reason, I was under the impression that the rule
> applied to core networking and not driver-only changes. Will keep this
> in mind.
>
> How should I proceed with this? Should I resubmit?
You don't need to resubmit.
> Also, I'm a little confused as to why my previous submissions to net
> with stable Cc'd were ok. E.g. commit
> 375679104ab3ccfd18dcbd7ba503734fb9a2c63a - "tg3: Expand
> 4g_overflow_test workaround to skb fragments of any size.". Did it
> slip by because I didn't have the < >?
I didn't catch them at the time, that's all. I process hundreds of
patches a day.
^ permalink raw reply
* Re: [PATCH net] tg3: Fix deadlock in tg3_change_mtu()
From: Nithin Nayak Sujir @ 2014-02-07 1:08 UTC (permalink / raw)
To: David Miller; +Cc: netdev, david.vrabel, stable, mchan
In-Reply-To: <20140206.165448.1676259324527494823.davem@davemloft.net>
On 02/06/2014 04:54 PM, David Miller wrote:
>
> Networking patches should never be CC:'d to -stable. And you should
> never add the:
>
> Cc: <stable@vger.kernel.org>
>
> tag to networking commit messages.
>
> Instead, after the "---" delimiter, you should kindly request that
> I queue up that patch for stable, and why. I handle networking
> stable submissions on my own.
>
I apologize. For some reason, I was under the impression that the rule applied
to core networking and not driver-only changes. Will keep this in mind.
How should I proceed with this? Should I resubmit?
Also, I'm a little confused as to why my previous submissions to net with stable
Cc'd were ok. E.g. commit 375679104ab3ccfd18dcbd7ba503734fb9a2c63a - "tg3:
Expand 4g_overflow_test workaround to skb fragments of any size.". Did it slip
by because I didn't have the < >?
Thanks,
Nithin.
^ permalink raw reply
* Re: VLAN ID 0 with priority tagging
From: Toshiaki Makita @ 2014-02-07 1:08 UTC (permalink / raw)
To: Sridhar Samudrala, netdev@vger.kernel.org
In-Reply-To: <52F4207A.6020408@gmail.com>
(2014/02/07 8:53), Sridhar Samudrala wrote:
> On 1/22/2014 3:49 PM, Sridhar Samudrala wrote:
>> I am trying to send a packet with VLAN ID 0 and non-zero priority.
>>
>> The VLAN interfaces are created on 2 hosts using
>> ip link add link eth1 eth1.0 type vlan id 0 egress-qos-map 0:2
>>
>> When i try to send a packet using ping/arping, on the sender side tcpdump
>> shows that the VLAN tag is added with ID 0 and priority 2.
>>
>> However, the receiver is receiving the packet with vlan tag stripped.
>>
>> I am seeing the same behavior with multiple NICs and also with a
>> switch in
>> between the 2 hosts or with the 2 hosts connected over loopback cable.
>>
>> It looks as if the driver on the send side is stripping the tag if
>> vlan id is 0.
>> Is this correct behavior or a bug?
>> Any clues on how to get priority tagging to work with vlan id 0?
>>
> I sent this note a few weeks back, but i haven't seen any response so far.
>
> Is priority tagging with VLAN ID 0 not supported or is this a bug?
> It looks like the NIC hardware is stripping the VLAN tag if the id is 0
> even when VLAN tag
> is added by the software.
eth1.0 should be able to send frames tagged with vid 0.
Though I don't know whether there are NICs/drivers that strip tag 0, I
can send frames with vid 0 (with e1000e).
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH] tcp: remove 1ms offset in srtt computation
From: Neal Cardwell @ 2014-02-07 1:08 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Yuchung Cheng, Vytautas Valancius
In-Reply-To: <1391731030.10160.36.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Feb 6, 2014 at 6:57 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> TCP pacing depends on an accurate srtt estimation.
>
> Current srtt estimation is using jiffie resolution,
> and has an artificial offset of at least 1 ms, which can produce
> slowdowns when FQ/pacing is used, especially in DC world,
> where typical rtt is below 1 ms.
>
> We are planning a switch to usec resolution for linux-3.15,
> but in the meantime, this patch removes the 1 ms offset.
>
> All we need is to have tp->srtt minimal value of 1 to differentiate
> the case of srtt being initialized or not, not 8.
>
> The problematic behavior was observed on a 40Gbit testbed,
> where 32 concurrent netperf were reaching 12Gbps of aggregate
> speed, instead of line speed.
>
> This patch also has the effect of reporting more accurate srtt and send
> rates to iproute2 ss command as in :
>
> $ ss -i dst cca2
> Netid State Recv-Q Send-Q Local Address:Port
> Peer Address:Port
> tcp ESTAB 0 0 10.244.129.1:56984
> 10.244.129.2:12865
> cubic wscale:6,6 rto:200 rtt:0.25/0.25 ato:40 mss:1448 cwnd:10 send
> 463.4Mbps rcv_rtt:1 rcv_space:29200
> tcp ESTAB 0 390960 10.244.129.1:60247
> 10.244.129.2:50204
> cubic wscale:6,6 rto:200 rtt:0.875/0.75 mss:1448 cwnd:73 ssthresh:51
> send 966.4Mbps unacked:73 retrans:0/121 rcv_space:29200
>
> Reported-by: Vytautas Valancius <valas@google.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Neal Cardwell <ncardwell@google.com>
> ---
> net/ipv4/tcp_input.c | 18 ++++++++++--------
> net/ipv4/tcp_output.c | 2 +-
> 2 files changed, 11 insertions(+), 9 deletions(-)
Acked-by: Neal Cardwell <ncardwell@google.com>
Thanks, Eric!
neal
^ permalink raw reply
* Re: [PATCH net] tg3: Fix deadlock in tg3_change_mtu()
From: David Miller @ 2014-02-07 0:54 UTC (permalink / raw)
To: nsujir; +Cc: netdev, david.vrabel, stable, mchan
In-Reply-To: <1391724785-13562-1-git-send-email-nsujir@broadcom.com>
Networking patches should never be CC:'d to -stable. And you should
never add the:
Cc: <stable@vger.kernel.org>
tag to networking commit messages.
Instead, after the "---" delimiter, you should kindly request that
I queue up that patch for stable, and why. I handle networking
stable submissions on my own.
^ permalink raw reply
* Re: [Patch net] bridge: fix netconsole setup over bridge
From: Toshiaki Makita @ 2014-02-07 0:50 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: Stephen Hemminger, David S. Miller, Cong Wang
In-Reply-To: <1391727652-12520-1-git-send-email-xiyou.wangcong@gmail.com>
(2014/02/07 8:00), Cong Wang wrote:
> From: Cong Wang <cwang@twopensource.com>
>
> Commit 93d8bf9fb8f3 ("bridge: cleanup netpoll code") introduced
> a check in br_netpoll_enable(), but this check is incorrect for
> br_netpoll_setup(). This patch moves the code after the check
> into __br_netpoll_enable() and calls it in br_netpoll_setup().
> For br_add_if(), the check is still needed.
>
Acked-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Tested-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Thanks,
Toshiaki Makita
^ permalink raw reply
* [PATCH] tcp: remove 1ms offset in srtt computation
From: Eric Dumazet @ 2014-02-06 23:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Yuchung Cheng, Neal Cardwell, Vytautas Valancius
From: Eric Dumazet <edumazet@google.com>
TCP pacing depends on an accurate srtt estimation.
Current srtt estimation is using jiffie resolution,
and has an artificial offset of at least 1 ms, which can produce
slowdowns when FQ/pacing is used, especially in DC world,
where typical rtt is below 1 ms.
We are planning a switch to usec resolution for linux-3.15,
but in the meantime, this patch removes the 1 ms offset.
All we need is to have tp->srtt minimal value of 1 to differentiate
the case of srtt being initialized or not, not 8.
The problematic behavior was observed on a 40Gbit testbed,
where 32 concurrent netperf were reaching 12Gbps of aggregate
speed, instead of line speed.
This patch also has the effect of reporting more accurate srtt and send
rates to iproute2 ss command as in :
$ ss -i dst cca2
Netid State Recv-Q Send-Q Local Address:Port
Peer Address:Port
tcp ESTAB 0 0 10.244.129.1:56984
10.244.129.2:12865
cubic wscale:6,6 rto:200 rtt:0.25/0.25 ato:40 mss:1448 cwnd:10 send
463.4Mbps rcv_rtt:1 rcv_space:29200
tcp ESTAB 0 390960 10.244.129.1:60247
10.244.129.2:50204
cubic wscale:6,6 rto:200 rtt:0.875/0.75 mss:1448 cwnd:73 ssthresh:51
send 966.4Mbps unacked:73 retrans:0/121 rcv_space:29200
Reported-by: Vytautas Valancius <valas@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/tcp_input.c | 18 ++++++++++--------
net/ipv4/tcp_output.c | 2 +-
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 65cf90e063d5..227cba79fa6b 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -671,6 +671,7 @@ static void tcp_rtt_estimator(struct sock *sk, const __u32 mrtt)
{
struct tcp_sock *tp = tcp_sk(sk);
long m = mrtt; /* RTT */
+ u32 srtt = tp->srtt;
/* The following amusing code comes from Jacobson's
* article in SIGCOMM '88. Note that rtt and mdev
@@ -688,11 +689,9 @@ static void tcp_rtt_estimator(struct sock *sk, const __u32 mrtt)
* does not matter how to _calculate_ it. Seems, it was trap
* that VJ failed to avoid. 8)
*/
- if (m == 0)
- m = 1;
- if (tp->srtt != 0) {
- m -= (tp->srtt >> 3); /* m is now error in rtt est */
- tp->srtt += m; /* rtt = 7/8 rtt + 1/8 new */
+ if (srtt != 0) {
+ m -= (srtt >> 3); /* m is now error in rtt est */
+ srtt += m; /* rtt = 7/8 rtt + 1/8 new */
if (m < 0) {
m = -m; /* m is now abs(error) */
m -= (tp->mdev >> 2); /* similar update on mdev */
@@ -723,11 +722,12 @@ static void tcp_rtt_estimator(struct sock *sk, const __u32 mrtt)
}
} else {
/* no previous measure. */
- tp->srtt = m << 3; /* take the measured time to be rtt */
+ srtt = m << 3; /* take the measured time to be rtt */
tp->mdev = m << 1; /* make sure rto = 3*rtt */
tp->mdev_max = tp->rttvar = max(tp->mdev, tcp_rto_min(sk));
tp->rtt_seq = tp->snd_nxt;
}
+ tp->srtt = max(1U, srtt);
}
/* Set the sk_pacing_rate to allow proper sizing of TSO packets.
@@ -746,8 +746,10 @@ static void tcp_update_pacing_rate(struct sock *sk)
rate *= max(tp->snd_cwnd, tp->packets_out);
- /* Correction for small srtt : minimum srtt being 8 (1 jiffy << 3),
- * be conservative and assume srtt = 1 (125 us instead of 1.25 ms)
+ /* Correction for small srtt and scheduling constraints.
+ * For small rtt, consider noise is too high, and use
+ * the minimal value (srtt = 1 -> 125 us for HZ=1000)
+ *
* We probably need usec resolution in the future.
* Note: This also takes care of possible srtt=0 case,
* when tcp_rtt_estimator() was not yet called.
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 03d26b85eab8..10435b3b9d0f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1977,7 +1977,7 @@ bool tcp_schedule_loss_probe(struct sock *sk)
/* Schedule a loss probe in 2*RTT for SACK capable connections
* in Open state, that are either limited by cwnd or application.
*/
- if (sysctl_tcp_early_retrans < 3 || !rtt || !tp->packets_out ||
+ if (sysctl_tcp_early_retrans < 3 || !tp->srtt || !tp->packets_out ||
!tcp_is_sack(tp) || inet_csk(sk)->icsk_ca_state != TCP_CA_Open)
return false;
^ permalink raw reply related
* Re: VLAN ID 0 with priority tagging
From: Sridhar Samudrala @ 2014-02-06 23:53 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <52E05901.6050601@us.ibm.com>
On 1/22/2014 3:49 PM, Sridhar Samudrala wrote:
> I am trying to send a packet with VLAN ID 0 and non-zero priority.
>
> The VLAN interfaces are created on 2 hosts using
> ip link add link eth1 eth1.0 type vlan id 0 egress-qos-map 0:2
>
> When i try to send a packet using ping/arping, on the sender side tcpdump
> shows that the VLAN tag is added with ID 0 and priority 2.
>
> However, the receiver is receiving the packet with vlan tag stripped.
>
> I am seeing the same behavior with multiple NICs and also with a
> switch in
> between the 2 hosts or with the 2 hosts connected over loopback cable.
>
> It looks as if the driver on the send side is stripping the tag if
> vlan id is 0.
> Is this correct behavior or a bug?
> Any clues on how to get priority tagging to work with vlan id 0?
>
I sent this note a few weeks back, but i haven't seen any response so far.
Is priority tagging with VLAN ID 0 not supported or is this a bug?
It looks like the NIC hardware is stripping the VLAN tag if the id is 0
even when VLAN tag
is added by the software.
Thanks
Sridhar
^ permalink raw reply
* [PATCHv2 2/2] dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac.
From: dinguyen @ 2014-02-06 23:19 UTC (permalink / raw)
To: netdev
Cc: dinh.linux, devicetree, Dinh Nguyen, Giuseppe Cavallaro,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Vince Bridgers
In-Reply-To: <1391728795-30435-1-git-send-email-dinguyen@altera.com>
From: Dinh Nguyen <dinguyen@altera.com>
This patch adds the dts bindings documenation for the Altera SOCFPGA glue
layer for the Synopsys STMMAC ethernet driver.
Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Vince Bridgers <vbridgers2013@gmail.com>
---
v2: Use the dwmac-sti as an example for a glue layer and split patch up
to have dts as a separate patch. Also cc dts maintainers since there is
a new binding.
---
.../devicetree/bindings/net/socfpga-dwmac.txt | 35 ++++++++++++++
arch/arm/boot/dts/socfpga.dtsi | 51 +++++++++++++-------
arch/arm/boot/dts/socfpga_arria5_socdk.dts | 24 +++++++++
arch/arm/boot/dts/socfpga_cyclone5.dtsi | 6 ---
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts | 18 +++++++
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 22 ++++++++-
arch/arm/boot/dts/socfpga_vt.dts | 13 +++--
7 files changed, 140 insertions(+), 29 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/socfpga-dwmac.txt
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
new file mode 100644
index 0000000..d53d376
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -0,0 +1,35 @@
+Altera SOCFPGA SoC DWMAC controller
+
+The device node has following properties.
+
+Required properties:
+ - compatible : Should contain "altr,socfpga-stmmac"
+ - altr,sysmgr-syscon : Should be the phandle to the system manager node that
+ encompasses the glue register, and the register offset.
+
+Sub-nodes:
+The dwmac core should be added as subnode to SOCFPGA dwmac glue.
+- dwmac : The binding details of dwmac can be found in
+ Documentation/devicetree/bindings/net/stmmac.txt
+
+Example:
+
+ethernet0: ethernet0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ compatible = "altr,socfpga-stmmac";
+ altr,sysmgr-syscon = <&sysmgr 0x60>;
+ status = "disabled";
+ ranges;
+
+ gmac0: gmac0@ff700000 {
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
+ reg = <0xff700000 0x2000>;
+ interrupts = <0 115 4>;
+ interrupt-names = "macirq";
+ mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
+ clocks = <&emac0_clk>;
+ clock-names = "stmmaceth";
+ };
+};
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 8c4adb7..ebf6113 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -442,26 +442,43 @@
};
};
- gmac0: ethernet@ff700000 {
- compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
- reg = <0xff700000 0x2000>;
- interrupts = <0 115 4>;
- interrupt-names = "macirq";
- mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
- clocks = <&emac0_clk>;
- clock-names = "stmmaceth";
+ ethernet0: ethernet0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "altr,socfpga-stmmac";
+ altr,sysmgr-syscon = <&sysmgr 0x60>;
status = "disabled";
+ ranges;
+
+ gmac0: gmac0@ff700000 {
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
+ reg = <0xff700000 0x2000>;
+ interrupts = <0 115 4>;
+ interrupt-names = "macirq";
+ mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
+ clocks = <&emac0_clk>;
+ clock-names = "stmmaceth";
+ };
};
- gmac1: ethernet@ff702000 {
- compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
- reg = <0xff702000 0x2000>;
- interrupts = <0 120 4>;
- interrupt-names = "macirq";
- mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
- clocks = <&emac1_clk>;
- clock-names = "stmmaceth";
+ ethernet1: ethernet1 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "altr,socfpga-stmmac";
+ altr,sysmgr-syscon = <&sysmgr 0x60>;
status = "disabled";
+ ranges;
+
+ gmac1: gmac1@ff702000 {
+ device_type = "network";
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
+ reg = <0xff702000 0x2000>;
+ interrupts = <0 120 4>;
+ interrupt-names = "macirq";
+ mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
+ clocks = <&emac1_clk>;
+ clock-names = "stmmaceth";
+ };
};
L2: l2-cache@fffef000 {
@@ -538,7 +555,7 @@
reg = <0xffd05000 0x1000>;
};
- sysmgr@ffd08000 {
+ sysmgr: sysmgr@ffd08000 {
compatible = "altr,sys-mgr", "syscon";
reg = <0xffd08000 0x4000>;
};
diff --git a/arch/arm/boot/dts/socfpga_arria5_socdk.dts b/arch/arm/boot/dts/socfpga_arria5_socdk.dts
index 5beffb2..2d6b38b 100644
--- a/arch/arm/boot/dts/socfpga_arria5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_arria5_socdk.dts
@@ -37,4 +37,28 @@
*/
ethernet0 = &gmac1;
};
+
+ aliases {
+ /* this allow the ethaddr uboot environmnet variable contents
+ * to be added to the gmac1 device tree blob.
+ */
+ ethernet0 = &gmac1;
+ };
+};
+
+ðernet1 {
+ status = "okay";
+};
+
+&gmac1 {
+ phy-mode = "rgmii";
+
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txen-skew-ps = <0>;
+ txc-skew-ps = <2600>;
+ rxdv-skew-ps = <0>;
+ rxc-skew-ps = <2000>;
};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5.dtsi b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
index ca41b0e..454148d 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5.dtsi
+++ b/arch/arm/boot/dts/socfpga_cyclone5.dtsi
@@ -39,12 +39,6 @@
};
};
- ethernet@ff702000 {
- phy-mode = "rgmii";
- phy-addr = <0xffffffff>; /* probe for phy addr */
- status = "okay";
- };
-
timer0@ffc08000 {
clock-frequency = <100000000>;
};
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
index 2ee52ab..9b3b01b 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
@@ -38,3 +38,21 @@
ethernet0 = &gmac1;
};
};
+
+ðernet1 {
+ status = "okay";
+};
+
+&gmac1 {
+ phy-mode = "rgmii";
+
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txen-skew-ps = <0>;
+ txc-skew-ps = <2600>;
+ rxdv-skew-ps = <0>;
+ rxc-skew-ps = <2000>;
+};
+
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 50b99a2..469bb5c 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -30,8 +30,28 @@
device_type = "memory";
reg = <0x0 0x40000000>; /* 1GB */
};
+
+ aliases {
+ /* this allow the ethaddr uboot environmnet variable contents
+ * to be added to the gmac1 device tree blob.
+ */
+ ethernet0 = &gmac1;
+ };
};
-&gmac1 {
+ðernet1 {
status = "okay";
};
+
+&gmac1 {
+ phy-mode = "rgmii";
+
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ txen-skew-ps = <0>;
+ txc-skew-ps = <2600>;
+ rxdv-skew-ps = <0>;
+ rxc-skew-ps = <2000>;
+};
diff --git a/arch/arm/boot/dts/socfpga_vt.dts b/arch/arm/boot/dts/socfpga_vt.dts
index 222313f..418472c 100644
--- a/arch/arm/boot/dts/socfpga_vt.dts
+++ b/arch/arm/boot/dts/socfpga_vt.dts
@@ -52,11 +52,6 @@
};
};
- ethernet@ff700000 {
- phy-mode = "gmii";
- status = "okay";
- };
-
timer0@ffc08000 {
clock-frequency = <7000000>;
};
@@ -86,3 +81,11 @@
};
};
};
+
+ðernet0 {
+ status = "okay";
+};
+
+&gmac0 {
+ phy-mode = "gmii";
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCHv2 1/2] net: stmmac: Add SOCFPGA glue driver
From: dinguyen-EIB2kfCEclfQT0dZR+AlfA @ 2014-02-06 23:19 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: dinh.linux-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, Dinh Nguyen,
Giuseppe Cavallaro, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Vince Bridgers
From: Dinh Nguyen <dinguyen-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
Like the STi series SOCs, Altera's SOCFPGA also needs a glue layer on top of the
Synopsys gmac IP.
This patch adds the platform driver for the glue layer which configures the IP
before the generic STMMAC driver takes over.
Signed-off-by: Dinh Nguyen <dinguyen-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>
Cc: Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Vince Bridgers <vbridgers2013-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
v2: Use the dwmac-sti as an example for a glue layer and split patch up
to have dts as a separate patch. Also cc dts maintainers since there is
a new binding.
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 184 ++++++++++++++++++++
2 files changed, 185 insertions(+)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile b/drivers/net/ethernet/stmicro/stmmac/Makefile
index ecadece..73df8b6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_STMMAC_ETH) += stmmac.o
+stmmac-$(CONFIG_ARCH_SOCFPGA) += dwmac-socfpga.o
stmmac-$(CONFIG_STMMAC_PLATFORM) += stmmac_platform.o
stmmac-$(CONFIG_STMMAC_PCI) += stmmac_pci.o
stmmac-$(CONFIG_DWMAC_SUNXI) += dwmac-sunxi.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
new file mode 100644
index 0000000..0a6da3e
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -0,0 +1,184 @@
+/* Copyright (C) 2014 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ *
+ * Adopted from dwmac-sti.c
+ */
+
+#include <linux/clk.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_net.h>
+#include <linux/of_platform.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/stmmac.h>
+
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII 0x0
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII 0x1
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH 2
+#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x00000003
+
+struct socfpga_dwmac {
+ int interface;
+ u32 reg_offset;
+ struct device *dev;
+ struct regmap *sys_mgr_base_addr;
+ struct device_node *dwmac_np;
+};
+
+static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct device_node *stmmac_np;
+ struct regmap *sys_mgr_base_addr;
+ u32 reg_offset;
+ int ret;
+
+ stmmac_np = of_get_next_available_child(np, NULL);
+ if (!stmmac_np) {
+ dev_info(dev, "No dwmac node found\n");
+ return -EINVAL;
+ }
+
+ if (!of_device_is_compatible(stmmac_np, "snps,dwmac")) {
+ dev_info(dev, "dwmac node isn't compatible with snps,dwmac\n");
+ return -EINVAL;
+ }
+
+ dwmac->interface = of_get_phy_mode(stmmac_np);
+ of_node_put(stmmac_np);
+
+ sys_mgr_base_addr = syscon_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
+ if (IS_ERR(sys_mgr_base_addr)) {
+ dev_info(dev, "No sysmgr-syscon node found\n");
+ return PTR_ERR(sys_mgr_base_addr);
+ }
+
+ ret = of_property_read_u32_index(np, "altr,sysmgr-syscon", 1, ®_offset);
+ if (ret) {
+ dev_info(dev, "Could not reg_offset into sysmgr-syscon!\n");
+ return -EINVAL;
+ }
+
+ dwmac->reg_offset = reg_offset;
+ dwmac->sys_mgr_base_addr = sys_mgr_base_addr;
+ dwmac->dwmac_np = stmmac_np;
+ dwmac->dev = dev;
+
+ return 0;
+}
+
+static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
+{
+ struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
+ int phymode = dwmac->interface;
+ u32 reg_offset = dwmac->reg_offset;
+ u32 ctrl, val, shift = 0;
+
+ if (of_machine_is_compatible("altr,socfpga-vt"))
+ return 0;
+
+ switch (phymode) {
+ case PHY_INTERFACE_MODE_RGMII:
+ val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII;
+ break;
+ case PHY_INTERFACE_MODE_MII:
+ case PHY_INTERFACE_MODE_GMII:
+ val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
+ break;
+ default:
+ dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
+ return -EINVAL;
+ }
+
+ regmap_read(sys_mgr_base_addr, reg_offset, &ctrl);
+ ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << shift);
+ ctrl |= val << shift;
+
+ regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
+ return 0;
+}
+
+static int socfpga_dwmac_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ int ret = -ENOMEM;
+ struct socfpga_dwmac *dwmac;
+
+ dwmac = devm_kzalloc(dev, sizeof(*dwmac), GFP_KERNEL);
+ if (!dwmac)
+ return -ENOMEM;
+
+ ret = socfpga_dwmac_parse_data(dwmac, dev);
+ if (ret) {
+ dev_err(dev, "Unable to parse OF data\n");
+ return ret;
+ }
+
+ ret = socfpga_dwmac_setup(dwmac);
+ if (ret) {
+ dev_err(dev, "couldn't setup SoC glue (%d)\n", ret);
+ return ret;
+ }
+
+ if (node) {
+ ret = of_platform_populate(node, NULL, NULL, dev);
+ if (ret) {
+ dev_err(dev, "failed to add dwmac core\n");
+ return ret;
+ }
+ } else {
+ dev_err(dev, "no device node, failed to add dwmac core\n");
+ return -ENODEV;
+ }
+
+ platform_set_drvdata(pdev, dwmac);
+
+ return 0;
+}
+
+static int socfpga_dwmac_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static const struct of_device_id socfpga_dwmac_match[] = {
+ { .compatible = "altr,socfpga-stmmac" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, socfpga_dwmac_match);
+
+static struct platform_driver socfpga_dwmac_driver = {
+ .probe = socfpga_dwmac_probe,
+ .remove = socfpga_dwmac_remove,
+ .driver = {
+ .name = "socfpga-dwmac",
+ .of_match_table = of_match_ptr(socfpga_dwmac_match),
+ },
+};
+
+module_platform_driver(socfpga_dwmac_driver);
+
+MODULE_ALIAS("platform:socfpga-dwmac");
+MODULE_AUTHOR("Dinh Nguyen <dinguyen-EIB2kfCEclfQT0dZR+AlfA@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Altera SOCFPGA DWMAC Glue Layer");
+
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Should I use the pernet stuff for rxrpc sysctls
From: David Howells @ 2014-02-06 23:12 UTC (permalink / raw)
Cc: dhowells, davem, netdev, linux-afs
In-Reply-To: <25347.1391728096@warthog.procyon.org.uk>
I also noticed this in net/core/sysctl_net_core.c:
static struct ctl_table net_core_table[] = {
#ifdef CONFIG_NET <---
{
But isn't the content of the net/core/ directory contingent on CONFIG_NET=y in
net/Makefile, rendering this redundant?
David
^ permalink raw reply
* Re: [RFC PATCH] udp4: Don't take socket reference in receive path
From: Eric Dumazet @ 2014-02-06 23:08 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List, Eric Dumazet
In-Reply-To: <CA+mtBx9Zovogvnc0_J2Xrf-B+yjxV4Of-24SDLNTt5WGsL5Qhw@mail.gmail.com>
On Thu, 2014-02-06 at 14:40 -0800, Tom Herbert wrote:
> >
> The rationale for SLAB_DESTROY_BY_RCU might be different for UDP than
> TCP. For instance, in the DNS example small connected UDP flows are
> more an issue on the client, the server (which is likely to have much
> greater load) should be using unconnected sockets.
>
I know some servers have a non connected UDP socket acting as a
'listener' and instancing a new connected socket for ever incoming flow.
You cannot really know what model is used.
> In any case, I am still looking for a way to address this. Like I said
> in the commit log, this per packet cost for UDP processing is far too
> high at least in encapsulation path. I thought about extending
> SO__REUSEPORT to provide CPU affinity but that seems like overkill
> with its own performance implications. Alternatively, we could have
> fast path for the encapsulation using UDP offload model which bypass
> sockets completely which seems unpleasant.
Note that you can solve this before UDP layer, in GRO for example.
If layers before UDP already provide skb->sk (early demux), this could
be a socket that is plainly using call_rcu() for its destruction, and
you do not need to touch socket refcount.
Alternative would be to use a percpu refcnt for these special 'sockets'
that potentially are receiving XX millions frames per second using 48
cpus...
Kent Overstreet designed Percpu refcounts, maybe you should take a look
at this.
^ permalink raw reply
* Should I use the pernet stuff for rxrpc sysctls
From: David Howells @ 2014-02-06 23:08 UTC (permalink / raw)
To: davem; +Cc: dhowells, netdev, linux-afs
Hi Dave,
I would like to add some sysctls for RxRPC to configure timeouts and
suchlike. Should I use the pernet stuff to make it namespaceable? I notice
that most net/ dirs don't use this yet.
David
^ permalink raw reply
* [Patch net] bridge: fix netconsole setup over bridge
From: Cong Wang @ 2014-02-06 23:00 UTC (permalink / raw)
To: netdev
Cc: Toshiaki Makita, Stephen Hemminger, David S. Miller, Cong Wang,
Cong Wang
From: Cong Wang <cwang@twopensource.com>
Commit 93d8bf9fb8f3 ("bridge: cleanup netpoll code") introduced
a check in br_netpoll_enable(), but this check is incorrect for
br_netpoll_setup(). This patch moves the code after the check
into __br_netpoll_enable() and calls it in br_netpoll_setup().
For br_add_if(), the check is still needed.
Fixes: 93d8bf9fb8f3 ("bridge: cleanup netpoll code")
Cc: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index e4401a5..d9a9b0f 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -226,6 +226,33 @@ static void br_netpoll_cleanup(struct net_device *dev)
br_netpoll_disable(p);
}
+static int __br_netpoll_enable(struct net_bridge_port *p, gfp_t gfp)
+{
+ struct netpoll *np;
+ int err;
+
+ np = kzalloc(sizeof(*p->np), gfp);
+ if (!np)
+ return -ENOMEM;
+
+ err = __netpoll_setup(np, p->dev, gfp);
+ if (err) {
+ kfree(np);
+ return err;
+ }
+
+ p->np = np;
+ return err;
+}
+
+int br_netpoll_enable(struct net_bridge_port *p, gfp_t gfp)
+{
+ if (!p->br->dev->npinfo)
+ return 0;
+
+ return __br_netpoll_enable(p, gfp);
+}
+
static int br_netpoll_setup(struct net_device *dev, struct netpoll_info *ni,
gfp_t gfp)
{
@@ -236,7 +263,7 @@ static int br_netpoll_setup(struct net_device *dev, struct netpoll_info *ni,
list_for_each_entry(p, &br->port_list, list) {
if (!p->dev)
continue;
- err = br_netpoll_enable(p, gfp);
+ err = __br_netpoll_enable(p, gfp);
if (err)
goto fail;
}
@@ -249,28 +276,6 @@ fail:
goto out;
}
-int br_netpoll_enable(struct net_bridge_port *p, gfp_t gfp)
-{
- struct netpoll *np;
- int err;
-
- if (!p->br->dev->npinfo)
- return 0;
-
- np = kzalloc(sizeof(*p->np), gfp);
- if (!np)
- return -ENOMEM;
-
- err = __netpoll_setup(np, p->dev, gfp);
- if (err) {
- kfree(np);
- return err;
- }
-
- p->np = np;
- return err;
-}
-
void br_netpoll_disable(struct net_bridge_port *p)
{
struct netpoll *np = p->np;
^ permalink raw reply related
* Re: [RFC PATCH] udp4: Don't take socket reference in receive path
From: Tom Herbert @ 2014-02-06 22:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List, Eric Dumazet
In-Reply-To: <1391720338.10160.12.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, Feb 6, 2014 at 12:58 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Thu, 2014-02-06 at 11:58 -0800, Tom Herbert wrote:
>> The reference counting in the UDP receive path is quite expensive for
>> a socket that is share amoungst CPUs. This is probably true for normal
>> sockets, but really is painful when just using the socket for
>> receive encapsulation.
>>
>> udp4_lib_lookup always takes a socket reference, and we also put back
>> the reference after calling udp_queue_rcv_skb in the normal receive
>> path, so the need for taking the reference seems to be to hold the
>> socket after doing rcu_read_unlock. This patch modifies udp_lib_lookup
>> to optionally take a reference and is always called with rcu_read_lock.
>> In udp4_lib_rcv we call lib_lookup and udp_queue_rcv under the
>> rcu_read_lock but without having taken the reference.
>>
>> Requesting comments because I suspect there are nuances to this!
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>
> Unfortunately this cant work.
>
> When I did the RCU implementation for TCP/UDP, we chose to use
> SLAB_DESTROY_BY_RCU.
>
> This meant we have to take a reference, then check again the keys for
> the lookup.
>
> If we remove SLAB_DESTROY_BY_RCU, we kill performance for short lived
> sessions, because of call_rcu() added latencies.
>
Thanks for the explanation.
> (One UDP socket is about 1024 bytes in memory, call_rcu() grace period
> is throwing away 1024 bytes from cpu caches)
>
> Sure, in your case you know your udp sessions are not short lived,
> but many applications used UDP for DNS lookups, using few packets per
> socket.
>
The rationale for SLAB_DESTROY_BY_RCU might be different for UDP than
TCP. For instance, in the DNS example small connected UDP flows are
more an issue on the client, the server (which is likely to have much
greater load) should be using unconnected sockets.
In any case, I am still looking for a way to address this. Like I said
in the commit log, this per packet cost for UDP processing is far too
high at least in encapsulation path. I thought about extending
SO__REUSEPORT to provide CPU affinity but that seems like overkill
with its own performance implications. Alternatively, we could have
fast path for the encapsulation using UDP offload model which bypass
sockets completely which seems unpleasant.
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox