* [U-Boot] Quick sanity test after my NAND patches
@ 2009-11-06 20:47 Paulraj, Sandeep
2009-11-06 21:08 ` Scott Wood
0 siblings, 1 reply; 9+ messages in thread
From: Paulraj, Sandeep @ 2009-11-06 20:47 UTC (permalink / raw)
To: u-boot
As most of you know I submitted a lot of patches for the MTD NAND driver to sync up with what's in the kernel.
I did a quick build for the DM355 from the u-boot-nand-flash/next tree.
The board booted up fine with a 2GB NAND device and I was able to perform NAND operations.
There will be issues if a 4GB NAND device is used as cmd_nand.c has to be updated to handle 64 bit variables. I'll work on that as I get time.
Thanks,
Sandeep
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Quick sanity test after my NAND patches
2009-11-06 20:47 [U-Boot] Quick sanity test after my NAND patches Paulraj, Sandeep
@ 2009-11-06 21:08 ` Scott Wood
2009-11-06 21:17 ` Jerry Van Baren
0 siblings, 1 reply; 9+ messages in thread
From: Scott Wood @ 2009-11-06 21:08 UTC (permalink / raw)
To: u-boot
On Fri, Nov 06, 2009 at 02:47:01PM -0600, Paulraj, Sandeep wrote:
> As most of you know I submitted a lot of patches for the MTD NAND driver
> to sync up with what's in the kernel.
They appear to correlate with specific Linux commits -- could you preserve
the authorship and signoffs? Especially when a copyrightably-sized chunk of
code is being added.
-Scott
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Quick sanity test after my NAND patches
2009-11-06 21:08 ` Scott Wood
@ 2009-11-06 21:17 ` Jerry Van Baren
2009-11-06 21:28 ` Paulraj, Sandeep
0 siblings, 1 reply; 9+ messages in thread
From: Jerry Van Baren @ 2009-11-06 21:17 UTC (permalink / raw)
To: u-boot
Scott Wood wrote:
> On Fri, Nov 06, 2009 at 02:47:01PM -0600, Paulraj, Sandeep wrote:
>> As most of you know I submitted a lot of patches for the MTD NAND driver
>> to sync up with what's in the kernel.
>
> They appear to correlate with specific Linux commits -- could you preserve
> the authorship and signoffs? Especially when a copyrightably-sized chunk of
> code is being added.
>
> -Scott
I don't know if the technique will work for you (Sandeep), but for the
libfdt synchronization, I literally extracted the patches from the
master DTC repository (git format-patch) and applied them (git am).
For the most part, David Gibson and Jon Loeliger made separate patches
for libfdt vs. the other stuff, so that was very helpful. Once or twice
I hand edited the patch to remove patches to non-libfdt files. I also
have to change the include/fdtlib.h file path since the DTC puts the
header file in a different directory. Hand editing the patches is an
ugly solution, but the result is very nice since it preserves the
changes, signoffs, and comments verbatim.
HTH,
gvb
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Quick sanity test after my NAND patches
2009-11-06 21:17 ` Jerry Van Baren
@ 2009-11-06 21:28 ` Paulraj, Sandeep
2009-11-06 21:37 ` Jerry Van Baren
2009-11-06 22:03 ` Scott Wood
0 siblings, 2 replies; 9+ messages in thread
From: Paulraj, Sandeep @ 2009-11-06 21:28 UTC (permalink / raw)
To: u-boot
Scott, Jerry,
>
> Scott Wood wrote:
> > On Fri, Nov 06, 2009 at 02:47:01PM -0600, Paulraj, Sandeep wrote:
> >> As most of you know I submitted a lot of patches for the MTD NAND
> driver
> >> to sync up with what's in the kernel.
> >
> > They appear to correlate with specific Linux commits -- could you
> preserve
> > the authorship and signoffs? Especially when a copyrightably-sized
> chunk of
Absolutely. Its not my work at all. As I said just trying to sync up with the kernel as somebody has to do it. So always willing to do it the correct way.
> > code is being added.
> >
> > -Scott
>
> I don't know if the technique will work for you (Sandeep), but for the
> libfdt synchronization, I literally extracted the patches from the
> master DTC repository (git format-patch) and applied them (git am).
This might not work as git-am will complain about not being able to apply clean.
>
> For the most part, David Gibson and Jon Loeliger made separate patches
> for libfdt vs. the other stuff, so that was very helpful. Once or twice
> I hand edited the patch to remove patches to non-libfdt files. I also
> have to change the include/fdtlib.h file path since the DTC puts the
> header file in a different directory. Hand editing the patches is an
> ugly solution, but the result is very nice since it preserves the
> changes, signoffs, and comments verbatim.
Is it ok if I send the patches again with the appropriate authors and signoffs.
>
> HTH,
> gvb
Scott,
Is it possible for you to let me know which patches you are OK with, so that I know what to resend?
Thanks,
Sandeep
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Quick sanity test after my NAND patches
2009-11-06 21:28 ` Paulraj, Sandeep
@ 2009-11-06 21:37 ` Jerry Van Baren
2009-11-06 21:44 ` Paulraj, Sandeep
2009-11-08 22:59 ` Wolfgang Denk
2009-11-06 22:03 ` Scott Wood
1 sibling, 2 replies; 9+ messages in thread
From: Jerry Van Baren @ 2009-11-06 21:37 UTC (permalink / raw)
To: u-boot
Paulraj, Sandeep wrote:
> Scott, Jerry,
[snip]
>> I don't know if the technique will work for you (Sandeep), but for the
>> libfdt synchronization, I literally extracted the patches from the
>> master DTC repository (git format-patch) and applied them (git am).
>
> This might not work as git-am will complain about not being able to apply clean.
I may be missing something, but if you hand-edit the patches so that
they are still valid patches, they will apply cleanly. In my hand
editing, I cut out all patch hunks to non-existing (for me) files (from
the patch's file name header to the next file name header). This is
simply a delete operation so it is pretty hard to screw up. I also
changed the file paths for all file references to libfdt.h which is
simply a substitution problem, again hard to screw up.
I don't know how complex your starting point patches are, so that may be
what I'm missing.
Note that the MD5 hash will be different between my edited patch and the
original patch, so you won't be able to correlate the u-boot/libfdt
patch directly to the DTC/libfdt patch, but that would happen anyway.
[snip]
Best regards,
gvb
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Quick sanity test after my NAND patches
2009-11-06 21:37 ` Jerry Van Baren
@ 2009-11-06 21:44 ` Paulraj, Sandeep
2009-11-08 22:59 ` Wolfgang Denk
1 sibling, 0 replies; 9+ messages in thread
From: Paulraj, Sandeep @ 2009-11-06 21:44 UTC (permalink / raw)
To: u-boot
> Paulraj, Sandeep wrote:
> > Scott, Jerry,
>
> [snip]
>
> >> I don't know if the technique will work for you (Sandeep), but for the
> >> libfdt synchronization, I literally extracted the patches from the
> >> master DTC repository (git format-patch) and applied them (git am).
> >
> > This might not work as git-am will complain about not being able to
> apply clean.
>
> I may be missing something, but if you hand-edit the patches so that
> they are still valid patches, they will apply cleanly. In my hand
> editing, I cut out all patch hunks to non-existing (for me) files (from
> the patch's file name header to the next file name header). This is
> simply a delete operation so it is pretty hard to screw up. I also
> changed the file paths for all file references to libfdt.h which is
> simply a substitution problem, again hard to screw up.
>
> I don't know how complex your starting point patches are, so that may be
> what I'm missing.
This is what I am referring to
>
> Note that the MD5 hash will be different between my edited patch and the
> original patch, so you won't be able to correlate the u-boot/libfdt
> patch directly to the DTC/libfdt patch, but that would happen anyway.
Yes that's true
>
> [snip]
>
> Best regards,
> gvb
Basically if I maintain the correct author and signoff, things should be OK.
I'll do it some way or the other, sooner rather than later.
I'll wait for Scott to say which ones need to be resubmitted.
Thanks,
Sandeep
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Quick sanity test after my NAND patches
2009-11-06 21:28 ` Paulraj, Sandeep
2009-11-06 21:37 ` Jerry Van Baren
@ 2009-11-06 22:03 ` Scott Wood
2009-11-06 22:14 ` Paulraj, Sandeep
1 sibling, 1 reply; 9+ messages in thread
From: Scott Wood @ 2009-11-06 22:03 UTC (permalink / raw)
To: u-boot
Paulraj, Sandeep wrote:
>> I don't know if the technique will work for you (Sandeep), but for the
>> libfdt synchronization, I literally extracted the patches from the
>> master DTC repository (git format-patch) and applied them (git am).
> This might not work as git-am will complain about not being able to apply clean.
You can apply the patches to your u-boot tree with git am, fixing up any
conflicts, and then do format-patch on the results.
> Is it possible for you to let me know which patches you are OK with, so that I know what to resend?
I'm most concerned with getting the attribution right on the 'fix "raw"
reads with ECC syndrome layouts' patch, since that adds significant new
code -- but ideally any patches that correspond with a patch in Linux
should look as much like that patch as possible (otherwise, mention in
the changelog that it is a sync with Linux). Or if you meant which
patches I'm OK with merging even after resend, they all look OK.
As for the comment about checkpatch warnings, what was it complaining
about? If it's not too bad I'd rather not make stylistic deviations
from what made it into Linux.
-Scott
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Quick sanity test after my NAND patches
2009-11-06 22:03 ` Scott Wood
@ 2009-11-06 22:14 ` Paulraj, Sandeep
0 siblings, 0 replies; 9+ messages in thread
From: Paulraj, Sandeep @ 2009-11-06 22:14 UTC (permalink / raw)
To: u-boot
Hello Scott,
> Paulraj, Sandeep wrote:
> >> I don't know if the technique will work for you (Sandeep), but for the
> >> libfdt synchronization, I literally extracted the patches from the
> >> master DTC repository (git format-patch) and applied them (git am).
> > This might not work as git-am will complain about not being able to
> apply clean.
>
> You can apply the patches to your u-boot tree with git am, fixing up any
> conflicts, and then do format-patch on the results.
>
> > Is it possible for you to let me know which patches you are OK with, so
> that I know what to resend?
>
> I'm most concerned with getting the attribution right on the 'fix "raw"
> reads with ECC syndrome layouts' patch, since that adds significant new
> code -- but ideally any patches that correspond with a patch in Linux
> should look as much like that patch as possible (otherwise, mention in
> the changelog that it is a sync with Linux).
So I take it that you only want the above patch resent with the correct signoffs.
I'll resend this single patch.
.
> Or if you meant which
> patches I'm OK with merging even after resend, they all look OK.
>
> As for the comment about checkpatch warnings, what was it complaining
> about? If it's not too bad I'd rather not make stylistic deviations
> from what made it into Linux.
80 chars per line warning. Do we really need to break this rule while I submit my patch?
Unrelated, but if you have a look at the subpage API, that's absolutely unbelievable; the function header itself is some 150 chars. I don't have a clue as to how it got accepted by the MTD folks.
>
> -Scott
Also in response to another e-mail from you, I think we need to update nand_ecc.c as well. I'll do that as well as a separate patch.
Thanks,
Sandeep
^ permalink raw reply [flat|nested] 9+ messages in thread
* [U-Boot] Quick sanity test after my NAND patches
2009-11-06 21:37 ` Jerry Van Baren
2009-11-06 21:44 ` Paulraj, Sandeep
@ 2009-11-08 22:59 ` Wolfgang Denk
1 sibling, 0 replies; 9+ messages in thread
From: Wolfgang Denk @ 2009-11-08 22:59 UTC (permalink / raw)
To: u-boot
Dear Jerry Van Baren,
In message <4AF4971B.9080602@ge.com> you wrote:
>
> > This might not work as git-am will complain about not being able to apply clean.
>
> I may be missing something, but if you hand-edit the patches so that
> they are still valid patches, they will apply cleanly. In my hand
> editing, I cut out all patch hunks to non-existing (for me) files (from
> the patch's file name header to the next file name header). This is
> simply a delete operation so it is pretty hard to screw up. I also
> changed the file paths for all file references to libfdt.h which is
> simply a substitution problem, again hard to screw up.
"filterdiff" and/or "editdiff" (from the "patchutils" package of the
distribution of your choice) may be useful tools for such tasks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One essential to success is that you desire be an all-obsessing one,
your thoughts and aims be co-ordinated, and your energy be concentra-
ted and applied without letup.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-11-08 22:59 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-06 20:47 [U-Boot] Quick sanity test after my NAND patches Paulraj, Sandeep
2009-11-06 21:08 ` Scott Wood
2009-11-06 21:17 ` Jerry Van Baren
2009-11-06 21:28 ` Paulraj, Sandeep
2009-11-06 21:37 ` Jerry Van Baren
2009-11-06 21:44 ` Paulraj, Sandeep
2009-11-08 22:59 ` Wolfgang Denk
2009-11-06 22:03 ` Scott Wood
2009-11-06 22:14 ` Paulraj, Sandeep
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.