Re: Send a large patch right now or is it better to do it later?
On Fri, Jul 28, 2017 at 05:16:56PM +0200, Marcus Wolf wrote: > Hi Greg, > > according to the proposals of Walter Harms, I revised the rf69.c: I replaced > some macros with inline functions and removed some obsolete ifdefs. According > to > walter this will improve the resource situation. In addition the readybility > is > enhanced, since lines got shorter. It's a quite big change, that touched > nearly > every function in that file. Just send your patches, we can't discuss them without seeing them. > I was testing the new code for a while now and did not observer a problem so > far. But I don't have a kind of unit test, so my tests for sure didn't cover > everything. Any sort of testing is probably better than 70% of staging patches. :P > > Is it a good time, to submit such a change in these days, or is it prefrable > to > submit it later? It doesn't matter when you send patches. > In adition, I am a bit afraid of my current mailtool doing something > unexpected... > > If you like, I can give it a try! > > Cheers, > > Marcus > P.S. Can you process diffs fom SVN, too, or is it mandatory to create the diff > with git? The patches have to be able to be applied with `cat email.txt | git am`. If you're renaming or moving files, then use git diff. Otherwise it's all fine. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: pi433: fix some warnings detected using sparse
On Fri, 2017-07-28 at 17:17 +0300, Dan Carpenter wrote:
> On Fri, Jul 28, 2017 at 02:56:26PM +0200, Elia Geretto wrote:
> > This patch corrects some visibility issues regarding some functions
> > and
> > solves a warning related to a non-matching union. After this patch,
> > sparse produces only one other warning regarding a bitwise
> > operator;
> > however, this behaviour seems to be intended.
>
> I can't understand this changelog at all :/ What are we fixing
> exactly? It seems like we're fixing something about bitwise
> operators... I guess let me check the Sparse warnings... Here they
> are
> from the latest linux-next:
>
> drivers/staging/pi433/pi433_if.c:211:9: warning: mixing different
> enum types
> drivers/staging/pi433/pi433_if.c:211:9: int enum
> optionOnOff versus
> drivers/staging/pi433/pi433_if.c:211:9: int enum packetFormat
> drivers/staging/pi433/pi433_if.c:211:9: warning: mixing different
> enum types
> drivers/staging/pi433/pi433_if.c:211:9: int enum
> optionOnOff versus
> drivers/staging/pi433/pi433_if.c:211:9: int enum packetFormat
> drivers/staging/pi433/pi433_if.c:268:9: warning: mixing different
> enum types
> drivers/staging/pi433/pi433_if.c:268:9: int enum
> optionOnOff versus
> drivers/staging/pi433/pi433_if.c:268:9: int enum packetFormat
> drivers/staging/pi433/pi433_if.c:268:9: warning: mixing different
> enum types
> drivers/staging/pi433/pi433_if.c:268:9: int enum
> optionOnOff versus
> drivers/staging/pi433/pi433_if.c:268:9: int enum packetFormat
> drivers/staging/pi433/pi433_if.c:317:1: warning: symbol
> 'pi433_receive' was not declared. Should it be static?
> drivers/staging/pi433/pi433_if.c:467:1: warning: symbol
> 'pi433_tx_thread' was not declared. Should it be static?
> drivers/staging/pi433/pi433_if.c:1155:36: error: incompatible types
> for operation (<)
> drivers/staging/pi433/pi433_if.c:1155:36:left side has type
> struct task_struct *tx_task_struct
> drivers/staging/pi433/pi433_if.c:1155:36:right side has type int
> drivers/staging/pi433/rf69.c:206:17: warning: dubious: x & !y
> drivers/staging/pi433/rf69.c:436:5: warning: symbol
> 'rf69_set_bandwidth_intern' was not declared. Should it be static?
>
> Each type of fix should be sent as a separate fix with a better
> changelog. People have already done the "static" fixes and IS_ERR()
> fixes, so don't worry about those. But I don't think anyway has
> fixed
> the enum issues so resend that. Also the bitwise thing is a real
> bug,
> but there is already a fix for that, it just hasn't been merged yet.
>
> >
> > Signed-off-by: Elia Geretto
> > ---
> > drivers/staging/pi433/pi433_if.c | 17 +++--
> > drivers/staging/pi433/rf69.c | 4 +++-
> > 2 files changed, 14 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/staging/pi433/pi433_if.c
> > b/drivers/staging/pi433/pi433_if.c
> > index d9328ce5ec1d..f8219a53ce60 100644
> > --- a/drivers/staging/pi433/pi433_if.c
> > +++ b/drivers/staging/pi433/pi433_if.c
> > @@ -208,7 +208,10 @@ rf69_set_rx_cfg(struct pi433_device *dev,
> > struct pi433_rx_cfg *rx_cfg)
> > {
> > SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi,
> > always));
> > }
> > - SET_CHECKED(rf69_set_packet_format (dev->spi, rx_cfg-
> > >enable_length_byte));
> > + if (rx_cfg->enable_length_byte == optionOn)
> > + SET_CHECKED(rf69_set_packet_format(dev->spi,
> > packetLengthVar));
> > + else
> > + SET_CHECKED(rf69_set_packet_format(dev->spi,
> > packetLengthFix));
>
> The SET_CHECKED() macro is total garbage. It has a hidden return and
> it calls the rf69_set_packet_format() twice on error it expands to:
>
> if (rf69_set_packet_format(dev->spi, rx_cfg-
> >enable_length_byte)) < 0)
> return rf69_set_packet_format(dev->spi, rx_cfg-
> >enable_length_byte);
>
> Mega turbo barf! Kill it with fire!
>
> regards,
> dan carpenter
>
I will resend a separate patch containing the enum work; I apologize
for the unclear changelog, I am still trying to understand how much in
detail I should go. Next time I will be more precise.
Regards,
Elia Geretto
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
Hi Greg,
already had a discussion concerning that patch with Dan yesterday.
I really don't know what's going on there. I detached the patch once more from
my outbox and had a very close look in an editor and looked at it with a
difftool. In my outbox the patch is fine. I really don't knwo why it reaches you
crapped.
Since there are contsant problems with my patches, I will stop sending patches
for a while. As soon as I can find time to deeply confess with the tooling, I
will start over with trying.
Concerning this patch: You can use Arnds Patch from yesterday instead:
[PATCH] staging: pi433: use div_u64 for 64-bit division
It's a bit different to my patch, but according to yesterdays discussion, it
should also fix the problem.
Sorry for any inconvenience,
Marcus
> Greg KH hat am 29. Juli 2017 um 02:01
> geschrieben:
>
>
> On Thu, Jul 20, 2017 at 05:56:36PM +0200, Marcus Wolf wrote:
> > Fixes problem with division in rf69_set_deviation
> >
> > Fixes: 874bcba65f9a ("staging: pi433: New driver")
> > Signed-off-by: Marcus Wolf
> >
> > diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
> > --- a/drivers/staging/pi433/rf69.c
> > +++ b/drivers/staging/pi433/rf69.c
> > @@ -221,7 +221,7 @@ int rf69_set_frequency(struct spi_device *spi, u32
> > frequency)
>
> Patch is line-wrapped and does not apply :(
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1][staging-next] staging: pi433: Make functions rf69_set_dc_cut_off_frequency_intern static
Hi Greg, also had a very close look to this patch. Even in your reply I can't find any problems with line wraps or other corruptions :-/ But we have alternative patches, solving these problems as well. You e.g. could use the patch [PATCH] Make functions rf69_set_bandwidth_intern and rf69_set_dc_cut_off_frequency_intern static from Colin King 21/07/2017. It's doing exactly the same, my patch should have done. But be careful - tonight you added patch staging: pi433: Make functions rf69_set_bandwidth_intern static" Clins patch includes that changes as well! Once again sorry for my crappy patches, Marcus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Concerning [PATCH] staging: pi433: fix bugs in register abstraction of rf69 chip
Hi Greg, there is another patch from me (see subject). I sent it 19/07/2017. Most probably, there is also something wrong with the patch, but maybe you can get it to work. The patch would be important. It doesn't fix any warnings or errors of static code analysis, but it fixes true implementation errors (wrong access of registers). From my point of view, that is one of the most important changes to the code, we had during the last weeks. Thanks, Marcus ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: pi433: Use matching enum types calling rf69_set_packet_format
This patch fixes the following four warnings found using sparse:
drivers/staging/pi433/pi433_if.c:211:9: warning: mixing different enum types
drivers/staging/pi433/pi433_if.c:211:9: int enum optionOnOff versus
drivers/staging/pi433/pi433_if.c:211:9: int enum packetFormat
drivers/staging/pi433/pi433_if.c:211:9: warning: mixing different enum types
drivers/staging/pi433/pi433_if.c:211:9: int enum optionOnOff versus
drivers/staging/pi433/pi433_if.c:211:9: int enum packetFormat
drivers/staging/pi433/pi433_if.c:268:9: warning: mixing different enum types
drivers/staging/pi433/pi433_if.c:268:9: int enum optionOnOff versus
drivers/staging/pi433/pi433_if.c:268:9: int enum packetFormat
drivers/staging/pi433/pi433_if.c:268:9: warning: mixing different enum types
drivers/staging/pi433/pi433_if.c:268:9: int enum optionOnOff versus
drivers/staging/pi433/pi433_if.c:268:9: int enum packetFormat
This is done calling the rf69_set_packet_format function using the
appropriate enum for the packetFormat argument.
Signed-off-by: Elia Geretto
---
drivers/staging/pi433/pi433_if.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index d9328ce5ec1d..fc2250810eed 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -208,7 +208,17 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
{
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, always));
}
- SET_CHECKED(rf69_set_packet_format (dev->spi,
rx_cfg->enable_length_byte));
+ if (rx_cfg->enable_length_byte == optionOn) {
+ int ret = rf69_set_packet_format(dev->spi, packetLengthVar);
+
+ if (ret < 0)
+ return ret;
+ } else {
+ int ret = rf69_set_packet_format(dev->spi, packetLengthFix);
+
+ if (ret < 0)
+ return ret;
+ }
SET_CHECKED(rf69_set_adressFiltering(dev->spi,
rx_cfg->enable_address_filtering));
SET_CHECKED(rf69_set_crc_enable (dev->spi, rx_cfg->enable_crc));
@@ -264,8 +274,18 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
{
SET_CHECKED(rf69_set_preamble_length(dev->spi, 0));
}
+ if (tx_cfg->enable_length_byte == optionOn) {
+ int ret = rf69_set_packet_format(dev->spi, packetLengthVar);
+
+ if (ret < 0)
+ return ret;
+ } else {
+ int ret = rf69_set_packet_format(dev->spi, packetLengthFix);
+
+ if (ret < 0)
+ return ret;
+ }
SET_CHECKED(rf69_set_sync_enable (dev->spi, tx_cfg->enable_sync));
- SET_CHECKED(rf69_set_packet_format(dev->spi,
tx_cfg->enable_length_byte));
SET_CHECKED(rf69_set_crc_enable (dev->spi, tx_cfg->enable_crc));
/* configure sync, if enabled */
--
2.13.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Undelivered Mail Returned to Sender
This is the mail system at host vscan68.melbpc.org.au. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : delivery temporarily suspended: connect to numbat.melbpc.org.au[203.12.152.22]:25: No route to host Reporting-MTA: dns; vscan68.melbpc.org.au X-Postfix-Queue-ID: AD2896954 X-Postfix-Sender: rfc822; devel@driverdev.osuosl.org Arrival-Date: Fri, 28 Jul 2017 19:55:04 +1000 (EST) Final-Recipient: rfc822; billm@numbat.melbpc.org.au Original-Recipient: rfc822;billm@numbat.melbpc.org.au Action: failed Status: 4.4.1 Diagnostic-Code: X-Postfix; delivery temporarily suspended: connect to numbat.melbpc.org.au[203.12.152.22]:25: No route to host --- Begin Message --- The original message was received at Fri, 28 Jul 2017 18:01:44 +0800 from driverdev.osuosl.org [24.71.29.215] - The following addresses had permanent fatal errors - - Transcript of session follows - while talking to melbpc.org.au.: >>> MAIL From:de...@driverdev.osuosl.org <<< 501 de...@driverdev.osuosl.org... Refused *** ** Attachment text.zip was infected with I-Worm.Mydoom.Q1 virus, ** attachment part was removed. *** --- End Message --- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: octeon: fix line over 80 characters
Hi John,
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.13-rc2 next-20170728]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/catalinnow-gmail-com/staging-octeon-fix-line-over-80-characters/20170728-071556
config: mips-cavium_octeon_defconfig (attached as .config)
compiler: mips64-linux-gnuabi64-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=mips
All warnings (new ones prefixed by >>):
drivers/staging/octeon/ethernet-rx.c: In function 'copy_segments_to_skb':
>> drivers/staging/octeon/ethernet-rx.c:173:3: warning: ISO C90 forbids mixed
>> declarations and code [-Wdeclaration-after-statement]
int segment_size =
^~~
vim +173 drivers/staging/octeon/ethernet-rx.c
151
152 static void copy_segments_to_skb(cvmx_wqe_t *work, struct sk_buff *skb)
153 {
154 int segments = work->word2.s.bufs;
155 union cvmx_buf_ptr segment_ptr = work->packet_ptr;
156 int len = work->word1.len;
157
158 while (segments--) {
159 union cvmx_buf_ptr next_ptr;
160
161 next_ptr = *(union cvmx_buf_ptr *)
162 cvmx_phys_to_ptr(segment_ptr.s.addr - 8);
163
164 /*
165 * Octeon Errata PKI-100: The segment size is wrong.
166 *
167 * Until it is fixed, calculate the segment size based
on
168 * the packet pool buffer size.
169 * When it is fixed, the following line should be
replaced
170 * with this one:
171 * int segment_size = segment_ptr.s.size;
172 */
> 173 int segment_size =
174 CVMX_FPA_PACKET_POOL_SIZE -
175 (segment_ptr.s.addr -
176 (((segment_ptr.s.addr >> 7) -
177 segment_ptr.s.back) << 7));
178
179 /* Don't copy more than what is left in the packet */
180 if (segment_size > len)
181 segment_size = len;
182
183 /* Copy the data into the packet */
184 skb_put_data(skb, cvmx_phys_to_ptr(segment_ptr.s.addr),
185 segment_size);
186 len -= segment_size;
187 segment_ptr = next_ptr;
188 }
189 }
190
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Concerning [PATCH] staging: pi433: fix bugs in register abstraction of rf69 chip
On Sat, Jul 29, 2017 at 11:16:11AM +0200, Marcus Wolf wrote: > Hi Greg, > > there is another patch from me (see subject). I sent it 19/07/2017. > > Most probably, there is also something wrong with the patch, but maybe you can > get it to work. > > The patch would be important. It doesn't fix any warnings or errors of static > code analysis, but it fixes true implementation errors (wrong access of > registers). It does fix some static checker warnings for me... ;) And I've been working on making add even more checker complaints inspired by that patch but haven't finished. > From my point of view, that is one of the most important changes to > the code, we had during the last weeks. The patch applies fine so no worries. Anyway, just send some patches to yourself and try applying them with `git am`. That's what everyone is doing on the recieving end. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1][staging-next] staging: pi433: Make functions rf69_set_dc_cut_off_frequency_intern static
On Sat, Jul 29, 2017 at 11:09:23AM +0200, Marcus Wolf wrote: > Hi Greg, > > also had a very close look to this patch. Even in your reply I can't find any > problems with line wraps or other corruptions :-/ > Here are the relevant lines from Greg's email: > +++ b/drivers/staging/pi433/rf69.c > @@ -221,7 +221,7 @@ int rf69_set_frequency(struct spi_device *spi, u32 > frequency) The "frequency)" bit is supposed to be on the line before. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Concerning [PATCH] staging: pi433: fix bugs in register abstraction of rf69 chip
Hi Dan, the "big" patch, I was telling about yesterday will touch exactly that file. So if you are planning deep changes, we will most probably run into conflicts. If I'll find some time (maybe tomorrow), I'll try to send that long patch, so you can see. Already nervous about next failing patch :-( Cheers, Marcus > Dan Carpenter hat am 29. Juli 2017 um 12:52 > geschrieben: > > > On Sat, Jul 29, 2017 at 11:16:11AM +0200, Marcus Wolf wrote: > > Hi Greg, > > > > there is another patch from me (see subject). I sent it 19/07/2017. > > > > Most probably, there is also something wrong with the patch, but maybe you > > can > > get it to work. > > > > The patch would be important. It doesn't fix any warnings or errors of > > static > > code analysis, but it fixes true implementation errors (wrong access of > > registers). > > It does fix some static checker warnings for me... ;) And I've been > working on making add even more checker complaints inspired by that > patch but haven't finished. > > > From my point of view, that is one of the most important changes to > > the code, we had during the last weeks. > > The patch applies fine so no worries. > > Anyway, just send some patches to yourself and try applying them with > `git am`. That's what everyone is doing on the recieving end. > > regards, > dan carpenter > > > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: pi433: fix some warnings detected using sparse
Hi Elia,
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on next-20170728]
[cannot apply to v4.13-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Elia-Geretto/Staging-pi433-fix-some-warnings-detected-using-sparse/20170729-205713
config: blackfin-allyesconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All errors (new ones prefixed by >>):
drivers/staging//pi433/pi433_if.c: In function 'rf69_set_rx_cfg':
>> drivers/staging//pi433/pi433_if.c:213:2: error: 'else' without a previous
>> 'if'
else
^~~~
drivers/staging//pi433/pi433_if.c: In function 'rf69_set_tx_cfg':
drivers/staging//pi433/pi433_if.c:272:2: error: 'else' without a previous
'if'
else
^~~~
vim +213 drivers/staging//pi433/pi433_if.c
181
182 static int
183 rf69_set_rx_cfg(struct pi433_device *dev, struct pi433_rx_cfg *rx_cfg)
184 {
185 int payload_length;
186
187 /* receiver config */
188 SET_CHECKED(rf69_set_frequency (dev->spi, rx_cfg->frequency));
189 SET_CHECKED(rf69_set_bit_rate (dev->spi, rx_cfg->bit_rate));
190 SET_CHECKED(rf69_set_modulation (dev->spi, rx_cfg->modulation));
191 SET_CHECKED(rf69_set_antenna_impedance (dev->spi,
rx_cfg->antenna_impedance));
192 SET_CHECKED(rf69_set_rssi_threshold (dev->spi,
rx_cfg->rssi_threshold));
193 SET_CHECKED(rf69_set_ook_threshold_dec (dev->spi,
rx_cfg->thresholdDecrement));
194 SET_CHECKED(rf69_set_bandwidth (dev->spi,
rx_cfg->bw_mantisse, rx_cfg->bw_exponent));
195 SET_CHECKED(rf69_set_bandwidth_during_afc(dev->spi,
rx_cfg->bw_mantisse, rx_cfg->bw_exponent));
196 SET_CHECKED(rf69_set_dagc(dev->spi,
rx_cfg->dagc));
197
198 dev->rx_bytes_to_drop = rx_cfg->bytes_to_drop;
199
200 /* packet config */
201 /* enable */
202 SET_CHECKED(rf69_set_sync_enable(dev->spi,
rx_cfg->enable_sync));
203 if (rx_cfg->enable_sync == optionOn)
204 {
205 SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi,
afterSyncInterrupt));
206 }
207 else
208 {
209 SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi,
always));
210 }
211 if (rx_cfg->enable_length_byte == optionOn)
212 SET_CHECKED(rf69_set_packet_format(dev->spi,
packetLengthVar));
> 213 else
214 SET_CHECKED(rf69_set_packet_format(dev->spi,
packetLengthFix));
215 SET_CHECKED(rf69_set_adressFiltering(dev->spi,
rx_cfg->enable_address_filtering));
216 SET_CHECKED(rf69_set_crc_enable (dev->spi,
rx_cfg->enable_crc));
217
218 /* lengths */
219 SET_CHECKED(rf69_set_sync_size(dev->spi, rx_cfg->sync_length));
220 if (rx_cfg->enable_length_byte == optionOn)
221 {
222 SET_CHECKED(rf69_set_payload_length(dev->spi, 0xff));
223 }
224 else if (rx_cfg->fixed_message_length != 0)
225 {
226 payload_length = rx_cfg->fixed_message_length;
227 if (rx_cfg->enable_length_byte == optionOn)
payload_length++;
228 if (rx_cfg->enable_address_filtering != filteringOff)
payload_length++;
229 SET_CHECKED(rf69_set_payload_length(dev->spi,
payload_length));
230 }
231 else
232 {
233 SET_CHECKED(rf69_set_payload_length(dev->spi, 0));
234 }
235
236 /* values */
237 if (rx_cfg->enable_sync == optionOn)
238 {
239 SET_CHECKED(rf69_set_sync_values(dev->spi,
rx_cfg->sync_pattern));
240 }
241 if (rx_cfg->enable_address_filtering != filteringOff)
242 {
243 SET_CHECKED(rf69_set_node_address (dev->spi,
rx_cfg->node_address));
244 SET_CHECKED(rf69_set_broadcast_address(dev->spi,
rx_cfg->broadcast_address));
245 }
246
247 return 0;
248 }
249
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: rtl8723bs: Do not initialise static to 0.
Do not initialise static to 0.
Static variables by default initialise to 0.
This patch fixes the errors found by checkpatch.
Signed-off-by: Shreeya Patel
---
drivers/staging/rtl8723bs/core/rtw_mlme.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_mlme_ext.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_pwrctrl.c | 4 ++--
drivers/staging/rtl8723bs/core/rtw_recv.c | 2 +-
drivers/staging/rtl8723bs/core/rtw_security.c | 14 +++---
drivers/staging/rtl8723bs/core/rtw_xmit.c | 4 ++--
6 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme.c
b/drivers/staging/rtl8723bs/core/rtw_mlme.c
index d5ab123..260e23f 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme.c
@@ -1384,7 +1384,7 @@ static void rtw_joinbss_update_network(struct adapter
*padapter, struct wlan_net
/* define REJOIN */
void rtw_joinbss_event_prehandle(struct adapter *adapter, u8 *pbuf)
{
- static u8 retry = 0;
+ static u8 retry;
u8 timer_cancelled;
struct sta_info *ptarget_sta = NULL, *pcur_sta = NULL;
struct sta_priv *pstapriv = &adapter->stapriv;
diff --git a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
index 17d881d..99e3b68 100644
--- a/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723bs/core/rtw_mlme_ext.c
@@ -2392,7 +2392,7 @@ s32 dump_mgntframe_and_wait(struct adapter *padapter,
struct xmit_frame *pmgntfr
s32 dump_mgntframe_and_wait_ack(struct adapter *padapter, struct xmit_frame
*pmgntframe)
{
- static u8 seq_no = 0;
+ static u8 seq_no;
s32 ret = _FAIL;
u32 timeout_ms = 500;/* 500ms */
struct xmit_priv *pxmitpriv = &padapter->xmitpriv;
diff --git a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
index f708dbf..f060e54 100644
--- a/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
+++ b/drivers/staging/rtl8723bs/core/rtw_pwrctrl.c
@@ -210,8 +210,8 @@ void pwr_state_check_handler(RTW_TIMER_HDL_ARGS)
void traffic_check_for_leave_lps(struct adapter *padapter, u8 tx, u32
tx_packets)
{
- static unsigned long start_time = 0;
- static u32 xmit_cnt = 0;
+ static unsigned long start_time;
+ static u32 xmit_cnt;
u8 bLeaveLPS = false;
struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c
b/drivers/staging/rtl8723bs/core/rtw_recv.c
index 695a5c9..c6018f0 100644
--- a/drivers/staging/rtl8723bs/core/rtw_recv.c
+++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
@@ -1005,7 +1005,7 @@ sint ap2sta_data_frame(
if (*psta == NULL) {
/* for AP multicast issue , modify by yiwei */
- static unsigned long send_issue_deauth_time = 0;
+ static unsigned long send_issue_deauth_time;
/* DBG_871X("After send deauth , %u ms has
elapsed.\n", jiffies_to_msecs(jiffies - send_issue_deauth_time)); */
diff --git a/drivers/staging/rtl8723bs/core/rtw_security.c
b/drivers/staging/rtl8723bs/core/rtw_security.c
index e832f16..06a7e40 100644
--- a/drivers/staging/rtl8723bs/core/rtw_security.c
+++ b/drivers/staging/rtl8723bs/core/rtw_security.c
@@ -162,7 +162,7 @@ static void arcfour_encrypt(
dest[i] = src[i] ^ (unsigned char)arcfour_byte(parc4ctx);
}
-static sint bcrc32initialized = 0;
+static sint bcrc32initialized;
static u32 crc32_table[256];
@@ -791,9 +791,9 @@ u32 rtw_tkip_decrypt(struct adapter *padapter, u8
*precvframe)
stainfo = rtw_get_stainfo(&padapter->stapriv,
&prxattrib->ta[0]);
if (stainfo != NULL) {
if (IS_MCAST(prxattrib->ra)) {
- static unsigned long start = 0;
- static u32 no_gkey_bc_cnt = 0;
- static u32 no_gkey_mc_cnt = 0;
+ static unsigned long start;
+ static u32 no_gkey_bc_cnt;
+ static u32 no_gkey_mc_cnt;
if (psecuritypriv->binstallGrpkey == false) {
res = _FAIL;
@@ -1882,9 +1882,9 @@ u32 rtw_aes_decrypt(struct adapter *padapter, u8
*precvframe)
RT_TRACE(_module_rtl871x_security_c_, _drv_err_,
("rtw_aes_decrypt: stainfo!= NULL!!!\n"));
if (IS_MCAST(prxattrib->ra)) {
- static unsigned long start = 0;
- static u32 no_gkey_bc_cnt = 0;
- static u32 no_gkey_mc_cnt = 0;
+ static unsigned long start;
+ static u32 no_gkey_bc_cnt;
+ static u32 no_gk
Re: [PATCH 1/1] staging: pi433: fix problem with division in rf69_set_deviation
On Sat, Jul 29, 2017 at 10:51:15AM +0200, Marcus Wolf wrote: > Hi Greg, > > already had a discussion concerning that patch with Dan yesterday. > I really don't know what's going on there. I detached the patch once more from > my outbox and had a very close look in an editor and looked at it with a > difftool. In my outbox the patch is fine. I really don't knwo why it reaches > you > crapped. > > Since there are contsant problems with my patches, I will stop sending patches > for a while. As soon as I can find time to deeply confess with the tooling, I > will start over with trying. Just use 'git send-email' for patches if you are having problems with your email client. And get a better email client the kernel Documentation has a whole file just about that topic and how to do it correctly. > Concerning this patch: You can use Arnds Patch from yesterday instead: > [PATCH] staging: pi433: use div_u64 for 64-bit division > It's a bit different to my patch, but according to yesterdays discussion, it > should also fix the problem. I already took it into my tree. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next v3 0/7] netvsc: minor fixes and optimization
From: Stephen Hemminger Date: Fri, 28 Jul 2017 08:59:40 -0700 > This is a subset of earlier submission with a few more fixes > found during testing. The are two small optimizations, one is to > better manage the receive completion ring, and the other is removing > one unneeded level of indirection. > > Will submit the improved VF support and buffer sizing in a later > patch so they get more review. Series applied, thanks Stephen. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
