Re: [staging:staging-testing 36/53] drivers/staging/rtl8192e/rtllib_crypt_tkip.c:640:7: warning: variable 'iv16' set but not used
On Fri, Aug 23, 2024 at 06:27:49PM +0100, Simon Horman wrote: > On Fri, Aug 23, 2024 at 06:16:49PM +0100, Simon Horman wrote: > > On Fri, Aug 23, 2024 at 08:35:15PM +0800, kernel test robot wrote: > > > tree: > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > > > staging-testing > > > head: 5315266844ea3b0b8b6be9842d5901e439fa838a > > > commit: 5f1a6826ea4900f8540d5eeb29f97796860f2d08 [36/53] staging: > > > rtl8192e: remove set but otherwise unused local variable iv32 > > > config: x86_64-allyesconfig > > > (https://download.01.org/0day-ci/archive/20240823/202408232049.ujef268y-...@intel.com/config) > > > compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project > > > 617a15a9eac96088ae5e9134248d8236e34b91b1) > > > reproduce (this is a W=1 build): > > > (https://download.01.org/0day-ci/archive/20240823/202408232049.ujef268y-...@intel.com/reproduce) > > > > > > If you fix the issue in a separate patch/commit (i.e. not just a new > > > version of > > > the same patch/commit), kindly add following tags > > > | Reported-by: kernel test robot > > > | Closes: > > > https://lore.kernel.org/oe-kbuild-all/202408232049.ujef268y-...@intel.com/ > > > > > > All warnings (new ones prefixed by >>): > > > > > > >> drivers/staging/rtl8192e/rtllib_crypt_tkip.c:640:7: warning: variable > > > >> 'iv16' set but not used [-Wunused-but-set-variable] > > > 640 | u16 iv16 = tkey->tx_iv16; > > > | ^ > > >1 warning generated. > > > > Sorry about this. > > > > It seems that my patch, cited above, which removed a set but otherwise > > unused variable results in iv16 being set but otherwise unused. > > > > I'll prepare a follow-up patch to address this. > > Patch is here: > > - [PATCH] staging: rtl8192e: remove set but otherwise unused local variable > iv16 > > https://lore.kernel.org/linux-staging/20240823-rtl8192e-iv16-v1-1-000702673...@kernel.org/T/#u Now applied, thanks for the quick response! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 36/53] drivers/staging/rtl8192e/rtllib_crypt_tkip.c:640:7: warning: variable 'iv16' set but not used
On Fri, Aug 23, 2024 at 06:16:49PM +0100, Simon Horman wrote: > On Fri, Aug 23, 2024 at 08:35:15PM +0800, kernel test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > > staging-testing > > head: 5315266844ea3b0b8b6be9842d5901e439fa838a > > commit: 5f1a6826ea4900f8540d5eeb29f97796860f2d08 [36/53] staging: rtl8192e: > > remove set but otherwise unused local variable iv32 > > config: x86_64-allyesconfig > > (https://download.01.org/0day-ci/archive/20240823/202408232049.ujef268y-...@intel.com/config) > > compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project > > 617a15a9eac96088ae5e9134248d8236e34b91b1) > > reproduce (this is a W=1 build): > > (https://download.01.org/0day-ci/archive/20240823/202408232049.ujef268y-...@intel.com/reproduce) > > > > If you fix the issue in a separate patch/commit (i.e. not just a new > > version of > > the same patch/commit), kindly add following tags > > | Reported-by: kernel test robot > > | Closes: > > https://lore.kernel.org/oe-kbuild-all/202408232049.ujef268y-...@intel.com/ > > > > All warnings (new ones prefixed by >>): > > > > >> drivers/staging/rtl8192e/rtllib_crypt_tkip.c:640:7: warning: variable > > >> 'iv16' set but not used [-Wunused-but-set-variable] > > 640 | u16 iv16 = tkey->tx_iv16; > > | ^ > >1 warning generated. > > Sorry about this. > > It seems that my patch, cited above, which removed a set but otherwise > unused variable results in iv16 being set but otherwise unused. > > I'll prepare a follow-up patch to address this. Patch is here: - [PATCH] staging: rtl8192e: remove set but otherwise unused local variable iv16 https://lore.kernel.org/linux-staging/20240823-rtl8192e-iv16-v1-1-000702673...@kernel.org/T/#u ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 36/53] drivers/staging/rtl8192e/rtllib_crypt_tkip.c:640:7: warning: variable 'iv16' set but not used
On Fri, Aug 23, 2024 at 08:35:15PM +0800, kernel test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > staging-testing > head: 5315266844ea3b0b8b6be9842d5901e439fa838a > commit: 5f1a6826ea4900f8540d5eeb29f97796860f2d08 [36/53] staging: rtl8192e: > remove set but otherwise unused local variable iv32 > config: x86_64-allyesconfig > (https://download.01.org/0day-ci/archive/20240823/202408232049.ujef268y-...@intel.com/config) > compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project > 617a15a9eac96088ae5e9134248d8236e34b91b1) > reproduce (this is a W=1 build): > (https://download.01.org/0day-ci/archive/20240823/202408232049.ujef268y-...@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version > of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot > | Closes: > https://lore.kernel.org/oe-kbuild-all/202408232049.ujef268y-...@intel.com/ > > All warnings (new ones prefixed by >>): > > >> drivers/staging/rtl8192e/rtllib_crypt_tkip.c:640:7: warning: variable > >> 'iv16' set but not used [-Wunused-but-set-variable] > 640 | u16 iv16 = tkey->tx_iv16; > | ^ >1 warning generated. Sorry about this. It seems that my patch, cited above, which removed a set but otherwise unused variable results in iv16 being set but otherwise unused. I'll prepare a follow-up patch to address this. ... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] add binder genl for txn report
Hi Li, kernel test robot noticed the following build errors: [auto build test ERROR on staging/staging-testing] [also build test ERROR on staging/staging-next staging/staging-linus linus/master v6.11-rc3 next-20240814] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Li-Li/add-binder-genl-for-txn-report/20240814-150338 base: staging/staging-testing patch link: https://lore.kernel.org/r/20240812211844.4107494-1-dualli%40chromium.org patch subject: [PATCH v1] add binder genl for txn report config: x86_64-buildonly-randconfig-002-20240814 (https://download.01.org/0day-ci/archive/20240815/202408150004.batk29zs-...@intel.com/config) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240815/202408150004.batk29zs-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202408150004.batk29zs-...@intel.com/ All error/warnings (new ones prefixed by >>): >> drivers/android/binder_genl.c:20: warning: This comment starts with '/**', >> but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * The registered process that would receive binder reports. drivers/android/binder_genl.c:25: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * The policy to verify the type of the binder genl data >> drivers/android/binder_genl.c:102: warning: cannot understand function >> prototype: 'struct genl_small_ops binder_genl_ops[] = ' >> drivers/android/binder_genl.c:114: warning: cannot understand function >> prototype: 'struct genl_family binder_gnl_family = ' -- ld: drivers/android/binder_genl.o: in function `binder_genl_cmd_doit': >> binder_genl.c:(.text+0x38): undefined reference to `__alloc_skb' >> ld: binder_genl.c:(.text+0x61): undefined reference to `genlmsg_put' >> ld: binder_genl.c:(.text+0x83): undefined reference to `nla_put' >> ld: binder_genl.c:(.text+0xb7): undefined reference to `init_net' >> ld: binder_genl.c:(.text+0xbc): undefined reference to `netlink_unicast' >> ld: binder_genl.c:(.text+0x135): undefined reference to `skb_trim' >> ld: binder_genl.c:(.text+0x144): undefined reference to `sk_skb_reason_drop' ld: binder_genl.c:(.text+0x195): undefined reference to `sk_skb_reason_drop' ld: drivers/android/binder_genl.o: in function `binder_genl_send_report': binder_genl.c:(.text+0x21c): undefined reference to `__alloc_skb' ld: binder_genl.c:(.text+0x248): undefined reference to `genlmsg_put' ld: binder_genl.c:(.text+0x267): undefined reference to `nla_put' ld: binder_genl.c:(.text+0x298): undefined reference to `init_net' ld: binder_genl.c:(.text+0x29d): undefined reference to `netlink_unicast' ld: binder_genl.c:(.text+0x304): undefined reference to `skb_trim' ld: binder_genl.c:(.text+0x313): undefined reference to `sk_skb_reason_drop' ld: binder_genl.c:(.text+0x34c): undefined reference to `sk_skb_reason_drop' ld: drivers/android/binder_genl.o: in function `binder_genl_init': >> binder_genl.c:(.init.text+0x12): undefined reference to >> `genl_register_family' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v1] add binder genl for txn report
Hi Li, kernel test robot noticed the following build errors: [auto build test ERROR on staging/staging-testing] [also build test ERROR on staging/staging-next staging/staging-linus linus/master v6.11-rc3 next-20240814] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Li-Li/add-binder-genl-for-txn-report/20240814-150338 base: staging/staging-testing patch link: https://lore.kernel.org/r/20240812211844.4107494-1-dualli%40chromium.org patch subject: [PATCH v1] add binder genl for txn report config: x86_64-buildonly-randconfig-005-20240814 (https://download.01.org/0day-ci/archive/20240815/202408150142.elc854f6-...@intel.com/config) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240815/202408150142.elc854f6-...@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot | Closes: https://lore.kernel.org/oe-kbuild-all/202408150142.elc854f6-...@intel.com/ All errors (new ones prefixed by >>): ld: vmlinux.o: in function `binder_genl_cmd_doit': binder_genl.c:(.text+0x1284e00): undefined reference to `__alloc_skb' ld: binder_genl.c:(.text+0x1284e2f): undefined reference to `genlmsg_put' ld: binder_genl.c:(.text+0x1284e5c): undefined reference to `nla_put' ld: binder_genl.c:(.text+0x1284e94): undefined reference to `init_net' ld: binder_genl.c:(.text+0x1284e9d): undefined reference to `netlink_unicast' ld: binder_genl.c:(.text+0x1284f04): undefined reference to `skb_trim' ld: binder_genl.c:(.text+0x1284f18): undefined reference to `sk_skb_reason_drop' ld: binder_genl.c:(.text+0x1284f72): undefined reference to `sk_skb_reason_drop' ld: vmlinux.o: in function `binder_genl_send_report': >> (.text+0x12850d9): undefined reference to `__alloc_skb' >> ld: (.text+0x128510a): undefined reference to `genlmsg_put' >> ld: (.text+0x1285131): undefined reference to `nla_put' >> ld: (.text+0x128516e): undefined reference to `init_net' >> ld: (.text+0x1285173): undefined reference to `netlink_unicast' >> ld: (.text+0x12851c2): undefined reference to `skb_trim' >> ld: (.text+0x12851d6): undefined reference to `sk_skb_reason_drop' ld: (.text+0x128527a): undefined reference to `sk_skb_reason_drop' ld: vmlinux.o: in function `binder_genl_init': >> (.init.text+0xa5bd7): undefined reference to `genl_register_family' -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ___ 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 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 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.
I'm happy to rename it to binder_netlink.c if that's easier to remember.
>
>
> >
> > 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?
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.
>
> 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.
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?
>
> 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.
It's also possible to have one netlink socket for each binder context.
But it seems
like overkill to me.
Thanks,
Li
___
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 v3] staging: rtl8192e: Fix conflicting types error with net_device.
On 6/25/24 18:33, Teddy Engel wrote:
Add a pre-declaration of struct net_device so the compiler is able to
use rtl_pci.h / rtl_cam.h.
Signed-off-by: Teddy Engel
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202406250858.l8rjmhqm-...@intel.com/
Fixes: 7dff0b27d9c8 ("staging: rtl8192e: Remove unnecessary pre-declaration of
struct net_device")
---
v3: Replace ad-hoc commit id / subject by expected Fixes tag.
v2: Add commit id / commit subject under description.
drivers/staging/rtl8192e/rtl8192e/rtl_cam.h | 2 ++
drivers/staging/rtl8192e/rtl8192e/rtl_pci.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_cam.h
b/drivers/staging/rtl8192e/rtl8192e/rtl_cam.h
index 3a5635494385..9deffdf96072 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_cam.h
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_cam.h
@@ -12,6 +12,8 @@
#include
+struct net_device;
+
void rtl92e_cam_reset(struct net_device *dev);
void rtl92e_enable_hw_security_config(struct net_device *dev);
void rtl92e_set_key(struct net_device *dev, u8 EntryNo, u8 KeyIndex,
diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_pci.h
b/drivers/staging/rtl8192e/rtl8192e/rtl_pci.h
index c645775b2150..3e39c4835ac8 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_pci.h
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_pci.h
@@ -13,6 +13,8 @@
#include
#include
+struct net_device;
+
bool rtl92e_check_adapter(struct pci_dev *pdev, struct net_device *dev);
#endif
Tested-by: Philipp Hortmann
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: rtl8192e: Fix conflicting types error with net_device.
On Tue, Jun 25, 2024 at 04:19:18PM +0100, Teddy Engel wrote: > Add a pre-declaration of struct net_device so the compiler is able to > use rtl_pci.h / rtl_cam.h. > > Fix for commit: 7dff0b27d9c842f88149bf611cbc0b59be1dcd3c: > [34/59] staging: rtl89192e: Remove unnecessary pre-declaration of struct > net_device. > > Signed-off-by: Teddy Engel > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202406250858.l8rjmhqm-...@intel.com/ > --- > v2: Add commit id that's being fixed. You do that with a "Fixes:" tag, not the paragraph you wrote above :) The documentation should explain how to do it, right? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: Fix conflicting types error with net_device.
On Tue, Jun 25, 2024 at 01:56:38PM +0100, Teddy Engel wrote: > Add a pre-declaration of struct net_device so the compiler is able to > use rtl_pci.h / rtl_cam.h. > > Signed-off-by: Teddy Engel > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202406250858.l8rjmhqm-...@intel.com/ What commit id does this fix? Also note, your mailing list address is wrong for staging stuff, you need to cc: the public one before I can take this. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [driver-core:const_driver 12/12] drivers/usb/core/driver.c:80 store_id() error: uninitialized symbol 'usb_dynid'.
On Thu, Jun 13, 2024 at 09:31:36AM +0300, Dan Carpenter wrote:
> On Thu, Jun 13, 2024 at 08:18:04AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Jun 13, 2024 at 08:57:13AM +0300, Dan Carpenter wrote:
> > > tree:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> > > const_driver
> > > head: be520b87ec28aa3b5c908a859501fb601bd8b322
> > > commit: be520b87ec28aa3b5c908a859501fb601bd8b322 [12/12] USB: move
> > > dynamic ids out of usb driver structures
> > > config: i386-randconfig-141-20240613
> > > (https://download.01.org/0day-ci/archive/20240613/202406130740.hir25kic-...@intel.com/config)
> > > compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project
> > > 617a15a9eac96088ae5e9134248d8236e34b91b1)
> > >
> > > If you fix the issue in a separate patch/commit (i.e. not just a new
> > > version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot
> > > | Reported-by: Dan Carpenter
> > > | Closes: https://lore.kernel.org/r/202406130740.hir25kic-...@intel.com/
> > >
> > > smatch warnings:
> > > drivers/usb/core/driver.c:80 store_id() error: uninitialized symbol
> > > 'usb_dynid'.
> > >
> > > vim +/usb_dynid +80 drivers/usb/core/driver.c
> > >
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 70 static int
> > > store_id(const struct device_driver *driver, const struct usb_device_id
> > > *id)
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 71 {
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 72 struct
> > > usb_dynids *u;
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 73 struct
> > > usb_dynid *usb_dynid;
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 74
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 75 u =
> > > usb_find_dynids(driver);
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 76 if (!u) {
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 77 /* This
> > > driver has not stored any ids yet, so make a new entry for it */
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 78 u =
> > > kmalloc(sizeof(*u), GFP_KERNEL);
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 79 if (!u)
> > > {
> > > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 @80
> > > kfree(usb_dynid);
> > >
> > > Delete the kfree()
> >
> > Ugh, thanks, missed that.
> >
> > And you are now testing random branches in my tree, nice! Note, I
> > haven't even booted this one yet, it barely builds :)
>
> These are zero day bot stuff. The zero day bot is always out there
> automatically slurping up any git repository it can find. There is a
> way to opt-out but I can't remember what it is...
No, I want zero-day to test this branch (I use it as my "build on all
arches test") and it found a bunch of issues already that I will be
queueing up later today.
For some reason I thought you were testing this on your own, nevermind,
it's just a side affect of 0-day's testing. No objection from me!
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [driver-core:const_driver 12/12] drivers/usb/core/driver.c:80 store_id() error: uninitialized symbol 'usb_dynid'.
On Thu, Jun 13, 2024 at 08:18:04AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 13, 2024 at 08:57:13AM +0300, Dan Carpenter wrote:
> > tree:
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> > const_driver
> > head: be520b87ec28aa3b5c908a859501fb601bd8b322
> > commit: be520b87ec28aa3b5c908a859501fb601bd8b322 [12/12] USB: move dynamic
> > ids out of usb driver structures
> > config: i386-randconfig-141-20240613
> > (https://download.01.org/0day-ci/archive/20240613/202406130740.hir25kic-...@intel.com/config)
> > compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project
> > 617a15a9eac96088ae5e9134248d8236e34b91b1)
> >
> > If you fix the issue in a separate patch/commit (i.e. not just a new
> > version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot
> > | Reported-by: Dan Carpenter
> > | Closes: https://lore.kernel.org/r/202406130740.hir25kic-...@intel.com/
> >
> > smatch warnings:
> > drivers/usb/core/driver.c:80 store_id() error: uninitialized symbol
> > 'usb_dynid'.
> >
> > vim +/usb_dynid +80 drivers/usb/core/driver.c
> >
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 70 static int store_id(const
> > struct device_driver *driver, const struct usb_device_id *id)
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 71 {
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 72struct usb_dynids *u;
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 73struct usb_dynid
> > *usb_dynid;
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 74
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 75u =
> > usb_find_dynids(driver);
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 76if (!u) {
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 77/* This driver
> > has not stored any ids yet, so make a new entry for it */
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 78u =
> > kmalloc(sizeof(*u), GFP_KERNEL);
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 79if (!u) {
> > be520b87ec28aa Greg Kroah-Hartman 2024-06-11 @80
> > kfree(usb_dynid);
> >
> > Delete the kfree()
>
> Ugh, thanks, missed that.
>
> And you are now testing random branches in my tree, nice! Note, I
> haven't even booted this one yet, it barely builds :)
These are zero day bot stuff. The zero day bot is always out there
automatically slurping up any git repository it can find. There is a
way to opt-out but I can't remember what it is...
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [driver-core:const_driver 12/12] drivers/usb/core/driver.c:80 store_id() error: uninitialized symbol 'usb_dynid'.
On Thu, Jun 13, 2024 at 08:57:13AM +0300, Dan Carpenter wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> const_driver
> head: be520b87ec28aa3b5c908a859501fb601bd8b322
> commit: be520b87ec28aa3b5c908a859501fb601bd8b322 [12/12] USB: move dynamic
> ids out of usb driver structures
> config: i386-randconfig-141-20240613
> (https://download.01.org/0day-ci/archive/20240613/202406130740.hir25kic-...@intel.com/config)
> compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project
> 617a15a9eac96088ae5e9134248d8236e34b91b1)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version
> of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot
> | Reported-by: Dan Carpenter
> | Closes: https://lore.kernel.org/r/202406130740.hir25kic-...@intel.com/
>
> smatch warnings:
> drivers/usb/core/driver.c:80 store_id() error: uninitialized symbol
> 'usb_dynid'.
>
> vim +/usb_dynid +80 drivers/usb/core/driver.c
>
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 70 static int store_id(const
> struct device_driver *driver, const struct usb_device_id *id)
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 71 {
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 72 struct usb_dynids *u;
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 73 struct usb_dynid
> *usb_dynid;
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 74
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 75 u =
> usb_find_dynids(driver);
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 76 if (!u) {
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 77 /* This driver
> has not stored any ids yet, so make a new entry for it */
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 78 u =
> kmalloc(sizeof(*u), GFP_KERNEL);
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 79 if (!u) {
> be520b87ec28aa Greg Kroah-Hartman 2024-06-11 @80
> kfree(usb_dynid);
>
> Delete the kfree()
Ugh, thanks, missed that.
And you are now testing random branches in my tree, nice! Note, I
haven't even booted this one yet, it barely builds :)
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtl8192e: Fixes a coding style error
On Fri, May 17, 2024 at 12:01:40PM +0100, Mohamed Karaoui wrote: > Adds a space before if statement's condition > > Signed-off-by: Mohamed Karaoui > --- > drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c > b/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c > index 0cbf4a1a326b..b2af802b9451 100644 > --- a/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c > +++ b/drivers/staging/rtl8192e/rtllib_crypt_ccmp.c > @@ -278,7 +278,7 @@ static int rtllib_ccmp_decrypt(struct sk_buff *skb, int > hdr_len, void *priv) > int aad_len, ret; > > req = aead_request_alloc(key->tfm, GFP_ATOMIC); > - if(!req) > + if (!req) > return -ENOMEM; > > aad_len = ccmp_init_iv_and_aad(hdr, pn, iv, aad); 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 did not apply to any known trees that Greg is in control of. Possibly this is because you made it against Linus's tree, not the linux-next tree, which is where all of the development for the next version of the kernel is at. Please refresh your patch against the linux-next tree, or even better yet, the development tree specified in the MAINTAINERS file for the subsystem you are submitting a patch for, and resend it. 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 AUTOSEL 6.1 3/7] x86/hyperv: Use slow_virt_to_phys() in page transition hypervisor callback
From: Pavel Machek Sent: Tuesday, March 12, 2024 1:35 PM > > > In preparation for temporarily marking pages not present during a > > transition between encrypted and decrypted, use slow_virt_to_phys() > > in the hypervisor callback. As long as the PFN is correct, > > This seems to be preparation for something we don't plan to do in > -stable. Please drop. > As the author of the patch, I agree. Michael ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH AUTOSEL 6.1 3/7] x86/hyperv: Use slow_virt_to_phys() in page transition hypervisor callback
Hi! > In preparation for temporarily marking pages not present during a > transition between encrypted and decrypted, use slow_virt_to_phys() > in the hypervisor callback. As long as the PFN is correct, This seems to be preparation for something we don't plan to do in -stable. Please drop. Best regards, Pavel -- People of Russia, stop Putin before his war on Ukraine escalates. signature.asc Description: PGP signature ___ 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: [driver-core:driver-core-testing] BUILD SUCCESS ae4d90f7ca49eb71f8a3dca64d06d4c4e2193705
Luis > El 25.12.2023, a las 4:31, kernel test robot escribió: > > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > driver-core-testing > branch HEAD: ae4d90f7ca49eb71f8a3dca64d06d4c4e2193705 driver core: device.h: > fix Excess kernel-doc description warning > > elapsed time: 2281m > > configs tested: 99 > configs skipped: 1 > > The following configs have been built successfully. > More configs may be tested in the coming days. > > tested configs: > alpha allnoconfig gcc > alpha defconfig gcc > arc allnoconfig gcc > arc defconfig gcc > arc nsimosci_hs_smp_defconfig gcc > arc randconfig-001-20231224 gcc > arc randconfig-002-20231224 gcc > arm allnoconfig gcc > arm defconfig clang > armmvebu_v5_defconfig clang > armneponset_defconfig clang > arm randconfig-001-20231224 gcc > arm randconfig-002-20231224 gcc > arm randconfig-003-20231224 gcc > arm randconfig-004-20231224 gcc > arm rpc_defconfig gcc > armshmobile_defconfig gcc > arm64 allnoconfig gcc > arm64 defconfig gcc > arm64 randconfig-001-20231224 gcc > arm64 randconfig-002-20231224 gcc > arm64 randconfig-003-20231224 gcc > arm64 randconfig-004-20231224 gcc > csky allnoconfig gcc > cskydefconfig gcc > csky randconfig-001-20231224 gcc > csky randconfig-002-20231224 gcc > hexagon allnoconfig clang > hexagon defconfig clang > hexagon randconfig-001-20231224 clang > hexagon randconfig-002-20231224 clang > i386 allmodconfig clang > i386 allnoconfig clang > i386 allyesconfig clang > i386 buildonly-randconfig-001-20231224 gcc > i386 buildonly-randconfig-002-20231224 gcc > i386 buildonly-randconfig-003-20231224 gcc > i386 buildonly-randconfig-004-20231224 gcc > i386 buildonly-randconfig-005-20231224 gcc > i386 buildonly-randconfig-006-20231224 gcc > i386defconfig gcc > i386 randconfig-001-20231224 gcc > i386 randconfig-002-20231224 gcc > i386 randconfig-003-20231224 gcc > i386 randconfig-004-20231224 gcc > i386 randconfig-005-20231224 gcc > i386 randconfig-006-20231224 gcc > i386 randconfig-011-20231224 clang > i386 randconfig-012-20231224 clang > i386 randconfig-013-20231224 clang > i386 randconfig-014-20231224 clang > i386 randconfig-015-20231224 clang > i386 randconfig-016-20231224 clang > loongarchallmodconfig gcc > loongarch allnoconfig gcc > loongarch randconfig-001-20231224 gcc > loongarch randconfig-002-20231224 gcc > m68k allmodconfig gcc > m68k allnoconfig gcc > m68k allyesconfig gcc > m68kdefconfig gcc > m68km5407c3_defconfig gcc > microblaze allmodconfig gcc > microblazeallnoconfig gcc > microblaze allyesconfig gcc > mips allyesconfig gcc > mips malta_kvm_defconfig clang > nios2allmodconfig gcc > nios2allyesconfig gcc > nios2 randconfig-001-20231224 gcc > nios2 randconfig-002-20231224 gcc > pariscrandconfig-001-20231224 gcc > pariscrandconfig-002-20231224 gcc > powerpc asp8347_defconfig gcc > powerpc currituck_defconfig gcc > powerpc ep8248e_defconfig gcc > powerpc ppa8548_defconfig gcc > powerpc randconfig-001-20231224 gcc > powerpc randconfig-002-20231224 gcc > powerpc randconfig-003-20231224 gcc > powerpc6
Re: [PATCH v4] Bluetooth: Fix for ACL disconnect when pairing fails
On 6/17/14 4:04 PM, Lukasz Rymanowski wrote: > When pairing fails hci_conn refcnt drops below zero. This cause that > ACL link is not disconnected when disconnect timeout fires. > > Probably this is because l2cap_conn_del calls l2cap_chan_del for each > channel, and inside l2cap_chan_del conn is dropped. After that loop > hci_chan_del is called which also drops conn. > > Anyway, as it is desrcibed in hci_core.h, it is known that refcnt > drops below 0 sometimes and it should be fine. If so, let disconnect > link when hci_conn_timeout fires and refcnt is 0 or below. This patch > does it. > > This affects PTS test SM_TC_JW_BV_05_C > > Logs from scenario: > > [69713.706227] [6515] pair_device: > [69713.706230] [6515] hci_conn_add: hci0 dst 00:1b:dc:06:06:22 > [69713.706233] [6515] hci_dev_hold: hci0 orig refcnt 8 > [69713.706235] [6515] hci_conn_init_sysfs: conn 88021f65a000 > [69713.706239] [6515] hci_req_add_ev: hci0 opcode 0x200d plen 25 > [69713.706242] [6515] hci_prepare_cmd: skb len 28 > [69713.706243] [6515] hci_req_run: length 1 > [69713.706248] [6515] hci_conn_hold: hcon 88021f65a000 orig refcnt 0 > [69713.706251] [6515] hci_dev_put: hci0 orig refcnt 9 > [69713.706281] [8909] hci_cmd_work: hci0 cmd_cnt 1 cmd queued 1 > [69713.706288] [8909] hci_send_frame: hci0 type 1 len 28 > [69713.706290] [8909] hci_send_to_monitor: hdev 88021f0c7000 len 28 > [69713.706316] [5949] hci_sock_recvmsg: sock 8800941a9680, sk > 88012bf4d000 > [69713.706382] [5949] hci_sock_recvmsg: sock 8800941a9680, sk > 88012bf4d000 > [69713.711664] [8909] hci_rx_work: hci0 > [69713.711668] [8909] hci_send_to_monitor: hdev 88021f0c7000 len 6 > [69713.711680] [8909] hci_rx_work: hci0 Event packet > [69713.711683] [8909] hci_cs_le_create_conn: hci0 status 0x00 > [69713.711685] [8909] hci_sent_cmd_data: hci0 opcode 0x200d > [69713.711688] [8909] hci_req_cmd_complete: opcode 0x200d status 0x00 > [69713.711690] [8909] hci_sent_cmd_data: hci0 opcode 0x200d > [69713.711695] [5949] hci_sock_recvmsg: sock 8800941a9680, sk > 88012bf4d000 > [69713.711744] [5949] hci_sock_recvmsg: sock 8800941a9680, sk > 88012bf4d000 > [69713.818875] [8909] hci_rx_work: hci0 > [69713.818889] [8909] hci_send_to_monitor: hdev 88021f0c7000 len 21 > [69713.818913] [8909] hci_rx_work: hci0 Event packet > [69713.818917] [8909] hci_le_conn_complete_evt: hci0 status 0x00 > [69713.818922] [8909] hci_send_to_control: len 19 > [69713.818927] [5949] hci_sock_recvmsg: sock 8800941a9680, sk > 88012bf4d000 > [69713.818938] [8909] hci_conn_add_sysfs: conn 88021f65a000 > [69713.818975] [6450] bt_sock_poll: sock 88005e758500, sk 88010323b800 > [69713.818981] [6515] hci_sock_recvmsg: sock 88005e75a080, sk > 88010323ac00 > ... > [69713.819021] [8909] hci_dev_hold: hci0 orig refcnt 10 > [69713.819025] [8909] l2cap_connect_cfm: hcon 88021f65a000 bdaddr > 00:1b:dc:06:06:22 status 0 > [69713.819028] [8909] hci_chan_create: hci0 hcon 88021f65a000 > [69713.819031] [8909] l2cap_conn_add: hcon 88021f65a000 conn > 880221005c00 hchan 88020d60b1c0 > [69713.819034] [8909] l2cap_conn_ready: conn 880221005c00 > [69713.819036] [5949] hci_sock_recvmsg: sock 8800941a9680, sk > 88012bf4d000 > [69713.819037] [8909] smp_conn_security: conn 880221005c00 hcon > 88021f65a000 level 0x02 > [69713.819039] [8909] smp_chan_create: > [69713.819041] [8909] hci_conn_hold: hcon 88021f65a000 orig refcnt 1 > [69713.819043] [8909] smp_send_cmd: code 0x01 > [69713.819045] [8909] hci_send_acl: hci0 chan 88020d60b1c0 flags 0x > [69713.819046] [5949] hci_sock_recvmsg: sock 8800941a9900, sk > 88012bf4e800 > [69713.819049] [8909] hci_queue_acl: hci0 nonfrag skb 88005157c100 len 15 > [69713.819055] [5949] hci_sock_recvmsg: sock 8800941a9900, sk > 88012bf4e800 > [69713.819057] [8909] l2cap_le_conn_ready: > [69713.819064] [8909] l2cap_chan_create: chan 88005ede2c00 > [69713.819066] [8909] l2cap_chan_hold: chan 88005ede2c00 orig refcnt 1 > [69713.819069] [8909] l2cap_sock_init: sk 88005ede5800 > [69713.819072] [8909] bt_accept_enqueue: parent 880160356000, sk > 88005ede5800 > [69713.819074] [8909] __l2cap_chan_add: conn 880221005c00, psm 0x00, dcid > 0x0004 > [69713.819076] [8909] l2cap_chan_hold: chan 88005ede2c00 orig refcnt 2 > [69713.819078] [8909] hci_conn_hold: hcon 88021f65a000 orig refcnt 2 > [69713.819080] [8909] smp_conn_security: conn 880221005c00 hcon > 88021f65a000 level 0x01 > [69713.819082] [8909] l2cap_sock_ready_cb: sk 88005ede5800, parent > 880160356000 > [69713.819086] [8909] le_pairing_complete_cb: status 0 > [69713.819091] [8909] hci_tx_work: hci0 acl 10 sco 8 le 0 > [69713.819093] [8909] hci_sched_acl: hci0 > [69713.819094] [8909] hci_sched_sco: hci0 > [69713.819096] [8909] hci_sched_esco: hci0 > [69713.819098] [8909] hci_sched_le: hci0 > [69713.819099] [8909] hci_chan_sent: hci0 > [69713
re
שלום יקירי, אני פונה אליך למידע שברצוני לחלוק איתך אל תהסס להשיב לפרטים ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
re
שלום יקירתי שמחה להגיע אליך שוב יש לי מייל בעבר ללא תגובה אני מזכיר לגבי חוזה שאני רוצה לשתף אותך חזור אליי לפרטים נוספים אני מחכה אנא ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: media: usbvision: Remove comparision to NULL
Hi Anup,
On 02/05/2023 03:05, Anup Sharma wrote:
> Remove comparison to null in file usbvision-core.c and usbvision-i2c.c.
>
> Signed-off-by: Anup Sharma
> ---
> drivers/staging/media/usbvision/usbvision-core.c | 8
> drivers/staging/media/usbvision/usbvision-i2c.c | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
The usbvision driver has been removed almost 2 years ago, so this patch is for
a really old kernel.
Rather odd, but in any case, I'm rejecting this patch for obvious reasons...
Regards,
Hans
>
> diff --git a/drivers/staging/media/usbvision/usbvision-core.c
> b/drivers/staging/media/usbvision/usbvision-core.c
> index e35dee35b068..a38104b2a0f9 100644
> --- a/drivers/staging/media/usbvision/usbvision-core.c
> +++ b/drivers/staging/media/usbvision/usbvision-core.c
> @@ -349,7 +349,7 @@ int usbvision_scratch_alloc(struct usb_usbvision
> *usbvision)
> {
> usbvision->scratch = vmalloc_32(scratch_buf_size);
> scratch_reset(usbvision);
> - if (usbvision->scratch == NULL) {
> + if (!usbvision->scratch) {
> dev_err(&usbvision->dev->dev,
> "%s: unable to allocate %d bytes for scratch\n",
> __func__, scratch_buf_size);
> @@ -374,7 +374,7 @@ int usbvision_decompress_alloc(struct usb_usbvision
> *usbvision)
> int IFB_size = MAX_FRAME_WIDTH * MAX_FRAME_HEIGHT * 3 / 2;
>
> usbvision->intra_frame_buffer = vmalloc_32(IFB_size);
> - if (usbvision->intra_frame_buffer == NULL) {
> + if (!usbvision->intra_frame_buffer) {
> dev_err(&usbvision->dev->dev,
> "%s: unable to allocate %d for compr. frame buffer\n",
> __func__, IFB_size);
> @@ -2284,7 +2284,7 @@ int usbvision_init_isoc(struct usb_usbvision *usbvision)
> struct urb *urb;
>
> urb = usb_alloc_urb(USBVISION_URB_FRAMES, GFP_KERNEL);
> - if (urb == NULL)
> + if (!urb)
> return -ENOMEM;
> usbvision->sbuf[buf_idx].urb = urb;
> usbvision->sbuf[buf_idx].data =
> @@ -2343,7 +2343,7 @@ void usbvision_stop_isoc(struct usb_usbvision
> *usbvision)
> int buf_idx, err_code, reg_value;
> int sb_size = USBVISION_URB_FRAMES * usbvision->isoc_packet_size;
>
> - if ((usbvision->streaming == stream_off) || (usbvision->dev == NULL))
> + if ((usbvision->streaming == stream_off) || (!usbvision->dev))
> return;
>
> /* Unschedule all of the iso td's */
> diff --git a/drivers/staging/media/usbvision/usbvision-i2c.c
> b/drivers/staging/media/usbvision/usbvision-i2c.c
> index 6e4df3335b1b..3bba93293463 100644
> --- a/drivers/staging/media/usbvision/usbvision-i2c.c
> +++ b/drivers/staging/media/usbvision/usbvision-i2c.c
> @@ -233,7 +233,7 @@ int usbvision_i2c_register(struct usb_usbvision
> *usbvision)
> &usbvision->i2c_adap,
> "tuner", 0, v4l2_i2c_tuner_addrs(type));
>
> - if (sd == NULL)
> + if (!sd)
> return -ENODEV;
> if (usbvision->tuner_type != -1) {
> tun_setup.mode_mask = T_ANALOG_TV | T_RADIO;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4] Add new uio device for PCI with dynamic memory allocation
On Wed, Apr 29, 2020 at 01:53:02PM +, Stahl, Manuel wrote: > On Mi, 2020-04-29 at 11:41 +0200, gre...@linuxfoundation.org wrote: > > On Wed, Apr 29, 2020 at 07:51:01AM +, Stahl, Manuel wrote: > > > On Di, 2020-04-28 at 15:54 +0200, gregkh @ linuxfoundation . org wrote: > > > > On Thu, Apr 16, 2020 at 06:38:30PM +0200, Manuel Stahl wrote: > > > > > > > > > > + * > > > > > + * Since the driver does not declare any device ids, you must > > > > > allocate > > > > > + * id and bind the device to the driver yourself. For example: > > > > > + * > > > > > + * # echo "8086 10f5" > > > > > > /sys/bus/pci/drivers/uio_pci_dmem_genirq/new_id > > > > > + * # echo -n :00:19.0 > /sys/bus/pci/drivers/e1000e/unbind > > > > > + * # echo -n :00:19.0 > > > > > > /sys/bus/pci/drivers/uio_pci_dmem_genirq/bind > > > > > + * # ls -l /sys/bus/pci/devices/:00:19.0/driver > > > > > + * .../:00:19.0/driver -> > > > > > ../../../bus/pci/drivers/uio_pci_dmem_genirq > > > > > + * > > > > > + * Or use a modprobe alias: > > > > > + * # alias pci:v10EEd1000sv*sd*sc*i* uio_pci_dmem_genirq > > > > > + * > > > > > + * Driver won't bind to devices which do not support the Interrupt > > > > > Disable Bit > > > > > + * in the command register. All devices compliant to PCI 2.3 (circa > > > > > 2002) and > > > > > + * all compliant PCI Express devices should support this bit. > > > > > + * > > > > > + * The DMA mask bits and sizes of dynamic regions are derived from > > > > > module > > > > > + * parameters. > > > > > + * > > > > > + * The format for specifying dynamic region sizes in module > > > > > parameters > > > > > + * is as follows: > > > > > + * > > > > > + * uio_pci_dmem_genirq.dmem_sizes := > > > > > [;] > > > > > + *:= :[,] > > > > > + *:= : > > > > > + * := standard linux memsize > > > > > + * > > > > > + * Examples: > > > > > + * > > > > > + * 1) UIO dmem device with 3 dynamic regions: > > > > > + * uio_pci_dmem_genirq.dmem_sizes=8086:10f5:4K,16K,4M > > > > > + * > > > > > + * 2) Two UIO dmem devices with different number of dynamic regions: > > > > > + * uio_pci_dmem_genirq.dmem_sizes=8086:10f5:4K,16K,4M;1234:0001:8K > > > > > > > > Module parameters are horrid, are you sure there is no other way? > > > > > > You're right, seemed to be the simplest solution back when we started > > > developing this driver. I will try to change it to sysfs, so that one can > > > add regions while the module is already loaded. > > > > /me hands you some \n characters... > > > > Anyway, configfs is for configuring stuff, don't make a sysfs file that > > you have to somehow "parse" please. > > Looking back at this driver after some years I realized again the reason > for using kernel parameters: > > The current UIO API needs the information about available memory maps when > registering a new UIO device with __uio_register_device(), which obviously > needs to be called during probe() in uio_pci_dmem_genirq. Otherwise there > is no device file in /dev to open for user space applications. > > After that there is no function to update the uio_map info. So we can either > keep the module parameters and allocate the DMA memory during probe() or > allocate the DMA memory during mmap() and > a) replicate parts of uio_dev_add_attributes() in this driver to update > sysfs > b) add a function in uio.c to allow updates to the uio_map > > Which way would you go? > > Best regards, > Manuel Stahl I have similar need for our FPGA project where DMA to userspace is wanted, how could this be moved forward? Cc'ed my collaborator here. It seems that there is not enough maintainance bandwidth for the UIO driver. I'm willing to be a reviewer, and I assume after handling some of the patches I can manage to do it. I wonder what else should be done. ___ 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 unnecesary parentheses
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?
___
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: [PATCH v6] staging: sm750: Rename sm750_hw_cursor_* functions to snake_case
On mercoledì 29 marzo 2023 13:27:04 CEST Kloudifold wrote:
> sm750 driver has sm750_hw_cursor_* functions, which are named in
> camelcase. Rename them to snake case to follow the function naming
> convention.
>
> - sm750_hw_cursor_setSize => sm750_hw_cursor_set_size
> - sm750_hw_cursor_setPos => sm750_hw_cursor_set_pos
> - sm750_hw_cursor_setColor => sm750_hw_cursor_set_color
> - sm750_hw_cursor_setData => sm750_hw_cursor_set_data
> - sm750_hw_cursor_setData2 => sm750_hw_cursor_set_data2
>
> Reported-by: kernel test robot
> Link:
> https://lore.kernel.org/oe-kbuild-all/202303110849.x24wnhnm-...@intel.com/
Delete the last two lines.
As Greg made you notice, it was not the Kernel Test Robot that had reported
you an issue for which you decided to make a patch to fix it.
The reason you made this patch is because you know that the Linux kernel style
guide wants developers to avoid camel-case symbols.
Before your "Signed-off-by" tag, you should only credit those tools and/or
services (checkpatch.pl, Coccinelle, Smatch, Syzkaller/Syzbot, GCC, Clang, and
so on) that had noticed that Linux has a problem that predates the first
version of your patch and that your first version has the purpose to fix that
problem.
You made this patch because _checkpatch_ had reported issues with camel-case
improper use, so you decided to convert some names to snake-case. You are
invited to credit only _checkpatch_ for you patch ("Reported by
checkpatch.pl.").
That credit is part of the commit message so, when you credit that tool, put a
blank line after the credit and before the "Signed-off-by" tag.
> Signed-off-by: Kloudifold
>
Instead, you should delete this blank line after your sign.
> ---
> Changes in v6:
> - Include missed recipients in v5, no functional change to the code
>
> Changes in v5:
> - Include missed recipients in v4, no functional change to the code
>
> Changes in v4:
> - Update the commit msg (Deepak)
> - Use tabs replace 8 spaces
>
> This v4 patch was prompted by 2 errors, 2 warnings and 1 checks reported
> by the scripts/checkpatch.pl, which detected the style problem.
>
> Changes in v3:
> - Add this changelog (Philipp)
> - Move lkp tags and link to the correct location in commit log (Alison)
> - Update the commit msg (Philip)
> - Update the commit log (Bagas, Julia)
>
> Changes in v2:
> - Use new function names in call sites (LKP)
This is the place to credit the Kernel Test Robot for noticing that you made
mistakes with v1 and that v2 is for fixing them.
Therefore, give credit here to the Robot:
Reported-by: kernel test robot
> Link:
> https://lore.kernel.org/oe-kbuild-all/202303110849.x24wnhnm-...@intel.com/
Thanks,
Fabio
P.S.: Someone suggested to drop the "sm750_" prefix. I don't think you should
do anything like this because I don't see "static" functions prefixed by
"sm750_" in your patch. However, later you may check if they can be "static"
and, if so, drop the prefix and make them "static" (in a follow up patch).
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6] staging: sm750: Rename sm750_hw_cursor_* functions to snake_case
On Wed, 29 Mar 2023 at 19:42, Greg Kroah-Hartman wrote: > > On Wed, Mar 29, 2023 at 07:27:04PM +0800, Kloudifold wrote: > > sm750 driver has sm750_hw_cursor_* functions, which are named in > > camelcase. Rename them to snake case to follow the function naming > > convention. > > > > - sm750_hw_cursor_setSize => sm750_hw_cursor_set_size > > - sm750_hw_cursor_setPos => sm750_hw_cursor_set_pos > > - sm750_hw_cursor_setColor => sm750_hw_cursor_set_color > > - sm750_hw_cursor_setData => sm750_hw_cursor_set_data > > - sm750_hw_cursor_setData2 => sm750_hw_cursor_set_data2 > > > > Reported-by: kernel test robot > > The test robot did not report that the names were incorrect :( > > > Link: > > https://lore.kernel.org/oe-kbuild-all/202303110849.x24wnhnm-...@intel.com/ > > Signed-off-by: Kloudifold > > Is that the name you use to sign documents? Yes. > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6] staging: sm750: Rename sm750_hw_cursor_* functions to snake_case
On Wed, Mar 29, 2023 at 07:27:04PM +0800, Kloudifold wrote: > sm750 driver has sm750_hw_cursor_* functions, which are named in > camelcase. Rename them to snake case to follow the function naming > convention. > > - sm750_hw_cursor_setSize => sm750_hw_cursor_set_size > - sm750_hw_cursor_setPos => sm750_hw_cursor_set_pos > - sm750_hw_cursor_setColor => sm750_hw_cursor_set_color > - sm750_hw_cursor_setData => sm750_hw_cursor_set_data > - sm750_hw_cursor_setData2 => sm750_hw_cursor_set_data2 > > Reported-by: kernel test robot The test robot did not report that the names were incorrect :( > Link: > https://lore.kernel.org/oe-kbuild-all/202303110849.x24wnhnm-...@intel.com/ > Signed-off-by: Kloudifold Is that the name you use to sign documents? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: android: ashmem.c: Declared file operation with const keyword
On Mon, Mar 06, 2023 at 12:30:57AM +0530, Santosh Mahto wrote: > Warning found by checkpatch.pl script. > > Signed-off-by: Santosh Mahto > --- > drivers/staging/android/ashmem.c | 2 +- What kernel did you make this against? This is not in my tree anymore. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [driver-core:driver-core-testing 77/77] drivers/base/base.h:221:63: error: void function 'devtmpfs_delete_node' should not return a value
On Fri, Feb 10, 2023 at 11:38:45PM +0800, kernel test robot wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> driver-core-testing
> head: ecfd9f08fe2ef7616477c089dce1b0f05dcee13c
> commit: ecfd9f08fe2ef7616477c089dce1b0f05dcee13c [77/77] devtmpfs: remove
> return value of devtmpfs_delete_node()
> config: arm-randconfig-r006-20230210
> (https://download.01.org/0day-ci/archive/20230210/202302102345.uqfdskhw-...@intel.com/config)
> compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project
> db0e6591612b53910a1b366863348bdb9d7d2fb1)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install arm cross compiling tool for clang build
> # apt-get install binutils-arm-linux-gnueabi
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=ecfd9f08fe2ef7616477c089dce1b0f05dcee13c
> git remote add driver-core
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> git fetch --no-tags driver-core driver-core-testing
> git checkout ecfd9f08fe2ef7616477c089dce1b0f05dcee13c
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> O=build_dir ARCH=arm olddefconfig
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> O=build_dir ARCH=arm SHELL=/bin/bash drivers/
>
> If you fix the issue, kindly add following tag where applicable
> | Reported-by: kernel test robot
> | Link:
> https://lore.kernel.org/oe-kbuild-all/202302102345.uqfdskhw-...@intel.com/
>
> All errors (new ones prefixed by >>):
>
>In file included from drivers/base/core.c:35:
> >> drivers/base/base.h:221:63: error: void function 'devtmpfs_delete_node'
> >> should not return a value [-Wreturn-type]
>static inline void devtmpfs_delete_node(struct device *dev) { return 0; }
> ^ ~
>1 error generated.
I've fixed this up by hand by modifying the original commit and pushing
out an update. No need for a separate patch.
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re
-- I'm Jeff Bezos, The CEO of Amazon, it's on this note that I'm informing the world of my intention to give out my Fortune of $124 Billion of my wealth to the lucky ones around the country and world at large. Your email was randomly selected to be a part of the people who will be beneficiaries of this charity project. each person would be awarded $520,000,00. (https://www.cnbc.com/amp/2022/11/14/jeff-bezos-says-he-plans-to-give-away-most-of-his-124-billion-fortune.html) Contact the Agent on how to proceed. Email: deborahjennings...@gmail.com My Best Regards.. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [driver-core:debugfs_lookup_fix] [mm/damon/dbgfs] ff25f87cfc: kernel_BUG_at_lib/list_debug.c
On Thu, 5 Jan 2023 10:53:57 +0100 Greg Kroah-Hartman
wrote:
> On Wed, Jan 04, 2023 at 06:35:39PM +, SeongJae Park wrote:
> > Hello,
> >
> > On Tue, 3 Jan 2023 21:16:09 +0800 kernel test robot
> > wrote:
> >
> > > [-- Attachment #1: Type: text/plain, Size: 7528 bytes --]
> > >
> > >
> > > Greeting,
> > >
> > > FYI, we noticed kernel_BUG_at_lib/list_debug.c due to commit (built with
> > > gcc-11):
> >
> > Thank you for the report!
> >
> > >
> > > commit: ff25f87cfcfc34ebe652987f2a7beb184762785b ("mm/damon/dbgfs: fix
> > > memory leak when using debugfs_lookup()")
> > > https://git.kernel.org/cgit/linux/kernel/git/gregkh/driver-core.git
> > > debugfs_lookup_fix
> >
> > The commit is for fixing a memory leak due to missed dput() call. The patch
> > has posted originally by Greg and revised my I[1]. The revised version has
> > merged in mainline during v6.0 stabilization period (1552fd3ef7db).
> >
> > The problematic tree (driver-core/debugfs_lookup_fix) is based on v6.2-rc2,
> > so
> > the revised patch is already applied. But the first version of the patch is
> > applied again on the tree[2], probably by mistake, and caused double
> > 'dput()'.
> >
> > So I think the commit seems needs to be reverted.
> >
> > If there is anything I missed or wrong, please let me know.
> >
> > [1] https://lore.kernel.org/damon/20220902191149.112434-1...@kernel.org/
> > [2]
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=debugfs_lookup_fix&id=5167d3e8149e332204274910da1057e8f907d7d2
>
> Yeah, this is my fault, sorry. That branch/tree has not been looked at
> carefully in a while, I need to refresh it properly and verify it all is
> correct. I'll drop this change as part of that work as well, sorry for
> the noise.
No problem, I'm glad to help! :)
Thanks,
SJ
>
> greg k-h
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [driver-core:debugfs_lookup_fix] [mm/damon/dbgfs] ff25f87cfc: kernel_BUG_at_lib/list_debug.c
On Wed, Jan 04, 2023 at 06:35:39PM +, SeongJae Park wrote:
> Hello,
>
> On Tue, 3 Jan 2023 21:16:09 +0800 kernel test robot
> wrote:
>
> > [-- Attachment #1: Type: text/plain, Size: 7528 bytes --]
> >
> >
> > Greeting,
> >
> > FYI, we noticed kernel_BUG_at_lib/list_debug.c due to commit (built with
> > gcc-11):
>
> Thank you for the report!
>
> >
> > commit: ff25f87cfcfc34ebe652987f2a7beb184762785b ("mm/damon/dbgfs: fix
> > memory leak when using debugfs_lookup()")
> > https://git.kernel.org/cgit/linux/kernel/git/gregkh/driver-core.git
> > debugfs_lookup_fix
>
> The commit is for fixing a memory leak due to missed dput() call. The patch
> has posted originally by Greg and revised my I[1]. The revised version has
> merged in mainline during v6.0 stabilization period (1552fd3ef7db).
>
> The problematic tree (driver-core/debugfs_lookup_fix) is based on v6.2-rc2, so
> the revised patch is already applied. But the first version of the patch is
> applied again on the tree[2], probably by mistake, and caused double 'dput()'.
>
> So I think the commit seems needs to be reverted.
>
> If there is anything I missed or wrong, please let me know.
>
> [1] https://lore.kernel.org/damon/20220902191149.112434-1...@kernel.org/
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=debugfs_lookup_fix&id=5167d3e8149e332204274910da1057e8f907d7d2
Yeah, this is my fault, sorry. That branch/tree has not been looked at
carefully in a while, I need to refresh it properly and verify it all is
correct. I'll drop this change as part of that work as well, sorry for
the noise.
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [driver-core:debugfs_lookup_fix] [mm/damon/dbgfs] ff25f87cfc: kernel_BUG_at_lib/list_debug.c
Hello,
On Tue, 3 Jan 2023 21:16:09 +0800 kernel test robot
wrote:
> [-- Attachment #1: Type: text/plain, Size: 7528 bytes --]
>
>
> Greeting,
>
> FYI, we noticed kernel_BUG_at_lib/list_debug.c due to commit (built with
> gcc-11):
Thank you for the report!
>
> commit: ff25f87cfcfc34ebe652987f2a7beb184762785b ("mm/damon/dbgfs: fix memory
> leak when using debugfs_lookup()")
> https://git.kernel.org/cgit/linux/kernel/git/gregkh/driver-core.git
> debugfs_lookup_fix
The commit is for fixing a memory leak due to missed dput() call. The patch
has posted originally by Greg and revised my I[1]. The revised version has
merged in mainline during v6.0 stabilization period (1552fd3ef7db).
The problematic tree (driver-core/debugfs_lookup_fix) is based on v6.2-rc2, so
the revised patch is already applied. But the first version of the patch is
applied again on the tree[2], probably by mistake, and caused double 'dput()'.
So I think the commit seems needs to be reverted.
If there is anything I missed or wrong, please let me know.
[1] https://lore.kernel.org/damon/20220902191149.112434-1...@kernel.org/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=debugfs_lookup_fix&id=5167d3e8149e332204274910da1057e8f907d7d2
Thanks,
SJ
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/1] binder: return pending info for frozen async txns
On Wed, Nov 23, 2022 at 12:16:54PM -0800, Li Li wrote:
> From: Li Li
>
> An async transaction to a frozen process will still be successfully
> put in the queue. But this pending async transaction won't be processed
> until the target process is unfrozen at an unspecified time in the
> future. Pass this important information back to the user space caller
> by returning BR_TRANSACTION_PENDING_FROZEN.
>
> Signed-off-by: Li Li
> ---
> drivers/android/binder.c| 32 +++--
> drivers/android/binder_internal.h | 3 ++-
> include/uapi/linux/android/binder.h | 7 ++-
> 3 files changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 880224ec6abb..acd53147d5d1 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -2728,7 +2728,10 @@ binder_find_outdated_transaction_ilocked(struct
> binder_transaction *t,
> *
> * Return: 0 if the transaction was successfully queued
> * BR_DEAD_REPLY if the target process or thread is dead
> - * BR_FROZEN_REPLY if the target process or thread is frozen
> + * BR_FROZEN_REPLY if the target process or thread is frozen and
> + * the sync transaction was rejected
> + * BR_TRANSACTION_PENDING_FROZEN if the target process is frozen
> + * and the async transaction was successfully queued
> */
> static int binder_proc_transaction(struct binder_transaction *t,
> struct binder_proc *proc,
> @@ -2738,6 +2741,7 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> bool oneway = !!(t->flags & TF_ONE_WAY);
> bool pending_async = false;
> struct binder_transaction *t_outdated = NULL;
> + bool frozen = false;
>
> BUG_ON(!node);
> binder_node_lock(node);
> @@ -2751,15 +2755,16 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
>
> binder_inner_proc_lock(proc);
> if (proc->is_frozen) {
> + frozen = true;
> proc->sync_recv |= !oneway;
> proc->async_recv |= oneway;
> }
>
> - if ((proc->is_frozen && !oneway) || proc->is_dead ||
> + if ((frozen && !oneway) || proc->is_dead ||
> (thread && thread->is_dead)) {
> binder_inner_proc_unlock(proc);
> binder_node_unlock(node);
> - return proc->is_frozen ? BR_FROZEN_REPLY : BR_DEAD_REPLY;
> + return frozen ? BR_FROZEN_REPLY : BR_DEAD_REPLY;
> }
>
> if (!thread && !pending_async)
> @@ -2770,7 +2775,7 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> } else if (!pending_async) {
> binder_enqueue_work_ilocked(&t->work, &proc->todo);
> } else {
> - if ((t->flags & TF_UPDATE_TXN) && proc->is_frozen) {
> + if ((t->flags & TF_UPDATE_TXN) && frozen) {
> t_outdated = binder_find_outdated_transaction_ilocked(t,
>
> &node->async_todo);
> if (t_outdated) {
> @@ -2807,6 +2812,9 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> binder_stats_deleted(BINDER_STAT_TRANSACTION);
> }
>
> + if (oneway && frozen)
> + return BR_TRANSACTION_PENDING_FROZEN;
> +
> return 0;
> }
>
> @@ -3607,9 +3615,17 @@ static void binder_transaction(struct binder_proc
> *proc,
> } else {
> BUG_ON(target_node == NULL);
> BUG_ON(t->buffer->async_transaction != 1);
> - binder_enqueue_thread_work(thread, tcomplete);
> return_error = binder_proc_transaction(t, target_proc, NULL);
> - if (return_error)
> + /*
> + * Let the caller know when async transaction reaches a frozen
> + * process and is put in a pending queue, waiting for the target
> + * process to be unfrozen.
> + */
> + if (return_error == BR_TRANSACTION_PENDING_FROZEN)
> + tcomplete->type = BINDER_WORK_TRANSACTION_PENDING;
> + binder_enqueue_thread_work(thread, tcomplete);
> + if (return_error &&
> + return_error != BR_TRANSACTION_PENDING_FROZEN)
> goto err_dead_proc_or_thread;
> }
> if (target_thread)
> @@ -4440,10 +4456,13 @@ static int binder_thread_read(struct binder_proc
> *proc,
> binder_stat_br(proc, thread, cmd);
> } break;
> case BINDER_WORK_TRANSACTION_COMPLETE:
> + case BINDER_WORK_TRANSACTION_PENDING:
> case BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT: {
> if (proc->oneway_spam_detection_enabled &&
> w->type ==
> BINDER_WORK_TRANSACTION_ON
Re: [PATCH v2 1/1] binder: return pending info for frozen async txns
On Wed, Nov 23, 2022 at 10:58 AM Carlos Llamas wrote: > > This looks good. Could you rename the new op to signify the frozen > scenario though? We might have some other instances of pending > transactions in the future so might as well be specific here. Done [1]. v3: rename BR_TRANSACTION_PENDING to BR_TRANSACTION_PENDING_FROZEN to signify the frozen scenario and avoid potential confusion [1] https://lkml.org/lkml/2022/11/23/1472 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/1] binder: return pending info for frozen async txns
On Thu, Nov 10, 2022 at 12:34:05PM -0800, Li Li wrote:
> From: Li Li
>
> An async transaction to a frozen process will still be successfully
> put in the queue. But this pending async transaction won't be processed
> until the target process is unfrozen at an unspecified time in the
> future. Pass this important information back to the user space caller
> by returning BR_TRANSACTION_PENDING.
>
> Signed-off-by: Li Li
> ---
> drivers/android/binder.c| 31 +++--
> drivers/android/binder_internal.h | 3 ++-
> include/uapi/linux/android/binder.h | 7 ++-
> 3 files changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 880224ec6abb..a798f6661488 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -2728,7 +2728,10 @@ binder_find_outdated_transaction_ilocked(struct
> binder_transaction *t,
> *
> * Return: 0 if the transaction was successfully queued
> * BR_DEAD_REPLY if the target process or thread is dead
> - * BR_FROZEN_REPLY if the target process or thread is frozen
> + * BR_FROZEN_REPLY if the target process or thread is frozen and
> + * the sync transaction was rejected
> + * BR_TRANSACTION_PENDING if the target process is frozen and the
> + * async transaction was successfully queued
> */
> static int binder_proc_transaction(struct binder_transaction *t,
> struct binder_proc *proc,
> @@ -2738,6 +2741,7 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> bool oneway = !!(t->flags & TF_ONE_WAY);
> bool pending_async = false;
> struct binder_transaction *t_outdated = NULL;
> + bool frozen = false;
>
> BUG_ON(!node);
> binder_node_lock(node);
> @@ -2751,15 +2755,16 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
>
> binder_inner_proc_lock(proc);
> if (proc->is_frozen) {
> + frozen = true;
> proc->sync_recv |= !oneway;
> proc->async_recv |= oneway;
> }
>
> - if ((proc->is_frozen && !oneway) || proc->is_dead ||
> + if ((frozen && !oneway) || proc->is_dead ||
> (thread && thread->is_dead)) {
> binder_inner_proc_unlock(proc);
> binder_node_unlock(node);
> - return proc->is_frozen ? BR_FROZEN_REPLY : BR_DEAD_REPLY;
> + return frozen ? BR_FROZEN_REPLY : BR_DEAD_REPLY;
> }
>
> if (!thread && !pending_async)
> @@ -2770,7 +2775,7 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> } else if (!pending_async) {
> binder_enqueue_work_ilocked(&t->work, &proc->todo);
> } else {
> - if ((t->flags & TF_UPDATE_TXN) && proc->is_frozen) {
> + if ((t->flags & TF_UPDATE_TXN) && frozen) {
> t_outdated = binder_find_outdated_transaction_ilocked(t,
>
> &node->async_todo);
> if (t_outdated) {
> @@ -2807,6 +2812,9 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> binder_stats_deleted(BINDER_STAT_TRANSACTION);
> }
>
> + if (oneway && frozen)
> + return BR_TRANSACTION_PENDING;
> +
> return 0;
> }
>
> @@ -3607,9 +3615,16 @@ static void binder_transaction(struct binder_proc
> *proc,
> } else {
> BUG_ON(target_node == NULL);
> BUG_ON(t->buffer->async_transaction != 1);
> - binder_enqueue_thread_work(thread, tcomplete);
> return_error = binder_proc_transaction(t, target_proc, NULL);
> - if (return_error)
> + /*
> + * Let the caller know when async transaction reaches a frozen
> + * process and is put in a pending queue, waiting for the target
> + * process to be unfrozen.
> + */
> + if (return_error == BR_TRANSACTION_PENDING)
> + tcomplete->type = BINDER_WORK_TRANSACTION_PENDING;
> + binder_enqueue_thread_work(thread, tcomplete);
> + if (return_error && return_error != BR_TRANSACTION_PENDING)
> goto err_dead_proc_or_thread;
> }
> if (target_thread)
> @@ -4440,10 +4455,13 @@ static int binder_thread_read(struct binder_proc
> *proc,
> binder_stat_br(proc, thread, cmd);
> } break;
> case BINDER_WORK_TRANSACTION_COMPLETE:
> + case BINDER_WORK_TRANSACTION_PENDING:
> case BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT: {
> if (proc->oneway_spam_detection_enabled &&
> w->type ==
> BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT)
>
Re: [PATCH v1 1/1] binder: return pending info for frozen async txns
On Wed, Nov 9, 2022 at 2:43 PM Carlos Llamas wrote:
>
> On Thu, Nov 03, 2022 at 12:05:49PM -0700, Li Li wrote:
> > From: Li Li
> >
> > An async transaction to a frozen process will still be successsfully
>
> nit: sucessfully typo
Nice catch! Will remove the extra 's' in v2.
>
> > put in the queue. But this pending async transaction won't be processed
> > until the target process is unfrozen at an unspecified time in the
> > future. Pass this important information back to the user space caller
> > by returning BR_TRANSACTION_PENDING.
> >
> > Signed-off-by: Li Li
> > ---
> > drivers/android/binder.c| 23 ---
> > drivers/android/binder_internal.h | 3 ++-
> > include/uapi/linux/android/binder.h | 7 ++-
> > 3 files changed, 28 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> > index 880224ec6abb..a097b89f6a7a 100644
> > --- a/drivers/android/binder.c
> > +++ b/drivers/android/binder.c
> > @@ -2728,7 +2728,10 @@ binder_find_outdated_transaction_ilocked(struct
> > binder_transaction *t,
> > *
> > * Return: 0 if the transaction was successfully queued
> > * BR_DEAD_REPLY if the target process or thread is dead
> > - * BR_FROZEN_REPLY if the target process or thread is frozen
> > + * BR_FROZEN_REPLY if the target process or thread is frozen and
> > + * the sync transaction was rejected
> > + * BR_TRANSACTION_PENDING if the target process is frozen and the
> > + * async transaction was successfully queued
> > */
> > static int binder_proc_transaction(struct binder_transaction *t,
> > struct binder_proc *proc,
> > @@ -2807,6 +2810,9 @@ static int binder_proc_transaction(struct
> > binder_transaction *t,
> > binder_stats_deleted(BINDER_STAT_TRANSACTION);
> > }
> >
> > + if (oneway && proc->is_frozen)
>
> Do you need the inner lock here for proc->is_frozen?
You're right. I'll add a new local variable and set it between the existing
binder_inner_proc_lock() and binder_inner_proc_unlock().
>
> > + return BR_TRANSACTION_PENDING;
> > +
> > return 0;
> > }
> >
> > @@ -3607,9 +3613,16 @@ static void binder_transaction(struct binder_proc
> > *proc,
> > } else {
> > BUG_ON(target_node == NULL);
> > BUG_ON(t->buffer->async_transaction != 1);
> > - binder_enqueue_thread_work(thread, tcomplete);
> > return_error = binder_proc_transaction(t, target_proc, NULL);
> > - if (return_error)
> > + /*
> > + * Let the caller know its async transaction reaches a frozen
>
> nit: I believe you meant s/its/when or similar?
Will change it in v2. Thanks!
>
> > + * process and is put in a pending queue, waiting for the
> > target
> > + * process to be unfrozen.
> > + */
> > + if (return_error == BR_TRANSACTION_PENDING)
> > + tcomplete->type = BINDER_WORK_TRANSACTION_PENDING;
> > + binder_enqueue_thread_work(thread, tcomplete);
>
> I wonder if switching the order of queuing the tcomplete here and waking
> up the target thread inside binder_proc_transaction() will have any
> performance implications if this task gets scheduled out.
Eventually the sender has to wait this whole function finish and then
call another
ioctl to actually read tcomplete back. If this task gets cheduled out,
it won't have
a chance to perform that reading operation even without this change. So there's
no difference.
>
> > + if (return_error && return_error != BR_TRANSACTION_PENDING)
> > goto err_dead_proc_or_thread;
> > }
> > if (target_thread)
> > @@ -4440,10 +4453,13 @@ static int binder_thread_read(struct binder_proc
> > *proc,
> > binder_stat_br(proc, thread, cmd);
> > } break;
> > case BINDER_WORK_TRANSACTION_COMPLETE:
> > + case BINDER_WORK_TRANSACTION_PENDING:
> > case BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT: {
> > if (proc->oneway_spam_detection_enabled &&
> > w->type ==
> > BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT)
> > cmd = BR_ONEWAY_SPAM_SUSPECT;
> > + else if (w->type == BINDER_WORK_TRANSACTION_PENDING)
> > + cmd = BR_TRANSACTION_PENDING;
> > else
> > cmd = BR_TRANSACTION_COMPLETE;
> > binder_inner_proc_unlock(proc);
> > @@ -6170,6 +6186,7 @@ static const char * const binder_return_strings[] = {
> > "BR_FAILED_REPLY",
> > "BR_FROZEN_REPLY",
> > "BR_ONEWAY_SPAM_SUSPECT",
> > + "BR_TRANSACTION_PENDING"
> > };
> >
> > static const char * const binder_command_str
Re: [PATCH v1 1/1] binder: return pending info for frozen async txns
On Thu, Nov 03, 2022 at 12:05:49PM -0700, Li Li wrote:
> From: Li Li
>
> An async transaction to a frozen process will still be successsfully
nit: sucessfully typo
> put in the queue. But this pending async transaction won't be processed
> until the target process is unfrozen at an unspecified time in the
> future. Pass this important information back to the user space caller
> by returning BR_TRANSACTION_PENDING.
>
> Signed-off-by: Li Li
> ---
> drivers/android/binder.c| 23 ---
> drivers/android/binder_internal.h | 3 ++-
> include/uapi/linux/android/binder.h | 7 ++-
> 3 files changed, 28 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index 880224ec6abb..a097b89f6a7a 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -2728,7 +2728,10 @@ binder_find_outdated_transaction_ilocked(struct
> binder_transaction *t,
> *
> * Return: 0 if the transaction was successfully queued
> * BR_DEAD_REPLY if the target process or thread is dead
> - * BR_FROZEN_REPLY if the target process or thread is frozen
> + * BR_FROZEN_REPLY if the target process or thread is frozen and
> + * the sync transaction was rejected
> + * BR_TRANSACTION_PENDING if the target process is frozen and the
> + * async transaction was successfully queued
> */
> static int binder_proc_transaction(struct binder_transaction *t,
> struct binder_proc *proc,
> @@ -2807,6 +2810,9 @@ static int binder_proc_transaction(struct
> binder_transaction *t,
> binder_stats_deleted(BINDER_STAT_TRANSACTION);
> }
>
> + if (oneway && proc->is_frozen)
Do you need the inner lock here for proc->is_frozen?
> + return BR_TRANSACTION_PENDING;
> +
> return 0;
> }
>
> @@ -3607,9 +3613,16 @@ static void binder_transaction(struct binder_proc
> *proc,
> } else {
> BUG_ON(target_node == NULL);
> BUG_ON(t->buffer->async_transaction != 1);
> - binder_enqueue_thread_work(thread, tcomplete);
> return_error = binder_proc_transaction(t, target_proc, NULL);
> - if (return_error)
> + /*
> + * Let the caller know its async transaction reaches a frozen
nit: I believe you meant s/its/when or similar?
> + * process and is put in a pending queue, waiting for the target
> + * process to be unfrozen.
> + */
> + if (return_error == BR_TRANSACTION_PENDING)
> + tcomplete->type = BINDER_WORK_TRANSACTION_PENDING;
> + binder_enqueue_thread_work(thread, tcomplete);
I wonder if switching the order of queuing the tcomplete here and waking
up the target thread inside binder_proc_transaction() will have any
performance implications if this task gets scheduled out.
> + if (return_error && return_error != BR_TRANSACTION_PENDING)
> goto err_dead_proc_or_thread;
> }
> if (target_thread)
> @@ -4440,10 +4453,13 @@ static int binder_thread_read(struct binder_proc
> *proc,
> binder_stat_br(proc, thread, cmd);
> } break;
> case BINDER_WORK_TRANSACTION_COMPLETE:
> + case BINDER_WORK_TRANSACTION_PENDING:
> case BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT: {
> if (proc->oneway_spam_detection_enabled &&
> w->type ==
> BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT)
> cmd = BR_ONEWAY_SPAM_SUSPECT;
> + else if (w->type == BINDER_WORK_TRANSACTION_PENDING)
> + cmd = BR_TRANSACTION_PENDING;
> else
> cmd = BR_TRANSACTION_COMPLETE;
> binder_inner_proc_unlock(proc);
> @@ -6170,6 +6186,7 @@ static const char * const binder_return_strings[] = {
> "BR_FAILED_REPLY",
> "BR_FROZEN_REPLY",
> "BR_ONEWAY_SPAM_SUSPECT",
> + "BR_TRANSACTION_PENDING"
> };
>
> static const char * const binder_command_strings[] = {
> diff --git a/drivers/android/binder_internal.h
> b/drivers/android/binder_internal.h
> index abe19d88c6ec..6c51325a826f 100644
> --- a/drivers/android/binder_internal.h
> +++ b/drivers/android/binder_internal.h
> @@ -133,7 +133,7 @@ enum binder_stat_types {
> };
>
> struct binder_stats {
> - atomic_t br[_IOC_NR(BR_ONEWAY_SPAM_SUSPECT) + 1];
> + atomic_t br[_IOC_NR(BR_TRANSACTION_PENDING) + 1];
> atomic_t bc[_IOC_NR(BC_REPLY_SG) + 1];
> atomic_t obj_created[BINDER_STAT_COUNT];
> atomic_t obj_deleted[BINDER_STAT_COUNT];
> @@ -152,6 +152,7 @@ struct binder_work {
> enum binder_work_type {
> BINDER_WORK_TRANSACTION = 1,
> BINDER_WORK_TRANSACTIO
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
Aw: Re: Verificar PI adjunto
Dios morgón, Vänligen bekräfta om priserna i bifogade PI fortfarande är identiska med de du nämnde i septiembre. Ursäkta den långa förseningen, eftersom vi väntar på bekräftelse från vår kund. Ange följande i ditt svar 1. Betalning 2. Leverántida 3. Tillgänglighet av föremål Tack och lyckönskningar, García Carlos<> <> ___ 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: [PATCH] usb: Improves USB2.0 write performance
On Tue, Aug 30, 2022 at 04:43:25PM +0800, Hu Xiaoying wrote: > USB external storage device(0x0b05:1932), use gnome-disk-utility tools > to test usb write < 30MB/s. if does not to load module of uas for this device > , can increase the write speed from 20MB/s to more than 40MB/s. > > Signed-off-by: Hu Xiaoying This email address "@gmail.com" is different from the address you used when you submitted the patch "@kylinos.cn". The two addresses must be the same. > --- You should put here (just after the "---" line) a description of how this patch version is different from all the earlier versions. Do that and submit it as [PATCH v4], and make sure you explain how it is different from versions 1, 2, and 3. There are lots of examples of patches like this in the mailing list archives. Look at some of them to see what they do. Alan Stern > drivers/usb/storage/unusual_uas.h | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/usb/storage/unusual_uas.h > b/drivers/usb/storage/unusual_uas.h > index 4051c8cd0cd8..3925c7c67915 100644 > --- a/drivers/usb/storage/unusual_uas.h > +++ b/drivers/usb/storage/unusual_uas.h > @@ -62,6 +62,13 @@ UNUSUAL_DEV(0x0984, 0x0301, 0x0128, 0x0128, > USB_SC_DEVICE, USB_PR_DEVICE, NULL, > US_FL_IGNORE_UAS), > > +/* Reported-by: Tom Hu */ > +UNUSUAL_DEV(0x0b05, 0x1932, 0x, 0x, > + "ASUS", > + "External HDD", > + USB_SC_DEVICE, USB_PR_DEVICE, NULL, > + US_FL_IGNORE_UAS), > + > /* Reported-by: David Webb */ > UNUSUAL_DEV(0x0bc2, 0x331a, 0x, 0x, > "Seagate", > -- > 2.25.1 > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: HELLO DEAR
Hallo, Sie haben meine vorherige Nachricht erhalten? Ich habe Sie schon einmal kontaktiert, aber die Nachricht ist fehlgeschlagen, also habe ich beschlossen, noch einmal zu schreiben. Bitte bestätigen Sie, ob Sie dies erhalten, damit ich fortfahren kann. warte auf deine Antwort. Grüße, Fräulein Reachal ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: Your Inheritance Fund !!!
Hello You are the next of kin to our late Singapore Gold Merchant worth 30 Million Dollars. Reply for more information. Ms.Sheema Khaja Waheed Uddin ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: IMTS Attendees Email List-2022
Hi, I hope you're doing great and staying healthy! Would you be interested in acquiring IMTS Attendees Data List 2022? List contains: Company Name, Contact Name, First Name, Middle Name, Last Name, Title, Address, Street, City, Zip code, State, Country, Telephone, Email address and more, No of Contacts:- 16,028 Cost: $ 1,684 Looking forward for your response, Kind Regards, Hannah Roger Marketing Coordinator ___ 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;
Hello Dear, My apologies for the unconventional contact, though it's for good purpose. My name is Ms Jacquelyn Mitchard, a banker by profession. I am contacting you to repatriate a huge sum of money deposited by our deceased customer who happens to have the same last name as you. For over five years the fund was without claim because the deceased died with the family in the auto crash incident. Now all the effort the bank made to locate the deceased family through his embassy was abortive . So I contact you to make this deal with you because it will be very easy for the bank to pay you the money as the deceased next of kin , hence you have the same last name as him, because this is legal. For more information to execute this deal, reply to my private email ( ms.jacquelyn...@hotmail.com ) Thanks Always Yours Ms Jacquelyn Mitchard ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: Mutual Investment Proposal
Good Day, My name is Luis Fernandez, I am contacting you because we have investors that have the capacity to invest in any massive project in your country or invest in your existing project that requires funding. Kindly get back to me for more details. Best Regards, Luis Fernandez ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Business Partnership
-- Dear Sir/ Madam My name is James Donald I am from Burkina Faso a minister here is interested to invest in your country , he confide on me to look for trust worthy person who is capable to partner with him to realize his investment plan with ( USD. $35.5 Million ) He has an investment interest in Mining, Exotic Properties for Commercial/Residential and Development Properties, Hotels and any other viable investment opportunities in your country based on your recommendation, will be highly welcomed. Please if you are willing Kindly Reply to me In my Confidential Email Address ( jamesdonalda...@gmail.com ) For The Confidentiality Of This Proposal.I will Give You The Complete Details How We Shall Proceed. 1.Full name: 2.Country: 3.Private cell phone: 4.Occupation: 5. Age Your co-operation is highly needed to achieve this investment project. I wait for your prompt response. May Almighty God Bless You! Thanks and best regards, Mr.James Donald ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Business Partnership
-- Dear Sir/ Madam My name is James Donald I am from Burkina Faso a minister here is interested to invest in your country , he confide on me to look for trust worthy person who is capable to partner with him to realize his investment plan with ( USD. $35.5 Million ) He has an investment interest in Mining, Exotic Properties for Commercial/Residential and Development Properties, Hotels and any other viable investment opportunities in your country based on your recommendation, will be highly welcomed. Your co-operation is highly needed to achieve this investment project. I wait for your prompt response. May Almighty God Bless You! Thanks and best regards, Mr.James Donald ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 54/54] drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false
On Sat, Jul 30, 2022 at 01:08:23PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Jul 30, 2022 at 04:14:57PM +0800, kernel test robot wrote:
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> > staging-testing
> > head: f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> > commit: f3a76018dd55d8ddcd28cb47049f46ae5c0ce557 [54/54] staging: r8188eu:
> > remove initializer from ret in rtw_pwr_wakeup
> > config: hexagon-randconfig-r015-20220729
> > (https://download.01.org/0day-ci/archive/20220730/202207301623.bfmklfhv-...@intel.com/config)
> > compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project
> > 52cd00cabf479aa7eb6dbb063b7ba41ea57bce9e)
> > reproduce (this is a W=1 build):
> > wget
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > #
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?id=f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> > git remote add staging
> > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> > git fetch --no-tags staging staging-testing
> > git checkout f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> > # save the config file
> > mkdir build_dir && cp config build_dir/.config
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> > O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/staging/r8188eu/
> >
> > If you fix the issue, kindly add following tag where applicable
> > Reported-by: kernel test robot
> >
> > All warnings (new ones prefixed by >>):
> >
> > >> drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:6: warning: variable
> > >> 'ret' is used uninitialized whenever 'if' condition is false
> > >> [-Wsometimes-uninitialized]
> >if (padapter->bDriverStopped || !padapter->bup ||
> > !padapter->hw_init_completed) {
> >
> > ^~
> >drivers/staging/r8188eu/core/rtw_pwrctrl.c:409:9: note: uninitialized
> > use occurs here
> >return ret;
> > ^~~
> >drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:2: note: remove the 'if'
> > if its condition is always true
> >if (padapter->bDriverStopped || !padapter->bup ||
> > !padapter->hw_init_completed) {
> >
> > ^~~~
> >drivers/staging/r8188eu/core/rtw_pwrctrl.c:384:9: note: initialize the
> > variable 'ret' to silence this warning
> >int ret;
> > ^
> >= 0
> >1 warning generated.
>
> Phillip, can you send a follow-up patch for this issue?
>
> thanks,
>
> greg k-h
Yes, of course. It will be a few hours though if that's ok - I've had
to pop out to send this as someone decided to steal some telecoms cabling,
thus knocking out DSL for us and three neighbouring towns :-)
Regards,
Phil
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 54/54] drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:6: warning: variable 'ret' is used uninitialized whenever 'if' condition is false
On Sat, Jul 30, 2022 at 04:14:57PM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> staging-testing
> head: f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> commit: f3a76018dd55d8ddcd28cb47049f46ae5c0ce557 [54/54] staging: r8188eu:
> remove initializer from ret in rtw_pwr_wakeup
> config: hexagon-randconfig-r015-20220729
> (https://download.01.org/0day-ci/archive/20220730/202207301623.bfmklfhv-...@intel.com/config)
> compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project
> 52cd00cabf479aa7eb6dbb063b7ba41ea57bce9e)
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?id=f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> git remote add staging
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> git fetch --no-tags staging staging-testing
> git checkout f3a76018dd55d8ddcd28cb47049f46ae5c0ce557
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
> O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/staging/r8188eu/
>
> If you fix the issue, kindly add following tag where applicable
> Reported-by: kernel test robot
>
> All warnings (new ones prefixed by >>):
>
> >> drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:6: warning: variable 'ret'
> >> is used uninitialized whenever 'if' condition is false
> >> [-Wsometimes-uninitialized]
>if (padapter->bDriverStopped || !padapter->bup ||
> !padapter->hw_init_completed) {
>
> ^~
>drivers/staging/r8188eu/core/rtw_pwrctrl.c:409:9: note: uninitialized use
> occurs here
>return ret;
> ^~~
>drivers/staging/r8188eu/core/rtw_pwrctrl.c:400:2: note: remove the 'if' if
> its condition is always true
>if (padapter->bDriverStopped || !padapter->bup ||
> !padapter->hw_init_completed) {
>
> ^~~~
>drivers/staging/r8188eu/core/rtw_pwrctrl.c:384:9: note: initialize the
> variable 'ret' to silence this warning
>int ret;
> ^
>= 0
>1 warning generated.
Phillip, can you send a follow-up patch for this issue?
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Bank Of America New York-Service Support,
-BANK OF AMERICA NEW YORK HEAD OFFICE, THIS IS TO LET YOU KNOW THAT WORLD BANK GROUP’S BOARD OF EXECUTIVE DIRECTORS HAS REOPENED OUR SERVICES TO BENEFICIARIES ON A PROJECT TO PROVIDE CASH SUPPORT TO 270,000 VULNERABLE HOUSEHOLDS UNIT INCLUDING THOSE WHO RECENTLY LOST THEIR SOURCE OF INCOME AS A RESULT OF THE PANDEMIC. GIVEN THIS DEVELOPMENT, WE ARE FULLY AWARE THAT MANY BENEFICIARIES MAY HAVE DIED AS A RESULT OF THE PANDEMIC AND THEREFORE COULD NOT CLAIM THEIR PENDING FUNDS. BANK OF AMERICA WAS APPOINTED BY THE OFFICE OF WORLD BANK AUDITORS TO MAKE SUCH PAYMENTS TO THE CONCERNED BENEFICIARIES. AND THE SUM OF USD 5,400,000.00 HAS BEEN APPROVED BY WORLD BANK AUDITORS TO BE PAID TO EACH BENEFICIARY CONCERNED OUT OF HIS/HER TOTAL FUND AS PART PAYMENT. WE, THEREFORE, WANT YOU TO GET BACK TO US IF YOU ARE STILL ALIVE BY FORWARDING YOUR FULL DETAILS SUCH AS YOUR FULL NAMES ADDRESS, PHONE NUMBER THE ONLY THING WE WILL DO IS TO RE-VALIDATE YOUR FILE SO THAT IT WILL BECOME MORE AUTHENTIC AND BE AMONG THE LIST OF FILES THAT WILL BE ON OUR PAY LIST. THIS IS A GOLDEN OPPORTUNITY FOR YOU TO RECEIVE YOUR FUND. THANKS FOR YOUR ANTICIPATED COOPERATION. YOUR IMMEDIATE RESPONSE IS HIGHLY NEEDED TO ENABLE US TO COMMENCE THE TRANSFER. MR.PAUL M DONOFRIO ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: IMTS Attendees List Report- 2022
Hi, I hope this email finds you well. Would you be interested in acquiring International Manufacturing Technology Show Attendees Data List 2022? List contains: Company Name, Contact Name, First Name, Middle Name, Last Name, Title, Address, Street, City, Zip code, State, Country, Telephone, Email address and more No of Contacts: - 48,239 Cost: $1,876 Looking forward for your response, Best Regards Lara Paul Marketing Coordinator ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 3/4] drm/loongson: Add interrupt driver for LS7A.
Hi Chenyang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v5.19-rc6 next-20220708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220625-171037
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: arm64-allmodconfig
(https://download.01.org/0day-ci/archive/20220712/202207120454.pjbs1e9p-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
77a38f6839980bfac61babb40d83772c51427011)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/intel-lab-lkp/linux/commit/7cad653ee3a3b83188e2d91335269753e134b808
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220625-171037
git checkout 7cad653ee3a3b83188e2d91335269753e134b808
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=arm64 SHELL=/bin/bash drivers/gpu/drm/loongson/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/loongson/loongson_irq.c:24:11: warning: variable 'lcrtc' is
>> used uninitialized whenever 'if' condition is false
>> [-Wsometimes-uninitialized]
else if (val & FB_VSYNC1_INT)
^~~
drivers/gpu/drm/loongson/loongson_irq.c:27:26: note: uninitialized use
occurs here
drm_crtc_handle_vblank(&lcrtc->base);
^
drivers/gpu/drm/loongson/loongson_irq.c:24:7: note: remove the 'if' if its
condition is always true
else if (val & FB_VSYNC1_INT)
^~~~
drivers/gpu/drm/loongson/loongson_irq.c:16:29: note: initialize the variable
'lcrtc' to silence this warning
struct loongson_crtc *lcrtc;
^
= NULL
1 warning generated.
vim +24 drivers/gpu/drm/loongson/loongson_irq.c
11
12 static irqreturn_t loongson_irq_handler(int irq, void *arg)
13 {
14 struct drm_device *dev = (struct drm_device *) arg;
15 struct loongson_device *ldev = to_loongson_device(dev);
16 struct loongson_crtc *lcrtc;
17 u32 val;
18
19 val = ls7a_mm_rreg(ldev, FB_INT_REG);
20 ls7a_mm_wreg(ldev, FB_INT_REG, val & (0x << 16));
21
22 if (val & FB_VSYNC0_INT)
23 lcrtc = ldev->mode_info[0].crtc;
> 24 else if (val & FB_VSYNC1_INT)
25 lcrtc = ldev->mode_info[1].crtc;
26
27 drm_crtc_handle_vblank(&lcrtc->base);
28
29 return IRQ_HANDLED;
30 }
31
--
0-DAY CI Kernel Test Service
https://01.org/lkp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re : Mes salutations
-- Mes salutations Je suis Monsieur Robert SONNE un Opérateur économique à la retraite hospitalisée pour raison de santé. Je souffre d'une maladie cardiaque et le résultat de certaines de mes analyses médicales faisait état de ce que mes jours sur terre sont comptés, alors que je dispose dans ma Banque une somme d'argent d'un million quatre cent vingt-cinq mille euros. Malheureusement, je n'ai ni famille ni enfant qui pourra bénéficier de cet argent. Il m'a été conseillé par l'Évêque Catholique et mon guide spirituel d'en faire hériter une personne que je dois choisir au hasard, qui pourra en fais bon usage de ces fonds. Raison pour laquelle je vous contacte ce jour par mail étant donné que je suis sous hospitalisation afin de vivre le reste de mes jours. Vous êtes donc bénéficiaire de 1.425.000 EUROS. Je vous l'offre du fond du cœur, je réclame juste des prières en retour afin que mon âme repose en paix au dernier jour. Veuillez donc m'écrire par Émail : robertsonne1...@hotmail.com Que le Seigneur Dieu créateur du ciel et de la terre exauce vos prières, Amen!!! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] wfx: add antenna configuration files
On Thursday 7 July 2022 19:40:27 CEST Josh Boyer wrote:
> On Thu, Jul 7, 2022 at 1:04 PM Ben Brown wrote:
> > On 21/02/2022 16:37, Jerome Pouiller wrote:
> > > From: Jérôme Pouiller
> >
> > > diff --git a/WHENCE b/WHENCE
> > > index 0a6cb15..96f67f7 100644
> > > --- a/WHENCE
> > > +++ b/WHENCE
> > > @@ -5845,8 +5845,18 @@ Driver: wfx - Silicon Labs Wi-Fi Transceiver
> > > File: wfx/wfm_wf200_C0.sec
> > > Version: 3.12.1
> > >
> > > +File: wfx/brd4001a.pds not listed in WHENCE
> > > +File: wfx/brd8022a.pds not listed in WHENCE
> > > +File: wfx/brd8023a.pds not listed in WHENCE
> >
> > This format does not appear to be correct. While this will seemingly
> > pass the `check_whence.py` check, it will be completely ignored by
> > `copy-firmware.sh`, as that takes the full line after 'File: ' (e.g.
> > 'wfx/brd4001a.pds not listed in WHENCE', which of course does not exist).
>
> Oh, indeed.
>
> > I'm assuming the trailing ' not listed in WHENCE' needs to be removed
> > from each of these lines. Otherwise these are likely not being picked up
> > by distros (they are missing from Arch, for example). This may have been
> > the intention, but that seems odd (and unclear if so).
>
> I doubt that was the intention. I'll correct WHENCE in a separate
> commit. Thank you for reporting the issue.
It seems I had copy-pasted the output of check_whence.py. I was probably not
very awake. Sorry for the disturb.
Do you think the change below could be useful?
-8<-8<
diff --git i/check_whence.py w/check_whence.py
index 8805e99..8244288 100755
--- i/check_whence.py
+++ w/check_whence.py
@@ -6,11 +6,11 @@
def list_whence():
with open('WHENCE', encoding='utf-8') as whence:
for line in whence:
-match = re.match(r'(?:File|Source):\s*"(.*)"', line)
+match = re.match(r'(?:File|Source):\s*"(.*)"\s*$', line)
if match:
yield match.group(1)
continue
-match = re.match(r'(?:File|Source):\s*(\S*)', line)
+match = re.match(r'(?:File|Source):\s*(\S*)\s*$', line)
if match:
yield match.group(1)
continue
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] wfx: add antenna configuration files
On Thu, Jul 7, 2022 at 1:04 PM Ben Brown wrote: > > On 21/02/2022 16:37, Jerome Pouiller wrote: > > From: Jérôme Pouiller > > > diff --git a/WHENCE b/WHENCE > > index 0a6cb15..96f67f7 100644 > > --- a/WHENCE > > +++ b/WHENCE > > @@ -5845,8 +5845,18 @@ Driver: wfx - Silicon Labs Wi-Fi Transceiver > > File: wfx/wfm_wf200_C0.sec > > Version: 3.12.1 > > > > +File: wfx/brd4001a.pds not listed in WHENCE > > +File: wfx/brd8022a.pds not listed in WHENCE > > +File: wfx/brd8023a.pds not listed in WHENCE > > This format does not appear to be correct. While this will seemingly > pass the `check_whence.py` check, it will be completely ignored by > `copy-firmware.sh`, as that takes the full line after 'File: ' (e.g. > 'wfx/brd4001a.pds not listed in WHENCE', which of course does not exist). Oh, indeed. > I'm assuming the trailing ' not listed in WHENCE' needs to be removed > from each of these lines. Otherwise these are likely not being picked up > by distros (they are missing from Arch, for example). This may have been > the intention, but that seems odd (and unclear if so). I doubt that was the intention. I'll correct WHENCE in a separate commit. Thank you for reporting the issue. josh ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/3] wfx: add antenna configuration files
On 21/02/2022 16:37, Jerome Pouiller wrote: > From: Jérôme Pouiller > diff --git a/WHENCE b/WHENCE > index 0a6cb15..96f67f7 100644 > --- a/WHENCE > +++ b/WHENCE > @@ -5845,8 +5845,18 @@ Driver: wfx - Silicon Labs Wi-Fi Transceiver > File: wfx/wfm_wf200_C0.sec > Version: 3.12.1 > > +File: wfx/brd4001a.pds not listed in WHENCE > +File: wfx/brd8022a.pds not listed in WHENCE > +File: wfx/brd8023a.pds not listed in WHENCE This format does not appear to be correct. While this will seemingly pass the `check_whence.py` check, it will be completely ignored by `copy-firmware.sh`, as that takes the full line after 'File: ' (e.g. 'wfx/brd4001a.pds not listed in WHENCE', which of course does not exist). I'm assuming the trailing ' not listed in WHENCE' needs to be removed from each of these lines. Otherwise these are likely not being picked up by distros (they are missing from Arch, for example). This may have been the intention, but that seems odd (and unclear if so). Regards, Ben ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE
-- Hello We wishes to inform you that we received your fund from IMF for safety transfer to you because that your email address was found in the list of scam victims. kindly reply for more details to you. Look forward to hear from you soon Yours affectionately. Tony Albert Office director ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 2/4] drm/loongson: Add GPIO and I2C driver for loongson drm.
Hi Chenyang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v5.19-rc3 next-20220624]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220625-171037
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: powerpc-allmodconfig
compiler: powerpc-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/3af56da81352153b38e05c082b8f2bf8c9fc0320
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220625-171037
git checkout 3af56da81352153b38e05c082b8f2bf8c9fc0320
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1
O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/gpu/drm/loongson/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/loongson/loongson_encoder.c:10:27: warning: no previous
>> prototype for 'loongson_bridge_detect' [-Wmissing-prototypes]
10 | enum drm_connector_status loongson_bridge_detect(struct drm_bridge
*bridge)
| ^~
vim +/loongson_bridge_detect +10 drivers/gpu/drm/loongson/loongson_encoder.c
9
> 10 enum drm_connector_status loongson_bridge_detect(struct drm_bridge
*bridge)
11 {
12 unsigned char start = 0x0;
13 struct i2c_msg msgs = {
14 .addr = DDC_ADDR,
15 .flags = 0,
16 .len = 1,
17 .buf = &start,
18 };
19
20 if (i2c_transfer(bridge->ddc, &msgs, 1) != 1)
21 return connector_status_disconnected;
22 else
23 return connector_status_connected;
24 }
25
--
0-DAY CI Kernel Test Service
https://01.org/lkp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 1/4] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
Hi Chenyang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v5.19-rc3 next-20220624]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220625-171037
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
config: powerpc-allmodconfig
compiler: powerpc-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/438d0791edb6352903bf09dfe214453526081075
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220625-171037
git checkout 438d0791edb6352903bf09dfe214453526081075
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1
O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/gpu/drm/loongson/
If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/loongson/loongson_crtc.c: In function
'loongson_crtc_mode_set_nofb':
>> drivers/gpu/drm/loongson/loongson_crtc.c:128:42: error: invalid use of
>> undefined type 'struct drm_framebuffer'
128 | format = crtc->primary->state->fb->format;
| ^~
--
drivers/gpu/drm/loongson/loongson_device.c: In function
'loongson_gpu_offset':
>> drivers/gpu/drm/loongson/loongson_device.c:14:44: error: invalid use of
>> undefined type 'struct drm_framebuffer'
14 | gbo = drm_gem_vram_of_gem(state->fb->obj[0]);
|^~
--
In file included from include/linux/device.h:15,
from include/linux/pci.h:37,
from drivers/gpu/drm/loongson/loongson_drv.c:14:
drivers/gpu/drm/loongson/loongson_drv.c: In function 'loongson_device_init':
>> include/drm/drm_print.h:425:39: warning: format '%llx' expects argument of
>> type 'long long unsigned int', but argument 3 has type 'resource_size_t'
>> {aka 'unsigned int'} [-Wformat=]
425 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
| ^~~~
include/linux/dev_printk.h:110:30: note: in definition of macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
include/linux/dev_printk.h:150:58: note: in expansion of macro 'dev_fmt'
150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev,
dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
include/drm/drm_print.h:425:9: note: in expansion of macro 'dev_info'
425 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
| ^~~~
include/drm/drm_print.h:429:9: note: in expansion of macro '__drm_printk'
429 | __drm_printk((drm), info,, fmt, ##__VA_ARGS__)
| ^~~~
drivers/gpu/drm/loongson/loongson_drv.c:91:9: note: in expansion of macro
'drm_info'
91 | drm_info(dev, "DC mmio base 0x%llx size 0x%llx io 0x%llx\n",
| ^~~~
include/drm/drm_print.h:425:39: warning: format '%llx' expects argument of
type 'long long unsigned int', but argument 4 has type 'resource_size_t' {aka
'unsigned int'} [-Wformat=]
425 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
| ^~~~
include/linux/dev_printk.h:110:30: note: in definition of macro
'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__);
\
| ^~~
include/linux/dev_printk.h:150:58: note: in expansion of macro 'dev_fmt'
150 | dev_printk_index_wrap(_dev_info, KERN_INFO, dev,
dev_fmt(fmt), ##__VA_ARGS__)
| ^~~
include/drm/drm_print.h:425:9: note: in expansion of macro 'dev_info'
425 | dev_##level##type((drm)->dev, "[drm] " fmt, ##__VA_ARGS__)
| ^~~~
include/drm/drm_print.h:429:9: note: in expansion of macro '__drm_printk'
429 | __drm_printk((drm), info,, fmt, ##__VA_ARGS__)
| ^~~~
drivers/gpu/drm/loongson/loongson_drv.c:
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: [RESEND PATCH v3 0/1] Binder: add TF_UPDATE_TXN to replace outdated txn
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! [1]: [RESEND PATCH v3 0/1] Binder: add TF_UPDATE_TXN to replace outdated txn https://lore.kernel.org/lkml/20220526220018.3334775-1-dua...@chromium.org/ > > 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: comedi: comedi_fops: fixed a spacing coding style issue
On 09/06/2022 05:53, Agam Kohli wrote: Fixed a coding style issue. Signed-off-by: Agam Kohli --- drivers/staging/comedi/comedi_fops.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging/comedi/comedi_fops.c b/drivers/staging/comedi/comedi_fops.c index e85a99b68f31..3f70e5dfac39 100644 --- a/drivers/staging/comedi/comedi_fops.c +++ b/drivers/staging/comedi/comedi_fops.c comedi moved out of "drivers/staging" in the 5.13 kernel. -- -=( Ian Abbott || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re:
Greeting ,I had written an earlier mail to you but without response ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: good day
Greeting ,I had written an earlier mail to you but without response ___ 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 Thu, May 19, 2022 at 8:50 AM Greg KH wrote:
>
> 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?
Sure, I'll add a brief summary there.
>
> >
> > 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?
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).
>
> > 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.
It passed checkpatch but --strict does suggest I adjust the logical ops.
I'll update it in v2. Thanks for reminding me about using --strict.
Thanks,
Li
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinf
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: Benefit Letter
Re: Benefit Letter Did you receive my previous email to you as regards my business proposal? CT... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Benefit Letter
Re: Benefit Letter Did you receive my previous email to you as regards my business proposal? CT... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: CRYPTOCURRENCY INVESTMENT PROPOSAL
Greetings, Are you looking to invest in Crypto-currency? Have you searched for a reliable partner that can offer you good returns on your investment and also guarantee the security of your capital? Pradok Investments is your solution Pradok Investments is one of the World's leading Block chain backed, hardware & configuration based mining pools. We are an International financial company engaged in trading of forex and crypto currency exchanges performed by well equipped qualified professional traders with a client base of 56,485 customers worldwide. At Pradok Investments, We are offering 15% return on your investments. More importantly we guarantee the security of your investment because all of our investments are 100% insured. We provide our clients with the most trusted, reliable and profitable features that will make their experience successful. As a client you will have access to your investment and also learn market signals through your portal on our websites. For more info visit our office- Address: 425 Urban Plz, Kirkland, WA 98033, United States OR Send me an email for more guide at georgepaulbusin...@gmail.com Regards. George Paul. (Pradok Accredited Agent) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: CRYPTOCURRENCY INVESTMENT PROPOSAL
Greetings, Are you looking to invest in Crypto-currency? Have you searched for a reliable partner that can offer you good returns on your investment and also guarantee the security of your capital? Pradok Investments is your solution Pradok Investments is one of the World's leading Block chain backed, hardware & configuration based mining pools. We are an International financial company engaged in trading of forex and crypto currency exchanges performed by well equipped qualified professional traders with a client base of 56,485 customers worldwide. At Pradok Investments, We are offering 15% return on your investments. More importantly we guarantee the security of your investment because all of our investments are 100% insured. We provide our clients with the most trusted, reliable and profitable features that will make their experience successful. As a client you will have access to your investment and also learn market signals through your portal on our websites. For more info visit our office- Address: 425 Urban Plz, Kirkland, WA 98033, United States OR Send me an email for more guide at georgepaulbusin...@gmail.com Regards. George Paul. (Pradok Accredited Agent) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RFT/RFC v2 01/47] staging: media: Revert "media: zoran: remove deprecated driver"
On Sat, May 07, 2022 at 10:58:39AM -0500, Sergey Meirovich wrote: > Sergey Meirovich has sent you an email via Gmail confidential mode: > > Gmail logoRe: [PATCH RFT/RFC v2 01/47] staging: media: Revert "media: zoran: > remove deprecated driver" > > This message was sent on May 7, 2022 at 8:58:50 AM PDT > You can open it by clicking the link below. This link will only work for > laurent.pinch...@ideasonboard.com. Please don't use this feature when posting to public mailing lists. Such messages will be totally ignored. > View the email > > Gmail confidential mode gives you more control over the messages you send. The > sender may have chosen to set an expiration time, disable printing or > forwarding, or track access to this message. Learn more > > Gmail: Email by Google > Use is subject to the Google Privacy PolicyGoogle > Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USAlogo > You have received this message because someone sent you an email via > Gmail confidential mode. > -- Regards, Laurent Pinchart ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: PROJECT: From: Dr. Emmanuel Ibe Kachikwu (GMD) Nnpc Towers Garki, Abuja
Nnpc Towers, Central Business District, Herbert Macaulay way, P.m.b. 190, Garki, Abuja. From: Dr. Emmanuel Ibe Kachikwu (GMD) Contract Ref No: NNPC/PED/1462/KADREF/92) Attn: Ceo, I know that this proposal may come to you as a surprise especially having to come from someone you have not met before. I got your information from your country's chamber of commerce here in Nigeria. My name is Dr. Emmanuel Ibe Kachikwu, The Minister of State for Petroleum Resources, National Petroleum Corporation (NNPC). Be informed that my partner Dr. Maikanti Baru and I awarded a contract to a foreign firm (Sheng Yang Contraction Company) with contract Ref No: NNPC/PED/1462/KADREF/92) for the maintenance of the Nigeria petroleum-chemical complex located at Kaduna, Nigeria. I know that this proposal may come to you as a surprise especially having to come from someone you have not met before, but I would like you to co-operate with me so that this U$D98, 000,000.00 will be released and transferred into your account, it is mine profound intention to contact you for this very important and highly confidential transaction for the transfer of (U$D98, 000,000.00 Ninety-Eight Million United States Dollars Only into your bank account. The contract has been successfully executed by the contractors and their contract sum has been paid to them, leaving us an overestimated balance of (U$D98, 000,000.00 Ninety-Eight Million United States Dollars Only) still pending at the bank. Right now, we are left with this overestimated balance of (U$D98, 000,000.00) which is still floating at the escrow account in the Central Bank of Nigeria (CBN) waiting for final payment to any reliable foreign bank account, you may provide. We, as government officials, are not permitted to own or operate foreign bank accounts. therefore, we need reliable person who will provide us with a foreign account where to transfer and deposit this US$98,000,000.00, that is the reason we are soliciting for your sincere assistance to provide us with an account where to transfer this money .all modalities for the easy transfer of this money is now in place, the period of this transaction is only two weeks from the day we receive your bank account details. Note that 50% of our share will be invested in your country, as we propose to give you 30% of the U$D98, 000,000.00, my partners and I will get 60% of the money. The balance of 10% will be allocated to cover all expenses incurred by both partners, be informed that this proposal is urgent and confidential, please send to me your bank account details and full address of company name and address, your private phone and fax number for easy communication which will be used in securing all the necessary documents for easy transfer of the fund. Awaiting your urgent response. Best regards. Dr. Emmanuel Ibe Kachikwu. The Minister of State for Petroleum Resources, Nigerian National Petroleum Corporation (NNPC) This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Masterpage®. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [driver-core:driver-core-testing 30/34] fs/kernfs/file.c:160:46: sparse: sparse: incorrect type in argument 1 (different address spaces)
On Wed, Apr 27, 2022 at 04:17:29AM +0800, kernel test robot wrote:
> tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> driver-core-testing
> head: 26360a8c9732cff2ee5bc2f180e9716b63e9f650
> commit: 07b42a72474e4ab59d6acb451f7816664095d7c0 [30/34] kernfs: make
> ->attr.open RCU protected.
> config: alpha-randconfig-s032-20220425
> (https://download.01.org/0day-ci/archive/20220427/202204270438.uex7kt3b-...@intel.com/config)
> compiler: alpha-linux-gcc (GCC) 11.3.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # apt-get install sparse
> # sparse version: v0.6.4-dirty
> #
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?id=07b42a72474e4ab59d6acb451f7816664095d7c0
> git remote add driver-core
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> git fetch --no-tags driver-core driver-core-testing
> git checkout 07b42a72474e4ab59d6acb451f7816664095d7c0
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross C=1
> CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=alpha
> SHELL=/bin/bash fs/kernfs/
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
>
>
> sparse warnings: (new ones prefixed by >>)
> >> fs/kernfs/file.c:160:46: sparse: sparse: incorrect type in argument 1
> >> (different address spaces) @@ expected struct atomic_t const
> >> [usertype] *v @@ got struct atomic_t [noderef] __rcu * @@
>fs/kernfs/file.c:160:46: sparse: expected struct atomic_t const
> [usertype] *v
>fs/kernfs/file.c:160:46: sparse: got struct atomic_t [noderef] __rcu *
>fs/kernfs/file.c:204:46: sparse: sparse: incorrect type in argument 1
> (different address spaces) @@ expected struct atomic_t const [usertype]
> *v @@ got struct atomic_t [noderef] __rcu * @@
>fs/kernfs/file.c:204:46: sparse: expected struct atomic_t const
> [usertype] *v
>fs/kernfs/file.c:204:46: sparse: got struct atomic_t [noderef] __rcu *
>
> vim +160 fs/kernfs/file.c
>
> 414985ae23c031e Tejun Heo 2013-11-28 155
> 414985ae23c031e Tejun Heo 2013-11-28 156 static int kernfs_seq_show(struct
> seq_file *sf, void *v)
> 414985ae23c031e Tejun Heo 2013-11-28 157 {
> c525aaddc366df2 Tejun Heo 2013-12-11 158 struct kernfs_open_file *of =
> sf->private;
> 414985ae23c031e Tejun Heo 2013-11-28 159
> adc5e8b58f4886d Tejun Heo 2013-12-11 @160 of->event =
> atomic_read(&of->kn->attr.open->event);
> 414985ae23c031e Tejun Heo 2013-11-28 161
> adc5e8b58f4886d Tejun Heo 2013-12-11 162 return
> of->kn->attr.ops->seq_show(sf, v);
> 414985ae23c031e Tejun Heo 2013-11-28 163 }
> 414985ae23c031e Tejun Heo 2013-11-28 164
>
> :: The code at line 160 was first introduced by commit
> :: adc5e8b58f4886d45f79f4ff41a09001a76a6b12 kernfs: drop s_ prefix from
> kernfs_node members
>
> :: TO: Tejun Heo
> :: CC: Greg Kroah-Hartman
>
Imran, I'm going to go drop this change from my tree and let you
resubmit it after it's been fixed up (you need to grab the rcu reference
on attr.open here.)
thanks,
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 1/4] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip
Hi Chenyang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v5.18-rc3 next-20220422]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220422-161914
base: git://anongit.freedesktop.org/drm/drm drm-next
config: arm-randconfig-s031-20220422
(https://download.01.org/0day-ci/archive/20220423/202204230030.kzgmtgoq-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-dirty
#
https://github.com/intel-lab-lkp/linux/commit/e9a9964d58e6cc797a113fa47f54583c10908d63
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220422-161914
git checkout e9a9964d58e6cc797a113fa47f54583c10908d63
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=arm
SHELL=/bin/bash drivers/gpu/drm/loongson/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/loongson/loongson_drv.c:91:9: sparse: sparse: cast removes
>> address space '__iomem' of expression
drivers/gpu/drm/loongson/loongson_drv.c:99:5: sparse: sparse: symbol
'loongson_modeset_init' was not declared. Should it be static?
vim +/__iomem +91 drivers/gpu/drm/loongson/loongson_drv.c
36
37 static int loongson_device_init(struct drm_device *dev)
38 {
39 struct loongson_device *ldev = to_loongson_device(dev);
40 struct pci_dev *pdev = to_pci_dev(dev->dev);
41 struct pci_dev *gpu_pdev;
42 resource_size_t aper_base;
43 resource_size_t aper_size;
44 resource_size_t mmio_base;
45 resource_size_t mmio_size;
46 int ret;
47
48 /* GPU MEM */
49 /* We need get 7A-gpu pci device information for ldev->gpu_pdev
*/
50 /* dev->pdev save 7A-dc pci device information */
51 gpu_pdev = pci_get_device(PCI_VENDOR_ID_LOONGSON,
52PCI_DEVICE_ID_LOONGSON_GPU, NULL);
53 ret = pci_enable_device(gpu_pdev);
54 if (ret)
55 return ret;
56 pci_set_drvdata(gpu_pdev, dev);
57
58 aper_base = pci_resource_start(gpu_pdev, 2);
59 aper_size = pci_resource_len(gpu_pdev, 2);
60 ldev->vram_start = aper_base;
61 ldev->vram_size = aper_size;
62
63 if (!devm_request_mem_region(dev->dev, ldev->vram_start,
64 ldev->vram_size, "loongson_vram"))
{
65 drm_err(dev, "Can't reserve VRAM\n");
66 return -ENXIO;
67 }
68
69 /* DC MEM */
70 mmio_base = pci_resource_start(pdev, 0);
71 mmio_size = pci_resource_len(pdev, 0);
72 ldev->mmio = devm_ioremap(dev->dev, mmio_base, mmio_size);
73 if (!ldev->mmio) {
74 drm_err(dev, "Cannot map mmio region\n");
75 return -ENOMEM;
76 }
77
78 if (!devm_request_mem_region(dev->dev, mmio_base,
79 mmio_size, "loongson_mmio")) {
80 drm_err(dev, "Can't reserve mmio registers\n");
81 return -ENOMEM;
82 }
83
84 /* DC IO */
85 ldev->io = devm_ioremap(dev->dev, LS7A_CHIPCFG_REG_BASE, 0xf);
86 if (!ldev->io)
87 return -ENOMEM;
88
89 ldev->num_crtc = 2;
90
> 91 drm_info(dev, "DC mmio base 0x%llx size 0x%llx io 0x%llx\n",
92 mmio_base, mmio_size, *(u64 *)ldev->io);
93 drm_info(dev, "GPU vram start = 0x%x size = 0x%x\n",
94 ldev->vram_start, ldev->vram_size);
95
96 return 0;
97 }
98
--
0-DAY CI Kernel Test Service
https://01.org/lkp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 2/4] drm/loongson: Add GPIO and I2C driver for loongson drm.
Hi Chenyang,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v5.18-rc3 next-20220422]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/intel-lab-lkp/linux/commits/Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220422-161914
base: git://anongit.freedesktop.org/drm/drm drm-next
config: riscv-allmodconfig
(https://download.01.org/0day-ci/archive/20220423/202204230046.2fbntjrk-...@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/4a5b6ac99c37617e030a054ca431c5c9aab227b8
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Chenyang-Li/drm-loongson-Add-DRM-Driver-for-Loongson-7A1000-bridge-chip/20220422-161914
git checkout 4a5b6ac99c37617e030a054ca431c5c9aab227b8
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross W=1
O=build_dir ARCH=riscv SHELL=/bin/bash drivers/gpu/drm/loongson/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/loongson/loongson_encoder.c:10:27: warning: no previous
>> prototype for 'loongson_bridge_detect' [-Wmissing-prototypes]
10 | enum drm_connector_status loongson_bridge_detect(struct drm_bridge
*bridge)
| ^~
vim +/loongson_bridge_detect +10 drivers/gpu/drm/loongson/loongson_encoder.c
9
> 10 enum drm_connector_status loongson_bridge_detect(struct drm_bridge
*bridge)
11 {
12 unsigned char start = 0x0;
13 struct i2c_msg msgs = {
14 .addr = DDC_ADDR,
15 .flags = 0,
16 .len = 1,
17 .buf = &start,
18 };
19
20 if (i2c_transfer(bridge->ddc, &msgs, 1) != 1)
21 return connector_status_disconnected;
22 else
23 return connector_status_connected;
24 }
25
--
0-DAY CI Kernel Test Service
https://01.org/lkp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: $$$10.5M USD OF YOUR FUNDS NOW FINALLY READY.
Reply To..Mr. Gabby Lee Email: worldsettlementcen...@outlook.com WORLD BANK COMPENSATION UNIT OUR REF: WB/STF01861/HQ RELEASE CODE NO. 074888 AMOUNT: $10.5m USD Attention: Sir/Ma, Please be informed that your long awaited compensation funds payment regarding LOTTERY WINNING, COVID-19 RELIEF FUNDS AND UNPAID CONTRACTORS that have not been paid for many years into decades have now been approved through our compensation program. The compensation amount is 10.5m USD (Ten Million,Five Hundred Thousand US D0llars only). But today a middle-aged lady by the name Judy Alexander forwarded her banking information claiming to represent you that you are now late/dead. This is to confirm from your email reply if you are truly dead or alive?? And kindly reconfirm your information once again for further procedure. 1. Name.. 2. Age. 3. Country... 4. Mobile Number 5. Alternative/Other Email... Please take note that you must pay $250 for official for proper clearance and documentation before we can proceed. If you choose otherwise not to pay do not reply to this email notification. We await your urgent response within the next 24 hours in order to proceed. Yours faithfully, Gabby Lee The International Payment and Settlement Center. The World Bank Office H-Unit ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE:
Did you receive my email sent to you last night? Brent Timmons ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
+ stephen Greg Kroah-Hartman writes: > On Wed, Apr 06, 2022 at 10:06:33AM +0300, Kalle Valo wrote: >> Jakub Kicinski writes: >> >> > On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: >> >> Sure, that would technically work. But I just think it's cleaner to use >> >> -rc1 (or later) as the baseline for an immutable branch. If the baseline >> >> is an arbitrary commit somewhere within merge windows commits, it's more >> >> work for everyone to verify the branch is suitable. >> >> >> >> Also in general I would also prefer to base -next trees to -rc1 or newer >> >> to make the bisect cleaner. The less we need to test kernels from the >> >> merge window (ie. commits after the final release and before -rc1) the >> >> better. >> >> >> >> But this is just a small wish from me, I fully understand that it might >> >> be too much changes to your process. Wanted to point out this anyway. >> > >> > Forwarded! >> >> Awesome, thank you Jakub! >> >> Greg, I now created an immutable branch for moving wfx from >> drivers/staging to drivers/net/wireless/silabs: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git >> wfx-move-out-of-staging >> >> The baseline for this branch is v5.18-rc1. If you think the branch is >> ok, please pull it to staging-next and let me know. I can then pull the >> branch to wireless-next and the transition should be complete. And do >> let me know if there are any problems. > > Looks great to me! I've pulled it into staging-next now. And will not > take any more patches to the driver (some happened before the merge but > git handled the move just fine.) Great, thanks Greg! I now merged the immutable branch also to wireless-next: 79649041edc8 Merge branch 'wfx-move-out-of-staging' 4a5fb1bbcdf1 wfx: get out from the staging area So from now on wfx patches should be submitted for wireless-next via the linux-wireless mailing list, instructions in the wiki link below. Stephen, I want to warn you in advance about this driver move but hopefully everything goes smoothly. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Wed, Apr 06, 2022 at 10:06:33AM +0300, Kalle Valo wrote: > Jakub Kicinski writes: > > > On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: > >> Sure, that would technically work. But I just think it's cleaner to use > >> -rc1 (or later) as the baseline for an immutable branch. If the baseline > >> is an arbitrary commit somewhere within merge windows commits, it's more > >> work for everyone to verify the branch is suitable. > >> > >> Also in general I would also prefer to base -next trees to -rc1 or newer > >> to make the bisect cleaner. The less we need to test kernels from the > >> merge window (ie. commits after the final release and before -rc1) the > >> better. > >> > >> But this is just a small wish from me, I fully understand that it might > >> be too much changes to your process. Wanted to point out this anyway. > > > > Forwarded! > > Awesome, thank you Jakub! > > Greg, I now created an immutable branch for moving wfx from > drivers/staging to drivers/net/wireless/silabs: > > git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git > wfx-move-out-of-staging > > The baseline for this branch is v5.18-rc1. If you think the branch is > ok, please pull it to staging-next and let me know. I can then pull the > branch to wireless-next and the transition should be complete. And do > let me know if there are any problems. Looks great to me! I've pulled it into staging-next now. And will not take any more patches to the driver (some happened before the merge but git handled the move just fine.) thanks! greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Jakub Kicinski writes: > On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: >> Sure, that would technically work. But I just think it's cleaner to use >> -rc1 (or later) as the baseline for an immutable branch. If the baseline >> is an arbitrary commit somewhere within merge windows commits, it's more >> work for everyone to verify the branch is suitable. >> >> Also in general I would also prefer to base -next trees to -rc1 or newer >> to make the bisect cleaner. The less we need to test kernels from the >> merge window (ie. commits after the final release and before -rc1) the >> better. >> >> But this is just a small wish from me, I fully understand that it might >> be too much changes to your process. Wanted to point out this anyway. > > Forwarded! Awesome, thank you Jakub! Greg, I now created an immutable branch for moving wfx from drivers/staging to drivers/net/wireless/silabs: git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git wfx-move-out-of-staging The baseline for this branch is v5.18-rc1. If you think the branch is ok, please pull it to staging-next and let me know. I can then pull the branch to wireless-next and the transition should be complete. And do let me know if there are any problems. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Tue, 05 Apr 2022 10:16:58 +0300 Kalle Valo wrote: > Sure, that would technically work. But I just think it's cleaner to use > -rc1 (or later) as the baseline for an immutable branch. If the baseline > is an arbitrary commit somewhere within merge windows commits, it's more > work for everyone to verify the branch is suitable. > > Also in general I would also prefer to base -next trees to -rc1 or newer > to make the bisect cleaner. The less we need to test kernels from the > merge window (ie. commits after the final release and before -rc1) the > better. > > But this is just a small wish from me, I fully understand that it might > be too much changes to your process. Wanted to point out this anyway. Forwarded! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Jakub Kicinski writes: > On Mon, 4 Apr 2022 23:22:47 -0700 Jakub Kicinski wrote: >> On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: >> > Dave&Jakub, once you guys open net-next will it be based on -rc1? >> >> Not normally. We usually let net feed net-next so it'd get -rc1 this >> Thursday. But we should be able to fast-forward, let me confirm with >> Dave. > > Wait, why is -rc1 magic? If you based the branch on whatever > the merge-base of net-next and staging-next is, would that be > an aberration? Sure, that would technically work. But I just think it's cleaner to use -rc1 (or later) as the baseline for an immutable branch. If the baseline is an arbitrary commit somewhere within merge windows commits, it's more work for everyone to verify the branch is suitable. Also in general I would also prefer to base -next trees to -rc1 or newer to make the bisect cleaner. The less we need to test kernels from the merge window (ie. commits after the final release and before -rc1) the better. But this is just a small wish from me, I fully understand that it might be too much changes to your process. Wanted to point out this anyway. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Mon, 4 Apr 2022 23:22:47 -0700 Jakub Kicinski wrote: > On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: > > Dave&Jakub, once you guys open net-next will it be based on -rc1? > > Not normally. We usually let net feed net-next so it'd get -rc1 this > Thursday. But we should be able to fast-forward, let me confirm with > Dave. Wait, why is -rc1 magic? If you based the branch on whatever the merge-base of net-next and staging-next is, would that be an aberration? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
On Mon, 04 Apr 2022 13:49:18 +0300 Kalle Valo wrote: > Dave&Jakub, once you guys open net-next will it be based on -rc1? Not normally. We usually let net feed net-next so it'd get -rc1 this Thursday. But we should be able to fast-forward, let me confirm with Dave. > That would make it easier for me to create an immutable branch between > staging-next and wireless-next. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Jérôme Pouiller writes: > On Saturday 26 February 2022 14:15:33 CEST Kalle Valo wrote: >> Greg Kroah-Hartman writes: >> >> > That sounds great to me, let's plan on that happening after 5.18-rc1 is >> > out. >> >> Very good, we have a plan then. I marked the patch as deferred in >> patchwork: >> >> https://patchwork.kernel.org/project/linux-wireless/patch/20220226092142.10164-2-jerome.pouil...@silabs.com/ >> >> Jerome, feel free to remind me about this after v5.18-rc1 is released. > > v5.18-rc1 is released :) Thanks for the reminder :) Once we open wireless-next I'll start preparing the branch. Dave&Jakub, once you guys open net-next will it be based on -rc1? That would make it easier for me to create an immutable branch between staging-next and wireless-next. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v10 0/1] wfx: get out from the staging area
Hi Kalle,
On Saturday 26 February 2022 14:15:33 CEST Kalle Valo wrote:
> Greg Kroah-Hartman writes:
>
> > On Sat, Feb 26, 2022 at 12:41:41PM +0200, Kalle Valo wrote:
> >> + jakub
> >>
> >> Jerome Pouiller writes:
> >>
> >> > The firmware and the PDS files (= antenna configurations) are now a part
> >> > of
> >> > the linux-firmware repository.
> >> >
> >> > All the issues have been fixed in staging tree. I think we are ready to
> >> > get
> >> > out from the staging tree for the kernel 5.18.
> >>
> >> [...]
> >>
> >> > rename Documentation/devicetree/bindings/{staging =>
> >> > }/net/wireless/silabs,wfx.yaml (98%)
> >>
> >> I lost track, is this file acked by the DT maintainers now?
> >>
> >> What I suggest is that we queue this for v5.19. After v5.18-rc1 is
> >> released I could create an immutable branch containing this one commit.
> >> Then I would merge the branch to wireless-next and Greg could merge it
> >> to the staging tree, that way we would minimise the chance of conflicts
> >> between trees.
> >>
> >> Greg, what do you think? Would this work for you? IIRC we did the same
> >> with wilc1000 back in 2020 and I recall it went without hiccups.
> >
> > That sounds great to me, let's plan on that happening after 5.18-rc1 is
> > out.
>
> Very good, we have a plan then. I marked the patch as deferred in
> patchwork:
>
> https://patchwork.kernel.org/project/linux-wireless/patch/20220226092142.10164-2-jerome.pouil...@silabs.com/
>
> Jerome, feel free to remind me about this after v5.18-rc1 is released.
v5.18-rc1 is released :)
--
Jérôme Pouiller
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Re: [PATCH v1] pinctrl: ralink: rt2880: Check for return value of devm_kcalloc()
On Fri, Apr 1, 2022 at 6:06 AM unSimple wrote: > > The main consideration of the 'continue' in the patch is that those > statements are inner a loop. > > The next allocation may be successful so I think it is better to use > 'continue' here. Please, do not top-post! What you explained is logical from APIs point of view, what I was asking is about functional point of view. Why do you think the skipping iteration is fine? You need to explain this in the code/commit message. > At 2022-03-29 19:45:50, "Andy Shevchenko" wrote: > >On Tue, Mar 29, 2022 at 11:36 AM QintaoShen wrote: > >> > >> The memory allocation function devm_kcalloc() may return NULL pointer, > > > >may --> might > > > >> so it is better to add a check for 'p->func[i]->pins' to avoid possible > >> NULL pointer dereference. ... > >> @@ -266,6 +266,10 @@ static int rt2880_pinmux_pins(struct rt2880_priv *p) > >> p->func[i]->pin_count, > >> sizeof(int), > >> GFP_KERNEL); > > > >> + > > > >Stray change. Also it seems it has trailing space character(s). > > > >> +if (!p->func[i]->pins) > > > >> +continue; > > > >Why is 'continue' the proper choice here? No clarification is given in > >the commit message. > > > >> for (j = 0; j < p->func[i]->pin_count; j++) > >> p->func[i]->pins[j] = p->func[i]->pin_first + j; -- With Best Regards, Andy Shevchenko ___ 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 11:36 AM QintaoShen wrote: > > The memory allocation function devm_kcalloc() may return NULL pointer, may --> might > so it is better to add a check for 'p->func[i]->pins' to avoid possible > NULL pointer dereference. ... > @@ -266,6 +266,10 @@ static int rt2880_pinmux_pins(struct rt2880_priv *p) > p->func[i]->pin_count, > sizeof(int), > GFP_KERNEL); > + Stray change. Also it seems it has trailing space character(s). > +if (!p->func[i]->pins) > +continue; Why is 'continue' the proper choice here? No clarification is given in the commit message. > for (j = 0; j < p->func[i]->pin_count; j++) > p->func[i]->pins[j] = p->func[i]->pin_first + j; -- With Best Regards, Andy Shevchenko ___ 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: Mutual Benefit
Did you receive my previous email to you as regards Business Proposal? CT... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Greetings!
Hello, Good day, The HSBC Bank is a financial institution in United Kingdom. We promotes long-term,sustainable and broad-based economic growth in developing and emerging countries by providing financial support like loans and investment to large, small and medium-sized companies (SMEs) as well as fast-growing enterprises which in turn helps to create secure and permanent jobs and reduce poverty. If you need fund to promotes your business, project(Project Funding), Loan, planning, budgeting and expansion of your business(s) , do not hesitate to indicate your interest as we are here to serve you better by granting your request. Thank you Mr:Mark ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
re
Hola, querido; Este es el of office (IMF) que hemos discutido con la empresa de entrega DHL Courier sobre cómo entregarle esta tarjeta de dinero, dijeron que solo debe pagar la tarifa cobrada por todos los documentos y la tarifa de entrega, han negociado con los interesados autoridad y acordaron entregar Su tarjeta de dinero a su domicilio designado. sacará un máximo de $150,000.00 por día hasta que retire todo su dinero en la tarjeta para que pueda retirar todo su dinero en la tarjeta antes de que venza; por lo tanto, comuníquese con la empresa de entrega ahora a través de su dirección de correo electrónico (dhl-deliverycomp...@europe.com). Firmar. Rev Fatther Henry R. Director Departamento de Remesas Hola, cariño; ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
