Re: [PATCH v1] add binder genl for txn report
On Mon, Aug 12, 2024 at 11:16:27PM -0700, Li Li wrote: > On Mon, Aug 12, 2024 at 10:13 PM Greg KH wrote: > > > > On Mon, Aug 12, 2024 at 02:18:44PM -0700, Li Li wrote: > > > From: Li Li > > > > Sorry, but I can not parse your Subject: line at all. Please use > > vowels, we don't have a lack of them :) > > > > Also look at how other patches are formatted for these files to get an > > idea of how to create a good subject line. > > Thank you for reviewing the patch! > > Sure, I'll find a more meaningful subject in v2. > > > > To prevent making the already bloated binder.c even bigger, a new source > > > file binder_genl.c is created to host those generic netlink code. > > > > "genl" is a rough abbreviation that is not going to be easy to remember, > > what's wrong with "binder_netlink.c"? > > It's just because genl has already been used in both of generic netlink > kernel code (e.g. in linux/include/net/genetlink.h) and user space libraries > https://man7.org/linux/man-pages/man8/genl.8.html. Ah, I wasn't aware of the existing names, so that's fine if it is what the networking world is used to. Which reminds me, why aren't you asking for their review here as well to ensure that you are doing things with netlink correctly? > > What userspace code is now going to use this and require it? How was it > > tested? Where is the test code? Where is the new user/kernel api that > > you created here documented? > > As mentioned in the commit message, binder is used in Android OS. But the > user space administration process can do little to deal with binder > transaction > errors. This is tested with Android. I'll upload the user space code to AOSP. > If there's a better option to host the test code, e.g. a smaller and > simpler project > that uses binder, please let me know. It needs to be somewhere, otherwise we don't know how any of this is being used at all. And there was some binder "test code" somewhere, is this new functionality added to that also? > > You added a new ioctl here as well, why not mention that? Why is it > > needed? Why not always emit netlink messages? How do you turn them > > off? > > The generic netlink message is a convenient way for the kernel driver to send > information to user space. Technically it's possible to replace this > new ioctl with > a netlink message. But that requires much more unnecessary code parsing the > raw byte streams and accessing internal binder_proc and other structures from > netlink layer. It's much more elegant to use an ioctl with only a > couple lines of > source code. Then you need to document that somewhere. > To turn them off, just call the same ioctl, resetting the flags to 0. > That said, the > name of this new ioctl (BINDER_ENABLE_REPORT) isn't good enough. > What do you think if I change it to BINDER_SET_NETLINK_REPORT? Yes, the name needs to change if you can both enable and disable reports from it. > > And how does this deal with binder namespaces? Are these messages all > > now "global" somehow? Or are they separated properly per namespace? > > The new ioctl BINDER_ENABLE_REPORT (again, it deserves a better name) > sets the report_flags for its associated binder context. Each binder context > has > its own settings. The messages from all binder contexts are sent to user space > via the same netlink socket. The user space code can enable the reports for > each binder context separately and distinguish the netlink messages by the > name of the binder context. So userspace will now get all reports and has to do the parsing to determine what is, and is not, relevant for what they want? That feels like a big security hole to me, has this been audited by the Android security team yet? > It's also possible to have one netlink socket for each binder context. > But it seems > like overkill to me. Again, think of security issues please. Do you want all binder processes in a system to be able to see all other messages? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] add binder genl for txn report
On Mon, Aug 12, 2024 at 02:18:44PM -0700, Li Li wrote:
> From: Li Li
Sorry, but I can not parse your Subject: line at all. Please use
vowels, we don't have a lack of them :)
Also look at how other patches are formatted for these files to get an
idea of how to create a good subject line.
> Frozen tasks can't process binder transactions, so sync binder
> transactions will fail with BR_FROZEN_REPLY and async binder
> transactions will be queued in the kernel async binder buffer.
> As these queued async transactions accumulates over time, the async
> buffer will eventually be running out, denying all new transactions
> after that with BR_FAILED_REPLY.
>
> In addition to the above cases, different kinds of binder error codes
> might be returned to the sender. However, the core Linux, or Android,
> system administration process never knows what's actually happening.
>
> This patch introduces the Linux generic netlink messages into the binder
> driver so that the Linux/Android system administration process can
> listen to important events and take corresponding actions, like stopping
> a broken app from attacking the OS by sending huge amount of spamming
> binder transactions.
>
> To prevent making the already bloated binder.c even bigger, a new source
> file binder_genl.c is created to host those generic netlink code.
"genl" is a rough abbreviation that is not going to be easy to remember,
what's wrong with "binder_netlink.c"?
>
> Usage example (user space pseudo code):
>
> // enable binder report from the interested binder context(s)
> struct binder_report_info info = {0, BINDER_REPORT_ALL};
> ioctl(binder1, BINDER_ENABLE_REPORT, &info);
> ioctl(binder2, BINDER_ENABLE_REPORT, &info);
>
> // set optional per-process report, overriding the global one
> struct binder_report_info info2;
> info2.pid = getpid();
> info2.flags = BINDER_REPORT_FAILED | BINDER_REPORT_OVERRIDE;
> ioctl(binder2, BINDER_ENABLE_REPORT, &info2);
>
> // open netlink socket
> int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
>
> // bind netlink socket
> bind(fd, struct socketaddr);
>
> // get the family id of binder generic netlink
> send(fd, CTRL_CMD_GETFAMILY, CTRL_ATTR_FAMILY_NAME);
> int id = recv(CTRL_ATTR_FAMILY_ID);
>
> // register the current process to receive binder reports
> send(fd, id, BINDER_GENL_CMD_REGISTER);
>
> // verify registration by reading back the registered pid
> recv(fd, BINDER_GENL_ATTR_PID, &pid);
>
> // wait and read all binder reports
> while (running) {
> struct binder_report report;
> recv(fd, BINDER_GENL_ATTR_REPORT, &report);
>
> // process struct binder_report
> do_something(&report);
> }
>
> // clean up
> close(fd);
What userspace code is now going to use this and require it? How was it
tested? Where is the test code? Where is the new user/kernel api that
you created here documented?
You added a new ioctl here as well, why not mention that? Why is it
needed? Why not always emit netlink messages? How do you turn them
off?
And how does this deal with binder namespaces? Are these messages all
now "global" somehow? Or are they separated properly per namespace?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: pi433: Updated bitrate range from datasheet
On Mon, Mar 04, 2024 at 02:28:02AM +0530, Aman Sharma wrote: > From a0528708b209739f0d566401bdd428e215abf366 Mon Sep 17 00:00:00 2001 > From: Aman Sharma > Date: Mon, 4 Mar 2024 00:44:06 +0530 > Subject: [PATCH] Staging: pi433: Updated bitrate range from datasheet Why is this all here in the changelog? Also, please use scripts/get_maintainer.pl, you have sent this to an obsolete email list. > > Updated bitrate range for FSK and OOK modulation from datasheet. > > Signed-off-by: Aman Sharma > --- > drivers/staging/pi433/Documentation/pi433.txt | 6 -- > drivers/staging/pi433/TODO| 1 - > 2 files changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/pi433/Documentation/pi433.txt > b/drivers/staging/pi433/Documentation/pi433.txt > index 4a0d34b4ad37..9ce7282ef6f8 100644 > --- a/drivers/staging/pi433/Documentation/pi433.txt > +++ b/drivers/staging/pi433/Documentation/pi433.txt > @@ -78,7 +78,8 @@ rf params: > Allowed values: 43305...43479 > bit_rate > bit rate used for transmission. > - Allowed values: # > + Allowed values (For FSK): 1200...32 > + Allowed values (For OOK): 1200...32768 > dev_frequency > frequency deviation in case of FSK. > Allowed values: 600...50 > @@ -169,7 +170,8 @@ rf params: > Allowed values: 43305...43479 > bit_rate > bit rate used for transmission. > - Allowed values: # > + Allowed values (For FSK): 1200...32 > + Allowed values (For OOK): 1200...32768 Where did these values come from? If you can explain that in the changelog text when you resend a v2, that would be great. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ks7010: remove unnecesary parentheses
On Fri, Mar 31, 2023 at 01:04:59AM +0800, Joel C. Chang wrote:
> On Thu, Mar 30, 2023 at 02:49:54PM +0200, Greg KH wrote:
> > On Thu, Mar 30, 2023 at 08:44:35PM +0800, Joel Camilo Chang Gonzalez wrote:
> > > Remove parentheses not needed in if statement
> > >
> > > Signed-off-by: Joel Camilo Chang Gonzalez
> > > ---
> > > drivers/staging/ks7010/ks_hostif.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/staging/ks7010/ks_hostif.c
> > > b/drivers/staging/ks7010/ks_hostif.c
> > > index af3825578d85..8bded7e88ce7 100644
> > > --- a/drivers/staging/ks7010/ks_hostif.c
> > > +++ b/drivers/staging/ks7010/ks_hostif.c
> > > @@ -129,7 +129,7 @@ int get_current_ap(struct ks_wlan_private *priv,
> > > struct link_ap_info *ap_info)
> > > size = (ap_info->rsn.size <= RSN_IE_BODY_MAX) ?
> > > ap_info->rsn.size : RSN_IE_BODY_MAX;
> > > if ((ap_info->rsn_mode & RSN_MODE_WPA2) &&
> > > - (priv->wpa.version == IW_AUTH_WPA_VERSION_WPA2)) {
> > > + priv->wpa.version == IW_AUTH_WPA_VERSION_WPA2) {
> >
> > If you look in the archives, you will see that I reject this type of
> > patch all the time.
> >
> > Also, please use scripts/get_maintainer.pl to determine who to send this
> > to, you used a very old mailing list address that is long dead.
> >
> > thanks,
> >
> > greg k-h
>
> Thanks for the input. I wasn't sure who to send it to, since the TODO in
> the driver and the script have different email addresses.
>
> Is there a place to check for inactive mailing lists?
Just trust the get_maintainer.pl script, it knows what to do.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ks7010: remove unnecessary parentheses
On Thu, Mar 30, 2023 at 08:48:28PM +0800, Joel Camilo Chang Gonzalez wrote: > Remove redundant parentheses > > Signed-off-by: Joel Camilo Chang Gonzalez > --- > drivers/staging/ks7010/ks_wlan_net.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/ks7010/ks_wlan_net.c > b/drivers/staging/ks7010/ks_wlan_net.c > index e03c87f0bfe7..eef1a1e70088 100644 > --- a/drivers/staging/ks7010/ks_wlan_net.c > +++ b/drivers/staging/ks7010/ks_wlan_net.c > @@ -193,14 +193,14 @@ static int ks_wlan_set_freq(struct net_device *dev, > fwrq->freq.m = c + 1; > } > /* Setting by channel number */ > - if ((fwrq->freq.m > 1000) || (fwrq->freq.e > 0)) > + if (fwrq->freq.m > 1000 || fwrq->freq.e > 0) Do you want to have to remember the precidence order between "||" and ">"? I don't, so please don't make this change. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ks7010: remove unnecesary parentheses
On Thu, Mar 30, 2023 at 08:44:35PM +0800, Joel Camilo Chang Gonzalez wrote:
> Remove parentheses not needed in if statement
>
> Signed-off-by: Joel Camilo Chang Gonzalez
> ---
> drivers/staging/ks7010/ks_hostif.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/ks7010/ks_hostif.c
> b/drivers/staging/ks7010/ks_hostif.c
> index af3825578d85..8bded7e88ce7 100644
> --- a/drivers/staging/ks7010/ks_hostif.c
> +++ b/drivers/staging/ks7010/ks_hostif.c
> @@ -129,7 +129,7 @@ int get_current_ap(struct ks_wlan_private *priv, struct
> link_ap_info *ap_info)
> size = (ap_info->rsn.size <= RSN_IE_BODY_MAX) ?
> ap_info->rsn.size : RSN_IE_BODY_MAX;
> if ((ap_info->rsn_mode & RSN_MODE_WPA2) &&
> - (priv->wpa.version == IW_AUTH_WPA_VERSION_WPA2)) {
> + priv->wpa.version == IW_AUTH_WPA_VERSION_WPA2) {
If you look in the archives, you will see that I reject this type of
patch all the time.
Also, please use scripts/get_maintainer.pl to determine who to send this
to, you used a very old mailing list address that is long dead.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Missing patch for Partial crash when loading driver rtl8192e
On Tue, Oct 11, 2022 at 09:43:46PM +0200, Philipp Hortmann wrote: > Hi, > > yesterday I did a git pull. > > when I tried to load the driver rtl8192e I had the below partial crash. > > I was able to fix it with this patch: > > https://lore.kernel.org/netdev/20220926233458.5316-1-yin31...@gmail.com/ > > Thanks for your support. > > Bye Philipp > > > This has worked before. But now I get this in my dmesg > [ 224.792852] [ cut here ] > [ 224.792856] memcpy: detected field-spanning write (size 8) of single > field "&compat_event->pointer" at net/wireless/wext-core.c:623 (size 4) Turn this option off, or apply the above patch :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: Android: ashmem.c: Fixed missing const modifier
On Thu, Sep 15, 2022 at 08:58:27PM +1200, Jonathan Bergh wrote:
> Fixed missing const modifier line 370
>
> Signed-off-by: Jonathan Bergh
> ---
> drivers/staging/android/ashmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/android/ashmem.c
> b/drivers/staging/android/ashmem.c
> index c05a214191da..a04488efd5f2 100644
> --- a/drivers/staging/android/ashmem.c
> +++ b/drivers/staging/android/ashmem.c
> @@ -367,7 +367,7 @@ ashmem_vmfile_get_unmapped_area(struct file *file,
> unsigned long addr,
>
> static int ashmem_mmap(struct file *file, struct vm_area_struct *vma)
> {
> - static struct file_operations vmfile_fops;
> + static struct const file_operations vmfile_fops;
> struct ashmem_area *asma = file->private_data;
> int ret = 0;
>
> --
> 2.34.1
>
Always test-build your patches before sending them out so you don't get
grumpy emails from maintainers asking you to test-build your patches
before sending them out.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Confirmation for subscribe linux-usb
On Wed, Aug 24, 2022 at 02:36:55PM +0800, Hu Xiaoying wrote: > submit patch > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch was attached, please place it inline so that it can be applied directly from the email message itself. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v3 0/1] Binder: add TF_UPDATE_TXN to replace outdated txn
On Wed, Jun 15, 2022 at 11:05:23AM -0700, Li Li wrote: > On Thu, May 26, 2022 at 10:50 PM Greg KH wrote: > > > > On Thu, May 26, 2022 at 03:00:17PM -0700, Li Li wrote: > > > From: Li Li > > > > > > Resend [Patch v3] with cover letter in case my previous email failed > > > to reach the maillist (no comments for 2 weeks). > > > > > > The previous comments of the old patch can be found at the following link: > > > https://lore.kernel.org/lkml/canbpypjknwso94nug1tkr1dgk2w2kbxijtriyvb7s3czhtz...@mail.gmail.com/ > > > > > > I copy and paste the key information here for your convenience. > > > > > > * Question #1 > > > > > > Note, your subject does not say what TF_UPDATE_TXN is, so it's a bit > > > hard to determine what is happening here. Can you clean that up a bit > > > and sumarize what this new addition does? > > > How was this tested? > > > > > > * Answer #1 === > > > > > > A more descriptive summary has been added to the new version of patch. > > > > > > * Question #2 > > > > > > How was this tested? > > > > > > * Answer #2 > > > > > > Old kernel: without this TF_UPDATE_TXN patch > > > New kernel: with this TF_UPDATE_TXN patch > > > Old apps: without setting TF_UPDATE_TXN > > > New apps: if (flags & TF_ONE_WAY) flags |= TF_UPDATE_TXN; > > > > > > 1. Compatibility: New kernel + Old apps, to verify the original > > > behavior doesn't change; > > > > > > 2. Compatibility: Old kernel + New apps, to verify the original > > > behavior doesn't change; > > > > > > 3. Unit test: New kernel + New apps, to verify the outdated oneway > > > binder transaction is actually superseded by the latest one (by > > > enabling BINDER_DEBUG logs); > > > > > > 4. Stress test: New kernel + New apps sending oneway binder > > > transactions repeatedly, to verify the size of the available async > > > binder buffer over time, and if the transactions fail as before > > > (due to async buffer running out). > > > > > > * Question #3 > > > > > > Did checkpatch pass this? Please always use --strict and fix up all the > > > issues that it reports as this is not a normal kernel coding style. > > > > > > * Answer #3 > > > > > > Yes, the latest version has passed "./scripts/checkpatch.pl --strict" > > > > > > * Changelog > > > > > > v3: > > > - Add this changelog required by "The canonical patch format" > > > v2: > > > - Fix alignment warnings reported by checkpatch --strict > > > - Add descriptive summary in patch subject > > > > > > Li Li (1): > > > Binder: add TF_UPDATE_TXN to replace outdated txn > > > > > > drivers/android/binder.c| 85 - > > > drivers/android/binder_trace.h | 4 ++ > > > include/uapi/linux/android/binder.h | 1 + > > > 3 files changed, 87 insertions(+), 3 deletions(-) > > > > > > -- > > > 2.36.1.124.g0e6072fb45-goog > > > > > > ___ > > > devel mailing list > > > de...@linuxdriverproject.org > > > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel > > > > > > Hi, > > > > This is the friendly semi-automated patch-bot of Greg Kroah-Hartman. > > You have sent him a patch that has triggered this response. > > > > Right now, the development tree you have sent a patch for is "closed" > > due to the timing of the merge window. Don't worry, the patch(es) you > > have sent are not lost, and will be looked at after the merge window is > > over (after the -rc1 kernel is released by Linus). > > > > So thank you for your patience and your patches will be reviewed at this > > later time, you do not have to do anything further, this is just a short > > note to let you know the patch status and so you don't worry they didn't > > make it through. > > Hi Greg and all reviewers, > > The rc-1 has been released for some days. Do I need to resend the patch > v3 [1] again to the maillist? Please let me know what I should do next to > have it reviewed. Thanks! If it still applies, no need to resend. I'm waiting for the other binder maintainers to review it before doing anything with it. thanks greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] Binder: add TF_UPDATE_TXN to replace outdated txn
On Thu, May 19, 2022 at 11:34:54AM -0700, Li Li wrote:
> From: Li Li
>
> When the target process is busy, incoming oneway transactions are
> queued in the async_todo list. If the clients continue sending extra
> oneway transactions while the target process is frozen, this queue can
> become too large to accommodate new transactions. That's why binder
> driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
> helpful to debug the async binder buffer exhausting issue, but the
> issue itself isn't solved directly.
>
> In real cases applications are designed to send oneway transactions
> repeatedly, delivering updated inforamtion to the target process.
> Typical examples are Wi-Fi signal strength and some real time sensor
> data. Even if the apps might only care about the lastet information,
> all outdated oneway transactions are still accumulated there until the
> frozen process is thawed later. For this kind of situations, there's
> no existing method to skip those outdated transactions and deliver the
> latest one only.
>
> This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
> use apps can set this new flag along with TF_ONE_WAY. When such an
> oneway transaction is to be queued into the async_todo list of a frozen
> process, binder driver will check if any previous pending transactions
> can be superseded by comparing their code, flags and target node. If
> such an outdated pending transaction is found, the latest transaction
> will supersede that outdated one. This effectively prevents the async
> binder buffer running out and saves unnecessary binder read workloads.
>
> Signed-off-by: Li Li
> ---
> drivers/android/binder.c| 85 -
> drivers/android/binder_trace.h | 4 ++
> include/uapi/linux/android/binder.h | 1 +
> 3 files changed, 87 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index f3b639e89dd8..bb968cf2f9ec 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -2594,6 +2594,56 @@ static int binder_fixup_parent(struct list_head
> *pf_head,
> return binder_add_fixup(pf_head, buffer_offset, bp->buffer, 0);
> }
>
> +/**
> + * binder_can_update_transaction() - Can a txn be superseded by an updated
> one?
> + * @t1: the pending async txn in the frozen process
> + * @t2: the new async txn to supersede the outdated pending one
> + *
> + * Return: true if t2 can supersede t1
> + * false if t2 can not supersede t1
> + */
> +static bool binder_can_update_transaction(struct binder_transaction *t1,
> + struct binder_transaction *t2)
> +{
> + if ((t1->flags & t2->flags & (TF_ONE_WAY | TF_UPDATE_TXN)) !=
> + (TF_ONE_WAY | TF_UPDATE_TXN) || !t1->to_proc || !t2->to_proc)
> + return false;
> + if (t1->to_proc->tsk == t2->to_proc->tsk && t1->code == t2->code &&
> + t1->flags == t2->flags && t1->buffer->pid == t2->buffer->pid &&
> + t1->buffer->target_node->ptr == t2->buffer->target_node->ptr &&
> + t1->buffer->target_node->cookie == t2->buffer->target_node->cookie)
> + return true;
> + return false;
> +}
> +
> +/**
> + * binder_find_outdated_transaction_ilocked() - Find the outdated transaction
> + * @t:new async transaction
> + * @target_list: list to find outdated transaction
> + *
> + * Return: the outdated transaction if found
> + * NULL if no outdated transacton can be found
> + *
> + * Requires the proc->inner_lock to be held.
> + */
> +static struct binder_transaction *
> +binder_find_outdated_transaction_ilocked(struct binder_transaction *t,
> + struct list_head *target_list)
> +{
> + struct binder_work *w;
> +
> + list_for_each_entry(w, target_list, entry) {
> + struct binder_transaction *t_queued;
> +
> + if (w->type != BINDER_WORK_TRANSACTION)
> + continue;
> + t_queued = container_of(w, struct binder_transaction, work);
> + if (binder_can_update_transaction(t_queued, t))
> + return t_queued;
> + }
> + return NULL;
> +}
> +
> /**
> * binder_proc_transaction() - sends a transaction to a process and wakes it
> up
> * @t: transaction to send
> @@ -2619,6 +2669,7 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> struct binder_node *node = t->buffer->target_node;
> bool oneway = !!(t->flags & TF_ONE_WAY);
> bool pending_async = false;
> + struct binder_transaction *t_outdated = NULL;
>
> BUG_ON(!node);
> binder_node_lock(node);
> @@ -2646,12 +2697,24 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> if (!thread && !pending_async)
> thread = binder_select_thread_ilocked(proc);
>
> - if (thread)
> + if (thread) {
> bi
Re: [PATCH v1] Binder: add TF_UPDATE_TXN
On Wed, May 18, 2022 at 05:06:23PM -0700, Li Li wrote:
> From: Li Li
Note, your subject does not say what TF_UPDATE_TXN is, so it's a bit
hard to determine what is happening here. Can you clean that up a bit
and sumarize what this new addition does?
>
> When the target process is busy, incoming oneway transactions are
> queued in the async_todo list. If the clients continue sending extra
> oneway transactions while the target process is frozen, this queue can
> become too large to accommodate new transactions. That's why binder
> driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
> helpful to debug the async binder buffer exhausting issue, but the
> issue itself isn't solved directly.
>
> In real cases applications are designed to send oneway transactions
> repeatedly, delivering updated inforamtion to the target process.
> Typical examples are Wi-Fi signal strength and some real time sensor
> data. Even if the apps might only care about the lastet information,
> all outdated oneway transactions are still accumulated there until the
> frozen process is thawed later. For this kind of situations, there's
> no existing method to skip those outdated transactions and deliver the
> latest one only.
>
> This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
> use apps can set this new flag along with TF_ONE_WAY. When such an
> oneway transaction is to be queued into the async_todo list of a frozen
> process, binder driver will check if any previous pending transactions
> can be superseded by comparing their code, flags and target node. If
> such an outdated pending transaction is found, the latest transaction
> will supersede that outdated one. This effectively prevents the async
> binder buffer running out and saves unnecessary binder read workloads.
>
> Signed-off-by: Li Li
> ---
> drivers/android/binder.c| 90 -
> drivers/android/binder_trace.h | 4 ++
> include/uapi/linux/android/binder.h | 1 +
How was this tested?
> 3 files changed, 92 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index f3b639e89dd8..153486a32d69 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -2594,6 +2594,60 @@ static int binder_fixup_parent(struct list_head
> *pf_head,
> return binder_add_fixup(pf_head, buffer_offset, bp->buffer, 0);
> }
>
> +/**
> + * binder_can_update_transaction() - Can a txn be superseded by an updated
> one?
> + * @t1: the pending async txn in the frozen process
> + * @t2: the new async txn to supersede the outdated pending one
> + *
> + * Return: true if t2 can supersede t1
> + * false if t2 can not supersede t1
> + */
> +static bool binder_can_update_transaction(struct binder_transaction *t1,
> + struct binder_transaction *t2)
> +{
> + if ((t1->flags & t2->flags & (TF_ONE_WAY | TF_UPDATE_TXN))
> + != (TF_ONE_WAY | TF_UPDATE_TXN)
> + || t1->to_proc == NULL || t2->to_proc == NULL)
> + return false;
> + if (t1->to_proc->tsk == t2->to_proc->tsk && t1->code == t2->code
> + && t1->flags == t2->flags
> + && t1->buffer->pid == t2->buffer->pid
> + && t1->buffer->target_node->ptr
> + == t2->buffer->target_node->ptr
> + && t1->buffer->target_node->cookie
> + == t2->buffer->target_node->cookie)
Did checkpatch pass this? Please always use --strict and fix up all the
issues that it reports as this is not a normal kernel coding style,
sorry.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()
On Tue, Mar 29, 2022 at 03:50:12PM +0800, QintaoShen wrote: > The memory allocation function devm_kcalloc() may return NULL pointer, > so it is better to add a check for 'p->func[i]->pins' to avoid possible > NULL pointer dereference. > > Signed-off-by: QintaoShen > --- > drivers/pinctrl/ralink/pinctrl-rt2880.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/pinctrl/ralink/pinctrl-rt2880.c > b/drivers/pinctrl/ralink/pinctrl-rt2880.c > index 96fc06d..308610e 100644 > --- a/drivers/pinctrl/ralink/pinctrl-rt2880.c > +++ b/drivers/pinctrl/ralink/pinctrl-rt2880.c > @@ -266,6 +266,10 @@ static int rt2880_pinmux_pins(struct rt2880_priv *p) > p->func[i]->pin_count, > sizeof(int), > GFP_KERNEL); > + > +if (!p->func[i]->pins) > +continue; > + > for (j = 0; j < p->func[i]->pin_count; j++) > p->func[i]->pins[j] = p->func[i]->pin_first + j; > > -- > 2.7.4 > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch contains warnings and/or errors noticed by the scripts/checkpatch.pl tool. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl871: rtl871x_mlme: fixed coding style issues
On Sat, Dec 25, 2021 at 11:32:39PM -0500, Agam Kohli wrote:
> Fixed multiple line dereferences
>
> Signed-off-by: Agam Kohli
> ---
> drivers/staging/rtl8712/rtl871x_mlme.c | 125 ++---
> 1 file changed, 49 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c
> b/drivers/staging/rtl8712/rtl871x_mlme.c
> index cabdb3549a5a..a2ced1b54ab5 100644
> --- a/drivers/staging/rtl8712/rtl871x_mlme.c
> +++ b/drivers/staging/rtl8712/rtl871x_mlme.c
> @@ -1,6 +1,5 @@
> // SPDX-License-Identifier: GPL-2.0
>
> /**
> - * rtl871x_mlme.c
> *
> * Copyright(c) 2007 - 2010 Realtek Corporation. All rights reserved.
> * Linux device driver for RTL8192SU
> @@ -124,7 +123,6 @@ static void free_network_nolock(struct mlme_priv
> *pmlmepriv,
> pmlmepriv->num_of_scanned--;
> }
>
> -
> /* return the wlan_network with the matching addr
> * Shall be called under atomic context...
> * to avoid possible racing condition...
> @@ -140,13 +138,13 @@ static struct wlan_network *r8712_find_network(struct
> __queue *scanned_queue,
> return NULL;
> spin_lock_irqsave(&scanned_queue->lock, irqL);
> phead = &scanned_queue->queue;
> - plist = phead->next;
> - while (plist != phead) {
> - pnetwork = container_of(plist, struct wlan_network, list);
> - plist = plist->next;
> + list_for_each(plist, phead) {
> + pnetwork = list_entry(plist, struct wlan_network, list);
> if (!memcmp(addr, pnetwork->network.MacAddress, ETH_ALEN))
> break;
> }
> + if (plist == phead)
> + pnetwork = NULL;
> spin_unlock_irqrestore(&scanned_queue->lock, irqL);
> return pnetwork;
> }
> @@ -249,8 +247,8 @@ static int is_same_network(struct wlan_bssid_ex *src,
> src->Ssid.SsidLength))) &&
> ((s_cap & WLAN_CAPABILITY_IBSS) ==
> (d_cap & WLAN_CAPABILITY_IBSS)) &&
> - ((s_cap & WLAN_CAPABILITY_BSS) ==
> - (d_cap & WLAN_CAPABILITY_BSS));
> + ((s_cap & WLAN_CAPABILITY_ESS) ==
> + (d_cap & WLAN_CAPABILITY_ESS));
>
> }
>
> @@ -264,13 +262,13 @@ struct wlan_network *r8712_get_oldest_wlan_network(
> phead = &scanned_queue->queue;
> plist = phead->next;
> while (1) {
> - if (end_of_queue_search(phead, plist) == true)
> + if (end_of_queue_search(phead, plist))
> break;
> pwlan = container_of(plist, struct wlan_network, list);
> - if (pwlan->fixed != true) {
> - if (oldest == NULL ||
> + if (!pwlan->fixed) {
> + if (!oldest ||
> time_after((unsigned long)oldest->last_scanned,
> - (unsigned long)pwlan->last_scanned))
> +(unsigned long)pwlan->last_scanned))
> oldest = pwlan;
> }
> plist = plist->next;
> @@ -358,7 +356,6 @@ static void update_scanned_network(struct _adapter
> *adapter,
> plist = plist->next;
> }
>
> -
> /* If we didn't find a match, then get a new network slot to initialize
>* with this beacon's information
>*/
> @@ -433,8 +430,7 @@ static int is_desired_network(struct _adapter *adapter,
> bselected = false;
> if (check_fwstate(&adapter->mlmepriv, WIFI_ADHOC_STATE)) {
> if (pnetwork->network.InfrastructureMode !=
> - adapter->mlmepriv.cur_network.network.
> - InfrastructureMode)
> +
> adapter->mlmepriv.cur_network.network.InfrastructureMode)
> bselected = false;
> }
> return bselected;
> @@ -541,8 +537,7 @@ void r8712_surveydone_event_callback(struct _adapter
> *adapter, u8 *pbuf)
> struct wlan_bssid_ex *pdev_network =
> &(adapter->registrypriv.dev_network);
> u8 *pibss =
> - adapter->registrypriv.
> - dev_network.MacAddress;
> +
> adapter->registrypriv.dev_network.MacAddress;
> pmlmepriv->fw_state ^= _FW_UNDER_SURVEY;
> memcpy(&pdev_network->Ssid,
> &pmlmepriv->assoc_ssid,
> @@ -621,7 +616,6 @@ void r8712_indicate_connect(struct _adapter *padapter)
> jiffies + msecs_to_jiffies(6));
> }
>
> -
> /*
> * r8712_ind_disconnect: the caller has to lock pmlmepriv->lock
> */
>
Re: [PATCH] binder: fix async_free_space accounting for empty parcels
On Mon, Dec 20, 2021 at 11:06:09AM -0800, Todd Kjos wrote:
> On Mon, Dec 20, 2021 at 11:02 AM Todd Kjos wrote:
> >
> > In 4.13, commit 74310e06be4d ("android: binder: Move buffer out of area
> > shared with user space")
> > fixed a kernel structure visibility issue. As part of that patch,
> > sizeof(void *) was used as the buffer size for 0-length data payloads so
> > the driver could detect abusive clients sending 0-length asynchronous
> > transactions to a server by enforcing limits on async_free_size.
> >
> > Unfortunately, on the "free" side, the accounting of async_free_space
> > did not add the sizeof(void *) back. The result was that up to 8-bytes of
> > async_free_space were leaked on every async transaction of 8-bytes or
> > less. These small transactions are uncommon, so this accounting issue
> > has gone undetected for several years.
> >
> > The fix is to use "buffer_size" (the allocated buffer size) instead of
> > "size" (the logical buffer size) when updating the async_free_space
> > during the free operation. These are the same except for this
> > corner case of asynchronous transactions with payloads < 8 bytes.
> >
> > Fixes: 74310e06be4d ("android: binder: Move buffer out of area shared with
> > user space")
> > Signed-off-by: Todd Kjos
>
> I forgot to CC stable. This applies to all stable branches back to 4.14.
> Cc: sta...@vger.kernel.org # 4.14+
Thanks, I've added that to the patch when committing it.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/1] staging: ion: Prevent incorrect reference counting behavour
On Fri, Nov 26, 2021 at 10:33:35AM +, Lee Jones wrote:
> Supply additional checks in order to prevent unexpected results.
>
> Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> Suggested-by: Dan Carpenter
> Signed-off-by: Lee Jones
> ---
> Destined for v4.4.y and v4.9.y
>
> drivers/staging/android/ion/ion.c | 6 ++
> 1 file changed, 6 insertions(+)
Now queued up, thanks.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Fri, Nov 26, 2021 at 08:56:27AM +, Lee Jones wrote:
> On Fri, 26 Nov 2021, Dan Carpenter wrote:
>
> > On Thu, Nov 25, 2021 at 06:18:22PM +0300, Dan Carpenter wrote:
> > > I had thought that ->kmap_cnt was a regular int and not an unsigned
> > > int, but I would have to pull a stable tree to see where I misread the
> > > code.
> >
> > I was looking at (struct ion_buffer)->kmap_cnt but this is
> > (struct ion_handle)->kmap_cnt. I'm not sure how those are related but
> > it makes me nervous that one can go higher than the other. Also both
> > probably need overflow protection.
> >
> > So I guess I would just do something like:
> >
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c
> > index 806e9b30b9dc8..e8846279b33b5 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -489,6 +489,8 @@ static void *ion_buffer_kmap_get(struct ion_buffer
> > *buffer)
> > void *vaddr;
> >
> > if (buffer->kmap_cnt) {
> > + if (buffer->kmap_cnt == INT_MAX)
> > + return ERR_PTR(-EOVERFLOW);
> > buffer->kmap_cnt++;
> > return buffer->vaddr;
> > }
> > @@ -509,6 +511,8 @@ static void *ion_handle_kmap_get(struct ion_handle
> > *handle)
> > void *vaddr;
> >
> > if (handle->kmap_cnt) {
> > + if (handle->kmap_cnt == INT_MAX)
> > + return ERR_PTR(-EOVERFLOW);
> > handle->kmap_cnt++;
> > return buffer->vaddr;
> > }
>
> Which is all well and good until somebody changes the type.
That's hard to do on code that is removed from the kernel tree :)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, Nov 25, 2021 at 01:03:46PM +, Lee Jones wrote:
> On Thu, 25 Nov 2021, Greg KH wrote:
>
> > On Thu, Nov 25, 2021 at 12:46:23PM +, Lee Jones wrote:
> > > On Thu, 25 Nov 2021, Greg KH wrote:
> > >
> > > > On Thu, Nov 25, 2021 at 12:02:34PM +, Lee Jones wrote:
> > > > > Supply additional checks in order to prevent unexpected results.
> > > > >
> > > > > Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> > > > > Signed-off-by: Lee Jones
> > > > > ---
> > > > > drivers/staging/android/ion/ion.c | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/drivers/staging/android/ion/ion.c
> > > > > b/drivers/staging/android/ion/ion.c
> > > > > index 806e9b30b9dc8..30f359faba575 100644
> > > > > --- a/drivers/staging/android/ion/ion.c
> > > > > +++ b/drivers/staging/android/ion/ion.c
> > > > > @@ -509,6 +509,9 @@ static void *ion_handle_kmap_get(struct
> > > > > ion_handle *handle)
> > > > > void *vaddr;
> > > > >
> > > > > if (handle->kmap_cnt) {
> > > > > + if (handle->kmap_cnt + 1 < handle->kmap_cnt)
> > > >
> > > > What about using the nice helpers in overflow.h for this?
> > >
> > > I haven't heard of these before.
> > >
> > > Looks like they're not widely used.
> > >
> > > I'll try them out and see how they go.
> > >
> > > > > + return ERR_PTR(-EOVERFLOW);
> > > > > +
> > > > > handle->kmap_cnt++;
> > > > > return buffer->vaddr;
> > > > > }
> > > >
> > > > What stable kernel branch(es) is this for?
> > >
> > > I assumed your magic scripts could determine this from the Fixes:
> > > tag. I'll be more explicit in v2.
> >
> > The fixes tag says how far back for it to go, but not where to start
> > that process from :)
>
> What's your preferred method for identifying a start-point?
>
> In the [PATCH] tag or appended on to Cc: stable ... # ?
>
> I know both work, but what makes your life easier?
Easiest is below the --- line say:
---
This is for kernel versions X.X and older.
nothing complex.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, Nov 25, 2021 at 12:46:23PM +, Lee Jones wrote:
> On Thu, 25 Nov 2021, Greg KH wrote:
>
> > On Thu, Nov 25, 2021 at 12:02:34PM +, Lee Jones wrote:
> > > Supply additional checks in order to prevent unexpected results.
> > >
> > > Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> > > Signed-off-by: Lee Jones
> > > ---
> > > drivers/staging/android/ion/ion.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/staging/android/ion/ion.c
> > > b/drivers/staging/android/ion/ion.c
> > > index 806e9b30b9dc8..30f359faba575 100644
> > > --- a/drivers/staging/android/ion/ion.c
> > > +++ b/drivers/staging/android/ion/ion.c
> > > @@ -509,6 +509,9 @@ static void *ion_handle_kmap_get(struct ion_handle
> > > *handle)
> > > void *vaddr;
> > >
> > > if (handle->kmap_cnt) {
> > > + if (handle->kmap_cnt + 1 < handle->kmap_cnt)
> >
> > What about using the nice helpers in overflow.h for this?
>
> I haven't heard of these before.
>
> Looks like they're not widely used.
>
> I'll try them out and see how they go.
>
> > > + return ERR_PTR(-EOVERFLOW);
> > > +
> > > handle->kmap_cnt++;
> > > return buffer->vaddr;
> > > }
> >
> > What stable kernel branch(es) is this for?
>
> I assumed your magic scripts could determine this from the Fixes:
> tag. I'll be more explicit in v2.
The fixes tag says how far back for it to go, but not where to start
that process from :)
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, Nov 25, 2021 at 12:02:34PM +, Lee Jones wrote:
> Supply additional checks in order to prevent unexpected results.
>
> Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> Signed-off-by: Lee Jones
> ---
> drivers/staging/android/ion/ion.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 806e9b30b9dc8..30f359faba575 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -509,6 +509,9 @@ static void *ion_handle_kmap_get(struct ion_handle
> *handle)
> void *vaddr;
>
> if (handle->kmap_cnt) {
> + if (handle->kmap_cnt + 1 < handle->kmap_cnt)
What about using the nice helpers in overflow.h for this?
> + return ERR_PTR(-EOVERFLOW);
> +
> handle->kmap_cnt++;
> return buffer->vaddr;
> }
> --
> 2.34.0.rc2.393.gf8c9666880-goog
What stable kernel branch(es) is this for?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] binder: fix test regression due to sender_euid change
On Fri, Nov 19, 2021 at 03:39:59PM -0800, Todd Kjos wrote:
> On Fri, Nov 19, 2021 at 3:00 PM Paul Moore wrote:
> >
> > On Fri, Nov 12, 2021 at 1:07 PM Todd Kjos wrote:
> > >
> > > This is a partial revert of commit
> > > 29bc22ac5e5b ("binder: use euid from cred instead of using task").
> > > Setting sender_euid using proc->cred caused some Android system test
> > > regressions that need further investigation. It is a partial
> > > reversion because subsequent patches rely on proc->cred.
> > >
> > > Cc: sta...@vger.kernel.org # 4.4+
> > > Fixes: 29bc22ac5e5b ("binder: use euid from cred instead of using task")
> > > Signed-off-by: Todd Kjos
> > > Change-Id: I9b1769a3510fed250bb21859ef8beebabe034c66
>
> Greg, I neglected to remove the "Change-Id" from my Android pre-submit
> testing. Can you remove that, or would you like me to resubmit without
> it?
Sorry, I missed it too. It's already in my tree, no need to worry about
it.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/3] binder: Prevent untranslated sender data from being copied to target
On Tue, Nov 23, 2021 at 11:17:34AM -0800, Todd Kjos wrote: > Binder copies transactions directly from the sender buffer > to the target buffer and then fixes up BINDER_TYPE_PTR and > BINDER_TYPE_FDA objects. This means there is a brief time > when sender pointers and fds are visible to the target > process. > > This series reworks the the sender to target copy to > avoid leaking any untranslated sender data from being > visible in the target. > > Todd Kjos (3): > binder: defer copies of pre-patched txn data > binder: read pre-translated fds from sender buffer > binder: avoid potential data leakage when copying txn > > drivers/android/binder.c | 442 > + > 1 file changed, 387 insertions(+), 55 deletions(-) Are these changes needed now in 5.16-final and also in stable kernels? Or can they wait until 5.17-rc1? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: vt6655: refactor camelcase uCurrRSSI to current_rssi
On Fri, Nov 19, 2021 at 02:36:44PM +0100, Alberto Merciai wrote: > driver-core$ ./scripts/get_maintainer.pl drivers/staging/vt6655/device.h > Forest Bond (odd fixer:STAGING - VIA VT665X > DRIVERS) > Greg Kroah-Hartman (supporter:STAGING SUBSYSTEM) > Alberto Merciai > (commit_signer:2/2=100%,authored:2/2=100%,added_lines:2/2=100%,removed_lines:2/2=100%) > de...@driverdev.osuosl.org (open list:STAGING SUBSYSTEM) > linux-ker...@vger.kernel.org (open list) What kernel version is that? The driverdev mailing list is very old and should not be used anymore. Please always work against the latest version of the kernel, and for development stuff, linux-next is usually best so you do not duplicate any work that anyone else has done. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: vt6655: refactor camelcase uCurrRSSI to current_rssi
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Fri, Nov 19, 2021 at 01:23:51PM +0100, Alberto Merciai wrote: > I'm using the master branch of > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/ Very odd, why? That git tree has nothing to do with the staging development process, and especially not the master branch. What caused you to pick that one? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: vt6655: refactor camelcase uCurrRSSI to current_rssi
On Thu, Nov 18, 2021 at 09:27:18PM +0100, Alberto Merciai wrote: > Replace camelcase variable "uCurrRSSI" (current Received Signal Strength > Indicator) into linux kernel coding style equivalent > variable "current_rssi". > > Signed-off-by: Alberto Merciai > --- > > v2 > - correct mailing list No, you did not use the correct mailing list. What is the output of scripts/get_maintainer.pl on your patch? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: vt6655: refactor camelcase uCurrRSSI to current_rssi
On Tue, Nov 16, 2021 at 12:31:02AM +0100, Alberto Merciai wrote: > Replace camelcase variable "uCurrRSSI" (current Received Signal Strength > Indicator) into linux kernel coding style equivalent > variable "current_rssi". > > Signed-off-by: Alberto Merciai > --- Sent to the wrong mailing list, please use scripts/get_maintainer.pl properly. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] staging: vt6655: fix camelcase in wCurrentRate
On Mon, Nov 15, 2021 at 03:08:56PM +0100, Alberto Merciai wrote: > Replace camelcase word variable "wCurrentRate" into linux kernel coding > style equivalent "current_rate". > > Signed-off-by: Alberto Merciai Does not apply to my tree. Please rebase against the staging-next branch and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6655: refactor camelcase uCurrRSSI to current_rssi
On Sun, Nov 14, 2021 at 05:40:48PM +0100, Alberto Merciai wrote: > Replace camelcase variable "uCurrRSSI" (current Received Signal Strength > Indicator) into linux kernel coding style equivalent Odd line break :( And trailing whitespace :( > variable "current_rssi". > > References: > https://www.kernel.org/doc/html/latest/process/coding-style.html > https://www.cse.iitk.ac.in/users/dsrkg/cs245/html/Guide.htm Same comments on these links as before. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: vt6655: fix camelcase in wCurrentRate
On Sun, Nov 14, 2021 at 10:09:35AM +0100, Alberto Merciai wrote: > Replace camelcase word variable "wCurrentRate" into linux kernel coding > style equivalent "current_rate". > > References: > https://www.kernel.org/doc/html/latest/process/coding-style.html We all know the kernel coding style, no need to have a link to it in the changelog text, right? > https://www.cse.iitk.ac.in/users/dsrkg/cs245/html/Guide.htm Why is this here? That's a random college course web site. And random links in changelog text do not age well, include the full text of what matters in the changelog text itself, it should be self-contained where ever possible as these live much longer than random web site links will. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: vt6655: fix camelcase in wCurrentRate
On Sun, Nov 14, 2021 at 09:20:29AM +0100, Alberto Merciai wrote: > Replace camelcase word variable "wCurrentRate" into linux kernel coding > style equivalent "current_rate". > > References: > https://www.kernel.org/doc/html/latest/process/coding-style.html > https://www.cse.iitk.ac.in/users/dsrkg/cs245/html/Guide.htm > > Signed-off-by: Alberto Merciai > --- > drivers/staging/vt6655/device.h | 2 +- > drivers/staging/vt6655/device_main.c | 12 +-- > drivers/staging/vt6655/rxtx.c| 134 +-- > 3 files changed, 74 insertions(+), 74 deletions(-) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - This looks like a new version of a previously submitted patch, but you did not list below the --- line any changes from the previous version. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what needs to be done here to properly describe this. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6655: fix camelcase in wCurrentRate
On Sat, Nov 13, 2021 at 06:09:42PM +0100, Alberto Merciai wrote:
> Signed-off-by: Alberto Merciai
> ---
> drivers/staging/vt6655/device.h | 2 +-
> drivers/staging/vt6655/device_main.c | 12 +--
> drivers/staging/vt6655/rxtx.c| 134 +--
> 3 files changed, 74 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/staging/vt6655/device.h b/drivers/staging/vt6655/device.h
> index 29f354ced563..f5dee7ad99cd 100644
> --- a/drivers/staging/vt6655/device.h
> +++ b/drivers/staging/vt6655/device.h
> @@ -208,7 +208,7 @@ struct vnt_private {
> unsigned char byPreambleType;
> unsigned char byShortPreamble;
>
> - unsigned short wCurrentRate;
> + unsigned short current_rate;
> unsigned char byShortRetryLimit;
> unsigned char byLongRetryLimit;
> enum nl80211_iftype op_mode;
> diff --git a/drivers/staging/vt6655/device_main.c
> b/drivers/staging/vt6655/device_main.c
> index 41cbec4134b0..2c5398b128df 100644
> --- a/drivers/staging/vt6655/device_main.c
> +++ b/drivers/staging/vt6655/device_main.c
> @@ -213,7 +213,7 @@ static void device_init_registers(struct vnt_private
> *priv)
>
> priv->bNonERPPresent = false;
> priv->bBarkerPreambleMd = false;
> - priv->wCurrentRate = RATE_1M;
> + priv->current_rate = RATE_1M;
> priv->byTopOFDMBasicRate = RATE_24M;
> priv->byTopCCKBasicRate = RATE_1M;
>
> @@ -369,7 +369,7 @@ static void device_init_registers(struct vnt_private
> *priv)
>
> /* Set BB and packet type at the same time. */
> /* Set Short Slot Time, xIFS, and RSPINF. */
> - priv->wCurrentRate = RATE_54M;
> + priv->current_rate = RATE_54M;
>
> priv->bRadioOff = false;
>
> @@ -1382,11 +1382,11 @@ static int vnt_config(struct ieee80211_hw *hw, u32
> changed)
>
> if (changed & IEEE80211_CONF_CHANGE_POWER) {
> if (priv->byBBType == BB_TYPE_11B)
> - priv->wCurrentRate = RATE_1M;
> + priv->current_rate = RATE_1M;
> else
> - priv->wCurrentRate = RATE_54M;
> + priv->current_rate = RATE_54M;
>
> - RFbSetPower(priv, priv->wCurrentRate,
> + RFbSetPower(priv, priv->current_rate,
> conf->chandef.chan->hw_value);
> }
>
> @@ -1448,7 +1448,7 @@ static void vnt_bss_info_changed(struct ieee80211_hw
> *hw,
> }
>
> if (changed & BSS_CHANGED_TXPOWER)
> - RFbSetPower(priv, priv->wCurrentRate,
> + RFbSetPower(priv, priv->current_rate,
> conf->chandef.chan->hw_value);
>
> if (changed & BSS_CHANGED_BEACON_ENABLED) {
> diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
> index cfab64d2b312..17795ebcdfbc 100644
> --- a/drivers/staging/vt6655/rxtx.c
> +++ b/drivers/staging/vt6655/rxtx.c
> @@ -97,7 +97,7 @@ s_vFillRTSHead(
> bool bNeedAck,
> bool bDisCRC,
> struct ieee80211_hdr *hdr,
> - unsigned short wCurrentRate,
> + unsigned short current_rate,
> unsigned char byFBOption
> );
>
> @@ -114,7 +114,7 @@ s_vGenerateTxParameter(
> bool bNeedACK,
> unsigned intuDMAIdx,
> void *psEthHeader,
> - unsigned short wCurrentRate
> + unsigned short current_rate
> );
>
> static unsigned int
> @@ -136,7 +136,7 @@ s_uFillDataHead(
> unsigned int cbLastFragmentSize,
> unsigned int uMACfragNum,
> unsigned char byFBOption,
> - unsigned short wCurrentRate,
> + unsigned short current_rate,
> bool is_pspoll
> );
>
> @@ -197,7 +197,7 @@ s_uGetRTSCTSRsvTime(
> unsigned char byRTSRsvType,
> unsigned char byPktType,
> unsigned int cbFrameLength,
> - unsigned short wCurrentRate
> + unsigned short current_rate
> )
> {
> unsigned int uRrvTime = 0;
> @@ -206,7 +206,7 @@ s_uGetRTSCTSRsvTime(
> unsigned int uAckTime = 0;
> unsigned int uDataTime = 0;
>
> - uDataTime = bb_get_frame_time(pDevice->byPreambleType, byPktType,
> cbFrameLength, wCurrentRate);
> + uDataTime = bb_get_frame_time(pDevice->byPreambleType, byPktType,
> cbFrameLength, current_rate);
> if (byRTSRsvType == 0) { /* RTSTxRrvTime_bb */
> uRTSTime = bb_get_frame_time(pDevice->byPreambleType,
> byPktType, 20, pDevice->byTopCCKBasicRate);
> uAckTime = bb_get_frame_time(pDevice->byPreambleType,
> byPktType, 14, pDevice->byTopCCKBasicRate);
> @@ -440,7 +440,7 @@ s_uFillDataHead(
> unsigned int cbLastFragmentSize,
> unsigned int uMACfragNum,
> unsigned char byFBOption,
> - unsigned short wCurrentRate,
> + unsigned short current_rate,
> bool is_pspoll
> )
> {
> @@ -451,7 +451,7 @@ s_uFillDataHead(
> if (byFBOption == AUTO_FB_NONE) {
> struct vnt_tx_datahead_g *buf = pTxDataHead;
> /* Get SignalField, ServiceField & Length
Re: [PATCH 4.4 2/2] binder: use cred instead of task for selinux checks
On Fri, Nov 12, 2021 at 05:11:38PM +0100, Greg KH wrote:
> On Wed, Nov 10, 2021 at 02:59:10PM -0800, Todd Kjos wrote:
> > commit 52f88693378a58094c538662ba652aff0253c4fe upstream.
> >
> > Since binder was integrated with selinux, it has passed
> > 'struct task_struct' associated with the binder_proc
> > to represent the source and target of transactions.
> > The conversion of task to SID was then done in the hook
> > implementations. It turns out that there are race conditions
> > which can result in an incorrect security context being used.
> >
> > Fix by using the 'struct cred' saved during binder_open and pass
> > it to the selinux subsystem.
> >
> > Cc: sta...@vger.kernel.org # 5.14 (need backport for earlier stables)
> > Fixes: 79af73079d75 ("Add security hooks to binder and implement the hooks
> > for SELinux.")
> > Suggested-by: Jann Horn
> > Signed-off-by: Todd Kjos
> > Acked-by: Casey Schaufler
> > Signed-off-by: Paul Moore
> > Change-Id: Id7157515d2b08f11683aeb8ad9b8f1da075d34e7
> > ---
> > drivers/android/binder.c | 18 +-
> > include/linux/lsm_hooks.h | 32
> > include/linux/security.h | 28 ++--
> > security/security.c | 14 +++---
> > security/selinux/hooks.c | 31 +--
> > 5 files changed, 59 insertions(+), 64 deletions(-)
>
> This doesn't apply at all. I've applied patch 1/2 here, but can you
> redo this one and submit it again?
Ugh, nope, my fault, sorry, this worked just fine.
It's been a long day...
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4.4 2/2] binder: use cred instead of task for selinux checks
On Wed, Nov 10, 2021 at 02:59:10PM -0800, Todd Kjos wrote:
> commit 52f88693378a58094c538662ba652aff0253c4fe upstream.
>
> Since binder was integrated with selinux, it has passed
> 'struct task_struct' associated with the binder_proc
> to represent the source and target of transactions.
> The conversion of task to SID was then done in the hook
> implementations. It turns out that there are race conditions
> which can result in an incorrect security context being used.
>
> Fix by using the 'struct cred' saved during binder_open and pass
> it to the selinux subsystem.
>
> Cc: sta...@vger.kernel.org # 5.14 (need backport for earlier stables)
> Fixes: 79af73079d75 ("Add security hooks to binder and implement the hooks
> for SELinux.")
> Suggested-by: Jann Horn
> Signed-off-by: Todd Kjos
> Acked-by: Casey Schaufler
> Signed-off-by: Paul Moore
> Change-Id: Id7157515d2b08f11683aeb8ad9b8f1da075d34e7
> ---
> drivers/android/binder.c | 18 +-
> include/linux/lsm_hooks.h | 32
> include/linux/security.h | 28 ++--
> security/security.c | 14 +++---
> security/selinux/hooks.c | 31 +--
> 5 files changed, 59 insertions(+), 64 deletions(-)
This doesn't apply at all. I've applied patch 1/2 here, but can you
redo this one and submit it again?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: Remove redundant indentation
On Tue, Nov 02, 2021 at 04:12:59PM +0800, hoshinomorimor...@gmail.com wrote: > From: Hoshinomori-Owari > > Remove redundant indentation in > drivers/staging/rtl8723bs/core/rtw_ap.c:1139. > Issue found by checkpatch.pl > > Signed-off-by: Hoshinomori-Owari > --- > drivers/staging/rtl8723bs/core/rtw_ap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/rtl8723bs/core/rtw_ap.c > b/drivers/staging/rtl8723bs/core/rtw_ap.c > index a76e81330756..4345dca1b552 100644 > --- a/drivers/staging/rtl8723bs/core/rtw_ap.c > +++ b/drivers/staging/rtl8723bs/core/rtw_ap.c > @@ -1137,7 +1137,7 @@ int rtw_check_beacon_data(struct adapter *padapter, u8 > *pbuf, int len) > } > > if ((p == NULL) || (ie_len == 0)) > - break; > + break; > } > > /* wmm */ > -- > 2.31.1 This does not apply to my tree (or Linus's tree) at all. Always make sure you work against linux-next so you do not duplicate other people's work that has already been done. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: comedi: Cleaned a bit of code that was not required
On Wed, Oct 27, 2021 at 03:32:34PM -0400, vaatsalya shrivastava wrote:
> Warning found by checkpatch.pl script.
Please be specific as to what you did.
>
> Signed-off-by: vaatsalya shrivastava
"V" and "S"?
> ---
> drivers/comedi/drivers/dt2815.c| 2 +-
> drivers/staging/vme/devices/vme_user.h | 8
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/comedi/drivers/dt2815.c b/drivers/comedi/drivers/dt2815.c
> index 5906f32aa01f..2be240630bbd 100644
> --- a/drivers/comedi/drivers/dt2815.c
> +++ b/drivers/comedi/drivers/dt2815.c
> @@ -17,7 +17,7 @@
> * contrary, please update.
> *
> * Configuration options:
> - * [0] - I/O port base base address
> + * [0] - I/O port base address
The original is correct.
> * [1] - IRQ (unused)
> * [2] - Voltage unipolar/bipolar configuration
> * 0 == unipolar 5V (0V -- +5V)
> diff --git a/drivers/staging/vme/devices/vme_user.h
> b/drivers/staging/vme/devices/vme_user.h
> index 19ecb05781cc..3c1564fd9b20 100644
> --- a/drivers/staging/vme/devices/vme_user.h
> +++ b/drivers/staging/vme/devices/vme_user.h
This is not a comedi driver.
> @@ -14,11 +14,11 @@ struct vme_master {
> __u32 aspace; /* Address Space */
> __u32 cycle;/* Cycle properties */
> __u32 dwidth; /* Maximum Data Width */
> -#if 0
> +
You can not just remove these lines, please realize what you are doing.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] binder: use cred instead of task for selinux checks
On Tue, Oct 05, 2021 at 09:53:31AM -0400, Paul Moore wrote:
> On Tue, Oct 5, 2021 at 9:31 AM Greg KH wrote:
> > On Fri, Oct 01, 2021 at 10:55:21AM -0700, Todd Kjos wrote:
> > > Save the struct cred associated with a binder process
> > > at initial open to avoid potential race conditions
> > > when converting to a security ID.
> > >
> > > Since binder was integrated with selinux, it has passed
> > > 'struct task_struct' associated with the binder_proc
> > > to represent the source and target of transactions.
> > > The conversion of task to SID was then done in the hook
> > > implementations. It turns out that there are race conditions
> > > which can result in an incorrect security context being used.
> > >
> > > Fix by saving the 'struct cred' during binder_open and pass
> > > it to the selinux subsystem.
> > >
> > > Fixes: 79af73079d75 ("Add security hooks to binder and implement the
> > > hooks for SELinux.")
> > > Signed-off-by: Todd Kjos
> > > Cc: sta...@vger.kernel.org # 5.14+ (need backport for earlier stables)
> > > ---
> > > v2: updated comments as suggested by Paul Moore
> > >
> > > drivers/android/binder.c | 14 +
> > > drivers/android/binder_internal.h | 4 +++
> > > include/linux/lsm_hook_defs.h | 14 -
> > > include/linux/lsm_hooks.h | 14 -
> > > include/linux/security.h | 28 +-
> > > security/security.c | 14 -
> > > security/selinux/hooks.c | 48 +--
> > > 7 files changed, 60 insertions(+), 76 deletions(-)
> >
> > Ideally I could get an ack from the security developers before taking
> > this in my tree...
>
> This should probably go in via one of the security trees, e.g. SELinux
> or LSM, rather than the binder/driver tree.
Fine with me, take it away!
Acked-by: Greg Kroah-Hartman
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] binder: use cred instead of task for selinux checks
On Fri, Oct 01, 2021 at 10:55:21AM -0700, Todd Kjos wrote:
> Save the struct cred associated with a binder process
> at initial open to avoid potential race conditions
> when converting to a security ID.
>
> Since binder was integrated with selinux, it has passed
> 'struct task_struct' associated with the binder_proc
> to represent the source and target of transactions.
> The conversion of task to SID was then done in the hook
> implementations. It turns out that there are race conditions
> which can result in an incorrect security context being used.
>
> Fix by saving the 'struct cred' during binder_open and pass
> it to the selinux subsystem.
>
> Fixes: 79af73079d75 ("Add security hooks to binder and implement the
> hooks for SELinux.")
> Signed-off-by: Todd Kjos
> Cc: sta...@vger.kernel.org # 5.14+ (need backport for earlier stables)
> ---
> v2: updated comments as suggested by Paul Moore
>
> drivers/android/binder.c | 14 +
> drivers/android/binder_internal.h | 4 +++
> include/linux/lsm_hook_defs.h | 14 -
> include/linux/lsm_hooks.h | 14 -
> include/linux/security.h | 28 +-
> security/security.c | 14 -
> security/selinux/hooks.c | 48 +--
> 7 files changed, 60 insertions(+), 76 deletions(-)
Ideally I could get an ack from the security developers before taking
this in my tree...
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 4.9] staging: android: ion: fix page is NULL
On Thu, Sep 23, 2021 at 10:18:14PM +0800, Cheng Chao wrote:
> Fixes: commit e7f63771b60e ("ION: Sys_heap: Add cached pool to spead up
> cached buffer alloc")
> the commit e7f63771b60e introduced the bug which didn't test page which maybe
> NULL.
> and previous logic was right.
>
> the e7f63771b60e has been merged in v4.8-rc3, only longterm 4.9.x has this
> bug,
> and other longterm/stable version have not.
thanks for this, now queued up.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [PATCH 4.9] staging: android: ion: fix page is NULL
On Wed, Sep 22, 2021 at 08:17:15PM +0800, Cheng Chao wrote: > I notice that v4.9.283 has released, but this patch is not merged. > It's exactly a bug. Can you please resend this and include all of the information in this thread in the changelog comment explaining why this is only needed for this one branch? Trying to piece it all together on my own doesn't work well :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] binder: make sure fd closes complete
On Fri, Sep 03, 2021 at 12:38:26PM -0700, Todd Kjos wrote:
> On Fri, Sep 3, 2021 at 1:06 AM Dan Carpenter wrote:
> >
> > On Thu, Sep 02, 2021 at 08:35:35AM -0700, Todd Kjos wrote:
> > > On Tue, Aug 31, 2021 at 12:24 AM Martijn Coenen wrote:
> > > >
> > > > On Mon, Aug 30, 2021 at 9:51 PM 'Todd Kjos' via kernel-team
> > > > wrote:
> > > > >
> > > > > During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object
> > > > > cleanup may close 1 or more fds. The close operations are
> > > > > completed using the task work mechanism -- which means the thread
> > > > > needs to return to userspace or the file object may never be
> > > > > dereferenced -- which can lead to hung processes.
> > > > >
> > > > > Force the binder thread back to userspace if an fd is closed during
> > > > > BC_FREE_BUFFER handling.
> > > > >
> > > > > Signed-off-by: Todd Kjos
> > > > Reviewed-by: Martijn Coenen
> > >
> > > Please also add to stable releases 5.4 and later.
> >
> > It would be better if this had a fixes tag so we knew which is the first
> > buggy commit.
> >
> > There was a long Project Zero article about the Bad Binder exploit
> > because commit f5cb779ba163 ("ANDROID: binder: remove waitqueue when
> > thread exits.") was marked as # 4.14 but it didn't have a Fixes tag and
> > the actual buggy commit was in 4.9.
>
> Good point Dan. I should have included a Fixes tag. Here is the tag
> (issue introduced in 4.20):
>
> Fixes: 80cd795630d6 ("binder: fix use-after-free due to ksys_close()
> during fdget()")
>
> Greg- would you like me to send a v2 with the Fixes tag and CC'ing
> stable appropriately?
I've added it to the commit when I added it to my tree, no need to
resend.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] [PATCH 4.9] staging: android: ion: fix page is NULL
On Sat, Sep 11, 2021 at 07:21:15PM +0800, Cheng Chao wrote: > kernel panic is here: > > Unable to handle kernel paging request at virtual address b038 > pgd = d9d94000 > [b038] *pgd= > Internal error: Oops: 2805 [#1] PREEMPT SMP ARM > ... > task: daa2dd00 task.stack: da194000 > PC is at v7_dma_clean_range+0x1c/0x34 > LR is at arm_dma_sync_single_for_device+0x44/0x58 > pc : []lr : []psr: 200f0013 > sp : da195da0 ip : dc1f9000 fp : c1043dc4 > r10: r9 : c16f1f58 r8 : 0001 > r7 : c1621f94 r6 : c0116418 r5 : r4 : c011aa58 > r3 : 003f r2 : 0040 r1 : b048 r0 : b038 > Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > Control: 10c5383d Table: 19d9406a DAC: 0051 > ... > [] (v7_dma_clean_range) from [] > (arm_dma_sync_single_for_device+0x44/0x58) > [] (arm_dma_sync_single_for_device) from [] > (arm_dma_sync_sg_for_device+0x50/0x7c) > [] (arm_dma_sync_sg_for_device) from [] > (ion_pages_sync_for_device+0xb0/0xec) > [] (ion_pages_sync_for_device) from [] > (ion_system_heap_allocate+0x2a0/0x2e0) > [] (ion_system_heap_allocate) from [] > (ion_alloc+0x12c/0x494) > [] (ion_alloc) from [] (ion_ioctl+0x510/0x63c) > [] (ion_ioctl) from [] (do_vfs_ioctl+0xa8/0x9b4) > [] (do_vfs_ioctl) from [] (SyS_ioctl+0x6c/0x7c) > [] (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x48) > Code: e3a02004 e1a02312 e2423001 e1c3 (ee070f3a) > ---[ end trace 89278304932c0e87 ]--- > Kernel panic - not syncing: Fatal exception > > Signed-off-by: Cheng Chao > --- > drivers/staging/android/ion/ion_system_heap.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/android/ion/ion_system_heap.c > b/drivers/staging/android/ion/ion_system_heap.c > index 22c481f2ae4f..2a35b99cf628 100644 > --- a/drivers/staging/android/ion/ion_system_heap.c > +++ b/drivers/staging/android/ion/ion_system_heap.c > @@ -75,7 +75,7 @@ static struct page *alloc_buffer_page(struct > ion_system_heap *heap, > > page = ion_page_pool_alloc(pool); > > - if (cached) > + if (page && cached) > ion_pages_sync_for_device(NULL, page, PAGE_SIZE << order, > DMA_BIDIRECTIONAL); > return page; > -- > 2.26.3 > Why is this just a 4.9 patch? Ion didn't get removed until 5.11, so wouldn't this be an issue for anything 5.10 and older? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/1] binder: fix freeze race
On Thu, Sep 09, 2021 at 11:17:42PM -0700, Li Li wrote:
> On Thu, Sep 9, 2021 at 10:38 PM Greg KH wrote:
> >
> > On Thu, Sep 09, 2021 at 08:53:16PM -0700, Li Li wrote:
> > > struct binder_frozen_status_info {
> > > __u32pid;
> > > +
> > > + /* process received sync transactions since last frozen
> > > + * bit 0: received sync transaction after being frozen
> > > + * bit 1: new pending sync transaction during freezing
> > > + */
> > > __u32sync_recv;
> >
> > You just changed a user/kernel api here, did you just break existing
> > userspace applications? If not, how did that not happen?
> >
>
> That's a good question. This design does keep backward compatibility.
>
> The existing userspace applications call ioctl(BINDER_GET_FROZEN_INFO)
> to check if there's sync or async binder transactions sent to a frozen
> process.
>
> If the existing userspace app runs on a new kernel, a sync binder call
> still sets bit 1 of sync_recv (as it's a bool variable) so the ioctl
> will return the expected value (TRUE). The app just doesn't check bit
> 1 intentionally so it doesn't have the ability to tell if there's a
> race - this behavior is aligned with what happens on an old kernel as
> the old kernel doesn't have bit 1 set at all.
>
> The bit 1 of sync_recv enables new userspace app the ability to tell
> 1) there's a sync binder transaction happened when being frozen - same
> as before; and 2) if that sync binder transaction happens exactly when
> there's a race - a new information for rollback decision.
Ah, can you add that to the changelog text to make it more obvious?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/1] binder: fix freeze race
On Thu, Sep 09, 2021 at 08:53:16PM -0700, Li Li wrote:
> From: Li Li
>
> Currently cgroup freezer is used to freeze the application threads, and
> BINDER_FREEZE is used to freeze the corresponding binder interface.
> There's already a mechanism in ioctl(BINDER_FREEZE) to wait for any
> existing transactions to drain out before actually freezing the binder
> interface.
>
> But freezing an app requires 2 steps, freezing the binder interface with
> ioctl(BINDER_FREEZE) and then freezing the application main threads with
> cgroupfs. This is not an atomic operation. The following race issue
> might happen.
>
> 1) Binder interface is frozen by ioctl(BINDER_FREEZE);
> 2) Main thread A initiates a new sync binder transaction to process B;
> 3) Main thread A is frozen by "echo 1 > cgroup.freeze";
> 4) The response from process B reaches the frozen thread, which will
> unexpectedly fail.
>
> This patch provides a mechanism to check if there's any new pending
> transaction happening between ioctl(BINDER_FREEZE) and freezing the
> main thread. If there's any, the main thread freezing operation can
> be rolled back to finish the pending transaction.
>
> Furthermore, the response might reach the binder driver before the
> rollback actually happens. That will still cause failed transaction.
>
> As the other process doesn't wait for another response of the response,
> the response transaction failure can be fixed by treating the response
> transaction like an oneway/async one, allowing it to reach the frozen
> thread. And it will be consumed when the thread gets unfrozen later.
>
> Fixes: 432ff1e91694 ("binder: BINDER_FREEZE ioctl")
> Signed-off-by: Li Li
> ---
> drivers/android/binder.c| 34 +
> drivers/android/binder_internal.h | 2 ++
> include/uapi/linux/android/binder.h | 7 ++
> 3 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index d9030cb6b1e4..eaffdf5f692c 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -3038,9 +3038,8 @@ static void binder_transaction(struct binder_proc *proc,
> if (reply) {
> binder_enqueue_thread_work(thread, tcomplete);
> binder_inner_proc_lock(target_proc);
> - if (target_thread->is_dead || target_proc->is_frozen) {
> - return_error = target_thread->is_dead ?
> - BR_DEAD_REPLY : BR_FROZEN_REPLY;
> + if (target_thread->is_dead) {
> + return_error = BR_DEAD_REPLY;
> binder_inner_proc_unlock(target_proc);
> goto err_dead_proc_or_thread;
> }
> @@ -4648,6 +4647,22 @@ static int binder_ioctl_get_node_debug_info(struct
> binder_proc *proc,
> return 0;
> }
>
> +static int binder_txns_pending_ilocked(struct binder_proc *proc)
> +{
> + struct rb_node *n;
> + struct binder_thread *thread;
> +
> + if (proc->outstanding_txns > 0)
> + return 1;
> +
> + for (n = rb_first(&proc->threads); n; n = rb_next(n)) {
> + thread = rb_entry(n, struct binder_thread, rb_node);
> + if (thread->transaction_stack)
> + return 1;
> + }
> + return 0;
> +}
> +
> static int binder_ioctl_freeze(struct binder_freeze_info *info,
> struct binder_proc *target_proc)
> {
> @@ -4682,6 +4697,14 @@ static int binder_ioctl_freeze(struct
> binder_freeze_info *info,
> if (!ret && target_proc->outstanding_txns)
> ret = -EAGAIN;
>
> + /* Also check pending transactions that wait for reply */
> + if (ret >= 0) {
> + binder_inner_proc_lock(target_proc);
> + if (binder_txns_pending_ilocked(target_proc))
> + ret = -EAGAIN;
> + binder_inner_proc_unlock(target_proc);
> + }
> +
> if (ret < 0) {
> binder_inner_proc_lock(target_proc);
> target_proc->is_frozen = false;
> @@ -4696,6 +4719,7 @@ static int binder_ioctl_get_freezer_info(
> {
> struct binder_proc *target_proc;
> bool found = false;
> + int txns_pending;
>
> info->sync_recv = 0;
> info->async_recv = 0;
> @@ -4705,7 +4729,9 @@ static int binder_ioctl_get_freezer_info(
> if (target_proc->pid == info->pid) {
> found = true;
> binder_inner_proc_lock(target_proc);
> - info->sync_recv |= target_proc->sync_recv;
> + txns_pending = binder_txns_pending_ilocked(target_proc);
> + info->sync_recv |= target_proc->sync_recv |
> + (txns_pending << 1);
> info->async_recv |= target_proc->async_recv;
> binder_inner_proc_unlock(target_proc);
> }
> diff --git a/drivers/android/binder_internal
Re: [PATCH] binder: make sure fd closes complete
On Thu, Sep 02, 2021 at 08:35:35AM -0700, Todd Kjos wrote: > On Tue, Aug 31, 2021 at 12:24 AM Martijn Coenen wrote: > > > > On Mon, Aug 30, 2021 at 9:51 PM 'Todd Kjos' via kernel-team > > wrote: > > > > > > During BC_FREE_BUFFER processing, the BINDER_TYPE_FDA object > > > cleanup may close 1 or more fds. The close operations are > > > completed using the task work mechanism -- which means the thread > > > needs to return to userspace or the file object may never be > > > dereferenced -- which can lead to hung processes. > > > > > > Force the binder thread back to userspace if an fd is closed during > > > BC_FREE_BUFFER handling. > > > > > > Signed-off-by: Todd Kjos > > Reviewed-by: Martijn Coenen > > Please also add to stable releases 5.4 and later. I'll try to remember to tag this as-such after 5.15-rc1 is out and I can apply it to my tree. But in the future, it's best if you add the cc: stable to the patch yourself so I don't have to do it "by hand" after the fact. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging/ks7010: Fix coding style problems [Version 2]
On Mon, Aug 16, 2021 at 08:04:47PM +0200, Leon Krieg wrote:
> By doing some last-second wording changes directly in the diff I've
> screwed up and managed to use spaces instead of tabs for the Kconfig file.
> This is embarrassing!
>
> Signed-off-by: Leon Krieg
> ---
> drivers/staging/ks7010/Kconfig | 7 ---
> drivers/staging/ks7010/ks_hostif.c | 2 +-
> drivers/staging/ks7010/ks_wlan_net.c | 20 ++--
> 3 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/staging/ks7010/Kconfig b/drivers/staging/ks7010/Kconfig
> index 0987fdc2f70d..4bc17e50ac89 100644
> --- a/drivers/staging/ks7010/Kconfig
> +++ b/drivers/staging/ks7010/Kconfig
> @@ -6,6 +6,7 @@ config KS7010
> select WEXT_PRIV
> select FW_LOADER
> help
> - This is a driver for KeyStream KS7010 based SDIO WIFI cards. It is
> - found on at least later Spectec SDW-821 (FCC-ID "S2Y-WLAN-11G-K" only,
> - sadly not FCC-ID "S2Y-WLAN-11B-G") and Spectec SDW-823 microSD cards.
> + Selecting this option enables the driver for KeyStream KS7010 SDIO
> + hardware found in at least Spectec SDW-821 and SDW-823 microSD cards
> + (FCC-ID "S2Y-WLAN-11G-K" but not FCC-ID "S2Y-WLAN-11B-G" and Spectec
> + SDW-823).
>
> diff --git a/drivers/staging/ks7010/ks_hostif.c
> b/drivers/staging/ks7010/ks_hostif.c
> index eaa70893224a..d2f9d0ed62c1 100644
> --- a/drivers/staging/ks7010/ks_hostif.c
> +++ b/drivers/staging/ks7010/ks_hostif.c
> @@ -134,7 +134,7 @@ int get_current_ap(struct ks_wlan_private *priv, struct
> link_ap_info *ap_info)
> size = (ap_info->rsn.size <= RSN_IE_BODY_MAX) ?
> ap_info->rsn.size : RSN_IE_BODY_MAX;
> if ((ap_info->rsn_mode & RSN_MODE_WPA2) &&
> - (priv->wpa.version == IW_AUTH_WPA_VERSION_WPA2)) {
> + priv->wpa.version == IW_AUTH_WPA_VERSION_WPA2) {
> ap->rsn_ie.id = RSN_INFO_ELEM_ID;
> ap->rsn_ie.size = size;
> memcpy(ap->rsn_ie.body, ap_info->rsn.body, size);
> diff --git a/drivers/staging/ks7010/ks_wlan_net.c
> b/drivers/staging/ks7010/ks_wlan_net.c
> index 09e7b4cd0138..33abb6a7dbe0 100644
> --- a/drivers/staging/ks7010/ks_wlan_net.c
> +++ b/drivers/staging/ks7010/ks_wlan_net.c
> @@ -181,26 +181,26 @@ static int ks_wlan_set_freq(struct net_device *dev,
>
> /* for SLEEP MODE */
> /* If setting by frequency, convert to a channel */
> - if ((fwrq->freq.e == 1) &&
> - (fwrq->freq.m >= 24120) && (fwrq->freq.m <= 24870)) {
> + if (fwrq->freq.e == 1 &&
> + fwrq->freq.m >= 24120 && fwrq->freq.m <= 24870) {
> int f = fwrq->freq.m / 10;
> int c = 0;
>
> while ((c < 14) && (f != frequency_list[c]))
> c++;
> - /* Hack to fall through... */
> + fallthrough;
> fwrq->freq.e = 0;
> fwrq->freq.m = c + 1;
> }
> /* Setting by channel number */
> - if ((fwrq->freq.m > 1000) || (fwrq->freq.e > 0))
> + if (fwrq->freq.m > 1000 || fwrq->freq.e > 0)
> return -EOPNOTSUPP;
>
> channel = fwrq->freq.m;
> /* We should do a better check than that,
>* based on the card capability !!!
>*/
> - if ((channel < 1) || (channel > 14)) {
> + if (channel < 1 || channel > 14) {
> netdev_dbg(dev, "%s: New channel value of %d is invalid!\n",
> dev->name, fwrq->freq.m);
> return -EINVAL;
> @@ -664,7 +664,7 @@ static int ks_wlan_set_rts(struct net_device *dev, struct
> iw_request_info *info,
> /* for SLEEP MODE */
> if (vwrq->rts.disabled)
> rthr = 2347;
> - if ((rthr < 0) || (rthr > 2347))
> + if (rthr < 0 || rthr > 2347)
> return -EINVAL;
>
> priv->reg.rts = rthr;
> @@ -702,7 +702,7 @@ static int ks_wlan_set_frag(struct net_device *dev,
> /* for SLEEP MODE */
> if (vwrq->frag.disabled)
> fthr = 2346;
> - if ((fthr < 256) || (fthr > 2346))
> + if (fthr < 256 || fthr > 2346)
> return -EINVAL;
>
> fthr &= ~0x1; /* Get an even value - is it really needed ??? */
> @@ -781,7 +781,7 @@ static int ks_wlan_set_encode(struct net_device *dev,
> return -EINVAL;
>
> /* for SLEEP MODE */
> - if ((index < 0) || (index > 4))
> + if (index < 0 || index > 4)
> return -EINVAL;
>
> index = (index == 0) ? priv->reg.wep_index : (index - 1);
> @@ -882,7 +882,7 @@ static int ks_wlan_get_encode(struct net_device *dev,
> }
>
> /* Which key do we want ? -1 -> tx index */
> - if ((index < 0) || (index >= 4))
> + if (index < 0 || index >= 4)
> index = priv->reg.wep_index;
> if (priv->reg.privacy_invoked) {
> enc->flags &= ~IW_ENCODE_DISABLED;
> @@ -1860,7 +1860,7 @@ static int ks_wlan_set_power_mgmt(struct net_
Re: [PATCH] staging/ks7010: Fix coding style problems
On Mon, Aug 16, 2021 at 07:55:03PM +0200, Leon Krieg wrote:
> Sorry to bother you with this low-effort patch but I'd really like to get
> my feet in the water and this whole process is making me nervous. I'd
> really appreciate you taking the time to look over this diff and
> hopefully I did not screw up to badly.
>
> Signed-off-by: Leon Krieg
> ---
> drivers/staging/ks7010/Kconfig | 7 ---
> drivers/staging/ks7010/ks_hostif.c | 2 +-
> drivers/staging/ks7010/ks_wlan_net.c | 20 ++--
> 3 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/staging/ks7010/Kconfig b/drivers/staging/ks7010/Kconfig
> index 0987fdc2f70d..4bc17e50ac89 100644
> --- a/drivers/staging/ks7010/Kconfig
> +++ b/drivers/staging/ks7010/Kconfig
> @@ -6,6 +6,7 @@ config KS7010
> select WEXT_PRIV
> select FW_LOADER
> help
> - This is a driver for KeyStream KS7010 based SDIO WIFI cards. It is
> - found on at least later Spectec SDW-821 (FCC-ID "S2Y-WLAN-11G-K" only,
> - sadly not FCC-ID "S2Y-WLAN-11B-G") and Spectec SDW-823 microSD cards.
> + Selecting this option enables the driver for KeyStream KS7010 SDIO
> + hardware found in at least Spectec SDW-821 and SDW-823 microSD cards
> + (FCC-ID "S2Y-WLAN-11G-K" but not FCC-ID "S2Y-WLAN-11B-G" and Spectec
> + SDW-823).
>
> diff --git a/drivers/staging/ks7010/ks_hostif.c
> b/drivers/staging/ks7010/ks_hostif.c
> index eaa70893224a..d2f9d0ed62c1 100644
> --- a/drivers/staging/ks7010/ks_hostif.c
> +++ b/drivers/staging/ks7010/ks_hostif.c
> @@ -134,7 +134,7 @@ int get_current_ap(struct ks_wlan_private *priv, struct
> link_ap_info *ap_info)
> size = (ap_info->rsn.size <= RSN_IE_BODY_MAX) ?
> ap_info->rsn.size : RSN_IE_BODY_MAX;
> if ((ap_info->rsn_mode & RSN_MODE_WPA2) &&
> - (priv->wpa.version == IW_AUTH_WPA_VERSION_WPA2)) {
> + priv->wpa.version == IW_AUTH_WPA_VERSION_WPA2) {
> ap->rsn_ie.id = RSN_INFO_ELEM_ID;
> ap->rsn_ie.size = size;
> memcpy(ap->rsn_ie.body, ap_info->rsn.body, size);
> diff --git a/drivers/staging/ks7010/ks_wlan_net.c
> b/drivers/staging/ks7010/ks_wlan_net.c
> index 09e7b4cd0138..33abb6a7dbe0 100644
> --- a/drivers/staging/ks7010/ks_wlan_net.c
> +++ b/drivers/staging/ks7010/ks_wlan_net.c
> @@ -181,26 +181,26 @@ static int ks_wlan_set_freq(struct net_device *dev,
>
> /* for SLEEP MODE */
> /* If setting by frequency, convert to a channel */
> - if ((fwrq->freq.e == 1) &&
> - (fwrq->freq.m >= 24120) && (fwrq->freq.m <= 24870)) {
> + if (fwrq->freq.e == 1 &&
> + fwrq->freq.m >= 24120 && fwrq->freq.m <= 24870) {
> int f = fwrq->freq.m / 10;
> int c = 0;
>
> while ((c < 14) && (f != frequency_list[c]))
> c++;
> - /* Hack to fall through... */
> + fallthrough;
> fwrq->freq.e = 0;
> fwrq->freq.m = c + 1;
> }
> /* Setting by channel number */
> - if ((fwrq->freq.m > 1000) || (fwrq->freq.e > 0))
> + if (fwrq->freq.m > 1000 || fwrq->freq.e > 0)
> return -EOPNOTSUPP;
>
> channel = fwrq->freq.m;
> /* We should do a better check than that,
>* based on the card capability !!!
>*/
> - if ((channel < 1) || (channel > 14)) {
> + if (channel < 1 || channel > 14) {
> netdev_dbg(dev, "%s: New channel value of %d is invalid!\n",
> dev->name, fwrq->freq.m);
> return -EINVAL;
> @@ -664,7 +664,7 @@ static int ks_wlan_set_rts(struct net_device *dev, struct
> iw_request_info *info,
> /* for SLEEP MODE */
> if (vwrq->rts.disabled)
> rthr = 2347;
> - if ((rthr < 0) || (rthr > 2347))
> + if (rthr < 0 || rthr > 2347)
> return -EINVAL;
>
> priv->reg.rts = rthr;
> @@ -702,7 +702,7 @@ static int ks_wlan_set_frag(struct net_device *dev,
> /* for SLEEP MODE */
> if (vwrq->frag.disabled)
> fthr = 2346;
> - if ((fthr < 256) || (fthr > 2346))
> + if (fthr < 256 || fthr > 2346)
> return -EINVAL;
>
> fthr &= ~0x1; /* Get an even value - is it really needed ??? */
> @@ -781,7 +781,7 @@ static int ks_wlan_set_encode(struct net_device *dev,
> return -EINVAL;
>
> /* for SLEEP MODE */
> - if ((index < 0) || (index > 4))
> + if (index < 0 || index > 4)
> return -EINVAL;
>
> index = (index == 0) ? priv->reg.wep_index : (index - 1);
> @@ -882,7 +882,7 @@ static int ks_wlan_get_encode(struct net_device *dev,
> }
>
> /* Which key do we want ? -1 -> tx index */
> - if ((index < 0) || (index >= 4))
> + if (index < 0 || index >= 4)
> index = priv->reg.wep_index;
> if (priv->reg.privacy_invoked) {
> enc->flags &= ~IW
[GIT PULL] Staging driver fixes for 5.14-rc5
The following changes since commit 2734d6c1b1a089fb593ef6a23d4b70903526fe0c: Linux 5.14-rc2 (2021-07-18 14:13:49 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git tags/staging-5.14-rc5 for you to fetch changes up to c7b65650c7f41d3946c4e2f0bb56dfdb92cfe127: staging: mt7621-pci: avoid to re-disable clock for those pcies not in use (2021-07-27 15:48:43 +0200) Staging driver fixes for 5.14-rc5 Here are a few small staging driver fixes for 5.14-rc5 to resolve some reported problems. They include: - mt7621 driver fix - rtl8723bs driver fixes - rtl8712 driver fixes. Nothing major, just small problems resolved. All have been in linux-next for a while with no reported issues. Signed-off-by: Greg Kroah-Hartman Arnd Bergmann (1): staging: rtl8723bs: select CONFIG_CRYPTO_LIB_ARC4 Pavel Skripkin (2): staging: rtl8712: get rid of flush_scheduled_work staging: rtl8712: error handling refactoring Sergio Paracuellos (1): staging: mt7621-pci: avoid to re-disable clock for those pcies not in use Xiangyang Zhang (1): staging: rtl8723bs: Fix a resource leak in sd_int_dpc drivers/staging/mt7621-pci/pci-mt7621.c | 1 - drivers/staging/rtl8712/hal_init.c| 30 -- drivers/staging/rtl8712/rtl8712_led.c | 8 + drivers/staging/rtl8712/rtl871x_led.h | 1 + drivers/staging/rtl8712/rtl871x_pwrctrl.c | 8 + drivers/staging/rtl8712/rtl871x_pwrctrl.h | 1 + drivers/staging/rtl8712/usb_intf.c| 51 ++- drivers/staging/rtl8723bs/Kconfig | 1 + drivers/staging/rtl8723bs/hal/sdio_ops.c | 2 ++ 9 files changed, 64 insertions(+), 39 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Drivers: comedi: Lindented files.
On Fri, Jul 23, 2021 at 12:09:27AM +0300, vpuh1 wrote: > Indented files in drivers/comedi directory using scripts/Lindent. > > Signed-off-by: Artem Baxtiarov Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch contains warnings and/or errors noticed by the scripts/checkpatch.pl tool. - Your patch did many different things all at once, making it difficult to review. All Linux kernel patches need to only do one thing at a time. If you need to do multiple things (such as clean up all coding style issues in a file/driver), do it in a sequence of patches, each one doing only one thing. This will make it easier to review the patches to ensure that they are correct, and to help alleviate any merge issues that larger patches can cause. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. - It looks like you did not use your "real" name for the patch on either the Signed-off-by: line, or the From: line (both of which have to match). Please read the kernel file, Documentation/SubmittingPatches for how to do this correctly. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging / IIO driver updates for 5.14-rc1
The following changes since commit 009c9aa5be652675a06d5211e1640e02bbb1c33d:
Linux 5.13-rc6 (2021-06-13 14:43:10 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
tags/staging-5.14-rc1
for you to fetch changes up to 77ad1f0e99bd00af024e650b862cfda3137af660:
staging: hi6421-spmi-pmic: cleanup some macros (2021-06-25 10:02:57 +0200)
Staging / IIO driver patches for 5.14-rc1
Here is the big set of IIO and staging driver patches for 5.14-rc1.
Loads of IIO driver updates and additions in here, the shortlog has the
full details.
For the staging side, we moved a few drivers out of staging, and deleted
the kpc2000 drivers as the original developer asked us to because no one
was working on them anymore.
Also in here are loads of coding style cleanups due to different intern
projects focusing on the staging tree to try to get experience doing
kernel development.
All of these have been in the linux-next tree for a while with no
reported problems.
Signed-off-by: Greg Kroah-Hartman
Alexander Vorwerk (1):
staging: rtl8712: remove multiple multiple assignments
Alexandru Ardelean (9):
iio: adc: ad_sigma_delta: introduct devm_ad_sd_setup_buffer_and_trigger()
iio: adc: ad7793: convert to device-managed functions
iio: adc: ad7791: convert to device-managed functions
iio: adc: ad7780: convert to device-managed functions
iio: adc: ad7192: use devm_clk_get_optional() for mclk
iio: adc: ad7192: convert to device-managed functions
iio: adc: ad_sigma_delta: remove
ad_sd_{setup,cleanup}_buffer_and_trigger()
iio: imu: remove unused private data assigned with spi_set_drvdata()
iio: adc: remove unused private data assigned with spi_set_drvdata()
Amos Gross (1):
Staging: rtl8188eu: rtw_ioctl_set.c: fixed indentation issue
Andy Shevchenko (15):
staging: fbtft: Rectify GPIO handling
staging: fbtft: Don't spam logs when probe is deferred
staging: fbtft: Add support for orientation on Himax HX8347d
staging: fbtft: Replace custom ->reset() with generic one
staging: fbtft: Update TODO
iio: adc: ad7298: Enable on Intel Galileo Gen 1
iio: accel: st_accel: Move platform data from header to C file
iio: gyro: st_gyro: Move platform data from header to C file
iio: magnetometer: st_magn: Provide default platform data
iio: st_sensors: Call st_sensors_power_enable() from bus drivers
iio: st_sensors: Make accel, gyro, magn and pressure probe shared
iio: st_sensors: Add lsm9ds0 IMU support
dt-bindings: iio: st,st-sensors: Add LSM9DS0 compatible string
iio: Drop Duplicated "mount-matrix" parameter
iio: hid-sensors: lighten exported symbols by moving to IIO_HID namespace
Arnd Bergmann (1):
iio: si1133: fix format string warnings
Ashish Kalra (1):
staging: wlan-ng: silence incorrect type in argument 1 (different address
spaces)
Ashish Vara (1):
staging: qlge: removed unnecessary debug message to fix coding style
warning
Bixuan Cui (1):
staging: comedi: Remove unused variable ‘min_full_scale’ and function
'get_min_full_scales'
Bryan Brattlof (11):
staging: rtl8723bs: remove unused argument 'msg'
staging: rtl8723bs: remove duplicate names for _rtw_read8()
staging: rtl8723bs: remove duplicate names for _rtw_read16()
staging: rtl8723bs: remove duplicate names for _rtw_read32()
staging: rtl8723bs: remove duplicate names for _rtw_write8()
staging: rtl8723bs: remove duplicate names for _rtw_write16()
staging: rtl8723bs: remove duplicate names for _rtw_write32()
staging: rtl8723bs: remove duplicate name for _rtw_write_port()
staging: rtl8723bs: remove _rtw_sd_f0_read8()
staging: rtl8723bs: remove if (true) statement
staging: rtl8723bs: remove sd_f0_read8()
Caleb D.S. Brzezinski (1):
staging: ks7010: Wrap macro definitions in parenthesis
Christophe JAILLET (5):
staging: rtl8712: Fix some tests against some 'data' subtype frames
staging: rtl8188eu: remove enum WIFI_FRAME_SUBTYPE
staging: rtl8723bs: Fix an error handling path
staging: rtl8188eu: remove "rtw_ieee80211_back_actioncode"
staging: rtl8188eu: remove "rtw_ieee80211_back_parties"
Chunyan Zhang (1):
iio: adc: Add missing MODULE_DEVICE_TABLE
Cláudio Maia (1):
staging: rtl8192u: Fix variable shadowing warning
Colin Ian King (4):
staging: wlan-ng: remove redundant initialization of variable txresult
staging: unisys: visorinput: remove redundant assignment of variable led
staging: gdm724x: emove redundant initialization of variable hci_len
staging: rts5208: remove redundant continue statement
Dan Carpenter (15):
iio: core: Fix an error pointer vs NULL bug in devm_iio_
[GIT PULL] Staging driver fixes for 5.13-rc6
The following changes since commit 8124c8a6b35386f73523d27eacb71b5364a68c4c: Linux 5.13-rc4 (2021-05-30 11:58:25 -1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git tags/staging-5.13-rc6 for you to fetch changes up to e9de1ecadeab5fbffd873b9110e969c869554a56: staging: ralink-gdma: Remove incorrect author information (2021-06-09 12:07:52 +0200) Staging driver fixes for 5.13-rc6 Here are two tiny staging driver fixes for 5.13-rc6 - ralink-gdma driver authorship information fixed up - rtl8723bs driver fix for reported regression Both have been in linux-next for a while with no reported problems. Signed-off-by: Greg Kroah-Hartman Lars-Peter Clausen (1): staging: ralink-gdma: Remove incorrect author information Wenli Looi (1): staging: rtl8723bs: Fix uninitialized variables drivers/staging/ralink-gdma/ralink-gdma.c | 2 -- drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 2 +- 2 files changed, 1 insertion(+), 3 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging/IIO driver fixes for 5.13-rc4
The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc: Linux 5.13-rc2 (2021-05-16 15:27:44 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git tags/staging-5.13-rc4 for you to fetch changes up to 54732a5322ff1fe0f42f2527fa6f5901a4de5111: Merge tag 'iio-fixes-5.13b-take2' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus (2021-05-22 09:49:59 +0200) Staging / IIO driver fixes for 5.13-rc4 Here are some small IIO and staging driver fixes for reported issues for 5.13-rc4. Nothing major here, tiny changes for reported problems, full details are in the shortlog if people are curious. All have been in linux-next for a while with no reported problems. Signed-off-by: Greg Kroah-Hartman Alexandru Ardelean (1): iio: adc: ad7192: handle regulator voltage error first Andy Shevchenko (1): iio: dac: ad5770r: Put fwnode in error case during ->probe() Dan Carpenter (1): staging: emxx_udc: fix loop in _nbu2ss_nuke() Greg Kroah-Hartman (1): Merge tag 'iio-fixes-5.13b-take2' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Jonathan Cameron (5): iio: adc: ad7124: Fix missbalanced regulator enable / disable on error. iio: adc: ad7124: Fix potential overflow due to non sequential channel numbers iio: adc: ad7192: Avoid disabling a clock that was never enabled. iio: adc: ad7768-1: Fix too small buffer passed to iio_push_to_buffers_with_timestamp() iio: adc: ad7923: Fix undersized rx buffer. Lucas Stankus (1): staging: iio: cdc: ad7746: avoid overwrite of num_channels Rui Miguel Silva (1): iio: gyro: fxas21002c: balance runtime power in error path YueHaibing (1): iio: adc: ad7793: Add missing error code in ad7793_setup() drivers/iio/adc/ad7124.c| 36 drivers/iio/adc/ad7192.c| 19 ++- drivers/iio/adc/ad7768-1.c | 8 ++-- drivers/iio/adc/ad7793.c| 1 + drivers/iio/adc/ad7923.c| 4 +++- drivers/iio/dac/ad5770r.c | 16 +++- drivers/iio/gyro/fxas21002c_core.c | 2 ++ drivers/staging/emxx_udc/emxx_udc.c | 4 ++-- drivers/staging/iio/cdc/ad7746.c| 1 - 9 files changed, 55 insertions(+), 36 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Fixed a coding style issue - missing a blank line after declarations
On Sat, May 22, 2021 at 08:49:50PM +0900, tco0427 wrote:
> ---
> drivers/staging/rtl8723bs/core/rtw_cmd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_cmd.c
> b/drivers/staging/rtl8723bs/core/rtw_cmd.c
> index e1a8f8b47edd..40d99644ddc7 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_cmd.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_cmd.c
> @@ -1337,6 +1337,7 @@ u8 traffic_status_watchdog(struct adapter *padapter, u8
> from_timer)
> static void dynamic_chk_wk_hdl(struct adapter *padapter)
> {
> struct mlme_priv *pmlmepriv;
> +
> pmlmepriv = &(padapter->mlmepriv);
>
> if (check_fwstate(pmlmepriv, WIFI_AP_STATE) == true)
> --
> 2.30.1 (Apple Git-130)
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- Your patch does not have a Signed-off-by: line. Please read the
kernel file, Documentation/SubmittingPatches and resend it after
adding that line. Note, the line needs to be in the body of the
email, before the patch, not at the bottom of the patch or in the
email signature.
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to
properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.
- It looks like you did not use your "real" name for the patch on either
the Signed-off-by: line, or the From: line (both of which have to
match). Please read the kernel file, Documentation/SubmittingPatches
for how to do this correctly.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/17] Add an experimental driver for Intel NUC leds
On Mon, May 17, 2021 at 11:02:58AM +0200, Mauro Carvalho Chehab wrote: > Em Mon, 17 May 2021 10:18:57 +0200 > Greg KH escreveu: > > > On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote: > > > Hi Greg, > > > > > > This series add support for the LEDs found at Intel NUCs since > > > NUC version 6. > > > > > > On several NUC models, the function of the LEDs are programmable, > > > which allow them to indicate several different hardware events. > > > > > > They can even be programmed to represent an userspace-driven event. > > > > > > Some models come with single colored or dual-colored LEDs, but > > > high end models have RGB LEDs. > > > > > > Programming them can ether be done via BIOS or by the OS. > > > > > > There are 3 different API types, and there is already some OOT > > > drivers that were written to support them, using procfs, each > > > one using a different (and IMO confusing) API. > > > > > > After looking at the existing drivers and not liking the uAPI > > > interfaces there, I opted to write a new driver from scratch, > > > unifying support for all different versions and using sysfs > > > via the leds class. > > > > Just do this the "right way" and not add it to staging first. Just use > > the existing LED class apis and all should be fine, no need for doing > > anything unusual here. > > I'm using the standard LED class already (but not triggers), and the > standard WMI support. > > Still, this API is complex, as it controls the LED behavior even when > the machine is suspended. I would feel more comfortable if the ABI > is not set into a stone at the beginning. code in drivers/staging/ does not mean that you can mess with the userspace api at will. It still follows the same "rules" of any other kernel code when it comes to that. So just work with the LED developers to come to a valid api that works properly within that framework please. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/17] staging: add support for NUC WMI LEDs
On Sun, May 16, 2021 at 12:53:29PM +0200, Mauro Carvalho Chehab wrote:
> Some Intel Next Unit of Computing (NUC) machines have
> software-configured LEDs that can be used to display a
> variety of events:
>
> - Power State
> - HDD Activity
> - Ethernet
> - WiFi
> - Power Limit
One nit:
> +static void nuc_wmi_remove(struct wmi_device *wdev)
> +{
> + struct device *dev = &wdev->dev;
> +
> + dev_info(dev, "NUC WMI driver removed.\n");
> +}
Drivers, when working properly, should be quiet. No need for noisy
stuff like this, it just slows down booting/loading for everyone.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/17] Add an experimental driver for Intel NUC leds
On Sun, May 16, 2021 at 12:53:28PM +0200, Mauro Carvalho Chehab wrote: > Hi Greg, > > This series add support for the LEDs found at Intel NUCs since > NUC version 6. > > On several NUC models, the function of the LEDs are programmable, > which allow them to indicate several different hardware events. > > They can even be programmed to represent an userspace-driven event. > > Some models come with single colored or dual-colored LEDs, but > high end models have RGB LEDs. > > Programming them can ether be done via BIOS or by the OS. > > There are 3 different API types, and there is already some OOT > drivers that were written to support them, using procfs, each > one using a different (and IMO confusing) API. > > After looking at the existing drivers and not liking the uAPI > interfaces there, I opted to write a new driver from scratch, > unifying support for all different versions and using sysfs > via the leds class. Just do this the "right way" and not add it to staging first. Just use the existing LED class apis and all should be fine, no need for doing anything unusual here. thanks,m greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging/IIO driver fixes for 5.13-rc2
The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5: Linux 5.13-rc1 (2021-05-09 14:17:44 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git tags/staging-5.13-rc2 for you to fetch changes up to ba9c25d94dea1a57492a606a1f5dde70d2432583: Merge tag 'iio-fixes-5.13a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus (2021-05-11 15:17:55 +0200) Staging/IIO driver fixes for 5.13-rc2 Here are some small IIO driver fixes and one Staging driver fix for 5.13-rc2. Nothing major, just some resolutions for reported problems: - gcc11 bogus warning fix for rtl8723bs - iio driver tiny fixes All of these have been in linux-next for many days with no reported issues. Signed-off-by: Greg Kroah-Hartman Alexandru Ardelean (2): iio: hid-sensors: select IIO_TRIGGERED_BUFFER under HID_SENSOR_IIO_TRIGGER iio: core: return ENODEV if ioctl is unknown Arnd Bergmann (1): staging: rtl8723bs: avoid bogus gcc warning Colin Ian King (1): iio: tsl2583: Fix division by a zero lux_val Dinghao Liu (2): iio: light: gp2ap002: Fix rumtime PM imbalance on error iio: proximity: pulsedlight: Fix rumtime PM imbalance on error Dmitry Osipenko (1): iio: gyro: mpu3050: Fix reported temperature value Greg Kroah-Hartman (1): Merge tag 'iio-fixes-5.13a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus Tomasz Duszynski (1): iio: core: fix ioctl handlers removal drivers/iio/accel/Kconfig | 1 - drivers/iio/common/hid-sensors/Kconfig| 1 + drivers/iio/gyro/Kconfig | 1 - drivers/iio/gyro/mpu3050-core.c | 13 +++-- drivers/iio/humidity/Kconfig | 1 - drivers/iio/industrialio-core.c | 9 + drivers/iio/light/Kconfig | 2 -- drivers/iio/light/gp2ap002.c | 5 +++-- drivers/iio/light/tsl2583.c | 8 drivers/iio/magnetometer/Kconfig | 1 - drivers/iio/orientation/Kconfig | 2 -- drivers/iio/pressure/Kconfig | 1 - drivers/iio/proximity/pulsedlight-lidar-lite-v2.c | 1 + drivers/iio/temperature/Kconfig | 1 - drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 23 +-- drivers/staging/rtl8723bs/os_dep/ioctl_linux.c| 21 - 16 files changed, 50 insertions(+), 41 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: fix array of flexible structures
On Wed, Apr 28, 2021 at 12:28:44AM +0530, Jitendra wrote:
> On Tue, Apr 27, 2021 at 08:10:20PM +0200, Greg KH wrote:
> > On Tue, Apr 27, 2021 at 11:19:45PM +0530, Jitendra Khasdev wrote:
> > > This patch fixes sparse warning "array of flexible structures"
> > > for rtllib.h.
> > >
> > > eg. drivers/staging/rtl8192e/rtllib.h:832:48: warning: array of
> > > flexible structures
> > >
> > > Signed-off-by: Jitendra Khasdev
> > > ---
> > > drivers/staging/rtl8192e/rtllib.h | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/staging/rtl8192e/rtllib.h
> > > b/drivers/staging/rtl8192e/rtllib.h
> > > index 4cabaf2..c7cb318 100644
> > > --- a/drivers/staging/rtl8192e/rtllib.h
> > > +++ b/drivers/staging/rtl8192e/rtllib.h
> > > @@ -802,7 +802,7 @@ struct rtllib_authentication {
> > > __le16 transaction;
> > > __le16 status;
> > > /*challenge*/
> > > - struct rtllib_info_element info_element[];
> > > + struct rtllib_info_element *info_element;
> >
> > You just changed the definition of this structure, and the other
> > structures here. Are you sure this is working properly?
> >
>
> I have compiled the driver and install it on my vm, but I don't this specific
> hardware, so couldn't test it.
>
> I fixed in context of sparse.
Please verify that this change is correct by looking at how the
structures are being created (i.e. is this being treated as a flexible
array or a pointer?)
I think we have been through this before and that sparse is not right,
but I can't remember...
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: fix array of flexible structures
On Tue, Apr 27, 2021 at 11:19:45PM +0530, Jitendra Khasdev wrote:
> This patch fixes sparse warning "array of flexible structures"
> for rtllib.h.
>
> eg. drivers/staging/rtl8192e/rtllib.h:832:48: warning: array of
> flexible structures
>
> Signed-off-by: Jitendra Khasdev
> ---
> drivers/staging/rtl8192e/rtllib.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/rtl8192e/rtllib.h
> b/drivers/staging/rtl8192e/rtllib.h
> index 4cabaf2..c7cb318 100644
> --- a/drivers/staging/rtl8192e/rtllib.h
> +++ b/drivers/staging/rtl8192e/rtllib.h
> @@ -802,7 +802,7 @@ struct rtllib_authentication {
> __le16 transaction;
> __le16 status;
> /*challenge*/
> - struct rtllib_info_element info_element[];
> + struct rtllib_info_element *info_element;
You just changed the definition of this structure, and the other
structures here. Are you sure this is working properly?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver updates for 5.13-rc1
On Mon, Apr 26, 2021 at 11:18:49AM -0700, Linus Torvalds wrote: > On Mon, Apr 26, 2021 at 8:11 AM Greg KH wrote: > > > > Yeah, merge issues with other trees are hard to resolve in the single > > tree here, not much I can just yet, have to wait for them to hit Linus's > > tree. > > It's generally a good idea to mention these things if you know about > them, just in case the other tree had come in in the meantime and I > had merged it first. > > That didn't happen this time, and I do generally catch these things > anyway as long as they at least trigger problems for my usual x86-64 > allmodconfig builds (but not everything does trigger that). Sorry, will mention it next time when I know it's going to happen with another tree like this. Thanks for pulling, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [GIT PULL] Staging/IIO driver updates for 5.13-rc1
On Tue, Apr 27, 2021 at 12:26:48AM +1000, Stephen Rothwell wrote: > Hi Greg, > > On Mon, 26 Apr 2021 14:46:10 +0200 Greg KH wrote: > > > > All of these have been in linux-next for a while with no reported > > issues. > > There was just these: > > https://lore.kernel.org/linux-next/20210329165525.32d51...@canb.auug.org.au/ > > https://lore.kernel.org/linux-next/20210331175151.67fcf...@canb.auug.org.au/ > > (the scmi tree commit mentioned in the latter is now in the arm-soc tree) > > Not issues as such, but worth mentioning the conflicts and resolutions. Yeah, merge issues with other trees are hard to resolve in the single tree here, not much I can just yet, have to wait for them to hit Linus's tree. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging driver fix for 5.12-rc6
The following changes since commit 0d02ec6b3136c73c09e7859f0d0e4e2c4c07b49b: Linux 5.12-rc4 (2021-03-21 14:56:43 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git tags/staging-5.12-rc6 for you to fetch changes up to e78836ae76d20f38eed8c8c67f21db97529949da: staging: rtl8192e: Change state information from u16 to u8 (2021-03-23 13:32:40 +0100) Staging driver fixes for 5.12-rc6 Here are 2 rtl8192e staging driver fixes for reported problems. Both of these have been in linux-next for a while with no reported issues. Signed-off-by: Greg Kroah-Hartman Atul Gopinathan (2): staging: rtl8192e: Fix incorrect source in memcpy() staging: rtl8192e: Change state information from u16 to u8 drivers/staging/rtl8192e/rtllib.h| 2 +- drivers/staging/rtl8192e/rtllib_rx.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: fbtft: change snprintf() to scnprintf()
On Fri, Apr 02, 2021 at 09:05:01AM +, Carlis wrote: > From: Xuezhi Zhang > > show() must not use snprintf() when formatting the value to > be returned to user space. Why not? The code is just fine as-is. > > Signed-off-by: Xuezhi Zhang > --- > drivers/staging/fbtft/fbtft-sysfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/fbtft/fbtft-sysfs.c > b/drivers/staging/fbtft/fbtft-sysfs.c > index 26e52cc2de64..7df92db648d6 100644 > --- a/drivers/staging/fbtft/fbtft-sysfs.c > +++ b/drivers/staging/fbtft/fbtft-sysfs.c > @@ -199,7 +199,7 @@ static ssize_t show_debug(struct device *device, > struct fb_info *fb_info = dev_get_drvdata(device); > struct fbtft_par *par = fb_info->par; > > - return snprintf(buf, PAGE_SIZE, "%lu\n", par->debug); > + return scnprintf(buf, PAGE_SIZE, "%lu\n", par->debug); If you really want to "fix" this, please just use sysfs_emit(). This change as-is, does nothing. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Re: Re: Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process
On Thu, Apr 01, 2021 at 08:28:02PM +0800, Yongji Xie wrote: > On Thu, Apr 1, 2021 at 7:33 PM Greg KH wrote: > > > > On Thu, Apr 01, 2021 at 07:29:45PM +0800, Yongji Xie wrote: > > > On Thu, Apr 1, 2021 at 6:42 PM Greg KH wrote: > > > > > > > > On Thu, Apr 01, 2021 at 06:12:51PM +0800, Yongji Xie wrote: > > > > > On Thu, Apr 1, 2021 at 5:54 PM Greg KH > > > > > wrote: > > > > > > > > > > > > On Thu, Apr 01, 2021 at 05:09:32PM +0800, Xie Yongji wrote: > > > > > > > Use receive_fd() to receive file from another process instead of > > > > > > > combination of get_unused_fd_flags() and fd_install(). This > > > > > > > simplifies > > > > > > > the logic and also makes sure we don't miss any security stuff. > > > > > > > > > > > > But no logic is simplified here, and nothing is "missed", so I do > > > > > > not > > > > > > understand this change at all. > > > > > > > > > > > > > > > > I noticed that we have security_binder_transfer_file() when we > > > > > transfer some fds. I'm not sure whether we need something like > > > > > security_file_receive() here? > > > > > > > > Why would you? And where is "here"? > > > > > > > > still confused, > > > > > > > > > > I mean do we need to go through the file_receive seccomp notifier when > > > we receive fd (use get_unused_fd_flags() + fd_install now) from > > > another process in binder_apply_fd_fixups(). > > > > Why? this is internal things, why does seccomp come into play here? > > > > We already have security_binder_transfer_file() to control the sender > process. So for the receiver process, do we need the seccomp too? Or > do I miss something here? I do not know, is this something that is a requirement that seccomp handle all filesystem handles sent to a process? I do not know the seccomp "guarantee" that well, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Re: Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process
On Thu, Apr 01, 2021 at 07:29:45PM +0800, Yongji Xie wrote: > On Thu, Apr 1, 2021 at 6:42 PM Greg KH wrote: > > > > On Thu, Apr 01, 2021 at 06:12:51PM +0800, Yongji Xie wrote: > > > On Thu, Apr 1, 2021 at 5:54 PM Greg KH wrote: > > > > > > > > On Thu, Apr 01, 2021 at 05:09:32PM +0800, Xie Yongji wrote: > > > > > Use receive_fd() to receive file from another process instead of > > > > > combination of get_unused_fd_flags() and fd_install(). This simplifies > > > > > the logic and also makes sure we don't miss any security stuff. > > > > > > > > But no logic is simplified here, and nothing is "missed", so I do not > > > > understand this change at all. > > > > > > > > > > I noticed that we have security_binder_transfer_file() when we > > > transfer some fds. I'm not sure whether we need something like > > > security_file_receive() here? > > > > Why would you? And where is "here"? > > > > still confused, > > > > I mean do we need to go through the file_receive seccomp notifier when > we receive fd (use get_unused_fd_flags() + fd_install now) from > another process in binder_apply_fd_fixups(). Why? this is internal things, why does seccomp come into play here? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process
On Thu, Apr 01, 2021 at 06:12:51PM +0800, Yongji Xie wrote: > On Thu, Apr 1, 2021 at 5:54 PM Greg KH wrote: > > > > On Thu, Apr 01, 2021 at 05:09:32PM +0800, Xie Yongji wrote: > > > Use receive_fd() to receive file from another process instead of > > > combination of get_unused_fd_flags() and fd_install(). This simplifies > > > the logic and also makes sure we don't miss any security stuff. > > > > But no logic is simplified here, and nothing is "missed", so I do not > > understand this change at all. > > > > I noticed that we have security_binder_transfer_file() when we > transfer some fds. I'm not sure whether we need something like > security_file_receive() here? Why would you? And where is "here"? still confused, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] binder: Use receive_fd() to receive file from another process
On Thu, Apr 01, 2021 at 05:09:32PM +0800, Xie Yongji wrote:
> Use receive_fd() to receive file from another process instead of
> combination of get_unused_fd_flags() and fd_install(). This simplifies
> the logic and also makes sure we don't miss any security stuff.
But no logic is simplified here, and nothing is "missed", so I do not
understand this change at all.
>
> Signed-off-by: Xie Yongji
> ---
> drivers/android/binder.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index c119736ca56a..080bcab7d632 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -3728,7 +3728,7 @@ static int binder_apply_fd_fixups(struct binder_proc
> *proc,
> int ret = 0;
>
> list_for_each_entry(fixup, &t->fd_fixups, fixup_entry) {
> - int fd = get_unused_fd_flags(O_CLOEXEC);
> + int fd = receive_fd(fixup->file, O_CLOEXEC);
Why 2 spaces?
>
> if (fd < 0) {
> binder_debug(BINDER_DEBUG_TRANSACTION,
> @@ -3741,7 +3741,7 @@ static int binder_apply_fd_fixups(struct binder_proc
> *proc,
>"fd fixup txn %d fd %d\n",
>t->debug_id, fd);
> trace_binder_transaction_fd_recv(t, fd, fixup->offset);
> - fd_install(fd, fixup->file);
> + fput(fixup->file);
Are you sure this is the same???
I d onot understand the need for this change at all, what is wrong with
the existing code here?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] Export receive_fd() to modules and do some cleanups
On Thu, Apr 01, 2021 at 05:09:30PM +0800, Xie Yongji wrote: > This series starts from Christian's comments on the series[1]. > We'd like to export receive_fd() which can not only be used by > our module in the series[1] but also allow further cleanups > like patch 2 does. But binder can not be a module, so why do you need this? confused, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] file: Export receive_fd() to modules
On Thu, Apr 01, 2021 at 05:09:31PM +0800, Xie Yongji wrote:
> Export receive_fd() so that some modules can use
> it to pass file descriptor across processes without
> missing any security stuffs.
>
> Signed-off-by: Xie Yongji
> ---
> fs/file.c| 6 ++
> include/linux/file.h | 7 +++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/fs/file.c b/fs/file.c
> index 56986e55befa..2a80c6c3e147 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -1107,6 +1107,12 @@ int receive_fd_replace(int new_fd, struct file *file,
> unsigned int o_flags)
> return new_fd;
> }
>
> +int receive_fd(struct file *file, unsigned int o_flags)
> +{
> + return __receive_fd(file, NULL, o_flags);
> +}
> +EXPORT_SYMBOL(receive_fd);
What module uses this?
And why not EXPORT_SYMBOL_GPL()?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/2] char: xillybus: Move class-related functions to new xillybus_class.c
On Tue, Mar 23, 2021 at 02:05:23PM +0200, Eli Billauer wrote: > On 22/03/21 13:11, Greg KH wrote: > > > > > XILLYBUS and XILLYBUS_PCIE are currently enabled as M in several Linux > > > distributions. Making them depend on, rather than select XILLYBUS_CLASS is > > > likely to disable the driver in those distributions. > > That's not an issue here, depends-on will allow those distros to also > > enable this option. > > > > But wait, why is this a separate option at all? Shouldn't the class > > code just be part of the "core" XILLYBUS code anyway? > > > I'll try to explain the whole picture: > >XILLYBUS_CLASS > /\ > | | > XILLYBUS XILLYUSB > / \ > | | > XILLYBUS_PCIE XILLYBUS_OF > > XILLYBUS_CLASS is new and common to all drivers in this group. > > XILLYBUS is for drivers based upon memory registers + DMA-based interfaces, > and it's combined with XILLYBUS_PCIE and/or XILLYBUS_OF. XILLYUSB is for the > USB variant only. > > Or a more detailed, bottom-up outline: > > * CONFIG_XILLYBUS_PCIE -> xillybus_pcie.c: Functions related to PCIe. > * CONFIG_XILLYBUS_OF -> xillybus_of.c: Functions related to Xillybus as a > peripheral on an FPGA / Processor combo chip. > * CONFIG_XILLYBUS -> xillybus_core.c: Functions that are common to the two > above, mainly access to the peripheral with memory-mapped registers and DMA. > * CONFIG_XILLYUSB -> xillyusb.c: The driver for the USB variant, accesses > the peripheral through the USB framework. > * CONFIG_XILLYBUS_CLASS -> xillybus_class.c: The new module, which contains > the class and API parts that would otherwise appear both in xillybus_core.c > and xillyusb.c. Contains utility functions for the two latter. > > Because XILLYBUS_CLASS is new and "N" by default, making a "depends on" > relationship means that "make olddefconfig" silently turns off > CONFIG_XILLYBUS and CONFIG_XILLYBUS_PCIE. That's a bug: Adding a new driver > shouldn't change anything in the existing configuration. > > That's why I had the "select XILLYBUS_CLASS" to begin with: It ensures a > smooth transition on a kernel upgrade, by adding XILLYBUS_CLASS to kernels > that had CONFIG_XILLYBUS enabled. Is there another way to prevent the said > bug, without "select"? Ok, that explains it a bit better, thanks for taking the time to explain it. At first glance it seems odd, but this looks better, if you include this information in the changelog texts for your patches when you send the next series, that will help out with the review. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: gasket: remove it from the kernel
On Thu, Mar 25, 2021 at 03:46:10PM +0100, Jan Kiszka wrote: > On 15.03.21 17:10, Rob Springer wrote: > > Acked-by: Rob Springer > > > > > > On Mon, Mar 15, 2021 at 8:44 AM wrote: > >> > >> From: Greg Kroah-Hartman > >> > >> As none of the proposed things that need to be changed in the gasket > >> drivers have ever been done, and there has not been any forward progress > >> to get this out of staging, it seems totally abandonded so remove the > >> code entirely so that people do not spend their time doing tiny cleanups > >> for code that will never get out of staging. > >> > >> If this code is actually being used, it can be reverted simply and then > >> cleaned up properly, but as it is abandoned, let's just get rid of it. > >> > >> Cc: Rob Springer > >> Cc: Todd Poynor > >> Cc: Ben Chan > >> Cc: Richard Yeh > >> Signed-off-by: Greg Kroah-Hartman > > OK, so is there a plan of the HW vendor to improve the user experience > for this hardware? Is there a different software architecture in sight > which will not need a kernel driver? What hardware vendor makes this thing? What systems require it? And why can't you use UIO instead? > Just wondering loudly while fiddling with dkms packages and starring at > the code diffs between what was removed here and what I still have to > install manually from remote sources. Where are the remote sources for this thing and why didn't they ever get synced into the kernel tree? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: fix fw is NULL but dereferenced
On Thu, Mar 25, 2021 at 07:03:39PM +0800, Jian Dong wrote: > On Thu, 25 Mar 2021 11:29:06 +0100 > Greg KH wrote: > > > On Thu, Mar 25, 2021 at 06:19:26PM +0800, Jian Dong wrote: > > > From: Jian Dong > > > > > > fixes coccicheck Error: > > > > > > drivers/staging/greybus/bootrom.c:301:41-45: ERROR: > > > fw is NULL but dereferenced. > > > > > > if procedure goto label directly, ret will be nefative, so the fw > > > is NULL and the if(condition) end with dereferenced fw. let's fix > > > it. > > > > Why is this all indented a space? > this maybe caused by my terminal, I will take notice next time. > > > > > > > > Signed-off-by: Jian Dong > > > --- > > > drivers/staging/greybus/bootrom.c | 8 > > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > > > diff --git a/drivers/staging/greybus/bootrom.c > > > b/drivers/staging/greybus/bootrom.c index a8efb86..0439efa 100644 > > > --- a/drivers/staging/greybus/bootrom.c > > > +++ b/drivers/staging/greybus/bootrom.c > > > @@ -246,7 +246,7 @@ static int gb_bootrom_get_firmware(struct > > > gb_operation *op) struct gb_bootrom_get_firmware_response > > > *firmware_response; struct device *dev = > > > &op->connection->bundle->dev; unsigned int offset, size; > > > - enum next_request_type next_request; > > > + enum next_request_type next_request = > > > NEXT_REQ_GET_FIRMWARE; int ret = 0; > > > > > > /* Disable timeouts */ > > > @@ -298,10 +298,10 @@ static int gb_bootrom_get_firmware(struct > > > gb_operation *op) > > > queue_work: > > > /* Refresh timeout */ > > > - if (!ret && (offset + size == fw->size)) > > > - next_request = NEXT_REQ_READY_TO_BOOT; > > > - else > > > + if (!!ret) > > > > That is hard to understand, please make this more obvious. > > > if (A && B) else (!A || !B) > > So, when ret is NON-ZERO, set next_request as GET_FIRMWARE, else set > READ_TO_BOOT. but if second express is flase, next_request still > need be set as GET_FIRMWARE, So, I initialze it as GET_FIRMWARE. My point is: if (!!ret) is odd, and is the same thing as: if (ret) correct? And the latter is the common kernel style, no need to be complex when you do not need to. Anyway, others have pointed out why this is incorrect, no need for further discussion. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: greybus: fix fw is NULL but dereferenced
On Thu, Mar 25, 2021 at 06:19:26PM +0800, Jian Dong wrote: > From: Jian Dong > > fixes coccicheck Error: > > drivers/staging/greybus/bootrom.c:301:41-45: ERROR: > fw is NULL but dereferenced. > > if procedure goto label directly, ret will be nefative, so the fw is NULL > and the if(condition) end with dereferenced fw. let's fix it. Why is this all indented a space? > > Signed-off-by: Jian Dong > --- > drivers/staging/greybus/bootrom.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/greybus/bootrom.c > b/drivers/staging/greybus/bootrom.c > index a8efb86..0439efa 100644 > --- a/drivers/staging/greybus/bootrom.c > +++ b/drivers/staging/greybus/bootrom.c > @@ -246,7 +246,7 @@ static int gb_bootrom_get_firmware(struct gb_operation > *op) > struct gb_bootrom_get_firmware_response *firmware_response; > struct device *dev = &op->connection->bundle->dev; > unsigned int offset, size; > - enum next_request_type next_request; > + enum next_request_type next_request = NEXT_REQ_GET_FIRMWARE; > int ret = 0; > > /* Disable timeouts */ > @@ -298,10 +298,10 @@ static int gb_bootrom_get_firmware(struct gb_operation > *op) > > queue_work: > /* Refresh timeout */ > - if (!ret && (offset + size == fw->size)) > - next_request = NEXT_REQ_READY_TO_BOOT; > - else > + if (!!ret) That is hard to understand, please make this more obvious. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: android: binder.c: Fix indentation of multi-line comment
On Sat, Mar 13, 2021 at 09:46:55PM +0530, Abhishek C wrote:
> Fixed alignment of multi-line comment.
> Added a * for each line of the comment.
>
> Signed-off-by: Abhishek C
> ---
> drivers/android/binder.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index c119736ca56a..700719c58147 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -4617,8 +4617,9 @@ static long binder_ioctl(struct file *filp, unsigned
> int cmd, unsigned long arg)
> unsigned int size = _IOC_SIZE(cmd);
> void __user *ubuf = (void __user *)arg;
>
> - /*pr_info("binder_ioctl: %d:%d %x %lx\n",
> - proc->pid, current->pid, cmd, arg);*/
> + /* pr_info("binder_ioctl: %d:%d %x %lx\n",
> + * proc->pid, current->pid, cmd, arg);
> + */
This looks like left-over debugging code, and as-is, is formatted
properly.
Why not just delete it entirely? If someone needs debugging code, they
can add it back in.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/9] fix extern declarations checkpatch issues
On Tue, Mar 23, 2021 at 01:56:27PM +0100, Fabio Aiuto wrote: > Fix extern declaration issues warned by checkpatch. Nit, we have a new mailing list, you might want to use that now instead of driverdev in the future, thanks! greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: Trivial typo fix
On Tue, Mar 23, 2021 at 06:38:35AM +0530, Bhaskar Chowdhury wrote:
>
> s/netowrk/network/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
> b/drivers/staging/rtl8723bs/core/rtw_mlme.c
> index 2c9425e2a1e9..3888d3984ec0 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
> @@ -599,7 +599,7 @@ void rtw_update_scanned_network(struct adapter *adapter,
> struct wlan_bssid_ex *t
> }
>
> if (rtw_roam_flags(adapter)) {
> - /* TODO: don't select netowrk in the same ess as
> oldest if it's new enough*/
> + /* TODO: don't select network in the same ess as
> oldest if it's new enough*/
Any reason you did not remove the two spaces at the same time?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] drivers: most: add ALSA sound driver
On Tue, Feb 09, 2021 at 11:13:47AM +0100, Christian Gromm wrote: > This patch moves the ALSA sound driver out of the staging area and adds it > to the stable part of the MOST driver. Modifications to the Makefiles and > Kconfigs are done accordingly to not break the build. > > Signed-off-by: Christian Gromm > --- > v2: > Reported-by: Greg Kroah-Hartman > > submitted patch that fixes issue found during code audit > to staging version first to be able to resend single patch that > adds the driver. The patch series included: > > - use swabXX functions of kernel > > v3: > Reported-by: Dan Carpenter > > - use non-safe list iteration > - add sanity check for function argument Given a lack of complaints about this, I've now queued this up in my staging tree for the next -rc1 merge window, thanks! greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wimax: Mundane typo fixes
On Mon, Mar 22, 2021 at 09:14:43PM -0700, Randy Dunlap wrote: > On 3/22/21 6:06 PM, Bhaskar Chowdhury wrote: > > > > s/procesing/processing/ > > s/comunication/communication/ > > > > Signed-off-by: Bhaskar Chowdhury > > drivers/staging/wimax/ is in the process of being deleted. It's already gone from my tree, and should be gone from linux-next as well. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/11] staging: rtl8723bs: remove argument in recv_indicatepkts_pkt_loss_cnt
On Mon, Mar 22, 2021 at 03:31:43PM +0100, Fabio Aiuto wrote: > remove debug_priv argument so function prototype can be > easily moved away > > Signed-off-by: Fabio Aiuto > --- > drivers/staging/rtl8723bs/core/rtw_recv.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c > b/drivers/staging/rtl8723bs/core/rtw_recv.c > index 9ef2408ded57..e2a6afed723c 100644 > --- a/drivers/staging/rtl8723bs/core/rtw_recv.c > +++ b/drivers/staging/rtl8723bs/core/rtw_recv.c > @@ -1983,13 +1983,13 @@ int enqueue_reorder_recvframe(struct > recv_reorder_ctrl *preorder_ctrl, union rec > > } > > -void recv_indicatepkts_pkt_loss_cnt(struct debug_priv *pdbgpriv, u64 > prev_seq, u64 current_seq); > -void recv_indicatepkts_pkt_loss_cnt(struct debug_priv *pdbgpriv, u64 > prev_seq, u64 current_seq) > +u64 recv_indicatepkts_pkt_loss_cnt(u64 prev_seq, u64 current_seq); But you did not drop the function prototype, why keep it? And shouldn't this be static? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 04/11] staging: rtl8723bs: moved function prototypes out of core/rtw_recv.c
On Mon, Mar 22, 2021 at 03:31:42PM +0100, Fabio Aiuto wrote:
> fix the following checkpatch issues:
>
> WARNING: externs should be avoided in .c files
> 1190: FILE: drivers/staging/rtl8723bs/core/rtw_recv.c:1190:
> +signed int validate_recv_mgnt_frame(struct adapter *padapter, union
> recv_frame *precv_frame);
>
> and then moved all function prototypes but one in include/rtw_recv.h
>
> Signed-off-by: Fabio Aiuto
> ---
> drivers/staging/rtl8723bs/core/rtw_recv.c| 31 +---
> drivers/staging/rtl8723bs/include/rtw_recv.h | 51
> 2 files changed, 52 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c
> b/drivers/staging/rtl8723bs/core/rtw_recv.c
> index 1fa381663b4c..9ef2408ded57 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_recv.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
> @@ -305,7 +305,6 @@ struct recv_buf *rtw_dequeue_recvbuf(struct __queue
> *queue)
>
> }
>
> -signed int recvframe_chkmic(struct adapter *adapter, union recv_frame
> *precvframe);
> signed int recvframe_chkmic(struct adapter *adapter, union recv_frame
> *precvframe)
> {
>
> @@ -435,8 +434,6 @@ signed int recvframe_chkmic(struct adapter *adapter,
> union recv_frame *precvfra
>
> }
>
> -/* decrypt and set the ivlen, icvlen of the recv_frame */
> -union recv_frame *decryptor(struct adapter *padapter, union recv_frame
> *precv_frame);
> union recv_frame *decryptor(struct adapter *padapter, union recv_frame
> *precv_frame)
> {
>
> @@ -527,8 +524,6 @@ union recv_frame *decryptor(struct adapter *padapter,
> union recv_frame *precv_fr
> return return_packet;
> }
>
> -/* set the security information in the recv_frame */
> -union recv_frame *portctrl(struct adapter *adapter, union recv_frame
> *precv_frame);
> union recv_frame *portctrl(struct adapter *adapter, union recv_frame
> *precv_frame)
> {
> u8 *psta_addr = NULL;
> @@ -606,7 +601,6 @@ union recv_frame *portctrl(struct adapter *adapter, union
> recv_frame *precv_fram
> return prtnframe;
> }
>
> -signed int recv_decache(union recv_frame *precv_frame, u8 bretry, struct
> stainfo_rxcache *prxcache);
> signed int recv_decache(union recv_frame *precv_frame, u8 bretry, struct
> stainfo_rxcache *prxcache)
> {
> signed int tid = precv_frame->u.hdr.attrib.priority;
> @@ -634,7 +628,6 @@ signed int recv_decache(union recv_frame *precv_frame, u8
> bretry, struct stainfo
>
> }
>
> -void process_pwrbit_data(struct adapter *padapter, union recv_frame
> *precv_frame);
> void process_pwrbit_data(struct adapter *padapter, union recv_frame
> *precv_frame)
> {
> unsigned char pwrbit;
> @@ -671,7 +664,6 @@ void process_pwrbit_data(struct adapter *padapter, union
> recv_frame *precv_frame
> }
> }
>
> -void process_wmmps_data(struct adapter *padapter, union recv_frame
> *precv_frame);
> void process_wmmps_data(struct adapter *padapter, union recv_frame
> *precv_frame)
> {
> struct rx_pkt_attrib *pattrib = &precv_frame->u.hdr.attrib;
> @@ -723,7 +715,6 @@ void process_wmmps_data(struct adapter *padapter, union
> recv_frame *precv_frame)
> }
> }
>
> -void count_rx_stats(struct adapter *padapter, union recv_frame *prframe,
> struct sta_info *sta);
> void count_rx_stats(struct adapter *padapter, union recv_frame *prframe,
> struct sta_info *sta)
> {
> int sz;
> @@ -755,8 +746,6 @@ void count_rx_stats(struct adapter *padapter, union
> recv_frame *prframe, struct
> traffic_check_for_leave_lps(padapter, false, 0);
> }
>
> -signed int sta2sta_data_frame(struct adapter *adapter, union recv_frame
> *precv_frame,
> - struct sta_info **psta);
> signed int sta2sta_data_frame(struct adapter *adapter, union recv_frame
> *precv_frame,
> struct sta_info **psta)
> {
> @@ -850,8 +839,6 @@ signed int sta2sta_data_frame(struct adapter *adapter,
> union recv_frame *precv_f
> return ret;
> }
>
> -signed int ap2sta_data_frame(struct adapter *adapter, union recv_frame
> *precv_frame,
> -struct sta_info **psta);
> signed int ap2sta_data_frame(struct adapter *adapter, union recv_frame
> *precv_frame,
> struct sta_info **psta)
> {
> @@ -992,8 +979,6 @@ signed int ap2sta_data_frame(struct adapter *adapter,
> union recv_frame *precv_fr
> return ret;
> }
>
> -signed int sta2ap_data_frame(struct adapter *adapter, union recv_frame
> *precv_frame,
> -struct sta_info **psta);
> signed int sta2ap_data_frame(struct adapter *adapter, union recv_frame
> *precv_frame,
> struct sta_info **psta)
> {
> @@ -1049,7 +1034,6 @@ signed int sta2ap_data_frame(struct adapter *adapter,
> union recv_frame *precv_fr
> return ret;
> }
>
> -signed int validate_recv_ctrl_frame(struct adapter *padapter, union
> recv_frame *precv_frame);
> signed int validate_recv_ctrl_frame(struct adapter
Re: [PATCH 03/11] staging: rtl8723bs: moved function prototype out of core/rtw_ioctl_set.c and core/rtw_mlme.c
On Mon, Mar 22, 2021 at 03:31:41PM +0100, Fabio Aiuto wrote:
> fix the following checkpatch issues:
>
> WARNING: externs should be avoided in .c files
> 40: FILE: drivers/staging/rtl8723bs/core/rtw_ioctl_set.c:40:
> +u8 rtw_do_join(struct adapter *padapter);
>
> WARNING: externs should be avoided in .c files
> 15: FILE: drivers/staging/rtl8723bs/core/rtw_mlme.c:15:
> +extern u8 rtw_do_join(struct adapter *padapter);
>
> moved function prototype in include/rtw_ioctl_set.h
>
> Signed-off-by: Fabio Aiuto
> ---
> drivers/staging/rtl8723bs/core/rtw_ioctl_set.c| 1 -
> drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 --
> drivers/staging/rtl8723bs/include/rtw_ioctl_set.h | 2 ++
> 3 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
> b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
> index cb14855742f7..7d858cae2395 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_ioctl_set.c
> @@ -37,7 +37,6 @@ u8 rtw_validate_ssid(struct ndis_802_11_ssid *ssid)
> return ret;
> }
>
> -u8 rtw_do_join(struct adapter *padapter);
> u8 rtw_do_join(struct adapter *padapter)
> {
> struct list_head*plist, *phead;
> diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
> b/drivers/staging/rtl8723bs/core/rtw_mlme.c
> index 95cfef118a94..1ee86ec2dee7 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
> @@ -12,8 +12,6 @@
> #include
> #include
>
> -extern u8 rtw_do_join(struct adapter *padapter);
> -
> int rtw_init_mlme_priv(struct adapter *padapter)
> {
> int i;
> diff --git a/drivers/staging/rtl8723bs/include/rtw_ioctl_set.h
> b/drivers/staging/rtl8723bs/include/rtw_ioctl_set.h
> index 4b929b84040a..55722c1366aa 100644
> --- a/drivers/staging/rtl8723bs/include/rtw_ioctl_set.h
> +++ b/drivers/staging/rtl8723bs/include/rtw_ioctl_set.h
> @@ -28,6 +28,8 @@ u8 rtw_set_802_11_connect(struct adapter *padapter, u8
> *bssid, struct ndis_802_1
> u8 rtw_validate_bssid(u8 *bssid);
> u8 rtw_validate_ssid(struct ndis_802_11_ssid *ssid);
>
> +u8 rtw_do_join(struct adapter *padapter);
> +
This is already in drivers/staging/rtl8188eu/include/hal_intf.h, why
declare it again?
I'm stopping here on reviewing this patchset, please look closer at it
again and fix up and resend a v2.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 02/11] staging: rtl8723bs: moved function prototypes out of core/rtw_efuse.c
On Mon, Mar 22, 2021 at 03:31:40PM +0100, Fabio Aiuto wrote:
> fix the following checkpatch issues:
>
> WARNING: externs should be avoided in .c files
> 35: FILE: drivers/staging/rtl8723bs/core/rtw_efuse.c:35:
> +bool
>
> moved two function prototypes in include/rtw_efuse.h
>
> Signed-off-by: Fabio Aiuto
> ---
> drivers/staging/rtl8723bs/core/rtw_efuse.c| 10 --
> drivers/staging/rtl8723bs/include/rtw_efuse.h | 3 +++
> 2 files changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_efuse.c
> b/drivers/staging/rtl8723bs/core/rtw_efuse.c
> index 32ca10f01413..0772397738d4 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_efuse.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_efuse.c
> @@ -32,11 +32,6 @@ u8 fakeBTEfuseModifiedMap[EFUSE_BT_MAX_MAP_LEN] = {0};
> #define REG_EFUSE_CTRL 0x0030
> #define EFUSE_CTRL REG_EFUSE_CTRL /* E-Fuse
> Control. */
>
> -bool
> -Efuse_Read1ByteFromFakeContent(
> - struct adapter *padapter,
> - u16 Offset,
> - u8 *Value);
> bool
> Efuse_Read1ByteFromFakeContent(
> struct adapter *padapter,
> @@ -53,11 +48,6 @@ Efuse_Read1ByteFromFakeContent(
> return true;
> }
>
> -bool
> -Efuse_Write1ByteToFakeContent(
> - struct adapter *padapter,
> - u16 Offset,
> - u8 Value);
> bool
> Efuse_Write1ByteToFakeContent(
> struct adapter *padapter,
> diff --git a/drivers/staging/rtl8723bs/include/rtw_efuse.h
> b/drivers/staging/rtl8723bs/include/rtw_efuse.h
> index 5bae46ecd9de..1f304df8c421 100644
> --- a/drivers/staging/rtl8723bs/include/rtw_efuse.h
> +++ b/drivers/staging/rtl8723bs/include/rtw_efuse.h
> @@ -103,6 +103,9 @@ extern u8 fakeBTEfuseInitMap[];
> extern u8 fakeBTEfuseModifiedMap[];
> /*Export global
> variable*/
>
> +bool Efuse_Read1ByteFromFakeContent(struct adapter *padapter, u16 Offset, u8
> *Value);
> +bool Efuse_Write1ByteToFakeContent(struct adapter *padapter, u16 Offset, u8
> Value);
No, there's no need for this to be in a .h file, it is only called from
one .c file.
Make the thing static and all should be fine, right?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 11/11] staging: rtl8723bs: remove unnecessary extern in os_dep/sdio_intf.c
On Mon, Mar 22, 2021 at 03:31:49PM +0100, Fabio Aiuto wrote: > remove unnecessary extern. > > The function is defined static in os_dep/os_intfs.c and used only once > in the same file > > remove also a blank line That needs to go to a separate patch :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8723bs: Mundane typo fixes
On Mon, Mar 22, 2021 at 12:58:08PM +0530, Bhaskar Chowdhury wrote: > > s/stoping/stooping/ Huh? Are you _sure_ that is the correct replacement? Last I looked it wasn't... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/2] staging: Add driver for XillyUSB (Xillybus variant for USB)
On Mon, Mar 22, 2021 at 01:01:54PM +0200, Eli Billauer wrote:
> Hello, Greg.
>
> Thanks for your comments. I'd like to address a couple of them.
>
> First, there's the lockless FIFO that is implemented in the driver:
>
> On 21/03/21 14:23, Greg KH wrote:
> >
> > > +
> > > +static unsigned int fifo_read(struct xillyfifo *fifo,
> > > + void *data, unsigned int len,
> > > + int (*copier)(void *, const void *, int))
> > > +{
> > > + unsigned int done = 0;
> > > + unsigned int todo = len;
> > > + unsigned int fill;
> > > + unsigned int readpos = fifo->readpos;
> > > + unsigned int readbuf = fifo->readbuf;
> > > +
> > > + fill = atomic_read(&fifo->fill);
> > And the number changed right after reading it :(
> >
> > Again, no atomics, use a lock please.
> >
> > This is a USB device, you are NOT doing high-speed data transfers at
> > all.
> >
> The current XillyUSB hardware is USB 3.0 based, running at ~400 MB/s, and
> this is just the beginning. For comparison, when the PCIe-based Xillybus
> started at 200 MB/s, I didn't believe it would reach 6.6 GB/s.
>
> So that's why I made the effort to implement a lockless FIFO, with all the
> extra synchronization fuss. And yes, it works perfectly, and has been
> heavily fuzz tested on an x86_64 machine. The memory barriers are carefully
> placed to make this work on less favorable platforms as well, but even if I
> got it wrong -- odds are that the fix will be a line or two.
>
> Replacing atomics with spinlocks is a piece of cake, of course. But given
> this extra information, do you still think it's a good idea?
Trying to review this code is hard, if not impossible because of the
structure. Again, USB interfaces are slow, a "custom lockless FIFO" is
something for the core kernel to implement, not for a random individual
driver, to ensure it is working properly.
And it seems like an overkill, are you sure those locks are a slowdown?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/2] char: xillybus: Move class-related functions to new xillybus_class.c
On Mon, Mar 22, 2021 at 01:02:04PM +0200, Eli Billauer wrote: > On 21/03/21 14:24, Greg KH wrote: > > > +config XILLYBUS_CLASS > > > > + tristate > > > > + > > > >config XILLYBUS > > > > tristate "Xillybus generic FPGA interface" > > > > depends on PCI || OF > > > > select CRC32 > > > > + select XILLYBUS_CLASS > > depends on, do not select. > > > XILLYBUS and XILLYBUS_PCIE are currently enabled as M in several Linux > distributions. Making them depend on, rather than select XILLYBUS_CLASS is > likely to disable the driver in those distributions. That's not an issue here, depends-on will allow those distros to also enable this option. But wait, why is this a separate option at all? Shouldn't the class code just be part of the "core" XILLYBUS code anyway? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[GIT PULL] Staging/IIO driver fixes for 5.12-rc4
The following changes since commit 1e28eed17697bcf343c6743f0028cc3b5dd88bf0: Linux 5.12-rc3 (2021-03-14 14:41:02 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git tags/staging-5.12-rc4 for you to fetch changes up to 2cafd46a714af1e55354bc6dcea9dcc13f9475b5: staging: vt665x: fix alignment constraints (2021-03-18 10:21:46 +0100) Staging/IIO driver fixes for 5.12-rc4 Here are some small staging and IIO driver fixes for 5.12-rc4. They include: - MAINTAINERS changes for the move of the staging mailing list - comedi driver fixes to get request_irq() to work correctly - counter driver fixes for reported issues with iio devices - tiny iio driver fixes for reported issues. All of these have been in linux-next with no reported problems. Signed-off-by: Greg Kroah-Hartman Alexandru Ardelean (1): iio: adc: adi-axi-adc: add proper Kconfig dependencies Dan Carpenter (1): iio: adis16400: Fix an error code in adis16400_initial_setup() Dinghao Liu (1): iio: gyro: mpu3050: Fix error handling in mpu3050_trigger_handler Edmundo Carmona Antoranz (1): staging: vt665x: fix alignment constraints Fabrice Gasnier (2): counter: stm32-timer-cnt: fix ceiling write max value counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register Greg Kroah-Hartman (3): Merge tag 'iio-fixes-for-5.12a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus MAINTAINERS: move some real subsystems off of the staging mailing list MAINTAINERS: move the staging subsystem to lists.linux.dev Jonathan Albrieux (1): iio:adc:qcom-spmi-vadc: add default scale to LR_MUX2_BAT_ID channel Jonathan Cameron (1): iio:adc:stm32-adc: Add HAS_IOMEM dependency Linus Walleij (1): iio: adc: ab8500-gpadc: Fix off by 10 to 3 Tong Zhang (2): staging: comedi: cb_pcidas: fix request_irq() warn staging: comedi: cb_pcidas64: fix request_irq() warn Wilfried Wessner (1): iio: adc: ad7949: fix wrong ADC result due to incorrect bit mask William Breathitt Gray (1): counter: stm32-timer-cnt: Report count function when SLAVE_MODE_DISABLED Ye Xiang (3): iio: hid-sensor-prox: Fix scale not correct issue iio: hid-sensor-humidity: Fix alignment issue of timestamp channel iio: hid-sensor-temperature: Fix issues of timestamp channel MAINTAINERS | 7 ++- drivers/counter/stm32-timer-cnt.c| 55 ++-- drivers/iio/adc/Kconfig | 3 ++ drivers/iio/adc/ab8500-gpadc.c | 2 +- drivers/iio/adc/ad7949.c | 2 +- drivers/iio/adc/qcom-spmi-vadc.c | 2 +- drivers/iio/gyro/mpu3050-core.c | 2 + drivers/iio/humidity/hid-sensor-humidity.c | 12 +++--- drivers/iio/imu/adis16400.c | 3 +- drivers/iio/light/hid-sensor-prox.c | 13 +- drivers/iio/temperature/hid-sensor-temperature.c | 14 +++--- drivers/staging/comedi/drivers/cb_pcidas.c | 2 +- drivers/staging/comedi/drivers/cb_pcidas64.c | 2 +- drivers/staging/vt6655/rxtx.h| 4 +- 14 files changed, 75 insertions(+), 48 deletions(-) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/2] char: xillybus: Move class-related functions to new xillybus_class.c
On Thu, Mar 11, 2021 at 11:50:32AM +0200, eli.billa...@gmail.com wrote: > +EXPORT_SYMBOL(xillybus_init_chrdev); Given the license for this code, perhaps EXPORT_SYMBOL_GPL()? I have to ask :) thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/2] char: xillybus: Move class-related functions to new xillybus_class.c
On Thu, Mar 11, 2021 at 11:50:32AM +0200, eli.billa...@gmail.com wrote: > From: Eli Billauer > > This patch is a preparation for adding another related driver, XillyUSB. > In order to share some code between the existing Xillybus driver and the > one to be added, some functions are moved to xillybus_class.c > > The header file, xillybus_class.h, is temporarily placed in include/linux/, > because the new XillyUSB driver is intended as a staging driver for the > time being. > > Signed-off-by: Eli Billauer > --- > > Notes: > Changelog: > > v4: > - Fix error code return value bugs in xillybus_init_chrdev() as > detected by > Smatch test robot, and reported by Dan Carpenter. > > This patch did not exist prior to v3. > > drivers/char/xillybus/Kconfig | 4 + > drivers/char/xillybus/Makefile | 1 + > drivers/char/xillybus/xillybus.h | 10 +- > drivers/char/xillybus/xillybus_class.c | 263 + > drivers/char/xillybus/xillybus_core.c | 181 +++-- > include/linux/xillybus_class.h | 30 +++ > 6 files changed, 322 insertions(+), 167 deletions(-) > create mode 100644 drivers/char/xillybus/xillybus_class.c > create mode 100644 include/linux/xillybus_class.h > > diff --git a/drivers/char/xillybus/Kconfig b/drivers/char/xillybus/Kconfig > index 130dbdce858f..e7800f025249 100644 > --- a/drivers/char/xillybus/Kconfig > +++ b/drivers/char/xillybus/Kconfig > @@ -3,10 +3,14 @@ > # Xillybus devices > # > > +config XILLYBUS_CLASS > + tristate > + > config XILLYBUS > tristate "Xillybus generic FPGA interface" > depends on PCI || OF > select CRC32 > + select XILLYBUS_CLASS depends on, do not select. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 2/2] staging: Add driver for XillyUSB (Xillybus variant for USB)
On Thu, Mar 11, 2021 at 11:50:33AM +0200, eli.billa...@gmail.com wrote: > From: Eli Billauer > > The XillyUSB driver is the USB variant for the Xillybus FPGA IP core. > Even though it presents a nearly identical API on the FPGA and host, > it's almost a complete rewrite of the driver: The framework for exchanging > data on a USB bus is fundamentally different from doing the same with a > PCIe interface, which leaves very little in common between the existing > driver and the new one for XillyUSB. > > Signed-off-by: Eli Billauer > --- > > Notes: > Changelog: > v4: > (No changes) > > v3: > - Move to staging > - Rely on xillybus_class for device file operations > - Fix no return value bug in xillyusb_discovery() > - Add module parameters for URB buffer size and count Don't move to staging, let's do this right the first time, it will just take too much work to get this out of staging instead of the correct way now. > > v2: > - Add comment in Kconfig file, saying XILLYUSB really doesn't depend > on XILLYBUS (following comment by Randy Dunlap) > - Use SEEK_* predefined constants instead of numbers > > MAINTAINERS |1 + > drivers/staging/Kconfig |2 + > drivers/staging/Makefile|1 + > drivers/staging/xillyusb/Kconfig| 20 + > drivers/staging/xillyusb/Makefile |6 + > drivers/staging/xillyusb/TODO | 13 + > drivers/staging/xillyusb/xillyusb.c | 2184 +++ > 7 files changed, 2227 insertions(+) > create mode 100644 drivers/staging/xillyusb/Kconfig > create mode 100644 drivers/staging/xillyusb/Makefile > create mode 100644 drivers/staging/xillyusb/TODO > create mode 100644 drivers/staging/xillyusb/xillyusb.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index d92f85ca831d..1bf73b132e31 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -19749,6 +19749,7 @@ M:Eli Billauer > L: linux-ker...@vger.kernel.org > S: Supported > F: drivers/char/xillybus/ > +F: drivers/staging/xillyusb/ > > XLP9XX I2C DRIVER > M: George Cherian > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > index b22f73d7bfc4..6fcbc6f90224 100644 > --- a/drivers/staging/Kconfig > +++ b/drivers/staging/Kconfig > @@ -114,4 +114,6 @@ source "drivers/staging/wfx/Kconfig" > > source "drivers/staging/hikey9xx/Kconfig" > > +source "drivers/staging/xillyusb/Kconfig" > + > endif # STAGING > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > index 2245059e69c7..42dfd6a4ca28 100644 > --- a/drivers/staging/Makefile > +++ b/drivers/staging/Makefile > @@ -47,3 +47,4 @@ obj-$(CONFIG_QLGE) += qlge/ > obj-$(CONFIG_WIMAX) += wimax/ > obj-$(CONFIG_WFX)+= wfx/ > obj-y+= hikey9xx/ > +obj-$(CONFIG_XILLYUSB) += xillyusb/ > diff --git a/drivers/staging/xillyusb/Kconfig > b/drivers/staging/xillyusb/Kconfig > new file mode 100644 > index ..af7251104b42 > --- /dev/null > +++ b/drivers/staging/xillyusb/Kconfig > @@ -0,0 +1,20 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# XillyUSB devices > +# > + > +config XILLYUSB > + tristate "Xillybus generic FPGA interface for USB" > + depends on USB > + select CRC32 > + select XILLYBUS_CLASS Depend on it, don't select it. > + help > + XillyUSB is the Xillybus variant which uses USB for communicating > + with the FPGA. > + > + Xillybus is a generic interface for peripherals designed on > + programmable logic (FPGA). The driver probes the hardware for > + its capabilities, and creates device files accordingly. > + > + Set to M if you want Xillybus to use USB for communicating with > + the FPGA. Module name? > diff --git a/drivers/staging/xillyusb/Makefile > b/drivers/staging/xillyusb/Makefile > new file mode 100644 > index ..1b45211992f5 > --- /dev/null > +++ b/drivers/staging/xillyusb/Makefile > @@ -0,0 +1,6 @@ > +# SPDX-License-Identifier: GPL-2.0-only > +# > +# Makefile for XillyUSB driver > +# > + > +obj-$(CONFIG_XILLYUSB) += xillyusb.o > diff --git a/drivers/staging/xillyusb/TODO b/drivers/staging/xillyusb/TODO > new file mode 100644 > index ..0cb6a005ada4 > --- /dev/null > +++ b/drivers/staging/xillyusb/TODO > @@ -0,0 +1,13 @@ > +XillyUSB driver > +=== > + > +This driver is the USB counterpart for the driver at drivers/char/xillybus/. > +See Documentation/driver-api/xillybus.rst. > + > +TODO > + > + - Enhance code reuse with the existing Xillybus driver. > + > + - General code review. Both should not be a reason for staging. > + > +Patches to: Eli Billauer > \ No newline at end of file > diff --git a/drivers/staging/xillyusb/xillyusb.c > b/drivers/staging/xillyusb/xillyusb.c > new file mode 100644 > index ..bcf55c1a380d > --- /dev/null > +++ b/drivers/st
Re: [PATCH] rtl8188eu: Removed Unnecessary ftrace-like logging
On Thu, Mar 18, 2021 at 08:05:27PM +, Paul McQuade wrote: > prefer using ftrace You need to say more here than just this please. Also please fix up your subject line to have "staging:" in it, otherwise it gets easily lost. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] rtsx_chip.c:Fix usleep_range is preferred over udelay
On Thu, Mar 18, 2021 at 04:38:37PM +0530, Akshith A V wrote:
> changed udelay to usleep_range
Trailing whitespace and odd line wrap :(
> because usleep_range is preferred over udelay by checkpatch.pl
>
> Signed-off-by: Akshith A V
> ---
> drivers/staging/rts5208/rtsx_chip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rts5208/rtsx_chip.c
> b/drivers/staging/rts5208/rtsx_chip.c
> index ee9ddc4eb94d..41ee334a4e6c 100644
> --- a/drivers/staging/rts5208/rtsx_chip.c
> +++ b/drivers/staging/rts5208/rtsx_chip.c
> @@ -1804,7 +1804,7 @@ void rtsx_exit_ss(struct rtsx_chip *chip)
>
> if (chip->power_down_in_ss) {
> rtsx_force_power_on(chip, SSC_PDCTL | OC_PDCTL);
> - udelay(1000);
> + usleep_range(1000, 1010);
Does this really do anything different?
Did you test this?
> }
>
> if (RTSX_TST_DELINK(chip)) {
> --
> 2.25.1
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: rtl8723bs: prefer ftrace
On Thu, Mar 18, 2021 at 10:14:15AM +0100, Fabio Aiuto wrote:
> Hi,
>
> some suggestions before diving in a new task.
> The following checkpatch issue:
>
> --
> WARNING: Unnecessary ftrace-like logging - prefer using ftrace
> #559: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:559:
> + DBG_871X("%s\n", __func__);
>
> simply says to remove the line, due to the existence of the more
> appealing ftrace facility, right?
>
> @@ -556,8 +554,6 @@ void update_sta_info_apmode(struct adapter *padapter,
> struct sta_info *psta)
> /* set intf_tag to if1 */
> /* psta->intf_tag = 0; */
>
> - DBG_871X("%s\n", __func__);
> -
> /* psta->mac_id = psta->aid+4; */
> /* psta->mac_id = psta->aid+1;//alloc macid when call
> rtw_alloc_stainfo(), */
> /* release macid when call rtw_free_stainfo() */
>
Yes, stuff like this can be deleted.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: rtl8723bs: remove unused code blocks completed?
On Wed, Mar 17, 2021 at 10:59:32AM +0100, Fabio Aiuto wrote: > Hi, > > I'm trying to search other unused code blocks: > > grep -r '^\(#ifdef \|#if defined(\|#ifndef \)CONFIG_' > drivers/staging/rtl8723bs/ > > drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:#if defined(CONFIG_PM) > drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:#if defined(CONFIG_PM) > drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:#if defined(CONFIG_WEXT_PRIV) > drivers/staging/rtl8723bs/include/drv_conf.h:#ifndef CONFIG_RTW_HIQ_FILTER > drivers/staging/rtl8723bs/include/autoconf.h:#ifndef CONFIG_WIRELESS_EXT > > all blocks left are checked by existing defines. > Could we apply this? Sure, looks good, submit this as a real patch with this information in the changelog and I"ll be glad to take it. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/15] staging: rtl8723bs: remove unused code blocks
On Mon, Mar 15, 2021 at 11:13:49AM +0100, Fabio Aiuto wrote: > Remove unused code blocks as required in TODO file > > Fabio Aiuto (15): > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_AUTO_AP_MODE > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_HW_PWRP_DETECTION > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_QOS_OPTIMIZATION > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_AP_WOWLAN > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_PM > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_SIGNAL_DISPLAY_DBM > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_BACKGROUND_NOISE_MONITOR > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_SKIP_SIGNAL_SCALE_MAPPING > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_GPIO_API > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_EXT_CLK > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_CHECK_BT_HANG > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_SDIO_TX_TASKLET > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_SW_CHANNEL_PLAN > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_C2H_PACKET_EN > staging: rtl8723bs: remove unused code blocks conditioned by never set > CONFIG_ODM_ADAPTIVITY Not all of these would apply, please rebase and resend the remaining ones. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/15] staging: rtl8723bs: remove unused code blocks conditioned by never set CONFIG_PM
On Mon, Mar 15, 2021 at 11:15:02AM +0100, Fabio Aiuto wrote: > remove conditional code blocks checked by unused CONFIG_PM > > cleaning required in TODO file: > > find and remove code blocks guarded by never set CONFIG_FOO defines > > Signed-off-by: Fabio Aiuto > --- > drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 8 > 1 file changed, 8 deletions(-) > > diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c > b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c > index 2ff71d001c07..5748e1c1a25c 100644 > --- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c > +++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c > @@ -3198,14 +3198,6 @@ static void rtw_cfg80211_preinit_wiphy(struct adapter > *padapter, struct wiphy *w > wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL; > wiphy->flags |= WIPHY_FLAG_OFFCHAN_TX | WIPHY_FLAG_HAVE_AP_SME; > > -#if defined(CONFIG_PM) > - wiphy->max_sched_scan_reqs = 1; > -#endif > - > -#if defined(CONFIG_PM) > - wiphy->wowlan = &wowlan_stub; > -#endif How this is "unused"? This is a real config option, did you just change the logic here? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rts5208: add empty line in general.c
On Mon, Mar 15, 2021 at 07:12:20PM +0800, Hao Peng wrote: > Add one empty line upon return for easy reading. Why? Is this really needed? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: remove extra lines in rtl819x_BAProc.c
On Mon, Mar 15, 2021 at 07:04:18PM +0800, Hao Peng wrote: > Remove extra lines in rtl819x_BAProc.c. > > Signed-off-by: Hao Peng Same issue here, please fix up the changelog text. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: remove extra space in rtl819x_BAProc.c
On Mon, Mar 15, 2021 at 06:33:20PM +0800, Hao Peng wrote: > Remove extra spaces in rtl819x_BAProc.c. That says what you did, but not _why_ you are doing this. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging:rtl8723bs:core:rtw_wlan_util:fixed indentation coding style issue
On Sun, Mar 14, 2021 at 09:58:55PM +0530, Shreya wrote: > Fixed the indentation of the else part of the conditional statement. > > Signed-off-by: Shreya > --- > v1 -> v2: > Changed name in signed-off-by to match name in From No, change it the other way around, you had your "real" name in the signed-off-by line, fix your email client to also have that :) Please try this again with a v3 patch. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192u: remove extra lines
On Tue, Mar 16, 2021 at 05:59:22PM +0800, zhaoxiao wrote:
> Remove extra lines in the struct r8192_private_args.
>
> Signed-off-by: zhaoxiao
> ---
> drivers/staging/rtl8192u/r8192U_wx.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/staging/rtl8192u/r8192U_wx.c
> b/drivers/staging/rtl8192u/r8192U_wx.c
> index 6ead461e3279..e9de7dc8f049 100644
> --- a/drivers/staging/rtl8192u/r8192U_wx.c
> +++ b/drivers/staging/rtl8192u/r8192U_wx.c
> @@ -879,12 +879,10 @@ static iw_handler r8192_wx_handlers[] = {
>
>
> static const struct iw_priv_args r8192_private_args[] = {
> -
> {
> SIOCIWFIRSTPRIV + 0x0,
> IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, "badcrc"
> },
> -
> {
> SIOCIWFIRSTPRIV + 0x1,
> IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, "activescan"
> @@ -897,7 +895,6 @@ static const struct iw_priv_args r8192_private_args[] = {
> {
> SIOCIWFIRSTPRIV + 0x3,
> IW_PRIV_TYPE_INT | IW_PRIV_SIZE_FIXED | 1, 0, "forcereset"
> -
> }
>
> };
> --
> 2.20.1
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what is needed in order to
properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/SubmittingPatches for what a proper Subject: line should
look like.
- This looks like a new version of a previously submitted patch, but you
did not list below the --- line any changes from the previous version.
Please read the section entitled "The canonical patch format" in the
kernel file, Documentation/SubmittingPatches for what needs to be done
here to properly describe this.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
