[PATCH] staging: rtl8712: Fix possible buffer overrun
From: Young Xiao
In commit 8b7a13c3f404 ("staging: r8712u: Fix possible buffer
overrun") we fix a potential off by one by making the limit smaller.
The better fix is to make the buffer larger. This makes it match up
with the similar code in other drivers.
Signed-off-by: Young Xiao
---
drivers/staging/rtl8712/mlme_linux.c | 2 +-
drivers/staging/rtl8712/rtl871x_mlme.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8712/mlme_linux.c
b/drivers/staging/rtl8712/mlme_linux.c
index 9d156ef..4d473f0 100644
--- a/drivers/staging/rtl8712/mlme_linux.c
+++ b/drivers/staging/rtl8712/mlme_linux.c
@@ -146,7 +146,7 @@ void r8712_report_sec_ie(struct _adapter *adapter, u8
authmode, u8 *sec_ie)
p = buff;
p += sprintf(p, "ASSOCINFO(ReqIEs=");
len = sec_ie[1] + 2;
- len = (len < IW_CUSTOM_MAX) ? len : IW_CUSTOM_MAX - 1;
+ len = (len < IW_CUSTOM_MAX) ? len : IW_CUSTOM_MAX;
for (i = 0; i < len; i++)
p += sprintf(p, "%02x", sec_ie[i]);
p += sprintf(p, ")");
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
b/drivers/staging/rtl8712/rtl871x_mlme.c
index a737400..986a1d5 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -1346,7 +1346,7 @@ sint r8712_restruct_sec_ie(struct _adapter *adapter, u8
*in_ie,
u8 *out_ie, uint in_len)
{
u8 authmode = 0, match;
- u8 sec_ie[255], uncst_oui[4], bkup_ie[255];
+ u8 sec_ie[IW_CUSTOM_MAX], uncst_oui[4], bkup_ie[255];
u8 wpa_oui[4] = {0x0, 0x50, 0xf2, 0x01};
uint ielength, cnt, remove_cnt;
int iEntry;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8712: Fix possible buffer overrun
Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v2] android: ion: How to properly clean caches for uncached allocations
Hi Liam, On Tue, Nov 27, 2018 at 10:46:07PM -0800, Liam Mark wrote: > On Tue, 27 Nov 2018, Brian Starkey wrote: > > > Hi Liam, > > > > On Mon, Nov 26, 2018 at 08:59:44PM -0800, Liam Mark wrote: > > > On Tue, 20 Nov 2018, Brian Starkey wrote: > > > > > > > Hi Liam, > > > > > > > > I'm missing a bit of context here, but I did read the v1 thread. > > > > Please accept my apologies if I'm re-treading trodden ground. > > > > > > > > I do know we're chasing nebulous ion "problems" on our end, which > > > > certainly seem to be related to what you're trying to fix here. > > > > > > > > On Thu, Nov 01, 2018 at 03:15:06PM -0700, Liam Mark wrote: > > > > >Based on the suggestions from Laura I created a first draft for a > > > > >change > > > > >which will attempt to ensure that uncached mappings are only applied to > > > > >ION memory who's cache lines have been cleaned. > > > > >It does this by providing cached mappings (for uncached ION > > > > >allocations) > > > > >until the ION buffer is dma mapped and successfully cleaned, then it > > > > drops > > > > >the userspace mappings and when pages are accessed they are faulted > > > > >back > > > > >in and uncached mappings are created. > > > > > > > > If I understand right, there's no way to portably clean the cache of > > > > the kernel mapping before we map the pages into userspace. Is that > > > > right? > > > > > > > > > > Yes, it isn't always possible to clean the caches for an uncached mapping > > > because a device is required by the DMA APIs to do cache maintenance and > > > there isn't necessarily a device available (dma_buf_attach may not yet > > > have been called). > > > > > > > Alternatively, can we just make ion refuse to give userspace a > > > > non-cached mapping for pages which are mapped in the kernel as cached? > > > > > > These pages will all be mapped as cached in the kernel for 64 bit (kernel > > > logical addresses) so you would always be refusing to create a non-cached > > > mapping. > > > > And that might be the sane thing to do, no? > > > > AFAIK there are still pages which aren't ever mapped as cached (e.g. > > dma_declare_coherent_memory(), anything under /reserved-memory marked > > as no-map). If those are exposed as an ion heap, then non-cached > > mappings would be fine, and permitted. > > > > Sounds like you are suggesting using carveouts to support uncached? > No, I'm just saying that ion can't give out uncached _CPU_ mappings for pages which are already mapped on the CPU as cached. > We have many multimedia use cases which use very large amounts of uncached > memory, uncached memory is used as a performance optimization because CPU > access won't happen so it allows us to skip cache maintenance for all the > dma map and dma unmap calls. To create carveouts large enough to support > to support the worst case scenarios could result in very large carveouts. > > Large carveouts like this would likely result in poor memory utilizations > (since they are tuned for worst case) which would likely have significant > performance impacts (more limited memory causes more frequent memory > reclaim ect...). > > Also estimating for worst case could be difficult since the amount of > uncached memory could be app dependent. > Unfortunately I don't think this would make for a very scalable solution. > Sure, I understand the desire not to use carveouts. I'm not suggesting carveouts are a viable alternative. > > > > > > > Would userspace using the dma-buf sync ioctl around its accesses do > > > > the "right thing" in that case? > > > > > > > > > > I don't think so, the dma-buf sync ioctl require a device to peform cache > > > maintenance, but as mentioned above a device may not be available. > > > > > > > If a device didn't attach yet, then no cache maintenance is > > necessary. The only thing accessing the memory is the CPU, via a > > cached mapping, which should work just fine. So far so good. > > > > Unfortunately not. > Scenario: > - Client allocates uncached memory. > - Client calls the DMA_BUF_IOCTL_SYNC IOCT IOCTL with flags > DMA_BUF_SYNC_START (but this doesn't do any cache maintenance since there > isn't any device) > - Client mmap the memory (ION creates uncached mapping) > - Client reads from that uncached mapping I think I maybe wasn't clear with my proposal. The sequence should be like this: - Client allocates memory - If this is from a region which the CPU has mapped as cached, then that's not "uncached" memory - it's cached memory - and you have to treat it as such. - Client calls the DMA_BUF_IOCTL_SYNC IOCTL with flags DMA_BUF_SYNC_START (but this doesn't do any cache maintenance since there isn't any device) - Client mmaps the memory - ion creates a _cached_ mapping into the userspace process. ion *must not* create an uncached mapping. - Client reads from that cached mapping - It sees zeroes, as expected. This proposal ensures that everyone will *always* see
[PATCH] staging: rtl8188eu: fix spelling mistake "inferface" -> "interface"
From: Colin Ian King Fix spelling mistake in module description text. Signed-off-by: Colin Ian King --- drivers/staging/rtl8188eu/os_dep/os_intfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8188eu/os_dep/os_intfs.c b/drivers/staging/rtl8188eu/os_dep/os_intfs.c index fb213a90ed1b..abcce2240f15 100644 --- a/drivers/staging/rtl8188eu/os_dep/os_intfs.c +++ b/drivers/staging/rtl8188eu/os_dep/os_intfs.c @@ -131,7 +131,7 @@ MODULE_PARM_DESC(debug, "Set debug level (1-9) (default 1)"); static bool rtw_monitor_enable; module_param_named(monitor_enable, rtw_monitor_enable, bool, 0444); -MODULE_PARM_DESC(monitor_enable, "Enable monitor inferface (default: false)"); +MODULE_PARM_DESC(monitor_enable, "Enable monitor interface (default: false)"); static int netdev_close(struct net_device *pnetdev); -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
HELLO GOOD FRIEND.
Attention To driverdev-devel@linuxdriverproject.org We found your email driverdev-devel@linuxdriverproject.org in our Investment Database Hence we are contacting you for Investment Purposes. Please pardon me for this unsolicited communique. I do have the trusteeship of a PRIVATE investor with a stormy political background to outsource individuals with sound Financial Management abilities to manage over US$1.3B devoid of his name. These funds can be invested in tranches of US$100M or a tranche that is suitable for the portfolio manager. If you have Financial Management abilities, credible project in need of funding or existing business requiring expansion, your feedback would be appreciated. Sincerely, Martin Jones. Managing Partner. FINANCIAL MANAGEMENT AND ADVISORY SERVICES LIMITED. Isle Of Man Business Park, Cooil Rd, Douglas, Isle of Man. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: speakup: i18n: fix spelling mistake "phoneticly" -> "phonetically"
From: Colin Ian King
There is a spelling mistake in array speakup_default_msgs at index
MSG_FUNCNAME_SPELL_WORD_PHONETICALLY, fix this.
Signed-off-by: Colin Ian King
---
drivers/staging/speakup/i18n.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/speakup/i18n.c b/drivers/staging/speakup/i18n.c
index cea8707653f5..ee240d36f947 100644
--- a/drivers/staging/speakup/i18n.c
+++ b/drivers/staging/speakup/i18n.c
@@ -336,7 +336,7 @@ static char *speakup_default_msgs[MSG_LAST_INDEX] = {
[MSG_FUNCNAME_SPELL_DELAY_DEC] = "spell delay decrement",
[MSG_FUNCNAME_SPELL_DELAY_INC] = "spell delay increment",
[MSG_FUNCNAME_SPELL_WORD] = "spell word",
- [MSG_FUNCNAME_SPELL_WORD_PHONETICALLY] = "spell word phoneticly",
+ [MSG_FUNCNAME_SPELL_WORD_PHONETICALLY] = "spell word phonetically",
[MSG_FUNCNAME_TONE_DEC] = "tone decrement",
[MSG_FUNCNAME_TONE_INC] = "tone increment",
[MSG_FUNCNAME_VOICE_DEC] = "voice decrement",
--
2.19.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: i18n: fix spelling mistake "phoneticly" -> "phonetically"
Hello, Colin King, le mer. 28 nov. 2018 16:12:32 +, a ecrit: > - [MSG_FUNCNAME_SPELL_WORD_PHONETICALLY] = "spell word phoneticly", > + [MSG_FUNCNAME_SPELL_WORD_PHONETICALLY] = "spell word phonetically", Mmm, clearly an english typo. Speakup people, do you think there might be any downside here? Could it be that it was done on purpose for e.g. syntheses to pronounce it right? Samuel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/6] staging: rtl8188eu: cleanup alignment issues in hal8188e_rate_adaptive.c
Cleanup alignment issues reported by checkpatch.
CHECK: Alignment should match open parenthesis
Signed-off-by: Michael Straube
---
.../rtl8188eu/hal/hal8188e_rate_adaptive.c| 37 +--
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
index c6f6594feaa2..f1ff86fec654 100644
--- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
+++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
@@ -114,20 +114,20 @@ static void odm_SetTxRPTTiming_8188E(struct odm_dm_struct
*dm_odm,
pRaInfo->RptTime = DynamicTxRPTTiming[idx];
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("pRaInfo->RptTime = 0x%x\n", pRaInfo->RptTime));
+("pRaInfo->RptTime = 0x%x\n", pRaInfo->RptTime));
}
static int odm_RateDown_8188E(struct odm_dm_struct *dm_odm,
- struct odm_ra_info *pRaInfo)
+ struct odm_ra_info *pRaInfo)
{
u8 RateID, LowestRate, HighestRate;
u8 i;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
- ODM_DBG_TRACE, ("=>%s()\n", __func__));
+ODM_DBG_TRACE, ("=>%s()\n", __func__));
if (!pRaInfo) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("%s(): pRaInfo is NULL\n", __func__));
+("%s(): pRaInfo is NULL\n", __func__));
return -1;
}
RateID = pRaInfo->PreRate;
@@ -170,14 +170,14 @@ static int odm_RateDown_8188E(struct odm_dm_struct
*dm_odm,
pRaInfo->DecisionRate = RateID;
odm_SetTxRPTTiming_8188E(dm_odm, pRaInfo, 2);
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
- ODM_DBG_LOUD, ("Rate down, RPT Timing default\n"));
+ODM_DBG_LOUD, ("Rate down, RPT Timing default\n"));
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
- ("RAWaitingCounter %d, RAPendingCounter %d",
+("RAWaitingCounter %d, RAPendingCounter %d",
pRaInfo->RAWaitingCounter, pRaInfo->RAPendingCounter));
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("Rate down to RateID %d RateSGI %d\n", RateID,
pRaInfo->RateSGI));
+("Rate down to RateID %d RateSGI %d\n", RateID,
pRaInfo->RateSGI));
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
- ("<= %s()\n", __func__));
+("<= %s()\n", __func__));
return 0;
}
@@ -188,10 +188,10 @@ static int odm_RateUp_8188E(struct odm_dm_struct *dm_odm,
u8 i;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
- ODM_DBG_TRACE, ("=>%s()\n", __func__));
+ODM_DBG_TRACE, ("=>%s()\n", __func__));
if (!pRaInfo) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("%s(): pRaInfo is NULL\n", __func__));
+("%s(): pRaInfo is NULL\n", __func__));
return -1;
}
RateID = pRaInfo->PreRate;
@@ -208,7 +208,7 @@ static int odm_RateUp_8188E(struct odm_dm_struct *dm_odm,
}
odm_SetTxRPTTiming_8188E(dm_odm, pRaInfo, 0);
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("%s():Decrease RPT Timing\n", __func__));
+("%s():Decrease RPT Timing\n", __func__));
if (RateID < HighestRate) {
for (i = RateID + 1; i <= HighestRate; i++) {
@@ -234,12 +234,12 @@ static int odm_RateUp_8188E(struct odm_dm_struct *dm_odm,
pRaInfo->DecisionRate = RateID;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("Rate up to RateID %d\n", RateID));
+("Rate up to RateID %d\n", RateID));
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
- ("RAWaitingCounter %d, RAPendingCounter %d",
-pRaInfo->RAWaitingCounter, pRaInfo->RAPendingCounter));
+("RAWaitingCounter %d, RAPendingCounter %d",
+ pRaInfo->RAWaitingCounter, pRaInfo->RAPendingCounter));
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
- ODM_DBG_TRACE, ("<= %s()\n", __func__));
+ODM_DBG_TRACE, ("<= %s()\n", __func__));
return 0;
}
@@ -255,15 +255,14 @@ static void odm_ResetRaCounter_8188E(struct odm_ra_info
*pRaInfo)
}
static void odm_RateDecision_8188E(struct odm_dm_struct *dm_odm,
- struct odm_ra_info *pRaInfo
- )
+ struct odm_ra_info *pRaInfo)
{
u8 RateID = 0, RtyPtID = 0, PenaltyID1
[PATCH 3/6] staging: rtl8188eu: add spaces around operators in hal8188e_rate_adaptive.c
Add spaces around operators to follow kernel coding style.
Reported by checkpatch.
Signed-off-by: Michael Straube
---
.../rtl8188eu/hal/hal8188e_rate_adaptive.c| 54 ++-
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
index 79e13d076553..ccd7bb24302b 100644
--- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
+++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
@@ -18,7 +18,7 @@ Major Change History:
/* Rate adaptive parameters */
-static u8 RETRY_PENALTY[PERENTRY][RETRYSIZE+1] = {
+static u8 RETRY_PENALTY[PERENTRY][RETRYSIZE + 1] = {
{5, 4, 3, 2, 0, 3}, /* 92 , idx = 0 */
{6, 5, 4, 3, 0, 4}, /* 86 , idx = 1 */
{6, 5, 4, 2, 0, 4}, /* 81 , idx = 2 */
@@ -44,7 +44,7 @@ static u8 RETRY_PENALTY[PERENTRY][RETRYSIZE+1] = {
{49, 16, 16, 0, 0, 48}
}; /* 3, idx = 0x16 */
-static u8 PT_PENALTY[RETRYSIZE+1] = {34, 31, 30, 24, 0, 32};
+static u8 PT_PENALTY[RETRYSIZE + 1] = {34, 31, 30, 24, 0, 32};
/* wilson modify */
static u8 RETRY_PENALTY_IDX[2][RATESIZE] = {
@@ -146,7 +146,7 @@ static int odm_RateDown_8188E(struct odm_dm_struct *dm_odm,
pRaInfo->RateSGI = 0;
} else if (RateID > LowestRate) {
if (RateID > 0) {
- for (i = RateID-1; i > LowestRate; i--) {
+ for (i = RateID - 1; i > LowestRate; i--) {
if (pRaInfo->RAUseRate & BIT(i)) {
RateID = i;
goto RateDownFinish;
@@ -216,7 +216,7 @@ static int odm_RateUp_8188E(
("%s():Decrease RPT Timing\n", __func__));
if (RateID < HighestRate) {
- for (i = RateID+1; i <= HighestRate; i++) {
+ for (i = RateID + 1; i <= HighestRate; i++) {
if (pRaInfo->RAUseRate & BIT(i)) {
RateID = i;
goto RateUpfinish;
@@ -232,7 +232,7 @@ static int odm_RateUp_8188E(
}
RateUpfinish:
if (pRaInfo->RAWaitingCounter ==
- (4+PendingForRateUpFail[pRaInfo->RAPendingCounter]))
+ (4 + PendingForRateUpFail[pRaInfo->RAPendingCounter]))
pRaInfo->RAWaitingCounter = 0;
else
pRaInfo->RAWaitingCounter++;
@@ -253,8 +253,10 @@ static void odm_ResetRaCounter_8188E(struct odm_ra_info
*pRaInfo)
u8 RateID;
RateID = pRaInfo->DecisionRate;
- pRaInfo->NscUp = (N_THRESHOLD_HIGH[RateID]+N_THRESHOLD_LOW[RateID])>>1;
- pRaInfo->NscDown =
(N_THRESHOLD_HIGH[RateID]+N_THRESHOLD_LOW[RateID])>>1;
+ pRaInfo->NscUp = (N_THRESHOLD_HIGH[RateID] +
+ N_THRESHOLD_LOW[RateID]) >> 1;
+ pRaInfo->NscDown = (N_THRESHOLD_HIGH[RateID] +
+ N_THRESHOLD_LOW[RateID]) >> 1;
}
static void odm_RateDecision_8188E(struct odm_dm_struct *dm_odm,
@@ -317,7 +319,7 @@ static void odm_RateDecision_8188E(struct odm_dm_struct
*dm_odm,
else
pRaInfo->NscUp = 0;
- ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE|ODM_COMP_INIT,
ODM_DBG_LOUD,
+ ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE | ODM_COMP_INIT,
ODM_DBG_LOUD,
(" RssiStaRa = %d RtyPtID =%d PenaltyID1 = 0x%x
PenaltyID2 = 0x%x RateID =%d NscDown =%d NscUp =%d SGI =%d\n",
pRaInfo->RssiStaRA, RtyPtID, PenaltyID1,
PenaltyID2, RateID, pRaInfo->NscDown, pRaInfo->NscUp, pRaInfo->RateSGI));
if ((pRaInfo->NscDown < N_THRESHOLD_LOW[RateID]) ||
@@ -357,41 +359,41 @@ static int odm_ARFBRefresh_8188E(struct odm_dm_struct
*dm_odm, struct odm_ra_inf
switch (pRaInfo->RateID) {
case RATR_INX_WIRELESS_NGB:
- pRaInfo->RAUseRate = (pRaInfo->RateMask)&0x0f8ff015;
+ pRaInfo->RAUseRate = pRaInfo->RateMask & 0x0f8ff015;
break;
case RATR_INX_WIRELESS_NG:
- pRaInfo->RAUseRate = (pRaInfo->RateMask)&0x0f8ff010;
+ pRaInfo->RAUseRate = pRaInfo->RateMask & 0x0f8ff010;
break;
case RATR_INX_WIRELESS_NB:
- pRaInfo->RAUseRate = (pRaInfo->RateMask)&0x0f8ff005;
+ pRaInfo->RAUseRate = pRaInfo->RateMask & 0x0f8ff005;
break;
case RATR_INX_WIRELESS_N:
- pRaInfo->RAUseRate = (pRaInfo->RateMask)&0x0f8ff000;
+ pRaInfo->RAUseRate = pRaInfo->RateMask & 0x0f8ff000;
break;
case RATR_INX_WIRELESS_GB:
- pRaInfo->RAUseRate = (pRaInfo->RateMask)&0x0ff5;
+ pRaInfo->RAUseRate = pRaInfo->RateMask & 0x0ff5;
break;
case RATR_INX_WIRELESS_G:
- p
[PATCH 6/6] staging: rtl8188eu: cleanup comment in hal8188e_rate_adaptive.c
Cleanup comment in hal8188e_rate_adaptive.c. Clears checkpatch warnings. WARNING: Block comments use * on subsequent lines WARNING: Block comments use a trailing */ on a separate line Signed-off-by: Michael Straube --- .../rtl8188eu/hal/hal8188e_rate_adaptive.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c index f1ff86fec654..9ddd51685063 100644 --- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c +++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c @@ -1,19 +1,8 @@ // SPDX-License-Identifier: GPL-2.0 -/*++ -Copyright (c) Realtek Semiconductor Corp. All rights reserved. +/* + * Copyright (c) Realtek Semiconductor Corp. All rights reserved. + */ -Module Name: - RateAdaptive.c - -Abstract: - Implement Rate Adaptive functions for common operations. - -Major Change History: - When Who What - -- --- --- - 2011-08-12 PageCreate. - ---*/ #include "odm_precomp.h" /* Rate adaptive parameters */ -- 2.19.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/6] staging: rtl8188eu: remove parentheses in hal8188e_rate_adaptive.c
Remove unnecessary parentheses reported by checkpatch.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
index 02f423accee8..79e13d076553 100644
--- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
+++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
@@ -554,7 +554,7 @@ int ODM_RAInfo_Init(struct odm_dm_struct *dm_odm, u8 macid)
u8 max_rate_idx = 0x13; /* MCS7 */
if (dm_odm->pWirelessMode)
- WirelessMode = *(dm_odm->pWirelessMode);
+ WirelessMode = *dm_odm->pWirelessMode;
if (WirelessMode != 0xFF) {
if (WirelessMode & ODM_WM_N24G)
@@ -661,7 +661,7 @@ void ODM_RA_UpdateRateInfo_8188E(struct odm_dm_struct
*dm_odm, u8 macid, u8 Rate
("macid =%d RateID = 0x%x RateMask = 0x%x SGIEnable =%d\n",
macid, RateID, RateMask, SGIEnable));
- pRaInfo = &(dm_odm->RAInfo[macid]);
+ pRaInfo = &dm_odm->RAInfo[macid];
pRaInfo->RateID = RateID;
pRaInfo->RateMask = RateMask;
pRaInfo->SGIEnable = SGIEnable;
@@ -677,7 +677,7 @@ void ODM_RA_SetRSSI_8188E(struct odm_dm_struct *dm_odm, u8
macid, u8 Rssi)
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
(" macid =%d Rssi =%d\n", macid, Rssi));
- pRaInfo = &(dm_odm->RAInfo[macid]);
+ pRaInfo = &dm_odm->RAInfo[macid];
pRaInfo->RssiStaRA = Rssi;
}
@@ -711,7 +711,7 @@ void ODM_RA_TxRPT2Handle_8188E(struct odm_dm_struct
*dm_odm, u8 *TxRPT_Buf, u16
else
valid = (1 << MacId) & macid_entry0;
- pRAInfo = &(dm_odm->RAInfo[MacId]);
+ pRAInfo = &dm_odm->RAInfo[MacId];
if (valid) {
pRAInfo->RTY[0] =
(u16)GET_TX_REPORT_TYPE1_RERTY_0(pBuffer);
pRAInfo->RTY[1] =
(u16)GET_TX_REPORT_TYPE1_RERTY_1(pBuffer);
--
2.19.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/6] staging: rtl8188eu: use __func__ in hal8188e_rate_adaptive.c
Use __func__ instead of hardcoded function names.
Reported by checkpatch.
Signed-off-by: Michael Straube
---
.../rtl8188eu/hal/hal8188e_rate_adaptive.c| 36 ++-
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
index 6dbd7d261f1e..02f423accee8 100644
--- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
+++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
@@ -127,10 +127,10 @@ static int odm_RateDown_8188E(struct odm_dm_struct
*dm_odm,
u8 i;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
- ODM_DBG_TRACE, ("=>odm_RateDown_8188E()\n"));
+ ODM_DBG_TRACE, ("=>%s()\n", __func__));
if (!pRaInfo) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("odm_RateDown_8188E(): pRaInfo is NULL\n"));
+ ("%s(): pRaInfo is NULL\n", __func__));
return -1;
}
RateID = pRaInfo->PreRate;
@@ -180,7 +180,7 @@ static int odm_RateDown_8188E(struct odm_dm_struct *dm_odm,
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
("Rate down to RateID %d RateSGI %d\n", RateID,
pRaInfo->RateSGI));
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
- ("<= odm_RateDown_8188E()\n"));
+ ("<= %s()\n", __func__));
return 0;
}
@@ -193,10 +193,10 @@ static int odm_RateUp_8188E(
u8 i;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
- ODM_DBG_TRACE, ("=>odm_RateUp_8188E()\n"));
+ ODM_DBG_TRACE, ("=>%s()\n", __func__));
if (!pRaInfo) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("odm_RateUp_8188E(): pRaInfo is NULL\n"));
+ ("%s(): pRaInfo is NULL\n", __func__));
return -1;
}
RateID = pRaInfo->PreRate;
@@ -213,7 +213,7 @@ static int odm_RateUp_8188E(
}
odm_SetTxRPTTiming_8188E(dm_odm, pRaInfo, 0);
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
- ("odm_RateUp_8188E():Decrease RPT Timing\n"));
+ ("%s():Decrease RPT Timing\n", __func__));
if (RateID < HighestRate) {
for (i = RateID+1; i <= HighestRate; i++) {
@@ -244,7 +244,7 @@ static int odm_RateUp_8188E(
("RAWaitingCounter %d, RAPendingCounter %d",
pRaInfo->RAWaitingCounter, pRaInfo->RAPendingCounter));
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
- ODM_DBG_TRACE, ("<= odm_RateUp_8188E()\n"));
+ ODM_DBG_TRACE, ("<= %s()\n", __func__));
return 0;
}
@@ -266,7 +266,7 @@ static void odm_RateDecision_8188E(struct odm_dm_struct
*dm_odm,
static u8 DynamicTxRPTTimingCounter;
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
- ("=>odm_RateDecision_8188E()\n"));
+ ("=>%s()\n", __func__));
if (pRaInfo->Active && (pRaInfo->TOTAL > 0)) { /* STA used and data
packet exits */
if ((pRaInfo->RssiStaRA < (pRaInfo->PreRssiStaRA - 3)) ||
@@ -345,7 +345,8 @@ static void odm_RateDecision_8188E(struct odm_dm_struct
*dm_odm,
odm_ResetRaCounter_8188E(pRaInfo);
}
- ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE, ("<=
odm_RateDecision_8188E()\n"));
+ ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
+("<= %s()\n", __func__));
}
static int odm_ARFBRefresh_8188E(struct odm_dm_struct *dm_odm, struct
odm_ra_info *pRaInfo)
@@ -533,7 +534,8 @@ odm_RATxRPTTimerSetting(
u16 minRptTime
)
{
- ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE, ("
=>odm_RATxRPTTimerSetting()\n"));
+ ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
+(" =>%s()\n", __func__));
if (dm_odm->CurrminRptTime != minRptTime) {
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
@@ -541,7 +543,8 @@ odm_RATxRPTTimerSetting(
rtw_rpt_timer_cfg_cmd(dm_odm->Adapter, minRptTime);
dm_odm->CurrminRptTime = minRptTime;
}
- ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE, (" <=
odm_RATxRPTTimerSetting()\n"));
+ ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
+(" <= %s()\n", __func__));
}
int ODM_RAInfo_Init(struct odm_dm_struct *dm_odm, u8 macid)
@@ -563,8 +566,8 @@ int ODM_RAInfo_Init(struct odm_dm_struct *dm_odm, u8 macid)
}
ODM_RT_TRACE(dm_odm, ODM_COM
[PATCH 4/6] staging: rtl8188eu: cleanup lines ending with '('
Cleanup lines ending with '(' in hal8188e_rate_adaptive.c.
Reported by checkpatch.
Signed-off-by: Michael Straube
---
.../rtl8188eu/hal/hal8188e_rate_adaptive.c| 20 ++-
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
index ccd7bb24302b..c6f6594feaa2 100644
--- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
+++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
@@ -92,11 +92,8 @@ static u16 DynamicTxRPTTiming[6] = {
/* End Rate adaptive parameters */
-static void odm_SetTxRPTTiming_8188E(
- struct odm_dm_struct *dm_odm,
- struct odm_ra_info *pRaInfo,
- u8 extend
- )
+static void odm_SetTxRPTTiming_8188E(struct odm_dm_struct *dm_odm,
+struct odm_ra_info *pRaInfo, u8 extend)
{
u8 idx = 0;
@@ -184,10 +181,8 @@ static int odm_RateDown_8188E(struct odm_dm_struct *dm_odm,
return 0;
}
-static int odm_RateUp_8188E(
- struct odm_dm_struct *dm_odm,
- struct odm_ra_info *pRaInfo
- )
+static int odm_RateUp_8188E(struct odm_dm_struct *dm_odm,
+ struct odm_ra_info *pRaInfo)
{
u8 RateID, HighestRate;
u8 i;
@@ -532,11 +527,8 @@ static void odm_PTDecision_8188E(struct odm_ra_info
*pRaInfo)
pRaInfo->PTStage = temp_stage;
}
-static void
-odm_RATxRPTTimerSetting(
- struct odm_dm_struct *dm_odm,
- u16 minRptTime
-)
+static void odm_RATxRPTTimerSetting(struct odm_dm_struct *dm_odm,
+ u16 minRptTime)
{
ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_TRACE,
(" =>%s()\n", __func__));
--
2.19.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/2] staging: iio: ad7780: move out of staging
This series of patches add user input to ad7780 'gain' & 'filter' gpio pins. Also, it moves the ad7780 out of staging to the main tree. Giuliano Belinassi (2): staging: iio: ad7780: Add gain & filter gpio support staging: iio: ad7780: Moving ad7780 out of staging drivers/iio/adc/Kconfig| 13 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/ad7780.c | 347 + drivers/staging/iio/adc/Kconfig| 13 - drivers/staging/iio/adc/Makefile | 1 - drivers/staging/iio/adc/ad7780.c | 277 include/linux/iio/adc/ad_sigma_delta.h | 5 + 7 files changed, 366 insertions(+), 291 deletions(-) create mode 100644 drivers/iio/adc/ad7780.c delete mode 100644 drivers/staging/iio/adc/ad7780.c -- 2.19.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: iio: ad7780: Add gain & filter gpio support
Previously, the AD7780 driver only supported gpio for the 'powerdown'
pin. This commit adds suppport for the 'gain' and 'filter' pin.
Signed-off-by: Giuliano Belinassi
---
Changes in v2:
- Now this patch is part of the patchset that aims to remove ad7780
out of staging. https://marc.info/?l=linux-iio&m=154282349808890&w=2
- Also, now it reads voltage and filter values from the userspace
instead of gpio pin states.
drivers/staging/iio/adc/ad7780.c | 78 --
include/linux/iio/adc/ad_sigma_delta.h | 5 ++
2 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index c4a85789c2db..05979a79fda3 100644
--- a/drivers/staging/iio/adc/ad7780.c
+++ b/drivers/staging/iio/adc/ad7780.c
@@ -39,6 +39,12 @@
#define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
#define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
+#define AD7780_GAIN_GPIO 0
+#define AD7780_FILTER_GPIO 1
+
+#define AD7780_GAIN_MIDPOINT 64
+#define AD7780_FILTER_MIDPOINT 13350
+
struct ad7780_chip_info {
struct iio_chan_specchannel;
unsigned intpattern_mask;
@@ -50,6 +56,8 @@ struct ad7780_state {
const struct ad7780_chip_info *chip_info;
struct regulator*reg;
struct gpio_desc*powerdown_gpio;
+ struct gpio_desc*gain_gpio;
+ struct gpio_desc*filter_gpio;
unsigned intgain;
struct ad_sigma_delta sd;
@@ -115,18 +123,65 @@ static int ad7780_read_raw(struct iio_dev *indio_dev,
return -EINVAL;
}
+static int ad7780_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val,
+ int val2,
+ long m)
+{
+ struct ad7780_state *st = iio_priv(indio_dev);
+ const struct ad7780_chip_info *chip_info = st->chip_info;
+ int uvref, gain;
+ unsigned int full_scale;
+
+ if (!chip_info->is_ad778x)
+ return 0;
+
+ switch (m) {
+ case IIO_CHAN_INFO_SCALE:
+ if (val != 0)
+ return -EINVAL;
+
+ uvref = regulator_get_voltage(st->reg);
+
+ if (uvref < 0)
+ return uvref;
+
+ full_scale = 1 << (chip_info->channel.scan_type.realbits - 1);
+ gain = DIV_ROUND_CLOSEST(uvref, full_scale);
+ gain = DIV_ROUND_CLOSEST(gain, val2);
+
+ gpiod_set_value(st->gain_gpio, gain < AD7780_GAIN_MIDPOINT ? 0
: 1);
+ break;
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ if (val2 != 0)
+ return -EINVAL;
+
+ gpiod_set_value(st->filter_gpio, val < AD7780_FILTER_MIDPOINT ?
0 : 1);
+ break;
+ }
+
+ return 0;
+}
+
static int ad7780_postprocess_sample(struct ad_sigma_delta *sigma_delta,
unsigned int raw_sample)
{
struct ad7780_state *st = ad_sigma_delta_to_ad7780(sigma_delta);
const struct ad7780_chip_info *chip_info = st->chip_info;
+ int val;
if ((raw_sample & AD7780_ERR) ||
((raw_sample & chip_info->pattern_mask) != chip_info->pattern))
return -EIO;
if (chip_info->is_ad778x) {
- if (raw_sample & AD7780_GAIN)
+ val = raw_sample & AD7780_GAIN;
+
+ if (val != gpiod_get_value(st->gain_gpio))
+ return -EIO;
+
+ if (val)
st->gain = 1;
else
st->gain = 128;
@@ -141,18 +196,20 @@ static const struct ad_sigma_delta_info
ad7780_sigma_delta_info = {
.has_registers = false,
};
-#define AD7780_CHANNEL(bits, wordsize) \
+#define AD7170_CHANNEL(bits, wordsize) \
AD_SD_CHANNEL_NO_SAMP_FREQ(1, 0, 0, bits, 32, wordsize - bits)
+#define AD7780_CHANNEL(bits, wordsize) \
+ AD_SD_CHANNEL_GAIN_FILTER(1, 0, 0, bits, 32, wordsize - bits)
static const struct ad7780_chip_info ad7780_chip_info_tbl[] = {
[ID_AD7170] = {
- .channel = AD7780_CHANNEL(12, 24),
+ .channel = AD7170_CHANNEL(12, 24),
.pattern = AD7170_PATTERN,
.pattern_mask = AD7170_PATTERN_MASK,
.is_ad778x = false,
},
[ID_AD7171] = {
- .channel = AD7780_CHANNEL(16, 24),
+ .channel = AD7170_CHANNEL(16, 24),
.pattern = AD7170_PATTERN,
.pattern_mask = AD7170_PATTERN_MASK,
.is_ad778x = false,
@@ -173,6 +230,7 @@ static const struct ad7780_chip_info ad7780_chip_info_tbl[]
= {
static const struct iio_info ad7780_info = {
.read_raw = ad7780_read_raw,
+ .write_raw = ad7780_write_raw,
};
static int ad7780_probe(struc
[PATCH 2/2] staging: iio: ad7780: Moving ad7780 out of staging
Move ad7780 sigma-delta adc out of staging to the main tree
Signed-off-by: Giuliano Belinassi
Signed-off-by: Renato Lui Geh
---
drivers/iio/adc/Kconfig | 13 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ad7780.c | 347 +++
drivers/staging/iio/adc/Kconfig | 13 --
drivers/staging/iio/adc/Makefile | 1 -
drivers/staging/iio/adc/ad7780.c | 347 ---
6 files changed, 361 insertions(+), 361 deletions(-)
create mode 100644 drivers/iio/adc/ad7780.c
delete mode 100644 drivers/staging/iio/adc/ad7780.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 575bf69fea57..e517425e364d 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -92,6 +92,19 @@ config AD7793
To compile this driver as a module, choose M here: the
module will be called AD7793.
+config AD7780
+ tristate "Analog Devices AD7780 and similar ADCs driver"
+ depends on SPI
+ depends on GPIOLIB || COMPILE_TEST
+ select AD_SIGMA_DELTA
+ help
+ Say yes here to build support for Analog Devices AD7170, AD7171,
+ AD7780 and AD7781 SPI analog to digital converters (ADC).
+ If unsure, say N (but it's safe to say "Y").
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad7780.
+
config AD7887
tristate "Analog Devices AD7887 ADC driver"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 91ba28aeb150..3301ca10b385 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_AD7298) += ad7298.o
obj-$(CONFIG_AD7923) += ad7923.o
obj-$(CONFIG_AD7476) += ad7476.o
obj-$(CONFIG_AD7766) += ad7766.o
+obj-$(CONFIG_AD7780) += ad7780.o
obj-$(CONFIG_AD7791) += ad7791.o
obj-$(CONFIG_AD7793) += ad7793.o
obj-$(CONFIG_AD7887) += ad7887.o
diff --git a/drivers/iio/adc/ad7780.c b/drivers/iio/adc/ad7780.c
new file mode 100644
index ..05979a79fda3
--- /dev/null
+++ b/drivers/iio/adc/ad7780.c
@@ -0,0 +1,347 @@
+/*
+ * AD7170/AD7171 and AD7780/AD7781 SPI ADC driver
+ *
+ * Copyright 2011 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#define AD7780_RDY BIT(7)
+#define AD7780_FILTER BIT(6)
+#define AD7780_ERR BIT(5)
+#define AD7780_ID1 BIT(4)
+#define AD7780_ID0 BIT(3)
+#define AD7780_GAINBIT(2)
+#define AD7780_PAT1BIT(1)
+#define AD7780_PAT0BIT(0)
+
+#define AD7780_PATTERN (AD7780_PAT0)
+#define AD7780_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1)
+
+#define AD7170_PAT2BIT(2)
+
+#define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
+#define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 | AD7170_PAT2)
+
+#define AD7780_GAIN_GPIO 0
+#define AD7780_FILTER_GPIO 1
+
+#define AD7780_GAIN_MIDPOINT 64
+#define AD7780_FILTER_MIDPOINT 13350
+
+struct ad7780_chip_info {
+ struct iio_chan_specchannel;
+ unsigned intpattern_mask;
+ unsigned intpattern;
+ boolis_ad778x;
+};
+
+struct ad7780_state {
+ const struct ad7780_chip_info *chip_info;
+ struct regulator*reg;
+ struct gpio_desc*powerdown_gpio;
+ struct gpio_desc*gain_gpio;
+ struct gpio_desc*filter_gpio;
+ unsigned intgain;
+
+ struct ad_sigma_delta sd;
+};
+
+enum ad7780_supported_device_ids {
+ ID_AD7170,
+ ID_AD7171,
+ ID_AD7780,
+ ID_AD7781,
+};
+
+static struct ad7780_state *ad_sigma_delta_to_ad7780(struct ad_sigma_delta *sd)
+{
+ return container_of(sd, struct ad7780_state, sd);
+}
+
+static int ad7780_set_mode(struct ad_sigma_delta *sigma_delta,
+ enum ad_sigma_delta_mode mode)
+{
+ struct ad7780_state *st = ad_sigma_delta_to_ad7780(sigma_delta);
+ unsigned int val;
+
+ switch (mode) {
+ case AD_SD_MODE_SINGLE:
+ case AD_SD_MODE_CONTINUOUS:
+ val = 1;
+ break;
+ default:
+ val = 0;
+ break;
+ }
+
+ gpiod_set_value(st->powerdown_gpio, val);
+
+ return 0;
+}
+
+static int ad7780_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val,
+ int *val2,
+ long m)
+{
+ struct ad7780_state *st = iio_priv(indio_dev);
+ int voltage_uv;
+
+ switch (m) {
+ case IIO_CHAN_INFO_RAW:
+ return ad_sigma_delta_single_conversion(indio_dev, chan, val);
+ case IIO_CHAN_INFO_SCALE:
+
[PATCH] staging: wilc1000: correct inconsistent indenting
Correct inconsistent indenting reported by smatch. Signed-off-by: Michael Straube --- drivers/staging/wilc1000/wilc_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/wilc_spi.c b/drivers/staging/wilc1000/wilc_spi.c index 35ff432587fe..6d1eb82d1df8 100644 --- a/drivers/staging/wilc1000/wilc_spi.c +++ b/drivers/staging/wilc1000/wilc_spi.c @@ -963,7 +963,7 @@ static int wilc_spi_read_int(struct wilc *wilc, u32 *int_status) dev_err(&spi->dev, "Unexpected interrupt(2):j=%d,tmp=%x,mask=%x\n", j, tmp, unknown_mask); - happened = 1; + happened = 1; } j++; -- 2.19.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/6] staging: rtl8188eu: use __func__ in hal8188e_rate_adaptive.c
On Wed, Nov 28, 2018 at 06:29:01PM +0100, Michael Straube wrote:
> Use __func__ instead of hardcoded function names.
> Reported by checkpatch.
>
> Signed-off-by: Michael Straube
> ---
> .../rtl8188eu/hal/hal8188e_rate_adaptive.c| 36 ++-
> 1 file changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
> b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
> index 6dbd7d261f1e..02f423accee8 100644
> --- a/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
> +++ b/drivers/staging/rtl8188eu/hal/hal8188e_rate_adaptive.c
> @@ -127,10 +127,10 @@ static int odm_RateDown_8188E(struct odm_dm_struct
> *dm_odm,
> u8 i;
>
> ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE,
> - ODM_DBG_TRACE, ("=>odm_RateDown_8188E()\n"));
> + ODM_DBG_TRACE, ("=>%s()\n", __func__));
This printk has no information that you couldn't get using ftrace.
> if (!pRaInfo) {
> ODM_RT_TRACE(dm_odm, ODM_COMP_RATE_ADAPTIVE, ODM_DBG_LOUD,
> - ("odm_RateDown_8188E(): pRaInfo is NULL\n"));
> + ("%s(): pRaInfo is NULL\n", __func__));
It pRaInfo is never NULL so this is dead code. A lot of this trace
output could just be deleted.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: vchiq_arm: add __user pointer annotations
Add __user to pointers based on context and suggestions by sparse.
Other sparse warnings still remain, in cases where more change would be
required apart from adding __user.
Signed-off-by: Szilveszter Székely
---
.../interface/vchiq_arm/vchiq_arm.c | 28 +--
.../interface/vchiq_arm/vchiq_if.h| 2 +-
.../interface/vchiq_arm/vchiq_ioctl.h | 4 +--
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index 0caee2d69..f28f68119 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -1593,7 +1593,7 @@ vchiq_compat_ioctl_queue_message(struct file *file,
unsigned long arg)
{
VCHIQ_QUEUE_MESSAGE_T *args;
- struct vchiq_element *elements;
+ struct vchiq_element __user *elements;
struct vchiq_queue_message32 args32;
unsigned int count;
@@ -1659,7 +1659,7 @@ vchiq_compat_ioctl_queue_bulk(struct file *file,
unsigned int cmd,
unsigned long arg)
{
- VCHIQ_QUEUE_BULK_TRANSFER_T *args;
+ VCHIQ_QUEUE_BULK_TRANSFER_T __user *args;
struct vchiq_queue_bulk_transfer32 args32;
struct vchiq_queue_bulk_transfer32 *ptrargs32 =
(struct vchiq_queue_bulk_transfer32 *)arg;
@@ -1725,16 +1725,16 @@ vchiq_compat_ioctl_await_completion(struct file *file,
unsigned int cmd,
unsigned long arg)
{
- VCHIQ_AWAIT_COMPLETION_T *args;
- VCHIQ_COMPLETION_DATA_T *completion;
+ VCHIQ_AWAIT_COMPLETION_T __user *args;
+ VCHIQ_COMPLETION_DATA_T __user *completion;
VCHIQ_COMPLETION_DATA_T completiontemp;
struct vchiq_await_completion32 args32;
struct vchiq_completion_data32 completion32;
- unsigned int *msgbufcount32;
+ unsigned int __user *msgbufcount32;
unsigned int msgbufcount_native;
compat_uptr_t msgbuf32;
- void *msgbuf;
- void **msgbufptr;
+ void __user *msgbuf;
+ void * __user *msgbufptr;
long ret;
args = compat_alloc_user_space(sizeof(*args) +
@@ -1743,11 +1743,11 @@ vchiq_compat_ioctl_await_completion(struct file *file,
if (!args)
return -EFAULT;
- completion = (VCHIQ_COMPLETION_DATA_T *)(args + 1);
- msgbufptr = (void __user **)(completion + 1);
+ completion = (VCHIQ_COMPLETION_DATA_T __user *)(args + 1);
+ msgbufptr = (void * __user *)(completion + 1);
if (copy_from_user(&args32,
- (struct vchiq_completion_data32 *)arg,
+ (struct vchiq_completion_data32 __user *)arg,
sizeof(args32)))
return -EFAULT;
@@ -1875,7 +1875,7 @@ vchiq_compat_ioctl_dequeue_message(struct file *file,
unsigned int cmd,
unsigned long arg)
{
- VCHIQ_DEQUEUE_MESSAGE_T *args;
+ VCHIQ_DEQUEUE_MESSAGE_T __user *args;
struct vchiq_dequeue_message32 args32;
args = compat_alloc_user_space(sizeof(*args));
@@ -1883,7 +1883,7 @@ vchiq_compat_ioctl_dequeue_message(struct file *file,
return -EFAULT;
if (copy_from_user(&args32,
- (struct vchiq_dequeue_message32 *)arg,
+ (struct vchiq_dequeue_message32 __user *)arg,
sizeof(args32)))
return -EFAULT;
@@ -1910,7 +1910,7 @@ vchiq_compat_ioctl_get_config(struct file *file,
unsigned int cmd,
unsigned long arg)
{
- VCHIQ_GET_CONFIG_T *args;
+ VCHIQ_GET_CONFIG_T __user *args;
struct vchiq_get_config32 args32;
args = compat_alloc_user_space(sizeof(*args));
@@ -1918,7 +1918,7 @@ vchiq_compat_ioctl_get_config(struct file *file,
return -EFAULT;
if (copy_from_user(&args32,
- (struct vchiq_get_config32 *)arg,
+ (struct vchiq_get_config32 __user *)arg,
sizeof(args32)))
return -EFAULT;
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h
index 7b948a173..0cdaebee9 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_if.h
@@ -87,7 +87,7 @@ typedef struct vchiq_header_struct {
} VCHIQ_HEADER_T;
struct vchiq_element {
- const void *data;
+ const void __user *data;
unsigned int size;
};
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/
Re: [PATCH] scsi: vmw_pscsi: Rearrange code to avoid multiple calls to free_irq during unload
Cathy, > Currently pvscsi_remove calls free_irq more than once as > pvscsi_release_resources and __pvscsi_shutdown both call > pvscsi_shutdown_intr. This results in a 'Trying to free > already-free IRQ' warning and stack trace. To solve the problem > pvscsi_shutdown_intr has been moved out of pvscsi_release_resources. Applied to 4.20/scsi-fixes, thanks! -- Martin K. Petersen Oracle Linux Engineering ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ion: Add chunk heap initialization
On 11/27/18 12:07 PM, Alexey Skidanov wrote:
On 11/27/18 9:20 PM, Laura Abbott wrote:
On 11/26/18 10:43 AM, Alexey Skidanov wrote:
On 11/26/18 6:39 PM, Laura Abbott wrote:
On 11/25/18 2:02 PM, Alexey Skidanov wrote:
On 11/25/18 11:40 PM, Laura Abbott wrote:
On 11/25/18 1:22 PM, Alexey Skidanov wrote:
On 11/25/18 10:51 PM, Laura Abbott wrote:
On 11/11/18 11:29 AM, Alexey Skidanov wrote:
Create chunk heap of specified size and base address by adding
"ion_chunk_heap=size@start" kernel boot parameter.
Signed-off-by: Alexey Skidanov
---
drivers/staging/android/ion/ion_chunk_heap.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c
b/drivers/staging/android/ion/ion_chunk_heap.c
index 159d72f..67573aa4 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -135,6 +135,7 @@ struct ion_heap *ion_chunk_heap_create(struct
ion_platform_heap *heap_data)
}
chunk_heap->base = heap_data->base;
chunk_heap->size = heap_data->size;
+ chunk_heap->heap.name = heap_data->name;
chunk_heap->allocated = 0;
gen_pool_add(chunk_heap->pool, chunk_heap->base,
heap_data->size, -1);
@@ -151,3 +152,42 @@ struct ion_heap *ion_chunk_heap_create(struct
ion_platform_heap *heap_data)
return ERR_PTR(ret);
}
+static u64 base;
+static u64 size;
+
+static int __init setup_heap(char *param)
+{
+ char *p, *pp;
+
+ size = memparse(param, &p);
+ if (param == p)
+ return -EINVAL;
+
+ if (*p == '@')
+ base = memparse(p + 1, &pp);
+ else
+ return -EINVAL;
+
+ if (p == pp)
+ return -EINVAL;
+
+ return 0;
+}
+
+__setup("ion_chunk_heap=", setup_heap);
+
+static int ion_add_chunk_heap(void)
+{
+ struct ion_heap *heap;
+ struct ion_platform_heap plat_heap = {.base = base,
+ .size = size,
+ .name = "chunk_heap",
+ .priv = (void *)PAGE_SIZE};
+ heap = ion_chunk_heap_create(&plat_heap);
+ if (heap)
+ ion_device_add_heap(heap);
+
+ return 0;
+}
+device_initcall(ion_add_chunk_heap);
+
This solves a problem but not enough of the problem.
We need to be able to support more than one chunk/carveout
heap.
This is easy to support.
This also assumes that the memory has already been
reserved/placed and that you know the base and size to
pass on the command line. Part of the issue with the carveout
heaps is that we need a way to tell the kernel to reserve
the memory early enough and then get that information to
Ion. Hard coding memory locations tends to be buggy from
my past experience with Ion.
memmap= kernel option marks the memory region(s) as reserved (Zone
Allocator doesn't use this memory region(s)). So the heap(s) may
manage
this memory region(s).
memmap= is x86 only. I really don't like using the command line for
specifying the base/size as it seems likely to conflict with platforms
that rely on devicetree for reserving memory regions.
Thanks,
Laura
I see ... So probably the better way is the one similar to this
https://elixir.bootlin.com/linux/latest/source/kernel/dma/contiguous.c#L245
?
Correct. For platforms that need devicetree, we need a way to specify
that a region should become an Ion heap. I went through a similar
exercise with CMA heaps before I kind of gave up on figuring out a
binding and just had Ion enumerate all CMA heaps. We do still need
a solution to work with non-DT platforms as well so whatever we
come up with needs to plausibly work for both cases. Your solution
would cover the non-DT case but I'd really like to make sure we
at least have a path forward for the devicetree case as well.
I would say that we have the following steps to consider:
1. Memory reservation. The suggested solution doesn't care how it's done.
2. Per-heap information passing to the Kernel. It's different for DT and
non-DT cases.
3. Heap objects instantiation. The DT and non-DT cases have different
ways/formats to pass this per-heap information. But once the parsing is
done, the rest of the code is common.
I think it clearly defines the steps covering both cases. What do you
think?
Yes, that sounds about right.
So, in this patch step #2 - is setup_heap() and step #3 - is
ion_add_chunk_heap(). The only missing part is to support several heap
instances creation, correct?
Mostly yes. I'd like to see struct ion_platform_heap go away since
it really isn't used for anything else but we need another
way to get the reserved memory information into Ion.
Thanks,
Laura
Thanks,
Alexey
Thanks,
Alexey
Thanks,
Laura
Thanks,
Alexey
If you'd like to see about coming up with a complete solution,
feel free to resubmit but I'm still strongly considering
removing these heaps.
I will add the multiple heaps support and resubmit the patch
Thanks,
Laura
Thanks,
Alexey
Re: [PATCH] scsi: storvsc: Fix a race in sub-channel creation that can cause panic
KY,
> From: Dexuan Cui
>
> We can concurrently try to open the same sub-channel from 2 paths:
>
> path #1: vmbus_onoffer() -> vmbus_process_offer() -> handle_sc_creation().
> path #2: storvsc_probe() -> storvsc_connect_to_vsp() ->
>-> storvsc_channel_init() -> handle_multichannel_storage() ->
>-> vmbus_are_subchannels_present() -> handle_sc_creation().
>
> They conflict with each other, but it was not an issue before the recent
> commit ae6935ed7d42 ("vmbus: split ring buffer allocation from open"),
> because at the beginning of vmbus_open() we checked newchannel->state so
> only one path could succeed, and the other would return with -EINVAL.
Applied to 4.20/scsi-fixes. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
vmbus_process_offer() mustn't call channel->sc_creation_callback()
directly for sub-channels, because sc_creation_callback() ->
vmbus_open() may never get the host's response to the
OPEN_CHANNEL message (the host may rescind a channel at any time,
e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
may not wake up the vmbus_open() as it's blocked due to a non-zero
vmbus_connection.offer_in_progress, and finally we have a deadlock.
The above is also true for primary channels, if the related device
drivers use sync probing mode by default.
And, usually the handling of primary channels and sub-channels can
depend on each other, so we should offload them to different
workqueues to avoid possible deadlock, e.g. in sync-probing mode,
NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
and waits for all the sub-channels to appear, but the latter
can't get the rtnl_lock and this blocks the handling of sub-channels.
The patch can fix the multiple-NIC deadlock described above for
v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
but don't enable async-probing for Hyper-V drivers (yet).
The patch can also fix the hang issue in sub-channel's handling described
above for all versions of kernels, including v4.19 and v4.20-rc4.
So, actually the patch should be applied to all the existing kernels,
not only the kernels that have 8195b1396ec8.
Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: sta...@vger.kernel.org
Cc: Stephen Hemminger
Cc: K. Y. Srinivasan
Cc: Haiyang Zhang
Signed-off-by: Dexuan Cui
Signed-off-by: K. Y. Srinivasan
---
There is no change in this repost. I just rebased this patch to today's
char-misc's char-misc-next branch. Previously KY posted the patch with his
Signed-off-by (which is kept in this repost), but there was a conflict issue.
Note: the patch can't be cleanly applied to char-misc's char-misc-linus branch
--
to do that, we need to cherry-pick the supporting patch first:
4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
vmbus_get_outgoing_channel()")
drivers/hv/channel_mgmt.c | 188 +++---
drivers/hv/connection.c | 24 +-
drivers/hv/hyperv_vmbus.h | 7 ++
include/linux/hyperv.h| 7 ++
4 files changed, 161 insertions(+), 65 deletions(-)
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 82e6736..d016890 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -434,60 +434,16 @@ void vmbus_free_channels(void)
}
}
-/*
- * vmbus_process_offer - Process the offer by creating a channel/device
- * associated with this offer
- */
-static void vmbus_process_offer(struct vmbus_channel *newchannel)
+/* Note: the function can run concurrently for primary/sub channels. */
+static void vmbus_add_channel_work(struct work_struct *work)
{
- struct vmbus_channel *channel;
- bool fnew = true;
+ struct vmbus_channel *newchannel =
+ container_of(work, struct vmbus_channel, add_channel_work);
+ struct vmbus_channel *primary_channel = newchannel->primary_channel;
unsigned long flags;
u16 dev_type;
int ret;
- /* Make sure this is a new offer */
- mutex_lock(&vmbus_connection.channel_mutex);
-
- /*
-* Now that we have acquired the channel_mutex,
-* we can release the potentially racing rescind thread.
-*/
- atomic_dec(&vmbus_connection.offer_in_progress);
-
- list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
- if (!uuid_le_cmp(channel->offermsg.offer.if_type,
- newchannel->offermsg.offer.if_type) &&
- !uuid_le_cmp(channel->offermsg.offer.if_instance,
- newchannel->offermsg.offer.if_instance)) {
- fnew = false;
- break;
- }
- }
-
- if (fnew)
- list_add_tail(&newchannel->listentry,
- &vmbus_connection.chn_list);
-
- mutex_unlock(&vmbus_connection.channel_mutex);
-
- if (!fnew) {
- /*
-* Check to see if this is a sub-channel.
-*/
- if (newchannel->offermsg.offer.sub_channel_index != 0) {
- /*
-* Process the sub-channel.
-*/
- newchannel->primary_channel = channel;
- spin_lock_irqsave(&channel->lock, flags);
- list_add_tail(&newchannel->sc_list, &channel->sc_list);
- spin_unlock_irqrestore(&channel->lock, flags);
- } else {
- goto err_free_chan;
- }
- }
-
dev_type = hv_get_dev_type(
Re: [PATCH] staging: android: ion: Add chunk heap initialization
On 11/29/18 3:30 AM, Laura Abbott wrote:
> On 11/27/18 12:07 PM, Alexey Skidanov wrote:
>>
>>
>> On 11/27/18 9:20 PM, Laura Abbott wrote:
>>> On 11/26/18 10:43 AM, Alexey Skidanov wrote:
On 11/26/18 6:39 PM, Laura Abbott wrote:
> On 11/25/18 2:02 PM, Alexey Skidanov wrote:
>>
>>
>> On 11/25/18 11:40 PM, Laura Abbott wrote:
>>> On 11/25/18 1:22 PM, Alexey Skidanov wrote:
On 11/25/18 10:51 PM, Laura Abbott wrote:
> On 11/11/18 11:29 AM, Alexey Skidanov wrote:
>> Create chunk heap of specified size and base address by adding
>> "ion_chunk_heap=size@start" kernel boot parameter.
>>
>> Signed-off-by: Alexey Skidanov
>> ---
>> drivers/staging/android/ion/ion_chunk_heap.c | 40
>>
>> 1 file changed, 40 insertions(+)
>>
>> diff --git a/drivers/staging/android/ion/ion_chunk_heap.c
>> b/drivers/staging/android/ion/ion_chunk_heap.c
>> index 159d72f..67573aa4 100644
>> --- a/drivers/staging/android/ion/ion_chunk_heap.c
>> +++ b/drivers/staging/android/ion/ion_chunk_heap.c
>> @@ -135,6 +135,7 @@ struct ion_heap *ion_chunk_heap_create(struct
>> ion_platform_heap *heap_data)
>> }
>> chunk_heap->base = heap_data->base;
>> chunk_heap->size = heap_data->size;
>> + chunk_heap->heap.name = heap_data->name;
>> chunk_heap->allocated = 0;
>> gen_pool_add(chunk_heap->pool, chunk_heap->base,
>> heap_data->size, -1);
>> @@ -151,3 +152,42 @@ struct ion_heap
>> *ion_chunk_heap_create(struct
>> ion_platform_heap *heap_data)
>> return ERR_PTR(ret);
>> }
>> +static u64 base;
>> +static u64 size;
>> +
>> +static int __init setup_heap(char *param)
>> +{
>> + char *p, *pp;
>> +
>> + size = memparse(param, &p);
>> + if (param == p)
>> + return -EINVAL;
>> +
>> + if (*p == '@')
>> + base = memparse(p + 1, &pp);
>> + else
>> + return -EINVAL;
>> +
>> + if (p == pp)
>> + return -EINVAL;
>> +
>> + return 0;
>> +}
>> +
>> +__setup("ion_chunk_heap=", setup_heap);
>> +
>> +static int ion_add_chunk_heap(void)
>> +{
>> + struct ion_heap *heap;
>> + struct ion_platform_heap plat_heap = {.base = base,
>> + .size = size,
>> + .name = "chunk_heap",
>> + .priv = (void *)PAGE_SIZE};
>> + heap = ion_chunk_heap_create(&plat_heap);
>> + if (heap)
>> + ion_device_add_heap(heap);
>> +
>> + return 0;
>> +}
>> +device_initcall(ion_add_chunk_heap);
>> +
>>
>
> This solves a problem but not enough of the problem.
>
> We need to be able to support more than one chunk/carveout
> heap.
This is easy to support.
This also assumes that the memory has already been
> reserved/placed and that you know the base and size to
> pass on the command line. Part of the issue with the carveout
> heaps is that we need a way to tell the kernel to reserve
> the memory early enough and then get that information to
> Ion. Hard coding memory locations tends to be buggy from
> my past experience with Ion.
memmap= kernel option marks the memory region(s) as reserved (Zone
Allocator doesn't use this memory region(s)). So the heap(s) may
manage
this memory region(s).
>>>
>>> memmap= is x86 only. I really don't like using the command line for
>>> specifying the base/size as it seems likely to conflict with
>>> platforms
>>> that rely on devicetree for reserving memory regions.
>>>
>>> Thanks,
>>> Laura
>>>
>> I see ... So probably the better way is the one similar to this
>> https://elixir.bootlin.com/linux/latest/source/kernel/dma/contiguous.c#L245
>>
>>
>>
>> ?
>>
>
> Correct. For platforms that need devicetree, we need a way to specify
> that a region should become an Ion heap. I went through a similar
> exercise with CMA heaps before I kind of gave up on figuring out a
> binding and just had Ion enumerate all CMA heaps. We do still need
> a solution to work with non-DT platforms as well so whatever we
> come up with needs to plausibly work for both cases. Your solution
> would cover the non-DT case but I'd really like to make sure we
> at least have a path forward for the devicetree case
Re: [RFC PATCH v2] android: ion: How to properly clean caches for uncached allocations
On Wed, 28 Nov 2018, Brian Starkey wrote: > Hi Liam, > > On Tue, Nov 27, 2018 at 10:46:07PM -0800, Liam Mark wrote: > > On Tue, 27 Nov 2018, Brian Starkey wrote: > > > > > Hi Liam, > > > > > > On Mon, Nov 26, 2018 at 08:59:44PM -0800, Liam Mark wrote: > > > > On Tue, 20 Nov 2018, Brian Starkey wrote: > > > > > > > > > Hi Liam, > > > > > > > > > > I'm missing a bit of context here, but I did read the v1 thread. > > > > > Please accept my apologies if I'm re-treading trodden ground. > > > > > > > > > > I do know we're chasing nebulous ion "problems" on our end, which > > > > > certainly seem to be related to what you're trying to fix here. > > > > > > > > > > On Thu, Nov 01, 2018 at 03:15:06PM -0700, Liam Mark wrote: > > > > > >Based on the suggestions from Laura I created a first draft for a > > > > > >change > > > > > >which will attempt to ensure that uncached mappings are only applied > > > > > >to > > > > > >ION memory who's cache lines have been cleaned. > > > > > >It does this by providing cached mappings (for uncached ION > > > > > >allocations) > > > > > >until the ION buffer is dma mapped and successfully cleaned, then it > > > > > drops > > > > > >the userspace mappings and when pages are accessed they are faulted > > > > > >back > > > > > >in and uncached mappings are created. > > > > > > > > > > If I understand right, there's no way to portably clean the cache of > > > > > the kernel mapping before we map the pages into userspace. Is that > > > > > right? > > > > > > > > > > > > > Yes, it isn't always possible to clean the caches for an uncached > > > > mapping > > > > because a device is required by the DMA APIs to do cache maintenance > > > > and > > > > there isn't necessarily a device available (dma_buf_attach may not yet > > > > have been called). > > > > > > > > > Alternatively, can we just make ion refuse to give userspace a > > > > > non-cached mapping for pages which are mapped in the kernel as cached? > > > > > > > > These pages will all be mapped as cached in the kernel for 64 bit > > > > (kernel > > > > logical addresses) so you would always be refusing to create a > > > > non-cached mapping. > > > > > > And that might be the sane thing to do, no? > > > > > > AFAIK there are still pages which aren't ever mapped as cached (e.g. > > > dma_declare_coherent_memory(), anything under /reserved-memory marked > > > as no-map). If those are exposed as an ion heap, then non-cached > > > mappings would be fine, and permitted. > > > > > > > Sounds like you are suggesting using carveouts to support uncached? > > > > No, I'm just saying that ion can't give out uncached _CPU_ mappings > for pages which are already mapped on the CPU as cached. > Okay then I guess I am not clear on where you would get this memory which doesn't have a cached kernel mapping. It sounded like you wanted to define sections of memory in the DT as not mapped in the kernel and then hand this memory to dma_declare_coherent_memory (so that it can be managed) and then use an ION heap as the allocator. If the memory was defined this way it sounded a lot like a carveout. But I guess you have some thoughts on how this memory which doesn't have a kernel mapping can be made available for general use (for example available in buddy)? Perhaps you were thinking of dynamically removing the kernel mappings before handing it out as uncached, but this would have a general system performance impact as this memory could come from anywhere so we would quickly lose our 1GB block mappings (and likely many of our 2MB block mappings as well). > > We have many multimedia use cases which use very large amounts of uncached > > memory, uncached memory is used as a performance optimization because CPU > > access won't happen so it allows us to skip cache maintenance for all the > > dma map and dma unmap calls. To create carveouts large enough to support > > to support the worst case scenarios could result in very large carveouts. > > > > Large carveouts like this would likely result in poor memory utilizations > > (since they are tuned for worst case) which would likely have significant > > performance impacts (more limited memory causes more frequent memory > > reclaim ect...). > > > > Also estimating for worst case could be difficult since the amount of > > uncached memory could be app dependent. > > Unfortunately I don't think this would make for a very scalable solution. > > > > Sure, I understand the desire not to use carveouts. I'm not suggesting > carveouts are a viable alternative. > > > > > > > > > > Would userspace using the dma-buf sync ioctl around its accesses do > > > > > the "right thing" in that case? > > > > > > > > > > > > > I don't think so, the dma-buf sync ioctl require a device to peform > > > > cache > > > > maintenance, but as mentioned above a device may not be available. > > > > > > > > > > If a device didn't attach yet, then no cache maintenance is > > > necessary. T
Re: [PATCH] [repost] Drivers: hv: vmbus: Offload the handling of channels to two workqueues
On Thu, Nov 29, 2018 at 04:36:43AM +, Dexuan Cui wrote:
>
> vmbus_process_offer() mustn't call channel->sc_creation_callback()
> directly for sub-channels, because sc_creation_callback() ->
> vmbus_open() may never get the host's response to the
> OPEN_CHANNEL message (the host may rescind a channel at any time,
> e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
> may not wake up the vmbus_open() as it's blocked due to a non-zero
> vmbus_connection.offer_in_progress, and finally we have a deadlock.
>
> The above is also true for primary channels, if the related device
> drivers use sync probing mode by default.
>
> And, usually the handling of primary channels and sub-channels can
> depend on each other, so we should offload them to different
> workqueues to avoid possible deadlock, e.g. in sync-probing mode,
> NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
> rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
> and waits for all the sub-channels to appear, but the latter
> can't get the rtnl_lock and this blocks the handling of sub-channels.
>
> The patch can fix the multiple-NIC deadlock described above for
> v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
> of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
> but don't enable async-probing for Hyper-V drivers (yet).
>
> The patch can also fix the hang issue in sub-channel's handling described
> above for all versions of kernels, including v4.19 and v4.20-rc4.
>
> So, actually the patch should be applied to all the existing kernels,
> not only the kernels that have 8195b1396ec8.
>
> Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
> Cc: sta...@vger.kernel.org
> Cc: Stephen Hemminger
> Cc: K. Y. Srinivasan
> Cc: Haiyang Zhang
> Signed-off-by: Dexuan Cui
> Signed-off-by: K. Y. Srinivasan
> ---
>
> There is no change in this repost. I just rebased this patch to today's
> char-misc's char-misc-next branch. Previously KY posted the patch with his
> Signed-off-by (which is kept in this repost), but there was a conflict issue.
>
> Note: the patch can't be cleanly applied to char-misc's char-misc-linus
> branch --
> to do that, we need to cherry-pick the supporting patch first:
> 4d3c5c69191f ("Drivers: hv: vmbus: Remove the useless API
> vmbus_get_outgoing_channel()")
That is not going to work for the obvious reason that this dependant
patch is not going to be merged into 4.20-final.
So, what do you expect us to do here? The only way this can be accepted
is to have it go into my -next branch, which means it will show up in
4.21-rc1, is that ok?
But then, if that happens, it will fail to apply to any stable tree for
4.20 and older, like you are asking it to be done for.
So what do you expect me to do here with this?
totally confused,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
