Re: [PATCH v6 16/17] dt: bindings: net: add microchip,wilc1000.yaml
On Fri, 27 Mar 2020 06:33:20 +, wrote: > > From: Ajay Singh > > This file describes the binding details to connect wilc1000 device. It's > moved from staging to 'Documentation/devicetree/bindings/net/wireless' > path. > > Signed-off-by: Ajay Singh > --- > .../net/wireless/microchip,wilc1000.yaml | 71 +++ > 1 file changed, 71 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/net/wireless/microchip,wilc1000.yaml > Reviewed-by: Rob Herring ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing] BUILD SUCCESS 2577408b68c05a5b85d95d0e60f51509d4a1a674
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing branch HEAD: 2577408b68c05a5b85d95d0e60f51509d4a1a674 staging: bcm2835-camera: reduce indentation in ctrl_set_image_effect elapsed time: 846m configs tested: 196 configs skipped: 0 The following configs have been built successfully. More configs may be tested in the coming days. arm allmodconfig arm allnoconfig arm allyesconfig arm64allmodconfig arm64 allnoconfig arm64allyesconfig arm at91_dt_defconfig arm efm32_defconfig arm exynos_defconfig armmulti_v5_defconfig armmulti_v7_defconfig armshmobile_defconfig arm sunxi_defconfig arm64 defconfig sparcallyesconfig i386 alldefconfig h8300 h8s-sim_defconfig xtensa iss_defconfig ia64defconfig powerpc defconfig sh allmodconfig alpha defconfig m68k allmodconfig sparc64 allnoconfig h8300 edosk2674_defconfig s390 debug_defconfig riscv rv32_defconfig sh rsk7269_defconfig i386 allnoconfig i386 allyesconfig i386defconfig ia64 alldefconfig ia64 allmodconfig ia64 allnoconfig ia64 allyesconfig c6x allyesconfig c6xevmc6678_defconfig nios2 10m50_defconfig nios2 3c120_defconfig openriscor1ksim_defconfig openrisc simple_smp_defconfig xtensa common_defconfig nds32 defconfig nds32 allnoconfig cskydefconfig h8300h8300h-sim_defconfig m68k m5475evb_defconfig m68k multi_defconfig m68k sun3_defconfig arc defconfig arc allyesconfig powerpc rhel-kconfig microblaze mmu_defconfig microblazenommu_defconfig powerpc allnoconfig powerpc ppc64_defconfig mips allyesconfig mips allnoconfig mips 32r2_defconfig mips allmodconfig mips 64r6el_defconfig mips fuloong2e_defconfig mips malta_kvm_defconfig pariscallnoconfig parisc allyesconfig pariscgeneric-32bit_defconfig pariscgeneric-64bit_defconfig i386 randconfig-a002-20200404 x86_64 randconfig-a002-20200404 x86_64 randconfig-a001-20200404 i386 randconfig-a001-20200404 i386 randconfig-a003-20200404 x86_64 randconfig-a001-20200405 x86_64 randconfig-a002-20200405 x86_64 randconfig-a003-20200405 i386 randconfig-a001-20200405 i386 randconfig-a002-20200405 i386 randconfig-a003-20200405 alpharandconfig-a001-20200405 m68k randconfig-a001-20200405 mips randconfig-a001-20200405 nds32randconfig-a001-20200405 parisc randconfig-a001-20200405 riscvrandconfig-a001-20200405 mips randconfig-a001-20200404 nds32randconfig-a001-20200404 m68k randconfig-a001-20200404 parisc randconfig-a001-20200404 alpharandconfig-a001-20200404 riscvrandconfig-a001-20200404 c6x randconfig-a001-20200405 h8300randconfig-a001-20200405 microblaze randconfig-a001-20200405 nios2randconfig-a001-20200405 sparc64 randconfig-a001-20200405 sparc64 randconfig-a001-20200404 h8300randconfig-a001-20200404 nios2randconfig-a001-20200404 microblaze randconfig-a001-20200404 c6x randconfig-a001-20200404 s390
INSTRUCTIONS / WARNING FROM CENTRAL BANK. 04/04
Dear Esteemed Beneficiary, This is to bring to your notice from the Executive Governor of the Central Bank Remittance Department that your outstanding contractual / inheritance payment which was suspended by the Nigerian government there by stopping the TRANSFER DEPARTMENT to pause the transfer of your contract fund to your nominated bank account. As a result of this development verification conducted by the Finance Ministry in conjunction with the Debt Verification Panel on your contract case file has been endorsed for payment awaiting your confirmations. In view of several efforts already made by us to contact you for the following reasons based on the new account submitted to this office on your behalf: (1) My Office desks have just received a sworn affidavit from Mr.Jim Hermann from your country to re-route your payment into a new bank account. The sum of US$ 3.8 Million US Dollars ( THREE MILLION EIGHT HUNDRED THOUSAND US Dollars) (2) Please, confirm to our office if you have instructed Mr. Jim Hermann from your country to appoint an attorney/agent on your behalf thereby asking that he receive cash call remittance on your behalf. (3) It have come to our notice that you are being contacted by unauthorized individuals with respect to your Contract / Inheritance payment but unfortunately this office is not aware of your unofficial dealings and warned that it is at your own risk. (4) Please, also confirm if you have authorized Mr. Jim Hermann to change your banking particulars. Also re-confirm your details and, Private Telephone, your e-mail address, so that we can cross-check it with our file records. We have decided to contact you for re-verification because we suspected that Mr. Jim Hermann is trying to divert your money through the sworn affidavit into a new different bank account. You are advised to get back to this office within 7days from today. Best Regards Mr.Godwin Emefiele Executive Governor Central Bank Nigeria -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: wilc1000: Use crc7 in lib/ rather than a private copy
On Sat, Apr 04, 2020 at 08:25:37PM +0300, Dan Carpenter wrote: > On Fri, Apr 03, 2020 at 11:40:28PM +, George Spelvin wrote: >> I understand that it's addressed more to patch authors than >> maintainers forwarding them, but I've read that thing a dozen times, >> and the description of S-o-b always seemed to be about copyright. > > It's to say that you didn't add anything which you shouldn't have, for > example, secret SCO UnixWare stuff. Yes, I'm familiar with the (irritating) history. Which is why I had the idea stuck in my head that that it was all about copyright and if you didn't add anything copyrightable, an S-o-b wasn't required. No more than I'd ask for one from the administrator of the e-mail system which delivered it. submitting-patches.rst says "sign your work". It didn't occur to me to sign something that wasn't my work. >> So I had assumed that edits which were below the de minimus standard >> of copyright didn't need a separate S-o-b. >> >> Am I right that there should be an S-o-b from everyone from the >> patch author to the patch committer (as recorded in git)? And the >> one exception is that we don't need S-o-b for git pulls after that, >> because the merge commits record the information? > > Yes. Also if people added their S-o-b for git merges it would change > the git hash for the patch which would suck. I understand the technical difficulties, but lawyers aren't always deterred by such things. :-) Seriously, it's clear there has to be an exception; the question was about the scope of the exception. Thank you for your patience clarifying this stuff for the nth time. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: wilc1000: Use crc7 in lib/ rather than a private copy
On Fri, Apr 03, 2020 at 11:40:28PM +, George Spelvin wrote: > I understand that it's addressed more to patch authors than > maintainers forwarding them, but I've read that thing a dozen times, > and the description of S-o-b always seemed to be about copyright. > It's to say that you didn't add anything which you shouldn't have, for example, secret SCO UnixWare stuff. > So I had assumed that edits which were below the de minimus standard > of copyright didn't need a separate S-o-b. > > Am I right that there should be an S-o-b from everyone from the > patch author to the patch committer (as recorded in git)? And the > one exception is that we don't need S-o-b for git pulls after that, > because the merge commits record the information? Yes. Also if people added their S-o-b for git merges it would change the git hash for the patch which would suck. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/3] staging: vt6656: Remove unnecessary local variable initialization
Don't initialize the rate variable as it is set a few lines later.
Signed-off-by: Oscar Carter
---
drivers/staging/vt6656/baseband.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/baseband.c
b/drivers/staging/vt6656/baseband.c
index a785f91c1566..04393ea6287d 100644
--- a/drivers/staging/vt6656/baseband.c
+++ b/drivers/staging/vt6656/baseband.c
@@ -135,7 +135,7 @@ unsigned int vnt_get_frame_time(u8 preamble_type, u8
pkt_type,
{
unsigned int frame_time;
unsigned int preamble;
- unsigned int rate = 0;
+ unsigned int rate;
if (tx_rate >= ARRAY_SIZE(vnt_frame_time))
return 0;
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/3] staging: vt6656: Cleanup of the vnt_get_frame_time function
This patch series makes a cleanup of the vnt_get_frame_time function. The first patch removes the define RATE_54M and changes it for the ARRAY_SIZE macro. This way avoid possibles issues if the size of the vnt_frame_time array change in the future but not change accordingly the RATE_54M constant. The second patch makes use of the define RATE_11M instead of a magic number. The third patch remove unnecessary local variable initialization. Oscar Carter (3): staging: vt6656: Use ARRAY_SIZE instead of define RATE_54M staging: vt6656: Use define instead of magic number for tx_rate staging: vt6656: Remove unnecessary local variable initialization drivers/staging/vt6656/baseband.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/3] staging: vt6656: Use define instead of magic number for tx_rate
Use the define RATE_11M present in the file "device.h" instead of the
magic number 3. So the code is more clear.
Signed-off-by: Oscar Carter
---
drivers/staging/vt6656/baseband.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/vt6656/baseband.c
b/drivers/staging/vt6656/baseband.c
index 3e4bd637849a..a785f91c1566 100644
--- a/drivers/staging/vt6656/baseband.c
+++ b/drivers/staging/vt6656/baseband.c
@@ -24,6 +24,7 @@
#include
#include
+#include "device.h"
#include "mac.h"
#include "baseband.h"
#include "rf.h"
@@ -141,7 +142,7 @@ unsigned int vnt_get_frame_time(u8 preamble_type, u8
pkt_type,
rate = (unsigned int)vnt_frame_time[tx_rate];
- if (tx_rate <= 3) {
+ if (tx_rate <= RATE_11M) {
if (preamble_type == 1)
preamble = 96;
else
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/3] staging: vt6656: Use ARRAY_SIZE instead of define RATE_54M
Use ARRAY_SIZE to replace the define RATE_54M so we will never have a mismatch. In this way, avoid the possibility of a buffer overflow if this define is changed in the future to a greater value. Signed-off-by: Oscar Carter --- drivers/staging/vt6656/baseband.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/vt6656/baseband.c b/drivers/staging/vt6656/baseband.c index a19a563d8bcc..3e4bd637849a 100644 --- a/drivers/staging/vt6656/baseband.c +++ b/drivers/staging/vt6656/baseband.c @@ -136,7 +136,7 @@ unsigned int vnt_get_frame_time(u8 preamble_type, u8 pkt_type, unsigned int preamble; unsigned int rate = 0; - if (tx_rate > RATE_54M) + if (tx_rate >= ARRAY_SIZE(vnt_frame_time)) return 0; rate = (unsigned int)vnt_frame_time[tx_rate]; -- 2.20.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3] staging: wilc1000: Use crc7 in lib/ rather than a private copy
George Spelvin writes: > On Fri, Apr 03, 2020 at 12:10:29PM +0300, Dan Carpenter wrote: >> On Thu, Apr 02, 2020 at 03:30:34PM +, George Spelvin wrote: >> > On Thu, Apr 02, 2020 at 11:27:45AM +0300, Dan Carpenter wrote: >> > > I don't know how this patch made it through two versions without anyone >> > > complaining that this paragraph should be done as a separate patch... >> > >> > I often fold comment (and spacing/formatting) patches in to a main >> > patch, when touching adjacent code anyway and it doesn't cause >> > distracting clutter. >> > >> > This seemed like such a case, which is why I submitted it as one. >> > But it's a bit of style thing. >> > >> >> We're super strict in Staging. :P Greg is more strict than I am. > > Okay, but it's my fault, not his. > >>> This should have you Signed-off-by. The Reviewed-by is kind of assumed so you can drop that bit. But everyone who touches a patch needs to add their signed off by. >>> >>> Er... all he did was add "staging: " to the front of the title. >>> >>> That's not a change to the code at all, and as trivial a change >>> to the commit message as adding "Reviewed-by:" to the end. >>> We don't need S-o-b for such things or we'd end up in a horrible >>> infinite recursion. >> >> You've misunderstood. He sent the email so he has to add his >> Signed-off-by. It's not at all related to changing anything in the >> patch. That's how sign offs work. > > Looking at my commits (just because I remember how they went in), > you seem to be right, but damn, submitting-patches.rst could be > clearer on the subject. > > I understand that it's addressed more to patch authors than > maintainers forwarding them, but I've read that thing a dozen times, > and the description of S-o-b always seemed to be about copyright. > > So I had assumed that edits which were below the de minimus standard > of copyright didn't need a separate S-o-b. > > Am I right that there should be an S-o-b from everyone from the > patch author to the patch committer (as recorded in git)? Yes, everyone either modifying or distributing (=submitting) the patch should add their s-o-b. > And the one exception is that we don't need S-o-b for git pulls after > that, because the merge commits record the information? Correct. When you do a git pull you are pulling the commits without any modification, so technically it's not even possible to add the s-o-b lines to the commits you are pulling. Modifying the commit logs would need a rebase and then it not would be a normal git pull anymore. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
