[PATCH 0/3] staging: wilc1000: code style patches

[Raphaël Beamonte]

Hello,

Please find in following emails code style patches for the driver
wilc1000 in staging.

Raphaël


Raphaël Beamonte (3):
  staging: wilc1000: code style: fix macro with multiple statements
  staging: wilc1000: code style: fix globals initialized to false
  staging: wilc1000: code style: fix open brace { on wrong line

 drivers/staging/wilc1000/host_interface.c |  4 ++--
 drivers/staging/wilc1000/linux_wlan.c |  3 +--
 drivers/staging/wilc1000/wilc_exported_buf.c  | 14 --
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c |  3 +--
 drivers/staging/wilc1000/wilc_wlan.c  |  2 +-
 5 files changed, 13 insertions(+), 13 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] staging: wilc1000: code style: fix macro with multiple statements

[Raphaël Beamonte]

Macros with multiple statements should be enclosed in a do - while loop

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/wilc1000/wilc_exported_buf.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_exported_buf.c 
b/drivers/staging/wilc1000/wilc_exported_buf.c
index 5294578..45c2c7e 100644
--- a/drivers/staging/wilc1000/wilc_exported_buf.c
+++ b/drivers/staging/wilc1000/wilc_exported_buf.c
@@ -12,11 +12,13 @@
void *exported_ ## name = NULL;
 
 #define MALLOC_WILC_BUFFER(name, size) \
-   exported_ ## name = kmalloc(size, GFP_KERNEL);\
-   if (!exported_ ## name) {   \
-   printk("fail to alloc: %s memory\n", exported_ ## name);  \
-   return -ENOBUFS;\
-   }
+   do { \
+   exported_ ## name = kmalloc(size, GFP_KERNEL);\
+   if (!exported_ ## name) {   \
+   printk("fail to alloc: %s memory\n", exported_ ## 
name);  \
+   return -ENOBUFS;\
+   }
+   } while (0)
 
 #define FREE_WILC_BUFFER(name) \
kfree(exported_ ## name);
@@ -73,4 +75,4 @@ MODULE_LICENSE("Dual BSD/GPL");
 MODULE_AUTHOR("Tony Cho");
 MODULE_DESCRIPTION("WILC1xxx Memory Manager");
 pure_initcall(wilc_module_init);
-module_exit(wilc_module_deinit);
\ No newline at end of file
+module_exit(wilc_module_deinit);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] staging: wilc1000: code style: fix open brace { on wrong line

[Raphaël Beamonte]

Open braces should be on the same line as if and for statements.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/wilc1000/linux_wlan.c | 3 +--
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 7eacc2f..040e55d 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -2103,8 +2103,7 @@ static void wilc_set_multicast_list(struct net_device 
*dev)
}
 
/* Store all of the multicast addresses in the hardware filter */
-   netdev_for_each_mc_addr(ha, dev)
-   {
+   netdev_for_each_mc_addr(ha, dev) {
memcpy(gau8MulticastMacAddrList[i], ha->addr, ETH_ALEN);
PRINT_D(INIT_DBG, "Entry[%d]: %x:%x:%x:%x:%x:%x\n", i,
gau8MulticastMacAddrList[i][0], 
gau8MulticastMacAddrList[i][1], gau8MulticastMacAddrList[i][2], 
gau8MulticastMacAddrList[i][3], gau8MulticastMacAddrList[i][4], 
gau8MulticastMacAddrList[i][5]);
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index c2f8d60..29f43d6 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1527,8 +1527,7 @@ static int WILC_WFI_get_key(struct wiphy *wiphy, struct 
net_device *netdev, u8 k
priv = wiphy_priv(wiphy);
 
 
-   if (!pairwise)
-   {
+   if (!pairwise) {
PRINT_D(CFG80211_DBG, "Getting group key idx: %x\n", key_index);
 
key_params.key = priv->wilc_gtk[key_index]->key;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 08/16] x86/efi: Carrying hibernation key by setup data

[joeyli]

On Sat, Aug 15, 2015 at 07:07:38PM +0200, Pavel Machek wrote:
> On Tue 2015-08-11 14:16:28, Lee, Chun-Yi wrote:
> > For forwarding hibernation key from EFI stub to boot kernel, this patch
> > allocates setup data for carrying hibernation key, size and the status
> > of efi operating.
> > 
> > Reviewed-by: Jiri Kosina 
> 
> Jiri, are you sure you reviewed these? This is not really
> english, afaict, and efi/EFI should be spelled consistently.
> 
> Could you try reviewing it again? Pointing out 10s of small
> bugs is quite boring...
>

It's my fault, I will find someone help to review my English in all
patch description for next edition.
 
> > unsigned long key_size;
> > unsigned long attributes;
> > +   struct setup_data *setup_data, *hibernation_setup_data;
> > struct hibernation_keys *keys;
> > +   unsigned long size = 0;
> > efi_status_t status;
> >  
> > /* Allocate setup_data to carry keys */
> > +   size = sizeof(struct setup_data) + sizeof(struct hibernation_keys);
> > status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
> > -   sizeof(struct hibernation_keys), );
> > +   size, _setup_data);
> > if (status != EFI_SUCCESS) {
> > efi_printk(sys_table, "Failed to alloc mem for hibernation 
> > keys\n");
> > return;
> > }
> >  
> > -   memset(keys, 0, sizeof(struct hibernation_keys));
> > +   memset(hibernation_setup_data, 0, size);
> > +   keys = (struct hibernation_keys *) hibernation_setup_data->data;
> >  
> 
> any chance to type stuff correctly so that casts are not
> neccessary?
> 

The data element defined in setup_data struct as u8:
__u8 data[0];

So I use cast here.

> > +clean_fail:
> > +   hibernation_setup_data->type = SETUP_HIBERNATION_KEYS;
> > +   hibernation_setup_data->len = sizeof(struct hibernation_keys);
> > +   hibernation_setup_data->next = 0;
> > +   keys->hkey_status = efi_status_to_err(status);
> > +
> > +   setup_data = (struct setup_data *)params->hdr.setup_data;
> > +   while (setup_data && setup_data->next)
> > +   setup_data = (struct setup_data *)setup_data->next;
> 
> way too many casts here.
> 
>   Pavel

I follow setup_efi_pci32() and setup_efi_pci64():

while (data && data->next)
data = (struct setup_data *)(unsigned long)data->next;

That's better I also add (unsigned long) cast as setup_efi_pci. Do
you have good suggestion let the above code more graceful?


Thanks a lot!
Joey Lee

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] staging: wilc1000: code style: fix globals initialized to false

[Raphaël Beamonte]

Globals should not be initialized to 0 or NULL.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/wilc1000/host_interface.c | 4 ++--
 drivers/staging/wilc1000/wilc_wlan.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index bab5319..53c4ca9 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -536,7 +536,7 @@ typedef enum {
 tstrWILC_WFIDrv *terminated_handle;
 tstrWILC_WFIDrv *gWFiDrvHandle;
 #ifdef DISABLE_PWRSAVE_AND_SCAN_DURING_IP
-bool g_obtainingIP = false;
+bool g_obtainingIP;
 #endif
 u8 P2P_LISTEN_STATE;
 static struct task_struct *HostIFthreadHandler;
@@ -558,7 +558,7 @@ static u8 
gapu8RcvdSurveyResults[2][MAX_SURVEY_RESULT_FRAG_SIZE];
 
 static u8 gapu8RcvdAssocResp[MAX_ASSOC_RESP_FRAME_SIZE];
 
-bool gbScanWhileConnected = false;
+bool gbScanWhileConnected;
 
 static s8 gs8Rssi;
 static s8 gs8lnkspd;
diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index fac16db..4c40955 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -482,7 +482,7 @@ static int wilc_wlan_txq_filter_dup_tcp_ack(void)
 #endif
 
 #ifdef TCP_ENHANCEMENTS
-bool EnableTCPAckFilter = false;
+bool EnableTCPAckFilter;
 
 void Enable_TCP_ACK_Filter(bool value)
 {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: recent updates to networking (26b552e0a85ba7e74d384a9624d83118d38071f7) cause softlocks

[Cong Wang]

(CC'ing netdev)

On Sat, Aug 15, 2015 at 7:20 PM, Jon Christopherson  wrote:
> Hello All,
>
> the recent commit (26b552e0a85ba7e74d384a9624d83118d38071f7) causes
> softlocks on my system using the e1000e driver. Kernel builds before this
> commit do not experience the behavior. I have opened a bug report here:
> https://bugzilla.kernel.org/show_bug.cgi?id=102911 with more details.
>

The commit you refer is a merge commit...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 40/46] sched/cpufreq_sched: compute freq_new based on capacity_orig_of()

[Michael Turquette]

Quoting Peter Zijlstra (2015-08-15 05:46:38)
> On Tue, Jul 07, 2015 at 07:24:23PM +0100, Morten Rasmussen wrote:
> > diff --git a/kernel/sched/cpufreq_sched.c b/kernel/sched/cpufreq_sched.c
> > index 2968f3a..7071528 100644
> > --- a/kernel/sched/cpufreq_sched.c
> > +++ b/kernel/sched/cpufreq_sched.c
> > @@ -184,7 +184,7 @@ void cpufreq_sched_set_cap(int cpu, unsigned long 
> > capacity)
> >   goto out;
> >  
> >   /* Convert the new maximum capacity request into a cpu frequency */
> > - freq_new = capacity * policy->max >> SCHED_CAPACITY_SHIFT;
> > + freq_new = (capacity * policy->max) / capacity_orig_of(cpu);
> >  
> >   /* No change in frequency? Bail and return current capacity. */
> >   if (freq_new == policy->cur)
> 
> Can't we avoid exporting that lot by simply passing in the right values
> to begin with?

By "right value" do you mean, "pass the frequency from cfs"?

If that is what you mean, then the answer is "yes". But it also means
that cfs will need access to either:

1) the cpu frequncy-domain topology described in struct cpufreq.cpus
OR
2) duplicate that frequency-domain knowledge, perhaps in sched_domain

If that isn't what you mean by "right value" then let me know.

Regards,
Mike

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 41/46] sched/fair: add triggers for OPP change requests

[Michael Turquette]

Quoting Peter Zijlstra (2015-08-15 05:48:17)
> 
> 
> So this OPP thing, I think that got mentioned once earlier in this patch
> set, wth is that?

OPP == OPerating Point == P-state

In System-on-chip Land OPP is a very common term, roughly defined as a
frequency & voltage pair that makes up a performance state.

In other words, OPP is the P-state of the non-ACPI world.

Similarly DVFS is sometimes confused as a brand new file system, but it
is also a very standardized acronym amongst SoC vendors meaning
frequency and voltage scaling.

Regards,
Mike

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/7] tools/power turbostat: fix typo on DRAM column in Joules-mode

[Len Brown]

From: Len Brown 

< RAM_W
> RAM_J

Reported-by: Hubert Chrzaniuk 
Signed-off-by: Len Brown 
---
 tools/power/x86/turbostat/turbostat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 915eb28..9655cb4 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -372,7 +372,7 @@ void print_header(void)
if (do_rapl & RAPL_GFX)
outp += sprintf(outp, "   GFX_J");
if (do_rapl & RAPL_DRAM)
-   outp += sprintf(outp, "   RAM_W");
+   outp += sprintf(outp, "   RAM_J");
if (do_rapl & RAPL_PKG_PERF_STATUS)
outp += sprintf(outp, "   PKG_%%");
if (do_rapl & RAPL_DRAM_PERF_STATUS)
-- 
2.5.0.330.g130be8e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/7] tools/power turbostat: cpu0 is no longer hard-coded, so update output

[Len Brown]

From: Len Brown 

The --debug option reads a number of per-package MSRs.
Previously we explicitly read them on cpu0, but recently
turbostat changed to read them on the current "base_cpu".

Update the print-out to reflect base_cpu, rather than
the hard-coded cpu0.

Signed-off-by: Len Brown 
---
 tools/power/x86/turbostat/turbostat.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 323b65e..67162ec 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1157,7 +1157,7 @@ dump_nhm_platform_info(void)
 
get_msr(base_cpu, MSR_NHM_PLATFORM_INFO, );
 
-   fprintf(stderr, "cpu0: MSR_NHM_PLATFORM_INFO: 0x%08llx\n", msr);
+   fprintf(stderr, "cpu%d: MSR_NHM_PLATFORM_INFO: 0x%08llx\n", base_cpu, 
msr);
 
ratio = (msr >> 40) & 0xFF;
fprintf(stderr, "%d * %.0f = %.0f MHz max efficiency frequency\n",
@@ -1168,8 +1168,8 @@ dump_nhm_platform_info(void)
ratio, bclk, ratio * bclk);
 
get_msr(base_cpu, MSR_IA32_POWER_CTL, );
-   fprintf(stderr, "cpu0: MSR_IA32_POWER_CTL: 0x%08llx (C1E 
auto-promotion: %sabled)\n",
-   msr, msr & 0x2 ? "EN" : "DIS");
+   fprintf(stderr, "cpu%d: MSR_IA32_POWER_CTL: 0x%08llx (C1E 
auto-promotion: %sabled)\n",
+   base_cpu, msr, msr & 0x2 ? "EN" : "DIS");
 
return;
 }
@@ -1182,7 +1182,7 @@ dump_hsw_turbo_ratio_limits(void)
 
get_msr(base_cpu, MSR_TURBO_RATIO_LIMIT2, );
 
-   fprintf(stderr, "cpu0: MSR_TURBO_RATIO_LIMIT2: 0x%08llx\n", msr);
+   fprintf(stderr, "cpu%d: MSR_TURBO_RATIO_LIMIT2: 0x%08llx\n", base_cpu, 
msr);
 
ratio = (msr >> 8) & 0xFF;
if (ratio)
@@ -1204,7 +1204,7 @@ dump_ivt_turbo_ratio_limits(void)
 
get_msr(base_cpu, MSR_TURBO_RATIO_LIMIT1, );
 
-   fprintf(stderr, "cpu0: MSR_TURBO_RATIO_LIMIT1: 0x%08llx\n", msr);
+   fprintf(stderr, "cpu%d: MSR_TURBO_RATIO_LIMIT1: 0x%08llx\n", base_cpu, 
msr);
 
ratio = (msr >> 56) & 0xFF;
if (ratio)
@@ -1256,7 +1256,7 @@ dump_nhm_turbo_ratio_limits(void)
 
get_msr(base_cpu, MSR_TURBO_RATIO_LIMIT, );
 
-   fprintf(stderr, "cpu0: MSR_TURBO_RATIO_LIMIT: 0x%08llx\n", msr);
+   fprintf(stderr, "cpu%d: MSR_TURBO_RATIO_LIMIT: 0x%08llx\n", base_cpu, 
msr);
 
ratio = (msr >> 56) & 0xFF;
if (ratio)
@@ -1312,8 +1312,8 @@ dump_knl_turbo_ratio_limits(void)
 
get_msr(base_cpu, MSR_NHM_TURBO_RATIO_LIMIT, );
 
-   fprintf(stderr, "cpu0: MSR_NHM_TURBO_RATIO_LIMIT: 0x%08llx\n",
-   msr);
+   fprintf(stderr, "cpu%d: MSR_NHM_TURBO_RATIO_LIMIT: 0x%08llx\n",
+   base_cpu, msr);
 
/**
 * Turbo encoding in KNL is as follows:
@@ -1371,7 +1371,7 @@ dump_nhm_cst_cfg(void)
 #define SNB_C1_AUTO_UNDEMOTE  (1UL << 27)
 #define SNB_C3_AUTO_UNDEMOTE  (1UL << 28)
 
-   fprintf(stderr, "cpu0: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x%08llx", msr);
+   fprintf(stderr, "cpu%d: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x%08llx", 
base_cpu, msr);
 
fprintf(stderr, " (%s%s%s%s%slocked: pkg-cstate-limit=%d: %s)\n",
(msr & SNB_C3_AUTO_UNDEMOTE) ? "UNdemote-C3, " : "",
-- 
2.5.0.330.g130be8e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/7] tools/power turbostat: dump CONFIG_TDP

[Len Brown]

From: Len Brown 

Config TDP is a feature that allows parts to be configured
for different thermal limits after they have left the factory.

This can have an effect on the operation of the part,
particularly in determiniing...

Max Non-turbo Ratio
Turbo Activation Ratio

Signed-off-by: Len Brown 
---
 arch/x86/include/uapi/asm/msr-index.h |  6 +++
 tools/power/x86/turbostat/turbostat.c | 78 ++-
 2 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/uapi/asm/msr-index.h 
b/arch/x86/include/uapi/asm/msr-index.h
index 3c6bb34..872b592 100644
--- a/arch/x86/include/uapi/asm/msr-index.h
+++ b/arch/x86/include/uapi/asm/msr-index.h
@@ -169,6 +169,12 @@
 #define MSR_PP1_ENERGY_STATUS  0x0641
 #define MSR_PP1_POLICY 0x0642
 
+#define MSR_CONFIG_TDP_NOMINAL 0x0648
+#define MSR_CONFIG_TDP_LEVEL_1 0x0649
+#define MSR_CONFIG_TDP_LEVEL_2 0x064A
+#define MSR_CONFIG_TDP_CONTROL 0x064B
+#define MSR_TURBO_ACTIVATION_RATIO 0x064C
+
 #define MSR_PKG_WEIGHTED_CORE_C0_RES   0x0658
 #define MSR_PKG_ANY_CORE_C0_RES0x0659
 #define MSR_PKG_ANY_GFXE_C0_RES0x065A
diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 67162ec..5a793be 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -1384,6 +1384,49 @@ dump_nhm_cst_cfg(void)
return;
 }
 
+static void
+dump_config_tdp(void)
+{
+   unsigned long long msr;
+
+   get_msr(base_cpu, MSR_CONFIG_TDP_NOMINAL, );
+   fprintf(stderr, "cpu%d: MSR_CONFIG_TDP_NOMINAL: 0x%08llx", base_cpu, 
msr);
+   fprintf(stderr, " (base_ratio=%d)\n", (unsigned int)msr & 0xEF);
+
+   get_msr(base_cpu, MSR_CONFIG_TDP_LEVEL_1, );
+   fprintf(stderr, "cpu%d: MSR_CONFIG_TDP_LEVEL_1: 0x%08llx (", base_cpu, 
msr);
+   if (msr) {
+   fprintf(stderr, "PKG_MIN_PWR_LVL1=%d ", (unsigned int)(msr >> 
48) & 0xEFFF);
+   fprintf(stderr, "PKG_MAX_PWR_LVL1=%d ", (unsigned int)(msr >> 
32) & 0xEFFF);
+   fprintf(stderr, "LVL1_RATIO=%d ", (unsigned int)(msr >> 16) & 
0xEF);
+   fprintf(stderr, "PKG_TDP_LVL1=%d", (unsigned int)(msr) & 
0xEFFF);
+   }
+   fprintf(stderr, ")\n");
+
+   get_msr(base_cpu, MSR_CONFIG_TDP_LEVEL_2, );
+   fprintf(stderr, "cpu%d: MSR_CONFIG_TDP_LEVEL_2: 0x%08llx (", base_cpu, 
msr);
+   if (msr) {
+   fprintf(stderr, "PKG_MIN_PWR_LVL2=%d ", (unsigned int)(msr >> 
48) & 0xEFFF);
+   fprintf(stderr, "PKG_MAX_PWR_LVL2=%d ", (unsigned int)(msr >> 
32) & 0xEFFF);
+   fprintf(stderr, "LVL2_RATIO=%d ", (unsigned int)(msr >> 16) & 
0xEF);
+   fprintf(stderr, "PKG_TDP_LVL2=%d", (unsigned int)(msr) & 
0xEFFF);
+   }
+   fprintf(stderr, ")\n");
+
+   get_msr(base_cpu, MSR_CONFIG_TDP_CONTROL, );
+   fprintf(stderr, "cpu%d: MSR_CONFIG_TDP_CONTROL: 0x%08llx (", base_cpu, 
msr);
+   if ((msr) & 0x3)
+   fprintf(stderr, "TDP_LEVEL=%d ", (unsigned int)(msr) & 0x3);
+   fprintf(stderr, " lock=%d", (unsigned int)(msr >> 31) & 1);
+   fprintf(stderr, ")\n");
+   
+   get_msr(base_cpu, MSR_TURBO_ACTIVATION_RATIO, );
+   fprintf(stderr, "cpu%d: MSR_TURBO_ACTIVATION_RATIO: 0x%08llx (", 
base_cpu, msr);
+   fprintf(stderr, "MAX_NON_TURBO_RATIO=%d", (unsigned int)(msr) & 0xEF);
+   fprintf(stderr, " lock=%d", (unsigned int)(msr >> 31) & 1);
+   fprintf(stderr, ")\n");
+}
+
 void free_all_buffers(void)
 {
CPU_FREE(cpu_present_set);
@@ -1873,6 +1916,36 @@ int has_knl_turbo_ratio_limit(unsigned int family, 
unsigned int model)
return 0;
}
 }
+int has_config_tdp(unsigned int family, unsigned int model)
+{
+   if (!genuine_intel)
+   return 0;
+
+   if (family != 6)
+   return 0;
+
+   switch (model) {
+   case 0x3A:  /* IVB */
+   case 0x3E:  /* IVB Xeon */
+
+   case 0x3C:  /* HSW */
+   case 0x3F:  /* HSX */
+   case 0x45:  /* HSW */
+   case 0x46:  /* HSW */
+   case 0x3D:  /* BDW */
+   case 0x47:  /* BDW */
+   case 0x4F:  /* BDX */
+   case 0x56:  /* BDX-DE */
+   case 0x4E:  /* SKL */
+   case 0x5E:  /* SKL */
+
+   case 0x57:  /* Knights Landing */
+   return 1;
+   default:
+   return 0;
+   }
+}
+
 static void
 dump_cstate_pstate_config_info(family, model)
 {
@@ -1893,6 +1966,9 @@ dump_cstate_pstate_config_info(family, model)
if (has_knl_turbo_ratio_limit(family, model))
dump_knl_turbo_ratio_limits();
 
+   if (has_config_tdp(family, model))
+   dump_config_tdp();
+
dump_nhm_cst_cfg();
 }
 
