[PATCH v3] staging: gdm724x: update HCI structs with new bitwise types
Update the driver's HCI structs and associated endian-converter
functions with new driver-specific bitwise types. The new types
encourage correct endian-handling within the driver by triggering
sparse warnings when mixing with other types. The driver's
endian-converters provide correct and warning-free conversions.
Driver-specific bitwise types are used instead of the standard
endian-specific types because the attached device can be of either
endian. This is also why the driver has its own endian-conversion
functions, which consider endianness of both the cpu and the attached
device.
Introducing the new types to the converters fixes the sparse warnings:
CHECK drivers/staging/gdm724x/gdm_endian.c
drivers/staging/gdm724x/gdm_endian.c:28:24: warning: incorrect type in return
expression (different base types)
drivers/staging/gdm724x/gdm_endian.c:28:24:expected unsigned short
drivers/staging/gdm724x/gdm_endian.c:28:24:got restricted __le16 [usertype]
drivers/staging/gdm724x/gdm_endian.c:30:24: warning: incorrect type in return
expression (different base types)
drivers/staging/gdm724x/gdm_endian.c:30:24:expected unsigned short
drivers/staging/gdm724x/gdm_endian.c:30:24:got restricted __be16 [usertype]
drivers/staging/gdm724x/gdm_endian.c:36:24: warning: cast to restricted __le16
drivers/staging/gdm724x/gdm_endian.c:38:24: warning: cast to restricted __be16
drivers/staging/gdm724x/gdm_endian.c:44:24: warning: incorrect type in return
expression (different base types)
drivers/staging/gdm724x/gdm_endian.c:44:24:expected unsigned int
drivers/staging/gdm724x/gdm_endian.c:44:24:got restricted __le32 [usertype]
drivers/staging/gdm724x/gdm_endian.c:46:24: warning: incorrect type in return
expression (different base types)
drivers/staging/gdm724x/gdm_endian.c:46:24:expected unsigned int
drivers/staging/gdm724x/gdm_endian.c:46:24:got restricted __be32 [usertype]
drivers/staging/gdm724x/gdm_endian.c:52:24: warning: cast to restricted __le32
drivers/staging/gdm724x/gdm_endian.c:54:24: warning: cast to restricted __be32
Signed-off-by: Eric S. Stone
---
Notes:
v3:
- new summary: "staging: gdm724x: update HCI structs with new bitwise
types"
- introduce new bitwise types to clarify endian considerations
throughout driver. Focus of patch shifts to this, not the sparse
warnings that helped highlight the issue.
- fix sparse warnings in endian-converters using forced casts
v2:
- new summary: "staging: gdm724x: use different endian converters to fix
sparse warnings"
- fix sparse warnings instead by using mutating endian converters
v1:
- summary: "staging: gdm724x: add forced casts in endian converters to
fix sparse warnings"
- add forced casts in endian-converters to fix sparse warnings
drivers/staging/gdm724x/gdm_endian.c | 24 +--
drivers/staging/gdm724x/gdm_endian.h | 15
drivers/staging/gdm724x/hci_packet.h | 46 ++--
3 files changed, 46 insertions(+), 39 deletions(-)
diff --git a/drivers/staging/gdm724x/gdm_endian.c
b/drivers/staging/gdm724x/gdm_endian.c
index d7144e7..d0b43e2 100644
--- a/drivers/staging/gdm724x/gdm_endian.c
+++ b/drivers/staging/gdm724x/gdm_endian.c
@@ -22,34 +22,34 @@ void gdm_set_endian(struct gdm_endian *ed, u8 dev_endian)
ed->dev_ed = ENDIANNESS_LITTLE;
}
-u16 gdm_cpu_to_dev16(struct gdm_endian *ed, u16 x)
+__dev16 gdm_cpu_to_dev16(struct gdm_endian *ed, u16 x)
{
if (ed->dev_ed == ENDIANNESS_LITTLE)
- return cpu_to_le16(x);
+ return (__force __dev16)cpu_to_le16(x);
else
- return cpu_to_be16(x);
+ return (__force __dev16)cpu_to_be16(x);
}
-u16 gdm_dev16_to_cpu(struct gdm_endian *ed, u16 x)
+u16 gdm_dev16_to_cpu(struct gdm_endian *ed, __dev16 x)
{
if (ed->dev_ed == ENDIANNESS_LITTLE)
- return le16_to_cpu(x);
+ return le16_to_cpu((__force __le16)x);
else
- return be16_to_cpu(x);
+ return be16_to_cpu((__force __be16)x);
}
-u32 gdm_cpu_to_dev32(struct gdm_endian *ed, u32 x)
+__dev32 gdm_cpu_to_dev32(struct gdm_endian *ed, u32 x)
{
if (ed->dev_ed == ENDIANNESS_LITTLE)
- return cpu_to_le32(x);
+ return (__force __dev32)cpu_to_le32(x);
else
- return cpu_to_be32(x);
+ return (__force __dev32)cpu_to_be32(x);
}
-u32 gdm_dev32_to_cpu(struct gdm_endian *ed, u32 x)
+u32 gdm_dev32_to_cpu(struct gdm_endian *ed, __dev32 x)
{
if (ed->dev_ed == ENDIANNESS_LITTLE)
- return le32_to_cpu(x);
+ return le32_to_cpu((__force __le32)x);
else
- return be32_to_cpu(x);
+ return be32_to_cpu((__force __be32)x);
}
diff --git a/drivers/staging/gdm724x/gdm_endian.h
b/drivers/staging/gdm724x/gdm_endian.h
index 6177870..a785f30 10064
[v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
Make uniform definition of ioremap, ioremap_wc, ioremap_wt and ioremap_cache, tree-wide. Signed-off-by: Arvind Yadav --- drivers/staging/i4l/act2000/act2000.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/i4l/act2000/act2000.h b/drivers/staging/i4l/act2000/act2000.h index 321d437..e372ff5 100644 --- a/drivers/staging/i4l/act2000/act2000.h +++ b/drivers/staging/i4l/act2000/act2000.h @@ -70,7 +70,7 @@ #include #include #include -#include +#include #include #include #include -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[v1] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
Make uniform definition of ioremap, ioremap_wc, ioremap_wt and ioremap_cache, tree-wide. Signed-off-by: Arvind Yadav --- drivers/staging/rtl8192u/r8192U.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8192u/r8192U.h b/drivers/staging/rtl8192u/r8192U.h index 0b7b04e..c078659 100644 --- a/drivers/staging/rtl8192u/r8192U.h +++ b/drivers/staging/rtl8192u/r8192U.h @@ -34,7 +34,7 @@ #include #include #include -#include +#include #include "ieee80211/ieee80211.h" #define RTL8192U -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv: use substraction to update ring buffer index
On Wed, Jan 04, 2017 at 08:08:22PM -0800, Long Li wrote: > From: Long Li > > The ring buffer code uses %= to calculate index. For x86/64, %= compiles to > div, more than 10 times slower than sub. > > Replace div with sub for this data heavy code path. > > Signed-off-by: Long Li > --- > drivers/hv/ring_buffer.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c > index cd49cb1..f8eee6e 100644 > --- a/drivers/hv/ring_buffer.c > +++ b/drivers/hv/ring_buffer.c > @@ -135,7 +135,8 @@ hv_get_next_readlocation_withoffset(struct > hv_ring_buffer_info *ring_info, > u32 next = ring_info->ring_buffer->read_index; > > next += offset; > - next %= ring_info->ring_datasize; > + if (next >= ring_info->ring_datasize) > + next -= ring_info->ring_datasize; I take it that we trust that offset is roughly correct and not more than 2x ring_info->ring_datasize? I guess there is only one caller so it's probably true... > > return next; > } > @@ -179,7 +180,8 @@ static u32 hv_copyfrom_ringbuffer( > memcpy(dest, ring_buffer + start_read_offset, destlen); > > start_read_offset += destlen; > - start_read_offset %= ring_buffer_size; > + if (start_read_offset >= ring_buffer_size) > + start_read_offset -= ring_buffer_size; I totally don't understand the original code here. We do the memset and then we verify that we are not copying beyond the end of the ring buffer? If feels like we should verify that offset + destlen aren't more than ring_buffer_size before we do the memcpy(). regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
On Thu, Jan 05, 2017 at 04:09:24PM +0530, Arvind Yadav wrote: > Make uniform definition of ioremap, ioremap_wc, ioremap_wt and > ioremap_cache, tree-wide. That doesn't make much sense, and doesn't match the subject: or the patch itself. And what is with the "[v1]"? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [v1] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
On Thu, Jan 05, 2017 at 04:15:03PM +0530, Arvind Yadav wrote: > Make uniform definition of ioremap, ioremap_wc, ioremap_wt and > ioremap_cache, tree-wide. Same complaint about text here as well... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] hv: use substraction to update ring buffer index
On Thu, Jan 05, 2017 at 02:39:55PM +0300, Dan Carpenter wrote: > > @@ -179,7 +180,8 @@ static u32 hv_copyfrom_ringbuffer( > > memcpy(dest, ring_buffer + start_read_offset, destlen); > > > > start_read_offset += destlen; > > - start_read_offset %= ring_buffer_size; > > + if (start_read_offset >= ring_buffer_size) > > + start_read_offset -= ring_buffer_size; > > I totally don't understand the original code here. We do the memset I meant memcpy() not memset. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
Please find my comment below. Thanks -Arvind On Thursday 05 January 2017 05:16 PM, Greg KH wrote: On Thu, Jan 05, 2017 at 04:09:24PM +0530, Arvind Yadav wrote: Make uniform definition of ioremap, ioremap_wc, ioremap_wt and ioremap_cache, tree-wide. That doesn't make much sense, and doesn't match the subject: or the patch itself. -- Please refer the commit which is already in main-lined. commit 2584cf83578c26db144730ef498f4070f82ee3ea And what is with the "[v1]"? ---V1 is stands for patch set version 1 thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
On Thu, Jan 05, 2017 at 05:25:05PM +0530, Arvind Yadav wrote: > Please find my comment below. Where? What happened to your email quoting? > Thanks > -Arvind > > On Thursday 05 January 2017 05:16 PM, Greg KH wrote: > > On Thu, Jan 05, 2017 at 04:09:24PM +0530, Arvind Yadav wrote: > > > Make uniform definition of ioremap, ioremap_wc, ioremap_wt and > > > ioremap_cache, tree-wide. > > That doesn't make much sense, and doesn't match the subject: or the > > patch itself. > > -- Please refer the commit which is already in main-lined. > > commit 2584cf83578c26db144730ef498f4070f82ee3ea Ah, here it is, please quote stuff correctly. If you are referring to something else, great, then say so in the commit itself. Every commit should be self-explanatory, how am I supposed to know this. And this text still doesn't make sense to me, please fix. > > And what is with the "[v1]"? > > ---V1 is stands for patch set version 1 Please read Documentation/SubmittingPatches for how to properly label patches, don't make new things up, we have too many different developers (i.e. 4000+) for everyone to do their own unique thing. :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wilc1000: Connect to highest RSSI value for required SSID
On Thu, Jan 05, 2017 at 01:03:41PM +0530, Aditya Shankar wrote:
> Connect to the highest rssi with the required SSID in the shadow
> table if the connection criteria is based only on the SSID.
> For the first matching SSID, an index to the table is saved.
> Later the index is updated if matching SSID has a higher
> RSSI value than the last saved index.
>
> However if decision is made based on BSSID, there is only one match
> in the table and corresponding index is used.
>
> Signed-off-by: Aditya Shankar
> ---
> drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 20 ++--
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> index c1a24f7..32206b8 100644
> --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
> @@ -665,6 +665,7 @@ static int connect(struct wiphy *wiphy, struct net_device
> *dev,
> {
> s32 s32Error = 0;
> u32 i;
> + u32 sel_bssi_idx = last_scanned_cnt + 1;
My understanding from reading the code is that "last_scanned_cnt + 1"
is a randomly chosen invalid value. Just saying:
sel_bssi_idx = last_scanned_cnt;
would also work because it's also invalid and slightly shorter to type.
But I suggest that you go with something like UINT_MAX because that's
more clearly invalid.
> u8 u8security = NO_ENCRYPT;
> enum AUTHTYPE tenuAuth_type = ANY;
>
> @@ -688,18 +689,25 @@ static int connect(struct wiphy *wiphy, struct
> net_device *dev,
> memcmp(last_scanned_shadow[i].ssid,
> sme->ssid,
> sme->ssid_len) == 0) {
> - if (!sme->bssid)
> - break;
> - else
> + if (!sme->bssid) {
> + if (sel_bssi_idx == (last_scanned_cnt + 1))
> + sel_bssi_idx = i;
> + else if (last_scanned_shadow[i].rssi >
> + last_scanned_shadow[sel_bssi_idx].rssi)
> + sel_bssi_idx = i;
Combine these with an ||.
if (!sme->bssid) {
if (sel_bssi_idx == UINT_MAX ||
last_scanned_shadow[i].rssi >
last_scanned_shadow[sel_bssi_idx].rssi)
sel_bssi_idx = i;
In a separate patch, you can reverse the if statement at the start of
the loop:
if (sme->ssid_len != last_scanned_shadow[i].ssid_len ||
memcmp(last_scanned_shadow[i].ssid, sme->ssid,
sme->ssid_len) != 0)
continue;
That way you can pull these lines in a tab.
> + } else {
> if (memcmp(last_scanned_shadow[i].bssid,
> sme->bssid,
> -ETH_ALEN) == 0)
> +ETH_ALEN) == 0){
Add a space before the curly brace.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 4/4] hv_util: improve time adjustment accuracy by disabling interrupts
Stephen Hemminger writes: > On Wed, 4 Jan 2017 18:24:39 +0100 > Vitaly Kuznetsov wrote: > >> If we happen to receive interrupts during hv_set_host_time() execution >> our adjustments may get inaccurate. Make the whole function atomic. >> Unfortunately, we can's call do_settimeofday64() with interrupts >> disabled as some cross-CPU work is being done but this call happens >> very rarely. >> >> Signed-off-by: Vitaly Kuznetsov > > Ok, the race is between timer interrupts and calling do_adjtimex(). > NTP has the same issue already. > > The getnstimeofday64() (or ktime_get) return an atomic value. > If a clock tick interrupt happens during this code, then the value > is still correct just old. > > If you want to avoid all races here, it looks like it would > be better to get timekeeper_lock and call __do_adjtimex. The existing > code in do_adjtimex() is expecting to be called from a system call > and changing it's assumptions is probably not a good idea. > I was thinking about it but to me what do_adjtimex() does looks too low-level for drivers (e.g. calling write_seqcount_begin(), __timekeeping_set_tai_offset(), tk_update_leap_state()). To me (again, I probably know not that much about time keeping) it looks like we'll have to have all this stuff around the __do_adjtimex() call here. Are there any particular concearns on calling do_adjtimex() directly? Yes, it was written for syscalls but I don't see any other required things in adjtimex syscall, it's just a straitforward copy_from_user() -> do_adjtimex() -> copy_to_user() chain. I would very much appreciate if Thomas or John could comment what's better here long-term. > Rather than calling system call from user space. Maybe better > to provide real kernel API in time subsystem for this use case. > What does KVM do? KVM doesn't have an NTP-like service, it just provides kvm_clock (which, BTW, implements VCLOCK_PVCLOCK for vDSO calls -- unlike Hyper-V's TSC page). hv_utils is going to be the first in-kernel 'NTP'. -- Vitaly ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/4] hv_util: use do_adjtimex() to update system time
Stephen Hemminger writes:
> On Wed, 4 Jan 2017 18:24:38 +0100
> Vitaly Kuznetsov wrote:
>
>> With TimeSync version 4 protocol support we started updating system time
>> continuously through the whole lifetime of Hyper-V guests. Every 5 seconds
>> there is a time sample from the host which triggers do_settimeofday[64]().
>> While the time from the host is very accurate such adjustments may cause
>> issues:
>> - Time is jumping forward and backward, some applications may misbehave.
>> - In case an NTP client is run in parallel things may go south, e.g. when
>> an NTP client tries to adjust tick/frequency with ADJ_TICK/ADJ_FREQUENCY
>> the Hyper-V module will not see this changes and time will oscillate and
>> never converge.
>> - Systemd starts annoying you by printing "Time has been changed" every 5
>> seconds to the system log.
>>
>> Instead of calling do_settimeofday64() we can pretend being an NTP client
>> and use do_adjtimex(). Do do_settimeofday64() in case the difference is too
>> big or ICTIMESYNCFLAG_SYNC flag was set in the request.
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> Changes since v1:
>> - do do_settimeofday64() when ICTIMESYNCFLAG_SYNC flag is present in the
>> request (Alex Ng)
>> - add pr_debug() for the case when do_adjtimex() fails (Alex Ng)
>> ---
>> drivers/hv/hv_util.c | 32 +---
>> 1 file changed, 29 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
>> index 94719eb..7e97231 100644
>> --- a/drivers/hv/hv_util.c
>> +++ b/drivers/hv/hv_util.c
>> @@ -182,9 +182,11 @@ struct adj_time_work {
>> static void hv_set_host_time(struct work_struct *work)
>> {
>> struct adj_time_work*wrk;
>> -s64 host_tns;
>> +s64 host_tns, our_tns, delta;
>> u64 newtime;
>> -struct timespec64 host_ts;
>> +struct timespec64 host_ts, our_ts;
>> +struct timex txc = {0};
>> +int ret;
>>
>> wrk = container_of(work, struct adj_time_work, work);
>>
>> @@ -205,7 +207,31 @@ static void hv_set_host_time(struct work_struct *work)
>> host_tns = (newtime - WLTIMEDELTA) * 100;
>> host_ts = ns_to_timespec64(host_tns);
>>
>> -do_settimeofday64(&host_ts);
>> +getnstimeofday64(&our_ts);
>> +our_tns = timespec64_to_ns(&our_ts);
>> +
>> +/* Difference between our time and host time */
>> +delta = host_tns - our_tns;
>
> This looks correct to me.
> Did you consider using ktime? It provides a cleaner abstraction for handling
> nanosecond time resolution.
I see. While s64 should work ktime seems preferable. I'll give it a try.
--
Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: ks7010: style fix, long lines
On Thu, Jan 05, 2017 at 12:56:16PM +1300, Derek Robson wrote: > Debug code had very long lines. > Reworked code to use several prints rather than one big print. > > Signed-off-by: Derek Robson > --- > drivers/staging/ks7010/ks_hostif.c | 32 +--- > 1 file changed, 25 insertions(+), 7 deletions(-) > > diff --git a/drivers/staging/ks7010/ks_hostif.c > b/drivers/staging/ks7010/ks_hostif.c > index 1fbd495e5e63..70f8565acbeb 100644 > --- a/drivers/staging/ks7010/ks_hostif.c > +++ b/drivers/staging/ks7010/ks_hostif.c > @@ -190,13 +190,31 @@ int get_current_ap(struct ks_wlan_private *priv, struct > link_ap_info_t *ap_info) > wireless_send_event(netdev, SIOCGIWAP, &wrqu, NULL); > } > DPRINTK(4, "\nLink AP\n"); > - DPRINTK(4, "bssid=%02X:%02X:%02X:%02X:%02X:%02X\n \ > - essid=%s\nrate_set=%02X,%02X,%02X,%02X,%02X,%02X,%02X,%02X\n > channel=%d\n \ > - rssi=%d\nsq=%d\ncapability=%04X\n", ap->bssid[0], ap->bssid[1], > ap->bssid[2], ap->bssid[3], ap->bssid[4], ap->bssid[5], &(ap->ssid.body[0]), > ap->rate_set.body[0], ap->rate_set.body[1], ap->rate_set.body[2], > ap->rate_set.body[3], ap->rate_set.body[4], ap->rate_set.body[5], > ap->rate_set.body[6], ap->rate_set.body[7], ap->channel, ap->rssi, ap->sq, > ap->capability); > - DPRINTK(4, "\nLink AP\nrsn.mode=%d\nrsn.size=%d\n", > - ap_info->rsn_mode, ap_info->rsn.size); > - DPRINTK(4, "\next_rate_set_size=%d\nrate_set_size=%d\n", > - ap_info->ext_rate_set.size, ap_info->rate_set.size); > + DPRINTK(4, "bssid="); > + DPRINTK(4, "%02X:", ap->bssid[0]); No. You can't do this. Every DPRINTK() prints the function name and some other stuff so it would totally mess up the output. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] Fixes coding style
On Wed, Jan 04, 2017 at 07:10:39PM -0600, Scott Matheina wrote: > The patch series addresses some coding style issues contained within the file. > > Scott Matheina (2): > drivers/staging/rtl8188eu/core/rtw_ap.c un-necessary parenthesis > drivers/staging/rtl8188eu/core/rtw_ap.c Alignment should match open > parenthesis > > drivers/staging/rtl8188eu/core/rtw_ap.c | 144 > > 1 file changed, 71 insertions(+), 73 deletions(-) Your subject line here could use some work, it needs to say where you are doing the work. For example it could have said: [PATCH 0/2] staging: rtl8188eu: coding style fixes Or better yet, no 0/2 email at all, a two patch series doesn't need it. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] drivers/staging/rtl8188eu/core/rtw_ap.c un-necessary parenthesis
On Wed, Jan 04, 2017 at 07:10:40PM -0600, Scott Matheina wrote: > Fixed coding style issue, un-necessary parenthesis present > > Signed-off-by: Scott Matheina Again, problems with your subject, does it make sense? Look at what others do for this driver, it should look something like: [PATCH 1/2] staging: rwl8188eu: rtw_ap.c: remove unnecessary braces Please fix this up and resend. Same for patch 2/2. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH net-next] net: make ndo_get_stats64 a void function
The network device operation for reading statistics is only called in one place, and it ignores the return value. Having a structure return value is potentially confusing because some future driver could incorrectly assume that the return value was used. Fix all drivers with ndo_get_stats64 to have a void function. Signed-off-by: Stephen Hemminger --- drivers/net/bonding/bond_main.c | 10 -- drivers/net/dummy.c | 5 ++--- drivers/net/ethernet/alacritech/slicoss.c| 6 ++ drivers/net/ethernet/amazon/ena/ena_netdev.c | 10 -- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 6 ++ drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 4 +--- drivers/net/ethernet/atheros/alx/main.c | 6 ++ drivers/net/ethernet/broadcom/b44.c | 5 ++--- drivers/net/ethernet/broadcom/bnx2.c | 3 +-- drivers/net/ethernet/broadcom/bnxt/bnxt.c| 6 ++ drivers/net/ethernet/broadcom/tg3.c | 8 +++- drivers/net/ethernet/brocade/bna/bnad.c | 6 ++ drivers/net/ethernet/calxeda/xgmac.c | 5 ++--- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 5 ++--- drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 7 +++ drivers/net/ethernet/cisco/enic/enic_main.c | 8 +++- drivers/net/ethernet/ec_bhf.c| 4 +--- drivers/net/ethernet/emulex/benet/be_main.c | 5 ++--- drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 6 ++ drivers/net/ethernet/hisilicon/hns/hns_enet.c| 6 ++ drivers/net/ethernet/ibm/ehea/ehea_main.c| 5 ++--- drivers/net/ethernet/intel/e1000e/e1000.h| 4 ++-- drivers/net/ethernet/intel/e1000e/netdev.c | 5 ++--- drivers/net/ethernet/intel/fm10k/fm10k_netdev.c | 6 ++ drivers/net/ethernet/intel/i40e/i40e.h | 5 ++--- drivers/net/ethernet/intel/i40e/i40e_main.c | 18 ++ drivers/net/ethernet/intel/igb/igb_main.c| 10 -- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c| 7 --- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c| 6 ++ drivers/net/ethernet/marvell/mvneta.c| 4 +--- drivers/net/ethernet/marvell/mvpp2.c | 4 +--- drivers/net/ethernet/marvell/sky2.c | 6 ++ drivers/net/ethernet/mediatek/mtk_eth_soc.c | 6 ++ drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 4 +--- drivers/net/ethernet/mellanox/mlx5/core/en_main.c| 3 +-- drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 3 +-- drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 +--- drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 3 +-- drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 9 - drivers/net/ethernet/neterion/vxge/vxge-main.c | 4 +--- drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 6 ++ drivers/net/ethernet/nvidia/forcedeth.c | 4 +--- drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 10 -- drivers/net/ethernet/qlogic/qede/qede_main.c | 7 ++- drivers/net/ethernet/qualcomm/emac/emac.c| 6 ++ drivers/net/ethernet/realtek/8139too.c | 9 +++-- drivers/net/ethernet/realtek/r8169.c | 4 +--- drivers/net/ethernet/samsung/sxgbe/sxgbe_main.c | 8 ++-- drivers/net/ethernet/sfc/efx.c | 6 ++ drivers/net/ethernet/sfc/falcon/efx.c| 6 ++ drivers/net/ethernet/sun/niu.c | 6 ++ drivers/net/ethernet/synopsys/dwc_eth_qos.c | 4 +--- drivers/net/ethernet/tile/tilepro.c | 4 ++-- drivers/net/ethernet/via/via-rhine.c | 8 +++- drivers/net/fjes/fjes_main.c | 7 ++- drivers/net/hyperv/netvsc_drv.c | 6 ++ drivers/net/ifb.c| 6 ++ drivers/net/ipvlan/ipvlan_main.c | 5 ++--- drivers/net/loopback.c | 5 ++--- drivers/net/macsec.c | 6 ++ drivers/net/macvlan.c| 5 ++--- drivers/net/nlmon.c | 4 +--- drivers/net/ppp/ppp_generic.c| 4 +--- drivers/net/slip/slip.c | 3 +-- drivers/net/team/team.c | 3 +-- drivers/net/tun.c| 3 +-- drivers/net/veth.c | 6 ++ drivers/net/virtio_net.c | 6 ++ drivers/net/vmxnet3/vmxnet3_ethtool.c| 4 +--- drivers/net/vmxnet3/vmxnet3_int.h| 4 ++-- drivers/net/vrf.c
[PATCH] staging: greybus: remove timesync protocol support
From: Greg Kroah-Hartman
While the timesync protocol was a great idea, it never ended up getting
implemented by any known hardware devices. It's also a bit
"interesting" in how it ties into the platform controller.
So, just remove it for now. It's not needed, no one uses it, and it's a
stumbling block in getting the greybus core code merged out of the
staging tree. If anyone wants it in the future, reverting this patch is
a great place to start from.
Signed-off-by: Greg Kroah-Hartman
---
Sorry Bryan, I know it was a lot of work, and it's a great protocol and
implementation, but it never made it into a device :(
Note, there are some remants in the arche-platform driver, but that's
probably next on the chopping block, so I didn't unwind it from there as
it's a bit more complex, and it never gets built so no one will see
it...
drivers/staging/greybus/Makefile|4 +-
drivers/staging/greybus/arche_platform.h|2 -
drivers/staging/greybus/control.c | 50 -
drivers/staging/greybus/control.h |7 -
drivers/staging/greybus/core.c | 11 -
drivers/staging/greybus/es2.c | 132 ---
drivers/staging/greybus/greybus.h |1 -
drivers/staging/greybus/greybus_protocols.h | 47 -
drivers/staging/greybus/greybus_trace.h | 28 -
drivers/staging/greybus/hd.h|7 -
drivers/staging/greybus/interface.c | 56 +-
drivers/staging/greybus/interface.h |5 -
drivers/staging/greybus/svc.c | 87 --
drivers/staging/greybus/svc.h |7 -
drivers/staging/greybus/timesync.c | 1357 ---
drivers/staging/greybus/timesync.h | 45 -
drivers/staging/greybus/timesync_platform.c | 82 --
17 files changed, 3 insertions(+), 1925 deletions(-)
delete mode 100644 drivers/staging/greybus/timesync.c
delete mode 100644 drivers/staging/greybus/timesync.h
delete mode 100644 drivers/staging/greybus/timesync_platform.c
diff --git a/drivers/staging/greybus/Makefile b/drivers/staging/greybus/Makefile
index f337b7b70782..b26b9a35bdd5 100644
--- a/drivers/staging/greybus/Makefile
+++ b/drivers/staging/greybus/Makefile
@@ -10,9 +10,7 @@ greybus-y := core.o \
control.o \
svc.o \
svc_watchdog.o \
- operation.o \
- timesync.o \
- timesync_platform.o
+ operation.o
obj-$(CONFIG_GREYBUS) += greybus.o
diff --git a/drivers/staging/greybus/arche_platform.h
b/drivers/staging/greybus/arche_platform.h
index bd12345b82a2..c0591df9b9d6 100644
--- a/drivers/staging/greybus/arche_platform.h
+++ b/drivers/staging/greybus/arche_platform.h
@@ -10,8 +10,6 @@
#ifndef __ARCHE_PLATFORM_H
#define __ARCHE_PLATFORM_H
-#include "timesync.h"
-
enum arche_platform_state {
ARCHE_PLATFORM_STATE_OFF,
ARCHE_PLATFORM_STATE_ACTIVE,
diff --git a/drivers/staging/greybus/control.c
b/drivers/staging/greybus/control.c
index 4716190e740a..5b30be30a3a4 100644
--- a/drivers/staging/greybus/control.c
+++ b/drivers/staging/greybus/control.c
@@ -198,56 +198,6 @@ int gb_control_mode_switch_operation(struct gb_control
*control)
return ret;
}
-int gb_control_timesync_enable(struct gb_control *control, u8 count,
- u64 frame_time, u32 strobe_delay, u32 refclk)
-{
- struct gb_control_timesync_enable_request request;
-
- request.count = count;
- request.frame_time = cpu_to_le64(frame_time);
- request.strobe_delay = cpu_to_le32(strobe_delay);
- request.refclk = cpu_to_le32(refclk);
- return gb_operation_sync(control->connection,
-GB_CONTROL_TYPE_TIMESYNC_ENABLE, &request,
-sizeof(request), NULL, 0);
-}
-
-int gb_control_timesync_disable(struct gb_control *control)
-{
- return gb_operation_sync(control->connection,
-GB_CONTROL_TYPE_TIMESYNC_DISABLE, NULL, 0,
-NULL, 0);
-}
-
-int gb_control_timesync_get_last_event(struct gb_control *control,
- u64 *frame_time)
-{
- struct gb_control_timesync_get_last_event_response response;
- int ret;
-
- ret = gb_operation_sync(control->connection,
- GB_CONTROL_TYPE_TIMESYNC_GET_LAST_EVENT,
- NULL, 0, &response, sizeof(response));
- if (!ret)
- *frame_time = le64_to_cpu(response.frame_time);
- return ret;
-}
-
-int gb_control_timesync_authoritative(struct gb_control *control,
- u64 *frame_time)
-{
- struct gb_control_timesync_authoritative_request request;
- int i;
-
- for (i = 0; i < GB_TIMESYNC_MAX_STROBES; i++)
- request.frame_time[i] = cpu_to_le64(frame_time[i]);
-
-
Re: [PATCH v2 4/4] hv_util: improve time adjustment accuracy by disabling interrupts
On Thu, 05 Jan 2017 13:35:58 +0100 Vitaly Kuznetsov wrote: > I was thinking about it but to me what do_adjtimex() does looks too > low-level for drivers (e.g. calling write_seqcount_begin(), > __timekeeping_set_tai_offset(), tk_update_leap_state()). To me (again, I > probably know not that much about time keeping) it looks like we'll have > to have all this stuff around the __do_adjtimex() call here. > > Are there any particular concearns on calling do_adjtimex() directly? With out holding timekeeper_lock, I don't see how you can do the adjtime atomically. The userspace NTP doesn't worry about it, but in the kernel you can be more accurate. But to do that you would need to write a new function that is kernel specific. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next] net: make ndo_get_stats64 a void function
From: Stephen Hemminger Date: Thu, 5 Jan 2017 09:31:36 -0800 > The network device operation for reading statistics is only called > in one place, and it ignores the return value. Having a structure > return value is potentially confusing because some future driver could > incorrectly assume that the return value was used. > > Fix all drivers with ndo_get_stats64 to have a void function. > > Signed-off-by: Stephen Hemminger You missed at least one new warning, please do a fresh allmodconfig build and watch the logs. drivers/net/ethernet/broadcom/bnx2.c: In function ‘bnx2_get_stats64’: drivers/net/ethernet/broadcom/bnx2.c:6830:10: warning: ‘return’ with a value, in function returning void Thanks. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: remove timesync protocol support
On 05/01/17 17:39, Greg Kroah-Hartman wrote: > From: Greg Kroah-Hartman > > While the timesync protocol was a great idea, it never ended up getting > implemented by any known hardware devices. It's also a bit > "interesting" in how it ties into the platform controller. > > So, just remove it for now. It's not needed, no one uses it, and it's a > stumbling block in getting the greybus core code merged out of the > staging tree. If anyone wants it in the future, reverting this patch is > a great place to start from. > > Signed-off-by: Greg Kroah-Hartman > --- > > Sorry Bryan, I know it was a lot of work, and it's a great protocol and > implementation, but it never made it into a device :( Kill it. One less turd to polish. Acked-by: Bryan O'Donoghue ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: remove timesync protocol support
On 01/05/2017 12:25 PM, Bryan O'Donoghue wrote: > On 05/01/17 17:39, Greg Kroah-Hartman wrote: >> From: Greg Kroah-Hartman >> >> While the timesync protocol was a great idea, it never ended up getting >> implemented by any known hardware devices. It's also a bit >> "interesting" in how it ties into the platform controller. >> >> So, just remove it for now. It's not needed, no one uses it, and it's a >> stumbling block in getting the greybus core code merged out of the >> staging tree. If anyone wants it in the future, reverting this patch is >> a great place to start from. >> >> Signed-off-by: Greg Kroah-Hartman >> --- >> >> Sorry Bryan, I know it was a lot of work, and it's a great protocol and >> implementation, but it never made it into a device :( > > Kill it. > > One less turd to polish. I think the core algorithm has some value that we might use at some future date. But I concur, at this point it interferes with things getting reorganized cleanly. -Alex > > Acked-by: Bryan O'Donoghue > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: remove timesync protocol support
On 01/05/2017 11:39 AM, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman
>
> While the timesync protocol was a great idea, it never ended up getting
> implemented by any known hardware devices. It's also a bit
> "interesting" in how it ties into the platform controller.
>
> So, just remove it for now. It's not needed, no one uses it, and it's a
> stumbling block in getting the greybus core code merged out of the
> staging tree. If anyone wants it in the future, reverting this patch is
> a great place to start from.
>
> Signed-off-by: Greg Kroah-Hartman
This consists entirely of deletions. I haven't applied the
patch to test it, so I trust it compiles as it should. And if
that is true, I'm sure it causes no harm, since as you said,
nobody uses the code right now.
Reviewed-by: Alex Elder
> ---
>
> Sorry Bryan, I know it was a lot of work, and it's a great protocol and
> implementation, but it never made it into a device :(
>
> Note, there are some remants in the arche-platform driver, but that's
> probably next on the chopping block, so I didn't unwind it from there as
> it's a bit more complex, and it never gets built so no one will see
> it...
>
> drivers/staging/greybus/Makefile|4 +-
> drivers/staging/greybus/arche_platform.h|2 -
> drivers/staging/greybus/control.c | 50 -
> drivers/staging/greybus/control.h |7 -
> drivers/staging/greybus/core.c | 11 -
> drivers/staging/greybus/es2.c | 132 ---
> drivers/staging/greybus/greybus.h |1 -
> drivers/staging/greybus/greybus_protocols.h | 47 -
> drivers/staging/greybus/greybus_trace.h | 28 -
> drivers/staging/greybus/hd.h|7 -
> drivers/staging/greybus/interface.c | 56 +-
> drivers/staging/greybus/interface.h |5 -
> drivers/staging/greybus/svc.c | 87 --
> drivers/staging/greybus/svc.h |7 -
> drivers/staging/greybus/timesync.c | 1357
> ---
> drivers/staging/greybus/timesync.h | 45 -
> drivers/staging/greybus/timesync_platform.c | 82 --
> 17 files changed, 3 insertions(+), 1925 deletions(-)
> delete mode 100644 drivers/staging/greybus/timesync.c
> delete mode 100644 drivers/staging/greybus/timesync.h
> delete mode 100644 drivers/staging/greybus/timesync_platform.c
>
> diff --git a/drivers/staging/greybus/Makefile
> b/drivers/staging/greybus/Makefile
> index f337b7b70782..b26b9a35bdd5 100644
> --- a/drivers/staging/greybus/Makefile
> +++ b/drivers/staging/greybus/Makefile
> @@ -10,9 +10,7 @@ greybus-y :=core.o \
> control.o \
> svc.o \
> svc_watchdog.o \
> - operation.o \
> - timesync.o \
> - timesync_platform.o
> + operation.o
>
> obj-$(CONFIG_GREYBUS)+= greybus.o
>
> diff --git a/drivers/staging/greybus/arche_platform.h
> b/drivers/staging/greybus/arche_platform.h
> index bd12345b82a2..c0591df9b9d6 100644
> --- a/drivers/staging/greybus/arche_platform.h
> +++ b/drivers/staging/greybus/arche_platform.h
> @@ -10,8 +10,6 @@
> #ifndef __ARCHE_PLATFORM_H
> #define __ARCHE_PLATFORM_H
>
> -#include "timesync.h"
> -
> enum arche_platform_state {
> ARCHE_PLATFORM_STATE_OFF,
> ARCHE_PLATFORM_STATE_ACTIVE,
> diff --git a/drivers/staging/greybus/control.c
> b/drivers/staging/greybus/control.c
> index 4716190e740a..5b30be30a3a4 100644
> --- a/drivers/staging/greybus/control.c
> +++ b/drivers/staging/greybus/control.c
> @@ -198,56 +198,6 @@ int gb_control_mode_switch_operation(struct gb_control
> *control)
> return ret;
> }
>
> -int gb_control_timesync_enable(struct gb_control *control, u8 count,
> -u64 frame_time, u32 strobe_delay, u32 refclk)
> -{
> - struct gb_control_timesync_enable_request request;
> -
> - request.count = count;
> - request.frame_time = cpu_to_le64(frame_time);
> - request.strobe_delay = cpu_to_le32(strobe_delay);
> - request.refclk = cpu_to_le32(refclk);
> - return gb_operation_sync(control->connection,
> - GB_CONTROL_TYPE_TIMESYNC_ENABLE, &request,
> - sizeof(request), NULL, 0);
> -}
> -
> -int gb_control_timesync_disable(struct gb_control *control)
> -{
> - return gb_operation_sync(control->connection,
> - GB_CONTROL_TYPE_TIMESYNC_DISABLE, NULL, 0,
> - NULL, 0);
> -}
> -
> -int gb_control_timesync_get_last_event(struct gb_control *control,
> -u64 *frame_time)
> -{
> - struct gb_control_timesync_get_last_event_response response;
> - int ret;
> -
> - ret = gb_operation_sync(control->connection,
> - GB_CONTROL_TYPE_TIMESYNC_GET_LAST_EVENT,
> -
Re: [PATCH v2 04/19] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
Hi Vladimir,
On 01/04/2017 04:25 AM, Vladimir Zapolskiy wrote:
Hi Steve,
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
Both hang off the same i2c2 bus, so they require different (and non-
default) i2c slave addresses.
The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi. It is set to transmit over MIPI virtual channel 1.
Note there is a pin conflict with GPIO6. This pin functions as a power
input pin to the OV5642, but ENET uses it as the h/w workaround for
erratum ERR006687, to wake-up the ARM cores on normal RX and TX packet
done events (see 6261c4c8). So workaround 6261c4c8 is reverted here to
support the OV5642, and the "fsl,err006687-workaround-present" boolean
also must be removed. The result is that the CPUidle driver will no longer
allow entering the deep idle states on the sabrelite.
For me it sounds like a candidate of its own separate change.
Yes, I split out the two partial reverts into a separate commit
("ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687
workaround").
+
+ mipi_camera: ov5640@40 {
Please reorder device nodes by address value,
done.
also according to ePAPR
node names should be generic, labels can be specific:
ov5640: camera@40 {
...
};
ov5642: camera@42 {
...
};
fixed.
+ pinctrl_ipu1_csi0: ipu1grp-csi0 {
Please rename node name to ipu1csi0grp.
done.
+
+pinctrl_ov5640: ov5640grp {
+fsl,pins = <
+ MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x000b0
+ MX6QDL_PAD_NANDF_WP_B__GPIO6_IO09 0x0b0b0
+>;
+};
+
Indentation issues above, please use tabs instead of spaces.
fixed.
Also please add new pin control groups preserving the alphanimerical order.
done.
Steve
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: gdm724x: cleanup long lines to conform to kernel coding style
Refactor code to remove multi-line derefs and code duplication
Signed-off-by: Emil Gedda
---
Yet again, sorry for the spam, still new to sending in patches and
everything related, but I'm more than happy being able to contribute.
Tried contacting the mentioned people in the relevant TODO, but after a
couple of weeks I still haven't received a response, thus sending this
to you directly. Error messages still need to be changed to use
netdev_err, but that's for another patch.
drivers/staging/gdm724x/gdm_lte.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/gdm724x/gdm_lte.c
b/drivers/staging/gdm724x/gdm_lte.c
index e72dfa9..a182757 100644
--- a/drivers/staging/gdm724x/gdm_lte.c
+++ b/drivers/staging/gdm724x/gdm_lte.c
@@ -688,6 +688,7 @@ static void gdm_lte_multi_sdu_pkt(struct phy_dev *phy_dev,
char *buf, int len)
struct net_device *dev;
struct multi_sdu *multi_sdu = (struct multi_sdu *)buf;
struct sdu *sdu = NULL;
+ struct gdm_endian *endian = phy_dev->get_endian(phy_dev->priv_dev);
u8 *data = (u8 *)multi_sdu->data;
u16 i = 0;
u16 num_packet;
@@ -696,20 +697,15 @@ static void gdm_lte_multi_sdu_pkt(struct phy_dev
*phy_dev, char *buf, int len)
u32 nic_type;
u8 index;
- hci_len = gdm_dev16_to_cpu(phy_dev->get_endian(phy_dev->priv_dev),
- multi_sdu->len);
- num_packet = gdm_dev16_to_cpu(phy_dev->get_endian(phy_dev->priv_dev),
- multi_sdu->num_packet);
+ hci_len = gdm_dev16_to_cpu(endian, multi_sdu->len);
+ num_packet = gdm_dev16_to_cpu(endian, multi_sdu->num_packet);
for (i = 0; i < num_packet; i++) {
sdu = (struct sdu *)data;
- cmd_evt = gdm_dev16_to_cpu(phy_dev->
- get_endian(phy_dev->priv_dev), sdu->cmd_evt);
- hci_len = gdm_dev16_to_cpu(phy_dev->
- get_endian(phy_dev->priv_dev), sdu->len);
- nic_type = gdm_dev32_to_cpu(phy_dev->
- get_endian(phy_dev->priv_dev), sdu->nic_type);
+ cmd_evt = gdm_dev16_to_cpu(endian, sdu->cmd_evt);
+ hci_len = gdm_dev16_to_cpu(endian, sdu->len);
+ nic_type = gdm_dev32_to_cpu(endian, sdu->nic_type);
if (cmd_evt != LTE_RX_SDU) {
pr_err("rx sdu wrong hci %04x\n", cmd_evt);
@@ -761,6 +757,7 @@ static int gdm_lte_receive_pkt(struct phy_dev *phy_dev,
char *buf, int len)
{
struct hci_packet *hci = (struct hci_packet *)buf;
struct hci_pdn_table_ind *pdn_table = (struct hci_pdn_table_ind *)buf;
+ struct gdm_endian *endian = phy_dev->get_endian(phy_dev->priv_dev);
struct sdu *sdu;
struct net_device *dev;
int ret = 0;
@@ -771,8 +768,7 @@ static int gdm_lte_receive_pkt(struct phy_dev *phy_dev,
char *buf, int len)
if (!len)
return ret;
- cmd_evt = gdm_dev16_to_cpu(phy_dev->get_endian(phy_dev->priv_dev),
- hci->cmd_evt);
+ cmd_evt = gdm_dev16_to_cpu(endian, hci->cmd_evt);
dev = phy_dev->dev[0];
if (!dev)
@@ -781,8 +777,7 @@ static int gdm_lte_receive_pkt(struct phy_dev *phy_dev,
char *buf, int len)
switch (cmd_evt) {
case LTE_RX_SDU:
sdu = (struct sdu *)hci->data;
- nic_type = gdm_dev32_to_cpu(phy_dev->
- get_endian(phy_dev->priv_dev), sdu->nic_type);
+ nic_type = gdm_dev32_to_cpu(endian, sdu->nic_type);
index = find_dev_index(nic_type);
dev = phy_dev->dev[index];
gdm_lte_netif_rx(dev, hci->data, len, nic_type);
@@ -797,9 +792,7 @@ static int gdm_lte_receive_pkt(struct phy_dev *phy_dev,
char *buf, int len)
break;
case LTE_PDN_TABLE_IND:
pdn_table = (struct hci_pdn_table_ind *)buf;
- nic_type = gdm_dev32_to_cpu(phy_dev->
- get_endian(phy_dev->priv_dev),
- pdn_table->nic_type);
+ nic_type = gdm_dev32_to_cpu(endian, pdn_table->nic_type);
index = find_dev_index(nic_type);
dev = phy_dev->dev[index];
gdm_lte_pdn_table(dev, buf, len);
--
2.10.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 00/14] staging: comedi: daqboard2000: some clean-up
On Wednesday, January 04, 2017 3:56 AM, Ian Abbott wrote: > I've had these clean-up patches for the daqboard2000 driver sitting > around for a few months, with a view to adding support for more boards > in the same series, and adding support for extra subdevice types. I > never got around to doing that, but I did manage to add support for a > couple of extra DAC channels on one of the two currently supported card > types. I'm still not positive that this driver works correctly. The adc/dac initialization code appears to be incomplete and the ai (*insn_read) is pretty odd. But, thanks for cleaning this one up! Reviewed-by: H Hartley Sweeten ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging
On Tue, Jan 03, 2017 at 10:19:29PM +0100, Arnd Bergmann wrote: > On Tuesday, January 3, 2017 4:24:36 PM CET Greg Kroah-Hartman wrote: > > On Wed, Mar 02, 2016 at 08:06:46PM +0100, Arnd Bergmann wrote: > > > The icn, act2000 and pcbit drivers are all for very old hardware, > > > and it is highly unlikely that anyone is actually still using them > > > on modern kernels, if at all. > > > > > > All three drivers apparently are for hardware that predates PCI > > > being the common connector, as they are ISA-only and active > > > PCI ISDN cards were widely available in the 1990s. > > > > > > Looking through the git logs, it I cannot find any indication of a > > > patch to any of these drivers that has been tested on real hardware, > > > only cleanups or global API changes. > > > > > > Signed-off-by: Arnd Bergmann > > > Acked-by: Karsten Keil > > > > This patch got added in the 4.6 kernel release. As I am now taking > > patches for 4.11-rc1, I figure it is time to just delete the > > drivers/staging/i4l/ directory now, given that no one has really done > > anything with it. If people show up that wish to maintain it, I'll be > > glad to revert it, or if someone really screams in the next week. > > Otherwise it's time to just move on > > Sounds good to me. Ok, now deleted! thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
On 01/04/2017 04:33 AM, Vladimir Zapolskiy wrote:
+
+ camera: ov5642@3c {
ov5642: camera@3c
done.
+ pwdn-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; /* SD1_DAT0 */
+ reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; /* SD1_DAT1 */
Comments about SD1_* pad names are redundant.
sure, removed.
+ status = "disabled";
Why is it disabled here?
It's explained in the header. I don't yet have the OV5642 module for
the sabresd for testing, so it is disabled for now.
+
+ mipi_camera: ov5640@3c {
ov5640: camera@3c
done.
+ pwdn-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; /* SD1_DAT2 */
+ reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; /* SD1_CLK */
Comments about SD1_* pad names are redundant.
removed.
+
+ pinctrl_ipu1_csi0: ipu1grp-csi0 {
Please rename the node name to ipu1csi0grp.
Please add new pin control groups preserving the alphanimerical order.
done and done.
Steve
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 09/19] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
On 01/04/2017 04:41 AM, Vladimir Zapolskiy wrote:
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
+
+ camera: adv7180@21 {
adv7180: camera@21
done.
+ pinctrl_ipu1_csi0: ipu1grp-csi0 {
Please rename node name to ipu1csi0grp.
done.
Steve
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCHv2 1/2] staging:rwl8188eu:rtw_ap.c remove unnecessary braces
Removed unnecessary braces
Signed-off-by: Scott Matheina
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 106
1 file changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 553e8d5..396b948 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -26,7 +26,7 @@
void init_mlme_ap_info(struct adapter *padapter)
{
- struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
+ struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct sta_priv *pstapriv = &padapter->stapriv;
struct wlan_acl_pool *pacl_list = &pstapriv->acl_list;
@@ -43,7 +43,7 @@ void free_mlme_ap_info(struct adapter *padapter)
{
struct sta_info *psta = NULL;
struct sta_priv *pstapriv = &padapter->stapriv;
- struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
+ struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
@@ -59,17 +59,17 @@ void free_mlme_ap_info(struct adapter *padapter)
/* free bc/mc sta_info */
psta = rtw_get_bcmc_stainfo(padapter);
- spin_lock_bh(&(pstapriv->sta_hash_lock));
+ spin_lock_bh(&pstapriv->sta_hash_lock);
rtw_free_stainfo(padapter, psta);
- spin_unlock_bh(&(pstapriv->sta_hash_lock));
+ spin_unlock_bh(&pstapriv->sta_hash_lock);
}
static void update_BCNTIM(struct adapter *padapter)
{
struct sta_priv *pstapriv = &padapter->stapriv;
- struct mlme_ext_priv *pmlmeext = &(padapter->mlmeextpriv);
- struct mlme_ext_info *pmlmeinfo = &(pmlmeext->mlmext_info);
- struct wlan_bssid_ex *pnetwork_mlmeext = &(pmlmeinfo->network);
+ struct mlme_ext_priv *pmlmeext = &padapter->mlmeextpriv;
+ struct mlme_ext_info *pmlmeinfo = &pmlmeext->mlmext_info;
+ struct wlan_bssid_ex *pnetwork_mlmeext = &pmlmeinfo->network;
unsigned char *pie = pnetwork_mlmeext->IEs;
u8 *p, *dst_ie, *premainder_ie = NULL;
u8 *pbackup_remainder_ie = NULL;
@@ -310,9 +310,9 @@ voidexpire_timeout_chk(struct adapter *padapter)
spin_unlock_bh(&pstapriv->auth_list_lock);
- spin_lock_bh(&(pstapriv->sta_hash_lock));
+ spin_lock_bh(&pstapriv->sta_hash_lock);
rtw_free_stainfo(padapter, psta);
- spin_unlock_bh(&(pstapriv->sta_hash_lock));
+ spin_unlock_bh(&pstapriv->sta_hash_lock);
spin_lock_bh(&pstapriv->auth_list_lock);
}
@@ -456,7 +456,7 @@ void add_RATid(struct adapter *padapter, struct sta_info
*psta, u8 rssi_level)
unsigned char limit;
unsigned int tx_ra_bitmap = 0;
struct ht_priv *psta_ht = NULL;
- struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
+ struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct wlan_bssid_ex *pcur_network = (struct wlan_bssid_ex
*)&pmlmepriv->cur_network.network;
if (psta)
@@ -548,7 +548,7 @@ static void update_bmc_sta(struct adapter *padapter)
unsigned char network_type, raid;
int i, supportRateNum = 0;
unsigned int tx_ra_bitmap = 0;
- struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
+ struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct wlan_bssid_ex *pcur_network = (struct wlan_bssid_ex
*)&pmlmepriv->cur_network.network;
struct sta_info *psta = rtw_get_bcmc_stainfo(padapter);
@@ -630,9 +630,9 @@ static void update_bmc_sta(struct adapter *padapter)
void update_sta_info_apmode(struct adapter *padapter, struct sta_info *psta)
{
- struct mlme_priv *pmlmepriv = &(padapter->mlmepriv);
+ struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
struct security_priv *psecuritypriv = &padapter->securitypriv;
- struct mlme_ext_priv*pmlmeext = &(padapter->mlmeextpriv);
+ struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
struct ht_priv *phtpriv_ap = &pmlmepriv->htpriv;
struct ht_priv *phtpriv_sta = &psta->htpriv;
@@ -700,7 +700,7 @@ static void update_hw_ht_param(struct adapter *padapter)
unsigned char max_AMPDU_len;
unsigned char min_MPDU_spacing;
struct mlme_ext_priv*pmlmeext = &padapter->mlmeextpriv;
- struct mlme_ext_info*pmlmeinfo = &(pmlmeext->mlmext_info);
+ struct mlme_ext_info*pmlmeinfo = &pmlmeext->mlmext_info;
DBG_88E("%s\n", __func__);
@@ -733,12 +733,12 @@ static void start_bss_network(struct adapter *padapter,
u8 *pbuf)
u32 acparm;
int ie_len;
struct registry_priv *pregpriv = &padapter->registrypriv;
- struct mlme_priv *p
[PATCHv2 2/2] staging:rtl8188eu:core Fixes Alignment should match opening brace
Fixed style issue: Alignment should match open brace
Signed-off-by: Scott Matheina
---
drivers/staging/rtl8188eu/core/rtw_ap.c | 38 -
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/rtl8188eu/core/rtw_ap.c
b/drivers/staging/rtl8188eu/core/rtw_ap.c
index 396b948..1c8fa3a 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ap.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ap.c
@@ -94,10 +94,9 @@ static void update_BCNTIM(struct adapter *padapter)
offset += pnetwork_mlmeext->Ssid.SsidLength + 2;
/* get supported rates len */
- p = rtw_get_ie(pie + _BEACON_IE_OFFSET_,
- _SUPPORTEDRATES_IE_, &tmp_len,
- (pnetwork_mlmeext->IELength -
- _BEACON_IE_OFFSET_));
+ p = rtw_get_ie(pie + _BEACON_IE_OFFSET_, _SUPPORTEDRATES_IE_,
+ &tmp_len, (pnetwork_mlmeext->IELength -
+ _BEACON_IE_OFFSET_));
if (p)
offset += tmp_len+2;
@@ -116,13 +115,12 @@ static void update_BCNTIM(struct adapter *padapter)
if (remainder_ielen > 0) {
pbackup_remainder_ie = rtw_malloc(remainder_ielen);
if (pbackup_remainder_ie && premainder_ie)
- memcpy(pbackup_remainder_ie,
- premainder_ie, remainder_ielen);
+ memcpy(pbackup_remainder_ie, premainder_ie,
+ remainder_ielen);
}
*dst_ie++ = _TIM_IE_;
- if ((pstapriv->tim_bitmap&0xff00) &&
- (pstapriv->tim_bitmap&0x00fc))
+ if ((pstapriv->tim_bitmap&0xff00) && (pstapriv->tim_bitmap&0x00fc))
tim_ielen = 5;
else
tim_ielen = 4;
@@ -157,7 +155,7 @@ static void update_BCNTIM(struct adapter *padapter)
}
void rtw_add_bcn_ie(struct adapter *padapter, struct wlan_bssid_ex *pnetwork,
- u8 index, u8 *data, u8 len)
+ u8 index, u8 *data, u8 len)
{
struct ndis_802_11_var_ie *pIE;
u8 bmatch = false;
@@ -201,8 +199,8 @@ void rtw_add_bcn_ie(struct adapter *padapter, struct
wlan_bssid_ex *pnetwork,
if (remainder_ielen > 0) {
pbackup_remainder_ie = rtw_malloc(remainder_ielen);
if (pbackup_remainder_ie && premainder_ie)
- memcpy(pbackup_remainder_ie,
- premainder_ie, remainder_ielen);
+ memcpy(pbackup_remainder_ie, premainder_ie,
+ remainder_ielen);
}
*dst_ie++ = index;
@@ -223,7 +221,7 @@ void rtw_add_bcn_ie(struct adapter *padapter, struct
wlan_bssid_ex *pnetwork,
}
void rtw_remove_bcn_ie(struct adapter *padapter, struct wlan_bssid_ex
*pnetwork,
- u8 index)
+ u8 index)
{
u8 *p, *dst_ie = NULL, *premainder_ie = NULL;
u8 *pbackup_remainder_ie = NULL;
@@ -247,8 +245,8 @@ void rtw_remove_bcn_ie(struct adapter *padapter, struct
wlan_bssid_ex *pnetwork,
if (remainder_ielen > 0) {
pbackup_remainder_ie = rtw_malloc(remainder_ielen);
if (pbackup_remainder_ie && premainder_ie)
- memcpy(pbackup_remainder_ie,
- premainder_ie, remainder_ielen);
+ memcpy(pbackup_remainder_ie, premainder_ie,
+ remainder_ielen);
}
/* copy remainder IE */
@@ -361,8 +359,8 @@ voidexpire_timeout_chk(struct adapter *padapter)
* for this station
*/
pstapriv->tim_bitmap |= BIT(psta->aid);
- update_beacon(padapter, _TIM_IE_,
- NULL, false);
+ update_beacon(padapter, _TIM_IE_, NULL,
+ false);
if (!pmlmeext->active_keep_alive_check)
continue;
@@ -1573,8 +1571,8 @@ void bss_cap_update_on_sta_join(struct adapter *padapter,
struct sta_info *psta)
pmlmepriv->num_sta_ht_no_gf++;
}
DBG_88E("%s STA %pM - no greenfield, num of non-gf
stations %d\n",
- __func__, (psta->hwaddr),
- pmlmepriv->num_sta_ht_no_gf);
+ __func__, (psta->hwaddr),
+ pmlmepriv->num_sta_ht_no_gf);
}
if ((ht_capab & IEEE80211_HT_CAP_SUP_WIDTH) == 0) {
[PATCH] Staging: greybus: style fix, permissions as octal
Changed permissions to be in octal style.
Found by checkpatch.
Signed-off-by: Derek Robson
---
drivers/staging/greybus/camera.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c
index 0ee291ca2c72..a64517eabff4 100644
--- a/drivers/staging/greybus/camera.c
+++ b/drivers/staging/greybus/camera.c
@@ -1067,22 +1067,22 @@ struct gb_camera_debugfs_entry {
static const struct gb_camera_debugfs_entry gb_camera_debugfs_entries[] = {
{
.name = "capabilities",
- .mask = S_IFREG | S_IRUGO,
+ .mask = S_IFREG | 0444,
.buffer = GB_CAMERA_DEBUGFS_BUFFER_CAPABILITIES,
.execute = gb_camera_debugfs_capabilities,
}, {
.name = "configure_streams",
- .mask = S_IFREG | S_IRUGO | S_IWUGO,
+ .mask = S_IFREG | 0666,
.buffer = GB_CAMERA_DEBUGFS_BUFFER_STREAMS,
.execute = gb_camera_debugfs_configure_streams,
}, {
.name = "capture",
- .mask = S_IFREG | S_IRUGO | S_IWUGO,
+ .mask = S_IFREG | 0666,
.buffer = GB_CAMERA_DEBUGFS_BUFFER_CAPTURE,
.execute = gb_camera_debugfs_capture,
}, {
.name = "flush",
- .mask = S_IFREG | S_IRUGO | S_IWUGO,
+ .mask = S_IFREG | 0666,
.buffer = GB_CAMERA_DEBUGFS_BUFFER_FLUSH,
.execute = gb_camera_debugfs_flush,
},
@@ -1097,7 +1097,7 @@ static ssize_t gb_camera_debugfs_read(struct file *file,
char __user *buf,
ssize_t ret;
/* For read-only entries the operation is triggered by a read. */
- if (!(op->mask & S_IWUGO)) {
+ if (!(op->mask & 0222)) {
ret = op->execute(gcam, NULL, 0);
if (ret < 0)
return ret;
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 10/19] media: Add i.MX media core driver
On 01/04/2017 05:33 AM, Vladimir Zapolskiy wrote:
Hi Steve,
On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
Add the core media driver for i.MX SOC.
Signed-off-by: Steve Longerbeam
---
Documentation/devicetree/bindings/media/imx.txt | 205 +
v2 was sent before getting Rob's review comments, but still they
should be addressed in v3.
yes, those changes will be part of v3 as well.
Also I would suggest to separate device tree binding documentation
change and place it as the first patch in the series, this should
make the following DTS changes valid.
done.
Documentation/media/v4l-drivers/imx.rst | 430 ++
drivers/staging/media/Kconfig | 2 +
drivers/staging/media/Makefile| 1 +
drivers/staging/media/imx/Kconfig | 8 +
drivers/staging/media/imx/Makefile| 6 +
drivers/staging/media/imx/TODO| 18 +
drivers/staging/media/imx/imx-media-common.c | 985 ++
drivers/staging/media/imx/imx-media-dev.c | 479 +++
drivers/staging/media/imx/imx-media-fim.c | 509 +++
drivers/staging/media/imx/imx-media-internal-sd.c | 457 ++
drivers/staging/media/imx/imx-media-of.c | 291 +++
drivers/staging/media/imx/imx-media-of.h | 25 +
drivers/staging/media/imx/imx-media.h | 299 +++
include/media/imx.h | 15 +
include/uapi/Kbuild | 1 +
include/uapi/linux/v4l2-controls.h| 4 +
include/uapi/media/Kbuild | 2 +
include/uapi/media/imx.h | 30 +
Probably Greg should ack the UAPI changes, you may consider
to split them into a separate patch.
I split out the one-line addition to include/uapi/Kbuild with an empty
include/uapi/media/Kbuild into a new patch "UAPI: Add media UAPI Kbuild
file".
Also added a patch "media: Add userspace header file for i.MX".
+
+struct imx_media_subdev *
+imx_media_find_subdev_by_sd(struct imx_media_dev *imxmd,
+ struct v4l2_subdev *sd)
+{
+ struct imx_media_subdev *imxsd;
+ int i, ret = -ENODEV;
+
+ for (i = 0; i < imxmd->num_subdevs; i++) {
+ imxsd = &imxmd->subdev[i];
+ if (sd == imxsd->sd) {
This can be simplifed:
...
if (sd == imxsd->sd)
return imxsd;
}
return ERR_PTR(-ENODEV);
yep, done.
+struct imx_media_subdev *
+imx_media_find_subdev_by_id(struct imx_media_dev *imxmd, u32 grp_id)
+{
+ struct imx_media_subdev *imxsd;
+ int i, ret = -ENODEV;
+
+ for (i = 0; i < imxmd->num_subdevs; i++) {
+ imxsd = &imxmd->subdev[i];
+ if (imxsd->sd && imxsd->sd->grp_id == grp_id) {
+ ret = 0;
+ break;
This can be simplifed:
...
if (imxsd->sd && imxsd->sd->grp_id == grp_i)
return imxsd;
}
return ERR_PTR(-ENODEV);
done.
diff --git a/drivers/staging/media/imx/imx-media-dev.c
b/drivers/staging/media/imx/imx-media-dev.c
new file mode 100644
index 000..8d22730
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-dev.c
@@ -0,0 +1,479 @@
+/*
+ * V4L2 Media Controller Driver for Freescale i.MX5/6 SOC
+ *
+ * Copyright (c) 2016 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
Please sort out the list of headers alphabetically.
done.
+#include
+#include
+#include "imx-media.h"
+#include "imx-media-of.h"
+
+#define DEVICE_NAME "imx-media"
I suppose you don't need this macro.
sure why not, removed.
[snip]
+ */
+static int imx_media_create_links(struct imx_media_dev *imxmd)
+{
+ struct imx_media_subdev *local_sd;
+ struct imx_media_subdev *remote_sd;
+ struct v4l2_subdev *source, *sink;
+ struct imx_media_link *link;
+ struct imx_media_pad *pad;
+ u16 source_pad, sink_pad;
+ int num_pads, i, j, k;
+ int ret = 0;
+
+ for (i = 0; i < imxmd->num_subdevs; i++) {
+ local_sd = &imxmd->subdev[i];
+ num_pads = local_sd->num_sink_pads + local_sd->num_src_pads;
+
+ for (j = 0; j < num_pads; j++) {
+ pad = &local_sd->pad[j];
+
+ for (k = 0; k < pad->num_links; k++) {
+ link = &pad->link[k];
+
Indentation depth is quite terrific.
yes, it needs to iterate by subdev, pads in the subdev, then links
in the pad. But I moved the code under the inne
[PATCH v2 02/2] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
'commit 2584cf83578c ("arch, drivers: don't
include directly, use instead")'
Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
ioremap_cache, tree-wide.
Signed-off-by: Arvind Yadav
---
drivers/staging/i4l/act2000/act2000.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/i4l/act2000/act2000.h
b/drivers/staging/i4l/act2000/act2000.h
index 321d437..e372ff5 100644
--- a/drivers/staging/i4l/act2000/act2000.h
+++ b/drivers/staging/i4l/act2000/act2000.h
@@ -70,7 +70,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [v1] i4l: act2000: act2000:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
Thanks for your suggestion :). I have done the changes as per your concern . Please review it. Thanks :) -Arvind On Thursday 05 January 2017 05:35 PM, Greg KH wrote: On Thu, Jan 05, 2017 at 05:25:05PM +0530, Arvind Yadav wrote: Please find my comment below. Where? What happened to your email quoting? Thanks -Arvind On Thursday 05 January 2017 05:16 PM, Greg KH wrote: On Thu, Jan 05, 2017 at 04:09:24PM +0530, Arvind Yadav wrote: Make uniform definition of ioremap, ioremap_wc, ioremap_wt and ioremap_cache, tree-wide. That doesn't make much sense, and doesn't match the subject: or the patch itself. -- Please refer the commit which is already in main-lined. commit 2584cf83578c26db144730ef498f4070f82ee3ea Ah, here it is, please quote stuff correctly. If you are referring to something else, great, then say so in the commit itself. Every commit should be self-explanatory, how am I supposed to know this. And this text still doesn't make sense to me, please fix. And what is with the "[v1]"? ---V1 is stands for patch set version 1 Please read Documentation/SubmittingPatches for how to properly label patches, don't make new things up, we have too many different developers (i.e. 4000+) for everyone to do their own unique thing. :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
'commit 2584cf83578c ("arch, drivers: don't
include directly, use instead")'
Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
ioremap_cache, tree-wide.
Signed-off-by: Arvind Yadav
---
drivers/staging/rtl8192u/r8192U.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192u/r8192U.h
b/drivers/staging/rtl8192u/r8192U.h
index 0b7b04e..c078659 100644
--- a/drivers/staging/rtl8192u/r8192U.h
+++ b/drivers/staging/rtl8192u/r8192U.h
@@ -34,7 +34,7 @@
#include
#include
#include
-#include
+#include
#include "ieee80211/ieee80211.h"
#define RTL8192U
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 01/2] rtl8192u: r8192U:- Do not use 'asm/io.h' directly, use 'linux/io.h'.
On Fri, Jan 06, 2017 at 11:46:11AM +0530, Arvind Yadav wrote:
> 'commit 2584cf83578c ("arch, drivers: don't
> include directly, use instead")'
> Make uniform definition of ioremap, ioremap_wc, ioremap_wt and
> ioremap_cache, tree-wide.
I still don't understand what this means at all, do you?
What does the "Make uniform..." sentance mean in relation to this simple
patch that just changes the include file used?
confused,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: greybus: style fix, permissions as octal
On Fri, Jan 06, 2017 at 02:20:23PM +1300, Derek Robson wrote:
> Changed permissions to be in octal style.
> Found by checkpatch.
>
> Signed-off-by: Derek Robson
> ---
> drivers/staging/greybus/camera.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/greybus/camera.c
> b/drivers/staging/greybus/camera.c
> index 0ee291ca2c72..a64517eabff4 100644
> --- a/drivers/staging/greybus/camera.c
> +++ b/drivers/staging/greybus/camera.c
> @@ -1067,22 +1067,22 @@ struct gb_camera_debugfs_entry {
> static const struct gb_camera_debugfs_entry gb_camera_debugfs_entries[] = {
> {
> .name = "capabilities",
> - .mask = S_IFREG | S_IRUGO,
> + .mask = S_IFREG | 0444,
So close, yet not correct :(
Please fix all of the permissions, not just one of them, unless you are
wanting to get two patches in instead of one here?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] MAINTAINERS: add greybus subsystem mailing list
From: Greg Kroah-Hartman The Greybus driver subsystem has a mailing list, so list it in the MAINTAINERS file so that people know to send patches there as well. Signed-off-by: Greg Kroah-Hartman diff --git a/MAINTAINERS b/MAINTAINERS index cfff2c9e3d94..f6cb07684cea 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5504,6 +5504,7 @@ M:Alex Elder M: Greg Kroah-Hartman S: Maintained F: drivers/staging/greybus/ +L: greybus-...@lists.linaro.org GREYBUS AUDIO PROTOCOLS DRIVERS M: Vaibhav Agarwal ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] Staging: greybus: style fix, permissions as octal
Changed permissions to be in octal style.
Found by checkpatch.
Signed-off-by: Derek Robson
---
This version of patch also make the file type part of the mask with the
permissions, as per recommendation from Greg K-H
drivers/staging/greybus/camera.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/greybus/camera.c b/drivers/staging/greybus/camera.c
index 0ee291ca2c72..73ddb612953b 100644
--- a/drivers/staging/greybus/camera.c
+++ b/drivers/staging/greybus/camera.c
@@ -1067,22 +1067,22 @@ struct gb_camera_debugfs_entry {
static const struct gb_camera_debugfs_entry gb_camera_debugfs_entries[] = {
{
.name = "capabilities",
- .mask = S_IFREG | S_IRUGO,
+ .mask = 0100444,
.buffer = GB_CAMERA_DEBUGFS_BUFFER_CAPABILITIES,
.execute = gb_camera_debugfs_capabilities,
}, {
.name = "configure_streams",
- .mask = S_IFREG | S_IRUGO | S_IWUGO,
+ .mask = 0100666,
.buffer = GB_CAMERA_DEBUGFS_BUFFER_STREAMS,
.execute = gb_camera_debugfs_configure_streams,
}, {
.name = "capture",
- .mask = S_IFREG | S_IRUGO | S_IWUGO,
+ .mask = 0100666,
.buffer = GB_CAMERA_DEBUGFS_BUFFER_CAPTURE,
.execute = gb_camera_debugfs_capture,
}, {
.name = "flush",
- .mask = S_IFREG | S_IRUGO | S_IWUGO,
+ .mask = 0100666,
.buffer = GB_CAMERA_DEBUGFS_BUFFER_FLUSH,
.execute = gb_camera_debugfs_flush,
},
@@ -1097,7 +1097,7 @@ static ssize_t gb_camera_debugfs_read(struct file *file,
char __user *buf,
ssize_t ret;
/* For read-only entries the operation is triggered by a read. */
- if (!(op->mask & S_IWUGO)) {
+ if (!(op->mask & 0222)) {
ret = op->execute(gcam, NULL, 0);
if (ret < 0)
return ret;
--
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
