Re: [PATCH v2 3/3] staging: wilc1000: refactor p2p action frames handling API's
Hi Greg, On 12/02/20 12:48 am, Greg KH wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > On Tue, Feb 11, 2020 at 09:57:10AM +, ajay.kat...@microchip.com wrote: >> From: Ajay Singh >> >> Refactor handling of P2P specific action frames. Make use of 'struct' to >> handle the P2P frames instead of manipulating using 'buf' pointer. >> >> Signed-off-by: Ajay Singh >> --- >> v2: corrected 'while' condition by adding 'struct' size as suggested by Dan. > > This patch doesn't apply to my tree :( > Ok. Please ignore this patch. I will rebase and send this patch again. Regards, Ajay ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wilc1000: refactor p2p action frames handling API's
From: Ajay Singh
Refactor handling of P2P specific action frames. Make use of 'struct' to
handle the P2P frames instead of manipulating using 'buf' pointer.
Signed-off-by: Ajay Singh
---
[resending this patch as it failed to apply earlier]
drivers/staging/wilc1000/cfg80211.c | 300
1 file changed, 128 insertions(+), 172 deletions(-)
diff --git a/drivers/staging/wilc1000/cfg80211.c
b/drivers/staging/wilc1000/cfg80211.c
index 7afbc475b3ea..d9c7bed2e6fb 100644
--- a/drivers/staging/wilc1000/cfg80211.c
+++ b/drivers/staging/wilc1000/cfg80211.c
@@ -6,29 +6,17 @@
#include "cfg80211.h"
-#define FRAME_TYPE_ID 0
-#define ACTION_CAT_ID 24
-#define ACTION_SUBTYPE_ID 25
-#define P2P_PUB_ACTION_SUBTYPE 30
-
-#define ACTION_FRAME 0xd0
-#define GO_INTENT_ATTR_ID 0x04
-#define CHANLIST_ATTR_ID 0x0b
-#define OPERCHAN_ATTR_ID 0x11
-#define PUB_ACTION_ATTR_ID 0x04
-#define P2PELEM_ATTR_ID0xdd
-
#define GO_NEG_REQ 0x00
#define GO_NEG_RSP 0x01
#define GO_NEG_CONF0x02
#define P2P_INV_REQ0x03
#define P2P_INV_RSP0x04
-#define PUBLIC_ACT_VENDORSPEC 0x09
-#define GAS_INITIAL_REQ0x0a
-#define GAS_INITIAL_RSP0x0b
#define WILC_INVALID_CHANNEL 0
+/* Operation at 2.4 GHz with channels 1-13 */
+#define WILC_WLAN_OPERATING_CLASS_2_4GHZ 0x51
+
static const struct ieee80211_txrx_stypes
wilc_wfi_cfg80211_mgmt_types[NUM_NL80211_IFTYPES] = {
[NL80211_IFTYPE_STATION] = {
@@ -67,7 +55,50 @@ struct wilc_p2p_mgmt_data {
u8 *buff;
};
-static const u8 p2p_oui[] = {0x50, 0x6f, 0x9A, 0x09};
+struct wilc_p2p_pub_act_frame {
+ u8 category;
+ u8 action;
+ u8 oui[3];
+ u8 oui_type;
+ u8 oui_subtype;
+ u8 dialog_token;
+ u8 elem[0];
+} __packed;
+
+struct wilc_vendor_specific_ie {
+ u8 tag_number;
+ u8 tag_len;
+ u8 oui[3];
+ u8 oui_type;
+ u8 attr[0];
+} __packed;
+
+struct wilc_attr_entry {
+ u8 attr_type;
+ __le16 attr_len;
+ u8 val[0];
+} __packed;
+
+struct wilc_attr_oper_ch {
+ u8 attr_type;
+ __le16 attr_len;
+ u8 country_code[IEEE80211_COUNTRY_STRING_LEN];
+ u8 op_class;
+ u8 op_channel;
+} __packed;
+
+struct wilc_attr_ch_list {
+ u8 attr_type;
+ __le16 attr_len;
+ u8 country_code[IEEE80211_COUNTRY_STRING_LEN];
+ u8 elem[0];
+} __packed;
+
+struct wilc_ch_list_elem {
+ u8 op_class;
+ u8 no_of_channels;
+ u8 ch_list[0];
+} __packed;
static void cfg_scan_result(enum scan_event scan_event,
struct wilc_rcvd_net_info *info, void *user_void)
@@ -896,87 +927,51 @@ static int flush_pmksa(struct wiphy *wiphy, struct
net_device *netdev)
return 0;
}
-static inline void wilc_wfi_cfg_parse_ch_attr(u8 *buf, u8 ch_list_attr_idx,
- u8 op_ch_attr_idx, u8 sta_ch)
+static inline void wilc_wfi_cfg_parse_ch_attr(u8 *buf, u32 len, u8 sta_ch)
{
- int i = 0;
- int j = 0;
-
- if (ch_list_attr_idx) {
- u8 limit = ch_list_attr_idx + 3 + buf[ch_list_attr_idx + 1];
+ struct wilc_attr_entry *e;
+ struct wilc_attr_ch_list *ch_list;
+ struct wilc_attr_oper_ch *op_ch;
+ u32 index = 0;
+ u8 ch_list_idx = 0;
+ u8 op_ch_idx = 0;
- for (i = ch_list_attr_idx + 3; i < limit; i++) {
- if (buf[i] == 0x51) {
- for (j = i + 2; j < ((i + 2) + buf[i + 1]); j++)
- buf[j] = sta_ch;
- break;
- }
- }
- }
+ if (sta_ch == WILC_INVALID_CHANNEL)
+ return;
- if (op_ch_attr_idx) {
- buf[op_ch_attr_idx + 6] = 0x51;
- buf[op_ch_attr_idx + 7] = sta_ch;
+ while (index + sizeof(*e) <= len) {
+ e = (struct wilc_attr_entry *)&buf[index];
+ if (e->attr_type == IEEE80211_P2P_ATTR_CHANNEL_LIST)
+ ch_list_idx = index;
+ else if (e->attr_type == IEEE80211_P2P_ATTR_OPER_CHANNEL)
+ op_ch_idx = index;
+ if (ch_list_idx && op_ch_idx)
+ break;
+ index += le16_to_cpu(e->attr_len) + sizeof(*e);
}
-}
-static void wilc_wfi_cfg_parse_rx_action(u8 *buf, u32 len, u8 sta_ch)
-{
- u32 index = 0;
- u8 op_channel_attr_index = 0;
- u8 channel_list_attr_index = 0;
-
- while (index < len) {
- if (buf[index] == CHANLIST_ATTR_ID)
- channel_list_attr_index = index;
-
Did You get My Message This Time?
This is the second time i am sending you this mail.I, Friedrich Mayrhofer Donate $ 1,000,000.00 to You, Email Me personally for more details .Regards. Friedrich Mayrhofer ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging:gasket:gasket_core.c:unified quoted string split across lines in one line
When the driver tries to map a region, but the region has certain
permissions, or when it attempts to open gasket with tgid, or when it
realeases device node; the logs are displayed in one line only while the
code has the strings split in two lines which makes it difficult for
developers to search for code based on the log messages. So, this patch
fixes three warnings of 'quoted string split across lines' in
gasket_core.c by merging the strings in one line.
Signed-off-by: Kaaira Gupta
---
drivers/staging/gasket/gasket_core.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
b/drivers/staging/gasket/gasket_core.c
index cd8be80d2076..411aaf248b37 100644
--- a/drivers/staging/gasket/gasket_core.c
+++ b/drivers/staging/gasket/gasket_core.c
@@ -692,8 +692,7 @@ static bool gasket_mmap_has_permissions(struct gasket_dev
*gasket_dev,
(vma->vm_flags & (VM_WRITE | VM_READ | VM_EXEC));
if (requested_permissions & ~(bar_permissions)) {
dev_dbg(gasket_dev->dev,
- "Attempting to map a region with requested permissions "
- "0x%x, but region has permissions 0x%x.\n",
+ "Attempting to map a region with requested permissions
0x%x, but region has permissions 0x%x.\n",
requested_permissions, bar_permissions);
return false;
}
@@ -1180,8 +1179,7 @@ static int gasket_open(struct inode *inode, struct file
*filp)
inode->i_size = 0;
dev_dbg(gasket_dev->dev,
- "Attempting to open with tgid %u (%s) (f_mode: 0%03o, "
- "fmode_write: %d is_root: %u)\n",
+ "Attempting to open with tgid %u (%s) (f_mode: 0%03o,
fmode_write: %d is_root: %u)\n",
current->tgid, task_name, filp->f_mode,
(filp->f_mode & FMODE_WRITE), is_root);
@@ -1258,8 +1256,7 @@ static int gasket_release(struct inode *inode, struct
file *file)
mutex_lock(&gasket_dev->mutex);
dev_dbg(gasket_dev->dev,
- "Releasing device node. Call origin: tgid %u (%s) "
- "(f_mode: 0%03o, fmode_write: %d, is_root: %u)\n",
+ "Releasing device node. Call origin: tgid %u (%s) (f_mode:
0%03o, fmode_write: %d, is_root: %u)\n",
current->tgid, task_name, file->f_mode,
(file->f_mode & FMODE_WRITE), is_root);
dev_dbg(gasket_dev->dev, "Current open count (owning tgid %u): %d\n",
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging:gasket:gasket_core.c:unified quoted string split across lines in one line
On Tue, Feb 11, 2020 at 09:45:03PM +0100, Julia Lawall wrote:
> On Wed, 12 Feb 2020, Kaaira Gupta wrote:
>
> > Whenever it tries to map a region, but the region has permissions, or it
> > attempts to open gasket with tgid, or it releases device node the messages
> > are displayed in one line only, respectively.
> > And it becomes confusing for the developer to search for the code based on
> > these lines' output since they are written in separate lines in the code.
> > So, this patch fixes this 'WARNING: quoted string split across lines'
> > in three lines in the file gasket_core.c.
>
> Congratulations on making the first submission of this round :)
Thanks!
>
> However, some changes are needed. The subject line needs better tags at
> the beginning to highlight what part of the kernel is affected. Use git
> log --oneline on this file to see what others have done. And follow the
> style used, in terms of whitespace. Also, try to avoid the word Fix in
> the subject line, which is not very descriptive. The word WARNING: is
> probably also not necessary.
>
> Afterwards, the log message should also respect the 80 character limit.
> Ideally even fewer characters, because it will come out indented in the
> resulting path.
>
> Finally, the log message should describe what it does using the
> imperative, and again should avoid the word "fix".
>
> julia
When the driver tries to map a region, but the region has certain
permissions, or when it attempts to open gasket with tgid, or when it
realeases device node; the logs are displayed in one line only while the
code has the strings split in two lines which makes it difficult for
developers to search for code based on the log messages. So, this patch
fixes three warnings of 'quoted string split across lines' in
gasket_core.c by merging the strings in one line.
Also, I wasn't sure if I were to send a separate batch or reply with a
v2 for this one. If former was the case than please let me know.
Thanks for your time!
>
> >
> > Signed-off-by: Kaaira Gupta
> > ---
> > drivers/staging/gasket/gasket_core.c | 9 +++--
> > 1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/staging/gasket/gasket_core.c
> > b/drivers/staging/gasket/gasket_core.c
> > index cd8be80d2076..411aaf248b37 100644
> > --- a/drivers/staging/gasket/gasket_core.c
> > +++ b/drivers/staging/gasket/gasket_core.c
> > @@ -692,8 +692,7 @@ static bool gasket_mmap_has_permissions(struct
> > gasket_dev *gasket_dev,
> > (vma->vm_flags & (VM_WRITE | VM_READ | VM_EXEC));
> > if (requested_permissions & ~(bar_permissions)) {
> > dev_dbg(gasket_dev->dev,
> > - "Attempting to map a region with requested permissions "
> > - "0x%x, but region has permissions 0x%x.\n",
> > + "Attempting to map a region with requested permissions
> > 0x%x, but region has permissions 0x%x.\n",
> > requested_permissions, bar_permissions);
> > return false;
> > }
> > @@ -1180,8 +1179,7 @@ static int gasket_open(struct inode *inode, struct
> > file *filp)
> > inode->i_size = 0;
> >
> > dev_dbg(gasket_dev->dev,
> > - "Attempting to open with tgid %u (%s) (f_mode: 0%03o, "
> > - "fmode_write: %d is_root: %u)\n",
> > + "Attempting to open with tgid %u (%s) (f_mode: 0%03o,
> > fmode_write: %d is_root: %u)\n",
> > current->tgid, task_name, filp->f_mode,
> > (filp->f_mode & FMODE_WRITE), is_root);
> >
> > @@ -1258,8 +1256,7 @@ static int gasket_release(struct inode *inode, struct
> > file *file)
> > mutex_lock(&gasket_dev->mutex);
> >
> > dev_dbg(gasket_dev->dev,
> > - "Releasing device node. Call origin: tgid %u (%s) "
> > - "(f_mode: 0%03o, fmode_write: %d, is_root: %u)\n",
> > + "Releasing device node. Call origin: tgid %u (%s) (f_mode:
> > 0%03o, fmode_write: %d, is_root: %u)\n",
> > current->tgid, task_name, file->f_mode,
> > (file->f_mode & FMODE_WRITE), is_root);
> > dev_dbg(gasket_dev->dev, "Current open count (owning tgid %u): %d\n",
> > --
> > 2.17.1
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/outreachy-kernel/20200211200456.GA10351%40kaaira-HP-Pavilion-Notebook.
> >
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging:gasket:gasket_core.c:unified quoted string split across lines in one line
On Wed, Feb 12, 2020 at 05:20:35PM +0530, Kaaira Gupta wrote: > When the driver tries to map a region, but the region has certain > permissions, or when it attempts to open gasket with tgid, or when it > realeases device node; We don't care about any of this information... > the logs are displayed in one line only while the > code has the strings split in two lines which makes it difficult for > developers to search for code based on the log messages. So, this patch > fixes three warnings of 'quoted string split across lines' in > gasket_core.c by merging the strings in one line. > > Also, I wasn't sure if I were to send a separate batch or reply with a > v2 for this one. If former was the case than please let me know. > Thanks for your time! I would say: "Kernel style says not to split string literals across mutliple lines because it makes it difficult to grep the source for the printk. I have changed the code accordingly. It will not affect runtime." That's not imperative and some subsystems are more strict about "you're not allowed to use the words 'I', 'we' or 'this patch'" in a commit description. But in staging we are pragmatists. So long as it's clear why you're writing the patch that's the main thing. The other problem with this code is that some of these messages are over 80 characters long themselves which is very long for one line. It doesn't matter if you send the v2 as a reply or not. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging:gasket:gasket_core.c:unified quoted string split across lines in one line
On Wed, Feb 12, 2020 at 05:44:24PM +0300, Dan Carpenter wrote: > On Wed, Feb 12, 2020 at 05:20:35PM +0530, Kaaira Gupta wrote: > > When the driver tries to map a region, but the region has certain > > permissions, or when it attempts to open gasket with tgid, or when it > > realeases device node; > > We don't care about any of this information... > > > the logs are displayed in one line only while the > > code has the strings split in two lines which makes it difficult for > > developers to search for code based on the log messages. So, this patch > > fixes three warnings of 'quoted string split across lines' in > > gasket_core.c by merging the strings in one line. Another perfectly adequate commit message would be: Fix three checkpatch.pl warnings of 'quoted string split across lines' in gasket_core.c by merging the strings in one line. Which is imperative. :) Hooray! regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: gasket: unify multi-line string
Fix three checkpatch.pl warnings of 'quoted string split across lines'
in gasket_core.c by merging the strings in one line.
Though some strings
are over 80 characters long, fixing this warning is necessary to ease
grep-ing the source for printk.
Signed-off-by: Kaaira Gupta
---
drivers/staging/gasket/gasket_core.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/gasket/gasket_core.c
b/drivers/staging/gasket/gasket_core.c
index cd8be80d2076..411aaf248b37 100644
--- a/drivers/staging/gasket/gasket_core.c
+++ b/drivers/staging/gasket/gasket_core.c
@@ -692,8 +692,7 @@ static bool gasket_mmap_has_permissions(struct gasket_dev
*gasket_dev,
(vma->vm_flags & (VM_WRITE | VM_READ | VM_EXEC));
if (requested_permissions & ~(bar_permissions)) {
dev_dbg(gasket_dev->dev,
- "Attempting to map a region with requested permissions "
- "0x%x, but region has permissions 0x%x.\n",
+ "Attempting to map a region with requested permissions
0x%x, but region has permissions 0x%x.\n",
requested_permissions, bar_permissions);
return false;
}
@@ -1180,8 +1179,7 @@ static int gasket_open(struct inode *inode, struct file
*filp)
inode->i_size = 0;
dev_dbg(gasket_dev->dev,
- "Attempting to open with tgid %u (%s) (f_mode: 0%03o, "
- "fmode_write: %d is_root: %u)\n",
+ "Attempting to open with tgid %u (%s) (f_mode: 0%03o,
fmode_write: %d is_root: %u)\n",
current->tgid, task_name, filp->f_mode,
(filp->f_mode & FMODE_WRITE), is_root);
@@ -1258,8 +1256,7 @@ static int gasket_release(struct inode *inode, struct
file *file)
mutex_lock(&gasket_dev->mutex);
dev_dbg(gasket_dev->dev,
- "Releasing device node. Call origin: tgid %u (%s) "
- "(f_mode: 0%03o, fmode_write: %d, is_root: %u)\n",
+ "Releasing device node. Call origin: tgid %u (%s) (f_mode:
0%03o, fmode_write: %d, is_root: %u)\n",
current->tgid, task_name, file->f_mode,
(file->f_mode & FMODE_WRITE), is_root);
dev_dbg(gasket_dev->dev, "Current open count (owning tgid %u): %d\n",
--
2.17.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/5] staging: vc04_services: use kref + RCU to reference count services
Currently reference counts are implemented by locking service_spinlock
and then incrementing the service's ->ref_count field, calling
kfree() when the last reference has been dropped. But at the same
time, there's code in multiple places that dereferences pointers
to services without having a reference, so there could be a race there.
It should be possible to avoid taking any lock in unlock_service()
or service_release() because we are setting a single array element
to NULL, and on service creation, a mutex is locked before looking
for a NULL spot to put the new service in.
Using a struct kref and RCU-delaying the freeing of services fixes
this race condition while still making it possible to skip
grabbing a reference in many places. Also it avoids the need to
acquire a single spinlock when e.g. taking a reference on
state->services[i] when somebody else is in the middle of taking
a reference on state->services[j].
Signed-off-by: Marcelo Diop-Gonzalez
---
.../interface/vchiq_arm/vchiq_arm.c | 25 +-
.../interface/vchiq_arm/vchiq_core.c | 222 +-
.../interface/vchiq_arm/vchiq_core.h | 12 +-
3 files changed, 140 insertions(+), 119 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
index c456ced431af..3ed0e4ea7f5c 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "vchiq_core.h"
@@ -2096,10 +2097,12 @@ int vchiq_dump_platform_instances(void *dump_context)
/* There is no list of instances, so instead scan all services,
marking those that have been dumped. */
+ rcu_read_lock();
for (i = 0; i < state->unused_service; i++) {
- struct vchiq_service *service = state->services[i];
+ struct vchiq_service *service;
struct vchiq_instance *instance;
+ service = rcu_dereference(state->services[i]);
if (!service || service->base.callback != service_callback)
continue;
@@ -2107,18 +2110,26 @@ int vchiq_dump_platform_instances(void *dump_context)
if (instance)
instance->mark = 0;
}
+ rcu_read_unlock();
for (i = 0; i < state->unused_service; i++) {
- struct vchiq_service *service = state->services[i];
+ struct vchiq_service *service;
struct vchiq_instance *instance;
int err;
- if (!service || service->base.callback != service_callback)
+ rcu_read_lock();
+ service = rcu_dereference(state->services[i]);
+ if (!service || service->base.callback != service_callback) {
+ rcu_read_unlock();
continue;
+ }
instance = service->instance;
- if (!instance || instance->mark)
+ if (!instance || instance->mark) {
+ rcu_read_unlock();
continue;
+ }
+ rcu_read_unlock();
len = snprintf(buf, sizeof(buf),
"Instance %pK: pid %d,%s completions %d/%d",
@@ -2128,7 +2139,6 @@ int vchiq_dump_platform_instances(void *dump_context)
instance->completion_insert -
instance->completion_remove,
MAX_COMPLETIONS);
-
err = vchiq_dump(dump_context, buf, len + 1);
if (err)
return err;
@@ -2585,8 +2595,10 @@ vchiq_dump_service_use_state(struct vchiq_state *state)
if (active_services > MAX_SERVICES)
only_nonzero = 1;
+ rcu_read_lock();
for (i = 0; i < active_services; i++) {
- struct vchiq_service *service_ptr = state->services[i];
+ struct vchiq_service *service_ptr =
+ rcu_dereference(state->services[i]);
if (!service_ptr)
continue;
@@ -2604,6 +2616,7 @@ vchiq_dump_service_use_state(struct vchiq_state *state)
if (found >= MAX_SERVICES)
break;
}
+ rcu_read_unlock();
read_unlock_bh(&arm_state->susp_res_lock);
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
index b2d9013b7f79..65270a5b29db 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
@@ -1,6 +1,9 @@
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
/* Copyright (c) 2010-2012 Broadcom. All rights reserved. */
+
Re: [PATCH 2/5] staging: vc04_services: remove unneeded parentheses
On Wed, Feb 12, 2020 at 01:51:15PM -0500, Marcelo Diop-Gonzalez wrote:
> On Wed, Feb 12, 2020 at 1:43 PM Marcelo Diop-Gonzalez
> wrote:
> >
> > there are extra parentheses around many conditional statements
> > that make things a little harder to read
> >
> > Signed-off-by: Marcelo Diop-Gonzalez
> > ---
> > .../interface/vchiq_arm/vchiq_core.c | 36 +--
> > 1 file changed, 18 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> > b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> > index 4f8b59deaec9..72bfa0f73958 100644
> > --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> > @@ -138,8 +138,8 @@ find_service_by_handle(unsigned int handle)
> >
> > spin_lock(&service_spinlock);
> > service = handle_to_service(handle);
> > - if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE) &&
> > - (service->handle == handle)) {
> > + if (service && service->srvstate != VCHIQ_SRVSTATE_FREE &&
> > + service->handle == handle) {
> > WARN_ON(service->ref_count == 0);
> > service->ref_count++;
> > } else
> > @@ -161,7 +161,7 @@ find_service_by_port(struct vchiq_state *state, int
> > localport)
> > if ((unsigned int)localport <= VCHIQ_PORT_MAX) {
> > spin_lock(&service_spinlock);
> > service = state->services[localport];
> > - if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE)) {
> > + if (service && service->srvstate != VCHIQ_SRVSTATE_FREE) {
> > WARN_ON(service->ref_count == 0);
> > service->ref_count++;
> > } else
> > @@ -184,9 +184,9 @@ find_service_for_instance(struct vchiq_instance
> > *instance,
> >
> > spin_lock(&service_spinlock);
> > service = handle_to_service(handle);
> > - if (service && (service->srvstate != VCHIQ_SRVSTATE_FREE) &&
> > - (service->handle == handle) &&
> > - (service->instance == instance)) {
> > + if (service && service->srvstate != VCHIQ_SRVSTATE_FREE &&
> > + service->handle == handle &&
> > + service->instance == instance) {
> > WARN_ON(service->ref_count == 0);
> > service->ref_count++;
> > } else
> > @@ -209,10 +209,10 @@ find_closed_service_for_instance(struct
> > vchiq_instance *instance,
> > spin_lock(&service_spinlock);
> > service = handle_to_service(handle);
> > if (service &&
> > - ((service->srvstate == VCHIQ_SRVSTATE_FREE) ||
> > -(service->srvstate == VCHIQ_SRVSTATE_CLOSED)) &&
> > - (service->handle == handle) &&
> > - (service->instance == instance)) {
> > + (service->srvstate == VCHIQ_SRVSTATE_FREE ||
> > +service->srvstate == VCHIQ_SRVSTATE_CLOSED) &&
> > + service->handle == handle &&
> > + service->instance == instance) {
> > WARN_ON(service->ref_count == 0);
> > service->ref_count++;
> > } else
> > @@ -237,8 +237,8 @@ next_service_by_instance(struct vchiq_state *state,
> > struct vchiq_instance *insta
> > while (idx < state->unused_service) {
> > struct vchiq_service *srv = state->services[idx++];
> >
> > - if (srv && (srv->srvstate != VCHIQ_SRVSTATE_FREE) &&
> > - (srv->instance == instance)) {
> > + if (srv && srv->srvstate != VCHIQ_SRVSTATE_FREE &&
> > + srv->instance == instance) {
> > service = srv;
> > WARN_ON(service->ref_count == 0);
> > service->ref_count++;
> > @@ -464,10 +464,10 @@ get_listening_service(struct vchiq_state *state, int
> > fourcc)
> > struct vchiq_service *service = state->services[i];
> >
> > if (service &&
> > - (service->public_fourcc == fourcc) &&
> > - ((service->srvstate == VCHIQ_SRVSTATE_LISTENING) ||
> > - ((service->srvstate == VCHIQ_SRVSTATE_OPEN) &&
> > - (service->remoteport == VCHIQ_PORT_FREE {
> > + service->public_fourcc == fourcc &&
> > + (service->srvstate == VCHIQ_SRVSTATE_LISTENING ||
> > +(service->srvstate == VCHIQ_SRVSTATE_OPEN &&
> > + service->remoteport == VCHIQ_PORT_FREE))) {
> > lock_service(service);
> > return service;
> > }
> > @@ -485,8 +485,8 @@ get_connected_service(struct vchiq_state *state,
> > unsigned int port)
> > for (i = 0; i < state->unused_service; i++) {
> >
Re: [PATCH 4/5] staging: vc04_services: use kref + RCU to reference count services
On Wed, Feb 12, 2020 at 01:43:32PM -0500, Marcelo Diop-Gonzalez wrote:
> Currently reference counts are implemented by locking service_spinlock
> and then incrementing the service's ->ref_count field, calling
> kfree() when the last reference has been dropped. But at the same
> time, there's code in multiple places that dereferences pointers
> to services without having a reference, so there could be a race there.
>
> It should be possible to avoid taking any lock in unlock_service()
> or service_release() because we are setting a single array element
> to NULL, and on service creation, a mutex is locked before looking
> for a NULL spot to put the new service in.
>
> Using a struct kref and RCU-delaying the freeing of services fixes
> this race condition while still making it possible to skip
> grabbing a reference in many places. Also it avoids the need to
> acquire a single spinlock when e.g. taking a reference on
> state->services[i] when somebody else is in the middle of taking
> a reference on state->services[j].
>
> Signed-off-by: Marcelo Diop-Gonzalez
> ---
> .../interface/vchiq_arm/vchiq_arm.c | 25 +-
> .../interface/vchiq_arm/vchiq_core.c | 222 +-
> .../interface/vchiq_arm/vchiq_core.h | 12 +-
> 3 files changed, 140 insertions(+), 119 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> index c456ced431af..3ed0e4ea7f5c 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "vchiq_core.h"
> @@ -2096,10 +2097,12 @@ int vchiq_dump_platform_instances(void *dump_context)
> /* There is no list of instances, so instead scan all services,
> marking those that have been dumped. */
>
> + rcu_read_lock();
> for (i = 0; i < state->unused_service; i++) {
> - struct vchiq_service *service = state->services[i];
> + struct vchiq_service *service;
> struct vchiq_instance *instance;
>
> + service = rcu_dereference(state->services[i]);
> if (!service || service->base.callback != service_callback)
> continue;
>
> @@ -2107,18 +2110,26 @@ int vchiq_dump_platform_instances(void *dump_context)
> if (instance)
> instance->mark = 0;
> }
> + rcu_read_unlock();
>
> for (i = 0; i < state->unused_service; i++) {
> - struct vchiq_service *service = state->services[i];
> + struct vchiq_service *service;
> struct vchiq_instance *instance;
> int err;
>
> - if (!service || service->base.callback != service_callback)
> + rcu_read_lock();
> + service = rcu_dereference(state->services[i]);
> + if (!service || service->base.callback != service_callback) {
> + rcu_read_unlock();
> continue;
> + }
>
> instance = service->instance;
> - if (!instance || instance->mark)
> + if (!instance || instance->mark) {
> + rcu_read_unlock();
> continue;
> + }
> + rcu_read_unlock();
>
> len = snprintf(buf, sizeof(buf),
> "Instance %pK: pid %d,%s completions %d/%d",
> @@ -2128,7 +2139,6 @@ int vchiq_dump_platform_instances(void *dump_context)
> instance->completion_insert -
> instance->completion_remove,
> MAX_COMPLETIONS);
> -
> err = vchiq_dump(dump_context, buf, len + 1);
> if (err)
> return err;
> @@ -2585,8 +2595,10 @@ vchiq_dump_service_use_state(struct vchiq_state *state)
> if (active_services > MAX_SERVICES)
> only_nonzero = 1;
>
> + rcu_read_lock();
> for (i = 0; i < active_services; i++) {
> - struct vchiq_service *service_ptr = state->services[i];
> + struct vchiq_service *service_ptr =
> + rcu_dereference(state->services[i]);
>
> if (!service_ptr)
> continue;
> @@ -2604,6 +2616,7 @@ vchiq_dump_service_use_state(struct vchiq_state *state)
> if (found >= MAX_SERVICES)
> break;
> }
> + rcu_read_unlock();
>
> read_unlock_bh(&arm_state->susp_res_lock);
>
> diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> index b2d9013b7f79..65270a5b29db 100644
> --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c
> +++ b/driver
Re: [PATCH] staging: wilc1000: refactor p2p action frames handling API's
On Wed, Feb 12, 2020 at 10:14:15AM +, ajay.kat...@microchip.com wrote: > From: Ajay Singh > > Refactor handling of P2P specific action frames. Make use of 'struct' to > handle the P2P frames instead of manipulating using 'buf' pointer. > > Signed-off-by: Ajay Singh > --- > [resending this patch as it failed to apply earlier] I had to export this and apply it by hand as the base64 stuff here really confused git :( odd... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/6] Re-instate octeon staging drivers
On Wed, Feb 05, 2020 at 01:11:10PM +1300, Chris Packham wrote: > This series re-instates the octeon drivers that were recently removed and > addresses the build issues that lead to that decision. > > I've approached Cavium/Marvell about taking a more active interest in getting > the code out of staging and into their proper location. No reply on that > (yet). Good luck with talking to the companies, hopefully that will work. Anyway, I've applied this series, thanks for this, let's see what breaks now :) greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-linus] BUILD SUCCESS 9a4556bd8f23209c29f152e6a930b6a893b0fc81
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-linus branch HEAD: 9a4556bd8f23209c29f152e6a930b6a893b0fc81 staging: rtl8723bs: Remove unneeded goto statements elapsed time: 2810m configs tested: 299 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm allmodconfig arm allnoconfig arm allyesconfig arm at91_dt_defconfig arm efm32_defconfig arm exynos_defconfig armmulti_v5_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm64 defconfig sparcallyesconfig nds32 allnoconfig riscv rv32_defconfig s390defconfig sh rsk7269_defconfig shtitan_defconfig riscv defconfig nds32 defconfig shallnoconfig xtensa common_defconfig openrisc simple_smp_defconfig powerpc defconfig alpha defconfig microblazenommu_defconfig parisc defconfig um defconfig openriscor1ksim_defconfig sparc64 allyesconfig i386 allnoconfig ia64defconfig powerpc allnoconfig microblaze mmu_defconfig riscvnommu_virt_defconfig h8300 h8s-sim_defconfig ia64 allnoconfig m68k sun3_defconfig ia64 allyesconfig sparc64 allmodconfig i386 alldefconfig m68k allmodconfig powerpc ppc64_defconfig cskydefconfig sh allmodconfig s390 allyesconfig sparc64 defconfig mips allnoconfig nios2 10m50_defconfig i386 allyesconfig i386defconfig ia64 alldefconfig ia64 allmodconfig c6x allyesconfig c6xevmc6678_defconfig nios2 3c120_defconfig xtensa iss_defconfig h8300 edosk2674_defconfig h8300h8300h-sim_defconfig m68k m5475evb_defconfig m68k multi_defconfig arc allyesconfig arc defconfig powerpc rhel-kconfig mips 32r2_defconfig mips 64r6el_defconfig mips allmodconfig mips allyesconfig mips fuloong2e_defconfig mips malta_kvm_defconfig pariscallnoconfig parisc allyesconfig parisc b180_defconfig pariscc3000_defconfig x86_64 randconfig-a001-20200213 x86_64 randconfig-a002-20200213 x86_64 randconfig-a003-20200213 i386 randconfig-a001-20200213 i386 randconfig-a002-20200213 i386 randconfig-a003-20200213 x86_64 randconfig-a001-20200211 x86_64 randconfig-a002-20200211 x86_64 randconfig-a003-20200211 i386 randconfig-a001-20200211 i386 randconfig-a002-20200211 i386 randconfig-a003-20200211 x86_64 randconfig-a001-20200212 x86_64 randconfig-a002-20200212 x86_64 randconfig-a003-20200212 i386 randconfig-a001-20200212 i386 randconfig-a002-20200212 i386 randconfig-a003-20200212 alpharandconfig-a001-20200211 m68k randconfig-a001-20200211 mips randconfig-a001-20200211 nds32randconfig-a001-20200211 parisc randconfig-a001-20200211 riscvrandconfig-a001-20200211 alpharandconfig
[driver-core:driver-core-linus] BUILD SUCCESS ae91c92565494a37c30ce9a691c87890f800d826
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-linus branch HEAD: ae91c92565494a37c30ce9a691c87890f800d826 debugfs: remove return value of debugfs_create_regset32() elapsed time: 2885m configs tested: 292 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm allmodconfig arm allnoconfig arm allyesconfig arm at91_dt_defconfig arm efm32_defconfig arm exynos_defconfig armmulti_v5_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm64 defconfig sparcallyesconfig nds32 allnoconfig riscv rv32_defconfig mips allmodconfig cskydefconfig mips fuloong2e_defconfig sh rsk7269_defconfig i386defconfig shallnoconfig shtitan_defconfig riscv defconfig s390defconfig nds32 defconfig xtensa common_defconfig powerpc allnoconfig openrisc simple_smp_defconfig microblazenommu_defconfig parisc defconfig um defconfig openriscor1ksim_defconfig sparc64 allyesconfig microblaze mmu_defconfig alpha defconfig ia64defconfig sparc64 allmodconfig m68k allmodconfig sparc64 allnoconfig m68k sun3_defconfig sparc64 defconfig nios2 10m50_defconfig i386 alldefconfig i386 allnoconfig i386 allyesconfig ia64 allmodconfig ia64 allnoconfig ia64 allyesconfig ia64 alldefconfig c6x allyesconfig c6xevmc6678_defconfig nios2 3c120_defconfig xtensa iss_defconfig h8300 edosk2674_defconfig h8300h8300h-sim_defconfig h8300 h8s-sim_defconfig m68k m5475evb_defconfig m68k multi_defconfig arc allyesconfig arc defconfig powerpc defconfig powerpc ppc64_defconfig powerpc rhel-kconfig mips 32r2_defconfig mips 64r6el_defconfig mips allnoconfig mips allyesconfig mips malta_kvm_defconfig pariscallnoconfig parisc allyesconfig parisc b180_defconfig pariscc3000_defconfig x86_64 randconfig-a001-20200212 x86_64 randconfig-a002-20200212 x86_64 randconfig-a003-20200212 i386 randconfig-a001-20200212 i386 randconfig-a002-20200212 i386 randconfig-a003-20200212 x86_64 randconfig-a001-20200213 x86_64 randconfig-a002-20200213 x86_64 randconfig-a003-20200213 i386 randconfig-a001-20200213 i386 randconfig-a002-20200213 i386 randconfig-a003-20200213 i386 randconfig-a003-20200211 i386 randconfig-a001-20200211 i386 randconfig-a002-20200211 x86_64 randconfig-a002-20200211 x86_64 randconfig-a003-20200211 x86_64 randconfig-a001-20200211 alpharandconfig-a001-20200211 m68k randconfig-a001-20200211 mips randconfig-a001-20200211 nds32randconfig-a001-20200211 parisc randconfig-a001-20200211 riscvrandconfig-a001-20200211 alpharandconfig-a001-20200212 m68k randconfig-a001-20200212 nds32
[driver-core:driver-core-next] BUILD SUCCESS 901cff7cb96140a658a848a568b606ba764239bc
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-next branch HEAD: 901cff7cb96140a658a848a568b606ba764239bc firmware_loader: load files from the mount namespace of init elapsed time: 2510m configs tested: 292 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm allmodconfig arm allnoconfig arm allyesconfig arm at91_dt_defconfig arm efm32_defconfig arm exynos_defconfig armmulti_v5_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm64 defconfig sparcallyesconfig riscvnommu_virt_defconfig sparc defconfig riscv defconfig s390 debug_defconfig riscv rv32_defconfig s390defconfig mips allmodconfig m68k sun3_defconfig sh rsk7269_defconfig shtitan_defconfig powerpc allnoconfig openrisc simple_smp_defconfig s390 allmodconfig mips allyesconfig sh sh7785lcr_32bit_defconfig microblazenommu_defconfig parisc defconfig um defconfig m68k m5475evb_defconfig microblaze mmu_defconfig ia64 allyesconfig ia64defconfig sparc64 allmodconfig m68k allmodconfig cskydefconfig nds32 defconfig h8300 h8s-sim_defconfig powerpc ppc64_defconfig alpha defconfig sparc64 defconfig s390 alldefconfig xtensa common_defconfig i386 alldefconfig i386 allnoconfig i386 allyesconfig i386defconfig ia64 alldefconfig ia64 allmodconfig ia64 allnoconfig c6x allyesconfig c6xevmc6678_defconfig nios2 10m50_defconfig nios2 3c120_defconfig openriscor1ksim_defconfig xtensa iss_defconfig nds32 allnoconfig h8300 edosk2674_defconfig h8300h8300h-sim_defconfig m68k multi_defconfig arc allyesconfig arc defconfig powerpc defconfig powerpc rhel-kconfig mips 32r2_defconfig mips 64r6el_defconfig mips allnoconfig mips fuloong2e_defconfig mips malta_kvm_defconfig pariscallnoconfig parisc allyesconfig parisc b180_defconfig pariscc3000_defconfig x86_64 randconfig-a001-20200212 x86_64 randconfig-a002-20200212 x86_64 randconfig-a003-20200212 i386 randconfig-a001-20200212 i386 randconfig-a002-20200212 i386 randconfig-a003-20200212 x86_64 randconfig-a001-20200213 x86_64 randconfig-a002-20200213 x86_64 randconfig-a003-20200213 i386 randconfig-a001-20200213 i386 randconfig-a002-20200213 i386 randconfig-a003-20200213 parisc randconfig-a001-20200211 riscvrandconfig-a001-20200211 mips randconfig-a001-20200211 m68k randconfig-a001-20200211 nds32randconfig-a001-20200211 alpharandconfig-a001-20200211 alpharandconfig-a001-20200212 m68k randconfig-a001-20200212 nds32randconfig-a001-20200212 parisc randconfig-a001-20200212 riscvrandconfig-a001-20200212 alpha
Re: [PATCH] staging: exfat: add exfat filesystem code to staging
Hello! On Thursday 17 October 2019 09:50:08 Pali Rohár wrote: > On Wednesday 16 October 2019 16:33:17 Sasha Levin wrote: > > On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote: > > > On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote: > > > > On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote: > > > > > On Friday 30 August 2019 09:56:47 Pali Rohár wrote: > > > > > > On Thursday 29 August 2019 19:35:06 Sasha Levin wrote: > > > > > > > With regards to missing specs/docs/whatever - our main concern > > > > > > > with this > > > > > > > release was that we want full interoperability, which is why the > > > > > > > spec > > > > > > > was made public as-is without modifications from what was used > > > > > > > internally. There's no "secret sauce" that Microsoft is hiding > > > > > > > here. > > > > > > > > > > > > Ok, if it was just drop of "current version" of documentation then > > > > > > it > > > > > > makes sense. > > > > > > > > > > > > > How about we give this spec/code time to get soaked and reviewed > > > > > > > for a > > > > > > > bit, and if folks still feel (in a month or so?) that there are > > > > > > > missing > > > > > > > bits of information related to exfat, I'll be happy to go back > > > > > > > and try > > > > > > > to get them out as well. > > > > > > > > > > Hello Sasha! > > > > > > > > > > Now one month passed, so do you have some information when missing > > > > > parts > > > > > of documentation like TexFAT would be released to public? > > > > > > > > Sure, I'll see if I can get an approval to open it up. > > > > > > Ok! > > > > > > > Can I assume you will be implementing TexFAT support once the spec is > > > > available? > > > > > > I cannot promise that I would implement something which I do not know > > > how is working... It depends on how complicated TexFAT is and also how > > > future exfat support in kernel would look like. > > > > > > But I'm interesting in implementing it. > > > > It looks like the reason this wasn't made public along with the exFAT > > spec is that TexFAT is pretty much dead - it's old, there are no users > > we are aware of, and digging it out of it's grave to make it public is > > actually quite the headache. > > > > Is this something you actually have a need for? an entity that has a > > requirement for TexFAT? > > Hi! > > I do not have device with requirements for TexFAT. The first reason why > I wanted to use TexFAT was that it it the only way how to use more FAT > tables (e.g. secondary for backup) and information for that is missing > in released exFAT specification. This could bring better data recovery. > > > I'd would rather spend my time elsewhere than digging TexFAT out of it's > > grave. > > Ok. > > I was hoping that it would be possible to easily use secondary FAT table > (from TexFAT extension) for redundancy without need to implement full > TexFAT, which could be also backward compatible with systems which do > not implement TexFAT extension at all. Similarly like using FAT32 disk > with two FAT tables is possible also on system which use first FAT > table. By the chance, is there any possibility to release TexFAT specification? Usage of more FAT tables (even for Linux) could help with data recovery. > > Is there anything else in the exFAT spec that is missing (and someone > > actually wants/uses)? > > Currently I do not know. I found one missing thing: In released exFAT specification is not written how are Unicode code points above U+ represented in exFAT upcase table. Normally in UTF-16 are Unicode code points above U+ represented by surrogate pairs but compression format of exFAT upcase table is not clear how to do it there. Are you able to send question about this problem to relevant MS people? New Linux implementation of exfat which is waiting on mailing list just do not support Unicode code points above U+ in exFAT upcase table. -- Pali Rohár pali.ro...@gmail.com ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