@@ -3014,7 +3090,7 @@ int get_and_dump_counters(void)
 }
 
 void print_version() {
-   

[PATCH 6/7] intel_idle: allow idle states to be freeze-mode specific

[Len Brown]

From: Len Brown 

intel_idle uses a NULL "enter" field in a cpuidle state
to recognize the invalid entry terminating a variable-length array.

Linux-4.0 added support for the system-wide "freeze" state
in cpuidle drivers via the new "enter_freeze" field.

The natural way to expose a deep idle state for freeze,
but not for run-time idle is to supply "enter_freeze" without "enter";
so we update the driver to accept such states.

Signed-off-by: Len Brown 
---
 drivers/idle/intel_idle.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 2a36a95..008e943 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -965,7 +965,8 @@ static int __init intel_idle_cpuidle_driver_init(void)
for (cstate = 0; cstate < CPUIDLE_STATE_MAX; ++cstate) {
int num_substates, mwait_hint, mwait_cstate;
 
-   if (cpuidle_state_table[cstate].enter == NULL)
+   if ((cpuidle_state_table[cstate].enter == NULL) &&
+   (cpuidle_state_table[cstate].enter_freeze == NULL))
break;
 
if (cstate + 1 > max_cstate) {
-- 
2.5.0.330.g130be8e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/7] tools/power turbostat: fix parameter passing for forked command

[Len Brown]

From: Len Brown 

turbostat supports forked command when sampling cpu state. However,
the forked command is not allowed to be executed with options, otherwise
turbostat might regard these options as invalid turbostat options.

For example:

./turbostat stress -c 4 -t 10
./turbostat: unrecognized option '-t'

Reported-by: Chen Yu 
Signed-off-by: Len Brown 
---
 tools/power/x86/turbostat/turbostat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/power/x86/turbostat/turbostat.c 
b/tools/power/x86/turbostat/turbostat.c
index 5a793be..915eb28 100644
--- a/tools/power/x86/turbostat/turbostat.c
+++ b/tools/power/x86/turbostat/turbostat.c
@@ -3118,7 +3118,7 @@ void cmdline(int argc, char **argv)
 
progname = argv[0];
 
-   while ((opt = getopt_long_only(argc, argv, "C:c:Ddhi:JM:m:PpST:v",
+   while ((opt = getopt_long_only(argc, argv, "+C:c:Ddhi:JM:m:PpST:v",
long_options, _index)) != -1) {
switch (opt) {
case 'C':
-- 
2.5.0.330.g130be8e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/7] intel_idle: Skylake Client Support

[Len Brown]

From: Len Brown 

Skylake Client CPU idle Power states (C-states)
are similar to the previous generation, Broadwell.
However, Skylake does get its own table with updated
worst-case latency and average energy-break-even residency values.

Signed-off-by: Len Brown 
---
 drivers/idle/intel_idle.c | 69 +++
 1 file changed, 69 insertions(+)

diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index 008e943..3a3738f 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -591,6 +591,67 @@ static struct cpuidle_state bdw_cstates[] = {
.enter = NULL }
 };
 
+static struct cpuidle_state skl_cstates[] = {
+   {
+   .name = "C1-SKL",
+   .desc = "MWAIT 0x00",
+   .flags = MWAIT2flg(0x00),
+   .exit_latency = 2,
+   .target_residency = 2,
+   .enter = _idle,
+   .enter_freeze = intel_idle_freeze, },
+   {
+   .name = "C1E-SKL",
+   .desc = "MWAIT 0x01",
+   .flags = MWAIT2flg(0x01),
+   .exit_latency = 10,
+   .target_residency = 20,
+   .enter = _idle,
+   .enter_freeze = intel_idle_freeze, },
+   {
+   .name = "C3-SKL",
+   .desc = "MWAIT 0x10",
+   .flags = MWAIT2flg(0x10) | CPUIDLE_FLAG_TLB_FLUSHED,
+   .exit_latency = 70,
+   .target_residency = 100,
+   .enter = _idle,
+   .enter_freeze = intel_idle_freeze, },
+   {
+   .name = "C6-SKL",
+   .desc = "MWAIT 0x20",
+   .flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
+   .exit_latency = 75,
+   .target_residency = 200,
+   .enter = _idle,
+   .enter_freeze = intel_idle_freeze, },
+   {
+   .name = "C7s-SKL",
+   .desc = "MWAIT 0x33",
+   .flags = MWAIT2flg(0x33) | CPUIDLE_FLAG_TLB_FLUSHED,
+   .exit_latency = 124,
+   .target_residency = 800,
+   .enter = _idle,
+   .enter_freeze = intel_idle_freeze, },
+   {
+   .name = "C8-SKL",
+   .desc = "MWAIT 0x40",
+   .flags = MWAIT2flg(0x40) | CPUIDLE_FLAG_TLB_FLUSHED,
+   .exit_latency = 174,
+   .target_residency = 800,
+   .enter = _idle,
+   .enter_freeze = intel_idle_freeze, },
+   {
+   .name = "C10-SKL",
+   .desc = "MWAIT 0x60",
+   .flags = MWAIT2flg(0x60) | CPUIDLE_FLAG_TLB_FLUSHED,
+   .exit_latency = 890,
+   .target_residency = 5000,
+   .enter = _idle,
+   .enter_freeze = intel_idle_freeze, },
+   {
+   .enter = NULL }
+};
+
 static struct cpuidle_state atom_cstates[] = {
{
.name = "C1E-ATM",
@@ -810,6 +871,12 @@ static const struct idle_cpu idle_cpu_bdw = {
.disable_promotion_to_c1e = true,
 };
 
+static const struct idle_cpu idle_cpu_skl = {
+   .state_table = skl_cstates,
+   .disable_promotion_to_c1e = true,
+};
+
+
 static const struct idle_cpu idle_cpu_avn = {
.state_table = avn_cstates,
.disable_promotion_to_c1e = true,
@@ -844,6 +911,8 @@ static const struct x86_cpu_id intel_idle_ids[] __initconst 
= {
ICPU(0x47, idle_cpu_bdw),
ICPU(0x4f, idle_cpu_bdw),
ICPU(0x56, idle_cpu_bdw),
+   ICPU(0x4e, idle_cpu_skl),
+   ICPU(0x5e, idle_cpu_skl),
{}
 };
 MODULE_DEVICE_TABLE(x86cpu, intel_idle_ids);
-- 
2.5.0.330.g130be8e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

intel_idle, turbostat patches queued for upstream

[Len Brown]

Here are some intel_idle and turbostat patches queued for upstream.
Please let me know if you see troubles with any of them.

Rafael,
They are on my "cpuidle" and "turbostat" branches, if you prefer
to pull them directly from there.

thanks,
Len Brown, Intel Open Source Technology Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/7] tools/power turbostat: update turbostat(8)

[Len Brown]

From: Len Brown 

Remove reference to the original Nehalem Turbo white paper,
since it has moved, and these mechanisms have now long since
been documented in the Software Developer's Manual.

Reported-by: Jeremie Lagraviere 
Signed-off-by: Len Brown 
---
 tools/power/x86/turbostat/turbostat.8 | 5 -
 1 file changed, 5 deletions(-)

diff --git a/tools/power/x86/turbostat/turbostat.8 
b/tools/power/x86/turbostat/turbostat.8
index 05b8fc3..622db68 100644
--- a/tools/power/x86/turbostat/turbostat.8
+++ b/tools/power/x86/turbostat/turbostat.8
@@ -251,11 +251,6 @@ Although it is not guaranteed by the architecture, 
turbostat assumes
 that they count at TSC rate, which is true on all processors tested to date.
 
 .SH REFERENCES
-"Intel® Turbo Boost Technology
-in Intel® Core™ Microarchitecture (Nehalem) Based Processors"
-http://download.intel.com/design/processor/applnots/320354.pdf
-
-"Intel® 64 and IA-32 Architectures Software Developer's Manual
 Volume 3B: System Programming Guide"
 http://www.intel.com/products/processor/manuals/
 
-- 
2.5.0.330.g130be8e

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RFC] eeprom: at24: extend driver to plug into the NVMEM framework

[Andrew Lunn]

Add a read only regmap for accessing the EEPROM, and then use that
with the NVMEM framework.

Signed-off-by: Andrew Lunn 
---
 drivers/misc/eeprom/at24.c | 65 ++
 1 file changed, 65 insertions(+)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 2d3db81be099..0e80c0c09d4e 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 /*
@@ -69,6 +71,10 @@ struct at24_data {
unsigned write_max;
unsigned num_addresses;
 
+   struct regmap_config regmap_config;
+   struct nvmem_config nvmem_config;
+   struct nvmem_device *nvmem;
+
/*
 * Some chips tie up multiple I2C addresses; dummy devices reserve
 * them for us, and we'll use them with SMBus calls.
@@ -471,6 +477,34 @@ static ssize_t at24_macc_write(struct memory_accessor 
*macc, const char *buf,
 
 /*-*/
 
+/*
+ * Provide a regmap interface, which is registered with the NVMEM
+ * framework
+*/
+static int at24_regmap_read(void *context, const void *reg, size_t reg_size,
+   void *val, size_t val_size)
+{
+   struct at24_data *at24 = context;
+   off_t offset = *(u32 *)reg;
+
+   return at24_read(at24, val, offset, val_size);
+}
+
+static int at24_regmap_write(void *context, const void *data, size_t count)
+{
+   struct at24_data *at24 = context;
+
+   return at24_write(at24, data, 0, count);
+}
+
+static const struct regmap_bus at24_regmap_bus = {
+   .read = at24_regmap_read,
+   .write = at24_regmap_write,
+   .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
+};
+
+/*-*/
+
 #ifdef CONFIG_OF
 static void at24_get_ofdata(struct i2c_client *client,
struct at24_platform_data *chip)
@@ -502,6 +536,7 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
int err;
unsigned i, num_addresses;
kernel_ulong_t magic;
+   struct regmap *regmap;
 
if (client->dev.platform_data) {
chip = *(struct at24_platform_data *)client->dev.platform_data;
@@ -644,6 +679,30 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
if (err)
goto err_clients;
 
+   at24->regmap_config.reg_bits = 32;
+   at24->regmap_config.val_bits = 8;
+   at24->regmap_config.reg_stride = 1;
+   at24->regmap_config.max_register = at24->bin.size - 1;
+
+   regmap = devm_regmap_init(>dev, _regmap_bus, at24,
+ >regmap_config);
+   if (IS_ERR(regmap)) {
+   dev_err(>dev, "regmap init failed\n");
+   err = PTR_ERR(regmap);
+   goto err_sysfs;
+   }
+
+   at24->nvmem_config.name = dev_name(>dev);
+   at24->nvmem_config.dev = >dev;
+   at24->nvmem_config.read_only = !writable;
+   at24->nvmem_config.owner = THIS_MODULE;
+
+   at24->nvmem = nvmem_register(>nvmem_config);
+   if (IS_ERR(at24->nvmem)) {
+   err = PTR_ERR(at24->nvmem);
+   goto err_sysfs;
+   }
+
i2c_set_clientdata(client, at24);
 
dev_info(>dev, "%zu byte %s EEPROM, %s, %u bytes/write\n",
@@ -662,6 +721,9 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
return 0;
 
+err_sysfs:
+   sysfs_remove_bin_file(>dev.kobj, >bin);
+
 err_clients:
for (i = 1; i < num_addresses; i++)
if (at24->client[i])
@@ -676,6 +738,9 @@ static int at24_remove(struct i2c_client *client)
int i;
 
at24 = i2c_get_clientdata(client);
+
+   nvmem_unregister(at24->nvmem);
+
sysfs_remove_bin_file(>dev.kobj, >bin);
 
for (i = 1; i < at24->num_addresses; i++)
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

recent updates to networking (26b552e0a85ba7e74d384a9624d83118d38071f7) cause softlocks

[Jon Christopherson]

Hello All,

the recent commit (26b552e0a85ba7e74d384a9624d83118d38071f7) causes 
softlocks on my system using the e1000e driver. Kernel builds before 
this commit do not experience the behavior. I have opened a bug report 
here: https://bugzilla.kernel.org/show_bug.cgi?id=102911 with more details.


Thanks,

Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 04/20] staging: rtl8192u: r8192U_core: fix code indent using spaces code style error

[Raphaël Beamonte]

Fix code indent should use tabs where possible code style error

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 1eaaa7a..fe92021 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1542,7 +1542,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
tx_fwinfo->RtsSubcarrier = (tx_fwinfo->RtsHT == 0) ? (tcb_desc->RTSSC) 
: 0;
tx_fwinfo->RtsBandwidth = (tx_fwinfo->RtsHT == 1) ? ((tcb_desc->bRTSBW) 
? 1 : 0) : 0;
tx_fwinfo->RtsShort = (tx_fwinfo->RtsHT == 0) ? 
(tcb_desc->bRTSUseShortPreamble ? 1 : 0) :
- (tcb_desc->bRTSUseShortGI ? 1 : 0);
+ (tcb_desc->bRTSUseShortGI ? 1 : 0);
 
/* Set Bandwidth and sub-channel settings. */
if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20_40) {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 13/20] staging: rtl8192u: r8192U_core: fix unnecessary check before kfree code style issue

[Raphaël Beamonte]

kfree(NULL) is safe and the checks were not required.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 849fd3d..99d7f7c 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1724,10 +1724,9 @@ static void rtl8192_usb_deleteendpoints(struct 
net_device *dev)
}
kfree(priv->oldaddr);
priv->oldaddr = NULL;
-   if (priv->pp_rxskb) {
-   kfree(priv->pp_rxskb);
-   priv->pp_rxskb = NULL;
-   }
+
+   kfree(priv->pp_rxskb);
+   priv->pp_rxskb = NULL;
 }
 #else
 void rtl8192_usb_deleteendpoints(struct net_device *dev)
@@ -1752,11 +1751,9 @@ void rtl8192_usb_deleteendpoints(struct net_device *dev)
priv->rx_urb = NULL;
kfree(priv->oldaddr);
priv->oldaddr = NULL;
-   if (priv->pp_rxskb) {
-   kfree(priv->pp_rxskb);
-   priv->pp_rxskb = 0;
 
-   }
+   kfree(priv->pp_rxskb);
+   priv->pp_rxskb = 0;
 
 #endif
 }
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 02/20] staging: rtl8192u: r8192U_core: fix consistent spacing code style error

[Raphaël Beamonte]

Fix multiple occurences of the need consistent spacing code style error

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 915493d..c4ab2a8 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2182,8 +2182,8 @@ static void rtl8192_init_priv_variable(struct net_device 
*dev)
priv->EarlyRxThreshold = 7;
priv->enable_gpio0 = 0;
priv->TransmitConfig =
-   (TCR_MXDMA_2048>1);
priv->eeprom_ChannelPlan = (tmpValue & 0xff00)>>8;
priv->btxpowerdata_readfromEEPORM = true;
-   priv->eeprom_CustomerID = eprom_read(dev, 
(EEPROM_Customer_ID>>1)) >>8;
+   priv->eeprom_CustomerID = eprom_read(dev, 
(EEPROM_Customer_ID>>1))>>8;
} else {
priv->eeprom_vid = 0;
priv->eeprom_pid = 0;
@@ -2344,7 +2344,7 @@ static void rtl8192_read_eeprom_info(struct net_device 
*dev)
priv->EEPROMThermalMeter = EEPROM_Default_ThermalMeter;
RT_TRACE(COMP_EPROM, "ThermalMeter:%d\n", 
priv->EEPROMThermalMeter);
//vivi, for tx power track
-   priv->TSSI_13dBm = priv->EEPROMThermalMeter *100;
+   priv->TSSI_13dBm = priv->EEPROMThermalMeter * 100;
//read antenna tx power offset of B/C/D to A from EEPROM
if (bLoad_From_EEPOM)
priv->EEPROMPwDiff = (eprom_read(dev, 
(EEPROM_PwDiff>>1))&0x0f00)>>8;
@@ -2570,7 +2570,7 @@ static void rtl8192_hwconfig(struct net_device *dev)
regRRSR = RATE_ALL_CCK;
break;
case WIRELESS_MODE_A:
-   regBwOpMode = BW_OPMODE_5G |BW_OPMODE_20MHZ;
+   regBwOpMode = BW_OPMODE_5G | BW_OPMODE_20MHZ;
regRATR = RATE_ALL_OFDM_AG;
regRRSR = RATE_ALL_OFDM_AG;
break;
@@ -2706,7 +2706,7 @@ static bool rtl8192_adapter_start(struct net_device *dev)
write_nic_dword(dev, RQPN1,  NUM_OF_PAGE_IN_FW_QUEUE_BK << 
RSVD_FW_QUEUE_PAGE_BK_SHIFT |
NUM_OF_PAGE_IN_FW_QUEUE_BE << 
RSVD_FW_QUEUE_PAGE_BE_SHIFT |
NUM_OF_PAGE_IN_FW_QUEUE_VI << 
RSVD_FW_QUEUE_PAGE_VI_SHIFT |
-   NUM_OF_PAGE_IN_FW_QUEUE_VO 
 
priv->stats.rx_rssi_percentage[rfpath]) {
priv->stats.rx_rssi_percentage[rfpath] =

((priv->stats.rx_rssi_percentage[rfpath]*(Rx_Smooth_Factor-1)) +
-
(pprevious_stats->RxMIMOSignalStrength[rfpath])) /(Rx_Smooth_Factor);
+
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
priv->stats.rx_rssi_percentage[rfpath] = 
priv->stats.rx_rssi_percentage[rfpath]  + 1;
} else {
priv->stats.rx_rssi_percentage[rfpath] =

((priv->stats.rx_rssi_percentage[rfpath]*(Rx_Smooth_Factor-1)) +
-
(pprevious_stats->RxMIMOSignalStrength[rfpath])) /(Rx_Smooth_Factor);
+
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
}
RT_TRACE(COMP_DBG, 
"priv->stats.rx_rssi_percentage[rfPath]  = %d \n", 
priv->stats.rx_rssi_percentage[rfpath]);
}
@@ -3818,12 +3818,12 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,
if (pprevious_stats->RxPWDBAll > 
(u32)priv->undecorated_smoothed_pwdb) {
priv->undecorated_smoothed_pwdb =

(((priv->undecorated_smoothed_pwdb)*(Rx_Smooth_Factor-1)) +
-(pprevious_stats->RxPWDBAll)) 
/(Rx_Smooth_Factor);
+(pprevious_stats->RxPWDBAll)) / 
(Rx_Smooth_Factor);
priv->undecorated_smoothed_pwdb = 
priv->undecorated_smoothed_pwdb + 1;
} else {
priv->undecorated_smoothed_pwdb =

(((priv->undecorated_smoothed_pwdb)*(Rx_Smooth_Factor-1)) +
-(pprevious_stats->RxPWDBAll)) 
/(Rx_Smooth_Factor);
+(pprevious_stats->RxPWDBAll)) / 
(Rx_Smooth_Factor);
}
 
}
@@ -3860,8 +3860,8 @@ static void 

[PATCH 14/20] staging: rtl8192u: r8192U_core: fix unnecessary parentheses code style issue

