| Message ID | 20200325031854.7625-1-chris.packham@alliedtelesis.co.nz (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2] powerpc/setup_64: Set cache-line-size based on cache-block-size | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch powerpc/merge (a87b93bdf800a4d7a42d95683624a4516e516b4f) |
| snowpatch_ozlabs/build-ppc64le | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64be | success | Build succeeded |
| snowpatch_ozlabs/build-ppc64e | success | Build succeeded |
| snowpatch_ozlabs/build-pmac32 | success | Build succeeded |
| snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 8 lines checked |
| snowpatch_ozlabs/needsstable | success | Patch has no Fixes tags |
Hi All, On Wed, 2020-03-25 at 16:18 +1300, Chris Packham wrote: > If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not, > use > the block-size value for both. Per the devicetree spec cache-line- > size > is only needed if it differs from the block size. > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > --- > It looks as though the bsizep = lsizep is not required per the spec > but it's > probably safer to retain it. > > Changes in v2: > - Scott pointed out that u-boot should be filling in the cache > properties > (which it does). But it does not specify a cache-line-size because > it > provides a cache-block-size and the spec says you don't have to if > they are > the same. So the error is in the parsing not in the devicetree > itself. > Ping? This thread went kind of quiet. > arch/powerpc/kernel/setup_64.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/powerpc/kernel/setup_64.c > b/arch/powerpc/kernel/setup_64.c > index e05e6dd67ae6..dd8a238b54b8 100644 > --- a/arch/powerpc/kernel/setup_64.c > +++ b/arch/powerpc/kernel/setup_64.c > @@ -516,6 +516,8 @@ static bool __init parse_cache_info(struct > device_node *np, > lsizep = of_get_property(np, propnames[3], NULL); > if (bsizep == NULL) > bsizep = lsizep; > + if (lsizep == NULL) > + lsizep = bsizep; > if (lsizep != NULL) > lsize = be32_to_cpu(*lsizep); > if (bsizep != NULL)
Chris Packham <Chris.Packham@alliedtelesis.co.nz> writes: > Hi All, > > On Wed, 2020-03-25 at 16:18 +1300, Chris Packham wrote: >> If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not, >> use >> the block-size value for both. Per the devicetree spec cache-line- >> size >> is only needed if it differs from the block size. >> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >> --- >> It looks as though the bsizep = lsizep is not required per the spec >> but it's >> probably safer to retain it. >> >> Changes in v2: >> - Scott pointed out that u-boot should be filling in the cache >> properties >> (which it does). But it does not specify a cache-line-size because >> it >> provides a cache-block-size and the spec says you don't have to if >> they are >> the same. So the error is in the parsing not in the devicetree >> itself. >> > > Ping? This thread went kind of quiet. I replied in the other thread: https://lore.kernel.org/linuxppc-dev/87369xx99u.fsf@mpe.ellerman.id.au/ But then the merge window happened which is a busy time. What I'd really like is a v3 that incorporates the info I wrote in the other thread and a Fixes tag. If you feel like doing that, that would be great. Otherwise I'll do it tomorrow. cheers
On Thu, 2020-04-16 at 21:43 +1000, Michael Ellerman wrote: > Chris Packham <Chris.Packham@alliedtelesis.co.nz> writes: > > Hi All, > > > > On Wed, 2020-03-25 at 16:18 +1300, Chris Packham wrote: > > > If {i,d}-cache-block-size is set and {i,d}-cache-line-size is > > > not, > > > use > > > the block-size value for both. Per the devicetree spec cache- > > > line- > > > size > > > is only needed if it differs from the block size. > > > > > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> > > > --- > > > It looks as though the bsizep = lsizep is not required per the > > > spec > > > but it's > > > probably safer to retain it. > > > > > > Changes in v2: > > > - Scott pointed out that u-boot should be filling in the cache > > > properties > > > (which it does). But it does not specify a cache-line-size > > > because > > > it > > > provides a cache-block-size and the spec says you don't have to > > > if > > > they are > > > the same. So the error is in the parsing not in the devicetree > > > itself. > > > > > > > Ping? This thread went kind of quiet. > > I replied in the other thread: > > > https://lore.kernel.org/linuxppc-dev/87369xx99u.fsf@mpe.ellerman.id.au/ > > But then the merge window happened which is a busy time. > Yeah I figured that was the case. > What I'd really like is a v3 that incorporates the info I wrote in > the > other thread and a Fixes tag. > > If you feel like doing that, that would be great. Otherwise I'll do > it > tomorrow. I'll rebase against Linus's tree and have a go a adding some more words to the commit message. > > cheers
Chris Packham <Chris.Packham@alliedtelesis.co.nz> writes: > On Thu, 2020-04-16 at 21:43 +1000, Michael Ellerman wrote: >> Chris Packham <Chris.Packham@alliedtelesis.co.nz> writes: >> > On Wed, 2020-03-25 at 16:18 +1300, Chris Packham wrote: >> > > If {i,d}-cache-block-size is set and {i,d}-cache-line-size is >> > > not, >> > > use >> > > the block-size value for both. Per the devicetree spec cache- >> > > line- >> > > size >> > > is only needed if it differs from the block size. >> > > >> > > Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> >> > > --- >> > > It looks as though the bsizep = lsizep is not required per the >> > > spec >> > > but it's >> > > probably safer to retain it. >> > > >> > > Changes in v2: >> > > - Scott pointed out that u-boot should be filling in the cache >> > > properties >> > > (which it does). But it does not specify a cache-line-size >> > > because >> > > it >> > > provides a cache-block-size and the spec says you don't have to >> > > if >> > > they are >> > > the same. So the error is in the parsing not in the devicetree >> > > itself. >> > > >> > >> > Ping? This thread went kind of quiet. >> >> I replied in the other thread: >> >> >> https://lore.kernel.org/linuxppc-dev/87369xx99u.fsf@mpe.ellerman.id.au/ >> >> But then the merge window happened which is a busy time. >> > > Yeah I figured that was the case. > >> What I'd really like is a v3 that incorporates the info I wrote in >> the >> other thread and a Fixes tag. >> >> If you feel like doing that, that would be great. Otherwise I'll do >> it >> tomorrow. > > I'll rebase against Linus's tree and have a go a adding some more words > to the commit message. Thanks. cheers
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c index e05e6dd67ae6..dd8a238b54b8 100644 --- a/arch/powerpc/kernel/setup_64.c +++ b/arch/powerpc/kernel/setup_64.c @@ -516,6 +516,8 @@ static bool __init parse_cache_info(struct device_node *np, lsizep = of_get_property(np, propnames[3], NULL); if (bsizep == NULL) bsizep = lsizep; + if (lsizep == NULL) + lsizep = bsizep; if (lsizep != NULL) lsize = be32_to_cpu(*lsizep); if (bsizep != NULL)
If {i,d}-cache-block-size is set and {i,d}-cache-line-size is not, use the block-size value for both. Per the devicetree spec cache-line-size is only needed if it differs from the block size. Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz> --- It looks as though the bsizep = lsizep is not required per the spec but it's probably safer to retain it. Changes in v2: - Scott pointed out that u-boot should be filling in the cache properties (which it does). But it does not specify a cache-line-size because it provides a cache-block-size and the spec says you don't have to if they are the same. So the error is in the parsing not in the devicetree itself. arch/powerpc/kernel/setup_64.c | 2 ++ 1 file changed, 2 insertions(+)