[PATCH] usb: Fix switch statement in ohci-tmio.c

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nicholas Krause]

I am fixing the bug on at the link, https://bugzilla.kernel.org/show_bug.cgi?id=79931.
This bug report states that in the function, tmio_hc_stop the switch has no needed breaks.
Further more this patch fixes this bug by adding the needed breaks.

Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
---
 drivers/usb/host/ohci-tmio.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
index bb40958..d2b5382 100644
--- a/drivers/usb/host/ohci-tmio.c
+++ b/drivers/usb/host/ohci-tmio.c
@@ -100,12 +100,16 @@ static void tmio_stop_hc(struct platform_device *dev)
 	switch (ohci->num_ports) {
 		default:
 			dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports);
+			break;
 		case 3:
 			pm |= CCR_PM_USBPW3;
+			break;
 		case 2:
 			pm |= CCR_PM_USBPW2;
+			break;
 		case 1:
 			pm |= CCR_PM_USBPW1;
+			break;
 	}
 	tmio_iowrite8(0, tmio->ccr + CCR_INTC);
 	tmio_iowrite8(0, tmio->ccr + CCR_ILME);
-- 
1.9.1

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 2:05 PM, Nicholas Krause <xerofoify@gmail.com> wrote:
> I am fixing the bug on at the link, https://bugzilla.kernel.org/show_bug.cgi?id=79931.
> This bug report states that in the function, tmio_hc_stop the switch has no needed breaks.
> Further more this patch fixes this bug by adding the needed breaks.
>
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> ---
>  drivers/usb/host/ohci-tmio.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
> index bb40958..d2b5382 100644
> --- a/drivers/usb/host/ohci-tmio.c
> +++ b/drivers/usb/host/ohci-tmio.c
> @@ -100,12 +100,16 @@ static void tmio_stop_hc(struct platform_device *dev)
>         switch (ohci->num_ports) {
>                 default:
>                         dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports);
> +                       break;
>                 case 3:
>                         pm |= CCR_PM_USBPW3;
> +                       break;
>                 case 2:
>                         pm |= CCR_PM_USBPW2;
> +                       break;
>                 case 1:
>                         pm |= CCR_PM_USBPW1;
> +                       break;
>         }
>         tmio_iowrite8(0, tmio->ccr + CCR_INTC);
>         tmio_iowrite8(0, tmio->ccr + CCR_ILME);
> --
> 1.9.1
>

If someone wants to send out this patch for me,that would be great :).
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Kristofer Hallin]

Please Nick, stop spamming the list with your patches. I _really_
doubt that anyone ever will try to get your patches merged since
you've managed to get banned from vger and got a somewhat flawed
reputation.

On Thu, Aug 14, 2014 at 8:06 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Thu, Aug 14, 2014 at 2:05 PM, Nicholas Krause <xerofoify@gmail.com> wrote:
>> I am fixing the bug on at the link, https://bugzilla.kernel.org/show_bug.cgi?id=79931.
>> This bug report states that in the function, tmio_hc_stop the switch has no needed breaks.
>> Further more this patch fixes this bug by adding the needed breaks.
>>
>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>> ---
>>  drivers/usb/host/ohci-tmio.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
>> index bb40958..d2b5382 100644
>> --- a/drivers/usb/host/ohci-tmio.c
>> +++ b/drivers/usb/host/ohci-tmio.c
>> @@ -100,12 +100,16 @@ static void tmio_stop_hc(struct platform_device *dev)
>>         switch (ohci->num_ports) {
>>                 default:
>>                         dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports);
>> +                       break;
>>                 case 3:
>>                         pm |= CCR_PM_USBPW3;
>> +                       break;
>>                 case 2:
>>                         pm |= CCR_PM_USBPW2;
>> +                       break;
>>                 case 1:
>>                         pm |= CCR_PM_USBPW1;
>> +                       break;
>>         }
>>         tmio_iowrite8(0, tmio->ccr + CCR_INTC);
>>         tmio_iowrite8(0, tmio->ccr + CCR_ILME);
>> --
>> 1.9.1
>>
>
> If someone wants to send out this patch for me,that would be great :).
> Nick
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 2:13 PM, Kristofer Hallin
<kristofer.hallin@gmail.com> wrote:
> Please Nick, stop spamming the list with your patches. I _really_
> doubt that anyone ever will try to get your patches merged since
> you've managed to get banned from vger and got a somewhat flawed
> reputation.
>
> On Thu, Aug 14, 2014 at 8:06 PM, Nick Krause <xerofoify@gmail.com> wrote:
>> On Thu, Aug 14, 2014 at 2:05 PM, Nicholas Krause <xerofoify@gmail.com> wrote:
>>> I am fixing the bug on at the link, https://bugzilla.kernel.org/show_bug.cgi?id=79931.
>>> This bug report states that in the function, tmio_hc_stop the switch has no needed breaks.
>>> Further more this patch fixes this bug by adding the needed breaks.
>>>
>>> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
>>> ---
>>>  drivers/usb/host/ohci-tmio.c | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
>>> index bb40958..d2b5382 100644
>>> --- a/drivers/usb/host/ohci-tmio.c
>>> +++ b/drivers/usb/host/ohci-tmio.c
>>> @@ -100,12 +100,16 @@ static void tmio_stop_hc(struct platform_device *dev)
>>>         switch (ohci->num_ports) {
>>>                 default:
>>>                         dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports);
>>> +                       break;
>>>                 case 3:
>>>                         pm |= CCR_PM_USBPW3;
>>> +                       break;
>>>                 case 2:
>>>                         pm |= CCR_PM_USBPW2;
>>> +                       break;
>>>                 case 1:
>>>                         pm |= CCR_PM_USBPW1;
>>> +                       break;
>>>         }
>>>         tmio_iowrite8(0, tmio->ccr + CCR_INTC);
>>>         tmio_iowrite8(0, tmio->ccr + CCR_ILME);
>>> --
>>> 1.9.1
>>>
>>
>> If someone wants to send out this patch for me,that would be great :).
>> Nick
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kristofer,
I understand that too but this patch works and builds I have tested it
completely.
Look I got off on the wrong start and I am starting to improve my repo but seems
impossible if people are just going to forget about my good patches.
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Lucas Tanure]

