Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-30 Thread Anthony Foiani
Greg -- Thanks for the very quick response. Greg KH writes: > This is an obvious one, it needs to be upstream first. > > Or if not, a whole lot of explaination saying that you know it > isn't, and why it isn't, and why it isn't applicable there, I thought that I did provide exactly this

Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-30 Thread Greg KH
On Fri, Nov 30, 2012 at 05:19:28PM -0700, Anthony Foiani wrote: > Greg KH writes: > > This is not the correct way to submit patches for inclusion in the > > stable kernel tree. Please read Documentation/stable_kernel_rules.txt > > for how to do this properly. > > My checklist against

Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-30 Thread Anthony Foiani
Greg KH writes: > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read Documentation/stable_kernel_rules.txt > for how to do this properly. My checklist against stable_kernel_rules.txt is below. I could only find two reasons why you are saying

Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-30 Thread Anthony Foiani
Greg KH g...@kroah.com writes: This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. My checklist against stable_kernel_rules.txt is below. I could only find two reasons why you

Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-30 Thread Greg KH
On Fri, Nov 30, 2012 at 05:19:28PM -0700, Anthony Foiani wrote: Greg KH g...@kroah.com writes: This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. My checklist against

Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-30 Thread Anthony Foiani
Greg -- Thanks for the very quick response. Greg KH g...@kroah.com writes: This is an obvious one, it needs to be upstream first. Or if not, a whole lot of explaination saying that you know it isn't, and why it isn't, and why it isn't applicable there, I thought that I did provide exactly

Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-29 Thread Greg KH
On Wed, Nov 07, 2012 at 11:48:24PM -0700, Anthony Foiani wrote: > > mtd: check partition count not partition array pointer > > The documentation claims that "nr_parts" is the determining factor, > while the code originally tested whether "parts" is non-null. > > In at least one driver

Re: [PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-29 Thread Greg KH
On Wed, Nov 07, 2012 at 11:48:24PM -0700, Anthony Foiani wrote: mtd: check partition count not partition array pointer The documentation claims that nr_parts is the determining factor, while the code originally tested whether parts is non-null. In at least one driver (fsl_elbc_nand),

[PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-07 Thread Anthony Foiani
mtd: check partition count not partition array pointer The documentation claims that "nr_parts" is the determining factor, while the code originally tested whether "parts" is non-null. In at least one driver (fsl_elbc_nand), parts is never initialized to 0; even though nr_parts is correctly 0,

[PATCH 1/1] v3.0.x: mtd: check partition count not partition array pointer

2012-11-07 Thread Anthony Foiani
mtd: check partition count not partition array pointer The documentation claims that nr_parts is the determining factor, while the code originally tested whether parts is non-null. In at least one driver (fsl_elbc_nand), parts is never initialized to 0; even though nr_parts is correctly 0,