[Raphaël Beamonte]

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 99d7f7c..25d31fe 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1859,7 +1859,7 @@ static int rtl8192_qos_handle_probe_response(struct 
r8192_priv *priv,
if (priv->ieee80211->state != IEEE80211_LINKED)
return ret;
 
-   if ((priv->ieee80211->iw_mode != IW_MODE_INFRA))
+   if (priv->ieee80211->iw_mode != IW_MODE_INFRA)
return ret;
 
if (network->flags & NETWORK_HAS_QOS_MASK) {
@@ -1923,7 +1923,7 @@ static int rtl8192_qos_association_resp(struct r8192_priv 
*priv,
if (priv->ieee80211->state != IEEE80211_LINKED)
return 0;
 
-   if ((priv->ieee80211->iw_mode != IW_MODE_INFRA))
+   if (priv->ieee80211->iw_mode != IW_MODE_INFRA)
return 0;
 
spin_lock_irqsave(>ieee80211->lock, flags);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 15/20] staging: rtl8192u: r8192U_core: fix unnecessary else after return code style issue

[Raphaël Beamonte]

An else statement is not useful after a return.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 25d31fe..c91ae28 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -988,8 +988,6 @@ static int rtl8192_hard_start_xmit(struct sk_buff *skb, 
struct net_device *dev)
skb_push(skb, USB_HWDESC_HEADER_LEN);
rtl819xU_tx_cmd(dev, skb);
ret = 1;
-   spin_unlock_irqrestore(>tx_lock, flags);
-   return ret;
} else {
skb_push(skb, priv->ieee80211->tx_headroom);
ret = rtl8192_tx(dev, skb);
@@ -1300,12 +1298,11 @@ short rtl819xU_tx_cmd(struct net_device *dev, struct 
sk_buff *skb)
 
status = usb_submit_urb(tx_urb, GFP_ATOMIC);
 
-   if (!status) {
+   if (!status)
return 0;
-   } else {
-   DMESGE("Error TX CMD URB, error %d", status);
-   return -1;
-   }
+
+   DMESGE("Error TX CMD URB, error %d", status);
+   return -1;
 }
 
 /*
@@ -1644,11 +1641,11 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
dev->trans_start = jiffies;
atomic_inc(>tx_pending[tcb_desc->queue_index]);
return 0;
-   } else {
-   RT_TRACE(COMP_ERR, "Error TX URB %d, error %d", 
atomic_read(>tx_pending[tcb_desc->queue_index]),
-status);
-   return -1;
}
+
+   RT_TRACE(COMP_ERR, "Error TX URB %d, error %d", 
atomic_read(>tx_pending[tcb_desc->queue_index]),
+status);
+   return -1;
 }
 
 static short rtl8192_usb_initendpoints(struct net_device *dev)
@@ -2924,20 +2921,20 @@ static bool HalRxCheckStuck819xUsb(struct net_device 
*dev)
(priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 && 
priv->undecorated_smoothed_pwdb >= RateAdaptiveTH_Low_20M))) {
if (rx_chk_cnt < 2)
return bStuck;
-   else
-   rx_chk_cnt = 0;
+
+   rx_chk_cnt = 0;
} else if (((priv->CurrentChannelBW != HT_CHANNEL_WIDTH_20 && 
priv->undecorated_smoothed_pwdb < RateAdaptiveTH_Low_40M) ||
(priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 && 
priv->undecorated_smoothed_pwdb < RateAdaptiveTH_Low_20M)) &&
 priv->undecorated_smoothed_pwdb >= VeryLowRSSI) {
if (rx_chk_cnt < 4)
return bStuck;
-   else
-   rx_chk_cnt = 0;
+
+   rx_chk_cnt = 0;
} else {
if (rx_chk_cnt < 8)
return bStuck;
-   else
-   rx_chk_cnt = 0;
+
+   rx_chk_cnt = 0;
}
 
if (priv->RxCounter == RegRxCounter)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 17/20] staging: rtl8192u: r8192U_core: fix missing blank line after declarations code style issue

[Raphaël Beamonte]

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 44 +++---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 5aae096..511e979 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -160,6 +160,7 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct 
r8192_priv *priv)
 {
int i, max_chan = -1, min_chan = -1;
struct ieee80211_device *ieee = priv->ieee80211;
+
switch (channel_plan) {
case COUNTRY_CODE_FCC:
case COUNTRY_CODE_IC:
@@ -428,6 +429,7 @@ static int proc_get_stats_ap(struct seq_file *m, void *v)
 
list_for_each_entry(target, >network_list, list) {
const char *wpa = "non_WPA";
+
if (target->wpa_ie_len > 0 || target->rsn_ie_len > 0)
wpa = "WPA";
 
@@ -674,6 +676,7 @@ void rtl8192_update_msr(struct net_device *dev)
 void rtl8192_set_chan(struct net_device *dev, short ch)
 {
struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev);
+
RT_TRACE(COMP_CH, "=>%s()ch:%d\n", __func__, ch);
priv->chan = ch;
 
@@ -879,8 +882,10 @@ static void rtl8192_rx_isr(struct urb *urb)
struct r8192_priv *priv = ieee80211_priv(dev);
int out_pipe = info->out_pipe;
int err;
+
if (!priv->up)
return;
+
if (unlikely(urb->status)) {
info->urb = NULL;
priv->stats.rxstaterr++;
@@ -1058,6 +1063,7 @@ static void rtl8192_config_rate(struct net_device *dev, 
u16 *rate_config)
struct r8192_priv *priv = ieee80211_priv(dev);
struct ieee80211_network *net;
u8 i = 0, basic_rate = 0;
+
net = >ieee80211->current_network;
 
for (i = 0; i < net->rates_len; i++) {
@@ -1153,6 +1159,7 @@ static void rtl8192_update_cap(struct net_device *dev, 
u16 cap)
u32 tmp = 0;
struct r8192_priv *priv = ieee80211_priv(dev);
struct ieee80211_network *net = >ieee80211->current_network;
+
priv->short_preamble = cap & WLAN_CAPABILITY_SHORT_PREAMBLE;
tmp = priv->basic_rate;
if (priv->short_preamble)
@@ -1161,6 +1168,7 @@ static void rtl8192_update_cap(struct net_device *dev, 
u16 cap)
 
if (net->mode & (IEEE_G | IEEE_N_24G)) {
u8 slot_time = 0;
+
if ((cap & WLAN_CAPABILITY_SHORT_SLOT) && 
(!priv->ieee80211->pHTInfo->bCurrentRT2RTLongSlotTime)) /* short slot time */
slot_time = SHORT_SLOT_TIME;
else /* long slot time */
@@ -1177,6 +1185,7 @@ static void rtl8192_net_update(struct net_device *dev)
struct ieee80211_network *net;
u16 BcnTimeCfg = 0, BcnCW = 6, BcnIFS = 0xf;
u16 rate_config = 0;
+
net = >ieee80211->current_network;
 
rtl8192_config_rate(dev, _config);
@@ -1490,6 +1499,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
int status;
struct urb *tx_urb = NULL, *tx_urb_zero = NULL;
unsigned int idx_pipe;
+
pend = atomic_read(>tx_pending[tcb_desc->queue_index]);
/* we are locked here so the two atomic_read and inc are executed
 * without interleaves
@@ -1616,6 +1626,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
 */
bool bSend0Byte = false;
u8 zero = 0;
+
if (udev->speed == USB_SPEED_HIGH) {
if (skb->len > 0 && skb->len % 512 == 0)
bSend0Byte = true;
@@ -1761,6 +1772,7 @@ static void rtl8192_link_change(struct net_device *dev)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
struct ieee80211_device *ieee = priv->ieee80211;
+
if (ieee->state == IEEE80211_LINKED) {
rtl8192_net_update(dev);
rtl8192_update_ratr_table(dev);
@@ -1774,6 +1786,7 @@ static void rtl8192_link_change(struct net_device *dev)
/*update timing params*/
if (ieee->iw_mode == IW_MODE_INFRA || ieee->iw_mode == IW_MODE_ADHOC) {
u32 reg = 0;
+
read_nic_dword(dev, RCR, );
if (priv->ieee80211->state == IEEE80211_LINKED)
priv->ReceiveConfig = reg |= RCR_CBSSID;
@@ -1959,6 +1972,7 @@ static int rtl8192_handle_assoc_response(struct 
net_device *dev,
 struct ieee80211_network *network)
 {
struct r8192_priv *priv = ieee80211_priv(dev);
+
rtl8192_qos_association_resp(priv, network);
return 0;
 }
@@ -1971,6 +1985,7 @@ static void rtl8192_update_ratr_table(struct net_device 
*dev)
u8 *pMcsRate = ieee->dot11HTOperationalRateSet;
u32 ratr_value = 0;
u8 rate_index = 0;
+
rtl8192_config_rate(dev, (u16 *)(_value));
ratr_value 

[PATCH 03/20] staging: rtl8192u: t8192U_core: fix space before close parenthesis code style error

[Raphaël Beamonte]

A space existed before the close parenthesis of an if statement. This patch
removes it to follow the kernel code style.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index c4ab2a8..1eaaa7a 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3221,7 +3221,7 @@ static void rtl819x_watchdog_wqcallback(struct 
work_struct *work)
//to get busy traffic condition
if (ieee->state == IEEE80211_LINKED) {
if (ieee->LinkDetectInfo.NumRxOkInPeriod > 666 ||
-   ieee->LinkDetectInfo.NumTxOkInPeriod > 666 ) {
+   ieee->LinkDetectInfo.NumTxOkInPeriod > 666) {
bBusyTraffic = true;
}
ieee->LinkDetectInfo.NumRxOkInPeriod = 0;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 16/20] staging: rtl8192u: r8192U_core: fix unnecessary whitespace code style issue

[Raphaël Beamonte]

Whitespaces are not necessary before a quoted newline.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index c91ae28..5aae096 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1350,7 +1350,7 @@ static u8 MapHwQueueToFirmwareQueue(u8 QueueID)
break;
 
default:
-   RT_TRACE(COMP_ERR, "TransmitTCB(): Impossible Queue Selection: 
%d \n", QueueID);
+   RT_TRACE(COMP_ERR, "TransmitTCB(): Impossible Queue Selection: 
%d\n", QueueID);
break;
}
return QueueSelect;
@@ -1880,7 +1880,7 @@ static int rtl8192_qos_handle_probe_response(struct 
r8192_priv *priv,
 
if ((network->qos_data.active == 1) && (active_network == 1)) {
queue_work(priv->priv_wq, >qos_activate);
-   RT_TRACE(COMP_QOS, "QoS was disabled call qos_activate 
\n");
+   RT_TRACE(COMP_QOS, "QoS was disabled call 
qos_activate\n");
}
network->qos_data.active = 0;
network->qos_data.supported = 0;
@@ -2895,7 +2895,7 @@ static RESET_TYPE TxCheckStuck(struct net_device *dev)
}
if (bCheckFwTxCnt) {
if (HalTxCheckStuck819xUsb(dev)) {
-   RT_TRACE(COMP_RESET, "TxCheckStuck(): Fw indicates no 
Tx condition! \n");
+   RT_TRACE(COMP_RESET, "TxCheckStuck(): Fw indicates no 
Tx condition!\n");
return RESET_TYPE_SILENT;
}
}
@@ -3032,7 +3032,7 @@ static void CamRestoreAllEntry(struct net_device *dev)
static u8   CAM_CONST_BROAD[] = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
 
-   RT_TRACE(COMP_SEC, "CamRestoreAllEntry: \n");
+   RT_TRACE(COMP_SEC, "CamRestoreAllEntry:\n");
 
 
if ((priv->ieee80211->pairwise_key_type == KEY_TYPE_WEP40) ||
@@ -3107,7 +3107,7 @@ static void rtl819x_ifsilentreset(struct net_device *dev)
if (priv->ResetProgress == RESET_TYPE_NORESET) {
 RESET_START:
 
-   RT_TRACE(COMP_RESET, "=>Reset progress!! \n");
+   RT_TRACE(COMP_RESET, "=>Reset progress!!\n");
 
/* Set the variable for reset. */
priv->ResetProgress = RESET_TYPE_SILENT;
@@ -3783,7 +3783,7 @@ static void rtl8192_process_phyinfo(struct r8192_priv 
*priv, u8 *buffer,

((priv->stats.rx_rssi_percentage[rfpath] * (Rx_Smooth_Factor - 1)) +
 
(pprevious_stats->RxMIMOSignalStrength[rfpath])) / (Rx_Smooth_Factor);
}
-   RT_TRACE(COMP_DBG, 
"priv->stats.rx_rssi_percentage[rfPath]  = %d \n", 
priv->stats.rx_rssi_percentage[rfpath]);
+   RT_TRACE(COMP_DBG, 
"priv->stats.rx_rssi_percentage[rfPath]  = %d\n", 
priv->stats.rx_rssi_percentage[rfpath]);
}
}
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 19/20] staging: rtl8192u: r8192U_core: fix use ether_addr_copy() over memcpy() code style issue

[Raphaël Beamonte]

Prefer ether_addr_copy() over memcpy() if the Ethernet addresses are 
__aligned(2)

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 0048cff..28074ca 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3469,7 +3469,7 @@ static int r8192_set_mac_adr(struct net_device *dev, void 
*mac)
 
down(>wx_sem);
 
-   memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
+   ether_addr_copy(dev->dev_addr, addr->sa_data);
 
schedule_work(>reset_wq);
up(>wx_sem);
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 18/20] staging: rtl8192u: r8192U_core: fix quoted string split across lines code style issue

[Raphaël Beamonte]

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 511e979..0048cff 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -611,8 +611,8 @@ static void rtl8192_proc_init_one(struct net_device *dev)
for (f = rtl8192_proc_files; f->name[0]; f++) {
if (!proc_create_data(f->name, S_IFREG | S_IRUGO, dir,
  _proc_fops, f->show)) {
-   RT_TRACE(COMP_ERR, "Unable to initialize "
-"/proc/net/rtl8192/%s/%s\n",
+   RT_TRACE(COMP_ERR,
+"Unable to initialize 
/proc/net/rtl8192/%s/%s\n",
 dev->name, f->name);
return;
}
@@ -1884,8 +1884,8 @@ static int rtl8192_qos_handle_probe_response(struct 
r8192_priv *priv,
network->qos_data.old_param_count =
network->qos_data.param_count;
queue_work(priv->priv_wq, >qos_activate);
-   RT_TRACE(COMP_QOS, "QoS parameters change call "
-"qos_activate\n");
+   RT_TRACE(COMP_QOS,
+"QoS parameters change call qos_activate\n");
}
} else {
memcpy(>ieee80211->current_network.qos_data.parameters,
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 05/20] staging: rtl8192u: r8192U_core: fix else following close brace code style error

[Raphaël Beamonte]

Fix else should follow close brace code style error.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index fe92021..80b9a08 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2585,8 +2585,7 @@ static void rtl8192_hwconfig(struct net_device *dev)
regBwOpMode = BW_OPMODE_20MHZ;
regRATR = RATE_ALL_CCK | RATE_ALL_OFDM_AG;
regRRSR = RATE_ALL_CCK | RATE_ALL_OFDM_AG;
-   }
-   else
+   } else
 #endif
{
regBwOpMode = BW_OPMODE_20MHZ;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 07/20] staging: rtl8192u: r8192_core: whitespace neatening

[Raphaël Beamonte]

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 270 -
 1 file changed, 135 insertions(+), 135 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index b204782..7d3a626 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -37,17 +37,17 @@ unsigned int __fixunsdfsi(double d)
 
 double __adddf3(double a, double b)
 {
-   return a+b;
+   return a + b;
 }
 
 double __addsf3(float a, float b)
 {
-   return a+b;
+   return a + b;
 }
 
 double __subdf3(double a, double b)
 {
-   return a-b;
+   return a - b;
 }
 
 double __extendsfdf2(float a)
@@ -114,9 +114,9 @@ static int channels = 0x3fff;
 
 
 
-module_param(ifname, charp, S_IRUGO|S_IWUSR);
-module_param(hwwep, int, S_IRUGO|S_IWUSR);
-module_param(channels, int, S_IRUGO|S_IWUSR);
+module_param(ifname, charp, S_IRUGO | S_IWUSR);
+module_param(hwwep, int, S_IRUGO | S_IWUSR);
+module_param(channels, int, S_IRUGO | S_IWUSR);
 
 MODULE_PARM_DESC(ifname, " Net interface name, wlan%d=default");
 MODULE_PARM_DESC(hwwep, " Try to use hardware security support. ");
@@ -212,7 +212,7 @@ static void CamResetAllEntry(struct net_device *dev)
//2004/02/11  In static WEP, OID_ADD_KEY or OID_ADD_WEP are set before 
STA associate to AP.
// However, ResetKey is called on OID_802_11_INFRASTRUCTURE_MODE and 
MlmeAssociateRequest
// In this condition, Cam can not be reset because upper layer will not 
set this static key again.
-   ulcommand |= BIT31|BIT30;
+   ulcommand |= BIT31 | BIT30;
write_nic_dword(dev, RWCAM, ulcommand);
 
 }
@@ -221,14 +221,14 @@ static void CamResetAllEntry(struct net_device *dev)
 void write_cam(struct net_device *dev, u8 addr, u32 data)
 {
write_nic_dword(dev, WCAMI, data);
-   write_nic_dword(dev, RWCAM, BIT31|BIT16|(addr&0xff));
+   write_nic_dword(dev, RWCAM, BIT31 | BIT16 | (addr & 0xff));
 }
 
 u32 read_cam(struct net_device *dev, u8 addr)
 {
u32 data;
 
-   write_nic_dword(dev, RWCAM, 0x8000|(addr&0xff));
+   write_nic_dword(dev, RWCAM, 0x8000 | (addr & 0xff));
read_nic_dword(dev, 0xa8, );
return data;
 }
@@ -241,7 +241,7 @@ void write_nic_byte_E(struct net_device *dev, int indx, u8 
data)
 
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
 RTL8187_REQ_SET_REGS, RTL8187_REQT_WRITE,
-indx|0xfe00, 0, , 1, HZ / 2);
+indx | 0xfe00, 0, , 1, HZ / 2);
 
if (status < 0)
netdev_err(dev, "write_nic_byte_E TimeOut! status: %d\n", 
status);
@@ -255,7 +255,7 @@ int read_nic_byte_E(struct net_device *dev, int indx, u8 
*data)
 
status = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
 RTL8187_REQ_GET_REGS, RTL8187_REQT_READ,
-indx|0xfe00, 0, data, 1, HZ / 2);
+indx | 0xfe00, 0, data, 1, HZ / 2);
 
if (status < 0) {
netdev_err(dev, "%s failure status: %d\n", __func__, status);
@@ -274,7 +274,7 @@ void write_nic_byte(struct net_device *dev, int indx, u8 
data)
 
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
 RTL8187_REQ_SET_REGS, RTL8187_REQT_WRITE,
-(indx&0xff)|0xff00, (indx>>8)&0x0f, , 1, 
HZ / 2);
+(indx & 0xff) | 0xff00, (indx >> 8) & 0x0f, 
, 1, HZ / 2);
 
if (status < 0)
netdev_err(dev, "write_nic_byte TimeOut! status: %d\n", status);
@@ -293,7 +293,7 @@ void write_nic_word(struct net_device *dev, int indx, u16 
data)
 
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
 RTL8187_REQ_SET_REGS, RTL8187_REQT_WRITE,
-(indx&0xff)|0xff00, (indx>>8)&0x0f, , 2, 
HZ / 2);
+(indx & 0xff) | 0xff00, (indx >> 8) & 0x0f, 
, 2, HZ / 2);
 
if (status < 0)
netdev_err(dev, "write_nic_word TimeOut! status: %d\n", status);
@@ -311,7 +311,7 @@ void write_nic_dword(struct net_device *dev, int indx, u32 
data)
 
status = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
 RTL8187_REQ_SET_REGS, RTL8187_REQT_WRITE,
-(indx&0xff)|0xff00, (indx>>8)&0x0f, , 4, 
HZ / 2);
+(indx & 0xff) | 0xff00, (indx >> 8) & 0x0f, 
, 4, HZ / 2);
 
 
if (status < 0)
@@ -329,7 +329,7 @@ int read_nic_byte(struct net_device *dev, int indx, u8 
*data)
 
status = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),
 RTL8187_REQ_GET_REGS, RTL8187_REQT_READ,
-(indx&0xff)|0xff00, (indx>>8)&0x0f, data, 1, 
HZ / 2);
+ 

[PATCH 20/20] staging: rtl8192u: r8192U_core: fix line over 80 characters code style issue

[Raphaël Beamonte]

Light code refactoring to keep the lines under 80 characters to follow
the kernel code style.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 1248 ++--
 lib/Kconfig.debug  |2 +-
 2 files changed, 851 insertions(+), 399 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 28074ca..fd62dbb 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -143,22 +143,61 @@ struct CHANNEL_LIST {
 };
 
 static struct CHANNEL_LIST ChannelPlan[] = {
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 
149, 153, 157, 161, 165}, 24}, /* FCC */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},  
/* IC */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56, 
60, 64}, 21},  /* ETSI */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  
/* Spain. Change to ETSI. */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  
/* France. Change to ETSI. */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  /* MKK */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  /* MKK1 */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  
/* Israel. */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  /* For 11a , TELEC */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  /* MIC */
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14}   /* For Global 
Domain. 1-11:active scan, 12-14 passive scan. */
+   { /* FCC */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60,
+64, 149, 153, 157, 161, 165},
+   24
+   },
+   { /* IC */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11},
+   11
+   },
+   { /* ETSI */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52,
+56, 60, 64},
+   21
+   },
+   { /* Spain. Change to ETSI. */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
+   13
+   },
+   { /* France. Change to ETSI. */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
+   13
+   },
+   { /* MKK */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48,
+52, 56, 60, 64},
+   22
+   },
+   { /* MKK1 */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48,
+52, 56, 60, 64},
+   22
+   },
+   { /* Israel. */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13},
+   13
+   },
+   { /* For 11a , TELEC */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48,
+52, 56, 60, 64},
+   22
+   },
+   { /* MIC */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48,
+52, 56, 60, 64},
+   22
+   },
+   { /* For Global Domain. 1-11:active scan, 12-14 passive scan. */
+   {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14},
+   14
+   }
 };
 
 static void rtl819x_set_channel_map(u8 channel_plan, struct r8192_priv *priv)
 {
-   int i, max_chan = -1, min_chan = -1;
+   int i, max_chan = -1, min_chan = -1, chan = -1;
struct ieee80211_device *ieee = priv->ieee80211;
 
switch (channel_plan) {
@@ -179,22 +218,29 @@ static void rtl819x_set_channel_map(u8 channel_plan, 
struct r8192_priv *priv)
min_chan = 1;
max_chan = 14;
} else {
-   RT_TRACE(COMP_ERR, "unknown rf chip, can't set channel 
map in function:%s()\n", __func__);
+   RT_TRACE(COMP_ERR,
+"unknown rf chip, can't set channel map in 
function:%s()\n",
+__func__);
}
if (ChannelPlan[channel_plan].Len != 0) {
/* Clear old channel map */
-   memset(GET_DOT11D_INFO(ieee)->channel_map, 0, 
sizeof(GET_DOT11D_INFO(ieee)->channel_map));
+   memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
+  sizeof(GET_DOT11D_INFO(ieee)->channel_map));
/* Set new channel map */
for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
-  

[PATCH 06/20] staging: rtl8192u: r8192U_core: fix missing struct leading to consistent spacing code style error

[Raphaël Beamonte]

A missing struct keyword in variable declaration triggered a
need consistent spacing around '*' code style error.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 80b9a08..b204782 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -4191,7 +4191,7 @@ static void TranslateRxSignalStuff819xUsb(struct sk_buff 
*skb,
  rx_drvinfo_819x_usb  *pdrvinfo)
 {
// TODO: We must only check packet for current MAC address. Not finish
-   rtl8192_rx_info *info = (struct rtl8192_rx_info *)skb->cb;
+   struct rtl8192_rx_info *info = (struct rtl8192_rx_info *)skb->cb;
struct net_device *dev = info->dev;
struct r8192_priv *priv = (struct r8192_priv *)ieee80211_priv(dev);
bool bpacket_match_bssid, bpacket_toself;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 08/20] staging: rtl8192u: r8192_core: clean C99 // comments

[Raphaël Beamonte]

Replace C99 // comments by /* comments */ to follow the
kernel code style. Remove some unuseful comments.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 636 -
 1 file changed, 316 insertions(+), 320 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 7d3a626..9477a0f 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -64,7 +64,7 @@ double __extendsfdf2(float a)
 #include "r8190_rtl8256.h" /* RTL8225 Radio frontend */
 #include "r8180_93cx6.h"   /* Card EEPROM */
 #include "r8192U_wx.h"
-#include "r819xU_phy.h" //added by WB 4.30.2008
+#include "r819xU_phy.h"
 #include "r819xU_phyreg.h"
 #include "r819xU_cmdpkt.h"
 #include "r8192U_dm.h"
@@ -72,13 +72,13 @@ double __extendsfdf2(float a)
 #include 
 #include 
 #include 
-// FIXME: check if 2.6.7 is ok
+/* FIXME: check if 2.6.7 is ok */
 
 #include "dot11d.h"
-//set here to open your trace code. //WB
+/* set here to open your trace code. */
 u32 rt_global_debug_component = COMP_DOWN  |
COMP_SEC|
-   COMP_ERR; //always open err flags on
+   COMP_ERR; /* always open err flags on */
 
 #define TOTAL_CAM_ENTRY 32
 #define CAM_CONTENT_COUNT 8
@@ -109,7 +109,7 @@ MODULE_DEVICE_TABLE(usb, rtl8192_usb_id_tbl);
 MODULE_DESCRIPTION("Linux driver for Realtek RTL8192 USB WiFi cards");
 
 static char *ifname = "wlan%d";
-static int hwwep = 1;  //default use hw. set 0 to use software security
+static int hwwep = 1;  /* default use hw. set 0 to use software security */
 static int channels = 0x3fff;
 
 
@@ -143,17 +143,17 @@ struct CHANNEL_LIST {
 };
 
 static struct CHANNEL_LIST ChannelPlan[] = {
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 
149, 153, 157, 161, 165}, 24}, //FCC
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},  
//IC
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56, 
60, 64}, 21},  //ETSI
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},//Spain. Change 
to ETSI.
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  //France. 
Change to ETSI.
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  //MKK   //MKK
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},//MKK1
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  //Israel.
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  // For 11a , TELEC
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},//MIC
-   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14}   
//For Global Domain. 1-11:active scan, 12-14 passive scan. 
//+YJ, 080626
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 36, 40, 44, 48, 52, 56, 60, 64, 
149, 153, 157, 161, 165}, 24}, /* FCC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}, 11},  
/* IC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 36, 40, 44, 48, 52, 56, 
60, 64}, 21},  /* ETSI */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  
/* Spain. Change to ETSI. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  
/* France. Change to ETSI. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  /* MKK */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  /* MKK1 */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}, 13},  
/* Israel. */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  /* For 11a , TELEC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 36, 40, 44, 48, 52, 
56, 60, 64}, 22},  /* MIC */
+   {{1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14}, 14}   /* For Global 
Domain. 1-11:active scan, 12-14 passive scan. */
 };
 
 static void rtl819x_set_channel_map(u8 channel_plan, struct r8192_priv *priv)