Nick,

To clean to clean up your online reputation take a long vacation.
*Seriously*.
Do not send any more e-mail, patch or apologize.

You do not need to be a kernel developer right now. You can restart next
year.
For now, just read, read this list, read other lists.

You are trying to rush to archive something that take years to accomplish.
Please take my advice, go away, and come next year. *Seriously*.

In the meantime, read books about linux, install Gentoo linux or arch
linux, do linux tutorials, build you hello world kernel module, make a
appointment with a psychologist. *Seriously. *

We need to forget about you for a while.

Thanks

Tanure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140814/f41b6950/attachment.html 

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Valdis.Kletnieks at vt.edu]

On Thu, 14 Aug 2014 14:18:40 -0400, Nick Krause said:

> >>>                 case 3:
> >>>                         pm |= CCR_PM_USBPW3;
> >>> +                       break;
> >>>                 case 2:
> >>>                         pm |= CCR_PM_USBPW2;
> >>> +                       break;
> >>>                 case 1:
> >>>                         pm |= CCR_PM_USBPW1;
> >>> +                       break;

> I understand that too but this patch works and builds I have tested it
> completely.

No, you haven't.  Far from it.

If you were testing it "completely", you would have found an actual Toshiba
Mobile or other hardware that uses this driver, and had logs to show how it
used to misbehave due to this bug, and that it worked correctly now.

And you would have noticed, and explained, why the #defines for
CCR_PM_USBPW2 and CCR_PM_USBPW3 are the same value.  In fact, that's
why the compiler whined, *not* because of the missing break; code.  So
sticking in breaks and not even mentioning the #defines shows that you
did ABSOLUTELY ZERO to actually understand what the compiler was telling you.

Note that there's perfectly valid reasons for fall-through in a C switch -
see Tom Duff for a classic example (yes, Dennis Ritchie said it was valid C):

http://www.lysator.liu.se/c/duffs-device.html

The #defines could possibly be intentionally that way if the chip is weird and
uses 2 pins to control 3 ports in a non-intuitive way - and if they're
active-low bits even the lack of break; after the default: warning case could
be proper, disabling all ports if an invalid one is specified.

And there's no indication you even *bothered* to check that possibility - which
would mean applying your patch would break a properly written driver.

And even worse, there's no indication you actually understood what the
compile warning was telling you.

> Look I got off on the wrong start and I am starting to improve my repo but seems

If you think you're improving your rep with these poor patches, you're delusional.

> impossible if people are just going to forget about my good patches.

We'll discuss that when you actually submit one that isn't a steaming
pile of dingo's kidneys.

