Re: [PATCH] staging: most: core: add autoconf ability

2017-04-21 Thread Greg KH 
On Fri, Apr 21, 2017 at 09:37:38PM +0200, Christian Gromm wrote:
> On Fri, 21 Apr 2017 18:15:43 +0200
> Greg KH  wrote:
> 
> > On Fri, Apr 21, 2017 at 05:36:43PM +0200, Christian Gromm wrote:
> > > 
> > > 
> > > On 04/20/2017 05:26 PM, Greg KH wrote:
> > > > On Thu, Apr 20, 2017 at 05:01:49PM +0200, Christian Gromm wrote:
> > > > > This patch extends the driver with the possibility of automatic
> > > > > configuration. This covers channel settings and connection
> > > > > establishing of a MOST device interface while it is registered
> > > > > with the core.
> > > > > 
> > > > > Making use of auto configuration will significantly cut the
> > > > > start-up overhead and the duration until the driver is
> > > > > available in userspace. Since the configuration depends on the
> > > > > type of network interface controller its setup and the
> > > > > peripheral interface, it can _not_ be part of the kernel and
> > > > > needs to be added once the system has been engineered.
> > > > 
> > > > I don't understand, what is using this new api you have added?
> > > > What is missing here?
> > > 
> > > What's missing is a module that holds the configuration, which looks
> > > basically like the sample module below. Once such a module is loaded
> > > along with the "regular" driver modules, configuration and linking
> > > of the channels is done automatically and you don't need any user
> > > space applications taking care of this.
> > > 
> > > But as stated in the commit message, this can't be part of the
> > > kernel tree since the information contained by this module heavily
> > > depends on what NIC is used, how it is configured and how the system
> > > designer wants to layout the network.
> > 
> > Well, I can never add an api to the kernel that no one uses, so this
> > isn't going to go very far at all.
> > 
> > Why don't you use DT for all of this?  It looks like that is exactly
> > what you are wanting to have your driver know.
> >
> 
> I understand the device tree as a description of the hardware layout
> and to let the kernel know about what HW is there. Never heard that it
> is (or can) used to configure certain modules.

What do you mean, it is used to configure modules (i.e. drivers) about
what hardware the platform has.  Which is what you want to do here,
right?  Your "hardware" (i.e. your network), is defined by the platform
it is running on.

Look at all of the stuff that DT is used to describe today, and if it
doesn't cover your use cases, please let us know.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: android: ion: Replace spaces with tabs for indentation

2017-04-21 Thread Melko 
From: Paolo Cretaro 

Fix checkpatch ERRORs: code indent should use tabs where possible.

Signed-off-by: Paolo Cretaro 
---
 drivers/staging/android/ion/ion_cma_heap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/android/ion/ion_cma_heap.c 
b/drivers/staging/android/ion/ion_cma_heap.c
index dc2a9135c4d0..a0949bc0dcf4 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -108,7 +108,7 @@ static struct ion_heap *__ion_cma_heap_create(struct cma 
*cma)
 
 int __ion_add_cma_heaps(struct cma *cma, void *data)
 {
-struct ion_heap *heap;
+   struct ion_heap *heap;
 
heap = __ion_cma_heap_create(cma);
if (IS_ERR(heap))
@@ -116,8 +116,8 @@ int __ion_add_cma_heaps(struct cma *cma, void *data)
 
heap->name = cma_get_name(cma);
 
-ion_device_add_heap(heap);
-return 0;
+   ion_device_add_heap(heap);
+   return 0;
 }
 
 static int ion_add_cma_heaps(void)
-- 
2.12.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}() helpers