@@ -173,7 +173,7 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct 
r8192_priv *priv)
case COUNTRY_CODE_MIC:
Dot11d_Init(ieee);
ieee->bGlobalDomain = false;
-   //actually 8225 & 8256 rf chips only support B,G,24N mode
+   /* actually 8225 & 8256 rf chips only support B,G,24N mode */
if ((priv->rf_chip == RF_8225) || 

[PATCH 09/20] staging: rtl8192u: r8192U_core: include linux/uaccess.h instead of asm/uaccess.h

[Raphaël Beamonte]

Use #include  instead of 

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 9477a0f..5bbfa91 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -58,7 +58,7 @@ double __extendsfdf2(float a)
 
 #define CONFIG_RTL8192_IO_MAP
 
-#include 
+#include 
 #include "r8192U_hw.h"
 #include "r8192U.h"
 #include "r8190_rtl8256.h" /* RTL8225 Radio frontend */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 10/20] staging: rtl8192u: r8192U_core: remove return statement of void function

[Raphaël Beamonte]

void function return statement was not useful in this case

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 5bbfa91..ff8c197 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1481,7 +1481,6 @@ static u8 QueryIsShort(u8 TxHT, u8 TxRate, cb_desc 
*tcb_desc)
 
 static void tx_zero_isr(struct urb *tx_urb)
 {
-   return;
 }
 
 /*
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 11/20] staging: rtl8192u: r8192U_core: fix unecessary braces code style issue

[Raphaël Beamonte]

braces {} are not necessary for any arm of a statement containing
one statement on each side.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index ff8c197..a851341 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2304,11 +2304,10 @@ static void rtl8192_read_eeprom_info(struct net_device 
*dev)
wEPROM_ID = eprom_read(dev, 0); /* first read EEPROM ID out; */
RT_TRACE(COMP_EPROM, "EEPROM ID is 0x%x\n", wEPROM_ID);
 
-   if (wEPROM_ID != RTL8190_EEPROM_ID) {
+   if (wEPROM_ID != RTL8190_EEPROM_ID)
RT_TRACE(COMP_ERR, "EEPROM ID is invalid(is 0x%x(should be 
0x%x)\n", wEPROM_ID, RTL8190_EEPROM_ID);
-   } else {
+   else
bLoad_From_EEPOM = true;
-   }
 
if (bLoad_From_EEPOM) {
tmpValue = eprom_read(dev, EEPROM_VID >> 1);
@@ -2496,11 +2495,10 @@ static void rtl8192_read_eeprom_info(struct net_device 
*dev)
}
 
 
-   if (priv->rf_type == RF_1T2R) {
+   if (priv->rf_type == RF_1T2R)
RT_TRACE(COMP_EPROM, "\n1T2R config\n");
-   } else {
+   else
RT_TRACE(COMP_EPROM, "\n2T4R config\n");
-   }
 
/* We can only know RF type in the function. So we have to init
 * DIG RATR table again.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 12/20] staging: rtl8192u: r8192U_core: fix externs in .c file code style issue

[Raphaël Beamonte]

Externs should be avoided in .c files. These one were not useful and
are thus removed.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index a851341..849fd3d 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1000,9 +1000,6 @@ static int rtl8192_hard_start_xmit(struct sk_buff *skb, 
struct net_device *dev)
return ret;
 }
 
-
-void rtl8192_try_wake_queue(struct net_device *dev, int pri);
-
 static void rtl8192_tx_isr(struct urb *tx_urb)
 {
struct sk_buff *skb = (struct sk_buff *)tx_urb->context;
@@ -1223,9 +1220,6 @@ inline u8 rtl8192_IsWirelessBMode(u16 rate)
return 0;
 }
 
-u16 N_DBPSOfRate(u16 DataRate);
-
-
 u16 N_DBPSOfRate(u16 DataRate)
 {
u16 N_DBPS = 24;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 00/20] staging: rtl8192u: r8192U_core: fix all checkpatch.pl reports

[Raphaël Beamonte]

Hello,

This patches series fixes all the checkpatch.pl errors and warnings on
the file drivers/staging/rtl8192u/r8192U_core.c.

checkpatch.pl tail output before patches: (on staging-testing)
total: 334 errors, 402 warnings, 4909 lines checked
checkpath.pl output after patches:
total: 0 errors, 0 warnings, 5379 lines checked 

Thanks,
Raphaël


Raphaël Beamonte (20):
  staging: rtl8192u: r8192U_core: fix switch and case indent code style
error
  staging: rtl8192u: r8192U_core: fix consistent spacing code style
error
  staging: rtl8192u: t8192U_core: fix space before close parenthesis
code style error
  staging: rtl8192u: r8192U_core: fix code indent using spaces code
style error
  staging: rtl8192u: r8192U_core: fix else following close brace code
style error
  staging: rtl8192u: r8192U_core: fix missing struct leading to
consistent spacing code style error
  staging: rtl8192u: r8192_core: whitespace neatening
  staging: rtl8192u: r8192_core: clean C99 // comments
  staging: rtl8192u: r8192U_core: include linux/uaccess.h instead of
asm/uaccess.h
  staging: rtl8192u: r8192U_core: remove return statement of void
function
  staging: rtl8192u: r8192U_core: fix unecessary braces code style issue
  staging: rtl8192u: r8192U_core: fix externs in .c file code style
issue
  staging: rtl8192u: r8192U_core: fix unnecessary check before kfree
code style issue
  staging: rtl8192u: r8192U_core: fix unnecessary parentheses code style
issue
  staging: rtl8192u: r8192U_core: fix unnecessary else after return code
style issue
  staging: rtl8192u: r8192U_core: fix unnecessary whitespace code style
issue
  staging: rtl8192u: r8192U_core: fix missing blank line after
declarations code style issue
  staging: rtl8192u: r8192U_core: fix quoted string split across lines
code style issue
  staging: rtl8192u: r8192U_core: fix use ether_addr_copy() over
memcpy() code style issue
  staging: rtl8192u: r8192U_core: fix line over 80 characters code style
issue

 drivers/staging/rtl8192u/r8192U_core.c | 2258 +++-
 lib/Kconfig.debug  |2 +-
 2 files changed, 1365 insertions(+), 895 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 01/20] staging: rtl8192u: r8192U_core: fix switch and case indent code style error

[Raphaël Beamonte]

Some switch and case were not be at the same indent level.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 190 -
 1 file changed, 95 insertions(+), 95 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 6f6fe38..915493d 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3536,107 +3536,107 @@ static u8 HwRateToMRate90(bool bIsHT, u8 rate)
 
if (!bIsHT) {
switch (rate) {
-   case DESC90_RATE1M:
-   ret_rate = MGN_1M;
-   break;
-   case DESC90_RATE2M:
-   ret_rate = MGN_2M;
-   break;
-   case DESC90_RATE5_5M:
-   ret_rate = MGN_5_5M;
-   break;
-   case DESC90_RATE11M:
-   ret_rate = MGN_11M;
-   break;
-   case DESC90_RATE6M:
-   ret_rate = MGN_6M;
-   break;
-   case DESC90_RATE9M:
-   ret_rate = MGN_9M;
-   break;
-   case DESC90_RATE12M:
-   ret_rate = MGN_12M;
-   break;
-   case DESC90_RATE18M:
-   ret_rate = MGN_18M;
-   break;
-   case DESC90_RATE24M:
-   ret_rate = MGN_24M;
-   break;
-   case DESC90_RATE36M:
-   ret_rate = MGN_36M;
-   break;
-   case DESC90_RATE48M:
-   ret_rate = MGN_48M;
-   break;
-   case DESC90_RATE54M:
-   ret_rate = MGN_54M;
-   break;
+   case DESC90_RATE1M:
+   ret_rate = MGN_1M;
+   break;
+   case DESC90_RATE2M:
+   ret_rate = MGN_2M;
+   break;
+   case DESC90_RATE5_5M:
+   ret_rate = MGN_5_5M;
+   break;
+   case DESC90_RATE11M:
+   ret_rate = MGN_11M;
+   break;
+   case DESC90_RATE6M:
+   ret_rate = MGN_6M;
+   break;
+   case DESC90_RATE9M:
+   ret_rate = MGN_9M;
+   break;
+   case DESC90_RATE12M:
+   ret_rate = MGN_12M;
+   break;
+   case DESC90_RATE18M:
+   ret_rate = MGN_18M;
+   break;
+   case DESC90_RATE24M:
+   ret_rate = MGN_24M;
+   break;
+   case DESC90_RATE36M:
+   ret_rate = MGN_36M;
+   break;
+   case DESC90_RATE48M:
+   ret_rate = MGN_48M;
+   break;
+   case DESC90_RATE54M:
+   ret_rate = MGN_54M;
+   break;
 
-   default:
-   ret_rate = 0xff;
-   RT_TRACE(COMP_RECV, "HwRateToMRate90(): Non 
supported Rate [%x], bIsHT = %d!!!\n", rate, bIsHT);
-   break;
+   default:
+   ret_rate = 0xff;
+   RT_TRACE(COMP_RECV, "HwRateToMRate90(): Non supported 
Rate [%x], bIsHT = %d!!!\n", rate, bIsHT);
+   break;
}
 
} else {
switch (rate) {
-   case DESC90_RATEMCS0:
-   ret_rate = MGN_MCS0;
-   break;
-   case DESC90_RATEMCS1:
-   ret_rate = MGN_MCS1;
-   break;
-   case DESC90_RATEMCS2:
-   ret_rate = MGN_MCS2;
-   break;
-   case DESC90_RATEMCS3:
-   ret_rate = MGN_MCS3;
-   break;
-   case DESC90_RATEMCS4:
-   ret_rate = MGN_MCS4;
-   break;
-   case DESC90_RATEMCS5:
-   ret_rate = MGN_MCS5;
-   break;
-   case DESC90_RATEMCS6:
-   ret_rate = 

Re: Hello everyone <3

[Chuck Ebbert]

On Sun, 16 Aug 2015 02:00:34 +0200
noi...@a6.25u.com wrote:

> Question: Wouldn't it be a good idea to enforce the Linux trademark 
> (somewhen) in a way that all these streamlined operating systems use the 
> word "Linux" more carefully (or not at all) in their promotional 
> material? To make sure "correlation" isn't (deliberately) twisted into 
> "causation" by the media /if/ the streamlining trend starts to cause 
> serious regressions in transparency and reliability?
> 
> Or is that too much politics for the weekend?

Concern troll is concerned.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hello everyone <3

[noisyb]

I'll troll and spread a little FUD on behalf of people who have better 
manners.. :)


This will only /reference/ a few circumstances in user-space and then 
ask an important question regarding kernel-space.


Recently, the user-space side of operating systems (that use the Linux 
kernel) have been streamlined to be more appealing to an unprofessional 
audience.


People who are probably not caring or aware of how operating systems 
function or what e.g. "Ready for the desktop." is supposed to even mean.


At the same time these valuable people are impressing their friends, 
neighbours and strangers (who happened to walk by on the road) with 
shorter reboot cycles of their streamlined operating system.


A key package in this streamlining of operating systems (that use the 
Linux kernel) is systemd, another iteration of the ideas that also led 
to the now defunct HAL project from a few years ago.


systemd promises to remove/hide burdensome transparency (AKA complexity) 
of the operating system from unprofessional users into an unauditioned 
program that uses proprietary config files.


I was so lucky so get in contact with systemd package maintainers of a 
popular operating system and they told me that they don't have enough 
people to keep up with the increasing speed of systemd updates/releases.


So NO auditioning of systemd is taking place in one of the most 
important operating systems that uses the Linux kernel and uses the 
trademark "Linux" in the promotional material.


The media is also still using "Linux operating system" or "Linux 
distribution" instead of just "operating system (that uses the Linux 
kernel)" to reference to these operating systems that are aimed at 
unprofessional users and where crucial parts are not auditioned.


The problem is that all users experience the streamlined user-space but 
call it "Linux".


Question: Wouldn't it be a good idea to enforce the Linux trademark 
(somewhen) in a way that all these streamlined operating systems use the 
word "Linux" more carefully (or not at all) in their promotional 
material? To make sure "correlation" isn't (deliberately) twisted into 
"causation" by the media /if/ the streamlining trend starts to cause 
serious regressions in transparency and reliability?


Or is that too much politics for the weekend?


Dirk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm: Change global memory state symbols to GPL-only

[Ben Hutchings]

Proprietary modules should not be able to touch vm_stat or participate
in shrinking.

Signed-off-by: Ben Hutchings 
---
 mm/vmscan.c | 4 ++--
 mm/vmstat.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 8286938..e6e7449 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -247,7 +247,7 @@ int register_shrinker(struct shrinker *shrinker)
up_write(_rwsem);
return 0;
 }
-EXPORT_SYMBOL(register_shrinker);
+EXPORT_SYMBOL_GPL(register_shrinker);
 
 /*
  * Remove one
@@ -259,7 +259,7 @@ void unregister_shrinker(struct shrinker *shrinker)
up_write(_rwsem);
kfree(shrinker->nr_deferred);
 }
-EXPORT_SYMBOL(unregister_shrinker);
+EXPORT_SYMBOL_GPL(unregister_shrinker);
 
 #define SHRINK_BATCH 128
 
diff --git a/mm/vmstat.c b/mm/vmstat.c
index 4f5cd97..6d3f8f4 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -87,7 +87,7 @@ void vm_events_fold_cpu(int cpu)
  * vm_stat contains the global counters
  */
 atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS] __cacheline_aligned_in_smp;
-EXPORT_SYMBOL(vm_stat);
+EXPORT_SYMBOL_GPL(vm_stat);
 
 #ifdef CONFIG_SMP
 
-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 4/8] watchdog: Make set_timeout function optional

[Guenter Roeck]

Hi Uwe,

On 08/14/2015 12:05 PM, Uwe Kleine-König wrote:

Hello Guenter,

On Fri, Aug 07, 2015 at 10:02:43PM -0700, Guenter Roeck wrote:

For some watchdogs, the hardware timeout is fixed, and the
watchdog driver depends on the watchdog core to handle the
actual timeout. In this situation, the watchdog driver might
only set the 'timeout' variable but do nothing else.
This can as well be handled by the infrastructure, so make
the set_timeout callback optional. If WDIOF_SETTIMEOUT is
configured but the .set_timeout callback is not available,
update the timeout variable in the infrastructure code.

Signed-off-by: Guenter Roeck 

Acked-by: Uwe Kleine-König 



Thanks!
Guenter


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/8] watchdog: Introduce WDOG_RUNNING flag

[Guenter Roeck]

On 08/14/2015 12:04 PM, Uwe Kleine-König wrote:

Hello Guenter,


diff --git a/Documentation/watchdog/watchdog-kernel-api.txt 
b/Documentation/watchdog/watchdog-kernel-api.txt
index 25b00b878a7b..6a54dc15a556 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
[...]
@@ -193,9 +194,12 @@ they are supported. These optional routines/operations are:
  The status bits should (preferably) be set with the set_bit and clear_bit 
alike
  bit-operations. The status bits that are defined are:
  * WDOG_ACTIVE: this status bit indicates whether or not a watchdog timer 
device
-  is active or not. When the watchdog is active after booting, then you should
-  set this status bit (Note: when you register the watchdog timer device with
-  this bit set, then opening /dev/watchdog will skip the start operation)
+  is active or not from user perspective. User space is expected to send
+  heartbeat requests to the driver while this flag is set. If the watchdog
+  is active after booting, and you don't want the infrastructure to send
+  heartbeats to the watchdog driver, then you should set this status bit.


IMHO this should not be the driver author's choice! If you implement
policy in the kernel it should at least be implemented in the framework
and preferably easily changeable. (At least with Kconfig, but better use
a kernel parameter (or both, the latter overriding the former).)


Agreed. I'll change that and simply drop that part. After all,
we now have WDOG_RUNNING to indicate that the watchdog is running.
I'll just have to make sure that there are no drivers which set
WDOG_ACTIVE at boot (afaics there are none).


+  Note: when you register the watchdog timer device with this bit set,
+  then opening /dev/watchdog will skip the start operation.
  * WDOG_DEV_OPEN: this status bit shows whether or not the watchdog device
was opened via /dev/watchdog.
(This bit should only be used by the WatchDog Timer Driver Core).
@@ -209,6 +213,11 @@ bit-operations. The status bits that are defined are:
any watchdog_ops, so that you can be sure that no operations (other then
unref) will get called after unregister, even if userspace still holds a
reference to /dev/watchdog
+* WDOG_RUNNING: Set by the watchdog driver if the hardware watchdog is running.
+  The bit must be set if the watchdog timer hardware can not be stopped.
+  The bit may also be set if the watchdog timer is running aftyer booting,
+  before the watchdog device is opened. If set, the watchdog infrastructure
+  will send keepalives to the watchdog hardware while WDOG_ACTIVE is not set.

To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog
timer device) you can either:
[...]
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index c04ba1a98cc8..676e233d5e7b 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -59,7 +59,8 @@ static inline bool watchdog_need_worker(struct 
watchdog_device *wdd)
unsigned int m = wdd->max_timeout * 1000;
unsigned int t = wdd->timeout * 1000;

-   return watchdog_active(wdd) && hm && (!m || hm < m) && t > hm;
+   return (watchdog_active(wdd) && hm && (!m || hm < m) && t > hm) ||
+  (t && !watchdog_active(wdd) && watchdog_running(wdd));


What is the meaning of

!t && !watchdog_active(wdd) && watchdog_running(wdd)

? Can this happen at all? If not, drop "t && "?


t can be 0, meaning "the watchdog timeout is unknown", unless a driver sets 
min_timeout
to a value larger than 0. Unfortunately, that is not explicitly specified.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/8] watchdog: Introduce hardware maximum timeout in watchdog core

[Guenter Roeck]

On 08/14/2015 04:23 AM, Uwe Kleine-König wrote:

Hello Guenter,

On Fri, Aug 07, 2015 at 10:02:41PM -0700, Guenter Roeck wrote:

[...]
@@ -61,26 +135,27 @@ static struct watchdog_device *old_wdd;

  static int watchdog_ping(struct watchdog_device *wdd)
  {
-   int err = 0;
+   int err;

mutex_lock(>lock);
+   err = _watchdog_ping(wdd);
+   wdd->last_keepalive = jiffies;
+   watchdog_update_worker(wdd, false, false);
+   mutex_unlock(>lock);

-   if (test_bit(WDOG_UNREGISTERED, >status)) {
-   err = -ENODEV;
-   goto out_ping;
-   }
+   return err;
+}