Do yourself a favor - try to resist the temptation to post a patch for at
least 30 to 60 days, *no matter how correct you think it is*.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140814/3021b06f/attachment.bin 

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 4:51 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 14 Aug 2014 14:18:40 -0400, Nick Krause said:
>
>> >>>                 case 3:
>> >>>                         pm |= CCR_PM_USBPW3;
>> >>> +                       break;
>> >>>                 case 2:
>> >>>                         pm |= CCR_PM_USBPW2;
>> >>> +                       break;
>> >>>                 case 1:
>> >>>                         pm |= CCR_PM_USBPW1;
>> >>> +                       break;
>
>> I understand that too but this patch works and builds I have tested it
>> completely.
>
> No, you haven't.  Far from it.
>
> If you were testing it "completely", you would have found an actual Toshiba
> Mobile or other hardware that uses this driver, and had logs to show how it
> used to misbehave due to this bug, and that it worked correctly now.
>
> And you would have noticed, and explained, why the #defines for
> CCR_PM_USBPW2 and CCR_PM_USBPW3 are the same value.  In fact, that's
> why the compiler whined, *not* because of the missing break; code.  So
> sticking in breaks and not even mentioning the #defines shows that you
> did ABSOLUTELY ZERO to actually understand what the compiler was telling you.
>
> Note that there's perfectly valid reasons for fall-through in a C switch -
> see Tom Duff for a classic example (yes, Dennis Ritchie said it was valid C):
>
> http://www.lysator.liu.se/c/duffs-device.html
>
> The #defines could possibly be intentionally that way if the chip is weird and
> uses 2 pins to control 3 ports in a non-intuitive way - and if they're
> active-low bits even the lack of break; after the default: warning case could
> be proper, disabling all ports if an invalid one is specified.
>
> And there's no indication you even *bothered* to check that possibility - which
> would mean applying your patch would break a properly written driver.
>
> And even worse, there's no indication you actually understood what the
> compile warning was telling you.
>
>> Look I got off on the wrong start and I am starting to improve my repo but seems
>
> If you think you're improving your rep with these poor patches, you're delusional.
>
>> impossible if people are just going to forget about my good patches.
>
> We'll discuss that when you actually submit one that isn't a steaming
> pile of dingo's kidneys.
>
> Do yourself a favor - try to resist the temptation to post a patch for at
> least 30 to 60 days, *no matter how correct you think it is*.


Very well then I will not do any more patches for the next month and
only read the list.
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Mandeep Sandhu]

>> Look I got off on the wrong start and I am starting to improve my repo but seems
>
> If you think you're improving your rep with these poor patches, you're delusional.
>
>> impossible if people are just going to forget about my good patches.
>
> We'll discuss that when you actually submit one that isn't a steaming
> pile of dingo's kidneys.
>
> Do yourself a favor - try to resist the temptation to post a patch for at
> least 30 to 60 days, *no matter how correct you think it is*.
>

Plz start listening to what people are telling you. Don't post patches
here. If you want to make them, fine. Keep them in your local machine
for now. Heed to the advice of seniors here otherwise people will just
start ignoring you _completely_ and you won't get any help after that.

Also, I've observed that you're not trying to understand what the code
is doing. You're looking at every build error/bug as a C programming
problem (which too unfortunately you're not understanding completely)
and have no clue of the context in which it's written. Thats why
Valdis and many others are finding so many faults in your 'patches'.
They are wrong at both levels!

Please go through some C tutorials and get a good grasp of the
language. Only _then_ attempt to get your hands dirty with kernel
code.

This is my last advice. After this, I will delete all patch related
emails from you without reading it.

Good luck,
-mandeep




> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 5:03 PM, Mandeep Sandhu
<mandeepsandhu.chd@gmail.com> wrote:
>>> Look I got off on the wrong start and I am starting to improve my repo but seems
>>
>> If you think you're improving your rep with these poor patches, you're delusional.
>>
>>> impossible if people are just going to forget about my good patches.
>>
>> We'll discuss that when you actually submit one that isn't a steaming
>> pile of dingo's kidneys.
>>
>> Do yourself a favor - try to resist the temptation to post a patch for at
>> least 30 to 60 days, *no matter how correct you think it is*.
>>
>
> Plz start listening to what people are telling you. Don't post patches
> here. If you want to make them, fine. Keep them in your local machine
> for now. Heed to the advice of seniors here otherwise people will just
> start ignoring you _completely_ and you won't get any help after that.
>
> Also, I've observed that you're not trying to understand what the code
> is doing. You're looking at every build error/bug as a C programming
> problem (which too unfortunately you're not understanding completely)
> and have no clue of the context in which it's written. Thats why
> Valdis and many others are finding so many faults in your 'patches'.
> They are wrong at both levels!
>
> Please go through some C tutorials and get a good grasp of the
> language. Only _then_ attempt to get your hands dirty with kernel
> code.
>
> This is my last advice. After this, I will delete all patch related
> emails from you without reading it.
>
> Good luck,
> -mandeep
>
>
>
>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>

Mandeep,
I am learned C. Perhaps I am a little rusty and need to review.
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Valdis.Kletnieks at vt.edu]

On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
> I am learned C. Perhaps I am a little rusty and need to review.

We've seen very little evidence that you *ever* really understood C
at all, and you're *far* from "a little rusty".  It's been some 23
years since I've hacked any code in IBM's Pascal/VS, and 29 since I
had to do maintenance work on PL/I code, and I *still* remember more
of those than you remember of C.  (I'll admit that my mad Snobol4 skilz
have pretty much evaporated, though ;)

http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20140814/a55ffb45/attachment.bin 

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 5:38 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
>> I am learned C. Perhaps I am a little rusty and need to review.
>
> We've seen very little evidence that you *ever* really understood C
> at all, and you're *far* from "a little rusty".  It's been some 23
> years since I've hacked any code in IBM's Pascal/VS, and 29 since I
> had to do maintenance work on PL/I code, and I *still* remember more
> of those than you remember of C.  (I'll admit that my mad Snobol4 skilz
> have pretty much evaporated, though ;)
>
> http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
 I learned C like two years ago and never really practiced it that
much to be honest.
 In addition I will come back in the future about I have read The C Programming
 Language.
Cheers Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Thu, Aug 14, 2014 at 5:38 PM,  <Valdis.Kletnieks@vt.edu> wrote:
>> On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
>>> I am learned C. Perhaps I am a little rusty and need to review.
>>
>> We've seen very little evidence that you *ever* really understood C
>> at all, and you're *far* from "a little rusty".  It's been some 23
>> years since I've hacked any code in IBM's Pascal/VS, and 29 since I
>> had to do maintenance work on PL/I code, and I *still* remember more
>> of those than you remember of C.  (I'll admit that my mad Snobol4 skilz
>> have pretty much evaporated, though ;)
>>
>> http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
>  I learned C like two years ago and never really practiced it that
> much to be honest.
>  In addition I will come back in the future about I have read The C Programming
>  Language.
> Cheers Nick
Thanks for pointing me in the right direction , I really do need to
brush up on my C.
Sorry for wasting your time.
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Greg Freemyer]

On Thu, Aug 14, 2014 at 7:46 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
>> On Thu, Aug 14, 2014 at 5:38 PM,  <Valdis.Kletnieks@vt.edu> wrote:
>>> On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
>>>> I am learned C. Perhaps I am a little rusty and need to review.
>>>
>>> We've seen very little evidence that you *ever* really understood C
>>> at all, and you're *far* from "a little rusty".  It's been some 23
>>> years since I've hacked any code in IBM's Pascal/VS, and 29 since I
>>> had to do maintenance work on PL/I code, and I *still* remember more
>>> of those than you remember of C.  (I'll admit that my mad Snobol4 skilz
>>> have pretty much evaporated, though ;)
>>>
>>> http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
>>  I learned C like two years ago and never really practiced it that
>> much to be honest.
>>  In addition I will come back in the future about I have read The C Programming
>>  Language.
>> Cheers Nick
> Thanks for pointing me in the right direction , I really do need to
> brush up on my C.
> Sorry for wasting your time.
> Nick

Nick,

The linux kernel has some of the most complex c code on the planet.
It is seriously not a place to "brush-up", "practice", or "learn".

A few _years_ of current c experience is pretty much a must to truly
grok the kernel.  Once you have that as a base, then it takes a lot of
real study to comprehend the complex use cases used in the linux
kernel.

I suggest you find a userspace project and work with it for a year or
two before you jump back into the kernel.  Personally, I find the
libyal family of userspace c libraries interesting.  The code base is
much smaller, but works with filesystems and is has multi-threaded
needs.  The main author is crazy smart (works for Google), so I'm not
saying he needs your help.  I'm saying the code base is small enough
you might be able to get your arms around it and really understand it.
That can help you understand the data structures used in filesystems,
complex volume systems, and encryption.

https://code.google.com/p/libyal/wiki/Overview

You said you have an interest in filesystems (as do I).

Looking at the filesystem section of that overview a couple of his
targeted libraries haven't even been started yet.  You code will
likely be throwaway code for your first effort or two, but
File systems

Several libraries for different types of filesystems don't even have code yet.

libfsclfs; Common Log File System (CLFS) format
libfshfs; Hierarchical File System (HFS) format - at the moment
documentation only
libfsntfs; New Technology File System (NTFS) format - at the moment
documentation only
libfsrefs; Resilient File System (ReFS) format - at the moment
documentation only

For me, if I was trying to learn about filesystems, that would be a
fun way to hack away at new code.  Also, libyal has lots of low level
libraries you can build upon so your not starting from scratch.
Further there are lots of "tools" written that provide high-level
end-user applications.

If you'd rather look at volumes (similar to device mapper code), there
are these projects:

libbde; BitLocker drive encryption (BDE)
libfvde; FileVault drive encryption (FVDE)
libluksde; LUKS Disk Encryption - at the moment documentation only
libvslvm; Linux Logical Volume Manager (LVM) volume system format - at
the moment documentation only
libvshadow; Volume Shadow Snapshot (VSS) format
libvslibs; several libraries for different types of volume systems. -
at the moment documentation only

Or maybe you'd like to learn about virtual disks such as VMs use:

Image formats

Several libraries for accessing different types of storage media:

libodraw; optical disc (split) RAW image format (bin/cue, iso/cue)
libsmdev; storage media devices
libsmraw; (split) RAW image format
libewf; Expert Witness Compression Format (EWF) image format
libqcow; QEMU Copy-On-Write (QCOW) image format
libvhdi; Virtual Hard Disk (VHD) image format
libvmdk; VMware Virtual Disk (VMDK) format

