Re: [PATCH v3 3/8] staging: rtl8192u: User memset to initialize memory, instead of loop.
On Mon, Jun 25, 2018 at 08:50:26PM +0100, John Whitmore wrote: > On Mon, Jun 25, 2018 at 02:05:04PM +0100, Justin Skists wrote: > > > > > On 25 June 2018 at 13:36 John Whitmore wrote: > > > > > > > > > On Mon, Jun 25, 2018 at 12:06:30PM +0300, Andy Shevchenko wrote: > > > > On Sun, Jun 24, 2018 at 6:34 PM, John Whitmore > > > > wrote: > > > > > Replaced memory initialising loop with memset, as suggested by Andy > > > > > Shevchenko > > > > > > > > > > > > > Suggested-by ? > > > > > > > > > > Em, not sure how to respond, it certainly wasn't my idea. I was just > > > making > > > coding style changes, badly. ;) > > > > Suggested-by is a tag for patches, to give credit. For example: > > > > https://elixir.bootlin.com/linux/v4.18-rc1/source/Documentation/process/submitting-patches.rst > > > > See section "13) Using Reported-by:, Tested-by:, Reviewed-by:, > > Suggested-by: and Fixes:" > > > > Hope that helps, > > Justin. > > Oops... that helps thank you. I have to re-read that document, it obvioiusly > didn't all sink in :( I've dropped this patch, can you fix it up and resend? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 5/8] staging: rtl8192u: Use %s and __func__ instead of hardcoded string - Style
On Sun, Jun 24, 2018 at 04:34:51PM +0100, John Whitmore wrote: > Changed a number of hard coded function names to use %s and __func__ > > Mailing list response suggest that there is a better method for debugging > using netdev_dbg(). I can't argue with that, but for the moment this change > will clear the checkpatch.pl Warning. > > Signed-off-by: John Whitmore > --- > drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Did not apply :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Do Qualcomm drivers use DMA buffers for request_firmware_into_buf()?
On Thu 07 Jun 11:42 PDT 2018, Ard Biesheuvel wrote: > On 7 June 2018 at 20:21, Bjorn Andersson wrote: > > On Thu 07 Jun 09:33 PDT 2018, Greg Kroah-Hartman wrote: [..] > >> > >> Why not just use kmalloc, it will always return a DMAable buffer. > >> > > > > For the buffers being targeted by request_firmware_into_buf() the > > problem is that some of them has requirements of physical placement and > > they are all too big for kmalloc() (i.e. tens of mb). > > > > > > For the dma_alloc_coherent() buffer that was mentioned earlier, which is > > not related to the firmware loading, it's not used because the buffer is > > passed to secure world, which temporarily locks Linux out from the > > memory region. Traditionally this region was kmalloc'ed downstream, but > > due to speculative access violations this code moved to use the DMA > > streaming API, although there's no actual DMA going on. > > > > OK, so you are relying on the fact that dma_alloc_coherent() gives you > a device mapping (because the qcom_scm device is described as non > cache coherent), but this sounds risky to me. The linear alias of that > memory will still be mapped cacheable, and could potentially still be > accessed speculatively AFAIK. > Yes and we are aware of the risk of having the linear alias present, but have yet to find a suitable way to handle this. The proposed mechanism was to use reserved-memory and memremap() the region while it should be available in Linux, but while this would work for some cases (e.g. memory regions for semi-static firmware executed by co-processors) it doesn't handle the scenarios where the memory-need is dynamic. So suggestions are very welcome on how to better handle this. Regards, Bjorn ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 3/4] x86/hyper-v: use cheaper HVCALL_SEND_IPI hypercall when possible
> -Original Message- > From: Vitaly Kuznetsov > Sent: Friday, June 22, 2018 10:06 AM > To: x...@kernel.org > Cc: de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; KY Srinivasan > ; Haiyang Zhang ; Stephen > Hemminger > ; Thomas Gleixner ; Ingo Molnar > ; H. Peter Anvin ; Tianyu Lan > ; Michael Kelley (EOSG) > > Subject: [PATCH 3/4] x86/hyper-v: use cheaper HVCALL_SEND_IPI hypercall when > possible > > When there is no need to send an IPI to a CPU with VP number > 64 > we can do the job with fast HVCALL_SEND_IPI hypercall. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Michael Kelley ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: Will the name of hyperv_clocksource_tsc_page or hyperv_clocksource pages change?
Thank you everybody for your help. I have passed this information along to the customer and asked for the reason they want to refer to the name of the clocksource. エアー・アルマ Professional Direct Delivery Manager Email: v-ale...@microsoft.com Microsoft Azure Professional Direct Services 日本 +81 1-2051-4100（無料） 日本 +81 3-6743-9670（有料） 電子メール: pdaz...@microsoft.com -Original Message- From: Greg KH Sent: Friday, June 22, 2018 10:51 PM To: Peter Zijlstra Cc: Alma Eyre (Sonata Software North America) ; Haiyang Zhang ; de...@linuxdriverproject.org; Vitaly Kuznetsov ; Linus Torvalds ; Thomas Gleixner Subject: Re: Will the name of hyperv_clocksource_tsc_page or hyperv_clocksource pages change? On Fri, Jun 22, 2018 at 10:22:28AM +0200, Peter Zijlstra wrote: > On Fri, Jun 22, 2018 at 03:17:25AM +, Alma Eyre (Sonata Software North > America) wrote: > > Hello, > > > > This is Alma supporting Azure for Japanese customers. I had a > > question from a customer that I could not find the answers for. I > > saw this > > github(https://na01.safelinks.protection.outlook.com/?url=https%3A%2 > > F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2F88c9281a9fba67636ab26c1 > > fd6afbc78a632374fdata=02%7C01%7Cv-aleyre%40microsoft.com%7Cfd2c > > bcc41da54a65be1908d5d8cd635c%7C72f988bf86f141af91ab2d7cd011db47%7C1% > > 7C0%7C636653299021462729sdata=B0KCAukioytYR0RlTPr2n3KVCrKzkRem2 > > ir1aBiXXoA%3Dreserved=0) page, and I was wondering if someone > > on this list might be able to answer the question. > > > > Will the name of hyperv_clocksource_tsc_page or hyperv_clocksource > > pages change? > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > b.com%2Ftorvalds%2Flinux%2Fblob%2Fe7aa8c2eb11ba69b1b69099c3c7bd6be3087 > b0ba%2FDocumentation%2Fprocess%2Fstable-api-nonsense.rstdata=02%7 > C01%7Cv-aleyre%40microsoft.com%7Cfd2cbcc41da54a65be1908d5d8cd635c%7C72 > f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636653299021462729sdata= > URuIH1hhfWowC4yfkZxZB8Gg9%2Fo6rEkzufMOUSgjJug%3Dreserved=0 Or better yet, in a pretty html format: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kernel.org%2Fdoc%2Fhtml%2Flatest%2Fprocess%2Fstable-api-nonsense.htmldata=02%7C01%7Cv-aleyre%40microsoft.com%7Cfd2cbcc41da54a65be1908d5d8cd635c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636653299021462729sdata=UBkvgJz9XcURXiTPbV1CImpK9DsnbK9HTgFwZCKjcJU%3Dreserved=0 But, this is a name of a clocksource, not really an internal kernel api. Alma, what external tool depends on the specific name of a kernel clock? Why would it matter what the name of it is? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 2/4] x86/hyper-v: use 'fast' hypercall for HVCALL_SEND_IPI
> -Original Message- > From: Vitaly Kuznetsov > Sent: Friday, June 22, 2018 10:06 AM > To: x...@kernel.org > Cc: de...@linuxdriverproject.org; linux-ker...@vger.kernel.org; KY Srinivasan > ; Haiyang Zhang ; Stephen > Hemminger > ; Thomas Gleixner ; Ingo Molnar > ; H. Peter Anvin ; Tianyu Lan > ; Michael Kelley (EOSG) > > Subject: [PATCH 2/4] x86/hyper-v: use 'fast' hypercall for HVCALL_SEND_IPI > > Current Hyper-V TLFS (v5.0b) claims that HvCallSendSyntheticClusterIpi > hypercall can't be 'fast' (passing parameters through registers) but > apparently this is not true, Windows always uses 'fast' version. We can > do the same in Linux too. > > Signed-off-by: Vitaly Kuznetsov Reviewed-by: Michael Kelley ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: add SPDX identifiers
This satisfies a checkpatch warning and is the preferred method for notating the license. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. Signed-off-by: Michael Straube --- drivers/staging/rtl8188eu/core/rtw_ap.c| 10 +- drivers/staging/rtl8188eu/core/rtw_cmd.c | 10 +- drivers/staging/rtl8188eu/core/rtw_debug.c | 10 +- drivers/staging/rtl8188eu/core/rtw_efuse.c | 10 +- drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 10 +- drivers/staging/rtl8188eu/core/rtw_ioctl_set.c | 10 +- drivers/staging/rtl8188eu/core/rtw_iol.c | 11 +-- drivers/staging/rtl8188eu/core/rtw_led.c | 11 +-- drivers/staging/rtl8188eu/core/rtw_mlme.c | 10 +- drivers/staging/rtl8188eu/core/rtw_mlme_ext.c | 10 +- drivers/staging/rtl8188eu/core/rtw_pwrctrl.c | 10 +- drivers/staging/rtl8188eu/core/rtw_recv.c | 10 +- drivers/staging/rtl8188eu/core/rtw_rf.c| 10 +- drivers/staging/rtl8188eu/core/rtw_security.c | 10 +- drivers/staging/rtl8188eu/core/rtw_sreset.c| 10 +- drivers/staging/rtl8188eu/core/rtw_sta_mgt.c | 10 +- drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 10 +- drivers/staging/rtl8188eu/core/rtw_xmit.c | 10 +- drivers/staging/rtl8188eu/hal/bb_cfg.c | 10 +- drivers/staging/rtl8188eu/hal/fw.c | 13 + drivers/staging/rtl8188eu/hal/hal_com.c| 10 +- drivers/staging/rtl8188eu/hal/hal_intf.c | 10 +- drivers/staging/rtl8188eu/hal/mac_cfg.c| 18 +- drivers/staging/rtl8188eu/hal/odm.c| 10 +- drivers/staging/rtl8188eu/hal/odm_HWConfig.c | 10 +- drivers/staging/rtl8188eu/hal/odm_RTL8188E.c | 10 +- drivers/staging/rtl8188eu/hal/phy.c| 10 +- drivers/staging/rtl8188eu/hal/pwrseq.c | 10 +- drivers/staging/rtl8188eu/hal/pwrseqcmd.c | 10 +- drivers/staging/rtl8188eu/hal/rf.c | 10 +- drivers/staging/rtl8188eu/hal/rf_cfg.c | 18 +- drivers/staging/rtl8188eu/hal/rtl8188e_cmd.c | 10 +- drivers/staging/rtl8188eu/hal/rtl8188e_dm.c| 10 +- .../staging/rtl8188eu/hal/rtl8188e_hal_init.c | 10 +- .../staging/rtl8188eu/hal/rtl8188e_rxdesc.c| 10 +- drivers/staging/rtl8188eu/hal/rtl8188e_xmit.c | 10 +- drivers/staging/rtl8188eu/hal/rtl8188eu_led.c | 10 +- drivers/staging/rtl8188eu/hal/rtl8188eu_recv.c | 10 +- drivers/staging/rtl8188eu/hal/rtl8188eu_xmit.c | 10 +- drivers/staging/rtl8188eu/hal/usb_halinit.c| 10 +- .../staging/rtl8188eu/include/Hal8188EPhyCfg.h | 10 +- .../staging/rtl8188eu/include/Hal8188EPhyReg.h | 10 +- drivers/staging/rtl8188eu/include/HalVerDef.h | 10 +- .../staging/rtl8188eu/include/basic_types.h| 12 ++-- drivers/staging/rtl8188eu/include/drv_types.h | 10 +- drivers/staging/rtl8188eu/include/fw.h | 13 + drivers/staging/rtl8188eu/include/hal_com.h| 10 +- drivers/staging/rtl8188eu/include/hal_intf.h | 10 +- drivers/staging/rtl8188eu/include/ieee80211.h | 10 +- drivers/staging/rtl8188eu/include/mlme_osdep.h | 10 +- drivers/staging/rtl8188eu/include/mon.h| 10 +- .../staging/rtl8188eu/include/mp_custom_oid.h | 10 +- drivers/staging/rtl8188eu/include/odm.h| 10 +- .../staging/rtl8188eu/include/odm_HWConfig.h | 11 +-- .../staging/rtl8188eu/include/odm_RTL8188E.h | 10 +- .../rtl8188eu/include/odm_RegDefine11N.h | 10 +- drivers/staging/rtl8188eu/include/odm_debug.h | 10 +- .../staging/rtl8188eu/include/odm_precomp.h| 10 +- drivers/staging/rtl8188eu/include/odm_reg.h| 10 +- drivers/staging/rtl8188eu/include/odm_types.h | 10 +- drivers/staging/rtl8188eu/include/osdep_intf.h | 10 +- .../staging/rtl8188eu/include/osdep_service.h | 10 +- drivers/staging/rtl8188eu/include/pwrseq.h | 11 +-- drivers/staging/rtl8188eu/include/pwrseqcmd.h | 10 +- drivers/staging/rtl8188eu/include/recv_osdep.h | 10 +- .../staging/rtl8188eu/include/rtl8188e_cmd.h | 10 +- .../staging/rtl8188eu/include/rtl8188e_dm.h| 10 +- .../staging/rtl8188eu/include/rtl8188e_hal.h | 10 +- .../staging/rtl8188eu/include/rtl8188e_led.h | 10 +- .../staging/rtl8188eu/include/rtl8188e_recv.h | 10 +- .../staging/rtl8188eu/include/rtl8188e_spec.h | 10 +- .../staging/rtl8188eu/include/rtl8188e_xmit.h | 10 +- .../staging/rtl8188eu/include/rtw_android.h| 10 +- drivers/staging/rtl8188eu/include/rtw_ap.h | 10
Re: [PATCH v3 3/8] staging: rtl8192u: User memset to initialize memory, instead of loop.
On Mon, Jun 25, 2018 at 02:05:04PM +0100, Justin Skists wrote: > > > On 25 June 2018 at 13:36 John Whitmore wrote: > > > > > > On Mon, Jun 25, 2018 at 12:06:30PM +0300, Andy Shevchenko wrote: > > > On Sun, Jun 24, 2018 at 6:34 PM, John Whitmore > > > wrote: > > > > Replaced memory initialising loop with memset, as suggested by Andy > > > > Shevchenko > > > > > > > > > > Suggested-by ? > > > > > > > Em, not sure how to respond, it certainly wasn't my idea. I was just making > > coding style changes, badly. ;) > > Suggested-by is a tag for patches, to give credit. For example: > > https://elixir.bootlin.com/linux/v4.18-rc1/source/Documentation/process/submitting-patches.rst > > See section "13) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: > and Fixes:" > > Hope that helps, > Justin. Oops... that helps thank you. I have to re-read that document, it obvioiusly didn't all sink in :( thanks again. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging:iio:impedance-analyzer:ad5933: Macro replacement Cleanups.
Doing some macro replacement to start an array of structures
so it can be reused by manipulating it with different values.
Signed-off-by: Karim Eshapa
---
.../staging/iio/impedance-analyzer/ad5933.c | 57 +++
1 file changed, 19 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
b/drivers/staging/iio/impedance-analyzer/ad5933.c
index 3bcf49466361..14df89510396 100644
--- a/drivers/staging/iio/impedance-analyzer/ad5933.c
+++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
@@ -116,45 +116,26 @@ static struct ad5933_platform_data ad5933_default_pdata
= {
.vref_mv = 3300,
};
+#define AD5933_CHANNEL(_type, _extend_name, _info_mask_separate, _address, \
+ _scan_index, _realbits) { \
+ .type = (_type), \
+ .extend_name = (_extend_name), \
+ .info_mask_separate = (_info_mask_separate), \
+ .address = (_address), \
+ .scan_index = (_scan_index), \
+ .scan_type = { \
+ .sign = 's', \
+ .realbits = (_realbits), \
+ .storagebits = 16, \
+ }, \
+}
+
static const struct iio_chan_spec ad5933_channels[] = {
- {
- .type = IIO_TEMP,
- .indexed = 1,
- .channel = 0,
- .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
- BIT(IIO_CHAN_INFO_SCALE),
- .address = AD5933_REG_TEMP_DATA,
- .scan_index = -1,
- .scan_type = {
- .sign = 's',
- .realbits = 14,
- .storagebits = 16,
- },
- }, { /* Ring Channels */
- .type = IIO_VOLTAGE,
- .indexed = 1,
- .channel = 0,
- .extend_name = "real",
- .address = AD5933_REG_REAL_DATA,
- .scan_index = 0,
- .scan_type = {
- .sign = 's',
- .realbits = 16,
- .storagebits = 16,
- },
- }, {
- .type = IIO_VOLTAGE,
- .indexed = 1,
- .channel = 0,
- .extend_name = "imag",
- .address = AD5933_REG_IMAG_DATA,
- .scan_index = 1,
- .scan_type = {
- .sign = 's',
- .realbits = 16,
- .storagebits = 16,
- },
- },
+ AD5933_CHANNEL(IIO_TEMP, NULL, BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE), AD5933_REG_TEMP_DATA, -1, 14),
+ /* Ring Channels */
+ AD5933_CHANNEL(IIO_VOLTAGE, "real", 0, AD5933_REG_REAL_DATA, 0, 16),
+ AD5933_CHANNEL(IIO_VOLTAGE, "imag", 0, AD5933_REG_IMAG_DATA, 1, 16),
};
static int ad5933_i2c_write(struct i2c_client *client, u8 reg, u8 len, u8
*data)
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 3/4] staging: rtl8723bs: use ether_addr_copy() in rtw_macaddr_cfg()
Use ether_addr_copy() instead of memcpy() to copy the mac address.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index 7aa00d1391f7..8af4a89e632f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -1172,15 +1172,15 @@ void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
for (jj = 0, kk = 0; jj < ETH_ALEN; jj++, kk += 3) {
mac[jj] = key_2char2num(rtw_initmac[kk], rtw_initmac[kk
+ 1]);
}
- memcpy(mac_addr, mac, ETH_ALEN);
+ ether_addr_copy(mac_addr, mac);
} else{ /* Use the mac address stored in the Efuse */
- memcpy(mac, mac_addr, ETH_ALEN);
+ ether_addr_copy(mac, mac_addr);
}
if (is_broadcast_ether_addr(mac) || is_zero_ether_addr(mac)) {
if ((addr = of_get_property(np, "local-mac-address", )) &&
len == ETH_ALEN) {
- memcpy(mac_addr, addr, ETH_ALEN);
+ ether_addr_copy(mac_addr, addr);
} else {
eth_random_addr(mac_addr);
DBG_871X("MAC Address from efuse error, assign random
one !!!\n");
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 4/4] staging: rtl8723bs: use mac_pton() in rtw_macaddr_cfg()
Use the mac_pton() helper to convert the mac address string.
The functions key_char2num() and key_2char2num() are not used
anywhere else and can be removed.
This also has the benefit of validating the input since mac_pton()
returns false if the string is not valid.
Signed-off-by: Michael Straube
---
.../staging/rtl8723bs/core/rtw_ieee80211.c| 30 +++
.../staging/rtl8723bs/os_dep/ioctl_linux.c| 3 --
2 files changed, 4 insertions(+), 29 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index 8af4a89e632f..62d19cfebb06 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -1137,25 +1137,6 @@ ParseRes rtw_ieee802_11_parse_elems(u8 *start, uint len,
}
-static u8 key_char2num(u8 ch);
-static u8 key_char2num(u8 ch)
-{
- if ((ch >= '0') && (ch <= '9'))
- return ch - '0';
- else if ((ch >= 'a') && (ch <= 'f'))
- return ch - 'a' + 10;
- else if ((ch >= 'A') && (ch <= 'F'))
- return ch - 'A' + 10;
- else
- return 0xff;
-}
-
-u8 key_2char2num(u8 hch, u8 lch);
-u8 key_2char2num(u8 hch, u8 lch)
-{
- return ((key_char2num(hch) << 4) | key_char2num(lch));
-}
-
void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
{
u8 mac[ETH_ALEN];
@@ -1166,14 +1147,11 @@ void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
if (!mac_addr)
return;
- if (rtw_initmac) { /* Users specify the mac address */
- int jj, kk;
-
- for (jj = 0, kk = 0; jj < ETH_ALEN; jj++, kk += 3) {
- mac[jj] = key_2char2num(rtw_initmac[kk], rtw_initmac[kk
+ 1]);
- }
+ if (rtw_initmac && mac_pton(rtw_initmac, mac)) {
+ /* Users specify the mac address */
ether_addr_copy(mac_addr, mac);
- } else{ /* Use the mac address stored in the Efuse */
+ } else{
+ /* Use the mac address stored in the Efuse */
ether_addr_copy(mac, mac_addr);
}
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index 39502156f652..4eb51f45b387 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -32,9 +32,6 @@
#define WEXT_CSCAN_HOME_DWELL_SECTION 'H'
#define WEXT_CSCAN_TYPE_SECTION'T'
-
-extern u8 key_2char2num(u8 hch, u8 lch);
-
static u32 rtw_rates[] = {100, 200, 550, 1100,
600, 900, 1200, 1800, 2400, 3600, 4800,
5400};
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/4] staging: rtl8723bs: refactor rtw_macaddr_cfg()
Using is_broadcast_ether_addr() and is_zero_ether_addr() instead of
testing each byte of the mac[] array for 0xff and 0x00 shortens the
code and improves readability.
If np == NULL, of_get_property() returns NULL, hence the "np" check
is not needed.
Instead of a fixed default mac address use a random one to reduce the
likelihood of mac address collision.
Thanks to Joe Perches and Dan Carpenter.
Signed-off-by: Michael Straube
---
.../staging/rtl8723bs/core/rtw_ieee80211.c| 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index e55895632921..7aa00d1391f7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -1177,24 +1177,13 @@ void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
memcpy(mac, mac_addr, ETH_ALEN);
}
- if (((mac[0] == 0xff) && (mac[1] == 0xff) && (mac[2] == 0xff) &&
-(mac[3] == 0xff) && (mac[4] == 0xff) && (mac[5] == 0xff)) ||
- ((mac[0] == 0x00) && (mac[1] == 0x00) && (mac[2] == 0x00) &&
-(mac[3] == 0x00) && (mac[4] == 0x00) && (mac[5] == 0x00))) {
- if (np &&
- (addr = of_get_property(np, "local-mac-address", )) &&
+ if (is_broadcast_ether_addr(mac) || is_zero_ether_addr(mac)) {
+ if ((addr = of_get_property(np, "local-mac-address", )) &&
len == ETH_ALEN) {
memcpy(mac_addr, addr, ETH_ALEN);
} else {
- mac[0] = 0x00;
- mac[1] = 0xe0;
- mac[2] = 0x4c;
- mac[3] = 0x87;
- mac[4] = 0x00;
- mac[5] = 0x00;
- /* use default mac addresss */
- memcpy(mac_addr, mac, ETH_ALEN);
- DBG_871X("MAC Address from efuse error, assign default
one !!!\n");
+ eth_random_addr(mac_addr);
+ DBG_871X("MAC Address from efuse error, assign random
one !!!\n");
}
}
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/4] staging: rtl8723bs: fix comparsion to NULL - coding style
Fix comparsion to NULL issues found by checkpatch.
Use !x instead of x == NULL.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index 0822e440204e..e55895632921 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
@@ -747,7 +747,7 @@ u8 rtw_is_wps_ie(u8 *ie_ptr, uint *wps_ielen)
u8 match = false;
u8 eid, wps_oui[4] = {0x0, 0x50, 0xf2, 0x04};
- if (ie_ptr == NULL)
+ if (!ie_ptr)
return match;
eid = ie_ptr[0];
@@ -1163,7 +1163,7 @@ void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
const unsigned char *addr;
int len;
- if (mac_addr == NULL)
+ if (!mac_addr)
return;
if (rtw_initmac) { /* Users specify the mac address */
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: rtl8723bs: remove rtw_set_tx_chksum_offload()
The function rtw_set_tx_chksum_offload() has empty definition.
Signed-off-by: Michael Straube
---
drivers/staging/rtl8723bs/core/rtw_xmit.c | 2 --
drivers/staging/rtl8723bs/include/xmit_osdep.h | 2 --
drivers/staging/rtl8723bs/os_dep/xmit_linux.c | 5 -
3 files changed, 9 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c
b/drivers/staging/rtl8723bs/core/rtw_xmit.c
index aaabffb0a199..3e7c1f07b8b4 100644
--- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
@@ -845,8 +845,6 @@ static s32 update_attrib(struct adapter *padapter, _pkt
*pkt, struct pkt_attrib
/* pattrib->priority = 5; force to used VI queue, for testing */
- rtw_set_tx_chksum_offload(pkt, pattrib);
-
exit:
return res;
}
diff --git a/drivers/staging/rtl8723bs/include/xmit_osdep.h
b/drivers/staging/rtl8723bs/include/xmit_osdep.h
index 377b453de199..a61412b54ec0 100644
--- a/drivers/staging/rtl8723bs/include/xmit_osdep.h
+++ b/drivers/staging/rtl8723bs/include/xmit_osdep.h
@@ -33,8 +33,6 @@ void rtw_os_xmit_schedule(struct adapter *padapter);
int rtw_os_xmit_resource_alloc(struct adapter *padapter, struct xmit_buf
*pxmitbuf, u32 alloc_sz, u8 flag);
void rtw_os_xmit_resource_free(struct adapter *padapter, struct xmit_buf
*pxmitbuf, u32 free_sz, u8 flag);
-extern void rtw_set_tx_chksum_offload(_pkt *pkt, struct pkt_attrib *pattrib);
-
extern uint rtw_remainder_len(struct pkt_file *pfile);
extern void _rtw_open_pktfile(_pkt *pkt, struct pkt_file *pfile);
extern uint _rtw_pktfile_read (struct pkt_file *pfile, u8 *rmem, uint rlen);
diff --git a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
index 4da0c6f323d1..2cf903c66854 100644
--- a/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/xmit_linux.c
@@ -46,11 +46,6 @@ sint rtw_endofpktfile(struct pkt_file *pfile)
return false;
}
-void rtw_set_tx_chksum_offload(_pkt *pkt, struct pkt_attrib *pattrib)
-{
-
-}
-
int rtw_os_xmit_resource_alloc(struct adapter *padapter, struct xmit_buf
*pxmitbuf, u32 alloc_sz, u8 flag)
{
if (alloc_sz > 0) {
--
2.18.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: omap4iss: Added SPDX license identifiers
Hi Daniel, Thank you for the patch. On Monday, 25 June 2018 16:21:32 EEST Daniel Graefe wrote: > Added missing SPDX license identifiers to all files of the omap4iss > driver. > > Most files already have license texts which clearly state them to be > licensed under GPL 2.0 or later. SPDX identifiers were added accordingly. > > Some files do not have any license text. SPDX identifiers for GPL 2.0 > were added to them, in accordance with the default license of the > kernel. > > Signed-off-by: Daniel Graefe > Signed-off-by: Roman Sommer > --- > drivers/staging/media/omap4iss/Kconfig | 2 ++ > drivers/staging/media/omap4iss/Makefile | 3 +++ > drivers/staging/media/omap4iss/iss.c | 1 + > drivers/staging/media/omap4iss/iss.h | 1 + > drivers/staging/media/omap4iss/iss_csi2.c| 1 + > drivers/staging/media/omap4iss/iss_csi2.h| 1 + > drivers/staging/media/omap4iss/iss_csiphy.c | 1 + > drivers/staging/media/omap4iss/iss_csiphy.h | 1 + > drivers/staging/media/omap4iss/iss_ipipe.c | 1 + > drivers/staging/media/omap4iss/iss_ipipe.h | 1 + > drivers/staging/media/omap4iss/iss_ipipeif.c | 1 + > drivers/staging/media/omap4iss/iss_ipipeif.h | 1 + > drivers/staging/media/omap4iss/iss_regs.h| 1 + > drivers/staging/media/omap4iss/iss_resizer.c | 1 + > drivers/staging/media/omap4iss/iss_resizer.h | 1 + > drivers/staging/media/omap4iss/iss_video.c | 1 + > drivers/staging/media/omap4iss/iss_video.h | 1 + > 17 files changed, 20 insertions(+) > > diff --git a/drivers/staging/media/omap4iss/Kconfig > b/drivers/staging/media/omap4iss/Kconfig index 273..841cc0b 100644 > --- a/drivers/staging/media/omap4iss/Kconfig > +++ b/drivers/staging/media/omap4iss/Kconfig > @@ -1,3 +1,5 @@ > +# SPDX-License-Identifier: GPL-2.0 > + > config VIDEO_OMAP4 > tristate "OMAP 4 Camera support" > depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C > diff --git a/drivers/staging/media/omap4iss/Makefile > b/drivers/staging/media/omap4iss/Makefile index a716ce9..e64d489 100644 > --- a/drivers/staging/media/omap4iss/Makefile > +++ b/drivers/staging/media/omap4iss/Makefile > @@ -1,4 +1,7 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > # Makefile for OMAP4 ISS driver > +# > > omap4-iss-objs += \ > iss.o iss_csi2.o iss_csiphy.o iss_ipipeif.o iss_ipipe.o iss_resizer.o > iss_video.o diff --git a/drivers/staging/media/omap4iss/iss.c > b/drivers/staging/media/omap4iss/iss.c index b1036ba..0c41939 100644 > --- a/drivers/staging/media/omap4iss/iss.c > +++ b/drivers/staging/media/omap4iss/iss.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later The SPDX identifier used for "GPL v2.0 or later" in the kernel is GPL-2.0+, as documented in Documentation/process/license-rules.rst. I'm aware that that identifier has been deprecated by the FSF in favour of the GPL-2.0-or-later identifier, but until Documentation/process/license-rules.rst gets updated, please use GPL-2.0+. > /* > * TI OMAP4 ISS V4L2 Driver > * Could you please remove the boilerplate license text, as it's not needed anymore ? Those two comments apply to all the other files. [snip$ -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: pi433: replace simple switch statements
If there are going to be actual users in the specific near term then that's fine. Otherwise if we're talking a year out, then it's too far away to predict what will happen a year from now so we should delete the dead weight. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: pi433: replace simple switch statements
Hi Dan, I'd like to mention once more, that the idea of the abstraction was to support multiple modules of Hope-RF. If the decision of the "team" of developer of this driver is, that it should be reduced to a Pi433 or RFM69CW driver only, I fully agree, that the abstraction layer isn't necessary (tough improving readability). But if the "team" wants to extend the driver - here I explicitly want to Name Marcin Ciupak and Hogo Lefeuvre, both were discussing this with me - I highly recommend to keep the abstraction layer. And once again, I have to announce, that - if noone appears, who wants to help me with selling Pi433 - I can't effort to let Pi433 on the market longer then end of this year. From this Point of view on long term it might be senseless to prepare a Pi433-only driver. Cheers, Marcus Dan Carpenter schrieb am 25.06.2018 14:35: > I'd still prefer if we just removed this abstraction entirely and used > OPMODE_MODE_TRANSMIT everywhere instead of bringing "transmit" into it. > > I know that every author thinks their abstraction will definitely be > useful in the future, but generally kernel style is to remove > abstractions. > > But I guess this code is an improvement over the original so the patch > is fine. > > regards, > dan carpenter > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: media: omap4iss: Added SPDX license identifiers
Added missing SPDX license identifiers to all files of the omap4iss driver. Most files already have license texts which clearly state them to be licensed under GPL 2.0 or later. SPDX identifiers were added accordingly. Some files do not have any license text. SPDX identifiers for GPL 2.0 were added to them, in accordance with the default license of the kernel. Signed-off-by: Daniel Graefe Signed-off-by: Roman Sommer --- drivers/staging/media/omap4iss/Kconfig | 2 ++ drivers/staging/media/omap4iss/Makefile | 3 +++ drivers/staging/media/omap4iss/iss.c | 1 + drivers/staging/media/omap4iss/iss.h | 1 + drivers/staging/media/omap4iss/iss_csi2.c| 1 + drivers/staging/media/omap4iss/iss_csi2.h| 1 + drivers/staging/media/omap4iss/iss_csiphy.c | 1 + drivers/staging/media/omap4iss/iss_csiphy.h | 1 + drivers/staging/media/omap4iss/iss_ipipe.c | 1 + drivers/staging/media/omap4iss/iss_ipipe.h | 1 + drivers/staging/media/omap4iss/iss_ipipeif.c | 1 + drivers/staging/media/omap4iss/iss_ipipeif.h | 1 + drivers/staging/media/omap4iss/iss_regs.h| 1 + drivers/staging/media/omap4iss/iss_resizer.c | 1 + drivers/staging/media/omap4iss/iss_resizer.h | 1 + drivers/staging/media/omap4iss/iss_video.c | 1 + drivers/staging/media/omap4iss/iss_video.h | 1 + 17 files changed, 20 insertions(+) diff --git a/drivers/staging/media/omap4iss/Kconfig b/drivers/staging/media/omap4iss/Kconfig index 273..841cc0b 100644 --- a/drivers/staging/media/omap4iss/Kconfig +++ b/drivers/staging/media/omap4iss/Kconfig @@ -1,3 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 + config VIDEO_OMAP4 tristate "OMAP 4 Camera support" depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && I2C diff --git a/drivers/staging/media/omap4iss/Makefile b/drivers/staging/media/omap4iss/Makefile index a716ce9..e64d489 100644 --- a/drivers/staging/media/omap4iss/Makefile +++ b/drivers/staging/media/omap4iss/Makefile @@ -1,4 +1,7 @@ +# SPDX-License-Identifier: GPL-2.0 +# # Makefile for OMAP4 ISS driver +# omap4-iss-objs += \ iss.o iss_csi2.o iss_csiphy.o iss_ipipeif.o iss_ipipe.o iss_resizer.o iss_video.o diff --git a/drivers/staging/media/omap4iss/iss.c b/drivers/staging/media/omap4iss/iss.c index b1036ba..0c41939 100644 --- a/drivers/staging/media/omap4iss/iss.c +++ b/drivers/staging/media/omap4iss/iss.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-or-later /* * TI OMAP4 ISS V4L2 Driver * diff --git a/drivers/staging/media/omap4iss/iss.h b/drivers/staging/media/omap4iss/iss.h index 760ee27..b16a5c0 100644 --- a/drivers/staging/media/omap4iss/iss.h +++ b/drivers/staging/media/omap4iss/iss.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ /* * TI OMAP4 ISS V4L2 Driver * diff --git a/drivers/staging/media/omap4iss/iss_csi2.c b/drivers/staging/media/omap4iss/iss_csi2.c index f6acc54..cdfd12f 100644 --- a/drivers/staging/media/omap4iss/iss_csi2.c +++ b/drivers/staging/media/omap4iss/iss_csi2.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-or-later /* * TI OMAP4 ISS V4L2 Driver - CSI PHY module * diff --git a/drivers/staging/media/omap4iss/iss_csi2.h b/drivers/staging/media/omap4iss/iss_csi2.h index 24ab378..cee02ee 100644 --- a/drivers/staging/media/omap4iss/iss_csi2.h +++ b/drivers/staging/media/omap4iss/iss_csi2.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ /* * TI OMAP4 ISS V4L2 Driver - CSI2 module * diff --git a/drivers/staging/media/omap4iss/iss_csiphy.c b/drivers/staging/media/omap4iss/iss_csiphy.c index 748607f..253b6aa 100644 --- a/drivers/staging/media/omap4iss/iss_csiphy.c +++ b/drivers/staging/media/omap4iss/iss_csiphy.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-or-later /* * TI OMAP4 ISS V4L2 Driver - CSI PHY module * diff --git a/drivers/staging/media/omap4iss/iss_csiphy.h b/drivers/staging/media/omap4iss/iss_csiphy.h index a0f2d97..f264c51 100644 --- a/drivers/staging/media/omap4iss/iss_csiphy.h +++ b/drivers/staging/media/omap4iss/iss_csiphy.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ /* * TI OMAP4 ISS V4L2 Driver - CSI PHY module * diff --git a/drivers/staging/media/omap4iss/iss_ipipe.c b/drivers/staging/media/omap4iss/iss_ipipe.c index d86ef8a..9f90641 100644 --- a/drivers/staging/media/omap4iss/iss_ipipe.c +++ b/drivers/staging/media/omap4iss/iss_ipipe.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-or-later /* * TI OMAP4 ISS V4L2 Driver - ISP IPIPE module * diff --git a/drivers/staging/media/omap4iss/iss_ipipe.h b/drivers/staging/media/omap4iss/iss_ipipe.h index d5b441d..54718f0 100644 --- a/drivers/staging/media/omap4iss/iss_ipipe.h +++ b/drivers/staging/media/omap4iss/iss_ipipe.h @@ -1,3 +1,4 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ /* * TI OMAP4 ISS V4L2 Driver - ISP IPIPE module * diff --git a/drivers/staging/media/omap4iss/iss_ipipeif.c b/drivers/staging/media/omap4iss/iss_ipipeif.c index cb88b2b..6cc9a43
Re: [PATCH v3 3/8] staging: rtl8192u: User memset to initialize memory, instead of loop.
> On 25 June 2018 at 13:36 John Whitmore wrote: > > > On Mon, Jun 25, 2018 at 12:06:30PM +0300, Andy Shevchenko wrote: > > On Sun, Jun 24, 2018 at 6:34 PM, John Whitmore > > wrote: > > > Replaced memory initialising loop with memset, as suggested by Andy > > > Shevchenko > > > > > > > Suggested-by ? > > > > Em, not sure how to respond, it certainly wasn't my idea. I was just making > coding style changes, badly. ;) Suggested-by is a tag for patches, to give credit. For example: https://elixir.bootlin.com/linux/v4.18-rc1/source/Documentation/process/submitting-patches.rst See section "13) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:" Hope that helps, Justin. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: pi433: replace simple switch statements
I'd still prefer if we just removed this abstraction entirely and used OPMODE_MODE_TRANSMIT everywhere instead of bringing "transmit" into it. I know that every author thinks their abstraction will definitely be useful in the future, but generally kernel style is to remove abstractions. But I guess this code is an improvement over the original so the patch is fine. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 3/8] staging: rtl8192u: User memset to initialize memory, instead of loop.
On Mon, Jun 25, 2018 at 12:06:30PM +0300, Andy Shevchenko wrote: > On Sun, Jun 24, 2018 at 6:34 PM, John Whitmore > wrote: > > Replaced memory initialising loop with memset, as suggested by Andy > > Shevchenko > > > > Suggested-by ? > Em, not sure how to respond, it certainly wasn't my idea. I was just making coding style changes, badly. ;) John ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix brace coding style issues
On Mon, Jun 25, 2018 at 12:47:44PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 22, 2018 at 1:28 PM, Dan Carpenter
> wrote:
> > On Thu, Jun 21, 2018 at 08:21:55PM +0200, Michael Straube wrote:
> >> Remove braces from single line if statements.
> >> Also fix a comparsion to NULL in one of the conditions.
> >> Issues found by checkpatch.
> >>
> >> Signed-off-by: Michael Straube
> >> ---
> >> drivers/staging/rtl8723bs/core/rtw_debug.c | 6 ++
> >> 1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c
> >> b/drivers/staging/rtl8723bs/core/rtw_debug.c
> >> index f852fde47350..2244ed72ab9c 100644
> >> --- a/drivers/staging/rtl8723bs/core/rtw_debug.c
> >> +++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
> >> @@ -618,9 +618,8 @@ ssize_t proc_set_wait_hiq_empty(struct file *file,
> >> const char __user *buffer, si
> >> if (count < 1)
> >> return -EFAULT;
> >>
> >> - if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp))) {
> >> + if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp)))
> >> sscanf(tmp, "%u", _wait_hiq_empty);
> >> - }
> >
> >
> > The original code is kind of bad. The NULL check isn't required.
> > The sscanf call should have error checking. The error code is wrong if
> > the copy from user fails. The tmp buffer isn't NUL terminated.
> >
> > if (copy_from_user(tmp, buffer, sizeof(tmp)))
> > return -EFAULT;
> > tmp[sizeof(tmp) - 1] = '\0';
> >
> > if (sscanf(tmp, "%u", _wait_hiq_empty) != 1)
> > return -EINVAL;
> >
> > return count;
>
> Shouldn't this be
>
> kstrtouint_from_user()
>
> instead of all those lines?
I wasn't sure kstrtoint() was the exact same as sscanf()... If so then
sure.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: pi433: cleanup comments in rf69.h
Fixes checkpatch warning: WARNING: line over 80 characters Signed-off-by: Valentin Vidic --- drivers/staging/pi433/rf69.h | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/staging/pi433/rf69.h b/drivers/staging/pi433/rf69.h index c131ffbdc2db..d80c41966d39 100644 --- a/drivers/staging/pi433/rf69.h +++ b/drivers/staging/pi433/rf69.h @@ -20,10 +20,11 @@ #include "rf69_enum.h" #include "rf69_registers.h" -#define F_OSC 3200 /* in Hz */ -#define FREQUENCY 43392 /* in Hz, modifying this value impacts CE certification */ -#define FIFO_SIZE 66 /* in byte */ -#define FIFO_THRESHOLD 15 /* in byte */ +/* NOTE: Modifying FREQUENCY value impacts CE certification */ +#define F_OSC 3200/* Hz */ +#define FREQUENCY 43392 /* Hz */ +#define FIFO_SIZE 66 /* bytes */ +#define FIFO_THRESHOLD 15 /* bytes */ int rf69_set_mode(struct spi_device *spi, enum mode mode); int rf69_set_data_mode(struct spi_device *spi, u8 data_mode); -- 2.18.0.rc2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: pi433: add SPDX-License-Identifier tag
Use GPL-2.0+ based on the license text in each of the files. Signed-off-by: Valentin Vidic --- drivers/staging/pi433/pi433_if.c | 1 + drivers/staging/pi433/pi433_if.h | 3 ++- drivers/staging/pi433/rf69.c | 1 + drivers/staging/pi433/rf69.h | 3 ++- drivers/staging/pi433/rf69_enum.h | 3 ++- drivers/staging/pi433/rf69_registers.h | 3 ++- 6 files changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c index b061f77dda41..e2b8a518dafe 100644 --- a/drivers/staging/pi433/pi433_if.c +++ b/drivers/staging/pi433/pi433_if.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * userspace interface for pi433 radio module * diff --git a/drivers/staging/pi433/pi433_if.h b/drivers/staging/pi433/pi433_if.h index b6e214c29ddf..0e0c1b0ab1a6 100644 --- a/drivers/staging/pi433/pi433_if.h +++ b/drivers/staging/pi433/pi433_if.h @@ -1,4 +1,5 @@ -/* +/* SPDX-License-Identifier: GPL-2.0+ + * * include/linux/TODO * * userspace interface for pi433 radio module diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c index 90280e9b006d..e4a1e64c868a 100644 --- a/drivers/staging/pi433/rf69.c +++ b/drivers/staging/pi433/rf69.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0+ /* * abstraction of the spi interface of HopeRf rf69 radio module * diff --git a/drivers/staging/pi433/rf69.h b/drivers/staging/pi433/rf69.h index c131ffbdc2db..2cec9a9c34d2 100644 --- a/drivers/staging/pi433/rf69.h +++ b/drivers/staging/pi433/rf69.h @@ -1,4 +1,5 @@ -/* +/* SPDX-License-Identifier: GPL-2.0+ + * * hardware abstraction/register access for HopeRf rf69 radio module * * Copyright (C) 2016 Wolf-Entwicklungen diff --git a/drivers/staging/pi433/rf69_enum.h b/drivers/staging/pi433/rf69_enum.h index 493bd0025453..de3b7e32dad7 100644 --- a/drivers/staging/pi433/rf69_enum.h +++ b/drivers/staging/pi433/rf69_enum.h @@ -1,4 +1,5 @@ -/* +/* SPDX-License-Identifier: GPL-2.0+ + * * enumerations for HopeRf rf69 radio module * * Copyright (C) 2016 Wolf-Entwicklungen diff --git a/drivers/staging/pi433/rf69_registers.h b/drivers/staging/pi433/rf69_registers.h index 33fd91518bb0..ea19c1ca7509 100644 --- a/drivers/staging/pi433/rf69_registers.h +++ b/drivers/staging/pi433/rf69_registers.h @@ -1,4 +1,5 @@ -/* +/* SPDX-License-Identifier: GPL-2.0+ + * * register description for HopeRf rf69 radio module * * Copyright (C) 2016 Wolf-Entwicklungen -- 2.18.0.rc2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 7/8] staging: rtl8192u: Correct if statement - Coding Style
On Sun, Jun 24, 2018 at 08:59:22AM -0700, Joe Perches wrote: > Rather than doing individual patches for each line > with a whitespace issue, I think it'd be better to > do a single driver wide patch. > > Perhaps use a tool like: > > $ git ls-files drivers/staging/rtl8192u | > xargs ./scripts/checkpatch.pl -f --fix-inplace --types=spacing > > where: > > $ git diff -w drivers/staging/rtl8192u/ > > should not show a single difference. > > Then compile and commit that as a single patch with > something like "use a more typical spacing style" > as the commit message. > Thank you for that command. Hadn't found the "--types=spacing" option. I'd fixed all the spacing issues in that file in a previous patch set. That space issue was in a commented out section of code, which is why I missed it previously. I think that file has all space issues cleared so there's only the single fix in this patch. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: refactor rtw_macaddr_cfg()
On Sat, Jun 23, 2018 at 12:45 PM, Michael Straube
wrote:
> Using is_broadcast_ether_addr() and is_zero_ether_addr() instead of
> testing each byte of the mac[] array for 0xff and 0x00 shortens the
> code and improves readability.
>
> If np == NULL, of_get_property() returns NULL, hence the "np" check
> is not needed.
>
> Instead of a fixed default mac address use a random one to reduce the
> likelihood of mac address collision.
>
> Thanks to Joe Perches and Dan Carpenter.
> + if ((addr = of_get_property(np, "local-mac-address", )) &&
> len == ETH_ALEN) {
> memcpy(mac_addr, addr, ETH_ALEN);
ether_addr_copy()?
> } else {
> + eth_random_addr(mac_addr);
> + DBG_871X("MAC Address from efuse error, assign random
> one !!!\n");
> }
--
With Best Regards,
Andy Shevchenko
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: do not use assignment in if condition
On Fri, Jun 22, 2018 at 8:28 PM, Joe Perches wrote: > On Fri, 2018-06-22 at 14:48 +0200, Michael Straube wrote: >> On 06/22/18 12:57, Dan Carpenter wrote: > Output from checkpatch is not gospel and can be ignored > whenever appropriate. > > I think the below is ok: > > if ((is_broadcast_ether_addr(mac) || is_zero_ether_addr(mac)) && > ((addr = of_get_property(np, "local-mac-address", )) && > len == ETH_ALEN)) > memcpy(mac_addr, addr, ETH_ALEN); > else > memcpy(mac_addr, ""\x00\xe0\x4c\x87\x00\x00", ETH_ALEN); > > Although the last memcpy of a fixed mac address could > probably use eth_random_addr to reduce the likelihood > of mac address collision ...and first one looks like ether_addr_copy(). > so maybe > > if ((is_broadcast_ether_addr(mac) || is_zero_ether_addr(mac)) && > ((addr = of_get_property(np, "local-mac-address", )) && > > len == ETH_ALEN)) > memcpy(mac_addr, addr, ETH_ALEN); > else > eth_random_addr(mac_addr); > >> If yes, I'm not sure how to proceed as these are the very first patches I >> send. >> Should I send a v2 patch with both changes or just a v2 with "np" removed and >> another one for adding 'is_broadcast_ether_addr' and 'is_zero_ether_addr' >> checks? -- With Best Regards, Andy Shevchenko ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix brace coding style issues
On Fri, Jun 22, 2018 at 1:28 PM, Dan Carpenter wrote:
> On Thu, Jun 21, 2018 at 08:21:55PM +0200, Michael Straube wrote:
>> Remove braces from single line if statements.
>> Also fix a comparsion to NULL in one of the conditions.
>> Issues found by checkpatch.
>>
>> Signed-off-by: Michael Straube
>> ---
>> drivers/staging/rtl8723bs/core/rtw_debug.c | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c
>> b/drivers/staging/rtl8723bs/core/rtw_debug.c
>> index f852fde47350..2244ed72ab9c 100644
>> --- a/drivers/staging/rtl8723bs/core/rtw_debug.c
>> +++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
>> @@ -618,9 +618,8 @@ ssize_t proc_set_wait_hiq_empty(struct file *file, const
>> char __user *buffer, si
>> if (count < 1)
>> return -EFAULT;
>>
>> - if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp))) {
>> + if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp)))
>> sscanf(tmp, "%u", _wait_hiq_empty);
>> - }
>
>
> The original code is kind of bad. The NULL check isn't required.
> The sscanf call should have error checking. The error code is wrong if
> the copy from user fails. The tmp buffer isn't NUL terminated.
>
> if (copy_from_user(tmp, buffer, sizeof(tmp)))
> return -EFAULT;
> tmp[sizeof(tmp) - 1] = '\0';
>
> if (sscanf(tmp, "%u", _wait_hiq_empty) != 1)
> return -EINVAL;
>
> return count;
Shouldn't this be
kstrtouint_from_user()
instead of all those lines?
--
With Best Regards,
Andy Shevchenko
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 3/8] staging: rtl8192u: User memset to initialize memory, instead of loop.
On Sun, Jun 24, 2018 at 6:34 PM, John Whitmore wrote:
> Replaced memory initialising loop with memset, as suggested by Andy Shevchenko
>
Suggested-by ?
> Signed-off-by: John Whitmore
> ---
> drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
> b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
> index 4bfadb49c363..ccb7bdf5ad5d 100644
> --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
> +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HTProc.c
> @@ -742,8 +742,6 @@ void HTConstructRT2RTAggElement(struct ieee80211_device
> *ieee, u8 *posRT2RTAgg,
> */
> static u8 HT_PickMCSRate(struct ieee80211_device *ieee, u8 *pOperateMCS)
> {
> - u8 i;
> -
> if (!pOperateMCS) {
> IEEE80211_DEBUG(IEEE80211_DL_ERR, "pOperateMCS can't be null
> in HT_PickMCSRate()\n");
> return false;
> @@ -756,8 +754,7 @@ static u8 HT_PickMCSRate(struct ieee80211_device *ieee,
> u8 *pOperateMCS)
> //legacy rate routine handled at selectedrate
>
> //no MCS rate
> - for (i = 0; i <= 15; i++)
> - pOperateMCS[i] = 0;
> + memset(pOperateMCS, 0, 16);
> break;
>
> case IEEE_N_24G://assume CCK rate ok
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