-   if (!watchdog_active(wdd))
-   goto out_ping;
+static void watchdog_ping_work(struct work_struct *work)
+{
+   struct watchdog_device *wdd;

-   if (wdd->ops->ping)
-   err = wdd->ops->ping(wdd);/* ping the watchdog */
-   else
-   err = wdd->ops->start(wdd);   /* restart watchdog */
+   wdd = container_of(to_delayed_work(work), struct watchdog_device, work);

-out_ping:
+   mutex_lock(>lock);
+   _watchdog_ping(wdd);
+   watchdog_update_worker(wdd, false, false);
mutex_unlock(>lock);
-   return err;
  }

  /*
@@ -107,8 +182,11 @@ static int watchdog_start(struct watchdog_device *wdd)
goto out_start;

err = wdd->ops->start(wdd);
-   if (err == 0)
+   if (err == 0) {
set_bit(WDOG_ACTIVE, >status);
+   wdd->last_keepalive = jiffies;
+   watchdog_update_worker(wdd, false, false);
+   }

  out_start:
mutex_unlock(>lock);
@@ -146,8 +224,10 @@ static int watchdog_stop(struct watchdog_device *wdd)
}

err = wdd->ops->stop(wdd);
-   if (err == 0)
+   if (err == 0) {
clear_bit(WDOG_ACTIVE, >status);
+   watchdog_update_worker(wdd, true, false);
+   }

  out_stop:
mutex_unlock(>lock);
@@ -211,6 +291,8 @@ static int watchdog_set_timeout(struct watchdog_device *wdd,

err = wdd->ops->set_timeout(wdd, timeout);

+   watchdog_update_worker(wdd, true, false);


I still try to wrap my head around this function. You pass cancel=true
for stop and set_timeout to ensure that the worker doesn't continue to
run. That's fine.

For watchdog_start you pass cancel=false. I guess the background is that
after one of the next patches the worker might already run for handling
the watchdog being unstoppable. Maybe it's easier to grasp the logic if
you don't try to be too clever here: stop the worker on start
unconditionally and possibly restart it if the hardware needs extra
poking to fulfil the timeout set?


I thought it would reduce the amount of code, and I thought it would be
more confusing and complicated to first call cancel the worker followed
by a (conditional) start. No strong opinion, though; I'll be happy to
make that change in exchange for a Reviewed-by:.



+   if (!watchdog_wq)
+   return -ENODEV;
+
+   INIT_DELAYED_WORK(>work, watchdog_ping_work);
+
+   if (!wdd->max_hw_timeout_ms)
+   wdd->max_hw_timeout_ms = wdd->max_timeout * 1000;


With this (and assuming wdd->max_timeout > 0) the check for
max_hw_timeout_ms != 0 is not necessary, is it?


With the logical change I am making, to ignore max_timeout if max_hw_timeout_ms
is configured, it is indeed no longer necessary (nor desirable).


+
if (wdd->id == 0) {
old_wdd = wdd;
watchdog_miscdev.parent = wdd->parent;
[...]
@@ -585,9 +680,21 @@ int watchdog_dev_unregister(struct watchdog_device *wdd)

  int __init watchdog_dev_init(void)
  {
-   int err = alloc_chrdev_region(_devt, 0, MAX_DOGS, "watchdog");
+   int err;
+
+   watchdog_wq = alloc_workqueue("watchdogd",
+ WQ_HIGHPRI | WQ_MEM_RECLAIM, 0);
+   if (!watchdog_wq) {
+   pr_err("Failed to create watchdog workqueue\n");
+   err = -ENOMEM;
+   goto abort;


Why not return -ENOMEM directly?


No idea. Changed.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/8] watchdog: Introduce hardware maximum timeout in watchdog core

[Guenter Roeck]

Hi Uwe,

On 08/13/2015 02:13 PM, Uwe Kleine-König wrote:

Hello Guenter,

On Fri, Aug 07, 2015 at 10:02:41PM -0700, Guenter Roeck wrote:

Introduce an optional hardware maximum timeout in the watchdog core.
The hardware maximum timeout can be lower than the maximum timeout.

Drivers can set the maximum hardware timeout value in the watchdog data
structure. If the configured timeout exceeds the maximum hardware timeout,
the watchdog core enables a timer function to assist sending keepalive
requests to the watchdog driver.

Cc: Timo Kokkonen 
Cc: Uwe Kleine-König 
Signed-off-by: Guenter Roeck 
---
v2:
- Improved and hopefully clarified documentation.
- Rearranged variables in struct watchdog_device such that internal variables
   come last.
- The code now ensures that the watchdog times out  seconds after
   the most recent keepalive sent from user space.
- The internal keepalive now stops silently and no longer generates a
   warning message. Reason is that it will now stop early, while there
   may still be a substantial amount of time for keepalives from user space
   to arrive. If such keepalives arrive late (for example if user space
   is configured to send keepalives just a few seconds before the watchdog
   times out), the message would just be noise and not provide any value.
---
  Documentation/watchdog/watchdog-kernel-api.txt |  23 +++-
  drivers/watchdog/watchdog_dev.c| 140 ++---
  include/linux/watchdog.h   |  26 +++--
  3 files changed, 163 insertions(+), 26 deletions(-)

diff --git a/Documentation/watchdog/watchdog-kernel-api.txt 
b/Documentation/watchdog/watchdog-kernel-api.txt
index d8b0d3367706..25b00b878a7b 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -53,9 +53,12 @@ struct watchdog_device {
unsigned int timeout;
unsigned int min_timeout;
unsigned int max_timeout;
+   unsigned int max_hw_timeout_ms;
void *driver_data;
-   struct mutex lock;
unsigned long status;
+   struct mutex lock;
+   unsigned long last_keepalive;
+   struct delayed_work work;
struct list_head deferred;
  };

@@ -73,18 +76,28 @@ It contains following fields:
additional information about the watchdog timer itself. (Like it's unique 
name)
  * ops: a pointer to the list of watchdog operations that the watchdog 
supports.
  * timeout: the watchdog timer's timeout value (in seconds).
+  This is the time after which the system will reboot if user space does
+  not send a heartbeat request if WDOG_ACTIVE is set.
  * min_timeout: the watchdog timer's minimum timeout value (in seconds).
  * max_timeout: the watchdog timer's maximum timeout value (in seconds).
+* max_hw_timeout_ms: Maximum hardware timeout, in milli-seconds. May differ
+  from max_timeout. If set to a value larger than max_timeout, the
+  infrastructure will send a heartbeat to the watchdog driver if 'timeout'
+  is larger than 'max_hw_timeout / 2', unless WDOG_ACTIVE is set and user
+  space failed to send a heartbeat for at least 'timeout' seconds.

To properly understand this it would be necessary to know what
max_timeout is. Maybe clearify that, too?



I think I found a better solution: Declare that max_timeout won't be used
if max_hw_timeout_ms is provided. This also simplifies the code a lot.


  * bootstatus: status of the device after booting (reported with watchdog
WDIOF_* status bits).
  * driver_data: a pointer to the drivers private data of a watchdog device.
This data should only be accessed via the watchdog_set_drvdata and
watchdog_get_drvdata routines.
-* lock: Mutex for WatchDog Timer Driver Core internal use only.
  * status: this field contains a number of status bits that give extra
information about the status of the device (Like: is the watchdog timer
running/active, is the nowayout bit set, is the device opened via
the /dev/watchdog interface or not, ...).
+* lock: Mutex for WatchDog Timer Driver Core internal use only.
+* last_keepalive: Time of most recent keepalive triggered from user space,
+  in jiffies.
+* work: Worker data structure for WatchDog Timer Driver Core internal use only.
  * deferred: entry in wtd_deferred_reg_list which is used to
register early initialized watchdogs.

@@ -160,7 +173,11 @@ they are supported. These optional routines/operations are:
and -EIO for "could not write value to the watchdog". On success this
routine should set the timeout value of the watchdog_device to the
achieved timeout value (which may be different from the requested one
-  because the watchdog does not necessarily has a 1 second resolution).
+  because the watchdog does not necessarily have a 1 second resolution).
+  Drivers implementing hw_max_timeout_ms set the hardware watchdog timeout
+  to the minimum of timeout and hw_max_timeout_ms. Those drivers set the
+  timeout value of the watchdog_device 

Re: [PATCH] Staging: vt6655: rf: fix C99 // comments coding style error

[Raphaël Beamonte]

> This doesn't apply to my staging-next branch of staging-git :(
>
> Please rebase and resend.

Seems it already has been fixed in your staging-git!
I switched to this git for future changes. (was using the linux.git)

Thanks!
Raphaël
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] iio: magnetometer: add mmc34160 magnetometer driver

[Jonathan Cameron]

On 15/08/15 21:47, Jonathan Cameron wrote:
> On 02/08/15 17:43, Jonathan Cameron wrote:
>> On 02/08/15 17:40, Jonathan Cameron wrote:
>>> On 31/07/15 15:27, Teodora Baluta wrote:
 This patch adds support for the MMC34160 3-axis magnetometer driver. The
 MMC31460 magnetometer driver uses the same register map as MMC35240 with
 different specifications for sensitivity.

 According to Memsic specification, for the MMC31460 sensor, there is no
 need to apply compensation to the read values. Also, the MMC34160 sensor
 does not use the same formula as MMC35240 for transforming raw data into
 mgauss, and the current formula is based on the input driver (mmc3416x)
 provided by Memsic.

 Signed-off-by: Teodora Baluta 
>>> Couple of comments inline.
>>>
>>> Applied to the togreg branch of iio.git - initially pushed out as testing
>>> for the autobuilders to play with it.
>>>
>> oops, didn't check it had actually applied cleanly.  Right now it doesn't.
>> Perhaps connected to various fixes working there way through.  I'll hold
>> this patch back for now on the basis it'll probably work itself out
>> as they hit the togreg branch (hopefully later this week).
>>
>> Jonathan
> 
> Applied to the togreg branch of iio.git (with some fuzz).
Spoke too soon.  The result doesn't build (id undefined at line 414).  Could
you rebase and send me an updated version against my testing branch?

Thanks,

Jonathan
> 
> Thanks,
> 
> Jonathan
>>> Thanks,
>>>
>>> Jonathan
 ---
  drivers/iio/magnetometer/Kconfig|   5 +-
  drivers/iio/magnetometer/mmc35240.c | 203 
 
  2 files changed, 161 insertions(+), 47 deletions(-)

 diff --git a/drivers/iio/magnetometer/Kconfig 
 b/drivers/iio/magnetometer/Kconfig
 index dcadfc4..baf59d9 100644
 --- a/drivers/iio/magnetometer/Kconfig
 +++ b/drivers/iio/magnetometer/Kconfig
 @@ -52,8 +52,9 @@ config MMC35240
select REGMAP_I2C
depends on I2C
help
 -Say yes here to build support for the MEMSIC MMC35240 3-axis
 -magnetic sensor.
 +Say yes here to build support for the MEMSIC MMC35240 3-axis magnetic
 +sensor. This driver also adds support for the MEMSIC MMC34160 3-axis 
 magnetic
 +sensor.
>>> Sometimes I wonder if we should have a standard form for multi device 
>>> supporting
>>> driver Kconfig help text.  This one seems rather unwieldy!  Anyhow we don't
>>> so until we do it can be like this.
  
  To compile this driver as a module, choose M here: the module
  will be called mmc35240.
 diff --git a/drivers/iio/magnetometer/mmc35240.c 
 b/drivers/iio/magnetometer/mmc35240.c
 index a4259bf..7a5921b 100644
 --- a/drivers/iio/magnetometer/mmc35240.c
 +++ b/drivers/iio/magnetometer/mmc35240.c
 @@ -83,6 +83,20 @@
  
  #define MMC35240_OTP_START_ADDR   0x1B
  
 +#define MMC35240_CHIP_ID  0x08
 +#define MMC34160_CHIP_ID  0x06
 +
 +enum mmc35240_chipset {
 +  MMC35240,
 +  MMC34160,
 +  MMC_MAX_CHIPS
 +};
 +
 +static u8 chip_ids[MMC_MAX_CHIPS] = {
 +  MMC35240_CHIP_ID,
 +  MMC34160_CHIP_ID,
 +};
 +
  enum mmc35240_resolution {
MMC35240_16_BITS_SLOW = 0, /* 7.92 ms */
MMC35240_16_BITS_FAST, /* 4.08 ms */
 @@ -99,27 +113,53 @@ enum mmc35240_axis {
  static const struct {
int sens[3]; /* sensitivity per X, Y, Z axis */
int nfo; /* null field output */
 -} mmc35240_props_table[] = {
 -  /* 16 bits, 125Hz ODR */
 -  {
 -  {1024, 1024, 1024},
 -  32768,
 -  },
 -  /* 16 bits, 250Hz ODR */
 -  {
 -  {1024, 1024, 770},
 -  32768,
 -  },
 -  /* 14 bits, 450Hz ODR */
 +} mmc35240_props_table[MMC_MAX_CHIPS][4] = {
 +  /* MMC35240 */
{
 -  {256, 256, 193},
 -  8192,
 +  /* 16 bits, 125Hz ODR */
 +  {
 +  {1024, 1024, 1024},
 +  32768,
 +  },
 +  /* 16 bits, 250Hz ODR */
 +  {
 +  {1024, 1024, 770},
 +  32768,
 +  },
 +  /* 14 bits, 450Hz ODR */
 +  {
 +  {256, 256, 193},
 +  8192,
 +  },
 +  /* 12 bits, 800Hz ODR */
 +  {
 +  {64, 64, 48},
 +  2048,
 +  },
},
 -  /* 12 bits, 800Hz ODR */
 +  /* MMC34160 */
{
 -  {64, 64, 48},
 -  2048,
 -  },
 +  /* 16 bits, 125Hz ODR */
 +  {
 +  {2048, 2048, 2048},
 +  32768,
 +  },
 +  /* 16 bits, 250Hz ODR */
 +  {
 +  {2048, 2048, 2048},

Re: [PATCH v3 2/2] iio: magnetometer: add mmc34160 magnetometer driver

[Jonathan Cameron]

On 02/08/15 17:43, Jonathan Cameron wrote:
> On 02/08/15 17:40, Jonathan Cameron wrote:
>> On 31/07/15 15:27, Teodora Baluta wrote:
>>> This patch adds support for the MMC34160 3-axis magnetometer driver. The
>>> MMC31460 magnetometer driver uses the same register map as MMC35240 with
>>> different specifications for sensitivity.
>>>
>>> According to Memsic specification, for the MMC31460 sensor, there is no
>>> need to apply compensation to the read values. Also, the MMC34160 sensor
>>> does not use the same formula as MMC35240 for transforming raw data into
>>> mgauss, and the current formula is based on the input driver (mmc3416x)
>>> provided by Memsic.
>>>
>>> Signed-off-by: Teodora Baluta 
>> Couple of comments inline.
>>
>> Applied to the togreg branch of iio.git - initially pushed out as testing
>> for the autobuilders to play with it.
>>
> oops, didn't check it had actually applied cleanly.  Right now it doesn't.
> Perhaps connected to various fixes working there way through.  I'll hold
> this patch back for now on the basis it'll probably work itself out
> as they hit the togreg branch (hopefully later this week).
> 
> Jonathan

Applied to the togreg branch of iio.git (with some fuzz).

Thanks,

Jonathan
>> Thanks,
>>
>> Jonathan
>>> ---
>>>  drivers/iio/magnetometer/Kconfig|   5 +-
>>>  drivers/iio/magnetometer/mmc35240.c | 203 
>>> 
>>>  2 files changed, 161 insertions(+), 47 deletions(-)
>>>
>>> diff --git a/drivers/iio/magnetometer/Kconfig 
>>> b/drivers/iio/magnetometer/Kconfig
>>> index dcadfc4..baf59d9 100644
>>> --- a/drivers/iio/magnetometer/Kconfig
>>> +++ b/drivers/iio/magnetometer/Kconfig
>>> @@ -52,8 +52,9 @@ config MMC35240
>>> select REGMAP_I2C
>>> depends on I2C
>>> help
>>> - Say yes here to build support for the MEMSIC MMC35240 3-axis
>>> - magnetic sensor.
>>> + Say yes here to build support for the MEMSIC MMC35240 3-axis magnetic
>>> + sensor. This driver also adds support for the MEMSIC MMC34160 3-axis 
>>> magnetic
>>> + sensor.
>> Sometimes I wonder if we should have a standard form for multi device 
>> supporting
>> driver Kconfig help text.  This one seems rather unwieldy!  Anyhow we don't
>> so until we do it can be like this.
>>>  
>>>   To compile this driver as a module, choose M here: the module
>>>   will be called mmc35240.
>>> diff --git a/drivers/iio/magnetometer/mmc35240.c 
>>> b/drivers/iio/magnetometer/mmc35240.c
>>> index a4259bf..7a5921b 100644
>>> --- a/drivers/iio/magnetometer/mmc35240.c
>>> +++ b/drivers/iio/magnetometer/mmc35240.c
>>> @@ -83,6 +83,20 @@
>>>  
>>>  #define MMC35240_OTP_START_ADDR0x1B
>>>  
>>> +#define MMC35240_CHIP_ID   0x08
>>> +#define MMC34160_CHIP_ID   0x06
>>> +
>>> +enum mmc35240_chipset {
>>> +   MMC35240,
>>> +   MMC34160,
>>> +   MMC_MAX_CHIPS
>>> +};
>>> +
>>> +static u8 chip_ids[MMC_MAX_CHIPS] = {
>>> +   MMC35240_CHIP_ID,
>>> +   MMC34160_CHIP_ID,
>>> +};
>>> +
>>>  enum mmc35240_resolution {
>>> MMC35240_16_BITS_SLOW = 0, /* 7.92 ms */
>>> MMC35240_16_BITS_FAST, /* 4.08 ms */
>>> @@ -99,27 +113,53 @@ enum mmc35240_axis {
>>>  static const struct {
>>> int sens[3]; /* sensitivity per X, Y, Z axis */
>>> int nfo; /* null field output */
>>> -} mmc35240_props_table[] = {
>>> -   /* 16 bits, 125Hz ODR */
>>> -   {
>>> -   {1024, 1024, 1024},
>>> -   32768,
>>> -   },
>>> -   /* 16 bits, 250Hz ODR */
>>> -   {
>>> -   {1024, 1024, 770},
>>> -   32768,
>>> -   },
>>> -   /* 14 bits, 450Hz ODR */
>>> +} mmc35240_props_table[MMC_MAX_CHIPS][4] = {
>>> +   /* MMC35240 */
>>> {
>>> -   {256, 256, 193},
>>> -   8192,
>>> +   /* 16 bits, 125Hz ODR */
>>> +   {
>>> +   {1024, 1024, 1024},
>>> +   32768,
>>> +   },
>>> +   /* 16 bits, 250Hz ODR */
>>> +   {
>>> +   {1024, 1024, 770},
>>> +   32768,
>>> +   },
>>> +   /* 14 bits, 450Hz ODR */
>>> +   {
>>> +   {256, 256, 193},
>>> +   8192,
>>> +   },
>>> +   /* 12 bits, 800Hz ODR */
>>> +   {
>>> +   {64, 64, 48},
>>> +   2048,
>>> +   },
>>> },
>>> -   /* 12 bits, 800Hz ODR */
>>> +   /* MMC34160 */
>>> {
>>> -   {64, 64, 48},
>>> -   2048,
>>> -   },
>>> +   /* 16 bits, 125Hz ODR */
>>> +   {
>>> +   {2048, 2048, 2048},
>>> +   32768,
>>> +   },
>>> +   /* 16 bits, 250Hz ODR */
>>> +   {
>>> +   {2048, 2048, 2048},
>>> +   32768,
>>> +   },
>>> +   /* 14 bits, 450Hz ODR */
>>> +   {
>>> +   {512, 512, 512},
>>> +   8192,
>>> +   },
>>> +   /* 12 bits, 800Hz ODR */
>>> +   {
>>> +   

Re: [PATCH] spi: Mediatek: fixup cpu_to_le32 incorrect usage

[Arnd Bergmann]

On Thursday 13 August 2015 20:06:41 Leilk Liu wrote:
> diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
> index ae645fa..519f50c 100644
> --- a/drivers/spi/spi-mt65xx.c
> +++ b/drivers/spi/spi-mt65xx.c
> @@ -359,11 +359,9 @@ static void mtk_spi_setup_dma_addr(struct spi_master 
> *master,
> struct mtk_spi *mdata = spi_master_get_devdata(master);
>  
> if (mdata->tx_sgl)
> -   writel((__force u32)cpu_to_le32(xfer->tx_dma),
> -  mdata->base + SPI_TX_SRC_REG);
> +   writel(xfer->tx_dma, mdata->base + SPI_TX_SRC_REG);
> if (mdata->rx_sgl)
> -   writel((__force u32)cpu_to_le32(xfer->rx_dma),
> -  mdata->base + SPI_RX_DST_REG);
> +   writel(xfer->rx_dma, mdata->base + SPI_RX_DST_REG);
>  }
>  
>  static int mtk_spi_fifo_transfer(struct spi_master *master,
> -- 
> 

This change looks good, but after I've briefly looked at the current driver,
I found at least one more location that looks like an endianess bug:


+static int mtk_spi_fifo_transfer(struct spi_master *master,
+struct spi_device *spi,
+struct spi_transfer *xfer)
+{
...
+
+   for (i = 0; i < cnt; i++)
+   writel(*((u32 *)xfer->tx_buf + i),
+  mdata->base + SPI_TX_DATA_REG);
+
+   mtk_spi_enable_transfer(master);
+
+   return 1;
+}

Here, you write data into a FIFO register using an accessor that converts
to little-endian. In contrast, the DMA based accessor apparently has
no byte swap, so most likely one of the two is broken on big-endian
systems. My guess is that the look above is wrong, and you need to
use iowrite32_rep() instead, so you always write into the FIFO in
the byte stream order (first byte to last byte) rather than swapping
32-bit entities.

The other suspicious part is this:

+   reg_val |= (chip_config->tx_endian << SPI_CMD_TX_ENDIAN_OFFSET);
+   reg_val |= (chip_config->rx_endian << SPI_CMD_RX_ENDIAN_OFFSET);

It's not clear what the tx_endian/rx_endian bits refer to and why you
can't just always set the register interface to little-endian. If it's
set to big-endian, you probably need to add more byte swaps in the
driver.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/19] staging: iio: Remove unnecessary externs

[Jonathan Cameron]

On 15/08/15 21:05, Lars-Peter Clausen wrote:
> On 08/15/2015 09:57 PM, Jonathan Cameron wrote:
>> On 11/08/15 19:43, Lars-Peter Clausen wrote:
>>> On 08/10/2015 11:51 PM, Joe Perches wrote:
 Using 'extern' is not necessary for function prototypes.

 Signed-off-by: Joe Perches 
>>>
>>> Acked-by: Lars-Peter Clausen 
>>>
>> Applied to the togreg branch of iio.git.  4.4 material now
>> probably.
> 
> Greg already picked the patch up earlier today on his own.
Thanks,
Dropped it from my branch as hadn't pushed out yet.

Jonathan
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] iio: adc: vf610: Add IIO buffer support for Vybrid ADC

[Jonathan Cameron]

On 11/08/15 10:05, Sanchayan Maity wrote:
> This patch adds support for IIO buffer to the Vybrid ADC driver.
> IIO triggered buffer infrastructure along with iio sysfs trigger
> is used to leverage continuous sampling support provided by the
> ADC block.
> 
> Signed-off-by: Sanchayan Maity 
Hi Sanchayan,

Very nearly there. One little point to do with the buffer handling.
Basically I don't think you want anything in the preenable or
postdisable hooks, just in the 'internal' ones.

Jonathan
> ---
>  drivers/iio/adc/Kconfig |   2 +
>  drivers/iio/adc/vf610_adc.c | 102 
> +---
>  2 files changed, 97 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 7c55658..660f790 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -337,6 +337,8 @@ config TWL6030_GPADC
>  config VF610_ADC
>   tristate "Freescale vf610 ADC driver"
>   depends on OF
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
>   help
> Say yes here to support for Vybrid board analog-to-digital converter.
> Since the IP is used for i.MX6SLX, the driver also support i.MX6SLX.
> diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
> index 23b8fb9..de62c48 100644
> --- a/drivers/iio/adc/vf610_adc.c
> +++ b/drivers/iio/adc/vf610_adc.c
> @@ -34,8 +34,11 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
> -#include 
> +#include 
> +#include 
> +#include 
>  
>  /* This will be the driver name the kernel reports */
>  #define DRIVER_NAME "vf610-adc"
> @@ -170,6 +173,7 @@ struct vf610_adc {
>   u32 sample_freq_avail[5];
>  
>   struct completion completion;
> + u16 buffer[8];
>  };
>  
>  static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
> @@ -505,12 +509,24 @@ static const struct iio_chan_spec_ext_info 
> vf610_ext_info[] = {
>   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE) |  \
>   BIT(IIO_CHAN_INFO_SAMP_FREQ),   \
>   .ext_info = vf610_ext_info, \
> + .scan_index = (_idx),   \
> + .scan_type = {  \
> + .sign = 'u',\
> + .realbits = 12, \
> + .storagebits = 16,  \
> + },  \
>  }
>  
>  #define VF610_ADC_TEMPERATURE_CHAN(_idx, _chan_type) {   \
>   .type = (_chan_type),   \
>   .channel = (_idx),  \
>   .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
> + .scan_index = (_idx),   \
> + .scan_type = {  \
> + .sign = 'u',\
> + .realbits = 12, \
> + .storagebits = 16,  \
> + },  \
>  }
>  
>  static const struct iio_chan_spec vf610_adc_iio_channels[] = {
> @@ -531,6 +547,7 @@ static const struct iio_chan_spec 
> vf610_adc_iio_channels[] = {
>   VF610_ADC_CHAN(14, IIO_VOLTAGE),
>   VF610_ADC_CHAN(15, IIO_VOLTAGE),
>   VF610_ADC_TEMPERATURE_CHAN(26, IIO_TEMP),
> + IIO_CHAN_SOFT_TIMESTAMP(32),
>   /* sentinel */
>  };
>  
> @@ -559,13 +576,20 @@ static int vf610_adc_read_data(struct vf610_adc *info)
>  
>  static irqreturn_t vf610_adc_isr(int irq, void *dev_id)
>  {
> - struct vf610_adc *info = (struct vf610_adc *)dev_id;
> + struct iio_dev *indio_dev = (struct iio_dev *)dev_id;
> + struct vf610_adc *info = iio_priv(indio_dev);
>   int coco;
>  
>   coco = readl(info->regs + VF610_REG_ADC_HS);
>   if (coco & VF610_ADC_HS_COCO0) {
>   info->value = vf610_adc_read_data(info);
> - complete(>completion);
> + if (iio_buffer_enabled(indio_dev)) {
> + info->buffer[0] = info->value;
> + iio_push_to_buffers_with_timestamp(indio_dev,
> + info->buffer, iio_get_time_ns());
> + iio_trigger_notify_done(indio_dev->trig);
> + } else
> + complete(>completion);
>   }
>  
>   return IRQ_HANDLED;
> @@ -613,8 +637,12 @@ static int vf610_read_raw(struct iio_dev *indio_dev,
>   case IIO_CHAN_INFO_RAW:
>   case IIO_CHAN_INFO_PROCESSED:
>   mutex_lock(_dev->mlock);
> - reinit_completion(>completion);
> + if (iio_buffer_enabled(indio_dev)) {
> + mutex_unlock(_dev->mlock);
> + return -EBUSY;
> + }
>  
> + reinit_completion(>completion);
>   hc_cfg = VF610_ADC_ADCHC(chan->channel);
>   hc_cfg |= VF610_ADC_AIEN;
>   writel(hc_cfg, info->regs + 

Re: [PATCH] driver/i2c/mux: Add register based mux i2c-mux-reg

[Wolfram Sang]

On Tue, Jun 16, 2015 at 10:28:12AM -0700, York Sun wrote:
> Based on i2c-mux-gpio driver, similarly the register based mux
> switch from one bus to another by setting a single register.
> The register can be on PCIe bus, local bus, or any memory-mapped
> address.
> 
> Signed-off-by: York Sun 
> CC: Wolfram Sang 
> CC: Peter Korsgaard 

Mostly good.

> +static int i2c_mux_reg_probe(struct platform_device *pdev)
> +{
> + struct regmux *mux;
> + struct i2c_adapter *parent;
> + struct resource *res;
> + int (*deselect)(struct i2c_adapter *, void *, u32);
> + unsigned int initial_state, class;

gcc says:

drivers/i2c/muxes/i2c-mux-reg.c:182:15: warning: variable 'initial_state' set 
but not used [-Wunused-but-set-variable]

It seens you prepared for setting the initial state but don't do the
actual set?

> +static struct platform_driver i2c_mux_reg_driver = {
> + .probe  = i2c_mux_reg_probe,
> + .remove = i2c_mux_reg_remove,
> + .driver = {
> + .owner  = THIS_MODULE,

coccicheck says:

drivers/i2c/muxes/i2c-mux-reg.c:288:3-8: No need to set .owner here. The core 
will do it.

> + .name   = "i2c-mux-reg",
> + },
> +};

Thanks,

   Wolfram

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels

[Wolfram Sang]

On Fri, Aug 14, 2015 at 12:31:32PM -0700, Dustin Byford wrote:
> 
> (v2 corrects cc: list)

And adding Mika to the cc-list who is our I2C and ACPI expert.
Mika can you have a look at this and the other patches Dustin sent
recently to the i2c list?

Thanks,

   Wolfram

> 
> I would like to add support for scanning I2C devices connected to ACPI
> OF compatible muxes described in ASL like this:
> 
> Device (MUX0)
> {
> Name (_ADR, 0x70)
> Name (_HID, "PRP0001")
> Name (_CRS, ResourceTemplate()
> {
> I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
>   AddressingMode7Bit, "^^SMB2", 0x00,
>   ResourceConsumer,,)
> })
> Name (_DSD, Package ()
> {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package (2) { "compatible", "nxp,pca9548" },
> }
> })
> 
> // MUX channels
> Device (CH00) { Name (_ADR, 0x0) }
> }
> 
> Scope(MUX0.CH00)
> {
> Device (TMP0) {
> /* Temp sensor ASL, for example. */
> }
> }
> 
> It seems like a reasonable way to describe a common I2C component and
> kernel support is almost there.
> 
> I had to:
> 
> 1) Find and set an ACPI companion for the "virtual" I2C adapters created
>for each mux channel.
> 
> 2) Make sure to scan adap.dev when registering devices under each mux
>channel.
> 
> At first, I was confused about why adap.dev->parent is used in
> acpi_i2c_register_devices().  I found b34bb1ee from 4/2013 (ACPI / I2C:
> Use parent's ACPI_HANDLE()), which offers an explanation.
> 
> This patch works well, but I'm not sure about the code to just fall back
> to using adap.dev when adap.dev->parent doesn't have an ACPI companion.
> Is there a more explicit check I can make to determine if the adapter
> represents a mux channel?
> 
> Any feedback would be welcome.  Thanks,
> 
>--Dustin
> 
> Dustin Byford (1):
>   i2c: acpi: scan ACPI enumerated I2C mux channels
> 
>  drivers/i2c/i2c-core.c | 10 ++
>  drivers/i2c/i2c-mux.c  |  8 
>  2 files changed, 18 insertions(+)
> 
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] spi: Mediatek: fix endian warnings

[Arnd Bergmann]

On Saturday 15 August 2015 22:16:03 Arnd Bergmann wrote:
> On Tuesday 11 August 2015 18:43:09 Leilk Liu wrote:
> > @@ -359,9 +359,11 @@ static void mtk_spi_setup_dma_addr(struct spi_master 
> > *master,
> > struct mtk_spi *mdata = spi_master_get_devdata(master);
> >  
> > if (mdata->tx_sgl)
> > -   writel(cpu_to_le32(xfer->tx_dma), mdata->base + 
> > SPI_TX_SRC_REG);
> > +   writel((__force u32)cpu_to_le32(xfer->tx_dma),
> > +  mdata->base + SPI_TX_SRC_REG);
> > if (mdata->rx_sgl)
> > -   writel(cpu_to_le32(xfer->rx_dma), mdata->base + 
> > SPI_RX_DST_REG);
> > +   writel((__force u32)cpu_to_le32(xfer->rx_dma),
> > +  mdata->base + SPI_RX_DST_REG);
> >  }
> > 
> 
> This looks wrong: writel takes a CPU-endian argument, so the value returned
> from cpu_to_le32() is not appropriate.
> 
> The warning is correct, and you have to remove the cpu_to_le32() conversion
> in order to get the driver to behave correctly when the kernel is built
> as big-endian.

Nevermind, I now saw the issue has already been raised.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] spi: Mediatek: fix endian warnings

[Arnd Bergmann]

On Tuesday 11 August 2015 18:43:09 Leilk Liu wrote:
> @@ -359,9 +359,11 @@ static void mtk_spi_setup_dma_addr(struct spi_master 
> *master,
> struct mtk_spi *mdata = spi_master_get_devdata(master);
>  
> if (mdata->tx_sgl)
> -   writel(cpu_to_le32(xfer->tx_dma), mdata->base + 
> SPI_TX_SRC_REG);
> +   writel((__force u32)cpu_to_le32(xfer->tx_dma),
> +  mdata->base + SPI_TX_SRC_REG);
> if (mdata->rx_sgl)
> -   writel(cpu_to_le32(xfer->rx_dma), mdata->base + 
> SPI_RX_DST_REG);
> +   writel((__force u32)cpu_to_le32(xfer->rx_dma),
> +  mdata->base + SPI_RX_DST_REG);
>  }
> 

This looks wrong: writel takes a CPU-endian argument, so the value returned
from cpu_to_le32() is not appropriate.

The warning is correct, and you have to remove the cpu_to_le32() conversion
in order to get the driver to behave correctly when the kernel is built
as big-endian.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fs: out of bounds on stack in iov_iter_advance

[Chuck Ebbert]

On Wed, 12 Aug 2015 10:13:24 -0400
Sasha Levin  wrote:

> While fuzzing with trinity inside a KVM tools guest running -next I've 
> stumbled on the following:
> 
> [64092.216447] 
> ==
> [64092.217840] BUG: KASan: out of bounds on stack in 
> iov_iter_advance+0x3b7/0x480 at addr 88040506fd48
> [64092.219314] Read of size 8 by task trinity-c194/11387
> [64092.220114] page:ea0010141bc0 count:0 mapcount:0 mapping:  
> (null) index:0x2
> [64092.221354] flags: 0x46f8000()
> [64092.221998] page dumped because: kasan: bad access detected
> [64092.222879] CPU: 4 PID: 11387 Comm: trinity-c194 Not tainted 
> 4.2.0-rc6-next-20150810-sasha-00040-g12ad0db3-dirty #2427
> [64092.224537]  88040506fd30 88040506fa88 9ce7763b 
> 88040506fb10
> [64092.225763]  88040506fb00 9376b1be  
> 880270108600
> [64092.226992]  0282   
> 
> [64092.228221] Call Trace:
> [64092.228679] dump_stack (lib/dump_stack.c:52)
> [64092.231252] kasan_report_error (mm/kasan/report.c:132 
> mm/kasan/report.c:193)
> [64092.232219] __asan_report_load8_noabort (mm/kasan/report.c:251)
> [64092.234167] iov_iter_advance (lib/iov_iter.c:511)
> [64092.235105] generic_file_read_iter (mm/filemap.c:1743)
> [64092.241532] blkdev_read_iter (fs/block_dev.c:1649)
> [64092.242448] __vfs_read (fs/read_write.c:423 fs/read_write.c:434)
> [64092.246949] vfs_read (fs/read_write.c:454)
> [64092.247743] SyS_pread64 (fs/read_write.c:607 fs/read_write.c:594)
> [64092.250445] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
> [64092.251440] Memory state around the buggy address:
> [64092.252221]  88040506fc00: 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f4 f4 
> f4 f3
> [64092.253340]  88040506fc80: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 
> 00 00
> [64092.254456] >88040506fd00: 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2 
> 00 00
> [64092.255566]   ^
> [64092.256432]  88040506fd80: 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 
> 00 f4
> [64092.257557]  88040506fe00: f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 
> 00 00
> [64092.258684] 
> ==
> 

I tried to debug this but kasan doesn't print much useful information
for stack out of bounds access. It shows the address that's being
accessed but it doesn't show the value of the boundary that was
exceeded. And the stack dump doesn't show any addresses either - just
contents. It would be nice to see a full stack frame dump showing
where all the parent frames are too. Also too the file and line number
(lib/iov_iter.c:511) are completely useless because of inlining,
though that's not kasan's fault.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 1/2] usb: make xhci platform driver use 64 bit or 32 bit DMA

[Arnd Bergmann]

On Saturday 08 August 2015 13:31:02 Duc Dang wrote:
> >
> > If we know that pdev->dev.dma_mask will always be initialised at this
> > point, then the above change is fine.  If not, it's introducing a
> > regression - dma_set_mask_and_coherent() will fail if pdev->dev.dma_mask
> > is NULL (depending on the architectures implementation of dma_set_mask()).
> >
> > Prefixing the above change with the two lines I mention above would
> > ensure equivalent behaviour.  Even if we do want to get rid of this,
> > I'd advise to do it as a separate patch after this change, which can
> > be independently reverted if there's problems with its removal.
> >
> Hi Russell,
> 
> I will add the 2 lines you mentioned back to next version of the
> patch. It is safer to do it that way as I do not see
> pdev->dev.dma_mask gets initialized before the call
> dma_set_mask_and_coherent  inside this xhci_plat.c file.

It would be good to add a WARN_ON() to the case where dma_mask
is a NULL pointer at the least. That way, we will at least
find out if there are some broken platforms that do not correctly
initialize the mask pointer.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/19] staging: iio: Remove unnecessary externs

[Lars-Peter Clausen]

On 08/15/2015 09:57 PM, Jonathan Cameron wrote:
> On 11/08/15 19:43, Lars-Peter Clausen wrote:
>> On 08/10/2015 11:51 PM, Joe Perches wrote:
>>> Using 'extern' is not necessary for function prototypes.
>>>
>>> Signed-off-by: Joe Perches 
>>
>> Acked-by: Lars-Peter Clausen 
>>
> Applied to the togreg branch of iio.git.  4.4 material now
> probably.

Greg already picked the patch up earlier today on his own.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Staging: iio: trigger: Use braces on both branches of if statement

[Jonathan Cameron]

On 11/08/15 11:20, Cristina Opriceana wrote:
> Fix style issue related to missing braces, detected by checkpatch.pl.
> 
> Signed-off-by: Cristina Opriceana 
Applied to the togreg branch of iio.git.

This one used to be left as optional, so there are a lot of these in older
code (and in IIO you don't get much older than this!)

For reference, it is going away the moment the high resolution timer
trigger is in as this support is emulated in all modern rtc drivers
anyway (was using actual hardware in the rtc when this driver was written).

Anyhow, even code with a short likely time to live can be well formatted!

Applied.

Jonathan
> ---
>  drivers/staging/iio/trigger/iio-trig-periodic-rtc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c 
> b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
> index a2a42c2..2db8857 100644
> --- a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
> +++ b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
> @@ -74,8 +74,9 @@ static ssize_t iio_trig_periodic_write_freq(struct device 
> *dev,
>   if (ret == 0 && trig_info->state && trig_info->frequency == 0)
>   ret = rtc_irq_set_state(trig_info->rtc,
>   _info->task, 1);
> - } else
> + } else {
>   ret = rtc_irq_set_state(trig_info->rtc, _info->task, 0);
> + }
>   if (ret)
>   goto error_ret;
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] Staging: iio: trigger: Alignment should match open parenthesis

[Jonathan Cameron]

On 11/08/15 11:18, Cristina Opriceana wrote:
> Fix alignment for function parameters as suggested by checkpatch.pl.
> 
> Signed-off-by: Cristina Opriceana 
Whilst I find it a little hard to care about tidying up in these two drivers,
we haven't explicitly noted they are both on their way out in the medium
term and it does no harm.

Applied to the togreg branch of iio.git

Thanks,

Jonathan
> ---
>  drivers/staging/iio/trigger/iio-trig-bfin-timer.c   | 7 ---
>  drivers/staging/iio/trigger/iio-trig-periodic-rtc.c | 2 +-
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/staging/iio/trigger/iio-trig-bfin-timer.c 
> b/drivers/staging/iio/trigger/iio-trig-bfin-timer.c
> index 3c1c8c6..9fe48ef 100644
> --- a/drivers/staging/iio/trigger/iio-trig-bfin-timer.c
> +++ b/drivers/staging/iio/trigger/iio-trig-bfin-timer.c
> @@ -79,7 +79,8 @@ static int iio_bfin_tmr_set_state(struct iio_trigger *trig, 
> bool state)
>  }
>  
>  static ssize_t iio_bfin_tmr_frequency_store(struct device *dev,
> - struct device_attribute *attr, const char *buf, size_t count)
> + struct device_attribute *attr,
> + const char *buf, size_t count)
>  {
>   struct iio_trigger *trig = to_iio_trigger(dev);
>   struct bfin_tmr_state *st = iio_trigger_get_drvdata(trig);
> @@ -116,8 +117,8 @@ static ssize_t iio_bfin_tmr_frequency_store(struct device 
> *dev,
>  }
>  
>  static ssize_t iio_bfin_tmr_frequency_show(struct device *dev,
> -  struct device_attribute *attr,
> -  char *buf)
> +struct device_attribute *attr,
> +char *buf)
>  {
>   struct iio_trigger *trig = to_iio_trigger(dev);
>   struct bfin_tmr_state *st = iio_trigger_get_drvdata(trig);
> diff --git a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c 
> b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
> index 0c1976d..a2a42c2 100644
> --- a/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
> +++ b/drivers/staging/iio/trigger/iio-trig-periodic-rtc.c
> @@ -37,7 +37,7 @@ static int iio_trig_periodic_rtc_set_state(struct 
> iio_trigger *trig, bool state)
>   if (trig_info->frequency == 0 && state)
>   return -EINVAL;
>   dev_dbg(_info->rtc->dev, "trigger frequency is %u\n",
> - trig_info->frequency);
> + trig_info->frequency);
>   ret = rtc_irq_set_state(trig_info->rtc, _info->task, state);
>   if (ret == 0)
>   trig_info->state = state;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/19] staging: iio: Remove unnecessary externs