FYI: I maintain many of the above for openSUSE and have the packages
in the main distro.  My to do list for this weekend is to package up
libqcow, libvhdi, and libvmdk.  That being my weekend plan is why I
have libyal in my head at the moment.

Greg

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 10:16 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
> On Thu, Aug 14, 2014 at 7:46 PM, Nick Krause <xerofoify@gmail.com> wrote:
>> On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
>>> On Thu, Aug 14, 2014 at 5:38 PM,  <Valdis.Kletnieks@vt.edu> wrote:
>>>> On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
>>>>> I am learned C. Perhaps I am a little rusty and need to review.
>>>>
>>>> We've seen very little evidence that you *ever* really understood C
>>>> at all, and you're *far* from "a little rusty".  It's been some 23
>>>> years since I've hacked any code in IBM's Pascal/VS, and 29 since I
>>>> had to do maintenance work on PL/I code, and I *still* remember more
>>>> of those than you remember of C.  (I'll admit that my mad Snobol4 skilz
>>>> have pretty much evaporated, though ;)
>>>>
>>>> http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
>>>  I learned C like two years ago and never really practiced it that
>>> much to be honest.
>>>  In addition I will come back in the future about I have read The C Programming
>>>  Language.
>>> Cheers Nick
>> Thanks for pointing me in the right direction , I really do need to
>> brush up on my C.
>> Sorry for wasting your time.
>> Nick
>
> Nick,
>
> The linux kernel has some of the most complex c code on the planet.
> It is seriously not a place to "brush-up", "practice", or "learn".
>
> A few _years_ of current c experience is pretty much a must to truly
> grok the kernel.  Once you have that as a base, then it takes a lot of
> real study to comprehend the complex use cases used in the linux
> kernel.
>
> I suggest you find a userspace project and work with it for a year or
> two before you jump back into the kernel.  Personally, I find the
> libyal family of userspace c libraries interesting.  The code base is
> much smaller, but works with filesystems and is has multi-threaded
> needs.  The main author is crazy smart (works for Google), so I'm not
> saying he needs your help.  I'm saying the code base is small enough
> you might be able to get your arms around it and really understand it.
> That can help you understand the data structures used in filesystems,
> complex volume systems, and encryption.
>
> https://code.google.com/p/libyal/wiki/Overview
>
> You said you have an interest in filesystems (as do I).
>
> Looking at the filesystem section of that overview a couple of his
> targeted libraries haven't even been started yet.  You code will
> likely be throwaway code for your first effort or two, but
> File systems
>
> Several libraries for different types of filesystems don't even have code yet.
>
> libfsclfs; Common Log File System (CLFS) format
> libfshfs; Hierarchical File System (HFS) format - at the moment
> documentation only
> libfsntfs; New Technology File System (NTFS) format - at the moment
> documentation only
> libfsrefs; Resilient File System (ReFS) format - at the moment
> documentation only
>
> For me, if I was trying to learn about filesystems, that would be a
> fun way to hack away at new code.  Also, libyal has lots of low level
> libraries you can build upon so your not starting from scratch.
> Further there are lots of "tools" written that provide high-level
> end-user applications.
>
> If you'd rather look at volumes (similar to device mapper code), there
> are these projects:
>
> libbde; BitLocker drive encryption (BDE)
> libfvde; FileVault drive encryption (FVDE)
> libluksde; LUKS Disk Encryption - at the moment documentation only
> libvslvm; Linux Logical Volume Manager (LVM) volume system format - at
> the moment documentation only
> libvshadow; Volume Shadow Snapshot (VSS) format
> libvslibs; several libraries for different types of volume systems. -
> at the moment documentation only
>
> Or maybe you'd like to learn about virtual disks such as VMs use:
>
> Image formats
>
> Several libraries for accessing different types of storage media:
>
> libodraw; optical disc (split) RAW image format (bin/cue, iso/cue)
> libsmdev; storage media devices
> libsmraw; (split) RAW image format
> libewf; Expert Witness Compression Format (EWF) image format
> libqcow; QEMU Copy-On-Write (QCOW) image format
> libvhdi; Virtual Hard Disk (VHD) image format
> libvmdk; VMware Virtual Disk (VMDK) format
>
> FYI: I maintain many of the above for openSUSE and have the packages
> in the main distro.  My to do list for this weekend is to package up
> libqcow, libvhdi, and libvmdk.  That being my weekend plan is why I
> have libyal in my head at the moment.
>
> Greg
Greg,
Thats very understandable I will  look into something else for now.
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 10:29 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Thu, Aug 14, 2014 at 10:16 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
>> On Thu, Aug 14, 2014 at 7:46 PM, Nick Krause <xerofoify@gmail.com> wrote:
>>> On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
>>>> On Thu, Aug 14, 2014 at 5:38 PM,  <Valdis.Kletnieks@vt.edu> wrote:
>>>>> On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
>>>>>> I am learned C. Perhaps I am a little rusty and need to review.
>>>>>
>>>>> We've seen very little evidence that you *ever* really understood C
>>>>> at all, and you're *far* from "a little rusty".  It's been some 23
>>>>> years since I've hacked any code in IBM's Pascal/VS, and 29 since I
>>>>> had to do maintenance work on PL/I code, and I *still* remember more
>>>>> of those than you remember of C.  (I'll admit that my mad Snobol4 skilz
>>>>> have pretty much evaporated, though ;)
>>>>>
>>>>> http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
>>>>  I learned C like two years ago and never really practiced it that
>>>> much to be honest.
>>>>  In addition I will come back in the future about I have read The C Programming
>>>>  Language.
>>>> Cheers Nick
>>> Thanks for pointing me in the right direction , I really do need to
>>> brush up on my C.
>>> Sorry for wasting your time.
>>> Nick
>>
>> Nick,
>>
>> The linux kernel has some of the most complex c code on the planet.
>> It is seriously not a place to "brush-up", "practice", or "learn".
>>
>> A few _years_ of current c experience is pretty much a must to truly
>> grok the kernel.  Once you have that as a base, then it takes a lot of
>> real study to comprehend the complex use cases used in the linux
>> kernel.
>>
>> I suggest you find a userspace project and work with it for a year or
>> two before you jump back into the kernel.  Personally, I find the
>> libyal family of userspace c libraries interesting.  The code base is
>> much smaller, but works with filesystems and is has multi-threaded
>> needs.  The main author is crazy smart (works for Google), so I'm not
>> saying he needs your help.  I'm saying the code base is small enough
>> you might be able to get your arms around it and really understand it.
>> That can help you understand the data structures used in filesystems,
>> complex volume systems, and encryption.
>>
>> https://code.google.com/p/libyal/wiki/Overview
>>
>> You said you have an interest in filesystems (as do I).
>>
>> Looking at the filesystem section of that overview a couple of his
>> targeted libraries haven't even been started yet.  You code will
>> likely be throwaway code for your first effort or two, but
>> File systems
>>
>> Several libraries for different types of filesystems don't even have code yet.
>>
>> libfsclfs; Common Log File System (CLFS) format
>> libfshfs; Hierarchical File System (HFS) format - at the moment
>> documentation only
>> libfsntfs; New Technology File System (NTFS) format - at the moment
>> documentation only
>> libfsrefs; Resilient File System (ReFS) format - at the moment
>> documentation only
>>
>> For me, if I was trying to learn about filesystems, that would be a
>> fun way to hack away at new code.  Also, libyal has lots of low level
>> libraries you can build upon so your not starting from scratch.
>> Further there are lots of "tools" written that provide high-level
>> end-user applications.
>>
>> If you'd rather look at volumes (similar to device mapper code), there
>> are these projects:
>>
>> libbde; BitLocker drive encryption (BDE)
>> libfvde; FileVault drive encryption (FVDE)
>> libluksde; LUKS Disk Encryption - at the moment documentation only
>> libvslvm; Linux Logical Volume Manager (LVM) volume system format - at
>> the moment documentation only
>> libvshadow; Volume Shadow Snapshot (VSS) format
>> libvslibs; several libraries for different types of volume systems. -
>> at the moment documentation only
>>
>> Or maybe you'd like to learn about virtual disks such as VMs use:
>>
>> Image formats
>>
>> Several libraries for accessing different types of storage media:
>>
>> libodraw; optical disc (split) RAW image format (bin/cue, iso/cue)
>> libsmdev; storage media devices
>> libsmraw; (split) RAW image format
>> libewf; Expert Witness Compression Format (EWF) image format
>> libqcow; QEMU Copy-On-Write (QCOW) image format
>> libvhdi; Virtual Hard Disk (VHD) image format
>> libvmdk; VMware Virtual Disk (VMDK) format
>>
>> FYI: I maintain many of the above for openSUSE and have the packages
>> in the main distro.  My to do list for this weekend is to package up
>> libqcow, libvhdi, and libvmdk.  That being my weekend plan is why I
>> have libyal in my head at the moment.
>>
>> Greg
> Greg,
> Thats very understandable I will  look into something else for now.
> Nick
I am going to work with postrqesql for now and learn from there.
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 10:42 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Thu, Aug 14, 2014 at 10:29 PM, Nick Krause <xerofoify@gmail.com> wrote:
>> On Thu, Aug 14, 2014 at 10:16 PM, Greg Freemyer <greg.freemyer@gmail.com> wrote:
>>> On Thu, Aug 14, 2014 at 7:46 PM, Nick Krause <xerofoify@gmail.com> wrote:
>>>> On Thu, Aug 14, 2014 at 6:12 PM, Nick Krause <xerofoify@gmail.com> wrote:
>>>>> On Thu, Aug 14, 2014 at 5:38 PM,  <Valdis.Kletnieks@vt.edu> wrote:
>>>>>> On Thu, 14 Aug 2014 17:13:28 -0400, Nick Krause said:
>>>>>>> I am learned C. Perhaps I am a little rusty and need to review.
>>>>>>
>>>>>> We've seen very little evidence that you *ever* really understood C
>>>>>> at all, and you're *far* from "a little rusty".  It's been some 23
>>>>>> years since I've hacked any code in IBM's Pascal/VS, and 29 since I
>>>>>> had to do maintenance work on PL/I code, and I *still* remember more
>>>>>> of those than you remember of C.  (I'll admit that my mad Snobol4 skilz
>>>>>> have pretty much evaporated, though ;)
>>>>>>
>>>>>> http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
>>>>>  I learned C like two years ago and never really practiced it that
>>>>> much to be honest.
>>>>>  In addition I will come back in the future about I have read The C Programming
>>>>>  Language.
>>>>> Cheers Nick
>>>> Thanks for pointing me in the right direction , I really do need to
>>>> brush up on my C.
>>>> Sorry for wasting your time.
>>>> Nick
>>>
>>> Nick,
>>>
>>> The linux kernel has some of the most complex c code on the planet.
>>> It is seriously not a place to "brush-up", "practice", or "learn".
>>>
>>> A few _years_ of current c experience is pretty much a must to truly
>>> grok the kernel.  Once you have that as a base, then it takes a lot of
>>> real study to comprehend the complex use cases used in the linux
>>> kernel.
>>>
>>> I suggest you find a userspace project and work with it for a year or
>>> two before you jump back into the kernel.  Personally, I find the
>>> libyal family of userspace c libraries interesting.  The code base is
>>> much smaller, but works with filesystems and is has multi-threaded
>>> needs.  The main author is crazy smart (works for Google), so I'm not
>>> saying he needs your help.  I'm saying the code base is small enough
>>> you might be able to get your arms around it and really understand it.
>>> That can help you understand the data structures used in filesystems,
>>> complex volume systems, and encryption.
>>>
>>> https://code.google.com/p/libyal/wiki/Overview
>>>
>>> You said you have an interest in filesystems (as do I).
>>>
>>> Looking at the filesystem section of that overview a couple of his
>>> targeted libraries haven't even been started yet.  You code will
>>> likely be throwaway code for your first effort or two, but
>>> File systems
>>>
>>> Several libraries for different types of filesystems don't even have code yet.
>>>
>>> libfsclfs; Common Log File System (CLFS) format
>>> libfshfs; Hierarchical File System (HFS) format - at the moment
>>> documentation only
>>> libfsntfs; New Technology File System (NTFS) format - at the moment
>>> documentation only
>>> libfsrefs; Resilient File System (ReFS) format - at the moment
>>> documentation only
>>>
>>> For me, if I was trying to learn about filesystems, that would be a
>>> fun way to hack away at new code.  Also, libyal has lots of low level
>>> libraries you can build upon so your not starting from scratch.
>>> Further there are lots of "tools" written that provide high-level
>>> end-user applications.
>>>
>>> If you'd rather look at volumes (similar to device mapper code), there
>>> are these projects:
>>>
>>> libbde; BitLocker drive encryption (BDE)
>>> libfvde; FileVault drive encryption (FVDE)
>>> libluksde; LUKS Disk Encryption - at the moment documentation only
>>> libvslvm; Linux Logical Volume Manager (LVM) volume system format - at
>>> the moment documentation only
>>> libvshadow; Volume Shadow Snapshot (VSS) format
>>> libvslibs; several libraries for different types of volume systems. -
>>> at the moment documentation only
>>>
>>> Or maybe you'd like to learn about virtual disks such as VMs use:
>>>
>>> Image formats
>>>
>>> Several libraries for accessing different types of storage media:
>>>
>>> libodraw; optical disc (split) RAW image format (bin/cue, iso/cue)
>>> libsmdev; storage media devices
>>> libsmraw; (split) RAW image format
>>> libewf; Expert Witness Compression Format (EWF) image format
>>> libqcow; QEMU Copy-On-Write (QCOW) image format
>>> libvhdi; Virtual Hard Disk (VHD) image format
>>> libvmdk; VMware Virtual Disk (VMDK) format
>>>
>>> FYI: I maintain many of the above for openSUSE and have the packages
>>> in the main distro.  My to do list for this weekend is to package up
>>> libqcow, libvhdi, and libvmdk.  That being my weekend plan is why I
>>> have libyal in my head at the moment.
>>>
>>> Greg
>> Greg,
>> Thats very understandable I will  look into something else for now.
>> Nick
> I am going to work with postrqesql for now and learn from there.
> Nick
I forget about the Eudyptula challenge, I am going to start with that
and I will make an agreement that you guys.
Until I complete all of the challenges correctly , I am not allowed to
sent out any more patches. If I do I don't
want any response what so ever , no matter how hard I plead. If this
is a deal , Greg and others please reply.
Thanks for the Help and I still don't known how the hell you haven't
given up on me yet,
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Jaret Flores]

> I forget about the Eudyptula challenge, I am going to start with that
> and I will make an agreement that you guys.
> Until I complete all of the challenges correctly , I am not allowed to
> sent out any more patches. If I do I don't
> want any response what so ever , no matter how hard I plead. If this
> is a deal , Greg and others please reply.

Warning!  Do not send any emails to the kernelnewbies mailing list
about the eudyptula challenge....otherwise you will be removed from
the challenge.  I am not a person in control of the challenge, but I
was just removed today for doing this.  So be sure to read through the
rules carefully!
-Jaret

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 11:42 PM, Jaret Flores <jarflores@gmail.com> wrote:
>> I forget about the Eudyptula challenge, I am going to start with that
>> and I will make an agreement that you guys.
>> Until I complete all of the challenges correctly , I am not allowed to
>> sent out any more patches. If I do I don't
>> want any response what so ever , no matter how hard I plead. If this
>> is a deal , Greg and others please reply.
>
> Warning!  Do not send any emails to the kernelnewbies mailing list
> about the eudyptula challenge....otherwise you will be removed from
> the challenge.  I am not a person in control of the challenge, but I
> was just removed today for doing this.  So be sure to read through the
> rules carefully!
> -Jaret
I failed too, asked about the first task(fail) and got removed.
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Nick Krause]

On Thu, Aug 14, 2014 at 11:43 PM, Nick Krause <xerofoify@gmail.com> wrote:
> On Thu, Aug 14, 2014 at 11:42 PM, Jaret Flores <jarflores@gmail.com> wrote:
>>> I forget about the Eudyptula challenge, I am going to start with that
>>> and I will make an agreement that you guys.
>>> Until I complete all of the challenges correctly , I am not allowed to
>>> sent out any more patches. If I do I don't
>>> want any response what so ever , no matter how hard I plead. If this
>>> is a deal , Greg and others please reply.
>>
>> Warning!  Do not send any emails to the kernelnewbies mailing list
>> about the eudyptula challenge....otherwise you will be removed from
>> the challenge.  I am not a person in control of the challenge, but I
>> was just removed today for doing this.  So be sure to read through the
>> rules carefully!
>> -Jaret
> I failed too, asked about the first task(fail) and got removed.
> Nick

In addition thanks to Greg and Vadis for putting up my crap :(.
I hope after I get back from the challenge I able to help more.
Nick

[PATCH] usb: Fix switch statement in ohci-tmio.c

[Tobias Boege]

On Thu, 14 Aug 2014, Nicholas Krause wrote:
> I am fixing the bug on at the link, https://bugzilla.kernel.org/show_bug.cgi?id=79931.
> This bug report states that in the function, tmio_hc_stop the switch has no needed breaks.
> Further more this patch fixes this bug by adding the needed breaks.
> 
> Signed-off-by: Nicholas Krause <xerofoify@gmail.com>
> ---
>  drivers/usb/host/ohci-tmio.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/host/ohci-tmio.c b/drivers/usb/host/ohci-tmio.c
> index bb40958..d2b5382 100644
> --- a/drivers/usb/host/ohci-tmio.c
> +++ b/drivers/usb/host/ohci-tmio.c
> @@ -100,12 +100,16 @@ static void tmio_stop_hc(struct platform_device *dev)
>  	switch (ohci->num_ports) {
>  		default:
>  			dev_err(&dev->dev, "Unsupported amount of ports: %d\n", ohci->num_ports);
> +			break;
>  		case 3:
>  			pm |= CCR_PM_USBPW3;
> +			break;
>  		case 2:
>  			pm |= CCR_PM_USBPW2;
> +			break;
>  		case 1:
>  			pm |= CCR_PM_USBPW1;
> +			break;
>  	}
>  	tmio_iowrite8(0, tmio->ccr + CCR_INTC);
>  	tmio_iowrite8(0, tmio->ccr + CCR_ILME);
> -- 
> 1.9.1
> 

Hmm, I don't know, man. The problem might as well (or even more likely) be
the defines:

#define CCR_PM_USBPW1    0x0004
#define CCR_PM_USBPW2    0x0008
#define CCR_PM_USBPW3    0x0008

which perfectly explain the warning and CCR_PM_USBPW3 needing to be 0x0010
would make more sense if you look at the "switch" head. Alas, I have no idea
about the stuff going on there, so this remains speculation.

However, maybe you can prove me wrong? If not, keep in mind that a bug
reporter doesn't necessarily provide a correct guide to fixing the bug.

[ Also, please consider just how *many* people gave you the (still surpris-
  ingly friendly formulated) advice to be silent for a while. Don't make me
  look up the procmailrc syntax again... ]

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk