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://github.com/torvalds/linux/commit/88c9281a9fba67636ab26c1fd6afbc78a632374f) > > 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://github.com/torvalds/linux/blob/e7aa8c2eb11ba69b1b69099c3c7bd6be3087b0ba/Documentation/process/stable-api-nonsense.rst Or better yet, in a pretty html format: https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html 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
hello
I intend to leave my money to you,am also giving my body to science for research. I want this last act of mine to be an offering to humanity. I'm diagnosed with laryngeal cancer,respond so i know you got this. Bless you ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] drivers/android: use SPDX license information
On Fri, Jun 22, 2018 at 08:27:24AM -0700, Todd Kjos wrote: > Are you planning to add this for every source file in the kernel tree? Someone has to, yes, we are planning on converting the whole tree, it's about 1/3 done so far. > Why this file? Odds are checkpatch was run on this and it complained about it. But: > On Fri, Jun 22, 2018 at 2:25 AM Mawanda Henry > wrote: > > > > SPDX license helps developers and machines to know the right license > > governing a file > > > > Signed-off-by: Mawanda Henry > > --- > > drivers/android/binder_alloc.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c > > index 2628806..84da232 100644 > > --- a/drivers/android/binder_alloc.c > > +++ b/drivers/android/binder_alloc.c > > @@ -1,3 +1,4 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later When adding license information to a file, you had BETTER get it right. This isn't the correct license for this file, sorry. Do NOT do these types of kernel changes unless you really understand license information please. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
hello
I intend to leave my money to you,am also giving my body to science for research. I want this last act of mine to be an offering to GOD and humanity. I'm diagnosed with laryngeal cancer,respond so i know you got this. Bless you ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/4] staging: wlan-ng: replace macro with inline function in prism2mgmt.c
checkpatch gives the following message for the p80211rate_to_p2bit
macro:
CHECK: Macro argument reuse 'n' - possible side-effects?
To fix the message, replace the macro with an equivalent inline
function.
Signed-off-by: Tim Collier
---
drivers/staging/wlan-ng/prism2mgmt.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
b/drivers/staging/wlan-ng/prism2mgmt.c
index d7de9e9c47a2..28e4029d46f6 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -85,10 +85,21 @@
#include "prism2mgmt.h"
/* Converts 802.11 format rate specifications to prism2 */
-#define p80211rate_to_p2bit(n) n) & ~BIT(7)) == 2) ? BIT(0) : \
-(((n) & ~BIT(7)) == 4) ? BIT(1) : \
-(((n) & ~BIT(7)) == 11) ? BIT(2) : \
-(((n) & ~BIT(7)) == 22) ? BIT(3) : 0)
+static inline u16 p80211rate_to_p2bit(u32 rate)
+{
+ switch (rate & ~BIT(7)) {
+ case 2:
+ return BIT(0);
+ case 4:
+ return BIT(1);
+ case 11:
+ return BIT(2);
+ case 22:
+ return BIT(3);
+ default:
+ return 0;
+ }
+}
/*
* prism2mgmt_scan
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/4] staging: wlan-ng: replace WLAN_CTL_FRAMELEN with inline function in p80211hdr.h
checkpatch reports a "CHECK" diagnostic for WLAN_CTL_FRAMELEN as the
macro reuses its argument, leading to possible side-effects. Avoid
this by replacing the macro with an equivalent function, named
wlan_ctl_framelen (as recommended in the coding style). All references
to the macro also updated accordingly.
Signed-off-by: Tim Collier
---
drivers/staging/wlan-ng/p80211hdr.h | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/wlan-ng/p80211hdr.h
b/drivers/staging/wlan-ng/p80211hdr.h
index 26b178721414..6564810fd026 100644
--- a/drivers/staging/wlan-ng/p80211hdr.h
+++ b/drivers/staging/wlan-ng/p80211hdr.h
@@ -174,15 +174,25 @@ union p80211_hdr {
/* Frame and header length macros */
-#define WLAN_CTL_FRAMELEN(fstype) (\
- (fstype) == WLAN_FSTYPE_BLOCKACKREQ ? 24 : \
- (fstype) == WLAN_FSTYPE_BLOCKACK? 152 : \
- (fstype) == WLAN_FSTYPE_PSPOLL ? 20 : \
- (fstype) == WLAN_FSTYPE_RTS ? 20 : \
- (fstype) == WLAN_FSTYPE_CTS ? 14 : \
- (fstype) == WLAN_FSTYPE_ACK ? 14 : \
- (fstype) == WLAN_FSTYPE_CFEND ? 20 : \
- (fstype) == WLAN_FSTYPE_CFENDCFACK ? 20 : 4)
+static inline u16 wlan_ctl_framelen(u16 fstype)
+{
+ switch (fstype) {
+ case WLAN_FSTYPE_BLOCKACKREQ:
+ return 24;
+ case WLAN_FSTYPE_BLOCKACK:
+ return 152;
+ case WLAN_FSTYPE_PSPOLL:
+ case WLAN_FSTYPE_RTS:
+ case WLAN_FSTYPE_CFEND:
+ case WLAN_FSTYPE_CFENDCFACK:
+ return 20;
+ case WLAN_FSTYPE_CTS:
+ case WLAN_FSTYPE_ACK:
+ return 14;
+ default:
+ return 4;
+ }
+}
#define WLAN_FCS_LEN 4
@@ -201,7 +211,7 @@ static inline u16 p80211_headerlen(u16 fctl)
hdrlen += ETH_ALEN;
break;
case WLAN_FTYPE_CTL:
- hdrlen = WLAN_CTL_FRAMELEN(WLAN_GET_FC_FSTYPE(fctl)) -
+ hdrlen = wlan_ctl_framelen(WLAN_GET_FC_FSTYPE(fctl)) -
WLAN_FCS_LEN;
break;
default:
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] staging: wlan-ng: fix coding style (indentation) in prism2mib.c
Fix "CHECK: Alignment should match open parenthesis" reported by
checkpatch.pl.
Signed-off-by: Tim Collier
---
drivers/staging/wlan-ng/prism2mib.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2mib.c
b/drivers/staging/wlan-ng/prism2mib.c
index edad299ff5ad..e88baf715cec 100644
--- a/drivers/staging/wlan-ng/prism2mib.c
+++ b/drivers/staging/wlan-ng/prism2mib.c
@@ -87,10 +87,10 @@ struct mibrec {
u16 parm2;
u16 parm3;
int (*func)(struct mibrec *mib,
-int isget,
-struct wlandevice *wlandev,
-struct hfa384x *hw,
-struct p80211msg_dot11req_mibset *msg, void *data);
+ int isget,
+ struct wlandevice *wlandev,
+ struct hfa384x *hw,
+ struct p80211msg_dot11req_mibset *msg, void *data);
};
static int prism2mib_bytearea2pstr(struct mibrec *mib,
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] staging: wlan-ng: coding style changes
Changes to fix issues reported by checkpatch. Tim Collier (4): staging: wlan-ng: fix coding style (indentation) in prism2mib.c staging: wlan-ng: replace WLAN_CTL_FRAMELEN with inline function in p80211hdr.h staging: wlan-ng: replace macro with inline function in prism2mgmt.c staging: wlan-ng: add parentheses to macro argument usage in prism2mgmt.c drivers/staging/wlan-ng/p80211hdr.h | 30 -- drivers/staging/wlan-ng/prism2mgmt.c | 23 +-- drivers/staging/wlan-ng/prism2mib.c | 8 3 files changed, 41 insertions(+), 20 deletions(-) -- 2.11.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] staging: wlan-ng: add parentheses to macro argument usage in prism2mgmt.c
Fix two "CHECK: Macro argument 'N' may be better as '(N)' to avoid
precedence issue" messages, reported by checkpatch, by adding
parentheses around the offending macro argument references.
Signed-off-by: Tim Collier
---
drivers/staging/wlan-ng/prism2mgmt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
b/drivers/staging/wlan-ng/prism2mgmt.c
index 28e4029d46f6..ebfe69b138c7 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -439,7 +439,7 @@ int prism2mgmt_scan_results(struct wlandevice *wlandev,
void *msgp)
#define REQBASICRATE(N) \
do { \
- if ((count >= N) && DOT11_RATE5_ISBASIC_GET( \
+ if ((count >= (N)) && DOT11_RATE5_ISBASIC_GET( \
item->supprates[(N) - 1])) { \
req->basicrate ## N .data = item->supprates[(N) - 1]; \
req->basicrate ## N .status = \
@@ -458,7 +458,7 @@ int prism2mgmt_scan_results(struct wlandevice *wlandev,
void *msgp)
#define REQSUPPRATE(N) \
do { \
- if (count >= N) { \
+ if (count >= (N)) { \
req->supprate ## N .data = item->supprates[(N) - 1]; \
req->supprate ## N .status = \
P80211ENUM_msgitem_status_data_ok; \
--
2.11.0
___
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 06/22/18 19:28, Joe Perches wrote:
On Fri, 2018-06-22 at 14:48 +0200, Michael Straube wrote:
On 06/22/18 12:57, Dan Carpenter wrote:
On Fri, Jun 22, 2018 at 03:54:22AM -0700, Joe Perches wrote:
On Fri, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
Fix checkpatch error 'do not use assignment in if condition'.
[]
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index e55895632921..87a4ced41028 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/
@@ -1181,9 +1181,8 @@ void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
(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))) {
Should also use is_broadcast_ether_addr and is_zero_ether_addr
- if (np &&
- (addr = of_get_property(np, "local-mac-address", )) &&
- len == ETH_ALEN) {
+ addr = of_get_property(np, "local-mac-address", );
+ if (np && addr && len == ETH_ALEN) {
You can remove the "np" check.
if (addr && len == ETH_ALEN) {
It looks more like the rewrite is incorrect
as np is tested before of_get_property
That's what I was worried about too, but if "np" is NULL then
of_get_property() just returns NULL so it's fine.
So it should be this?
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)) &&
(is_broadcast_ether_addr(mac) || is_zero_ether_addr(mac))) {
No as the mac[] tests are the same as is__ether_addr
Ok, I understand now.
and there's nothing really objectionable about embedding
the assignment in the if here.
Output from checkpatch is not gospel and can be ignored
whenever appropriate.
Ok, good to know.
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 so maybe
eth_random_addr(mac_addr);
Using a random address would be preffered?
Thanks for your help and patience.
Michael
___
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, 2018-06-22 at 14:48 +0200, Michael Straube wrote:
> On 06/22/18 12:57, Dan Carpenter wrote:
> > On Fri, Jun 22, 2018 at 03:54:22AM -0700, Joe Perches wrote:
> > > On Fri, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
> > > > On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
> > > > > Fix checkpatch error 'do not use assignment in if condition'.
> > > []
> > > > > diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > > > > b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > > > > index e55895632921..87a4ced41028 100644
> > > > > --- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > > > > +++ b/
> > > > > @@ -1181,9 +1181,8 @@ void rtw_macaddr_cfg(struct device *dev, u8
> > > > > *mac_addr)
> > > > >(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)))
> > > > > {
> > >
> > > Should also use is_broadcast_ether_addr and is_zero_ether_addr
> > >
> > > > > - if (np &&
> > > > > - (addr = of_get_property(np, "local-mac-address",
> > > > > )) &&
> > > > > - len == ETH_ALEN) {
> > > > > + addr = of_get_property(np, "local-mac-address", );
> > > > > + if (np && addr && len == ETH_ALEN) {
> > > >
> > > > You can remove the "np" check.
> > > >
> > > > if (addr && len == ETH_ALEN) {
> > >
> > > It looks more like the rewrite is incorrect
> > > as np is tested before of_get_property
> > >
> >
> > That's what I was worried about too, but if "np" is NULL then
> > of_get_property() just returns NULL so it's fine.
>
> So it should be this?
>
> 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)) &&
> (is_broadcast_ether_addr(mac) || is_zero_ether_addr(mac))) {
No as the mac[] tests are the same as is__ether_addr
and there's nothing really objectionable about embedding
the assignment in the if here.
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 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?
I'd send 1 patch.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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
---
arch/x86/hyperv/hv_apic.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 90055f89223b..ee962784d25b 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -99,6 +99,9 @@ static bool __send_ipi_mask_ex(const struct cpumask *mask,
int vector)
int nr_bank = 0;
int ret = 1;
+ if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
+ return false;
+
local_irq_save(flags);
arg = (struct ipi_arg_ex **)this_cpu_ptr(hyperv_pcpu_input_arg);
@@ -140,8 +143,18 @@ static bool __send_ipi_mask(const struct cpumask *mask,
int vector)
if ((vector < HV_IPI_LOW_VECTOR) || (vector > HV_IPI_HIGH_VECTOR))
return false;
- if ((ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
- return __send_ipi_mask_ex(mask, vector);
+ /*
+* From the supplied CPU set we need to figure out if we can get away
+* with cheaper HVCALL_SEND_IPI hypercall. This is possible when the
+* highest VP number in the set is < 64. As VP numbers are usually in
+* ascending order and match Linux CPU ids, here is an optimization:
+* we check the VP number for the highest bit in the supplied set first
+* so we can quickly find out if using HVCALL_SEND_IPI_EX hypercall is
+* a must. We will also check all VP numbers when walking the supplied
+* CPU set to remain correct in all cases.
+*/
+ if (hv_cpu_number_to_vp_number(cpumask_last(mask)) >= 64)
+ goto do_ex_hypercall;
ipi_arg.vector = vector;
ipi_arg.cpu_mask = 0;
@@ -153,16 +166,17 @@ static bool __send_ipi_mask(const struct cpumask *mask,
int vector)
* only target upto 64 CPUs.
*/
if (vcpu >= 64)
- goto ipi_mask_done;
+ goto do_ex_hypercall;
__set_bit(vcpu, (unsigned long *)_arg.cpu_mask);
}
ret = hv_do_fast_hypercall16(HVCALL_SEND_IPI, ipi_arg.vector,
ipi_arg.cpu_mask);
-
-ipi_mask_done:
return ((ret == 0) ? true : false);
+
+do_ex_hypercall:
+ return __send_ipi_mask_ex(mask, vector);
}
static bool __send_ipi_one(int cpu, int vector)
@@ -218,10 +232,7 @@ static void hv_send_ipi_self(int vector)
void __init hv_apic_init(void)
{
if (ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) {
- if ((ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
- pr_info("Hyper-V: Using ext hypercalls for IPI\n");
- else
- pr_info("Hyper-V: Using IPI hypercalls\n");
+ pr_info("Hyper-V: Using IPI hypercalls\n");
/*
* Set the IPI entry points.
*/
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/4] x86/hyper-v: trace PV IPI send
Trace Hyper-V PV IPIs the same way we do PV TLB flush.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/hyperv/hv_apic.c | 4
arch/x86/include/asm/trace/hyperv.h | 15 +++
2 files changed, 19 insertions(+)
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index ee962784d25b..657a2b8c738a 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -31,6 +31,8 @@
#include
#include
+#include
+
static struct apic orig_apic;
static u64 hv_apic_icr_read(void)
@@ -134,6 +136,8 @@ static bool __send_ipi_mask(const struct cpumask *mask, int
vector)
struct ipi_arg_non_ex ipi_arg;
int ret = 1;
+ trace_hyperv_send_ipi_mask(mask, vector);
+
if (cpumask_empty(mask))
return true;
diff --git a/arch/x86/include/asm/trace/hyperv.h
b/arch/x86/include/asm/trace/hyperv.h
index 4253bca99989..9c0d4b588e3f 100644
--- a/arch/x86/include/asm/trace/hyperv.h
+++ b/arch/x86/include/asm/trace/hyperv.h
@@ -28,6 +28,21 @@ TRACE_EVENT(hyperv_mmu_flush_tlb_others,
__entry->addr, __entry->end)
);
+TRACE_EVENT(hyperv_send_ipi_mask,
+ TP_PROTO(const struct cpumask *cpus,
+int vector),
+ TP_ARGS(cpus, vector),
+ TP_STRUCT__entry(
+ __field(unsigned int, ncpus)
+ __field(int, vector)
+ ),
+ TP_fast_assign(__entry->ncpus = cpumask_weight(cpus);
+ __entry->vector = vector;
+ ),
+ TP_printk("ncpus %d vector %x",
+ __entry->ncpus, __entry->vector)
+ );
+
#endif /* CONFIG_HYPERV */
#undef TRACE_INCLUDE_PATH
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/4] x86/hyper-v: optimize PV IPIs
When reviewing my "x86/hyper-v: use cheaper HVCALL_FLUSH_VIRTUAL_ADDRESS_
{LIST,SPACE} hypercalls when possible" patch Michael suggested to apply the
same idea to PV IPIs. Here we go!
Despite what Hyper-V TLFS says about HVCALL_SEND_IPI hypercall, it can
actually be 'fast' (passing parameters through registers). Use that too.
This series can collide with my "KVM: x86: hyperv: PV IPI support for
Windows guests" series as I rename ipi_arg_non_ex/ipi_arg_ex structures
there. Depending on which one gets in first we may need to do tiny
adjustments.
Vitaly Kuznetsov (4):
x86/hyper-v: implement hv_do_fast_hypercall16
x86/hyper-v: use 'fast' hypercall for HVCALL_SEND_IPI
x86/hyper-v: use cheaper HVCALL_SEND_IPI hypercall when possible
x86/hyper-v: trace PV IPI send
arch/x86/hyperv/hv_apic.c | 57 -
arch/x86/include/asm/mshyperv.h | 34 ++
arch/x86/include/asm/trace/hyperv.h | 15 ++
3 files changed, 80 insertions(+), 26 deletions(-)
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[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
---
arch/x86/hyperv/hv_apic.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index f68855499391..90055f89223b 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -128,10 +128,8 @@ static bool __send_ipi_mask_ex(const struct cpumask *mask,
int vector)
static bool __send_ipi_mask(const struct cpumask *mask, int vector)
{
int cur_cpu, vcpu;
- struct ipi_arg_non_ex **arg;
- struct ipi_arg_non_ex *ipi_arg;
+ struct ipi_arg_non_ex ipi_arg;
int ret = 1;
- unsigned long flags;
if (cpumask_empty(mask))
return true;
@@ -145,16 +143,8 @@ static bool __send_ipi_mask(const struct cpumask *mask,
int vector)
if ((ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED))
return __send_ipi_mask_ex(mask, vector);
- local_irq_save(flags);
- arg = (struct ipi_arg_non_ex **)this_cpu_ptr(hyperv_pcpu_input_arg);
-
- ipi_arg = *arg;
- if (unlikely(!ipi_arg))
- goto ipi_mask_done;
-
- ipi_arg->vector = vector;
- ipi_arg->reserved = 0;
- ipi_arg->cpu_mask = 0;
+ ipi_arg.vector = vector;
+ ipi_arg.cpu_mask = 0;
for_each_cpu(cur_cpu, mask) {
vcpu = hv_cpu_number_to_vp_number(cur_cpu);
@@ -165,13 +155,13 @@ static bool __send_ipi_mask(const struct cpumask *mask,
int vector)
if (vcpu >= 64)
goto ipi_mask_done;
- __set_bit(vcpu, (unsigned long *)_arg->cpu_mask);
+ __set_bit(vcpu, (unsigned long *)_arg.cpu_mask);
}
- ret = hv_do_hypercall(HVCALL_SEND_IPI, ipi_arg, NULL);
+ ret = hv_do_fast_hypercall16(HVCALL_SEND_IPI, ipi_arg.vector,
+ipi_arg.cpu_mask);
ipi_mask_done:
- local_irq_restore(flags);
return ((ret == 0) ? true : false);
}
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/4] x86/hyper-v: implement hv_do_fast_hypercall16
Implement 'Fast' hypercall with two 64-bit input parameter. This is
going to be used for HvCallSendSyntheticClusterIpi hypercall.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/mshyperv.h | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
index 3cd14311edfa..da25642940d3 100644
--- a/arch/x86/include/asm/mshyperv.h
+++ b/arch/x86/include/asm/mshyperv.h
@@ -193,6 +193,40 @@ static inline u64 hv_do_fast_hypercall8(u16 code, u64
input1)
return hv_status;
}
+/* Fast hypercall with 16 bytes of input */
+static inline u64 hv_do_fast_hypercall16(u16 code, u64 input1, u64 input2)
+{
+ u64 hv_status, control = (u64)code | HV_HYPERCALL_FAST_BIT;
+
+#ifdef CONFIG_X86_64
+ {
+ __asm__ __volatile__("mov %4, %%r8\n"
+CALL_NOSPEC
+: "=a" (hv_status), ASM_CALL_CONSTRAINT,
+ "+c" (control), "+d" (input1)
+: "r" (input2),
+ THUNK_TARGET(hv_hypercall_pg)
+: "cc", "r8", "r9", "r10", "r11");
+ }
+#else
+ {
+ u32 input1_hi = upper_32_bits(input1);
+ u32 input1_lo = lower_32_bits(input1);
+ u32 input2_hi = upper_32_bits(input2);
+ u32 input2_lo = lower_32_bits(input2);
+
+ __asm__ __volatile__ (CALL_NOSPEC
+ : "=A"(hv_status),
+ "+c"(input1_lo), ASM_CALL_CONSTRAINT
+ : "A" (control), "b" (input1_hi),
+ "D"(input2_hi), "S"(input2_lo),
+ THUNK_TARGET(hv_hypercall_pg)
+ : "cc");
+ }
+#endif
+ return hv_status;
+}
+
/*
* Rep hypercalls. Callers of this functions are supposed to ensure that
* rep_count and varhead_size comply with Hyper-V hypercall definition.
--
2.14.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: wlan-ng: improved readability of function prism2_add_key
Improve readability of prism2_add_key:
a) Reduce nesting and removed goto statement by using more return statements.
Signed-off-by: Chris Opperman
---
drivers/staging/wlan-ng/cfg80211.c | 40 +-
1 file changed, 13 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index 4291225..8320318 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -148,40 +148,26 @@ static int prism2_add_key(struct wiphy *wiphy, struct
net_device *dev,
struct wlandevice *wlandev = dev->ml_priv;
u32 did;
- int err = 0;
- int result = 0;
-
if (key_index >= NUM_WEPKEYS)
return -EINVAL;
- switch (params->cipher) {
- case WLAN_CIPHER_SUITE_WEP40:
- case WLAN_CIPHER_SUITE_WEP104:
- result = prism2_domibset_uint32(wlandev,
-
DIDmib_dot11smt_dot11PrivacyTable_dot11WEPDefaultKeyID,
- key_index);
- if (result)
- goto exit;
-
- /* send key to driver */
- did = DIDmib_dot11smt_dot11WEPDefaultKeysTable_key(key_index +
1);
-
- result = prism2_domibset_pstr32(wlandev, did,
- params->key_len, params->key);
- if (result)
- goto exit;
- break;
-
- default:
+ if (params->cipher != WLAN_CIPHER_SUITE_WEP40 &&
+ params->cipher != WLAN_CIPHER_SUITE_WEP104) {
pr_debug("Unsupported cipher suite\n");
- result = 1;
+ return -EFAULT;
}
-exit:
- if (result)
- err = -EFAULT;
+ if (prism2_domibset_uint32(wlandev,
+
DIDmib_dot11smt_dot11PrivacyTable_dot11WEPDefaultKeyID,
+ key_index))
+ return -EFAULT;
- return err;
+ /* send key to driver */
+ did = DIDmib_dot11smt_dot11WEPDefaultKeysTable_key(key_index + 1);
+
+ if (prism2_domibset_pstr32(wlandev, did, params->key_len, params->key))
+ return -EFAULT;
+ return 0;
}
static int prism2_get_key(struct wiphy *wiphy, struct net_device *dev,
--
2.1.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] drivers/android: use SPDX license information
Are you planning to add this for every source file in the kernel tree? Why this file? On Fri, Jun 22, 2018 at 2:25 AM Mawanda Henry wrote: > > SPDX license helps developers and machines to know the right license > governing a file > > Signed-off-by: Mawanda Henry > --- > drivers/android/binder_alloc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c > index 2628806..84da232 100644 > --- a/drivers/android/binder_alloc.c > +++ b/drivers/android/binder_alloc.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > /* binder_alloc.c > * > * Android IPC Subsystem > -- > 2.7.4 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key
Okay, in that case I will fix and resend the patch. Kind Regards, Chris Opperman ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: rtl8723bs: Fix comment on variable init
Change comment from 'local variable' to 'global variables'
and change style to comply with coding-style.
Signed-off-by: Henriette Hofmeier
Signed-off-by: Florian Harbecke
---
drivers/staging/rtl8723bs/core/rtw_efuse.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c
b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index 9d265f4..c306ad7 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -12,7 +12,7 @@
#include
-/*Define local variable--*/
+/* Define global variables */
u8 fakeEfuseBank;
u32 fakeEfuseUsedBytes;
u8 fakeEfuseContent[EFUSE_MAX_HW_SIZE] = {0};
@@ -28,12 +28,9 @@ u32 fakeBTEfuseUsedBytes;
u8 fakeBTEfuseContent[EFUSE_MAX_BT_BANK][EFUSE_MAX_HW_SIZE];
u8 fakeBTEfuseInitMap[EFUSE_BT_MAX_MAP_LEN] = {0};
u8 fakeBTEfuseModifiedMap[EFUSE_BT_MAX_MAP_LEN] = {0};
-/*Define local variable--*/
-/* */
#define REG_EFUSE_CTRL 0x0030
#define EFUSE_CTRL REG_EFUSE_CTRL /* E-Fuse
Control. */
-/* */
bool
Efuse_Read1ByteFromFakeContent(
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: rtl8723bs: Move definition open brace
Move open braces of definitions to the next line
to comply with codestyle.
Criticized by checkpatch.
Signed-off-by: Henriette Hofmeier
Signed-off-by: Florian Harbecke
---
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index a81e130..0952d15 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -331,7 +331,8 @@ static void init_mlme_ext_priv_value(struct adapter
*padapter)
static int has_channel(RT_CHANNEL_INFO *channel_set,
u8 chanset_size,
- u8 chan) {
+ u8 chan)
+{
int i;
for (i = 0; i < chanset_size; i++) {
@@ -345,7 +346,8 @@ static int has_channel(RT_CHANNEL_INFO *channel_set,
static void init_channel_list(struct adapter *padapter, RT_CHANNEL_INFO
*channel_set,
u8 chanset_size,
- struct p2p_channels
*channel_list) {
+ struct p2p_channels
*channel_list)
+{
struct p2p_oper_class_map op_class[] = {
{ IEEE80211G, 81, 1, 13, 1, BW20 },
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] staging: rtl8723bs: Correct errors reported by checkpatch and comment
Fix errors reported by checkpatch: * move open braces of defintions * remove unnecessary initializations Change comment on local variable definition to comply with coding-style and correct to 'global variables'. Henriette Hofmeier (3): rtl8723bs: Move definition open brace to next line rtl8723bs: Remove unnecessary initializations staging: rtl8723bs: Fix comment on variable init drivers/staging/rtl8723bs/core/rtw_efuse.c| 13 + drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 6 -- 2 files changed, 9 insertions(+), 10 deletions(-) -- 2.7.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: rtl8723bs: Remove unnecessary initializations
Remove initializations of global variables with 0.
Criticized by checkpatch.
Signed-off-by: Henriette Hofmeier
Signed-off-by: Florian Harbecke
---
drivers/staging/rtl8723bs/core/rtw_efuse.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c
b/drivers/staging/rtl8723bs/core/rtw_efuse.c
index bbf6f3f..9d265f4 100644
--- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
+++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
@@ -13,18 +13,18 @@
/*Define local variable--*/
-u8 fakeEfuseBank = 0;
-u32 fakeEfuseUsedBytes = 0;
+u8 fakeEfuseBank;
+u32 fakeEfuseUsedBytes;
u8 fakeEfuseContent[EFUSE_MAX_HW_SIZE] = {0};
u8 fakeEfuseInitMap[EFUSE_MAX_MAP_LEN] = {0};
u8 fakeEfuseModifiedMap[EFUSE_MAX_MAP_LEN] = {0};
-u32 BTEfuseUsedBytes = 0;
+u32 BTEfuseUsedBytes;
u8 BTEfuseContent[EFUSE_MAX_BT_BANK][EFUSE_MAX_HW_SIZE];
u8 BTEfuseInitMap[EFUSE_BT_MAX_MAP_LEN] = {0};
u8 BTEfuseModifiedMap[EFUSE_BT_MAX_MAP_LEN] = {0};
-u32 fakeBTEfuseUsedBytes = 0;
+u32 fakeBTEfuseUsedBytes;
u8 fakeBTEfuseContent[EFUSE_MAX_BT_BANK][EFUSE_MAX_HW_SIZE];
u8 fakeBTEfuseInitMap[EFUSE_BT_MAX_MAP_LEN] = {0};
u8 fakeBTEfuseModifiedMap[EFUSE_BT_MAX_MAP_LEN] = {0};
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix brace coding style issues
On 06/22/18 12:28, Dan Carpenter wrote:
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.
Just for clarification, NULL check refers to checking if buffer != NULL in the
if condition?
if (buffer && !copy_from_user(tmp, buffer, sizeof(tmp)))
~~
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;
regards,
dan carpenter
Regards,
Michael
___
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 06/22/18 12:57, Dan Carpenter wrote:
On Fri, Jun 22, 2018 at 03:54:22AM -0700, Joe Perches wrote:
On Fri, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
Fix checkpatch error 'do not use assignment in if condition'.
[]
diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
index e55895632921..87a4ced41028 100644
--- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
+++ b/
@@ -1181,9 +1181,8 @@ void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
(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))) {
Should also use is_broadcast_ether_addr and is_zero_ether_addr
- if (np &&
- (addr = of_get_property(np, "local-mac-address", )) &&
- len == ETH_ALEN) {
+ addr = of_get_property(np, "local-mac-address", );
+ if (np && addr && len == ETH_ALEN) {
You can remove the "np" check.
if (addr && len == ETH_ALEN) {
It looks more like the rewrite is incorrect
as np is tested before of_get_property
That's what I was worried about too, but if "np" is NULL then
of_get_property() just returns NULL so it's fine.
So it should be this?
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)) &&
(is_broadcast_ether_addr(mac) || is_zero_ether_addr(mac))) {
addr = of_get_property(np, "local-mac-address", );
if (addr && len == ETH_ALEN) {
memcpy(mac_addr, addr, ETH_ALEN);
} else {
mac[0] = 0x00;
...
}
}
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?
Regards,
Michael
___
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?
"Alma Eyre (Sonata Software North America)" writes: > 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://github.com/torvalds/linux/commit/88c9281a9fba67636ab26c1fd6afbc78a632374f) > 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? > > Background: > > The customer is experiencing "tsc: Fast TSC calibration failed" error > on their CentOS 7.4（3.10.0-693.11.6.el7) VM. Hi Alma, I think the following upstream commit would help: commit 71c2a2d0a81f096a2932fccb39a500116fece554 Author: Vitaly Kuznetsov Date: Thu Jun 22 18:07:30 2017 +0800 x86/hyperv: Read TSC frequency from a synthetic MSR > > My research: > > Although I could find information that both of these pages are maintained by > Microsoft, I could not find any information about whether these pages are > subject to name change. > > Regarding both > > Here(https://github.com/torvalds/linux/commit/88c9281a9fba67636ab26c1fd6afbc78a632374f) > it says "On Hyper-V platform there > > are two good clocksources: MSR-based hyperv_clocksource and > > recently introduced TSC page." > > Regarding hyperv_clocksource_tsc_page > > The mechanism is detailed > here(https://opensource.com/article/17/6/timekeeping-linux-vms) but whether > or not this page will ever change names is not noted. It also says "Microsoft > reinvented the pv_clock protocol with their own TSC page proctol, " > > Here(https://lists.linuxfoundation.org/pipermail/virtualization/2017-February/034235.html) > it says that the TSC page is documented, but I cannot find the documentation. > TSC page clocksource is documented in TLFS: https://github.com/Microsoft/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0b.pdf (12.6.2 Format of the Reference TSC Page) But to be honest I didn't get your question. In case you're asking if 'hyperv_clocksource_tsc_page' name is stable than the answer is: there is no guarantee. Nobody will probably change the name just for the sake of change but it can be changed for a reason. -- Vitaly ___ 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, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
> On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
> > Fix checkpatch error 'do not use assignment in if condition'.
[]
> > diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > index e55895632921..87a4ced41028 100644
> > --- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > +++ b/
> > @@ -1181,9 +1181,8 @@ void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
> > (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))) {
Should also use is_broadcast_ether_addr and is_zero_ether_addr
> > - if (np &&
> > - (addr = of_get_property(np, "local-mac-address", )) &&
> > - len == ETH_ALEN) {
> > + addr = of_get_property(np, "local-mac-address", );
> > + if (np && addr && len == ETH_ALEN) {
>
> You can remove the "np" check.
>
> if (addr && len == ETH_ALEN) {
It looks more like the rewrite is incorrect
as np is tested before of_get_property
It could be written something like:
if (is_broadcast_ether_addr(mac) || is_zero_ether_addr(mac)) {
bool assigned = false;
if (np) {
addr = of_get_property(np, "local-mac-address", );
if (len == ETH_ALEN) {
memcpy(mac_addr, addr, ETH_ALEN);
assigned = true;
}
}
if (!assigned) {
mac_addr[0] = 0x00;
mac_addr[1] = ...
}
}
___
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 03:54:22AM -0700, Joe Perches wrote:
> On Fri, 2018-06-22 at 13:40 +0300, Dan Carpenter wrote:
> > On Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
> > > Fix checkpatch error 'do not use assignment in if condition'.
> []
> > > diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > > b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > > index e55895632921..87a4ced41028 100644
> > > --- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> > > +++ b/
> > > @@ -1181,9 +1181,8 @@ void rtw_macaddr_cfg(struct device *dev, u8
> > > *mac_addr)
> > >(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))) {
>
> Should also use is_broadcast_ether_addr and is_zero_ether_addr
>
> > > - if (np &&
> > > - (addr = of_get_property(np, "local-mac-address", )) &&
> > > - len == ETH_ALEN) {
> > > + addr = of_get_property(np, "local-mac-address", );
> > > + if (np && addr && len == ETH_ALEN) {
> >
> > You can remove the "np" check.
> >
> > if (addr && len == ETH_ALEN) {
>
> It looks more like the rewrite is incorrect
> as np is tested before of_get_property
>
That's what I was worried about too, but if "np" is NULL then
of_get_property() just returns NULL so it's fine.
regards,
dan carpenter
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: improved readability of function prism2_add_key
I liked the patch, but just go over the 80 character limit instead of adding a "key" variable. It's better that it generate a checkpatch warning and forces someone to rename the variable... regards, dan carpenter ___ 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 Thu, Jun 21, 2018 at 08:22:30PM +0200, Michael Straube wrote:
> Fix checkpatch error 'do not use assignment in if condition'.
>
> Signed-off-by: Michael Straube
> ---
> drivers/staging/rtl8723bs/core/rtw_ieee80211.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> index e55895632921..87a4ced41028 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_ieee80211.c
> @@ -1181,9 +1181,8 @@ void rtw_macaddr_cfg(struct device *dev, u8 *mac_addr)
>(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", )) &&
> - len == ETH_ALEN) {
> + addr = of_get_property(np, "local-mac-address", );
> + if (np && addr && len == ETH_ALEN) {
You can remove the "np" check.
if (addr && len == ETH_ALEN) {
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: fix brace coding style issues
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;
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] drivers/android: use SPDX license information
SPDX license helps developers and machines to know the right license governing a file Signed-off-by: Mawanda Henry --- drivers/android/binder_alloc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c index 2628806..84da232 100644 --- a/drivers/android/binder_alloc.c +++ b/drivers/android/binder_alloc.c @@ -1,3 +1,4 @@ +// SPDX-License-Identifier: GPL-2.0-or-later /* binder_alloc.c * * Android IPC Subsystem -- 2.7.4 ___ 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?
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://github.com/torvalds/linux/commit/88c9281a9fba67636ab26c1fd6afbc78a632374f) > 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://github.com/torvalds/linux/blob/e7aa8c2eb11ba69b1b69099c3c7bd6be3087b0ba/Documentation/process/stable-api-nonsense.rst ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android/vsoc: stop using 'timespec'
On Mon, Jun 18, 2018 at 5:09 PM, Arnd Bergmann wrote: > The timespec structure suffers from the y2038 overflow and should not > be used. This changes handle_vsoc_cond_wait() to use ktime_t directly. > > Signed-off-by: Arnd Bergmann Reviewed-by: Martijn Coenen Thanks! > --- > drivers/staging/android/vsoc.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c > index 806beda1040b..22571abcaa4e 100644 > --- a/drivers/staging/android/vsoc.c > +++ b/drivers/staging/android/vsoc.c > @@ -405,7 +405,7 @@ static int handle_vsoc_cond_wait(struct file *filp, > struct vsoc_cond_wait *arg) > int ret = 0; > struct vsoc_device_region *region_p = vsoc_region_from_filep(filp); > atomic_t *address = NULL; > - struct timespec ts; > + ktime_t wake_time; > > /* Ensure that the offset is aligned */ > if (arg->offset & (sizeof(uint32_t) - 1)) > @@ -433,14 +433,13 @@ static int handle_vsoc_cond_wait(struct file *filp, > struct vsoc_cond_wait *arg) > * We do things this way to flatten differences between 32 bit > * and 64 bit timespecs. > */ > - ts.tv_sec = arg->wake_time_sec; > - ts.tv_nsec = arg->wake_time_nsec; > - > - if (!timespec_valid()) > + if (arg->wake_time_nsec >= NSEC_PER_SEC) > return -EINVAL; > + wake_time = ktime_set(arg->wake_time_sec, > arg->wake_time_nsec); > + > hrtimer_init_on_stack(>timer, CLOCK_MONOTONIC, > HRTIMER_MODE_ABS); > - hrtimer_set_expires_range_ns(>timer, > timespec_to_ktime(ts), > + hrtimer_set_expires_range_ns(>timer, wake_time, > current->timer_slack_ns); > > hrtimer_init_sleeper(to, current); > -- > 2.9.0 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2 v2] staging: android: ashmem: Fix mmap size validation
On Thu, Jun 21, 2018 at 1:29 AM, Joel Fernandes wrote: > Also if you look at the kernel sources, there are dozens of drivers that > check for correct VMA size in mmap handler and fail if it isn't sized > correctly. If that's the case, we should definitely do it this way for ashmem as well. Since its size is fixed after creation, preventing anyone from mapping a larger size seems reasonable to me. Reviewed-by: Martijn Coenen > > thanks! > > - Joel > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: rf69_set_deviation in rf69.c (pi433 driver)
On Thu, Jun 21, 2018 at 10:03:45PM -0400, Hugo Lefeuvre wrote: > I'll prepare a patch addressing both issues. However I don't own test devices > so it would be really great if you could test it ! I have two pi433 devices now so I should be able to tests things, just let me know... -- Valentin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: pi433: initialization of tx config in pi433_open()
Hi Hugo, thank you for all your work on Pi433 driver. For a better understanding some info about Pi433 and the ideas behind it. Pi433 was developed by me in order to have a simple to mount CE-compliant 433MHz shield for the Raspberry Pi. I wanted to put it on sale on the one side and develop a further product for home automation, using the Pi433. After three years of development and hard trying to find sales partner, I almost gave up, since after three years still earn on those topics by far do not cover the spendings. If nothing changes, I'll have to close my company at the end of this year. At a distinct point, the work on trying to sell exceeded the technical work, so no time was left for the driver development. And now I started over in freelancing to earn money. That's why all of you nearly hear nothing from me - very sad about that! Back to technics: There was already the idea of equipping the driver with default values. I see no benefit with setting the default values from the data sheet, since they do not lead to a good, maybe even not working setup of the rf69. Idea was to choose settings, that allow to use pipeoperators on the command sehll for transmitting and receiving telegrams. There was a longer discussion about one year ago with Marcin Ciupak about that topic. Most important point from my side was, that the defaults should be in a way, that CE recommandations are meat. You can find a lot of configurations, making Pi433 work in a way, that it isn't CE-compliant any more. The 4711 sound like just beeing a place holder. Since - like I told before - I inteded to use Pi433 mainly for OOK/ASK, my idea was to use an good OOK/ASK setup as default. I could provide you with a source code, I used the Pi433 with - but I think attachments are unwanted here. As far as I can remember, there were some more details to modify on the driver, to use it with pipes on command line. But I had a rough implementation. At least send was working... To long ago to remeber :-( Since it might happen, that Pi433 will go off the market in a few monthes (tears in my eyes), I think it's a good idea to modify the driver to become a generic hope-RF driver. I already did investigations on different hope-RF chips and asked hope-RF for a little support (e.g. partnership), but they were of opinion, that they don't need such a driver. It would be easy to cover up to five/six chips of them - even their brand new LoRaWan-chip. RFM-12 will be a little bit harder, since it works a little bit different. There were already preparations to support several chips - e. g. by capsulating the HW layer. But even hard discussions one year ago didn't help - according to kernel guide lines, it wasn't allowed to keep this capsulations. So the strict capsulation was broken and some of the basics for supporting more chips are lost now. Also on this topic I had several discussions with Marcin Ciupak, how to realise the support of the next chips. Maybe you can search the mailing list? If not, I can try to find the discussions in my inbox. I would love to help you with these extending topics, but since I am almost out of money, at the moment there is no margin for complimentary developments any more :-/ But if you like, I can discuss some stuff with you from time to time. Thank you so much for your interest in Pi433 and my driver!! If you need hradware for testing, let me know. Marcus Am 22.06.2018 um 04:47 schrieb Hugo Lefeuvre: > Hi Marcus, > > I'm currently working on the following TODO: > > 966 /* setup instance data*/ > 967 instance->device = device; > 968 instance->tx_cfg.bit_rate = 4711; > 969 // TODO: fill instance->tx_cfg; > > If a user calls write() right after open()-ing an instance, the driver > might try to setup the device with uninitialized garbage. In fact > nothing really bad will happen because the rf69 interface abstraction > will filter out wrong values, but this might be a confusing behavior > for the user. > > What do you think about initializing instance->tx_cfg with the default > values of the rf69 datasheet[0] ? > > Also, is there a specific reason why you chose 4711 as a default value > for the bit rate ? I couldn't find it anywhere in the datasheet nor on > the internet. > > Thanks ! > > Regards, > Hugo > > [0] http://www.hoperf.com/upload/rf/RFM69CW-V1.1.pdf > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