[Jonathan Cameron]

On 11/08/15 19:43, Lars-Peter Clausen wrote:
> On 08/10/2015 11:51 PM, Joe Perches wrote:
>> Using 'extern' is not necessary for function prototypes.
>>
>> Signed-off-by: Joe Perches 
> 
> Acked-by: Lars-Peter Clausen 
> 
Applied to the togreg branch of iio.git.  4.4 material now
probably.

Thanks,

Jonathan
> Thanks.
> 
>> ---
>>  drivers/staging/iio/meter/ade7854.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/staging/iio/meter/ade7854.h 
>> b/drivers/staging/iio/meter/ade7854.h
>> index 52ca541..52f4195 100644
>> --- a/drivers/staging/iio/meter/ade7854.h
>> +++ b/drivers/staging/iio/meter/ade7854.h
>> @@ -168,7 +168,7 @@ struct ade7854_state {
>>  
>>  };
>>  
>> -extern int ade7854_probe(struct iio_dev *indio_dev, struct device *dev);
>> -extern int ade7854_remove(struct iio_dev *indio_dev);
>> +int ade7854_probe(struct iio_dev *indio_dev, struct device *dev);
>> +int ade7854_remove(struct iio_dev *indio_dev);
>>  
>>  #endif
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4] iio: adc: xilinx-xadc: Push interrupts into hardirq context

[Jonathan Cameron]

On 12/08/15 17:33, Sebastian Andrzej Siewior wrote:
> On 08/12/2015 05:17 PM, Lars-Peter Clausen wrote:
>> On 08/12/2015 01:00 AM, Xander Huff wrote:
>>> Unfortunately, this breaks PREEMPT_RT builds, where a spinlock can sleep,
>>> and is thus not able to be acquired from a hardirq handler. This patch gets
>>> rid of the threaded handler and pushes all interrupt handling into the
>>> hardirq context, and uses request_irq().
>>>
>>> To validate that this change has no impact on RT performance, here are
>>> cyclictest values with no processes running:
>>
>> Looks good, thanks.
>>
>> Acked-by: Lars-Peter Clausen 
> 
> Yes, I'm fine with the rework, too.
Formal Acked-by would be good but I'll take this on the basis of Lars' one
and that the code clearly should work from a read through.

Applied to the togreg branch of iio.git.  Thanks for following through
the various twists of this one. Will initially be pushed out as testing.
Note this has almost certainly (unless Linus announces a delay) missed the
upcoming merge window so will be lined up for the 4.4 one.

Jonathan
> 
> Sebastian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 38/46] sched: scheduler-driven cpu frequency selection

[Peter Zijlstra]

On Tue, Jul 07, 2015 at 07:24:21PM +0100, Morten Rasmussen wrote:
> diff --git a/kernel/sched/cpufreq_sched.c b/kernel/sched/cpufreq_sched.c
> new file mode 100644
> index 000..5020f24
> --- /dev/null
> +++ b/kernel/sched/cpufreq_sched.c
> @@ -0,0 +1,308 @@
> +/*
> + *  Copyright (C)  2015 Michael Turquette 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "sched.h"
> +
> +#define THROTTLE_NSEC5000 /* 50ms default */
> +
> +static DEFINE_PER_CPU(unsigned long, pcpu_capacity);
> +static DEFINE_PER_CPU(struct cpufreq_policy *, pcpu_policy);
> +
> +/**
> + * gov_data - per-policy data internal to the governor
> + * @throttle: next throttling period expiry. Derived from throttle_nsec
> + * @throttle_nsec: throttle period length in nanoseconds
> + * @task: worker thread for dvfs transition that may block/sleep
> + * @irq_work: callback used to wake up worker thread
> + * @freq: new frequency stored in *_sched_update_cpu and used in 
> *_sched_thread
> + *
> + * struct gov_data is the per-policy cpufreq_sched-specific data structure. A
> + * per-policy instance of it is created when the cpufreq_sched governor 
> receives
> + * the CPUFREQ_GOV_START condition and a pointer to it exists in the gov_data
> + * member of struct cpufreq_policy.
> + *
> + * Readers of this data must call down_read(policy->rwsem). Writers must
> + * call down_write(policy->rwsem).
> + */
> +struct gov_data {
> + ktime_t throttle;
> + unsigned int throttle_nsec;
> + struct task_struct *task;
> + struct irq_work irq_work;
> + struct cpufreq_policy *policy;
> + unsigned int freq;
> +};
> +
> +static void cpufreq_sched_try_driver_target(struct cpufreq_policy *policy, 
> unsigned int freq)
> +{
> + struct gov_data *gd = policy->governor_data;
> +
> + /* avoid race with cpufreq_sched_stop */
> + if (!down_write_trylock(>rwsem))
> + return;
> +
> + __cpufreq_driver_target(policy, freq, CPUFREQ_RELATION_L);
> +
> + gd->throttle = ktime_add_ns(ktime_get(), gd->throttle_nsec);
> + up_write(>rwsem);
> +}

That locking truly is disgusting.. why can't we change that?

> +static int cpufreq_sched_thread(void *data)
> +{

> +
> + ret = set_cpus_allowed_ptr(gd->task, policy->related_cpus);

That's not sufficient, you really want to have called kthread_bind() on
these threads, otherwise userspace can change affinity on you.

> +
> + do_exit(0);

I thought kthreads only needed to return...

> +}

> +void cpufreq_sched_set_cap(int cpu, unsigned long capacity)
> +{
> + unsigned int freq_new, cpu_tmp;
> + struct cpufreq_policy *policy;
> + struct gov_data *gd;
> + unsigned long capacity_max = 0;
> +
> + /* update per-cpu capacity request */
> + __this_cpu_write(pcpu_capacity, capacity);
> +
> + policy = cpufreq_cpu_get(cpu);

So this does a down_read_trylock(_rwsem) and a
read_lock_irqsave(_driver_lock), all while holding scheduler
locks.

> + if (cpufreq_driver_might_sleep())
> + irq_work_queue_on(>irq_work, cpu);
> + else
> + cpufreq_sched_try_driver_target(policy, freq_new);

This will then do a down_write_trylock(>rwsem)

> +
> +out:
> + cpufreq_cpu_put(policy);

> + return;
> +}

That is just insane... surely we can replace all that with a wee bit of
RCU logic.

So something like:

DEFINE_MUTEX(cpufreq_mutex);
struct cpufreq_driver *cpufreq_driver;

struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
{
struct cpufreq_driver *driver;
struct cpufreq_policy *policy;

rcu_read_lock();
driver = rcu_dereference(cpufreq_driver);
if (!driver)
goto err;

policy = per_cpu_ptr(driver->policy, cpu);
if (!policy)
goto err;

return policy;

err:
rcu_read_unlock();
return NULL;
}


void cpufreq_cpu_put(struct cpufreq_policy *policy)
{
rcu_read_unlock();
}



void cpufreq_set_driver(struct cpufreq_driver *driver)
{
mutex_lock(_mutex);

rcu_assign_pointer(cpufreq_driver, NULL);

/*
 * Wait for everyone to observe the lack of driver; iow. until
 * its unused.
 */
synchronize_rcu();

/*
 * Now that ye olde driver be gone, install a new one.
 */
if (driver)
rcu_assign_pointer(cpufreq_driver, driver);

mutex_unlock(_mutex);
}


No need for cpufreq_rwsem or cpufreq_driver_lock..


Hmm?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 40/46] sched/cpufreq_sched: compute freq_new based on capacity_orig_of()

[Peter Zijlstra]

On Tue, Jul 07, 2015 at 07:24:23PM +0100, Morten Rasmussen wrote:
> diff --git a/kernel/sched/cpufreq_sched.c b/kernel/sched/cpufreq_sched.c
> index 2968f3a..7071528 100644
> --- a/kernel/sched/cpufreq_sched.c
> +++ b/kernel/sched/cpufreq_sched.c
> @@ -184,7 +184,7 @@ void cpufreq_sched_set_cap(int cpu, unsigned long 
> capacity)
>   goto out;
>  
>   /* Convert the new maximum capacity request into a cpu frequency */
> - freq_new = capacity * policy->max >> SCHED_CAPACITY_SHIFT;
> + freq_new = (capacity * policy->max) / capacity_orig_of(cpu);
>  
>   /* No change in frequency? Bail and return current capacity. */
>   if (freq_new == policy->cur)

Can't we avoid exporting that lot by simply passing in the right values
to begin with?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 38/46] sched: scheduler-driven cpu frequency selection

[Peter Zijlstra]

On Tue, Jul 07, 2015 at 07:24:21PM +0100, Morten Rasmussen wrote:
> +void cpufreq_sched_set_cap(int cpu, unsigned long capacity)
> +{
> + unsigned int freq_new, cpu_tmp;
> + struct cpufreq_policy *policy;
> + struct gov_data *gd;
> + unsigned long capacity_max = 0;
> +
> + /* update per-cpu capacity request */
> + __this_cpu_write(pcpu_capacity, capacity);
> +
> + policy = cpufreq_cpu_get(cpu);
> + if (IS_ERR_OR_NULL(policy)) {
> + return;
> + }
> +
> + if (!policy->governor_data)
> + goto out;
> +
> + gd = policy->governor_data;
> +
> + /* bail early if we are throttled */
> + if (ktime_before(ktime_get(), gd->throttle))
> + goto out;

Isn't this the wrong place to throttle? Suppose you're getting multiple
new tasks placed on this CPU, the first one would trigger this callback
and start increasing freq..

While we're still changing freq. (and therefore throttled), another task
comes in which would again raise the freq.

With this scheme you loose the latter freq. change and will not
re-evaluate.

Any scheme that limits the callbacks to the actual hardware will have to
buffer requests and once the hardware returns (be it through an
interrupt or timeout) issue the latest request.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 41/46] sched/fair: add triggers for OPP change requests

[Peter Zijlstra]

So this OPP thing, I think that got mentioned once earlier in this patch
set, wth is that?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 36/46] sched: Prevent unnecessary active balance of single task in sched group

[Peter Zijlstra]

On Tue, Jul 07, 2015 at 07:24:19PM +0100, Morten Rasmussen wrote:
> Scenarios with the busiest group having just one task and the local
> being idle on topologies with sched groups with different numbers of
> cpus manage to dodge all load-balance bailout conditions resulting the
> nr_balance_failed counter to be incremented. This eventually causes an
> pointless active migration of the task. This patch prevents this by not
> incrementing the counter when the busiest group only has one task.
> ASYM_PACKING migrations and migrations due to reduced capacity should
> still take place as these are explicitly captured by
> need_active_balance().
> 
> A better solution would be to not attempt the load-balance in the first
> place, but that requires significant changes to the order of bailout
> conditions and statistics gathering.

*groan*, and this is of course triggered by your 2+3 core TC2 thingy.

Yes, asymmetric groups like that are a pain.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 34/46] sched: Enable idle balance to pull single task towards cpu with higher capacity

[Peter Zijlstra]

On Tue, Jul 07, 2015 at 07:24:17PM +0100, Morten Rasmussen wrote:
> +++ b/kernel/sched/fair.c
> @@ -7569,6 +7569,13 @@ static int need_active_balance(struct lb_env *env)
>   return 1;
>   }
>  
> + if ((capacity_of(env->src_cpu) < capacity_of(env->dst_cpu)) &&
> + env->src_rq->cfs.h_nr_running == 1 &&
> + cpu_overutilized(env->src_cpu) &&
> + !cpu_overutilized(env->dst_cpu)) {
> + return 1;
> + }
> +
>   return unlikely(sd->nr_balance_failed > sd->cache_nice_tries+2);
>  }

Doesn't this allow for a nice game of ping-pong? Where if a task runs on
CPU X and generates interrupts there, its capacity will lower and we'll
migrate it over to CPU Y because that isn't receiving interrupts.

Now the task is running on Y, will generate interrupts there, and sees X
as a more attractive destination.

goto 1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 35/46] sched: Disable energy-unfriendly nohz kicks

[Peter Zijlstra]

On Tue, Jul 07, 2015 at 07:24:18PM +0100, Morten Rasmussen wrote:
> With energy-aware scheduling enabled nohz_kick_needed() generates many
> nohz idle-balance kicks which lead to nothing when multiple tasks get
> packed on a single cpu to save energy. This causes unnecessary wake-ups
> and hence wastes energy. Make these conditions depend on !energy_aware()
> for now until the energy-aware nohz story gets sorted out.

The patch does slightly more; it also allows the kick if over utilized.

But disabling this will allow getting 'stuck' in certain over loaded
situations because we're not kicking the balancer.

I think you need more justification for doing this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFCv5 PATCH 39/46] sched/cpufreq_sched: use static key for cpu frequency selection

[Peter Zijlstra]

On Wed, Jul 08, 2015 at 08:19:56AM -0700, Michael Turquette wrote:
> > @@ -254,6 +267,7 @@ static int cpufreq_sched_stop(struct cpufreq_policy 
> > *policy)
> >  {
> > struct gov_data *gd = policy->governor_data;
> >  
> > +   clear_sched_energy_freq();
> 
> 
> 
> These controls are exposed to userspace via cpufreq sysfs knobs. Should
> we use a struct static_key_deferred and static_key_slow_dec_deferred()
> instead? This helps avoid a possible attack vector for slowing down the
> system.
> 
> 
> 
> I don't really know what a sane default rate limit would be in that case
> though.  Otherwise feel free to add:

Exposed through being able to change the policy, right? No other new
knobs, right?

IIRC the policy is only writable by root, in which case deferred isn't
really needed, root can kill the machine many other ways.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] staging: iio: hmc5843: Set iio name dynamically

[Jonathan Cameron]

On 12/08/15 16:21, Lars-Peter Clausen wrote:
> On 08/12/2015 03:25 PM, sdliy...@gmail.com wrote:
>> From: Yong Li 
>>
>> Load the driver using the below command:
>> echo hmc5983 0x1e > /sys/bus/i2c/devices/i2c-?/new_device
>>
>> In sysfs, the iio name is hmc5843, however the i2c name is hmc5983,
>> they are inconsistent.
>>
>> With this patch, the iio name will be the same as the i2c device name
>>
>> Signed-off-by: Yong Li 
> 
> Looks good.
> 
> Reviewed-by: Lars-Peter Clausen 
Applied to the togreg branch of iio.git - initially pushed out as testing
for the autobuilders to play with it.

Thanks,

Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm/memblock: check memblock_reserve on fail in memblock_virt_alloc_internal

[Alexander Kuleshov]

This patch adds a check for memblock_reserve() call in the
memblock_virt_alloc_internal() function, because memblock_reserve()
can return -errno on fail.

Signed-off-by: Alexander Kuleshov 
---
 mm/memblock.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 87108e7..73427546 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1298,7 +1298,9 @@ again:
 
return NULL;
 done:
-   memblock_reserve(alloc, size);
+   if (memblock_reserve(alloc, size))
+   return NULL;
+
ptr = phys_to_virt(alloc);
memset(ptr, 0, size);
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Mail

[Dr. Mohammad Saoud]

Dear Beneficiary,

This is to inform you that you were among the lucky beneficiary selected to 
receive this donations award sum of Eur950,000.00, as charity donations/aid 
from the Qatar Foundation held in Doha, Qatar,  to promote your business and 
personal Interest.

Kindly get back for more details on how to claims your award via email: (). On 
behalf of the foundation, we say congratulations to you.

Yours Sincerely, Dr. Mohammad Fathy Saoud.

Reply To: (qatafoundat...@aol.com)

President of Qatar Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] crypto: KEYS: convert public key to the akcipher API

[Stephan Mueller]

Am Mittwoch, 12. August 2015, 20:54:39 schrieb Tadeusz Struk:

Hi Tadeusz,

>@@ -41,7 +41,7 @@ struct pkcs7_parse_context {
> static void pkcs7_free_signed_info(struct pkcs7_signed_info *sinfo)
> {
>   if (sinfo) {
>-  mpi_free(sinfo->sig.mpi[0]);
>+  kfree(sinfo->sig.s);

kzfree?

>   kfree(sinfo->sig.digest);

kzfree?

>   kfree(sinfo->signing_cert_id);
>   kfree(sinfo);

kzfree (due to ->msdigest)?


Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/7] pmem, dax: have direct_access use __pmem annotation

[Dan Williams]

On Sat, Aug 15, 2015 at 9:00 AM, Christoph Hellwig  wrote:
> On Sat, Aug 15, 2015 at 08:44:27AM -0700, Dan Williams wrote:
>> That said, while we don't need special accessors we do need guarantees
>> that anything that has written to a persistent memory address has done
>> so in a way that wmb_pmem() is able to flush it.  It's more of a "I've
>> audited this code path for wmb_pmem() compatibility so use this api to
>> write to pmem."
>
> I'm more worried about things where don't just do plain loads and stores
> to a pmem region but DMA, which will end up as a nightmare of casts.
>
> But we can wait and see how that evolves in the end..

It's already not possible to do something like dma_map_single() on an
ioremap()'d address, so there currently are't any __iomem/DMA
collisions.  As long as DMA setup is relative to a physical address
resource I think we're ok.

Making sure a DMA is both complete and persistent though is a different problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] coccinelle: add style check for assignment in if

[Julia Lawall]

My version is below.  It adds parentheses in a few more places, and allows 
assignments without a binary operator (b) in the && cases.

Also I threw in a case for things like: if (ret = -ENOENT, !data)

Another thing is that the header is not really correct.  It should be in 
the following format:

/// Short comment of gernal interest
//# More information, eg about potential false positives
///
// Confidence: Moderate
// Copyright: whatever you want, it would be nice to have your name
// URL: http://coccinelle.lip6.fr/
// Comments:
// Options: --no-includes --include-headers

Then you should have:

virtual patch

Otherwise, the kernel infrastructure will not think that the patch mode is 
supported.  No other changes are needed, since no other modes are 
supported.  I don't think that supporting other modes is necessary, since 
I think that checkpatch complains about this issue too.

julia



// find checkpatch.pl errors of the type:
//  ERROR: do not use assignment in if condition
//
// This script is designed to correct code where assignments exist in if
// conditions. It is only capable of handling a subset of such problems.
//
// For example:
//
//  if(result = myfun())
//
// would become:
//
//  result = myfun();
//  if(result)
//
// Confidence: Moderate

// if ( (ret = call()) < 0 )
@if2@
expression i;
expression E, E2;
statement S1, S2;
binary operator b;
@@

+ i = E;
  if (
(
  ... b
- (i = E)
+ i
|
- (i = E)
+ i
  b ...
|
- (i = E)
+ i
|
- (i = E),
  E2
)
   ) S1 else S2

// if ( ptr->fun && (ret = ptr->fun()) < 0 )
@if3@
expression i2;
expression E1, E2;
constant c;
binary operator b;
@@

+ if( E1 ) {
+   i2 = E2;
+   if (i2 b c) {
- if( E1 && ((i2 = E2) b c) ) {
  ...
- }
+   }
+ }

// if ( (ret = call()) < 0 && ret != -1 )
@if4@
expression i;
expression E, E2;
statement S1, S2;
binary operator b;
@@

+ i = E;
  if (
(
  (...
  b
- (i = E)
+ i
  )
|
  (
- (i = E)
+ i
  b
  ...)
|
- (i = E)
+ i
) && E2 ) S1 else S2

// if ( (ret = call()) < 0 && ret != -1 && ret != -2 )
@if5@
expression i;
expression E, E2, E3;
statement S1, S2;
binary operator b;
@@

+ i = E;
  if (
(
  (...
  b
- (i = E)
+ i
  )
|
  (
- (i = E)
+ i
  b
  ...)
|
- (i = E)
+ i
) && E2 && E3 ) S1 else S2

@@
expression i,e;
statement S1,S2;
@@

if (<+... 
-i = e
+BAD
 ...+>) S1 else S2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] coccinelle: add style check for assignment in if

[Kris Borer]

I apologize, I misunderstood your email. It is the same as RFC v2.

On Sat, Aug 15, 2015 at 1:30 PM, Julia Lawall  wrote:
>
>
> On Sat, 15 Aug 2015, Kris Borer wrote:
>
>> Add a semantic patch for fixing some cases of checkpatch.pl error:
>>
>> ERROR: do not use assignment in if condition
>>
>> Reviewed-by: Julia Lawall 
>
> Sorry, but I'm not done reviewing it.  I have a lot of changes to propose.
> Is this different than the RFC v2?
>
> julia
>
>> Signed-off-by: Kris Borer 
>> ---
>>  scripts/coccinelle/style/assignment_in_if.cocci | 92 
>> +
>>  1 file changed, 92 insertions(+)
>>  create mode 100644 scripts/coccinelle/style/assignment_in_if.cocci
>>
>> diff --git a/scripts/coccinelle/style/assignment_in_if.cocci 
>> b/scripts/coccinelle/style/assignment_in_if.cocci
>> new file mode 100644
>> index 000..22ab161
>> --- /dev/null
>> +++ b/scripts/coccinelle/style/assignment_in_if.cocci
>> @@ -0,0 +1,92 @@
>> +// find checkpatch.pl errors of the type:
>> +//   ERROR: do not use assignment in if condition
>> +//
>> +// This script is designed to correct code where assignments exist in if
>> +// conditions. It is only capable of handling a subset of such problems.
>> +//
>> +// For example:
>> +//
>> +//   if(result = myfun())
>> +//
>> +// would become:
>> +//
>> +//   result = myfun();
>> +//   if(result)
>> +//
>> +// Confidence: Moderate
>> +
>> +
>> +// if ( ret = call() )
>> +@if1@
>> +identifier i;
>> +expression E;
>> +statement S1, S2;
>> +@@
>> +
>> ++ i = E;
>> +  if (
>> +- (i = E)
>> ++ i
>> +  ) S1 else S2
>> +
>> +
>> +// if ( (ret = call()) < 0 )
>> +@if2@
>> +identifier i;
>> +expression E;
>> +statement S1, S2;
>> +binary operator b;
>> +@@
>> +
>> ++ i = E;
>> +  if (
>> +- (i = E)
>> ++ i
>> +  b ... ) S1 else S2
>> +
>> +// if ( ptr->fun && (ret = ptr->fun()) < 0 )
>> +@if3@
>> +identifier i, i2;
>> +expression E1, E2;
>> +constant c;
>> +binary operator b;
>> +@@
>> +
>> ++ if( E1->i ) {
>> ++i2 = E2;
>> ++if (i2 b c) {
>> +- if( E1->i && ((i2 = E2) b c) ) {
>> +  ...
>> +- }
>> ++}
>> ++ }
>> +
>> +// if ( (ret = call()) < 0 && ret != -1 )
>> +@if4@
>> +identifier i;
>> +expression E, E2;
>> +statement S1, S2;
>> +binary operator b;
>> +@@
>> +
>> ++ i = E;
>> +  if (
>> +- (i = E)
>> ++ i
>> +  b
>> +  ... && E2 ) S1 else S2
>> +
>> +// if ( (ret = call()) < 0 && ret != -1 && ret != -2 )
>> +@if5@
>> +identifier i;
>> +expression E, E2, E3;
>> +statement S1, S2;
>> +binary operator b;
>> +@@
>> +
>> ++ i = E;
>> +  if (
>> +- (i = E)
>> ++ i
>> +  b
>> +  ... && E2 && E3 ) S1 else S2
>> --
>> 1.9.1
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] coccinelle: add style check for assignment in if

[Julia Lawall]

On Sat, 15 Aug 2015, Kris Borer wrote:

> Add a semantic patch for fixing some cases of checkpatch.pl error:
> 
> ERROR: do not use assignment in if condition
> 
> Reviewed-by: Julia Lawall 

Sorry, but I'm not done reviewing it.  I have a lot of changes to propose.  
Is this different than the RFC v2?

julia

> Signed-off-by: Kris Borer 
> ---
>  scripts/coccinelle/style/assignment_in_if.cocci | 92 
> +
>  1 file changed, 92 insertions(+)
>  create mode 100644 scripts/coccinelle/style/assignment_in_if.cocci
> 
> diff --git a/scripts/coccinelle/style/assignment_in_if.cocci 
> b/scripts/coccinelle/style/assignment_in_if.cocci
> new file mode 100644
> index 000..22ab161
> --- /dev/null
> +++ b/scripts/coccinelle/style/assignment_in_if.cocci
> @@ -0,0 +1,92 @@
> +// find checkpatch.pl errors of the type:
> +//   ERROR: do not use assignment in if condition
> +//
> +// This script is designed to correct code where assignments exist in if
> +// conditions. It is only capable of handling a subset of such problems.
> +//
> +// For example:
> +//
> +//   if(result = myfun())
> +//
> +// would become:
> +//
> +//   result = myfun();
> +//   if(result)
> +//
> +// Confidence: Moderate
> +
> +
> +// if ( ret = call() )
> +@if1@
> +identifier i;
> +expression E;
> +statement S1, S2;
> +@@
> +
> ++ i = E;
> +  if (
> +- (i = E)
> ++ i
> +  ) S1 else S2
> +
> +
> +// if ( (ret = call()) < 0 )
> +@if2@
> +identifier i;
> +expression E;
> +statement S1, S2;
> +binary operator b;
> +@@
> +
> ++ i = E;
> +  if (
> +- (i = E)
> ++ i
> +  b ... ) S1 else S2
> +
> +// if ( ptr->fun && (ret = ptr->fun()) < 0 )
> +@if3@
> +identifier i, i2;
> +expression E1, E2;
> +constant c;
> +binary operator b;
> +@@
> +
> ++ if( E1->i ) {
> ++i2 = E2;
> ++if (i2 b c) {
> +- if( E1->i && ((i2 = E2) b c) ) {
> +  ...
> +- }
> ++}
> ++ }
> +
> +// if ( (ret = call()) < 0 && ret != -1 )
> +@if4@
> +identifier i;
> +expression E, E2;
> +statement S1, S2;
> +binary operator b;
> +@@
> +
> ++ i = E;
> +  if (
> +- (i = E)
> ++ i
> +  b
> +  ... && E2 ) S1 else S2
> +
> +// if ( (ret = call()) < 0 && ret != -1 && ret != -2 )
> +@if5@
> +identifier i;
> +expression E, E2, E3;
> +statement S1, S2;
> +binary operator b;
> +@@
> +
> ++ i = E;
> +  if (
> +- (i = E)
> ++ i
> +  b
> +  ... && E2 && E3 ) S1 else S2
> -- 
> 1.9.1
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv3] serial: don't register CIR serial ports

[Maciej S. Szmigiero]

CIR type serial ports aren't real serial ports.

This is just a way to prevent legacy 8250 serial
driver from probing and eventually binding some
resources.

Since in current state such ports aren't providing
any real functionality and it is not possible
to change their type via setserial/ioctl(TIOCSSERIAL)
(due to UPF_FIXED_PORT flag set on them)
it is simpler and cleaner to not register them at all
with serial core.

Print a short message in this case so it is known
to user what has happened.

This way checks for PORT_8250_CIR in serial port
callbacks can be removed too, since they won't
ever be called.

Signed-off-by: Maciej Szmigiero 
---
This replaces "serial: don't announce CIR serial ports"
submission.

Changes from v1: print message using dev_info().

Changes from v2: added specific code in
serial8250_register_ports() regarding not adding
PORT_8250_CIR-type ports, updated to changes in
tty-testing branch.

 drivers/tty/serial/8250/8250_core.c | 26 --
 drivers/tty/serial/8250/8250_port.c | 14 +-
 2 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index cfbb9d7..2308ff8 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -569,6 +569,9 @@ serial8250_register_ports(struct uart_driver *drv, struct 
device *dev)
for (i = 0; i < nr_uarts; i++) {
struct uart_8250_port *up = _ports[i];
 
+   if (up->port.type == PORT_8250_CIR)
+   continue;
+
if (up->port.dev)
continue;
 
@@ -1027,13 +1030,24 @@ int serial8250_register_8250_port(struct uart_8250_port 
*up)
if (up->dl_write)
uart->dl_write = up->dl_write;
 
-   if (serial8250_isa_config != NULL)
-   serial8250_isa_config(0, >port,
-   >capabilities);
+   if (uart->port.type != PORT_8250_CIR) {
+   if (serial8250_isa_config != NULL)
+   serial8250_isa_config(0, >port,
+   >capabilities);
+
+   ret = uart_add_one_port(_reg,
+   >port);
+   if (ret == 0)
+   ret = uart->port.line;
+   } else {
+   dev_info(uart->port.dev,
+   "skipping CIR port at 0x%lx / 0x%llx, IRQ %d\n",
+   uart->port.iobase,
+   (unsigned long long)uart->port.mapbase,
+   uart->port.irq);
 
-   ret = uart_add_one_port(_reg, >port);
-   if (ret == 0)
-   ret = uart->port.line;
+   ret = 0;
+   }
}
mutex_unlock(_mutex);
 
diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 54e6c8d..138a36f 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -1799,9 +1799,6 @@ int serial8250_do_startup(struct uart_port *port)
unsigned char lsr, iir;
int retval;
 
-   if (port->type == PORT_8250_CIR)
-   return -ENODEV;
-
if (!port->fifosize)
port->fifosize = uart_config[port->type].fifo_size;
if (!up->tx_loadsz)
@@ -2505,14 +2502,8 @@ static void serial8250_release_port(struct uart_port 
*port)
 static int serial8250_request_port(struct uart_port *port)
 {
struct uart_8250_port *up = up_to_u8250p(port);
-   int ret;
-
-   if (port->type == PORT_8250_CIR)
-   return -ENODEV;
 
-   ret = serial8250_request_std_resource(up);
-
-   return ret;
+   return serial8250_request_std_resource(up);
 }
 
 static int fcr_get_rxtrig_bytes(struct uart_8250_port *up)
@@ -2660,9 +2651,6 @@ static void serial8250_config_port(struct uart_port 
*port, int flags)
struct uart_8250_port *up = up_to_u8250p(port);
int ret;
 
-   if (port->type == PORT_8250_CIR)
-   return;
-
/*
 * Find the region that we can probe for.  This in turn
 * tells us whether we can probe for the type of port.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] coccinelle: add style check for assignment in if

[Kris Borer]

Add a semantic patch for fixing some cases of checkpatch.pl error:

ERROR: do not use assignment in if condition

Reviewed-by: Julia Lawall 
Signed-off-by: Kris Borer 
---
 scripts/coccinelle/style/assignment_in_if.cocci | 92 +
 1 file changed, 92 insertions(+)
 create mode 100644 scripts/coccinelle/style/assignment_in_if.cocci

diff --git a/scripts/coccinelle/style/assignment_in_if.cocci 
b/scripts/coccinelle/style/assignment_in_if.cocci
new file mode 100644
index 000..22ab161
--- /dev/null
+++ b/scripts/coccinelle/style/assignment_in_if.cocci
@@ -0,0 +1,92 @@
+// find checkpatch.pl errors of the type:
+// ERROR: do not use assignment in if condition
+//
+// This script is designed to correct code where assignments exist in if
+// conditions. It is only capable of handling a subset of such problems.
+//
+// For example:
+//
+// if(result = myfun())
+//
+// would become:
+//
+// result = myfun();
+// if(result)
+//
+// Confidence: Moderate
+
+
+// if ( ret = call() )
+@if1@
+identifier i;
+expression E;
+statement S1, S2;
+@@
+
++ i = E;
+  if (
+- (i = E)
++ i
+  ) S1 else S2
+
+
+// if ( (ret = call()) < 0 )
+@if2@
+identifier i;
+expression E;
+statement S1, S2;
+binary operator b;
+@@
+
++ i = E;
+  if (
+- (i = E)
++ i
+  b ... ) S1 else S2
+
+// if ( ptr->fun && (ret = ptr->fun()) < 0 )
+@if3@
+identifier i, i2;
+expression E1, E2;
+constant c;
+binary operator b;
+@@
+
++ if( E1->i ) {
++  i2 = E2;
++  if (i2 b c) {
+- if( E1->i && ((i2 = E2) b c) ) {
+  ...
+- }
++  }
++ }
+
+// if ( (ret = call()) < 0 && ret != -1 )
+@if4@
+identifier i;
+expression E, E2;
+statement S1, S2;
+binary operator b;
+@@
+
++ i = E;
+  if (
+- (i = E)
++ i
+  b
+  ... && E2 ) S1 else S2
+
+// if ( (ret = call()) < 0 && ret != -1 && ret != -2 )
+@if5@
+identifier i;
+expression E, E2, E3;
+statement S1, S2;
+binary operator b;
+@@
+
++ i = E;
+  if (
+- (i = E)
++ i
+  b
+  ... && E2 && E3 ) S1 else S2
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] Thermal-SoC management updates for v4.2-rc7

[Eduardo Valentin]

Rui,

On Sat, Aug 15, 2015 at 10:14:45AM -0700, Eduardo Valentin wrote:
> Hello Rui,
> 
> Please pull from
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal 
> fixes
> 
> to receive Thermal-SoC Management updates for v4.2-rc7 with top-most
> 
> 1afb9c539daebc2c8a7b33d0e0b8fc9f74671b02:
> 
>   thermal/cpu_cooling: update policy limits if clipped_freq < policy->max 
> (2015-08-14 18:26:23 -0700)
> 
> on top of commit 7ddab73346a1277b90fd6a4d044bc948f9cc9ad8:
> 
>   Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm 
> (2015-08-13 16:34:56 -0700)
> 
> 
> Specifics:
> - Locked fix in the cpu cooling code.

Sorry for the late notice, but this fix should make it as soon as
possible. I messed up by forgetting this one for very long time. 

> - Refactoring in the cpu cooling code.
> - Remove devm* functions from power allocator.
> 
> BR,
> 
> Eduardo Valentin
> 
> Dmitry Torokhov (1):
>   thermal: power_allocator: do not use devm* interfaces
> 
> Russell King (1):
>   thermal: cpu_cooling: fix lockdep problems in cpu_cooling
> 
> Viresh Kumar (6):
>   thermal/cpu_cooling: No need to initialize max_freq to 0
>   thermal/cpu_cooling: quit early after updating policy
>   thermal/cpu_cooling: convert 'switch' block to 'if' block in notifier
>   thermal/cpu_cooling: rename cpufreq_val as clipped_freq
>   thermal/cpu_cooling: rename max_freq as clipped_freq in notifier
>   thermal/cpu_cooling: update policy limits if clipped_freq < policy->max
> 
>  drivers/thermal/cpu_cooling.c | 73 
> +++
>  drivers/thermal/power_allocator.c |  8 ++---
>  2 files changed, 48 insertions(+), 33 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] Thermal-SoC management updates for v4.2-rc7

[Eduardo Valentin]

Hello Rui,

Please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes

to receive Thermal-SoC Management updates for v4.2-rc7 with top-most

1afb9c539daebc2c8a7b33d0e0b8fc9f74671b02:

  thermal/cpu_cooling: update policy limits if clipped_freq < policy->max 
(2015-08-14 18:26:23 -0700)

on top of commit 7ddab73346a1277b90fd6a4d044bc948f9cc9ad8:

  Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm (2015-08-13 
16:34:56 -0700)


Specifics:
- Locked fix in the cpu cooling code.
- Refactoring in the cpu cooling code.
- Remove devm* functions from power allocator.

BR,

Eduardo Valentin

Dmitry Torokhov (1):
  thermal: power_allocator: do not use devm* interfaces

Russell King (1):
  thermal: cpu_cooling: fix lockdep problems in cpu_cooling

Viresh Kumar (6):
  thermal/cpu_cooling: No need to initialize max_freq to 0
  thermal/cpu_cooling: quit early after updating policy
  thermal/cpu_cooling: convert 'switch' block to 'if' block in notifier
  thermal/cpu_cooling: rename cpufreq_val as clipped_freq
  thermal/cpu_cooling: rename max_freq as clipped_freq in notifier
  thermal/cpu_cooling: update policy limits if clipped_freq < policy->max

 drivers/thermal/cpu_cooling.c | 73 +++
 drivers/thermal/power_allocator.c |  8 ++---
 2 files changed, 48 insertions(+), 33 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 08/16] x86/efi: Carrying hibernation key by setup data

[Pavel Machek]

On Tue 2015-08-11 14:16:28, Lee, Chun-Yi wrote:
> For forwarding hibernation key from EFI stub to boot kernel, this patch
> allocates setup data for carrying hibernation key, size and the status
> of efi operating.
> 
> Reviewed-by: Jiri Kosina 

Jiri, are you sure you reviewed these? This is not really
english, afaict, and efi/EFI should be spelled consistently.

Could you try reviewing it again? Pointing out 10s of small
bugs is quite boring...

>   unsigned long key_size;
>   unsigned long attributes;
> + struct setup_data *setup_data, *hibernation_setup_data;
>   struct hibernation_keys *keys;
> + unsigned long size = 0;
>   efi_status_t status;
>  
>   /* Allocate setup_data to carry keys */
> + size = sizeof(struct setup_data) + sizeof(struct hibernation_keys);
>   status = efi_call_early(allocate_pool, EFI_LOADER_DATA,
> - sizeof(struct hibernation_keys), );
> + size, _setup_data);
>   if (status != EFI_SUCCESS) {
>   efi_printk(sys_table, "Failed to alloc mem for hibernation 
> keys\n");
>   return;
>   }
>  
> - memset(keys, 0, sizeof(struct hibernation_keys));
> + memset(hibernation_setup_data, 0, size);
> + keys = (struct hibernation_keys *) hibernation_setup_data->data;
>  

any chance to type stuff correctly so that casts are not
neccessary?

> +clean_fail:
> + hibernation_setup_data->type = SETUP_HIBERNATION_KEYS;
> + hibernation_setup_data->len = sizeof(struct hibernation_keys);
> + hibernation_setup_data->next = 0;
> + keys->hkey_status = efi_status_to_err(status);
> +
> + setup_data = (struct setup_data *)params->hdr.setup_data;
> + while (setup_data && setup_data->next)
> + setup_data = (struct setup_data *)setup_data->next;

way too many casts here.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More hw_breakpoint scariness reduction

[Frederic Weisbecker]

2015-08-15 0:38 GMT+02:00 Andy Lutomirski :
> Would you all consider it acceptable to disallow watchpoints on per
> cpu data entirely?  I can think of a *lot* of places where hitting #DB
> when accessing per cpu data from entry asm would be bad.
>
> Of course, actually implementing that might be less than entirely fun,
> given that a cpu could be onlined after creating a watchpoint.

Well I think there will always be places where setting a breakpoint is
a bad idea. The same goes for kprobes. We can't fix all of them.
Kernel breakpoints can only be set by root users so it's not a
security issue. Besides, kernel breakpoints should only be used by
kernel hackers (perf, kdb).

Given the wide use of per-cpu data, forbidding all of them will
seriously reduce the usability of kernel breakpoints. Not that I think
they are really used in practice though ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mm/memblock: rename local variable of memblock_type to 'type'

[Alexander Kuleshov]

Since the e3239ff92a1 commit (memblock: Rename memblock_region
to memblock_type and memblock_property to memblock_region), all
local variables of the membock_type type were renamed to 'type'.
This commit renames all remaining local variables with the
memblock_type type to the same view.

Signed-off-by: Alexander Kuleshov 
---
 mm/memblock.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 87108e7..cf6b109 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -611,14 +611,14 @@ static int __init_memblock 
memblock_add_region(phys_addr_t base,
int nid,
unsigned long flags)
 {
-   struct memblock_type *_rgn = 
+   struct memblock_type *type = 
 
memblock_dbg("memblock_add: [%#016llx-%#016llx] flags %#02lx %pF\n",
 (unsigned long long)base,
 (unsigned long long)base + size - 1,
 flags, (void *)_RET_IP_);
 
-   return memblock_add_range(_rgn, base, size, nid, flags);
+   return memblock_add_range(type, base, size, nid, flags);
 }
 
 int __init_memblock memblock_add(phys_addr_t base, phys_addr_t size)
@@ -831,10 +831,10 @@ void __init_memblock __next_reserved_mem_region(u64 *idx,
   phys_addr_t *out_start,
   phys_addr_t *out_end)
 {
-   struct memblock_type *rsv = 
+   struct memblock_type *type = 
 
-   if (*idx >= 0 && *idx < rsv->cnt) {
-   struct memblock_region *r = >regions[*idx];
+   if (*idx >= 0 && *idx < type->cnt) {
+   struct memblock_region *r = >regions[*idx];
phys_addr_t base = r->base;
phys_addr_t size = r->size;
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] rtlwifi: rtl8192ee: fix semicolon.cocci warnings

[Larry Finger]

On 08/15/2015 05:36 AM, kbuild test robot wrote:

drivers/net/wireless/rtlwifi/rtl8192ee/phy.c:856:2-3: Unneeded semicolon
drivers/net/wireless/rtlwifi/rtl8192ee/phy.c:492:3-4: Unneeded semicolon
drivers/net/wireless/rtlwifi/rtl8192ee/phy.c:452:3-4: Unneeded semicolon


  Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Larry Finger 
Signed-off-by: Fengguang Wu 


Signed-off-by: Larry Finger 

Larry


---

  phy.c |6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/rtlwifi/rtl8192ee/phy.c
+++ b/drivers/net/wireless/rtlwifi/rtl8192ee/phy.c
@@ -449,7 +449,7 @@ static void _rtl92ee_phy_set_txpower_by_
 "Invalid RateSection %d in 2.4G,Rf %d,%dTx\n",
  rate_section, path, txnum);
break;
-   };
+   }
} else {
RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
 "Invalid Band %d\n", band);
@@ -489,7 +489,7 @@ static u8 _rtl92ee_phy_get_txpower_by_ra
 "Invalid RateSection %d in 2.4G,Rf %d,%dTx\n",
  rate_section, path, txnum);
break;
-   };
+   }
} else {
RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
 "Invalid Band %d()\n", band);
@@ -853,7 +853,7 @@ static u8 _rtl92ee_get_rate_section_inde
else if (regaddr >= 0xE20 && regaddr <= 0xE4C)
index = (u8)((regaddr - 0xE20) / 4);
break;
-   };
+   }
return index;
  }




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4.1 00/84] 4.1.6-stable review

[Greg Kroah-Hartman]

On Sat, Aug 15, 2015 at 08:21:43AM -0700, Guenter Roeck wrote:
> On Fri, Aug 14, 2015 at 10:41:28AM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.1.6 release.
> > There are 84 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sun Aug 16 17:41:54 UTC 2015.
> > Anything received after that time might be too late.
> > 
> Build results:
>   total: 138 pass: 138 fail: 0
> Qemu test results:
>   total: 84 pass: 83 fail: 1
> Failed tests:
>   mips:fuloong2e_defconfig
> 
> The fix for the qemu test failure is still pending acceptance and integration
> upstream.
> 
> Details are available at http://server.roeck-us.net:8010/builders/.

Thanks for testing all of these and letting me know.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] snic: fix simple_return.cocci warnings

[kbuild test robot]

drivers/scsi/snic/vnic_cq.c:46:1-4: WARNING: end returns can be simpified and 
declaration on line 34 can be dropped

 Simplify a trivial if-return sequence.  Possibly combine with a
 preceding function call.

Generated by: scripts/coccinelle/misc/simple_return.cocci

CC: Narsimhulu Musini 
Signed-off-by: Fengguang Wu 
---

 vnic_cq.c |8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

--- a/drivers/scsi/snic/vnic_cq.c
+++ b/drivers/scsi/snic/vnic_cq.c
@@ -31,8 +31,6 @@ void svnic_cq_free(struct vnic_cq *cq)
 int svnic_cq_alloc(struct vnic_dev *vdev, struct vnic_cq *cq,
unsigned int index, unsigned int desc_count, unsigned int desc_size)
 {
-   int err;
-
cq->index = index;
cq->vdev = vdev;
 
@@ -43,11 +41,7 @@ int svnic_cq_alloc(struct vnic_dev *vdev
return -EINVAL;
}
 
-   err = svnic_dev_alloc_desc_ring(vdev, >ring, desc_count, desc_size);
-   if (err)
-   return err;
-
-   return 0;
+   return svnic_dev_alloc_desc_ring(vdev, >ring, desc_count, 
desc_size);
 }
 
 void svnic_cq_init(struct vnic_cq *cq, unsigned int flow_control_enable,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Applied "regulator: pbias: Fix broken pbias disable functionality" to the regulator tree

[Mark Brown]

The patch

   regulator: pbias: Fix broken pbias disable functionality

has been applied to the regulator tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From c329061be51bef655f28c9296093984c977aff85 Mon Sep 17 00:00:00 2001
From: Kishon Vijay Abraham I 
Date: Mon, 27 Jul 2015 16:54:10 +0530
Subject: [PATCH] regulator: pbias: Fix broken pbias disable functionality

regulator_disable of pbias always writes '0' to the enable_reg.
However actual disable value of pbias regulator is not always '0'.
Fix it by populating the disable_val in pbias_reg_info for the
various platforms and assign it to the disable_val of
pbias regulator descriptor. This will be used by
regulator_disable_regmap while disabling pbias regulator.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Mark Brown 
Cc: 
---
 drivers/regulator/pbias-regulator.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index bd2b75c..4fa7bca 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -30,6 +30,7 @@
 struct pbias_reg_info {
u32 enable;
u32 enable_mask;
+   u32 disable_val;
u32 vmode;
unsigned int enable_time;
char *name;
@@ -62,6 +63,7 @@ static const struct pbias_reg_info pbias_mmc_omap2430 = {
.enable = BIT(1),
.enable_mask = BIT(1),
.vmode = BIT(0),
+   .disable_val = 0,
.enable_time = 100,
.name = "pbias_mmc_omap2430"
 };
@@ -77,6 +79,7 @@ static const struct pbias_reg_info pbias_sim_omap3 = {
 static const struct pbias_reg_info pbias_mmc_omap4 = {
.enable = BIT(26) | BIT(22),
.enable_mask = BIT(26) | BIT(25) | BIT(22),
+   .disable_val = BIT(25),
.vmode = BIT(21),
.enable_time = 100,
.name = "pbias_mmc_omap4"
@@ -85,6 +88,7 @@ static const struct pbias_reg_info pbias_mmc_omap4 = {
 static const struct pbias_reg_info pbias_mmc_omap5 = {
.enable = BIT(27) | BIT(26),
.enable_mask = BIT(27) | BIT(25) | BIT(26),
+   .disable_val = BIT(25),
.vmode = BIT(21),
.enable_time = 100,
.name = "pbias_mmc_omap5"
@@ -159,6 +163,7 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
drvdata[data_idx].desc.enable_reg = res->start;
drvdata[data_idx].desc.enable_mask = info->enable_mask;
drvdata[data_idx].desc.enable_val = info->enable;
+   drvdata[data_idx].desc.disable_val = info->disable_val;
 
cfg.init_data = pbias_matches[idx].init_data;
cfg.driver_data = [data_idx];
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: lustre: ptlrpc: add missing include directive

[Greg KH]

On Sat, Aug 15, 2015 at 11:13:39AM +0300, Ioan-Adrian Ratiu wrote:
> On Fri, 14 Aug 2015 18:50:24 -0700
> Greg KH  wrote:
> 
> > On Fri, Aug 14, 2015 at 12:57:06PM +0300, Ioan-Adrian Ratiu wrote:
> > > Without including ptlrpc_internal.h, GCC gives prototype warnings
> > > "pack_generic.c:642:5: warning: no previous prototype for ..."
> > 
> > It does?  What version of gcc give you that, I don't see that here.
> > 
> 
> Yes, but it's a non-default warning (-Wmissing-prototypes)

Then you should say that, otherwise you have us worrying something is
really wrong with our build/compiler versions...

I've taken this patch, but next time please be more specific.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/memblock: validate the creation of debugfs files

[Greg Kroah-Hartman]

On Sat, Aug 15, 2015 at 12:38:30AM -0700, Andrew Morton wrote:
> On Sat, 15 Aug 2015 13:26:36 +0600 Alexander Kuleshov 
>  wrote:
> 
> > Hello Andrew,
> > 
> > On 08-14-15, Andrew Morton wrote:
> > > On Sat, 15 Aug 2015 01:03:31 +0600 Alexander Kuleshov 
> > >  wrote:
> > > 
> > > > Signed-off-by: Alexander Kuleshov 
> > > 
> > > There's no changelog.
> > 
> > Yes, will add it if there will be sense in the patch.
> > 
> > > 
> > > Why?  Ignoring the debugfs API return values is standard practice.
> > > 
> > 
> > Yes, but I saw many places where this practice is applicable (for example
> > in the kernel/kprobes and etc.), besides this, the memblock API is used
> > mostly at early stage, so we will have some output if something going wrong.
> 
> The debugfs error-handling rules are something Greg cooked up after one
> too many beers.  I've never understood them, but maybe I continue to
> miss the point.

The "point" is that it should be easy to use, and you don't care if the
file fails to be created because your normal code flow / functionality
does not care if a debugfs file fails to be created.

The only way a debugfs file will fail to be created is if you name
something the same as a file is present, or you passed in the wrong
options, or if you are out of memory, and in all of those cases, there's
nothing a user can do about it.  Yes, when writing your code the first
time, check the error if you want to figure out your logic, but after
that, you don't care.

If debugfs is not enabled, yes, an error will be returned, but you don't
have to care about that, because again, you don't care, and your main
code path is just fine.

So just ignore the return value of debugfs functions, except to save off
pointers that you need to pass back in them later.

> Yes, I agree that if memblock's debugfs_create_file() fails, we want to
> know about it because something needs fixing.

What can be fixed?  Out of memory?  Identical file name?  Nothing a user
can do about that.

> But that's true of
> all(?) debugfs_create_file callsites, so it's a bit silly to add
> warnings to them all.  Why not put the warning into
> debugfs_create_file() itself?  And add a debugfs_create_file_no_warn()
> if there are callsites which have reason to go it alone.  Or add a
> debugfs_create_file_warn() wrapper.

No, it's really not worth it.  The goal of debugfs was to make an api
that is easier to use than procfs which required a bunch of odd return
error checks and you could never tell if the error was due to something
real or if the procfs was not enabled in the kernel.

And it's for debugging files, again, nothing that should be something
you rely on.  If you rely on debugfs files for something, well, you are
using the wrong api (yes, I know all about the trace nightmare...)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

[Dan Williams]

On Sat, Aug 15, 2015 at 8:58 AM, Christoph Hellwig  wrote:
> On Sat, Aug 15, 2015 at 08:28:35AM -0700, Dan Williams wrote:
>> I'm not grokking the argument against allowing this functionality to
>> be modular.
>
> You're adding a another layer of platform_devices just to make a tivially
> small piece of code modular so that you can hook into it.  I don't think
> that's a good reason, and neither is the after thought of preventing
> potentially future buggy firmware.

What other layer? /sys/devices/platform/e820_pmem is that exact same
device we had before this patch.  We just have a proper driver for it
now.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/7] pmem, dax: have direct_access use __pmem annotation

[Christoph Hellwig]

On Sat, Aug 15, 2015 at 08:44:27AM -0700, Dan Williams wrote:
> That said, while we don't need special accessors we do need guarantees
> that anything that has written to a persistent memory address has done
> so in a way that wmb_pmem() is able to flush it.  It's more of a "I've
> audited this code path for wmb_pmem() compatibility so use this api to
> write to pmem."

I'm more worried about things where don't just do plain loads and stores
to a pmem region but DMA, which will end up as a nightmare of casts.

But we can wait and see how that evolves in the end..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 5/7] libnvdimm, e820: make CONFIG_X86_PMEM_LEGACY a tristate option

[Christoph Hellwig]

On Sat, Aug 15, 2015 at 08:28:35AM -0700, Dan Williams wrote:
> I'm not grokking the argument against allowing this functionality to
> be modular.

You're adding a another layer of platform_devices just to make a tivially
small piece of code modular so that you can hook into it.  I don't think
that's a good reason, and neither is the after thought of preventing
potentially future buggy firmware.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drm/nouveau/fifo: fix simple_return.cocci warnings

[kbuild test robot]

drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.c:396:1-4: WARNING: end returns 
can be simpified

 Simplify a trivial if-return sequence.  Possibly combine with a
 preceding function call.

Generated by: scripts/coccinelle/misc/simple_return.cocci

Signed-off-by: Fengguang Wu 
---

 g84.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.c
@@ -393,12 +393,8 @@ g84_fifo_context_ctor(struct nvkm_object
if (ret)
return ret;
 
-   ret = nvkm_gpuobj_new(nv_object(base), nv_object(base), 0x0100,
+   return nvkm_gpuobj_new(nv_object(base), nv_object(base), 0x0100,
  0x100, NVOBJ_FLAG_ZERO_ALLOC, >ramfc);
-   if (ret)
-   return ret;
-
-   return 0;
 }
 
 static struct nvkm_oclass
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] drm/nouveau/fifo: fix simple_return.cocci warnings

[kbuild test robot]

drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:340:1-4: WARNING: end returns 
can be simpified

 Simplify a trivial if-return sequence.  Possibly combine with a
 preceding function call.

Generated by: scripts/coccinelle/misc/simple_return.cocci

Signed-off-by: Fengguang Wu 
---

 gf100.c |6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c
@@ -337,11 +337,7 @@ gf100_fifo_context_ctor(struct nvkm_obje
nv_wo32(base, 0x0208, 0x);
nv_wo32(base, 0x020c, 0x00ff);
 
-   ret = nvkm_vm_ref(nvkm_client(parent)->vm, >vm, base->pgd);
-   if (ret)
-   return ret;
-
-   return 0;
+   return nvkm_vm_ref(nvkm_client(parent)->vm, >vm, base->pgd);
 }
 
 static void
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/7] pmem, dax: have direct_access use __pmem annotation

[Dan Williams]

On Sat, Aug 15, 2015 at 2:11 AM, Christoph Hellwig  wrote:
> On Fri, Aug 14, 2015 at 09:58:16AM -0700, Dan Williams wrote:
>> > I'll merge with your code for v3.
>>
>> Sounds, let me go rebase the __pfn_t patches on -mm so we'all lined up
>> and collision free.
>
> I'm doubt that we'll have PFN mapping ready for 4.3.  I'd rather see
> Ross series goes first, and move the patch to remove the size argument
> from ->direct access [1] over to this series as well.
>
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git/commit/?h=pfn=8e15e69fb9e61ac563c5a7ffd9dd9a7b545cced3

Yes, let's do it.  The need for DAX persistence guarantees is a higher
priority than solving the DAX vs PMEM unbind bug.  Especially if we
can defer __pfn_t and get some basic struct page mapping into 4.3 as
well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] blk-mq: two fixes

[Jens Axboe]

On 08/14/2015 07:10 PM, Ming Lei wrote:

On Sun, Aug 9, 2015 at 3:41 PM, Ming Lei  wrote:

Hi Jens,

The 1st patch fixes one buffer overflow issue when reading
sysfs file of hctx's pending.

The 2nd patch fixes one race between timeout and request freeing,
which also simplifies implementation of blk_mq_tag_to_rq() a lot.


Ping...


Sorry, 1/2 is a no brainer, needed a bit of time to look at 2/2. I think 
it looks fine, and I like how it simplifies (and gets rid of) the flush 
special case tag lookup. Applied.



--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/7] pmem, dax: have direct_access use __pmem annotation

[Dan Williams]

On Sat, Aug 15, 2015 at 2:19 AM, Christoph Hellwig  wrote:
> On Thu, Aug 13, 2015 at 10:51:11AM -0600, Ross Zwisler wrote:
>> Update the annotation for the kaddr pointer returned by direct_access()
>> so that it is a __pmem pointer.  This is consistent with the PMEM driver
>> and with how this direct_access() pointer is used in the DAX code.
>
> IFF we stick to the __pmem annotations this looks good.
>
> That beeing said I start to really dislike them.  We don't special
> accesors to read/write from pmem, we just need to explicitly commit
> it if we want to make it persistent.  So I really don't see the need
> to treat it special and require all the force casts to and from the
> attribute.

I'm not going to put up much of a fight if it's really getting in the way

That said, while we don't need special accessors we do need guarantees
that anything that has written to a persistent memory address has done
so in a way that wmb_pmem() is able to flush it.  It's more of a "I've
audited this code path for wmb_pmem() compatibility so use this api to
write to pmem."

Perhaps a better way to statically check for missed flushes might be
to have acquire_pmem_for_write() + release() annotations and the final
release does a wmb_pmem(), but as far as I can tell the sparse
acquire/release annotations don't stack.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/