2017-04-21 Thread Rafael J. Wysocki 
On Friday, April 21, 2017 05:46:45 PM Andy Shevchenko wrote:
> Recently introduced helpers take pointers to uuid_{be|le} instead of
> reference.
> 
> Using them makes code less ugly.
> 
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/acpi/acpi_extlog.c | 2 +-
>  drivers/acpi/apei/ghes.c   | 8 
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
> index 502ea4dc2080..45e299aefda7 100644
> --- a/drivers/acpi/acpi_extlog.c
> +++ b/drivers/acpi/acpi_extlog.c
> @@ -169,7 +169,7 @@ static int extlog_print(struct notifier_block *nb, 
> unsigned long val,
>   if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
>   fru_text = gdata->fru_text;
>   sec_type = (uuid_le *)gdata->section_type;
> - if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
> + if (!uuid_le_cmp_p(sec_type, CPER_SEC_PLATFORM_MEM)) {
>   struct cper_sec_mem_err *mem = (void *)(gdata + 1);
>   if (gdata->error_data_length >= sizeof(*mem))
>   trace_extlog_mem_event(mem, err_seq, fru_id, fru_text,

ACK for this one.

> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index d0855c09f32f..f2a7ee26d45f 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -431,12 +431,13 @@ static void ghes_do_proc(struct ghes *ghes,
>  {
>   int sev, sec_sev;
>   struct acpi_hest_generic_data *gdata;
> + uuid_le *sec_type;
>  
>   sev = ghes_severity(estatus->error_severity);
>   apei_estatus_for_each_section(estatus, gdata) {
> + sec_type = (uuid_le *)gdata->section_type;
>   sec_sev = ghes_severity(gdata->error_severity);
> - if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
> -  CPER_SEC_PLATFORM_MEM)) {
> + if (!uuid_le_cmp_p(sec_type, CPER_SEC_PLATFORM_MEM)) {
>   struct cper_sec_mem_err *mem_err;
>   mem_err = (struct cper_sec_mem_err *)(gdata+1);
>   ghes_edac_report_mem_error(ghes, sev, mem_err);
> @@ -445,8 +446,7 @@ static void ghes_do_proc(struct ghes *ghes,
>   ghes_handle_memory_failure(gdata, sev);
>   }
>  #ifdef CONFIG_ACPI_APEI_PCIEAER
> - else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
> -   CPER_SEC_PCIE)) {
> + else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE)) {
>   struct cper_sec_pcie *pcie_err;
>   pcie_err = (struct cper_sec_pcie *)(gdata+1);
>   if (sev == GHES_SEV_RECOVERABLE &&
> 

But this one is for Boris.

Thanks,
Rafael

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8723bs: rework debug configuration handling

2017-04-21 Thread Arnd Bergmann 
I ran into this warning during randconfig testing:

drivers/staging/rtl8723bs/os_dep/rtw_proc.c: In function 
'rtw_adapter_proc_deinit':
drivers/staging/rtl8723bs/os_dep/rtw_proc.c:738:25: error: unused variable 
'drv_proc' [-Werror=unused-variable]
drivers/staging/rtl8723bs/os_dep/rtw_proc.c: In function 
'rtw_adapter_proc_replace':
drivers/staging/rtl8723bs/os_dep/rtw_proc.c:762:25: error: unused variable 
'drv_proc' [-Werror=unused-variable]

The problem is that the code procfs code gets built even when CONFIG_PROC_FS
is disabled, but some functions are turned into empty stubs then. This
is easily addressed by adding an #ifdef around the definition of the
CONFIG_PROC_DEBUG macro.

However, I could not bear looking at the macro name that clashes with the
Kconfig name space, so I also renamed it to simply PROC_DEBUG, along with
the other rtl8723bs specific CONFIG_DEBUG_* macros that I renamed the same
way. This is consistent with how we handle the same checks in the non-staging
rtlwifi driver.

As the code path for !CONFIG_PROC_DEBUG had not been tested properly, it
turned out to be incorrect and requires adding 'static inline' annotations
for the stub handlers, and moving some variables around.

Fixes: 554c0a3abf21 ("staging: Add rtl8723bs sdio wifi driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/rtl8723bs/core/rtw_cmd.c  |  2 ++
 drivers/staging/rtl8723bs/core/rtw_debug.c| 11 +++-
 drivers/staging/rtl8723bs/core/rtw_mlme_ext.c |  6 ++---
 drivers/staging/rtl8723bs/hal/rtl8723b_cmd.c  |  4 +--
 drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c | 12 ++---
 drivers/staging/rtl8723bs/include/autoconf.h  | 16 +++-
 drivers/staging/rtl8723bs/include/rtw_debug.h | 12 -
 drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 32 +++
 drivers/staging/rtl8723bs/os_dep/ioctl_linux.c|  6 ++---
 drivers/staging/rtl8723bs/os_dep/rtw_proc.c   |  4 +--
 drivers/staging/rtl8723bs/os_dep/rtw_proc.h   | 16 ++--
 11 files changed, 62 insertions(+), 59 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c 
b/drivers/staging/rtl8723bs/core/rtw_cmd.c
index 24ba0533572e..080c81b9aa94 100644
--- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
@@ -1744,6 +1744,8 @@ u8 rtw_ps_cmd(struct adapter *padapter)
return res;
 }
 
+u32 g_wait_hiq_empty = 0;
+
 static void rtw_chk_hi_queue_hdl(struct adapter *padapter)
 {
struct sta_info *psta_bmc;
diff --git a/drivers/staging/rtl8723bs/core/rtw_debug.c 
b/drivers/staging/rtl8723bs/core/rtw_debug.c
index fc6b94d59c37..3db02e9f27ab 100644
--- a/drivers/staging/rtl8723bs/core/rtw_debug.c
+++ b/drivers/staging/rtl8723bs/core/rtw_debug.c
@@ -19,7 +19,7 @@
 
 u32 GlobalDebugLevel = _drv_err_;
 
-#ifdef CONFIG_DEBUG_RTL871X
+#ifdef DEBUG_RTL871X
 
u64 GlobalDebugComponents = \
_module_rtl871x_xmit_c_ |
@@ -52,7 +52,7 @@ u32 GlobalDebugLevel = _drv_err_;
_module_mp_ |
_module_efuse_;
 
-#endif /* CONFIG_DEBUG_RTL871X */
+#endif /* DEBUG_RTL871X */
 
 #include 
 
@@ -140,7 +140,7 @@ void rf_reg_dump(void *sel, struct adapter *adapter)
}
 }
 
-#ifdef CONFIG_PROC_DEBUG
+#ifdef PROC_DEBUG
 ssize_t proc_set_write_reg(struct file *file, const char __user *buffer, 
size_t count, loff_t *pos, void *data)
 {
struct net_device *dev = data;
@@ -605,9 +605,6 @@ ssize_t proc_set_rate_ctl(struct file *file, const char 
__user *buffer, size_t c
return count;
 }
 
-u8 g_fwdl_chksum_fail = 0;
-u8 g_fwdl_wintint_rdy_fail = 0;
-
 ssize_t proc_set_fwdl_test_case(struct file *file, const char __user *buffer, 
size_t count, loff_t *pos, void *data)
 {
char tmp[32];
@@ -622,8 +619,6 @@ ssize_t proc_set_fwdl_test_case(struct file *file, const 
char __user *buffer, si
return count;
 }
 
-u32 g_wait_hiq_empty = 0;
-
 ssize_t proc_set_wait_hiq_empty(struct file *file, const char __user *buffer, 
size_t count, loff_t *pos, void *data)
 {
char tmp[32];
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 697b81e2140c..17d881d66910 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -4844,7 +4844,7 @@ static void process_80211d(struct adapter *padapter, 
struct wlan_bssid_ex *bssid
}
chplan_ap.Len = i;
 
-#ifdef CONFIG_DEBUG_RTL871X
+#ifdef DEBUG_RTL871X
i = 0;
DBG_871X("%s: AP[%s] channel plan {", __func__, 
bssid->Ssid.Ssid);
while ((i < chplan_ap.Len) && (chplan_ap.Channel[i] != 0)) {
@@ -4855,7 +4855,7 @@ static void process_80211d(struct adapter *padapter, 
struct wlan_bssid_ex *bssid
 #endif
 
memcpy(chplan_sta, pmlmeext->channel_set, sizeof(chplan_sta));
-#ifdef CONFIG_DEBUG_RTL871X
+#ifdef

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

2017-04-21 Thread Joe Perches 
On Fri, 2017-04-21 at 00:40 -0700, Chandra Annamaneni wrote:
> Third Reminder. Please review.

Patience.

> On Sun, 9 Apr 2017, chandrasekhar annamaneni wrote:
> > Second reminder, please review.
[]
> > On Fri, Mar 17, 2017 at 12:49 PM, Chandra Annamaneni 
> > wrote:
> > 
> >   Change video.c to use %s, __func__ instead of function names.
> >   Warnings flagged by checkpatch.pl
[]
> >   diff --git a/drivers/staging/most/aim-v4l2/video.c
[]
> >   @@ -79,7 +79,7 @@ static int aim_vdev_open(struct file *filp)
> >           struct most_video_dev *mdev = video_drvdata(filp);
> >           struct aim_fh *fh;
> > 
> >   -       v4l2_info(>v4l2_dev, "aim_vdev_open()\n");
> >   +       v4l2_info(>v4l2_dev, "%s()\n", __func__);

More likely all of these should be deleted
as these seem to be function tracing logging
and ftrace works well.

see: Documentation/trace/ftrace.txt

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: most: core: add autoconf ability

2017-04-21 Thread Christian Gromm 
On Fri, 21 Apr 2017 18:15:43 +0200
Greg KH  wrote:

> On Fri, Apr 21, 2017 at 05:36:43PM +0200, Christian Gromm wrote:
> > 
> > 
> > On 04/20/2017 05:26 PM, Greg KH wrote:
> > > On Thu, Apr 20, 2017 at 05:01:49PM +0200, Christian Gromm wrote:
> > > > This patch extends the driver with the possibility of automatic
> > > > configuration. This covers channel settings and connection
> > > > establishing of a MOST device interface while it is registered
> > > > with the core.
> > > > 
> > > > Making use of auto configuration will significantly cut the
> > > > start-up overhead and the duration until the driver is
> > > > available in userspace. Since the configuration depends on the
> > > > type of network interface controller its setup and the
> > > > peripheral interface, it can _not_ be part of the kernel and
> > > > needs to be added once the system has been engineered.
> > > 
> > > I don't understand, what is using this new api you have added?
> > > What is missing here?
> > 
> > What's missing is a module that holds the configuration, which looks
> > basically like the sample module below. Once such a module is loaded
> > along with the "regular" driver modules, configuration and linking
> > of the channels is done automatically and you don't need any user
> > space applications taking care of this.
> > 
> > But as stated in the commit message, this can't be part of the
> > kernel tree since the information contained by this module heavily
> > depends on what NIC is used, how it is configured and how the system
> > designer wants to layout the network.
> 
> Well, I can never add an api to the kernel that no one uses, so this
> isn't going to go very far at all.
> 
> Why don't you use DT for all of this?  It looks like that is exactly
> what you are wanting to have your driver know.
>

I understand the device tree as a description of the hardware layout
and to let the kernel know about what HW is there. Never heard that it
is (or can) used to configure certain modules.

thanks,
Chris

> good luck!
> 
> greg k-h



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

2017-04-21 Thread Greg KH 
On Fri, Apr 21, 2017 at 11:06:54AM -0700, Chandra Annamaneni wrote:
> 
> Sorry about the top posting.
> 
> I did ask about it on the 9th of April and the reply was that the email
> was 'acked'. Since I did not get a further email, I assumed it was lost.
> Perhaps I misunderstood.

I really do not know, sorry.  If you didn't get an automated email from
my system that it was applied, rebased it against the latest
staging-next branch and resend it.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

2017-04-21 Thread Chandra Annamaneni 

Sorry about the top posting.

I did ask about it on the 9th of April and the reply was that the email
was 'acked'. Since I did not get a further email, I assumed it was lost.
Perhaps I misunderstood.

Thanks!
Chandra


On Fri, 21 Apr 2017, Greg KH wrote:

> 
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> 
> http://daringfireball.net/2007/07/on_top
> 
> On Fri, Apr 21, 2017 at 12:40:25AM -0700, Chandra Annamaneni wrote:
> > 
> > Third Reminder. Please review.
> 
> 2 days after you asked before?
> 
> And I don't even see this patch in my queue, are you sure it hasn't
> already been handled, or merged, or rejected?
> 
> thanks,
> 
> greg k-h
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH net-next 1/1] netvsc: Deal with rescinded channels correctly

2017-04-21 Thread David Miller 
From: k...@exchange.microsoft.com
Date: Wed, 19 Apr 2017 13:53:49 -0700

> From: K. Y. Srinivasan 
> 
> We will not be able to send packets over a channel that has been
> rescinded. Make necessary adjustments so we can properly cleanup
> even when the channel is rescinded. This issue can be trigerred
> in the NIC hot-remove path.
> 
> Signed-off-by: K. Y. Srinivasan 

Applied, thanks.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: rtl8192u: fix spelling mistake in variable name *attentuation

2017-04-21 Thread Colin King 
From: Colin Ian King 

Fix the spelling of a bunch of variables, from *attentuation to
*attenuation.  No functional change.

Signed-off-by: Colin Ian King 
---
 drivers/staging/rtl8192u/r8192U.h  |  8 ++---
 drivers/staging/rtl8192u/r8192U_core.c | 10 +++---
 drivers/staging/rtl8192u/r8192U_dm.c   | 56 +-
 drivers/staging/rtl8192u/r819xU_phy.c  | 34 ++---
 4 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U.h 
b/drivers/staging/rtl8192u/r8192U.h
index 524c1c94193a..e702afb5a70e 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -1041,10 +1041,10 @@ typedef struct r8192_priv {
u8 rfc_txpowertrackingindex;
u8 rfc_txpowertrackingindex_real;
 
-   s8 cck_present_attentuation;
-   u8 cck_present_attentuation_20Mdefault;
-   u8 cck_present_attentuation_40Mdefault;
-   s8 cck_present_attentuation_difference;
+   s8 cck_present_attenuation;
+   u8 cck_present_attenuation_20Mdefault;
+   u8 cck_present_attenuation_40Mdefault;
+   s8 cck_present_attenuation_difference;
bool btxpower_tracking;
bool bcck_in_ch14;
bool btxpowerdata_readfromEEPORM;
diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 8448e83f64f3..9f370e8d84d3 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -3023,14 +3023,14 @@ static bool rtl8192_adapter_start(struct net_device 
*dev)
 
for (i = 0; i < CCKTxBBGainTableLength; i++) {
if (TempCCk == 
priv->cck_txbbgain_table[i].ccktxbb_valuearray[0]) {
-   
priv->cck_present_attentuation_20Mdefault = (u8)i;
+   
priv->cck_present_attenuation_20Mdefault = (u8)i;
break;
}
}
-   priv->cck_present_attentuation_40Mdefault = 0;
-   priv->cck_present_attentuation_difference = 0;
-   priv->cck_present_attentuation =
-   priv->cck_present_attentuation_20Mdefault;
+   priv->cck_present_attenuation_40Mdefault = 0;
+   priv->cck_present_attenuation_difference = 0;
+   priv->cck_present_attenuation =
+   priv->cck_present_attenuation_20Mdefault;
}
}
write_nic_byte(dev, 0x87, 0x0);
diff --git a/drivers/staging/rtl8192u/r8192U_dm.c 
b/drivers/staging/rtl8192u/r8192U_dm.c
index 623d49585bee..975f707827e1 100644
--- a/drivers/staging/rtl8192u/r8192U_dm.c
+++ b/drivers/staging/rtl8192u/r8192U_dm.c
@@ -598,8 +598,8 @@ static void dm_TXPowerTrackingCallback_TSSI(struct 
net_device *dev)
RT_TRACE(COMP_POWER_TRACKING, "tx power track 
is done\n");
RT_TRACE(COMP_POWER_TRACKING, 
"priv->rfa_txpowertrackingindex = %d\n", priv->rfa_txpowertrackingindex);
RT_TRACE(COMP_POWER_TRACKING, 
"priv->rfa_txpowertrackingindex_real = %d\n", 
priv->rfa_txpowertrackingindex_real);
-   RT_TRACE(COMP_POWER_TRACKING, 
"priv->cck_present_attentuation_difference = %d\n", 
priv->cck_present_attentuation_difference);
-   RT_TRACE(COMP_POWER_TRACKING, 
"priv->cck_present_attentuation = %d\n", priv->cck_present_attentuation);
+   RT_TRACE(COMP_POWER_TRACKING, 
"priv->cck_present_attenuation_difference = %d\n", 
priv->cck_present_attenuation_difference);
+   RT_TRACE(COMP_POWER_TRACKING, 
"priv->cck_present_attenuation = %d\n", priv->cck_present_attenuation);
return;
}
if (Avg_TSSI_Meas_from_driver < TSSI_13dBm - 
E_FOR_TX_POWER_TRACK) {
@@ -618,17 +618,17 @@ static void dm_TXPowerTrackingCallback_TSSI(struct 
net_device *dev)
 
}
}
-   priv->cck_present_attentuation_difference
+   priv->cck_present_attenuation_difference
= priv->rfa_txpowertrackingindex - 
priv->rfa_txpowertracking_default;
 
if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20)
-   priv->cck_present_attentuation
-   = 
priv->cck_present_attentuation_20Mdefault + 
priv->cck_present_attentuation_difference;
+   priv->cck_present_attenuation
+   = 
priv->cck_present_attenuation_20Mdefault + 
priv->cck_present_attenuation_difference;

Re: [PATCH] staging: most: core: add autoconf ability

2017-04-21 Thread Greg KH 
On Fri, Apr 21, 2017 at 05:36:43PM +0200, Christian Gromm wrote:
> 
> 
> On 04/20/2017 05:26 PM, Greg KH wrote:
> > On Thu, Apr 20, 2017 at 05:01:49PM +0200, Christian Gromm wrote:
> > > This patch extends the driver with the possibility of automatic
> > > configuration. This covers channel settings and connection establishing of
> > > a MOST device interface while it is registered with the core.
> > > 
> > > Making use of auto configuration will significantly cut the start-up
> > > overhead and the duration until the driver is available in userspace.
> > > Since the configuration depends on the type of network interface 
> > > controller
> > > its setup and the peripheral interface, it can _not_ be part of the kernel
> > > and needs to be added once the system has been engineered.
> > 
> > I don't understand, what is using this new api you have added?  What is
> > missing here?
> 
> What's missing is a module that holds the configuration, which looks
> basically like the sample module below. Once such a module is loaded
> along with the "regular" driver modules, configuration and linking of
> the channels is done automatically and you don't need any user space
> applications taking care of this.
> 
> But as stated in the commit message, this can't be part of the kernel
> tree since the information contained by this module heavily depends
> on what NIC is used, how it is configured and how the system
> designer wants to layout the network.

Well, I can never add an api to the kernel that no one uses, so this
isn't going to go very far at all.

Why don't you use DT for all of this?  It looks like that is exactly
what you are wanting to have your driver know.

good luck!

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/1] staging: fbtft: Fix Sparse warning in fb_watterott.c

2017-04-21 Thread Cezary Gapinski 
Sparse reports the following in fb_watterott.c:

warning: incorrect type in assignment (different base types)
expected unsigned short [unsigned] [short] [usertype] 
got restricted __be16 [usertype] 

Use __be16 types for endian correctness

Signed-off-by: Cezary Gapinski 
---
 drivers/staging/fbtft/fb_watterott.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/fbtft/fb_watterott.c 
b/drivers/staging/fbtft/fb_watterott.c
index 4293045..180e5be 100644
--- a/drivers/staging/fbtft/fb_watterott.c
+++ b/drivers/staging/fbtft/fb_watterott.c
@@ -69,8 +69,8 @@ static int write_vmem(struct fbtft_par *par, size_t offset, 
size_t len)
 {
unsigned int start_line, end_line;
u16 *vmem16 = (u16 *)(par->info->screen_buffer + offset);
-   u16 *pos = par->txbuf.buf + 1;
-   u16 *buf16 = par->txbuf.buf + 10;
+   __be16 *pos = par->txbuf.buf + 1;
+   __be16 *buf16 = par->txbuf.buf + 10;
int i, j;
int ret = 0;
 
@@ -106,7 +106,7 @@ static int write_vmem_8bit(struct fbtft_par *par, size_t 
offset, size_t len)
 {
unsigned int start_line, end_line;
u16 *vmem16 = (u16 *)(par->info->screen_buffer + offset);
-   u16 *pos = par->txbuf.buf + 1;
+   __be16 *pos = par->txbuf.buf + 1;
u8 *buf8 = par->txbuf.buf + 10;
int i, j;
int ret = 0;
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: most: core: add autoconf ability

2017-04-21 Thread Christian Gromm 



On 04/20/2017 05:26 PM, Greg KH wrote:

On Thu, Apr 20, 2017 at 05:01:49PM +0200, Christian Gromm wrote:

This patch extends the driver with the possibility of automatic
configuration. This covers channel settings and connection establishing of
a MOST device interface while it is registered with the core.

Making use of auto configuration will significantly cut the start-up
overhead and the duration until the driver is available in userspace.
Since the configuration depends on the type of network interface controller
its setup and the peripheral interface, it can _not_ be part of the kernel
and needs to be added once the system has been engineered.


I don't understand, what is using this new api you have added?  What is
missing here?


What's missing is a module that holds the configuration, which looks
basically like the sample module below. Once such a module is loaded
along with the "regular" driver modules, configuration and linking of
the channels is done automatically and you don't need any user space
applications taking care of this.

But as stated in the commit message, this can't be part of the kernel
tree since the information contained by this module heavily depends
on what NIC is used, how it is configured and how the system
designer wants to layout the network.

regards,
Chris

/*
 * default_conf.c - Default configuration for the MOST channels.
 *
 * Copyright (C) 2017, Microchip Technology Germany II GmbH & Co. KG
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * This file is licensed under GPLv2.
 */

#include "most.h"
#include 

static struct most_config_probe config_probes[] = {
/* MediaLB */
{
.ch_name = "ca2",
.cfg = {
.direction = MOST_CH_RX,
.data_type = MOST_CH_CONTROL,
.num_buffers = 16,
.buffer_size = 64,
},
.comp_name = "cdev",
.comp_param = "inic-mlb-crx",
},
{
.ch_name = "ca4",
.cfg = {
.direction = MOST_CH_TX,
.data_type = MOST_CH_CONTROL,
.num_buffers = 16,
.buffer_size = 64,
},
.comp_name = "cdev",
.comp_param = "inic-mlb-ctx",
},
{
.ch_name = "ca6",
.cfg = {
.direction = MOST_CH_RX,
.data_type = MOST_CH_ASYNC,
.num_buffers = 20,
.buffer_size = 1522,
},
.comp_name = "cdev",
.comp_param = "inic-mlb-arx",
},
{
.ch_name = "ca8",
.cfg = {
.direction = MOST_CH_TX,
.data_type = MOST_CH_ASYNC,
.num_buffers = 20,
.buffer_size = 1522,
},
.comp_name = "cdev",
.comp_param = "inic-mlb-atx",
},

/* USB */
{
.ch_name = "ep8f",
.cfg = {
.direction = MOST_CH_RX,
.data_type = MOST_CH_CONTROL,
.num_buffers = 16,
.buffer_size = 64,
},
.comp_name = "cdev",
.comp_param = "inic-usb-crx",
},
{
.ch_name = "ep0f",
.cfg = {
.direction = MOST_CH_TX,
.data_type = MOST_CH_CONTROL,
.num_buffers = 16,
.buffer_size = 64,
},
.comp_name = "cdev",
.comp_param = "inic-usb-ctx",
},
{
.ch_name = "ep8e",
.cfg = {
.direction = MOST_CH_RX,
.data_type = MOST_CH_ASYNC,
.num_buffers = 20,
.buffer_size = 1522,
},
.comp_name = "cdev",
.comp_param = "inic-usb-arx",
},
{
.ch_name = "ep0e",
.cfg = {
.direction = MOST_CH_TX,
.data_type = MOST_CH_ASYNC,
.num_buffers = 20,
.buffer_size = 1522,
},
.comp_name = "cdev",
.comp_param = "inic-usb-atx",
},
{
.ch_name = "ep81",
.cfg = {
.direction = MOST_CH_RX,
.data_type

Re: [PATCHv4 00/12] Ion cleanup in preparation for moving out of staging

2017-04-21 Thread Sumit Semwal 
Hi Laura,

Thanks much for this series!

On 18 April 2017 at 23:57, Laura Abbott  wrote:
> Hi,
>
> This is v4 of the series to cleanup to Ion. Greg took some of the patches
> that weren't CMA related already. There was a minor bisectability problem
> with the CMA APIs so this is a new version to address that. I also
> addressed some minor comments on the patch to collapse header files.

For the series, please feel free to apply my
Acked-by: Sumit Semwal 

>
> Thanks,
> Laura
>
> Laura Abbott (12):
>   cma: Store a name in the cma structure
>   cma: Introduce cma_for_each_area
>   staging: android: ion: Use CMA APIs directly
>   staging: android: ion: Stop butchering the DMA address
>   staging: android: ion: Break the ABI in the name of forward progress
>   staging: android: ion: Get rid of ion_phys_addr_t
>   staging: android: ion: Collapse internal header files
>   staging: android: ion: Rework heap registration/enumeration
>   staging: android: ion: Drop ion_map_kernel interface
>   staging: android: ion: Remove ion_handle and ion_client
>   staging: android: ion: Set query return value
>   staging/android: Update Ion TODO list
>
>  arch/powerpc/kvm/book3s_hv_builtin.c|   3 +-
>  drivers/base/dma-contiguous.c   |   5 +-
>  drivers/staging/android/TODO|  21 +-
>  drivers/staging/android/ion/Kconfig |  32 +
>  drivers/staging/android/ion/Makefile|  11 +-
>  drivers/staging/android/ion/compat_ion.c| 152 -
>  drivers/staging/android/ion/compat_ion.h|  29 -
>  drivers/staging/android/ion/ion-ioctl.c |  55 +-
>  drivers/staging/android/ion/ion.c   | 812 
> ++--
>  drivers/staging/android/ion/ion.h   | 386 ---
>  drivers/staging/android/ion/ion_carveout_heap.c |  21 +-
>  drivers/staging/android/ion/ion_chunk_heap.c|  16 +-
>  drivers/staging/android/ion/ion_cma_heap.c  | 120 ++--
>  drivers/staging/android/ion/ion_heap.c  |  68 --
>  drivers/staging/android/ion/ion_page_pool.c |   3 +-
>  drivers/staging/android/ion/ion_priv.h  | 453 -
>  drivers/staging/android/ion/ion_system_heap.c   |  39 +-
>  drivers/staging/android/uapi/ion.h  |  36 +-
>  include/linux/cma.h |   6 +-
>  mm/cma.c|  31 +-
>  mm/cma.h|   1 +
>  mm/cma_debug.c  |   2 +-
>  22 files changed, 524 insertions(+), 1778 deletions(-)
>  delete mode 100644 drivers/staging/android/ion/compat_ion.c
>  delete mode 100644 drivers/staging/android/ion/compat_ion.h
>  delete mode 100644 drivers/staging/android/ion/ion_priv.h
>
> --
> 2.7.4
>



-- 
Thanks and regards,

Sumit Semwal
Linaro Mobile Group - Kernel Team Lead
Linaro.org │ Open source software for ARM SoCs
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}() helpers

2017-04-21 Thread Andy Shevchenko 
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: "Rafael J. Wysocki" 
Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/acpi_extlog.c | 2 +-
 drivers/acpi/apei/ghes.c   | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpi_extlog.c b/drivers/acpi/acpi_extlog.c
index 502ea4dc2080..45e299aefda7 100644
--- a/drivers/acpi/acpi_extlog.c
+++ b/drivers/acpi/acpi_extlog.c
@@ -169,7 +169,7 @@ static int extlog_print(struct notifier_block *nb, unsigned 
long val,
if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
fru_text = gdata->fru_text;
sec_type = (uuid_le *)gdata->section_type;
-   if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
+   if (!uuid_le_cmp_p(sec_type, CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem = (void *)(gdata + 1);
if (gdata->error_data_length >= sizeof(*mem))
trace_extlog_mem_event(mem, err_seq, fru_id, fru_text,
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d0855c09f32f..f2a7ee26d45f 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -431,12 +431,13 @@ static void ghes_do_proc(struct ghes *ghes,
 {
int sev, sec_sev;
struct acpi_hest_generic_data *gdata;
+   uuid_le *sec_type;
 
sev = ghes_severity(estatus->error_severity);
apei_estatus_for_each_section(estatus, gdata) {
+   sec_type = (uuid_le *)gdata->section_type;
sec_sev = ghes_severity(gdata->error_severity);
-   if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
-CPER_SEC_PLATFORM_MEM)) {
+   if (!uuid_le_cmp_p(sec_type, CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err;
mem_err = (struct cper_sec_mem_err *)(gdata+1);
ghes_edac_report_mem_error(ghes, sev, mem_err);
@@ -445,8 +446,7 @@ static void ghes_do_proc(struct ghes *ghes,
ghes_handle_memory_failure(gdata, sev);
}
 #ifdef CONFIG_ACPI_APEI_PCIEAER
-   else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
- CPER_SEC_PCIE)) {
+   else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie_err;
pcie_err = (struct cper_sec_pcie *)(gdata+1);
if (sev == GHES_SEV_RECOVERABLE &&
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 6/8] mei: Use recently introduced uuid_le_cmp_p{p}() helpers

2017-04-21 Thread Andy Shevchenko 
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: Tomas Winkler 
Signed-off-by: Andy Shevchenko 
---
 drivers/misc/mei/bus-fixup.c | 2 +-
 drivers/misc/mei/bus.c   | 2 +-
 drivers/misc/mei/client.c| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 0208c4b027c5..de0fcd98d162 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -416,7 +416,7 @@ void mei_cl_bus_dev_fixup(struct mei_cl_device *cldev)
 
f = _fixups[i];
if (uuid_le_cmp(f->uuid, MEI_UUID_ANY) == 0 ||
-   uuid_le_cmp(f->uuid, *uuid) == 0)
+   uuid_le_cmp_p(uuid, f->uuid) == 0)
f->hook(cldev);
}
 }
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index d1928fdd0f43..e15549f71891 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -615,7 +615,7 @@ struct mei_cl_device_id *mei_cl_device_find(struct 
mei_cl_device *cldev,
 
id = cldrv->id_table;
while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
-   if (!uuid_le_cmp(*uuid, id->uuid)) {
+   if (!uuid_le_cmp_p(uuid, id->uuid)) {
match = true;
 
if (cldev->name[0])
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index be64969d986a..590accb369bd 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -148,7 +148,7 @@ static struct mei_me_client *__mei_me_cl_by_uuid(struct 
mei_device *dev,
 
list_for_each_entry(me_cl, >me_clients, list) {
pn = _cl->props.protocol_name;
-   if (uuid_le_cmp(*uuid, *pn) == 0)
+   if (uuid_le_cmp_pp(uuid, pn) == 0)
return mei_me_cl_get(me_cl);
}
 
@@ -228,7 +228,7 @@ static struct mei_me_client *__mei_me_cl_by_uuid_id(struct 
mei_device *dev,
 
list_for_each_entry(me_cl, >me_clients, list) {
pn = _cl->props.protocol_name;
-   if (uuid_le_cmp(*uuid, *pn) == 0 &&
+   if (uuid_le_cmp_pp(uuid, pn) == 0 &&
me_cl->client_id == client_id)
return mei_me_cl_get(me_cl);
}
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] bus: fsl-mc: dpio: fix alter FQ state command

2017-04-21 Thread Dan Carpenter 
On Fri, Apr 21, 2017 at 01:50:24PM +, Horia Geantă wrote:
> Let me know whether keeping code similar would be preferred or not.
> 

Keeping the code similar to the surrounding is never a valid argument
but especially not in staging/.  If only 1 line is nice in the whole
file, at least that's better than nothing.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 4/8] vfio-mdev: Use recently introduced uuid_le_cmp_p{p}()

2017-04-21 Thread Andy Shevchenko 
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: Kirti Wankhede 
Cc: Alex Williamson 
Signed-off-by: Andy Shevchenko 
---
 drivers/vfio/mdev/mdev_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/vfio/mdev/mdev_core.c
index 126991046eb7..82de886855d8 100644
--- a/drivers/vfio/mdev/mdev_core.c
+++ b/drivers/vfio/mdev/mdev_core.c
@@ -75,7 +75,7 @@ static int _find_mdev_device(struct device *dev, void *data)
 
mdev = to_mdev_device(dev);
 
-   if (uuid_le_cmp(mdev->uuid, *(uuid_le *)data) == 0)
+   if (uuid_le_cmp_p(data, mdev->uuid) == 0)
return 1;
 
return 0;
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 3/8] HID: intel_ish-hid: Use recently introduced uuid_le_cmp_p{p}()

2017-04-21 Thread Andy Shevchenko 
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: Srinivas Pandruvada 
Cc: Benjamin Tissoires 
Signed-off-by: Andy Shevchenko 
---
 drivers/hid/intel-ish-hid/ishtp/bus.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c 
b/drivers/hid/intel-ish-hid/ishtp/bus.c
index 5f382fedc2ab..165e21b7ee9f 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c
@@ -138,8 +138,7 @@ int ishtp_fw_cl_by_uuid(struct ishtp_device *dev, const 
uuid_le *uuid)
int i, res = -ENOENT;
 
for (i = 0; i < dev->fw_clients_num; ++i) {
-   if (uuid_le_cmp(*uuid, dev->fw_clients[i].props.protocol_name)
-   == 0) {
+   if (!uuid_le_cmp_p(uuid, 
dev->fw_clients[i].props.protocol_name)) {
res = i;
break;
}
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 7/8] efi: Use recently introduced uuid_le_cmp_p{p}() helpers

2017-04-21 Thread Andy Shevchenko 
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Signed-off-by: Andy Shevchenko 
---
 drivers/firmware/efi/cper.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index d42537425438..7735b0f0ea90 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -402,14 +402,14 @@ static void cper_estatus_print_section(
printk("%s""fru_text: %.20s\n", pfx, gdata->fru_text);
 
snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
-   if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
+   if (!uuid_le_cmp_p(sec_type, CPER_SEC_PROC_GENERIC)) {
struct cper_sec_proc_generic *proc_err = (void *)(gdata + 1);
printk("%s""section_type: general processor error\n", newpfx);
if (gdata->error_data_length >= sizeof(*proc_err))
cper_print_proc_generic(newpfx, proc_err);
else
goto err_section_too_small;
-   } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
+   } else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err = (void *)(gdata + 1);
printk("%s""section_type: memory error\n", newpfx);
if (gdata->error_data_length >=
@@ -418,7 +418,7 @@ static void cper_estatus_print_section(
   gdata->error_data_length);
else
goto err_section_too_small;
-   } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
+   } else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie = (void *)(gdata + 1);
printk("%s""section_type: PCIe error\n", newpfx);
if (gdata->error_data_length >= sizeof(*pcie))
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 2/8] ASoC: Intel: Skylake: Use recently introduced uuid_le_cmp_p{p}()

2017-04-21 Thread Andy Shevchenko 
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Vinod Koul 
Signed-off-by: Andy Shevchenko 
---
 sound/soc/intel/skylake/skl-pcm.c   | 2 +-
 sound/soc/intel/skylake/skl-sst-utils.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/sound/soc/intel/skylake/skl-pcm.c 
b/sound/soc/intel/skylake/skl-pcm.c
index 600faad19bd4..4bf171985872 100644
--- a/sound/soc/intel/skylake/skl-pcm.c
+++ b/sound/soc/intel/skylake/skl-pcm.c
@@ -1207,7 +1207,7 @@ static int skl_get_module_info(struct skl *skl, struct 
skl_module_cfg *mconfig)
}
 
list_for_each_entry(module, >uuid_list, list) {
-   if (uuid_le_cmp(*uuid_mod, module->uuid) == 0) {
+   if (uuid_le_cmp_p(uuid_mod, module->uuid) == 0) {
mconfig->id.module_id = module->id;
mconfig->is_loadable = module->is_loadable;
return 0;
diff --git a/sound/soc/intel/skylake/skl-sst-utils.c 
b/sound/soc/intel/skylake/skl-sst-utils.c
index 6d5bff04bf65..67288580c743 100644
--- a/sound/soc/intel/skylake/skl-sst-utils.c
+++ b/sound/soc/intel/skylake/skl-sst-utils.c
@@ -189,7 +189,7 @@ int skl_get_pvt_id(struct skl_sst *ctx, uuid_le *uuid_mod, 
int instance_id)
int pvt_id;
 
list_for_each_entry(module, >uuid_list, list) {
-   if (uuid_le_cmp(*uuid_mod, module->uuid) == 0) {
+   if (uuid_le_cmp_p(uuid_mod, module->uuid) == 0) {
 
pvt_id = skl_pvtid_128(module);
if (pvt_id >= 0) {
@@ -218,7 +218,7 @@ int skl_put_pvt_id(struct skl_sst *ctx, uuid_le *uuid_mod, 
int *pvt_id)
struct uuid_module *module;
 
list_for_each_entry(module, >uuid_list, list) {
-   if (uuid_le_cmp(*uuid_mod, module->uuid) == 0) {
+   if (uuid_le_cmp_p(uuid_mod, module->uuid) == 0) {
 
if (*pvt_id != 0)
i = (*pvt_id) / 64;
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 1/8] lib/uuid: Introduce uuid_{be|le}_cmp_p{p}() helpers

2017-04-21 Thread Andy Shevchenko 
New helpers take pointers to uuid_{be|le} as parameters.

When using them on a raw data we don't need to do an ugly dereference
and, in some cases, a type casting.

Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Vinod Koul 
Cc: Srinivas Pandruvada 
Cc: Benjamin Tissoires 
Cc: Kirti Wankhede 
Cc: Alex Williamson 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Tomas Winkler 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: "Rafael J. Wysocki" 

Signed-off-by: Andy Shevchenko 
---
 include/linux/uuid.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index 4dff73a89758..45312cb5ac65 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -58,6 +58,26 @@ static inline int uuid_be_cmp(const uuid_be u1, const 
uuid_be u2)
return memcmp(, , sizeof(uuid_be));
 }
 
+static inline int uuid_le_cmp_p(const uuid_le *pu1, const uuid_le u2)
+{
+   return memcmp(pu1, , sizeof(uuid_le));
+}
+
+static inline int uuid_be_cmp_p(const uuid_be *pu1, const uuid_be u2)
+{
+   return memcmp(pu1, , sizeof(uuid_be));
+}
+
+static inline int uuid_le_cmp_pp(const uuid_le *pu1, const uuid_le *pu2)
+{
+   return memcmp(pu1, pu2, sizeof(uuid_le));
+}
+
+static inline int uuid_be_cmp_pp(const uuid_be *pu1, const uuid_be *pu2)
+{
+   return memcmp(pu1, pu2, sizeof(uuid_be));
+}
+
 void generate_random_uuid(unsigned char uuid[16]);
 
 extern void uuid_le_gen(uuid_le *u);
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1 5/8] vmbus: Use recently introduced uuid_le_cmp_p{p}() helpers

2017-04-21 Thread Andy Shevchenko 
Recently introduced helpers take pointers to uuid_{be|le} instead of
reference.

Using them makes code less ugly.

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Signed-off-by: Andy Shevchenko 
---
 drivers/hv/channel_mgmt.c | 10 +-
 drivers/hv/vmbus_drv.c|  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 735f9363f2e4..01570c50ed04 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -176,7 +176,7 @@ static bool is_unsupported_vmbus_devs(const uuid_le *guid)
int i;
 
for (i = 0; i < ARRAY_SIZE(vmbus_unsupported_devs); i++)
-   if (!uuid_le_cmp(*guid, vmbus_unsupported_devs[i].guid))
+   if (!uuid_le_cmp_p(guid, vmbus_unsupported_devs[i].guid))
return true;
return false;
 }
@@ -190,7 +190,7 @@ static u16 hv_get_dev_type(const struct vmbus_channel 
*channel)
return HV_UNKNOWN;
 
for (i = HV_IDE; i < HV_UNKNOWN; i++) {
-   if (!uuid_le_cmp(*guid, vmbus_devs[i].guid))
+   if (!uuid_le_cmp_p(guid, vmbus_devs[i].guid))
return i;
}
pr_info("Unknown GUID: %pUl\n", guid);
@@ -456,9 +456,9 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
 
list_for_each_entry(channel, _connection.chn_list, listentry) {
if (!uuid_le_cmp(channel->offermsg.offer.if_type,
-   newchannel->offermsg.offer.if_type) &&
-   !uuid_le_cmp(channel->offermsg.offer.if_instance,
-   newchannel->offermsg.offer.if_instance)) {
+newchannel->offermsg.offer.if_type) &&
+   !uuid_le_cmp(channel->offermsg.offer.if_instance,
+newchannel->offermsg.offer.if_instance)) {
fnew = false;
break;
}
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index 0087b49095eb..b41a2be778f6 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -557,7 +557,7 @@ static const struct hv_vmbus_device_id 
*hv_vmbus_get_id(struct hv_driver *drv,
/* Look at the dynamic ids first, before the static ones */
spin_lock(>dynids.lock);
list_for_each_entry(dynid, >dynids.list, node) {
-   if (!uuid_le_cmp(dynid->id.guid, *guid)) {
+   if (!uuid_le_cmp_p(guid, dynid->id.guid)) {
id = >id;
break;
}
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] bus: fsl-mc: dpio: fix alter FQ state command

2017-04-21 Thread Horia Geantă 
On 4/21/2017 4:31 PM, Stuart Yoder wrote:
> On Fri, Apr 21, 2017 at 7:00 AM, Horia Geantă  wrote:
>>
>> When checking the response verb, the valid bit should be masked out,
>> since its value flips depending on what Response Register
>> (RR0 /RR1) it's been read from.
>>
>> Fixes: 321eecb06bfb ("bus: fsl-mc: dpio: add QBMan portal APIs for DPAA2")
>> Signed-off-by: Horia Geantă 
>> ---
>>  drivers/staging/fsl-mc/bus/dpio/qbman-portal.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c 
>> b/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
>> index 2a3ea29d9b43..5d020fb98c66 100644
>> --- a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
>> +++ b/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
>> @@ -963,7 +963,7 @@ int qbman_swp_alt_fq_state(struct qbman_swp *s, u32 fqid,
>> }
>>
>> /* Decode the outcome */
>> -   WARN_ON(r->verb != alt_fq_verb);
>> +   WARN_ON((r->verb & 0x7f) != alt_fq_verb);
> 
> Don't use magic constants like that.  Create a #define for the valid bit.
> 
Just looking at the surrounding code, this seems the preferred way to
mask the valid bit.

Though there are two defines that could be used in this case:
#define QB_VALID_BIT ((u32)0x80)
#define QBMAN_RESULT_MASK  0x7f

Let me know whether keeping code similar would be preferred or not.

Thanks,
Horia

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] bus: fsl-mc: dpio: fix alter FQ state command

2017-04-21 Thread Stuart Yoder 
On Fri, Apr 21, 2017 at 7:00 AM, Horia Geantă  wrote:
>
> When checking the response verb, the valid bit should be masked out,
> since its value flips depending on what Response Register
> (RR0 /RR1) it's been read from.
>
> Fixes: 321eecb06bfb ("bus: fsl-mc: dpio: add QBMan portal APIs for DPAA2")
> Signed-off-by: Horia Geantă 
> ---
>  drivers/staging/fsl-mc/bus/dpio/qbman-portal.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c 
> b/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
> index 2a3ea29d9b43..5d020fb98c66 100644
> --- a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
> +++ b/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
> @@ -963,7 +963,7 @@ int qbman_swp_alt_fq_state(struct qbman_swp *s, u32 fqid,
> }
>
> /* Decode the outcome */
> -   WARN_ON(r->verb != alt_fq_verb);
> +   WARN_ON((r->verb & 0x7f) != alt_fq_verb);

Don't use magic constants like that.  Create a #define for the valid bit.

Thanks,
Stuart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] bus: fsl-mc: dpio: fix alter FQ state command

2017-04-21 Thread Horia Geantă 
When checking the response verb, the valid bit should be masked out,
since its value flips depending on what Response Register
(RR0 /RR1) it's been read from.

Fixes: 321eecb06bfb ("bus: fsl-mc: dpio: add QBMan portal APIs for DPAA2")
Signed-off-by: Horia Geantă 
---
 drivers/staging/fsl-mc/bus/dpio/qbman-portal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c 
b/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
index 2a3ea29d9b43..5d020fb98c66 100644
--- a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
+++ b/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
@@ -963,7 +963,7 @@ int qbman_swp_alt_fq_state(struct qbman_swp *s, u32 fqid,
}
 
/* Decode the outcome */
-   WARN_ON(r->verb != alt_fq_verb);
+   WARN_ON((r->verb & 0x7f) != alt_fq_verb);
 
/* Determine success or failure */
if (unlikely(r->rslt != QBMAN_MC_RSLT_OK)) {
-- 
2.12.0.264.gd6db3f216544

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: atomisp: remove #ifdef for runtime PM functions

2017-04-21 Thread Arnd Bergmann 
The runtime power management functions are called from the reset handler even
if CONFIG_PM is disabled, leading to a link error:

drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd1c): undefined reference to `atomisp_runtime_suspend'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd3a): undefined reference to `atomisp_mrfld_power_down'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd58): undefined reference to `atomisp_mrfld_power_up'
drivers/staging/built-in.o: In function `atomisp_reset':
(.text+0x4cd77): undefined reference to `atomisp_runtime_resume'

Removing the #ifdef around the PM functions avoids the problem, and
lets us simplify it further. The __maybe_unused annotation is needed
to ensure the compiler can silently drop the unused callbacks.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 9bd186bad1bd..9b4508e731f3 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -310,7 +310,6 @@ static int __maybe_unused atomisp_restore_iunit_reg(struct 
atomisp_device *isp)
return 0;
 }
 
-#ifdef CONFIG_PM
 static int atomisp_mrfld_pre_power_down(struct atomisp_device *isp)
 {
struct pci_dev *dev = isp->pdev;
@@ -550,7 +549,7 @@ int atomisp_runtime_resume(struct device *dev)
return 0;
 }
 
-static int atomisp_suspend(struct device *dev)
+static int __maybe_unused atomisp_suspend(struct device *dev)
 {
struct atomisp_device *isp = (struct atomisp_device *)
dev_get_drvdata(dev);
@@ -588,7 +587,7 @@ static int atomisp_suspend(struct device *dev)
return atomisp_mrfld_power_down(isp);
 }
 
-static int atomisp_resume(struct device *dev)
+static int __maybe_unused atomisp_resume(struct device *dev)
 {
struct atomisp_device *isp = (struct atomisp_device *)
dev_get_drvdata(dev);
@@ -614,7 +613,6 @@ static int atomisp_resume(struct device *dev)
atomisp_freq_scaling(isp, ATOMISP_DFS_MODE_LOW, true);
return 0;
 }
-#endif
 
 int atomisp_csi_lane_config(struct atomisp_device *isp)
 {
@@ -1576,7 +1574,6 @@ static const struct pci_device_id atomisp_pci_tbl[] = {
 
 MODULE_DEVICE_TABLE(pci, atomisp_pci_tbl);
 
-#ifdef CONFIG_PM
 static const struct dev_pm_ops atomisp_pm_ops = {
.runtime_suspend = atomisp_runtime_suspend,
.runtime_resume = atomisp_runtime_resume,
@@ -1584,14 +1581,9 @@ static const struct dev_pm_ops atomisp_pm_ops = {
.resume = atomisp_resume,
 };
 
-#define DEV_PM_OPS (_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif
-
 static struct pci_driver atomisp_pci_driver = {
.driver = {
-   .pm = DEV_PM_OPS,
+   .pm = _pm_ops,
},
.name = "atomisp-isp2",
.id_table = atomisp_pci_tbl,
-- 
2.9.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: atomisp: satm include directory is gone

2017-04-21 Thread Arnd Bergmann 
After the satm kernel was removed, we should no longer add the directory
to the search path. This was found with a 'make W=1' warning:

cc1: error: 
drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/satm/: No such 
file or directory [-Werror=missing-include-dirs]

Fixes: 184f8e0981ef ("atomisp: remove satm kernel")
Signed-off-by: Arnd Bergmann 
---
 drivers/staging/media/atomisp/pci/atomisp2/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile 
b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
index 96a7bd0fa96e..5e8646c976a6 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile
+++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile
@@ -301,7 +301,6 @@ INCLUDES += \
-I$(atomisp)/css2400/isp/kernels/s3a/ \
-I$(atomisp)/css2400/isp/kernels/s3a/s3a_1.0/ \
-I$(atomisp)/css2400/isp/kernels/s3a_stat_ls/ \
-   -I$(atomisp)/css2400/isp/kernels/satm/ \
-I$(atomisp)/css2400/isp/kernels/scale/ \
-I$(atomisp)/css2400/isp/kernels/scale/scale_1.0/ \
-I$(atomisp)/css2400/isp/kernels/sc/ \
-- 
2.9.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

2017-04-21 Thread Greg KH 

Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


http://daringfireball.net/2007/07/on_top

On Fri, Apr 21, 2017 at 12:40:25AM -0700, Chandra Annamaneni wrote:
> 
> Third Reminder. Please review.

2 days after you asked before?

And I don't even see this patch in my queue, are you sure it hasn't
already been handled, or merged, or rejected?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v3] Staging: most: use __func__ instead of the function name

2017-04-21 Thread Chandra Annamaneni 

Third Reminder. Please review.

--
Chandra


On Sun, 9 Apr 2017, chandrasekhar annamaneni wrote:

> 
> Second reminder, please review.
> 
> Thanks.
> Chandra
> 
> 
> On Fri, Mar 17, 2017 at 12:49 PM, Chandra Annamaneni 
> wrote:
> 
>   Change video.c to use %s, __func__ instead of function names.
>   Warnings flagged by checkpatch.pl
> 
>   Signed-off-by: Chandra Annamaneni 
> 
>   diff --git a/drivers/staging/most/aim-v4l2/video.c
>   b/drivers/staging/most/aim-v4l2/video.c
>   index e074841..59e861e 100644
>   --- a/drivers/staging/most/aim-v4l2/video.c
>   +++ b/drivers/staging/most/aim-v4l2/video.c
>   @@ -79,7 +79,7 @@ static int aim_vdev_open(struct file *filp)
>           struct most_video_dev *mdev = video_drvdata(filp);
>           struct aim_fh *fh;
> 
>   -       v4l2_info(>v4l2_dev, "aim_vdev_open()\n");
>   +       v4l2_info(>v4l2_dev, "%s()\n", __func__);
> 
>           switch (vdev->vfl_type) {
>           case VFL_TYPE_GRABBER:
>   @@ -128,7 +128,7 @@ static int aim_vdev_close(struct file *filp)
>           struct most_video_dev *mdev = fh->mdev;
>           struct mbo *mbo, *tmp;
> 
>   -       v4l2_info(>v4l2_dev, "aim_vdev_close()\n");
>   +       v4l2_info(>v4l2_dev, "%s()\n", __func__);
> 
>           /*
>            * We need to put MBOs back before we call
>   most_stop_channel()
>   @@ -324,7 +324,7 @@ static int vidioc_g_std(struct file *file,
>   void *priv, v4l2_std_id *norm)
>           struct aim_fh *fh = priv;
>           struct most_video_dev *mdev = fh->mdev;
> 
>   -       v4l2_info(>v4l2_dev, "vidioc_g_std()\n");
>   +       v4l2_info(>v4l2_dev, "%s()\n", __func__);
> 
>           *norm = V4L2_STD_UNKNOWN;
>           return 0;
>   @@ -361,7 +361,7 @@ static int vidioc_s_input(struct file *file,
>   void *priv, unsigned int index)
>           struct aim_fh *fh = priv;
>           struct most_video_dev *mdev = fh->mdev;
> 
>   -       v4l2_info(>v4l2_dev, "vidioc_s_input(%d)\n",
>   index);
>   +       v4l2_info(>v4l2_dev, "%s(%d)\n", __func__, index);
> 
>           if (index >= V4L2_AIM_MAX_INPUT)
>                   return -EINVAL;
>   @@ -441,7 +441,7 @@ static int aim_register_videodev(struct
>   most_video_dev *mdev)
>    {
>           int ret;
> 
>   -       v4l2_info(>v4l2_dev, "aim_register_videodev()\n");
>   +       v4l2_info(>v4l2_dev, "%s()\n", __func__);
> 
>           init_waitqueue_head(>wait_data);
> 
>   @@ -471,7 +471,7 @@ static int aim_register_videodev(struct
>   most_video_dev *mdev)
> 
>    static void aim_unregister_videodev(struct most_video_dev
>   *mdev)
>    {
>   -       v4l2_info(>v4l2_dev,
>   "aim_unregister_videodev()\n");
>   +       v4l2_info(>v4l2_dev, "%s()\n", __func__);
> 
>           video_unregister_device(mdev->vdev);
>    }
> 
> 
> 
> ___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel