On Wed, Oct 29, 2014 at 11:38 AM, Scott Lovenberg
wrote:
> On Wed, Oct 29, 2014 at 12:05 AM, Sudip Mukherjee
> wrote:
>>
>> On Wed, Oct 29, 2014 at 7:31 AM, nick wrote:
>> > Greg,
>> > That's fine, I was wondering how long Greg KH takes to get around to
>> > picking this up as he is very busy w
On Wed, Oct 29, 2014 at 12:05 AM, Sudip Mukherjee
wrote:
>
> On Wed, Oct 29, 2014 at 7:31 AM, nick wrote:
> > Greg,
> > That's fine, I was wondering how long Greg KH takes to get around to
> > picking this up as he is very busy with
> > other kernel work.
>
> it might take a long long time. i th
On Wed, Oct 29, 2014 at 7:31 AM, nick wrote:
> Greg,
> That's fine, I was wondering how long Greg KH takes to get around to picking
> this up as he is very busy with
> other kernel work.
it might take a long long time. i think he is very busy now. I have
not seen his replies to patches in the ke
從我的 HTC 寄出
- Reply message -
寄件者： "Jeff Kirsher"
收件者： "nick"
副本： "Greg Donald" , "Greg Freemyer"
, "kernelnewbies"
主旨： [PATCH] staging: rtl8723au: Fix brace coding style issues reported by
checkpatch
日期： 週三, 10 月 29 日, 2014 年 10:04 上午
On Tue, 2014-10-28 at 22:01 -0400, nick wrote:
On Tue, Oct 28, 2014 at 03:58:40PM -0200, Raphael Philipe wrote:
> Hi,
>
> I'm developing a device driver to drive a specific custom hardware,
> that is implemented in FPGA. Since it is an application specific
> device driver, where (in witch folder) should I put Its source in my
> local kernel so
Sorry Jeff,
My fault, mistyped.
Cheers Nick
On 14-10-28 10:04 PM, Jeff Kirsher wrote:
> On Tue, 2014-10-28 at 22:01 -0400, nick wrote:
>> Greg,
>> That's fine, I was wondering how long Greg KH takes to get around to picking
>> this up as he is very busy with
>> other kernel work.
>> Cheers Nick
On Tue, 2014-10-28 at 22:01 -0400, nick wrote:
> Greg,
> That's fine, I was wondering how long Greg KH takes to get around to picking
> this up as he is very busy with
> other kernel work.
> Cheers Nick
I am Jeff and I was the one that responded...
>
> On 14-10-28 09:58 PM, Jeff Kirsher wrote:
Greg,
That's fine, I was wondering how long Greg KH takes to get around to picking
this up as he is very busy with
other kernel work.
Cheers Nick
On 14-10-28 09:58 PM, Jeff Kirsher wrote:
> On Tue, 2014-10-28 at 21:49 -0400, nick wrote:
>> Greg,
>> Not picked up of yet. I would appreciate if thi
On Tue, 2014-10-28 at 21:49 -0400, nick wrote:
> Greg,
> Not picked up of yet. I would appreciate if this gets forwarded for me as
> this may help it get picked up.
> Further more this issues I am were causing were not technical but not
> listening and that's why I decided
> to state around and l
Greg,
Not picked up of yet. I would appreciate if this gets forwarded for me as this
may help it get picked up.
Further more this issues I am were causing were not technical but not listening
and that's why I decided
to state around and learn how to my patches properly.
Cheers Nick
On 14-10-2
Hello
I have a question about this structure. It has 2 fields. One is iov_base
the pointer of type void. Second is iov_len of type size_t.
This is interesting: iov_len has always a value of 8190. How does it impact
the iov_base? I mean does iov_base is built from other structures? If soo
where I
On Tue, Oct 28, 2014 at 03:55:53PM -0500, Greg Donald wrote:
> On Tue, Oct 28, 2014 at 2:04 PM, John de la Garza wrote:
> > It seems like you assuming the limit is based on terminal size?
>
> Hmm, I thought it was because of 80 column punch cards and ancient
> printers that didn't wrap.
>
What
On Tue, Oct 28, 2014 at 2:52 PM, nick wrote:
> I am trying to improve my code as much as possible now, I really am finally
> understanding
> how terrible my code was before and I hope never again to make patches that
> shitty.
I don't think your recent progress has gone unnoticed. Any word on
On Tue, Oct 28, 2014 at 1:20 PM, Mandeep Sandhu
wrote:
> Just
> increase your font size so that it fits nicely in your editor from end to
> end! :P
I see :)
Sounds good but no. Increasing the font size just causes a loss of
screen real estate vertically.
--
Greg Donald
_
On Tue, Oct 28, 2014 at 2:04 PM, John de la Garza wrote:
> It seems like you assuming the limit is based on terminal size?
Hmm, I thought it was because of 80 column punch cards and ancient
printers that didn't wrap.
> There is some research in typography that suggests that it is easier
> to re
Hey Greg,
I am trying to improve my code as much as possible now, I really am finally
understanding
how terrible my code was before and I hope never again to make patches that
shitty.
Cheers Nick
On 14-10-28 02:06 PM, Greg Donald wrote:
> On Tue, Oct 28, 2014 at 12:53 PM, Nick Krause wrote:
>
On Tue, Oct 28, 2014 at 12:39:17PM -0500, Greg Donald wrote:
> The WARNING "line over 80 characters" currently accounts for 216K of
> the total violations. IMHO checkpatch should just stop complaining
> about the 80 char limit since that's the main offender causing new
> kernel developers to inadv
On Tue, 28 Oct 2014 12:39:17 -0500, Greg Donald said:
> The WARNING "line over 80 characters" currently accounts for 216K of
> the total violations. IMHO checkpatch should just stop complaining
> about the 80 char limit since that's the main offender causing new
On the other hand, there's very g
>
> > it's pointless. Increase it to a 21st century value or kill it.
> >
> >
> > --
> > Greg Donald
>
> But, but, but, what about all the kernel developers who are writing kernel
> code on VT100s and storing their sources on 80 column punch cards?
>
Lol, I agree!
There's nothing 21st century ab
> -Original Message-
> From: kernelnewbies-bounces+jharan=bytemobile@kernelnewbies.org
> [mailto:kernelnewbies-
> bounces+jharan=bytemobile@kernelnewbies.org] On Behalf Of Greg Donald
> Sent: Tuesday, October 28, 2014 10:39 AM
> To: Greg Freemyer
> Cc: kernelnewbies; Jeff Kirsher;
On Tue, Oct 28, 2014 at 12:53 PM, Nick Krause wrote:
> I actually fixed this to improve code readability not for the kernel
> rules for your information.
I know, good job.. and here's to hoping a maintainer picks up your
patch and applies it to their tree :)
But I would argue "kernel rules" and
Hi,
I'm developing a device driver to drive a specific custom hardware,
that is implemented in FPGA. Since it is an application specific
device driver, where (in witch folder) should I put Its source in my
local kernel source tree? Is there any guideline or best practice
about it?
This device dri
On Tue, Oct 28, 2014 at 1:39 PM, Greg Donald wrote:
> On Tue, Oct 28, 2014 at 11:50 AM, Greg Freemyer
> wrote:
>> Lots of violations
>> checkpatch finds are intentionally left in place because correcting
>> them makes the code less readable, not more readable.
>
> Yeah, but there are still hundr
On Tue, Oct 28, 2014 at 11:50 AM, Greg Freemyer wrote:
> Lots of violations
> checkpatch finds are intentionally left in place because correcting
> them makes the code less readable, not more readable.
Yeah, but there are still hundreds of thousands of checkpatch
violations throughout the kernel
On Tue, Oct 28, 2014 at 4:24 AM, Jeff Kirsher
wrote:
> On Sun, Oct 26, 2014 at 12:52 PM, Nicholas Krause wrote:
>> Fix all opening and closing braces issues reported by checkpatch.
>> Signed-off-by: Nicholas Krause
>> ---
>> drivers/staging/rtl8723au/core/rtw_ap.c | 138
>> ++--
Hi Pranay,
Thanks a bunch for nice explanation.
Best Regards,
Krishna
On Mon, Oct 27, 2014 at 10:34 PM, Pranay Srivastava
wrote:
> On Mon, Oct 27, 2014 at 8:08 PM, Er Krishna wrote:
> > Hi Valdis,
> >
> > Many thanks for the mail and quick answers. Regarding the point 4 I know
> > there won't
Fix the curley braces that do not reside on the same line because
this does not follow the kernel coding style and causes checkpatch.pl
warnings.
Signed-off-by: Nicholas Krause
---
drivers/staging/rtl8723au/core/rtw_ap.c | 138 ++--
1 file changed, 43 insertions(+), 95
On Sun, Oct 26, 2014 at 12:52 PM, Nicholas Krause wrote:
> Fix all opening and closing braces issues reported by checkpatch.
> Signed-off-by: Nicholas Krause
> ---
> drivers/staging/rtl8723au/core/rtw_ap.c | 138
> ++--
> 1 file changed, 43 insertions(+), 95 deletion
28 matches
Mail list logo
