[PATCH 9/9] staging: rtl8723bs: Remove unused function prototype ODM_SetAntenna()
Remove unused function prototype ODM_SetAntenna. Signed-off-by: Nishka Dasgupta --- drivers/staging/rtl8723bs/hal/odm.h | 4 1 file changed, 4 deletions(-) diff --git a/drivers/staging/rtl8723bs/hal/odm.h b/drivers/staging/rtl8723bs/hal/odm.h index 6ba77bb70889..fba3b9e1491b 100644 --- a/drivers/staging/rtl8723bs/hal/odm.h +++ b/drivers/staging/rtl8723bs/hal/odm.h @@ -1365,10 +1365,6 @@ extern u32 TxScalingTable_Jaguar[TXSCALE_TABLE_SIZE]; #define SWAW_STEP_PEAK 0 #define SWAW_STEP_DETERMINE1 -/* Remove DIG by yuchen */ - -void ODM_SetAntenna(PDM_ODM_T pDM_Odm, u8 Antenna); - /* Remove BB power saving by Yuchen */ #define dm_CheckTXPowerTracking ODM_TXPowerTrackingCheck -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 8/9] staging: rtl8723bs: Replace function ODM_TXPowerTrackingCheck()
Remove function ODM_TXPowerTrackingCheck as all it does is call
odm_TXPowerTrackingCheckCE.
Rename odm_TXPowerTrackingCheckCE to ODM_TXPowerTrackingCheck to
maintain compatibility with call site.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/odm.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/odm.c
b/drivers/staging/rtl8723bs/hal/odm.c
index 01f732853689..dd9a16fb83a4 100644
--- a/drivers/staging/rtl8723bs/hal/odm.c
+++ b/drivers/staging/rtl8723bs/hal/odm.c
@@ -342,8 +342,6 @@ void odm_RateAdaptiveMaskInit(PDM_ODM_T pDM_Odm);
void odm_TXPowerTrackingInit(PDM_ODM_T pDM_Odm);
-void odm_TXPowerTrackingCheckCE(PDM_ODM_T pDM_Odm);
-
/* Remove Edca by Yu Chen */
@@ -1390,13 +1388,7 @@ void odm_TXPowerTrackingInit(PDM_ODM_T pDM_Odm)
}
-
void ODM_TXPowerTrackingCheck(PDM_ODM_T pDM_Odm)
-{
- odm_TXPowerTrackingCheckCE(pDM_Odm);
-}
-
-void odm_TXPowerTrackingCheckCE(PDM_ODM_T pDM_Odm)
{
struct adapter *Adapter = pDM_Odm->Adapter;
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/9] staging: rtl8723bs: hal: Replace function PHY_GetTxPowerIndex()
Remove function PHY_GetTxPowerIndex as it does nothing except call
PHY_GetTxPowerIndex_8723B.
Rename PHY_GetTxPowerIndex_8723B to PHY_GetTxPowerIndex to maintain
compatibility with call site.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 11 ---
drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c| 2 +-
drivers/staging/rtl8723bs/include/hal_com_phycfg.h | 9 -
drivers/staging/rtl8723bs/include/hal_phy_cfg.h| 2 +-
4 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
index 7b1e6c4a2e8d..6539bee9b5ba 100644
--- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
@@ -2040,17 +2040,6 @@ void PHY_SetTxPowerLimit(
}
}
-u8 PHY_GetTxPowerIndex(
- struct adapter *padapter,
- u8 RFPath,
- u8 Rate,
- enum CHANNEL_WIDTH BandWidth,
- u8 Channel
-)
-{
- return PHY_GetTxPowerIndex_8723B(padapter, RFPath, Rate, BandWidth,
Channel);
-}
-
void Hal_ChannelPlanToRegulation(struct adapter *Adapter, u16 ChannelPlan)
{
struct hal_com_data *pHalData = GET_HAL_DATA(Adapter);
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
index b02ff10fedbf..cb3ec085faa5 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
@@ -668,7 +668,7 @@ void PHY_SetTxPowerIndex(
}
}
-u8 PHY_GetTxPowerIndex_8723B(
+u8 PHY_GetTxPowerIndex(
struct adapter *padapter,
u8 RFPath,
u8 Rate,
diff --git a/drivers/staging/rtl8723bs/include/hal_com_phycfg.h
b/drivers/staging/rtl8723bs/include/hal_com_phycfg.h
index f3521b7ae295..9167f1e7827f 100644
--- a/drivers/staging/rtl8723bs/include/hal_com_phycfg.h
+++ b/drivers/staging/rtl8723bs/include/hal_com_phycfg.h
@@ -213,15 +213,6 @@ PHY_GetTxPowerTrackingOffset(
u8 RFPath
);
-u8
-PHY_GetTxPowerIndex(
-struct adapter * padapter,
-u8 RFPath,
-u8 Rate,
-enum CHANNEL_WIDTH BandWidth,
-u8 Channel
- );
-
void
Hal_ChannelPlanToRegulation(
struct adapter * Adapter,
diff --git a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
index 1ebd7094705f..b40868b2e76f 100644
--- a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
+++ b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
@@ -73,7 +73,7 @@ u8Rate
);
u8
-PHY_GetTxPowerIndex_8723B(
+PHY_GetTxPowerIndex(
struct adapter * padapter,
u8 RFPath,
u8 Rate,
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 7/9] staging: rtl8723bs: Replace function odm_TXPowerTrackingInit()
Remove function odm_TXPowerTrackingInit as all it does is call
odm_TXPowerTrackingThermalMeterInit.
Rename odm_TXPowerTrackingThermalMeterInit to
odm_TXPowerTrackingInit to maintain compatibility with call sites.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/odm.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/odm.c
b/drivers/staging/rtl8723bs/hal/odm.c
index e3f4307f3d20..01f732853689 100644
--- a/drivers/staging/rtl8723bs/hal/odm.c
+++ b/drivers/staging/rtl8723bs/hal/odm.c
@@ -339,8 +339,6 @@ void ODM_TXPowerTrackingCheck(PDM_ODM_T pDM_Odm);
void odm_RateAdaptiveMaskInit(PDM_ODM_T pDM_Odm);
-void odm_TXPowerTrackingThermalMeterInit(PDM_ODM_T pDM_Odm);
-
void odm_TXPowerTrackingInit(PDM_ODM_T pDM_Odm);
@@ -1324,11 +1322,6 @@ void odm_RSSIMonitorCheckCE(PDM_ODM_T pDM_Odm)
/* 3 Tx Power Tracking */
/* 3 */
-void odm_TXPowerTrackingInit(PDM_ODM_T pDM_Odm)
-{
- odm_TXPowerTrackingThermalMeterInit(pDM_Odm);
-}
-
static u8 getSwingIndex(PDM_ODM_T pDM_Odm)
{
struct adapter *Adapter = pDM_Odm->Adapter;
@@ -1353,7 +1346,7 @@ static u8 getSwingIndex(PDM_ODM_T pDM_Odm)
return i;
}
-void odm_TXPowerTrackingThermalMeterInit(PDM_ODM_T pDM_Odm)
+void odm_TXPowerTrackingInit(PDM_ODM_T pDM_Odm)
{
u8 defaultSwingIndex = getSwingIndex(pDM_Odm);
u8 p = 0;
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/9] staging: rtl8723bs: Replace function beacon_timing_control()
Remove function beacon_timing_control as it does nothing except call
rtw_hal_bcn_related_reg_setting.
Rename rtw_hal_bcn_related_reg_setting to beacon_timing_control to
maintain compatibility with call site.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 5 -
drivers/staging/rtl8723bs/hal/hal_intf.c | 2 +-
drivers/staging/rtl8723bs/include/hal_intf.h | 2 +-
drivers/staging/rtl8723bs/include/rtw_mlme_ext.h | 1 -
4 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
index 76c50377f0fe..d78fbbc98fa2 100644
--- a/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723bs/core/rtw_wlan_util.c
@@ -1996,11 +1996,6 @@ void adaptive_early_32k(struct mlme_ext_priv *pmlmeext,
u8 *pframe, uint len)
}
}
-void beacon_timing_control(struct adapter *padapter)
-{
- rtw_hal_bcn_related_reg_setting(padapter);
-}
-
void rtw_alloc_macid(struct adapter *padapter, struct sta_info *psta)
{
int i;
diff --git a/drivers/staging/rtl8723bs/hal/hal_intf.c
b/drivers/staging/rtl8723bs/hal/hal_intf.c
index acb25978a46c..7d8f21f32fb9 100644
--- a/drivers/staging/rtl8723bs/hal/hal_intf.c
+++ b/drivers/staging/rtl8723bs/hal/hal_intf.c
@@ -369,7 +369,7 @@ void rtw_hal_dm_watchdog_in_lps(struct adapter *padapter)
}
}
-void rtw_hal_bcn_related_reg_setting(struct adapter *padapter)
+void beacon_timing_control(struct adapter *padapter)
{
if (padapter->HalFunc.SetBeaconRelatedRegistersHandler)
padapter->HalFunc.SetBeaconRelatedRegistersHandler(padapter);
diff --git a/drivers/staging/rtl8723bs/include/hal_intf.h
b/drivers/staging/rtl8723bs/include/hal_intf.h
index 3a0c3d079d50..24926ebaf950 100644
--- a/drivers/staging/rtl8723bs/include/hal_intf.h
+++ b/drivers/staging/rtl8723bs/include/hal_intf.h
@@ -362,7 +362,7 @@ void rtw_hal_add_ra_tid(struct adapter *padapter, u32
bitmap, u8 *arg, u8 rssi_l
void rtw_hal_start_thread(struct adapter *padapter);
void rtw_hal_stop_thread(struct adapter *padapter);
-void rtw_hal_bcn_related_reg_setting(struct adapter *padapter);
+void beacon_timing_control(struct adapter *padapter);
u32 rtw_hal_read_bbreg(struct adapter *padapter, u32 RegAddr, u32 BitMask);
void rtw_hal_write_bbreg(struct adapter *padapter, u32 RegAddr, u32 BitMask,
u32 Data);
diff --git a/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
b/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
index 70cd8c0e3641..fd3cf955c9f8 100644
--- a/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
+++ b/drivers/staging/rtl8723bs/include/rtw_mlme_ext.h
@@ -650,7 +650,6 @@ void report_del_sta_event(struct adapter *padapter,
unsigned char* MacAddr, unsi
void report_add_sta_event(struct adapter *padapter, unsigned char* MacAddr,
int cam_idx);
void report_wmm_edca_update(struct adapter *padapter);
-void beacon_timing_control(struct adapter *padapter);
u8 chk_bmc_sleepq_cmd(struct adapter *padapter);
extern u8 set_tx_beacon_cmd(struct adapter *padapter);
unsigned int setup_beacon_frame(struct adapter *padapter, unsigned char
*beacon_frame);
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/9] staging: rtl8723bs: hal: Replace function rtl8723b_set_ap_wowlan_cmd()
Remove function rtl8723b_set_ap_wowlan_cmd as all it does is call
rtl8723b_set_AP_FwWoWlanRelated_cmd.
Rename rtl8723b_set_AP_FwWoWlanRelated_cmd to
rtl8723b_set_ap_wowlan_cmd to maintain compatibility with call site.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
index 0f2767c0454c..79c1e3edb189 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
@@ -1393,7 +1393,7 @@ static void rtl8723b_set_Fw_AP_Offload_Cmd(struct adapter
*padapter, u8 bFuncEn)
H2C_AP_OFFLOAD_LEN, u1H2CAPOffloadCtrlParm);
}
-static void rtl8723b_set_AP_FwWoWlan_cmd(struct adapter *padapter, u8 enable)
+void rtl8723b_set_ap_wowlan_cmd(struct adapter *padapter, u8 enable)
{
DBG_871X_LEVEL(_drv_always_, "+%s()+: enable =%d\n", __func__, enable);
if (enable) {
@@ -1408,11 +1408,6 @@ static void rtl8723b_set_AP_FwWoWlan_cmd(struct adapter
*padapter, u8 enable)
DBG_871X_LEVEL(_drv_always_, "-%s()-\n", __func__);
return ;
}
-
-void rtl8723b_set_ap_wowlan_cmd(struct adapter *padapter, u8 enable)
-{
- rtl8723b_set_AP_FwWoWlan_cmd(padapter, enable);
-}
#endif /* CONFIG_AP_WOWLAN */
/* */
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/9] staging: rtl8723bs: hal: Replace function PHY_SetTxPowerIndex()
Remove function PHY_SetTxPowerIndex as it does nothing except call
PHY_SetTxPowerIndex_8723B.
Rename PHY_SetTxPowerIndex_8723B to PHY_SetTxPowerIndex to maintain
compatibility with call site.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 7 ---
drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c| 2 +-
drivers/staging/rtl8723bs/include/hal_com_phycfg.h | 8
drivers/staging/rtl8723bs/include/hal_phy_cfg.h| 2 +-
4 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
index 336764464e7d..7b1e6c4a2e8d 100644
--- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
@@ -2051,13 +2051,6 @@ u8 PHY_GetTxPowerIndex(
return PHY_GetTxPowerIndex_8723B(padapter, RFPath, Rate, BandWidth,
Channel);
}
-void PHY_SetTxPowerIndex(
- struct adapter *padapter, u32 PowerIndex, u8 RFPath, u8 Rate
-)
-{
- PHY_SetTxPowerIndex_8723B(padapter, PowerIndex, RFPath, Rate);
-}
-
void Hal_ChannelPlanToRegulation(struct adapter *Adapter, u16 ChannelPlan)
{
struct hal_com_data *pHalData = GET_HAL_DATA(Adapter);
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
index 25c75b977666..b02ff10fedbf 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_phycfg.c
@@ -585,7 +585,7 @@ int PHY_RFConfig8723B(struct adapter *Adapter)
*
<20120830, Kordan>
**/
-void PHY_SetTxPowerIndex_8723B(
+void PHY_SetTxPowerIndex(
struct adapter *Adapter,
u32 PowerIndex,
u8 RFPath,
diff --git a/drivers/staging/rtl8723bs/include/hal_com_phycfg.h
b/drivers/staging/rtl8723bs/include/hal_com_phycfg.h
index f841546584a7..f3521b7ae295 100644
--- a/drivers/staging/rtl8723bs/include/hal_com_phycfg.h
+++ b/drivers/staging/rtl8723bs/include/hal_com_phycfg.h
@@ -222,14 +222,6 @@ enum CHANNEL_WIDTH BandWidth,
u8 Channel
);
-void
-PHY_SetTxPowerIndex(
-struct adapter * padapter,
-u32PowerIndex,
-u8 RFPath,
-u8 Rate
- );
-
void
Hal_ChannelPlanToRegulation(
struct adapter * Adapter,
diff --git a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
index 640427f407e3..1ebd7094705f 100644
--- a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
+++ b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
@@ -65,7 +65,7 @@ int PHY_RFConfig8723B(struct adapter *Adapter );
s32 PHY_MACConfig8723B(struct adapter *padapter);
void
-PHY_SetTxPowerIndex_8723B(
+PHY_SetTxPowerIndex(
struct adapter * Adapter,
u32PowerIndex,
u8 RFPath,
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/9] staging: rtl8723bs: rtw_pwrctrl: Change true/false checks
Change comparisons to true to the variable itself.
Change comparisons to false to the negation of the variable.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/core/rtw_pwrctrl.c | 117 +--
1 file changed, 54 insertions(+), 63 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
index ae7fb7046c93..62b42e29e4fd 100644
--- a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
+++ b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
@@ -103,7 +103,7 @@ static bool rtw_pwr_unassociated_idle(struct adapter
*adapter)
bool ret = false;
- if (adapter_to_pwrctl(adapter)->bpower_saving == true) {
+ if (adapter_to_pwrctl(adapter)->bpower_saving) {
/* DBG_871X("%s: already in LPS or IPS mode\n", __func__); */
goto exit;
}
@@ -167,7 +167,7 @@ void rtw_ps_processor(struct adapter *padapter)
goto exit;
}
- if (pwrpriv->bInSuspend == true) {/* system suspend or autosuspend */
+ if (pwrpriv->bInSuspend) {/* system suspend or autosuspend */
pdbgpriv->dbg_ps_insuspend_cnt++;
DBG_871X("%s, pwrpriv->bInSuspend == true ignore this
process\n", __func__);
return;
@@ -219,10 +219,9 @@ void traffic_check_for_leave_lps(struct adapter *padapter,
u8 tx, u32 tx_packets
if (jiffies_to_msecs(jiffies - start_time) > 2000) { /* 2 sec
== watch dog timer */
if (xmit_cnt > 8) {
- if ((adapter_to_pwrctl(padapter)->bLeisurePs)
- &&
(adapter_to_pwrctl(padapter)->pwr_mode != PS_MODE_ACTIVE)
- && (hal_btcoex_IsBtControlLps(padapter)
== false)
- ) {
+ if (adapter_to_pwrctl(padapter)->bLeisurePs
+ && (adapter_to_pwrctl(padapter)->pwr_mode
!= PS_MODE_ACTIVE)
+ && !(hal_btcoex_IsBtControlLps(padapter))) {
DBG_871X("leave lps via Tx = %d\n",
xmit_cnt);
bLeaveLPS = true;
}
@@ -234,10 +233,9 @@ void traffic_check_for_leave_lps(struct adapter *padapter,
u8 tx, u32 tx_packets
} else { /* from rx path */
if (pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod > 4/*2*/) {
- if ((adapter_to_pwrctl(padapter)->bLeisurePs)
- && (adapter_to_pwrctl(padapter)->pwr_mode !=
PS_MODE_ACTIVE)
- && (hal_btcoex_IsBtControlLps(padapter) ==
false)
- ) {
+ if (adapter_to_pwrctl(padapter)->bLeisurePs
+ && (adapter_to_pwrctl(padapter)->pwr_mode !=
PS_MODE_ACTIVE)
+ && !(hal_btcoex_IsBtControlLps(padapter))) {
DBG_871X("leave lps via Rx = %d\n",
pmlmepriv->LinkDetectInfo.NumRxUnicastOkInPeriod);
bLeaveLPS = true;
}
@@ -267,7 +265,7 @@ void rtw_set_rpwm(struct adapter *padapter, u8 pslv)
pslv = PS_STATE(pslv);
- if (pwrpriv->brpwmtimeout == true) {
+ if (pwrpriv->brpwmtimeout) {
DBG_871X("%s: RPWM timeout, force to set RPWM(0x%02X)
again!\n", __func__, pslv);
} else {
if ((pwrpriv->rpwm == pslv)
@@ -278,8 +276,7 @@ void rtw_set_rpwm(struct adapter *padapter, u8 pslv)
}
}
- if ((padapter->bSurpriseRemoved == true) ||
- (padapter->hw_init_completed == false)) {
+ if ((padapter->bSurpriseRemoved) || !(padapter->hw_init_completed)) {
RT_TRACE(_module_rtl871x_pwrctrl_c_, _drv_err_,
("%s: SurpriseRemoved(%d)
hw_init_completed(%d)\n",
__func__, padapter->bSurpriseRemoved,
padapter->hw_init_completed));
@@ -289,7 +286,7 @@ void rtw_set_rpwm(struct adapter *padapter, u8 pslv)
return;
}
- if (padapter->bDriverStopped == true) {
+ if (padapter->bDriverStopped) {
RT_TRACE(_module_rtl871x_pwrctrl_c_, _drv_err_,
("%s: change power state(0x%02X) when
DriverStopped\n", __func__, pslv));
@@ -355,14 +352,14 @@ static u8 PS_RDY_CHECK(struct adapter *padapter)
struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
#if defined(CONFIG_WOWLAN) || defined(CONFIG_AP_WOWLAN)
- if (true == pwrpriv->bInSuspend && pwrpriv->wowlan_mode)
+ if (pwrpriv->bInSuspend && pwrpriv->wowlan_mode)
return true;
- else if (true == pwrpriv->bInSuspend && pwrpriv->wowlan_ap_mode)
+ else if (pwrpriv->bInSuspend && pwrpriv->wowlan_ap_mode)
return
[PATCH 4/9] staging: rtl8723bs: hal: Replace function rtl8723b_set_wowlan_cmd()
Remove function rtl8723b_set_wowlan_cmd as all it does is call
rtl8723b_set_FwWoWlanRelated_cmd.
Rename rtl8723b_set_FwWoWlanRelated_cmd to rtl8723b_set_wowlan_cmd to
maintain compatibility with call site.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
b/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
index 080e974914b6..0f2767c0454c 100644
--- a/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
+++ b/drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c
@@ -1300,7 +1300,7 @@ static void rtl8723b_set_FwScanOffloadInfo_cmd(struct
adapter *padapter, PRSVDPA
}
#endif /* CONFIG_PNO_SUPPORT */
-static void rtl8723b_set_FwWoWlanRelated_cmd(struct adapter *padapter, u8
enable)
+void rtl8723b_set_wowlan_cmd(struct adapter *padapter, u8 enable)
{
struct security_priv *psecpriv = >securitypriv;
struct pwrctrl_priv *ppwrpriv = adapter_to_pwrctl(padapter);
@@ -1346,11 +1346,6 @@ static void rtl8723b_set_FwWoWlanRelated_cmd(struct
adapter *padapter, u8 enable
DBG_871X_LEVEL(_drv_always_, "-%s()-\n", __func__);
}
-
-void rtl8723b_set_wowlan_cmd(struct adapter *padapter, u8 enable)
-{
- rtl8723b_set_FwWoWlanRelated_cmd(padapter, enable);
-}
#endif /* CONFIG_WOWLAN */
#ifdef CONFIG_AP_WOWLAN
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: comedi: daqboard2000: Remove function db2k_initialize_dac()
Remove function db2k_initialize_dac as all it does is call
db2k_dac_disarm.
Modify call site accordingly.
Issue found with Coccinelle.
Signed-off-by: Nishka Dasgupta
---
drivers/staging/comedi/drivers/daqboard2000.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/daqboard2000.c
b/drivers/staging/comedi/drivers/daqboard2000.c
index aabcda3f9fc8..28603dfadce2 100644
--- a/drivers/staging/comedi/drivers/daqboard2000.c
+++ b/drivers/staging/comedi/drivers/daqboard2000.c
@@ -665,11 +665,6 @@ static void db2k_initialize_adc(struct comedi_device *dev)
db2k_initialize_tmrs(dev);
}
-static void db2k_initialize_dac(struct comedi_device *dev)
-{
- db2k_dac_disarm(dev);
-}
-
static int db2k_8255_cb(struct comedi_device *dev, int dir, int port, int data,
unsigned long iobase)
{
@@ -719,7 +714,7 @@ static int db2k_auto_attach(struct comedi_device *dev,
unsigned long context)
return result;
db2k_initialize_adc(dev);
- db2k_initialize_dac(dev);
+ db2k_dac_disarm(dev);
s = >subdevices[0];
/* ai subdevice */
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HELP REQUESTED from the community] Was: Staging status of speakup
Gregory Nowak writes: > keymap > I believe this is the currently active kernel keymap. I'm not sure of > the format, probably what dumpkeys(1) and showkey(1) use. Echoing > different values here should allow for remapping speakup's review > commands besides remapping the keyboard as a whole. AFAIK the Speakup keymap is just for remapping keys to Speakup functions. It's a binary format, not related to dumpkeys etc. You need a special program to compile a textual keymap into something that can be loaded into /sys/accessibility/speakup/keymap. I may have source for that lying around here somewhere. This is "here there be dragons" territory. I think the only specification of the format is in the source code. -- Chris ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [HELP REQUESTED from the community] Was: Staging status of speakup
On Fri, Jul 12, 2019 at 05:46:23PM -0700, Gregory Nowak wrote: > On Fri, Jul 12, 2019 at 11:23:19AM +0200, Samuel Thibault wrote: > > Hello, > > > > To readers of the linux-speakup: could you help on this so we can get > > Speakup in mainline? Neither Okash or I completely know what user > > consequences the files in /sys/accessibility/speakup/ have, so could > > people give brief explanations for each file (something like 3-6 lines > > of explanation)? > > I have a recollection of documenting most of this on the speakup list > in response to a similar query a number of years ago. Unfortunately, > the speakup mailing list archives aren't easily searchable, and I > don't have a local copy of that mail. > > Kirk, doing grep with a few of the file names in > /sys/accessibility/speakup against the list's mbox file archive should > find that message if it's in fact there. If you can please find it, > and post the date when it was sent, we can provide a URL to that > thread as a starting point. If my recollection is wrong, and such a > message isn't in the archives, I'll write up what I know about. I've located the message I was thinking of in the archives, but that describes some speakup key commands, not /sys/accessibility/speakup. So, here's what I know, and hopefully someone else can fill in the rest. attrib_bleep Beeps the PC speaker when there is an attribute change such as foreground or background color when using speakup review commands. One = on, zero = off. I'm not currently at a machine with a working PC speaker, so can't test this right now. bell_pos As far as I know, this works much like a typewriter bell. If for example 72 is echoed to bell_pos, it will beep the PC speaker when typing on a line past character 72. Again, no PC speaker at the moment here, so can't actually test this. bleeps Not 100% sure, but I believe this controls whether one hears beeps through the PC speaker when using speakup's review commands. If no one jumps in on this, I'll experiment when at a machine with a working PC speaker, and will reply back with details. bleep_time Again, not 100% sure, but I believe this controls the duration of the PC speaker beeps speakup produces. I'm not sure of the units this is in either, possibly jiffys. I'll come back with more details on this one if no one else does. cursor_time Don't know. delimiters Don't know. I've tried echoing various characters to this and looking for differences when reviewing the screen, but no luck. ex_num Don't know. key_echo Controls if speakup speaks keys when they are typed. One = on, zero = off or don't echo keys. keymap I believe this is the currently active kernel keymap. I'm not sure of the format, probably what dumpkeys(1) and showkey(1) use. Echoing different values here should allow for remapping speakup's review commands besides remapping the keyboard as a whole. no_interrupt Controls if typing interrupts output from speakup. With no_interrupt set to zero, typing on the keyboard will interrupt speakup if for example the say screen command is used before the entire screen is read. With no_interrupt set to one, if the say screen command is used, and one then types on the keyboard, speakup will continue to say the whole screen regardless until it finishes. punc_all This is a list of all the punctuation speakup should speak when punc_level is set to four. punc_level Controls the level of punctuation spoken as the screen is displayed, not reviewed. Levels range from zero no punctuation, to four, all punctuation. As far as I can tell, one corresponds to punc_some, two corresponds to punc_most, and three as well as four seem to both correspond to punc_all, though I do stand to be corrected. I am using the soft synthesizer driver, so it is possible that some hardware synthesizers have different levels each corresponding to three and four for punc_level. Also note that if punc_level is set to zero, and key_echo is set to one, typed punctuation is still spoken as it is typed. punc_most This is a list of all the punctuation speakup should speak when punc_level is set to two. punc_some This is a list of all the punctuation speakup should speak when punc_level is set to one. reading_punc Almost the same as punc_level, the differences being that reading_punc controls the level of punctuation when reviewing the screen with speakup's screen review commands. The other difference is that reading_punc set to three speaks punc_all, and reading_punc set to four speaks all punctuation, including spaces. repeats a list of characters speakup repeats. Normally, when there are more than three characters in a row, speakup just reads three of those characters. For example, ".." would be read as dot, dot, dot. If a . is added to the list of characters in repeats, ".." would be read as dot, dot, dot, times six. say_control If set to one, speakup speaks shift, alt and control when those keys are pressed. Perhaps more keys are spoken, but those three are
[PATCH] staging: rtl8723bs: hal: Remove unneeded variable pU1Tmp
Both pu8 and pU1Tmp are of same data type u8. So replace pU1Tmp with u8.
Signed-off-by: Hariprasad Kelam
---
drivers/staging/rtl8723bs/hal/hal_btcoex.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
index 5257287..8987b5f 100644
--- a/drivers/staging/rtl8723bs/hal/hal_btcoex.c
+++ b/drivers/staging/rtl8723bs/hal/hal_btcoex.c
@@ -389,7 +389,6 @@ static u8 halbtcoutsrc_Get(void *pBtcContext, u8 getType,
void *pOutBuf)
u8 *pu8;
s32 *pS4Tmp;
u32 *pU4Tmp;
- u8 *pU1Tmp;
u8 ret;
@@ -403,7 +402,6 @@ static u8 halbtcoutsrc_Get(void *pBtcContext, u8 getType,
void *pOutBuf)
pu8 = pOutBuf;
pS4Tmp = pOutBuf;
pU4Tmp = pOutBuf;
- pU1Tmp = pOutBuf;
ret = true;
switch (getType) {
@@ -516,32 +514,32 @@ static u8 halbtcoutsrc_Get(void *pBtcContext, u8 getType,
void *pOutBuf)
break;
case BTC_GET_U1_WIFI_DOT11_CHNL:
- *pU1Tmp = padapter->mlmeextpriv.cur_channel;
+ *pu8 = padapter->mlmeextpriv.cur_channel;
break;
case BTC_GET_U1_WIFI_CENTRAL_CHNL:
- *pU1Tmp = pHalData->CurrentChannel;
+ *pu8 = pHalData->CurrentChannel;
break;
case BTC_GET_U1_WIFI_HS_CHNL:
- *pU1Tmp = 0;
+ *pu8 = 0;
ret = false;
break;
case BTC_GET_U1_MAC_PHY_MODE:
- *pU1Tmp = BTC_SMSP;
+ *pu8 = BTC_SMSP;
/* *pU1Tmp = BTC_DMSP; */
/* *pU1Tmp = BTC_DMDP; */
/* *pU1Tmp = BTC_MP_UNKNOWN; */
break;
case BTC_GET_U1_AP_NUM:
- *pU1Tmp = halbtcoutsrc_GetWifiScanAPNum(padapter);
+ *pu8 = halbtcoutsrc_GetWifiScanAPNum(padapter);
break;
/* 1Ant === */
case BTC_GET_U1_LPS_MODE:
- *pU1Tmp = padapter->dvobj->pwrctl_priv.pwr_mode;
+ *pu8 = padapter->dvobj->pwrctl_priv.pwr_mode;
break;
default:
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: hantro: Remove call to memset after dma_alloc_coherent
fix below issue reported by coccicheck /drivers/staging/media/hantro/hantro_vp8.c:149:16-34: WARNING: dma_alloc_coherent use in aux_buf -> cpu already zeroes out memory, so memset is not needed Signed-off-by: Hariprasad Kelam --- drivers/staging/media/hantro/hantro_vp8.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/media/hantro/hantro_vp8.c b/drivers/staging/media/hantro/hantro_vp8.c index 66c4533..363ddda 100644 --- a/drivers/staging/media/hantro/hantro_vp8.c +++ b/drivers/staging/media/hantro/hantro_vp8.c @@ -151,8 +151,6 @@ int hantro_vp8_dec_init(struct hantro_ctx *ctx) if (!aux_buf->cpu) return -ENOMEM; - memset(aux_buf->cpu, 0, aux_buf->size); - /* * Allocate probability table buffer, * total 1208 bytes, 4K page is far enough. -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: wilc1000: Merge memcpy + le32_to_cpus to get_unaligned_le32
Merge the combo use of memcpy and le32_to_cpus.
Use get_unaligned_le32 instead.
This simplifies the code.
Signed-off-by: Chuhong Yuan
---
Changes in v2:
- Merge the previous two patches which
have the same subject line.
drivers/staging/wilc1000/wilc_mon.c | 3 +--
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 +--
drivers/staging/wilc1000/wilc_wlan.c | 9 +++--
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_mon.c
b/drivers/staging/wilc1000/wilc_mon.c
index 7d7933d40924..d6f14f69ad64 100644
--- a/drivers/staging/wilc1000/wilc_mon.c
+++ b/drivers/staging/wilc1000/wilc_mon.c
@@ -35,8 +35,7 @@ void wilc_wfi_monitor_rx(struct net_device *mon_dev, u8
*buff, u32 size)
return;
/* Get WILC header */
- memcpy(, (buff - HOST_HDR_OFFSET), HOST_HDR_OFFSET);
- le32_to_cpus();
+ header = get_unaligned_le32(buff - HOST_HDR_OFFSET);
/*
* The packet offset field contain info about what type of management
* the frame we are dealing with and ack status
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index d72fdd333050..12fb4add05ec 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1038,8 +1038,7 @@ void wilc_wfi_p2p_rx(struct wilc_vif *vif, u8 *buff, u32
size)
s32 freq;
__le16 fc;
- memcpy(, (buff - HOST_HDR_OFFSET), HOST_HDR_OFFSET);
- le32_to_cpus();
+ header = get_unaligned_le32(buff - HOST_HDR_OFFSET);
pkt_offset = GET_PKT_OFFSET(header);
if (pkt_offset & IS_MANAGMEMENT_CALLBACK) {
diff --git a/drivers/staging/wilc1000/wilc_wlan.c
b/drivers/staging/wilc1000/wilc_wlan.c
index d46876edcfeb..7d438ae90c3e 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -703,8 +703,7 @@ static void wilc_wlan_handle_rx_buff(struct wilc *wilc, u8
*buffer, int size)
do {
buff_ptr = buffer + offset;
- memcpy(, buff_ptr, 4);
- le32_to_cpus();
+ header = get_unaligned_le32(buff_ptr);
is_cfg_packet = (header >> 31) & 0x1;
pkt_offset = (header >> 22) & 0x1ff;
@@ -874,10 +873,8 @@ int wilc_wlan_firmware_download(struct wilc *wilc, const
u8 *buffer,
offset = 0;
do {
- memcpy(, [offset], 4);
- memcpy(, [offset + 4], 4);
- le32_to_cpus();
- le32_to_cpus();
+ addr = get_unaligned_le32([offset]);
+ size = get_unaligned_le32([offset + 4]);
acquire_bus(wilc, WILC_BUS_ACQUIRE_ONLY);
offset += 8;
while (((int)size) && (offset < buffer_size)) {
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: wilc1000: Merge memcpy + le32_to_cpus to get_unaligned_le32
Merge the combo use of memcpy and le32_to_cpus.
Use get_unaligned_le32 instead.
This simplifies the code.
Signed-off-by: Chuhong Yuan
---
drivers/staging/wilc1000/wilc_mon.c | 3 +--
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 +--
drivers/staging/wilc1000/wilc_wlan.c | 9 +++--
3 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_mon.c
b/drivers/staging/wilc1000/wilc_mon.c
index 7d7933d40924..d6f14f69ad64 100644
--- a/drivers/staging/wilc1000/wilc_mon.c
+++ b/drivers/staging/wilc1000/wilc_mon.c
@@ -35,8 +35,7 @@ void wilc_wfi_monitor_rx(struct net_device *mon_dev, u8
*buff, u32 size)
return;
/* Get WILC header */
- memcpy(, (buff - HOST_HDR_OFFSET), HOST_HDR_OFFSET);
- le32_to_cpus();
+ header = get_unaligned_le32(buff - HOST_HDR_OFFSET);
/*
* The packet offset field contain info about what type of management
* the frame we are dealing with and ack status
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index d72fdd333050..12fb4add05ec 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1038,8 +1038,7 @@ void wilc_wfi_p2p_rx(struct wilc_vif *vif, u8 *buff, u32
size)
s32 freq;
__le16 fc;
- memcpy(, (buff - HOST_HDR_OFFSET), HOST_HDR_OFFSET);
- le32_to_cpus();
+ header = get_unaligned_le32(buff - HOST_HDR_OFFSET);
pkt_offset = GET_PKT_OFFSET(header);
if (pkt_offset & IS_MANAGMEMENT_CALLBACK) {
diff --git a/drivers/staging/wilc1000/wilc_wlan.c
b/drivers/staging/wilc1000/wilc_wlan.c
index d46876edcfeb..7d438ae90c3e 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -703,8 +703,7 @@ static void wilc_wlan_handle_rx_buff(struct wilc *wilc, u8
*buffer, int size)
do {
buff_ptr = buffer + offset;
- memcpy(, buff_ptr, 4);
- le32_to_cpus();
+ header = get_unaligned_le32(buff_ptr);
is_cfg_packet = (header >> 31) & 0x1;
pkt_offset = (header >> 22) & 0x1ff;
@@ -874,10 +873,8 @@ int wilc_wlan_firmware_download(struct wilc *wilc, const
u8 *buffer,
offset = 0;
do {
- memcpy(, [offset], 4);
- memcpy(, [offset + 4], 4);
- le32_to_cpus();
- le32_to_cpus();
+ addr = get_unaligned_le32([offset]);
+ size = get_unaligned_le32([offset + 4]);
acquire_bus(wilc, WILC_BUS_ACQUIRE_ONLY);
offset += 8;
while (((int)size) && (offset < buffer_size)) {
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] media: staging: tegra-vde: Fix build error
If IOMMU_SUPPORT is not set, and COMPILE_TEST is y,
IOMMU_IOVA may be set to m. So building will fails:
drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
iommu.c:(.text+0x41): undefined reference to `alloc_iova'
iommu.c:(.text+0x56): undefined reference to `__free_iova'
Select IOMMU_IOVA while COMPILE_TEST is set to fix this.
Reported-by: Hulk Robot
Suggested-by: Dmitry Osipenko
Fixes: b301f8de1925 ("media: staging: media: tegra-vde: Add IOMMU support")
Signed-off-by: YueHaibing
---
drivers/staging/media/tegra-vde/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/tegra-vde/Kconfig
b/drivers/staging/media/tegra-vde/Kconfig
index 2e7f644..ba49ea5 100644
--- a/drivers/staging/media/tegra-vde/Kconfig
+++ b/drivers/staging/media/tegra-vde/Kconfig
@@ -3,7 +3,7 @@ config TEGRA_VDE
tristate "NVIDIA Tegra Video Decoder Engine driver"
depends on ARCH_TEGRA || COMPILE_TEST
select DMA_SHARED_BUFFER
- select IOMMU_IOVA if IOMMU_SUPPORT
+ select IOMMU_IOVA if (IOMMU_SUPPORT || COMPILE_TEST)
select SRAM
help
Say Y here to enable support for the NVIDIA Tegra video decoder
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] qlge: Fix build error without CONFIG_ETHERNET
From: YueHaibing
Date: Wed, 24 Jul 2019 21:01:26 +0800
> Now if CONFIG_ETHERNET is not set, QLGE driver
> building fails:
>
> drivers/staging/qlge/qlge_main.o: In function `qlge_remove':
> drivers/staging/qlge/qlge_main.c:4831: undefined reference to
> `unregister_netdev'
>
> Reported-by: Hulk Robot
> Fixes: 955315b0dc8c ("qlge: Move drivers/net/ethernet/qlogic/qlge/ to
> drivers/staging/qlge/")
> Signed-off-by: YueHaibing
I'll let Greg take this.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] qlge: Fix build error without CONFIG_ETHERNET
From: David Miller
Date: Wed, 24 Jul 2019 14:12:02 -0700 (PDT)
> From: YueHaibing
> Date: Wed, 24 Jul 2019 21:01:26 +0800
>
>> Now if CONFIG_ETHERNET is not set, QLGE driver
>> building fails:
>>
>> drivers/staging/qlge/qlge_main.o: In function `qlge_remove':
>> drivers/staging/qlge/qlge_main.c:4831: undefined reference to
>> `unregister_netdev'
>>
>> Reported-by: Hulk Robot
>> Fixes: 955315b0dc8c ("qlge: Move drivers/net/ethernet/qlogic/qlge/ to
>> drivers/staging/qlge/")
>> Signed-off-by: YueHaibing
>
> I'll let Greg take this.
Actually, I take that back.
Since the move to staging happened in my tree I will take this ;-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Limits for ION Memory Allocator
On Wed, Jul 24, 2019 at 1:18 PM John Stultz wrote:
>
> On Wed, Jul 24, 2019 at 12:36 PM Laura Abbott wrote:
> >
> > On 7/17/19 12:31 PM, Alexander Popov wrote:
> > > Hello!
> > >
> > > The syzkaller [1] has a trouble with fuzzing the Linux kernel with ION
> > > Memory
> > > Allocator.
> > >
> > > Syzkaller uses several methods [2] to limit memory consumption of the
> > > userspace
> > > processes calling the syscalls for testing the kernel:
> > > - setrlimit(),
> > > - cgroups,
> > > - various sysctl.
> > > But these methods don't work for ION Memory Allocator, so any userspace
> > > process
> > > that has access to /dev/ion can bring the system to the out-of-memory
> > > state.
> > >
> > > An example of a program doing that:
> > >
> > >
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > > #include
> > >
> > > #define ION_IOC_MAGIC 'I'
> > > #define ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
> > > struct ion_allocation_data)
> > >
> > > struct ion_allocation_data {
> > > __u64 len;
> > > __u32 heap_id_mask;
> > > __u32 flags;
> > > __u32 fd;
> > > __u32 unused;
> > > };
> > >
> > > int main(void)
> > > {
> > > unsigned long i = 0;
> > > int fd = -1;
> > > struct ion_allocation_data data = {
> > > .len = 0x13f65d8c,
> > > .heap_id_mask = 1,
> > > .flags = 0,
> > > .fd = -1,
> > > .unused = 0
> > > };
> > >
> > > fd = open("/dev/ion", 0);
> > > if (fd == -1) {
> > > perror("[-] open /dev/ion");
> > > return 1;
> > > }
> > >
> > > while (1) {
> > > printf("iter %lu\n", i);
> > > ioctl(fd, ION_IOC_ALLOC, );
> > > i++;
> > > }
> > >
> > > return 0;
> > > }
> > >
> > >
> > > I looked through the code of ion_alloc() and didn't find any limit checks.
> > > Is it currently possible to limit ION kernel allocations for some process?
> > >
> > > If not, is it a right idea to do that?
> > > Thanks!
> > >
> >
> > Yes, I do think that's the right approach. We're working on moving Ion
> > out of staging and this is something I mentioned to John Stultz. I don't
> > think we've thought too hard about how to do the actual limiting so
> > suggestions are welcome.
>
> In part the dmabuf heaps allow for separate heap devices, so we can
> have finer grained permissions to the specific heaps. But that
> doesn't provide any controls on how much memory one process could
> allocate using the device if it has permission.
>
> I suspect the same issue is present with any of the dmabuf exporters
> (gpu/display drivers, etc), so this is less of an ION/dmabuf heap
> issue and more of a dmabuf core accounting issue.
>
Also, do unmapped memfd buffers have similar accounting issues?
thanks
-john
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Limits for ION Memory Allocator
On Wed, Jul 24, 2019 at 12:36 PM Laura Abbott wrote:
>
> On 7/17/19 12:31 PM, Alexander Popov wrote:
> > Hello!
> >
> > The syzkaller [1] has a trouble with fuzzing the Linux kernel with ION
> > Memory
> > Allocator.
> >
> > Syzkaller uses several methods [2] to limit memory consumption of the
> > userspace
> > processes calling the syscalls for testing the kernel:
> > - setrlimit(),
> > - cgroups,
> > - various sysctl.
> > But these methods don't work for ION Memory Allocator, so any userspace
> > process
> > that has access to /dev/ion can bring the system to the out-of-memory state.
> >
> > An example of a program doing that:
> >
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > #define ION_IOC_MAGIC 'I'
> > #define ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
> > struct ion_allocation_data)
> >
> > struct ion_allocation_data {
> > __u64 len;
> > __u32 heap_id_mask;
> > __u32 flags;
> > __u32 fd;
> > __u32 unused;
> > };
> >
> > int main(void)
> > {
> > unsigned long i = 0;
> > int fd = -1;
> > struct ion_allocation_data data = {
> > .len = 0x13f65d8c,
> > .heap_id_mask = 1,
> > .flags = 0,
> > .fd = -1,
> > .unused = 0
> > };
> >
> > fd = open("/dev/ion", 0);
> > if (fd == -1) {
> > perror("[-] open /dev/ion");
> > return 1;
> > }
> >
> > while (1) {
> > printf("iter %lu\n", i);
> > ioctl(fd, ION_IOC_ALLOC, );
> > i++;
> > }
> >
> > return 0;
> > }
> >
> >
> > I looked through the code of ion_alloc() and didn't find any limit checks.
> > Is it currently possible to limit ION kernel allocations for some process?
> >
> > If not, is it a right idea to do that?
> > Thanks!
> >
>
> Yes, I do think that's the right approach. We're working on moving Ion
> out of staging and this is something I mentioned to John Stultz. I don't
> think we've thought too hard about how to do the actual limiting so
> suggestions are welcome.
In part the dmabuf heaps allow for separate heap devices, so we can
have finer grained permissions to the specific heaps. But that
doesn't provide any controls on how much memory one process could
allocate using the device if it has permission.
I suspect the same issue is present with any of the dmabuf exporters
(gpu/display drivers, etc), so this is less of an ION/dmabuf heap
issue and more of a dmabuf core accounting issue.
Another practical complication is that with Android these days, I
believe the gralloc code lives in the HIDL-ized
android.hardware.graphics.allocator@2.0-service HAL, which does the
buffer allocations on behalf of requests sent over the binder IPC
interface. So with all dma-buf allocations effectively going through
that single process, I'm not sure we would want to put per-process
limits on the allocator. Instead, I suspect we'd want the memory
covered by the dmabuf to be accounted against processes that have the
dmabuf fd still open?
I know Android has some logic with their memtrack HAL to I believe try
to do accounting of gpu memory against various processes, but I've not
looked at that in detail recently.
Todd/Joel: Any input here?
thanks
-john
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 11/12] staging: media: cedrus: Fix misuse of GENMASK macro
On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: > Arguments are supposed to be ordered high then low. > > Signed-off-by: Joe Perches > --- > drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > index 3e9931416e45..ddd29788d685 100644 > --- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > @@ -110,7 +110,7 @@ > #define VE_DEC_MPEG_MBADDR (VE_ENGINE_DEC_MPEG + 0x10) > > #define VE_DEC_MPEG_MBADDR_X(w) (((w) << 8) & > GENMASK(15, 8)) > -#define VE_DEC_MPEG_MBADDR_Y(h) (((h) << 0) & > GENMASK(0, 7)) > +#define VE_DEC_MPEG_MBADDR_Y(h) (((h) << 0) & > GENMASK(7, 0)) > > #define VE_DEC_MPEG_CTRL (VE_ENGINE_DEC_MPEG + 0x14) Greg? ping? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Limits for ION Memory Allocator
On 7/17/19 12:31 PM, Alexander Popov wrote:
Hello!
The syzkaller [1] has a trouble with fuzzing the Linux kernel with ION Memory
Allocator.
Syzkaller uses several methods [2] to limit memory consumption of the userspace
processes calling the syscalls for testing the kernel:
- setrlimit(),
- cgroups,
- various sysctl.
But these methods don't work for ION Memory Allocator, so any userspace process
that has access to /dev/ion can bring the system to the out-of-memory state.
An example of a program doing that:
#include
#include
#include
#include
#include
#include
#define ION_IOC_MAGIC 'I'
#define ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
struct ion_allocation_data)
struct ion_allocation_data {
__u64 len;
__u32 heap_id_mask;
__u32 flags;
__u32 fd;
__u32 unused;
};
int main(void)
{
unsigned long i = 0;
int fd = -1;
struct ion_allocation_data data = {
.len = 0x13f65d8c,
.heap_id_mask = 1,
.flags = 0,
.fd = -1,
.unused = 0
};
fd = open("/dev/ion", 0);
if (fd == -1) {
perror("[-] open /dev/ion");
return 1;
}
while (1) {
printf("iter %lu\n", i);
ioctl(fd, ION_IOC_ALLOC, );
i++;
}
return 0;
}
I looked through the code of ion_alloc() and didn't find any limit checks.
Is it currently possible to limit ION kernel allocations for some process?
If not, is it a right idea to do that?
Thanks!
Yes, I do think that's the right approach. We're working on moving Ion
out of staging and this is something I mentioned to John Stultz. I don't
think we've thought too hard about how to do the actual limiting so
suggestions are welcome.
Thanks,
Laura
Best regards,
Alexander
[1]: https://github.com/google/syzkaller
[2]: https://github.com/google/syzkaller/blob/master/executor/common_linux.h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 11/12] staging: media: cedrus: Fix misuse of GENMASK macro
On Wed, Jul 24, 2019 at 11:39:03AM -0700, Joe Perches wrote: > On Wed, 2019-07-24 at 20:35 +0200, Greg Kroah-Hartman wrote: > > On Wed, Jul 24, 2019 at 10:09:44AM -0700, Joe Perches wrote: > > > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: > > > > Arguments are supposed to be ordered high then low. > > > > > > > > Signed-off-by: Joe Perches > > > > --- > > > > drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > > > b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > > > index 3e9931416e45..ddd29788d685 100644 > > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > > > @@ -110,7 +110,7 @@ > > > > #define VE_DEC_MPEG_MBADDR (VE_ENGINE_DEC_MPEG + > > > > 0x10) > > > > > > > > #define VE_DEC_MPEG_MBADDR_X(w)(((w) << 8) & > > > > GENMASK(15, 8)) > > > > -#define VE_DEC_MPEG_MBADDR_Y(h)(((h) << 0) & > > > > GENMASK(0, 7)) > > > > +#define VE_DEC_MPEG_MBADDR_Y(h)(((h) << 0) & > > > > GENMASK(7, 0)) > > > > > > > > #define VE_DEC_MPEG_CTRL (VE_ENGINE_DEC_MPEG + > > > > 0x14) > > > > > > Greg? ping? > > > > > > > > > > I am not the maintainer of drivers/staging/media, that is Mauro. > > Maybe you want: > --- > diff --git a/MAINTAINERS b/MAINTAINERS > index f7dc5bad396a..2fb95ad6ebef 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -15312,6 +15312,7 @@ T:git > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > L: de...@driverdev.osuosl.org > S: Supported > F: drivers/staging/ > +X: drivers/staging/media/ > Not really, it's nice to see the patches flow by :) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 11/12] staging: media: cedrus: Fix misuse of GENMASK macro
On Wed, 2019-07-24 at 20:35 +0200, Greg Kroah-Hartman wrote: > On Wed, Jul 24, 2019 at 10:09:44AM -0700, Joe Perches wrote: > > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: > > > Arguments are supposed to be ordered high then low. > > > > > > Signed-off-by: Joe Perches > > > --- > > > drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > > b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > > index 3e9931416e45..ddd29788d685 100644 > > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > > @@ -110,7 +110,7 @@ > > > #define VE_DEC_MPEG_MBADDR (VE_ENGINE_DEC_MPEG + > > > 0x10) > > > > > > #define VE_DEC_MPEG_MBADDR_X(w) (((w) << 8) & > > > GENMASK(15, 8)) > > > -#define VE_DEC_MPEG_MBADDR_Y(h) (((h) << 0) & > > > GENMASK(0, 7)) > > > +#define VE_DEC_MPEG_MBADDR_Y(h) (((h) << 0) & > > > GENMASK(7, 0)) > > > > > > #define VE_DEC_MPEG_CTRL (VE_ENGINE_DEC_MPEG + 0x14) > > > > Greg? ping? > > > > > > I am not the maintainer of drivers/staging/media, that is Mauro. Maybe you want: --- diff --git a/MAINTAINERS b/MAINTAINERS index f7dc5bad396a..2fb95ad6ebef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -15312,6 +15312,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git L: de...@driverdev.osuosl.org S: Supported F: drivers/staging/ +X: drivers/staging/media/ STARFIRE/DURALAN NETWORK DRIVER M: Ion Badulescu ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 11/12] staging: media: cedrus: Fix misuse of GENMASK macro
On Wed, Jul 24, 2019 at 10:09:44AM -0700, Joe Perches wrote: > On Tue, 2019-07-09 at 22:04 -0700, Joe Perches wrote: > > Arguments are supposed to be ordered high then low. > > > > Signed-off-by: Joe Perches > > --- > > drivers/staging/media/sunxi/cedrus/cedrus_regs.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > index 3e9931416e45..ddd29788d685 100644 > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_regs.h > > @@ -110,7 +110,7 @@ > > #define VE_DEC_MPEG_MBADDR (VE_ENGINE_DEC_MPEG + 0x10) > > > > #define VE_DEC_MPEG_MBADDR_X(w)(((w) << 8) & > > GENMASK(15, 8)) > > -#define VE_DEC_MPEG_MBADDR_Y(h)(((h) << 0) & > > GENMASK(0, 7)) > > +#define VE_DEC_MPEG_MBADDR_Y(h)(((h) << 0) & > > GENMASK(7, 0)) > > > > #define VE_DEC_MPEG_CTRL (VE_ENGINE_DEC_MPEG + 0x14) > > Greg? ping? > > I am not the maintainer of drivers/staging/media, that is Mauro. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled
24.07.2019 17:23, Robin Murphy пишет:
> On 24/07/2019 15:09, Dmitry Osipenko wrote:
>> 24.07.2019 17:03, Yuehaibing пишет:
>>> On 2019/7/24 21:49, Robin Murphy wrote:
On 24/07/2019 11:30, Sakari Ailus wrote:
> Hi Yue,
>
> On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
>> If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
>> But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
>> in the Kconfig, for example, CONFIG_TEGRA_VDE is set to y but
>> IOMMU_IOVA
>> is m, then the building fails like this:
>>
>> drivers/staging/media/tegra-vde/iommu.o: In function
>> `tegra_vde_iommu_map':
>> iommu.c:(.text+0x41): undefined reference to `alloc_iova'
>> iommu.c:(.text+0x56): undefined reference to `__free_iova'
>>
>> Reported-by: Hulk Robot
>> Fixes: 7fc7af649ca7 ("media: staging/intel-ipu3: Add imgu top
>> level pci device driver")
>> Signed-off-by: YueHaibing
>> ---
>> drivers/staging/media/ipu3/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/media/ipu3/Kconfig
>> b/drivers/staging/media/ipu3/Kconfig
>> index 4b51c67..b7df18f 100644
>> --- a/drivers/staging/media/ipu3/Kconfig
>> +++ b/drivers/staging/media/ipu3/Kconfig
>> @@ -4,7 +4,7 @@ config VIDEO_IPU3_IMGU
>> depends on PCI && VIDEO_V4L2
>> depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
>> depends on X86
>> - select IOMMU_IOVA
>> + select IOMMU_IOVA if IOMMU_SUPPORT
>
> This doesn't seem right: the ipu3-cio2 driver needs IOMMU_IOVA
> independently of IOMMU_SUPPORT.
>
> Looking at tegra-vde, it seems to depend on IOMMU_SUPPORT but
> that's not
> declared in its Kconfig entry. I wonder if adding that would be the
> right
> way to fix this.
>
> Cc'ing the IOMMU list.
>> IOMMU_SUPPORT is optional for the Tegra-VDE driver.
>>
Right, I also had the impression that we'd made the IOVA library
completely standalone. And what does the IPU3 driver's Kconfig have
to do with some *other* driver failing to link anyway?
>>
>> I can see it failing if IPU3 is compiled as a loadable module, while
>> Tegra-VDE is a built-in driver. Hence IOVA lib should be also a kernel
>> module and thus the IOVA symbols will be missing during of linkage of
>> the VDE driver.
>>
>>> Oh, I misunderstand that IOMMU_IOVA is depend on IOMMU_SUPPORT, thank
>>> you for clarification.
>>>
>>> I will try to fix this in tegra-vde.
>>
>> Probably IOVA could be selected independently of IOMMU_SUPPORT, but IOVA
>> library isn't needed for the VDE driver if IOMMU_SUPPORT is disabled.
>
> Oh, I think I get the problem now - tegra-vde/iommu.c is built
> unconditionally and relies on the static inline stubs for IOMMU and IOVA
> calls if !IOMMU_SUPPORT, but in a compile-test config where IOVA=m for
> other reasons, it then picks up the real declarations from linux/iova.h
> instead of the stubs, and things go downhill from there. So there is a
> real issue, but indeed it's Tegra-VDE which needs to be restructured to
> cope with such configurations, and not IPU3's (or anyone else who may
> select IOVA=m in future) job to work around it.
I guess it could be:
select IOMMU_IOVA if (IOMMU_SUPPORT || COMPILE_TEST)
as a workaround.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled
On 24/07/2019 15:09, Dmitry Osipenko wrote:
24.07.2019 17:03, Yuehaibing пишет:
On 2019/7/24 21:49, Robin Murphy wrote:
On 24/07/2019 11:30, Sakari Ailus wrote:
Hi Yue,
On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
in the Kconfig, for example, CONFIG_TEGRA_VDE is set to y but IOMMU_IOVA
is m, then the building fails like this:
drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
iommu.c:(.text+0x41): undefined reference to `alloc_iova'
iommu.c:(.text+0x56): undefined reference to `__free_iova'
Reported-by: Hulk Robot
Fixes: 7fc7af649ca7 ("media: staging/intel-ipu3: Add imgu top level pci device
driver")
Signed-off-by: YueHaibing
---
drivers/staging/media/ipu3/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/ipu3/Kconfig
b/drivers/staging/media/ipu3/Kconfig
index 4b51c67..b7df18f 100644
--- a/drivers/staging/media/ipu3/Kconfig
+++ b/drivers/staging/media/ipu3/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_IPU3_IMGU
depends on PCI && VIDEO_V4L2
depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
depends on X86
-select IOMMU_IOVA
+select IOMMU_IOVA if IOMMU_SUPPORT
This doesn't seem right: the ipu3-cio2 driver needs IOMMU_IOVA
independently of IOMMU_SUPPORT.
Looking at tegra-vde, it seems to depend on IOMMU_SUPPORT but that's not
declared in its Kconfig entry. I wonder if adding that would be the right
way to fix this.
Cc'ing the IOMMU list.
IOMMU_SUPPORT is optional for the Tegra-VDE driver.
Right, I also had the impression that we'd made the IOVA library completely
standalone. And what does the IPU3 driver's Kconfig have to do with some
*other* driver failing to link anyway?
I can see it failing if IPU3 is compiled as a loadable module, while
Tegra-VDE is a built-in driver. Hence IOVA lib should be also a kernel
module and thus the IOVA symbols will be missing during of linkage of
the VDE driver.
Oh, I misunderstand that IOMMU_IOVA is depend on IOMMU_SUPPORT, thank you for
clarification.
I will try to fix this in tegra-vde.
Probably IOVA could be selected independently of IOMMU_SUPPORT, but IOVA
library isn't needed for the VDE driver if IOMMU_SUPPORT is disabled.
Oh, I think I get the problem now - tegra-vde/iommu.c is built
unconditionally and relies on the static inline stubs for IOMMU and IOVA
calls if !IOMMU_SUPPORT, but in a compile-test config where IOVA=m for
other reasons, it then picks up the real declarations from linux/iova.h
instead of the stubs, and things go downhill from there. So there is a
real issue, but indeed it's Tegra-VDE which needs to be restructured to
cope with such configurations, and not IPU3's (or anyone else who may
select IOVA=m in future) job to work around it.
Robin.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled
24.07.2019 17:03, Yuehaibing пишет:
> On 2019/7/24 21:49, Robin Murphy wrote:
>> On 24/07/2019 11:30, Sakari Ailus wrote:
>>> Hi Yue,
>>>
>>> On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
in the Kconfig, for example, CONFIG_TEGRA_VDE is set to y but IOMMU_IOVA
is m, then the building fails like this:
drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
iommu.c:(.text+0x41): undefined reference to `alloc_iova'
iommu.c:(.text+0x56): undefined reference to `__free_iova'
Reported-by: Hulk Robot
Fixes: 7fc7af649ca7 ("media: staging/intel-ipu3: Add imgu top level pci
device driver")
Signed-off-by: YueHaibing
---
drivers/staging/media/ipu3/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/ipu3/Kconfig
b/drivers/staging/media/ipu3/Kconfig
index 4b51c67..b7df18f 100644
--- a/drivers/staging/media/ipu3/Kconfig
+++ b/drivers/staging/media/ipu3/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_IPU3_IMGU
depends on PCI && VIDEO_V4L2
depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
depends on X86
-select IOMMU_IOVA
+select IOMMU_IOVA if IOMMU_SUPPORT
>>>
>>> This doesn't seem right: the ipu3-cio2 driver needs IOMMU_IOVA
>>> independently of IOMMU_SUPPORT.
>>>
>>> Looking at tegra-vde, it seems to depend on IOMMU_SUPPORT but that's not
>>> declared in its Kconfig entry. I wonder if adding that would be the right
>>> way to fix this.
>>>
>>> Cc'ing the IOMMU list.
IOMMU_SUPPORT is optional for the Tegra-VDE driver.
>> Right, I also had the impression that we'd made the IOVA library completely
>> standalone. And what does the IPU3 driver's Kconfig have to do with some
>> *other* driver failing to link anyway?
I can see it failing if IPU3 is compiled as a loadable module, while
Tegra-VDE is a built-in driver. Hence IOVA lib should be also a kernel
module and thus the IOVA symbols will be missing during of linkage of
the VDE driver.
> Oh, I misunderstand that IOMMU_IOVA is depend on IOMMU_SUPPORT, thank you for
> clarification.
>
> I will try to fix this in tegra-vde.
Probably IOVA could be selected independently of IOMMU_SUPPORT, but IOVA
library isn't needed for the VDE driver if IOMMU_SUPPORT is disabled.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled
On 2019/7/24 21:49, Robin Murphy wrote:
> On 24/07/2019 11:30, Sakari Ailus wrote:
>> Hi Yue,
>>
>> On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
>>> If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
>>> But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
>>> in the Kconfig, for example, CONFIG_TEGRA_VDE is set to y but IOMMU_IOVA
>>> is m, then the building fails like this:
>>>
>>> drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
>>> iommu.c:(.text+0x41): undefined reference to `alloc_iova'
>>> iommu.c:(.text+0x56): undefined reference to `__free_iova'
>>>
>>> Reported-by: Hulk Robot
>>> Fixes: 7fc7af649ca7 ("media: staging/intel-ipu3: Add imgu top level pci
>>> device driver")
>>> Signed-off-by: YueHaibing
>>> ---
>>> drivers/staging/media/ipu3/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/media/ipu3/Kconfig
>>> b/drivers/staging/media/ipu3/Kconfig
>>> index 4b51c67..b7df18f 100644
>>> --- a/drivers/staging/media/ipu3/Kconfig
>>> +++ b/drivers/staging/media/ipu3/Kconfig
>>> @@ -4,7 +4,7 @@ config VIDEO_IPU3_IMGU
>>> depends on PCI && VIDEO_V4L2
>>> depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
>>> depends on X86
>>> -select IOMMU_IOVA
>>> +select IOMMU_IOVA if IOMMU_SUPPORT
>>
>> This doesn't seem right: the ipu3-cio2 driver needs IOMMU_IOVA
>> independently of IOMMU_SUPPORT.
>>
>> Looking at tegra-vde, it seems to depend on IOMMU_SUPPORT but that's not
>> declared in its Kconfig entry. I wonder if adding that would be the right
>> way to fix this.
>>
>> Cc'ing the IOMMU list.
>
> Right, I also had the impression that we'd made the IOVA library completely
> standalone. And what does the IPU3 driver's Kconfig have to do with some
> *other* driver failing to link anyway?
Oh, I misunderstand that IOMMU_IOVA is depend on IOMMU_SUPPORT, thank you for
clarification.
I will try to fix this in tegra-vde.
>
> Robin.
>
>>
>>> select VIDEOBUF2_DMA_SG
>>> help
>>> This is the Video4Linux2 driver for Intel IPU3 image processing
>>> unit,
>>
>
> .
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled
On 24/07/2019 11:30, Sakari Ailus wrote:
Hi Yue,
On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
in the Kconfig, for example, CONFIG_TEGRA_VDE is set to y but IOMMU_IOVA
is m, then the building fails like this:
drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
iommu.c:(.text+0x41): undefined reference to `alloc_iova'
iommu.c:(.text+0x56): undefined reference to `__free_iova'
Reported-by: Hulk Robot
Fixes: 7fc7af649ca7 ("media: staging/intel-ipu3: Add imgu top level pci device
driver")
Signed-off-by: YueHaibing
---
drivers/staging/media/ipu3/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/ipu3/Kconfig
b/drivers/staging/media/ipu3/Kconfig
index 4b51c67..b7df18f 100644
--- a/drivers/staging/media/ipu3/Kconfig
+++ b/drivers/staging/media/ipu3/Kconfig
@@ -4,7 +4,7 @@ config VIDEO_IPU3_IMGU
depends on PCI && VIDEO_V4L2
depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
depends on X86
- select IOMMU_IOVA
+ select IOMMU_IOVA if IOMMU_SUPPORT
This doesn't seem right: the ipu3-cio2 driver needs IOMMU_IOVA
independently of IOMMU_SUPPORT.
Looking at tegra-vde, it seems to depend on IOMMU_SUPPORT but that's not
declared in its Kconfig entry. I wonder if adding that would be the right
way to fix this.
Cc'ing the IOMMU list.
Right, I also had the impression that we'd made the IOVA library
completely standalone. And what does the IPU3 driver's Kconfig have to
do with some *other* driver failing to link anyway?
Robin.
select VIDEOBUF2_DMA_SG
help
This is the Video4Linux2 driver for Intel IPU3 image processing unit,
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] qlge: Fix build error without CONFIG_ETHERNET
Now if CONFIG_ETHERNET is not set, QLGE driver
building fails:
drivers/staging/qlge/qlge_main.o: In function `qlge_remove':
drivers/staging/qlge/qlge_main.c:4831: undefined reference to
`unregister_netdev'
Reported-by: Hulk Robot
Fixes: 955315b0dc8c ("qlge: Move drivers/net/ethernet/qlogic/qlge/ to
drivers/staging/qlge/")
Signed-off-by: YueHaibing
---
drivers/staging/qlge/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/qlge/Kconfig b/drivers/staging/qlge/Kconfig
index ae9ed2c..a3cb25a3 100644
--- a/drivers/staging/qlge/Kconfig
+++ b/drivers/staging/qlge/Kconfig
@@ -2,7 +2,7 @@
config QLGE
tristate "QLogic QLGE 10Gb Ethernet Driver Support"
- depends on PCI
+ depends on ETHERNET && PCI
help
This driver supports QLogic ISP8XXX 10Gb Ethernet cards.
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] media: staging/intel-ipu3: Use dev_get_drvdata where possible
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.
Signed-off-by: Chuhong Yuan
---
drivers/staging/media/ipu3/ipu3.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/ipu3/ipu3.c
b/drivers/staging/media/ipu3/ipu3.c
index a7372395a101..06a61f31ca50 100644
--- a/drivers/staging/media/ipu3/ipu3.c
+++ b/drivers/staging/media/ipu3/ipu3.c
@@ -778,8 +778,7 @@ static int __maybe_unused imgu_suspend(struct device *dev)
static int __maybe_unused imgu_resume(struct device *dev)
{
- struct pci_dev *pci_dev = to_pci_dev(dev);
- struct imgu_device *imgu = pci_get_drvdata(pci_dev);
+ struct imgu_device *imgu = dev_get_drvdata(dev);
int r = 0;
unsigned int pipe;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: staging: davinci: remove vpfe driver
On Tue, Jul 23, 2019 at 11:46 AM Arnd Bergmann wrote: > > The davinci_vpfe driver was merged into staging back in 2012 by Manjunath > Hadli from TI, with a long TODO list. > > For all I can tell, since then it has only seen fixes for compile-time > issues and global cleanups, but nobody has actually worked on the items > on the TODO list. > > To make things worse, the driver in its current form is incompatible with > the platform code in arch/arm/mach-davinci, i.e. the driver expects to > get its platform_data passed to the device as a 'struct vpfe_config', > but uses a differnet definition for that structure compared to what the s/differnet/different > platform uses. > > Finally, there is another driver for the same device in > drivers/media/platform/davinci/vpfe_capture.c. From all I can tell, the > staging version was originally a copy of a more featureful driver in TI's > downstream kernels. However, that kernel no longer supports dm365 after > linux-2.6.37, and the mainline version moved in a different direction. > > Signed-off-by: Arnd Bergmann > --- > drivers/staging/media/Kconfig |2 - > drivers/staging/media/Makefile|1 - > drivers/staging/media/davinci_vpfe/Kconfig| 13 - > drivers/staging/media/davinci_vpfe/Makefile | 11 - > drivers/staging/media/davinci_vpfe/TODO | 38 - > .../media/davinci_vpfe/davinci-vpfe-mc.txt| 154 -- > .../media/davinci_vpfe/davinci_vpfe_user.h| 1287 -- > .../staging/media/davinci_vpfe/dm365_ipipe.c | 1852 --- > .../staging/media/davinci_vpfe/dm365_ipipe.h | 174 -- > .../media/davinci_vpfe/dm365_ipipe_hw.c | 1038 > .../media/davinci_vpfe/dm365_ipipe_hw.h | 556 - > .../media/davinci_vpfe/dm365_ipipeif.c| 1070 - > .../media/davinci_vpfe/dm365_ipipeif.h| 228 -- > .../media/davinci_vpfe/dm365_ipipeif_user.h | 90 - > .../staging/media/davinci_vpfe/dm365_isif.c | 2097 - > .../staging/media/davinci_vpfe/dm365_isif.h | 200 -- > .../media/davinci_vpfe/dm365_isif_regs.h | 291 --- > .../media/davinci_vpfe/dm365_resizer.c| 1995 > .../media/davinci_vpfe/dm365_resizer.h| 241 -- > drivers/staging/media/davinci_vpfe/vpfe.h | 83 - > .../media/davinci_vpfe/vpfe_mc_capture.c | 716 -- > .../media/davinci_vpfe/vpfe_mc_capture.h | 90 - > .../staging/media/davinci_vpfe/vpfe_video.c | 1646 - > .../staging/media/davinci_vpfe/vpfe_video.h | 150 -- > 24 files changed, 14023 deletions(-) > delete mode 100644 drivers/staging/media/davinci_vpfe/Kconfig > delete mode 100644 drivers/staging/media/davinci_vpfe/Makefile > delete mode 100644 drivers/staging/media/davinci_vpfe/TODO > delete mode 100644 drivers/staging/media/davinci_vpfe/davinci-vpfe-mc.txt > delete mode 100644 drivers/staging/media/davinci_vpfe/davinci_vpfe_user.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipe_hw.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_ipipeif_user.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_isif_regs.h > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_resizer.c > delete mode 100644 drivers/staging/media/davinci_vpfe/dm365_resizer.h > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe.h > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe_mc_capture.h > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe_video.c > delete mode 100644 drivers/staging/media/davinci_vpfe/vpfe_video.h > Acked-by: Lad, Prabhakar Regards, --Prabhakar Lad ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] media: staging: ipu3: Enable IOVA API only when IOMMU support is enabled
Hi Yue,
On Mon, Jul 22, 2019 at 09:47:49PM +0800, YueHaibing wrote:
> If IOMMU_SUPPORT is not set, ipu3 driver may select IOMMU_IOVA to m.
> But for many drivers, they use "select IOMMU_IOVA if IOMMU_SUPPORT"
> in the Kconfig, for example, CONFIG_TEGRA_VDE is set to y but IOMMU_IOVA
> is m, then the building fails like this:
>
> drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
> iommu.c:(.text+0x41): undefined reference to `alloc_iova'
> iommu.c:(.text+0x56): undefined reference to `__free_iova'
>
> Reported-by: Hulk Robot
> Fixes: 7fc7af649ca7 ("media: staging/intel-ipu3: Add imgu top level pci
> device driver")
> Signed-off-by: YueHaibing
> ---
> drivers/staging/media/ipu3/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/media/ipu3/Kconfig
> b/drivers/staging/media/ipu3/Kconfig
> index 4b51c67..b7df18f 100644
> --- a/drivers/staging/media/ipu3/Kconfig
> +++ b/drivers/staging/media/ipu3/Kconfig
> @@ -4,7 +4,7 @@ config VIDEO_IPU3_IMGU
> depends on PCI && VIDEO_V4L2
> depends on MEDIA_CONTROLLER && VIDEO_V4L2_SUBDEV_API
> depends on X86
> - select IOMMU_IOVA
> + select IOMMU_IOVA if IOMMU_SUPPORT
This doesn't seem right: the ipu3-cio2 driver needs IOMMU_IOVA
independently of IOMMU_SUPPORT.
Looking at tegra-vde, it seems to depend on IOMMU_SUPPORT but that's not
declared in its Kconfig entry. I wonder if adding that would be the right
way to fix this.
Cc'ing the IOMMU list.
> select VIDEOBUF2_DMA_SG
> help
> This is the Video4Linux2 driver for Intel IPU3 image processing unit,
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
