* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
From: Scott Wood @ 2020-04-16 19:40 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, kernel, Wang Wenhu, linuxppc-dev
In-Reply-To: <20200416063002.GA299193@kroah.com>
On Thu, 2020-04-16 at 08:30 +0200, Greg KH wrote:
> On Wed, Apr 15, 2020 at 02:26:55PM -0500, Scott Wood wrote:
> > Instead, have module parameters that take the sizes and alignments you'd
> > like
> > to allocate and expose to userspace. Better still would be some sort of
> > dynamic allocation (e.g. open a fd, ioctl to set the requested
> > size/alignment,
> > if it succeeds you can mmap it, and when the fd is closed the region is
> > freed).
>
> No module parameters please, this is not the 1990's.
>
> Use device tree, that is what it is there for.
Since when is the device tree for indicating desired allocations? This is not
hardware description.
If module parameters are unacceptable, then I'd suggest dynamic allocation as
described above.
-Scott
^ permalink raw reply
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
From: Scott Wood @ 2020-04-16 19:36 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel, kernel, Wang Wenhu, linuxppc-dev
In-Reply-To: <20200416063034.GB299193@kroah.com>
On Thu, 2020-04-16 at 08:30 +0200, Greg KH wrote:
> On Wed, Apr 15, 2020 at 02:27:51PM -0500, Scott Wood wrote:
> > > > + dev_err(&pdev->dev, "error no valid uio-map
> > > > configured\n");
> > > > + ret = -EINVAL;
> > > > + goto err_info_free_internel;
> > > > + }
> > > > +
> > > > + info->version = "0.1.0";
> > >
> > > Could you define some DRIVER_VERSION in the top of the file next to
> > > DRIVER_NAME instead of hard coding in the middle on a function ?
> >
> > That's what v1 had, and Greg KH said to remove it. I'm guessing that he
> > thought it was the common-but-pointless practice of having the driver
> > print a
> > version number that never gets updated, rather than something the UIO API
> > (unfortunately, compared to a feature query interface) expects. That
> > said,
> > I'm not sure what the value is of making it a macro since it should only
> > be
> > used once, that use is self documenting, it isn't tunable, etc. Though if
> > this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro
> > again, it should be UIO_VERSION, not DRIVER_VERSION).
> >
> > Does this really need a three-part version scheme? What's wrong with a
> > version of "1", to be changed to "2" in the hopefully-unlikely event that
> > the
> > userspace API changes? Assuming UIO is used for this at all, which
> > doesn't
> > seem like a great fit to me.
>
> No driver version numbers at all please, they do not make any sense when
> the driver is included in the kernel tree.
Again, reporting a version string is part of the UIO API. It might not be a
good API, but if it's left as NULL the registration will fail.
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'
From: Segher Boessenkool @ 2020-04-16 19:01 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <f797e5ac-a29a-0eb0-89c8-ff0a9f537ccf@c-s.fr>
On Thu, Apr 16, 2020 at 02:41:56PM +0200, Christophe Leroy wrote:
> Le 16/04/2020 à 00:37, Segher Boessenkool a écrit :
> >>+ __put_user_nocheck_goto((__typeof__(*(ptr)))(x), (ptr),
> >>sizeof(*(ptr)), label)
> >
> >This line gets too long, can you break it up somehow?
>
> This line has 86 chars.
(And your mail program has wrapped it ;-) )
> powerpc arch tolerates lines with up to 90 chars, see
> arch/powerpc/tools/checkpatch.sh
I *tolerate* it as well, sure, but long lines are bad for readability.
Like, I noticed it because it wrapped :-)
That "90" thing is just dumb, we should get rid of it. Sometimes you
can have long lines, if that is better than the alternatives. There
does not need to be a ridiculous "rule" that is unhappy *both* ways!
(This is true for many things in checkpatch, btw... Rules of thumb,
not rules).
Segher
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Adhemerval Zanella @ 2020-04-16 18:52 UTC (permalink / raw)
To: Rich Felker; +Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <20200416183151.GA11469@brightrain.aerifal.cx>
On 16/04/2020 15:31, Rich Felker wrote:
> On Thu, Apr 16, 2020 at 03:18:42PM -0300, Adhemerval Zanella wrote:
>>
>>
>> On 16/04/2020 14:59, Rich Felker wrote:
>>> On Thu, Apr 16, 2020 at 02:50:18PM -0300, Adhemerval Zanella wrote:
>>>>
>>>>
>>>> On 16/04/2020 12:37, Rich Felker wrote:
>>>>> On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote:
>>>>>>> My preference would be that it work just like the i386 AT_SYSINFO
>>>>>>> where you just replace "int $128" with "call *%%gs:16" and the kernel
>>>>>>> provides a stub in the vdso that performs either scv or the old
>>>>>>> mechanism with the same calling convention. Then if the kernel doesn't
>>>>>>> provide it (because the kernel is too old) libc would have to provide
>>>>>>> its own stub that uses the legacy method and matches the calling
>>>>>>> convention of the one the kernel is expected to provide.
>>>>>>
>>>>>> What about pthread cancellation and the requirement of checking the
>>>>>> cancellable syscall anchors in asynchronous cancellation? My plan is
>>>>>> still to use musl strategy on glibc (BZ#12683) and for i686 it
>>>>>> requires to always use old int$128 for program that uses cancellation
>>>>>> (static case) or just threads (dynamic mode, which should be more
>>>>>> common on glibc).
>>>>>>
>>>>>> Using the i686 strategy of a vDSO bridge symbol would require to always
>>>>>> fallback to 'sc' to still use the same cancellation strategy (and
>>>>>> thus defeating this optimization in such cases).
>>>>>
>>>>> Yes, I assumed it would be the same, ignoring the new syscall
>>>>> mechanism for cancellable syscalls. While there are some exceptions,
>>>>> cancellable syscalls are generally not hot paths but things that are
>>>>> expected to block and to have significant amounts of work to do in
>>>>> kernelspace, so saving a few tens of cycles is rather pointless.
>>>>>
>>>>> It's possible to do a branch/multiple versions of the syscall asm for
>>>>> cancellation but would require extending the cancellation handler to
>>>>> support checking against multiple independent address ranges or using
>>>>> some alternate markup of them.
>>>>
>>>> The main issue is at least for glibc dynamic linking is way more common
>>>> than static linking and once the program become multithread the fallback
>>>> will be always used.
>>>
>>> I'm not relying on static linking optimizing out the cancellable
>>> version. I'm talking about how cancellable syscalls are pretty much
>>> all "heavy" operations to begin with where a few tens of cycles are in
>>> the realm of "measurement noise" relative to the dominating time
>>> costs.
>>
>> Yes I am aware, but at same time I am not sure how it plays on real world.
>> For instance, some workloads might issue kernel query syscalls, such as
>> recv, where buffer copying might not be dominant factor. So I see that if
>> the idea is optimizing syscall mechanism, we should try to leverage it
>> as whole in libc.
>
> Have you timed a minimal recv? I'm not assuming buffer copying is the
> dominant factor. I'm assuming the overhead of all the kernel layers
> involved is dominant.
Not really, but reading the advantages of using 'scv' over 'sc' also does
not outline the real expect gain. Taking in consideration this should
be a micro-optimization (focused on entry syscall patch), I think we should
use where it possible.
>
>>>> And besides the cancellation performance issue, a new bridge vDSO mechanism
>>>> will still require to setup some extra bridge for the case of the older
>>>> kernel. In the scheme you suggested:
>>>>
>>>> __asm__("indirect call" ... with common clobbers);
>>>>
>>>> The indirect call will be either the vDSO bridge or an libc provided that
>>>> fallback to 'sc' for !PPC_FEATURE2_SCV. I am not this is really a gain
>>>> against:
>>>>
>>>> if (hwcap & PPC_FEATURE2_SCV) {
>>>> __asm__(... with some clobbers);
>>>> } else {
>>>> __asm__(... with different clobbers);
>>>> }
>>>
>>> If the indirect call can be made roughly as efficiently as the sc
>>> sequence now (which already have some cost due to handling the nasty
>>> error return convention, making the indirect call likely just as small
>>> or smaller), it's O(1) additional code size (and thus icache usage)
>>> rather than O(n) where n is number of syscall points.
>>>
>>> Of course it would work just as well (for avoiding O(n) growth) to
>>> have a direct call to out-of-line branch like you suggested.
>>
>> Yes, but does it really matter to optimize this specific usage case
>> for size? glibc, for instance, tries to leverage the syscall mechanism
>> by adding some complex pre-processor asm directives. It optimizes
>> the syscall code size in most cases. For instance, kill in static case
>> generates on x86_64:
>>
>> 0000000000000000 <__kill>:
>> 0: b8 3e 00 00 00 mov $0x3e,%eax
>> 5: 0f 05 syscall
>> 7: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
>> d: 0f 83 00 00 00 00 jae 13 <__kill+0x13>
>> 13: c3 retq
>>
>> While on musl:
>>
>> 0000000000000000 <kill>:
>> 0: 48 83 ec 08 sub $0x8,%rsp
>> 4: 48 63 ff movslq %edi,%rdi
>> 7: 48 63 f6 movslq %esi,%rsi
>> a: b8 3e 00 00 00 mov $0x3e,%eax
>> f: 0f 05 syscall
>> 11: 48 89 c7 mov %rax,%rdi
>> 14: e8 00 00 00 00 callq 19 <kill+0x19>
>> 19: 5a pop %rdx
>> 1a: c3 retq
>
> Wow that's some extraordinarily bad codegen going on by gcc... The
> sign-extension is semantically needed and I don't see a good way
> around it (glibc's asm is kinda a hack taking advantage of kernel not
> looking at high bits, I think), but the gratuitous stack adjustment
> and refusal to generate a tail call isn't. I'll see if we can track
> down what's going on and get it fixed.
Wrt glibc, it is most likely and it has bitten us on x32 port recently
(where some types were being passed correctly). In any case, my long
term plan to also get rid of this nasty assembly pre-processor on
syscall passing.
>
>> But I hardly think it pays off the required code complexity. Some
>> for providing a O(1) bridge: this will require additional complexity
>> to write it and setup correctly.
>
> In some sense I agree, but inline instructions are a lot more
> expensive on ppc (being 32-bit each), and it might take out-of-lining
> anyway to get rid of stack frame setups if that ends up being a
> problem.
Indeed, I didn't started to prototype what would be required to make
this change on glibc. Maybe an out-of-line helper might make sense.
>
>>>> Specially if 'hwcap & PPC_FEATURE2_SCV' could be optimized with a
>>>> TCB member (as we do on glibc) and if we could make the asm clever
>>>> enough to not require different clobbers (although not sure if
>>>> it would be possible).
>>>
>>> The easy way not to require different clobbers is just using the union
>>> of the clobbers, no? Does the proposed new method clobber any
>>> call-saved registers that would make it painful (requiring new call
>>> frames to save them in)?
>>
>> As far I can tell, it should be ok.
>
> Note that because lr is clobbered we need at least once normally
> call-clobbered register that's not syscall clobbered to save lr in.
> Otherwise stack frame setup is required to spill it. (And I'm not even
> sure if gcc does things right to avoid it by using a register -- we
> should check that I guess...)
If I recall correctly Florian has found some issue in lr clobbering.
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 18:44 UTC (permalink / raw)
To: Adhemerval Zanella
Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <20200416183151.GA11469@brightrain.aerifal.cx>
On Thu, Apr 16, 2020 at 02:31:51PM -0400, Rich Felker wrote:
> > While on musl:
> >
> > 0000000000000000 <kill>:
> > 0: 48 83 ec 08 sub $0x8,%rsp
> > 4: 48 63 ff movslq %edi,%rdi
> > 7: 48 63 f6 movslq %esi,%rsi
> > a: b8 3e 00 00 00 mov $0x3e,%eax
> > f: 0f 05 syscall
> > 11: 48 89 c7 mov %rax,%rdi
> > 14: e8 00 00 00 00 callq 19 <kill+0x19>
> > 19: 5a pop %rdx
> > 1a: c3 retq
>
> Wow that's some extraordinarily bad codegen going on by gcc... The
> sign-extension is semantically needed and I don't see a good way
> around it (glibc's asm is kinda a hack taking advantage of kernel not
> looking at high bits, I think), but the gratuitous stack adjustment
> and refusal to generate a tail call isn't. I'll see if we can track
> down what's going on and get it fixed.
It seems to be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14441
which I've updated with a comment about the above.
Rich
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 18:31 UTC (permalink / raw)
To: Adhemerval Zanella
Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <4f824a37-e660-8912-25aa-fde88d4b79f3@linaro.org>
On Thu, Apr 16, 2020 at 03:18:42PM -0300, Adhemerval Zanella wrote:
>
>
> On 16/04/2020 14:59, Rich Felker wrote:
> > On Thu, Apr 16, 2020 at 02:50:18PM -0300, Adhemerval Zanella wrote:
> >>
> >>
> >> On 16/04/2020 12:37, Rich Felker wrote:
> >>> On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote:
> >>>>> My preference would be that it work just like the i386 AT_SYSINFO
> >>>>> where you just replace "int $128" with "call *%%gs:16" and the kernel
> >>>>> provides a stub in the vdso that performs either scv or the old
> >>>>> mechanism with the same calling convention. Then if the kernel doesn't
> >>>>> provide it (because the kernel is too old) libc would have to provide
> >>>>> its own stub that uses the legacy method and matches the calling
> >>>>> convention of the one the kernel is expected to provide.
> >>>>
> >>>> What about pthread cancellation and the requirement of checking the
> >>>> cancellable syscall anchors in asynchronous cancellation? My plan is
> >>>> still to use musl strategy on glibc (BZ#12683) and for i686 it
> >>>> requires to always use old int$128 for program that uses cancellation
> >>>> (static case) or just threads (dynamic mode, which should be more
> >>>> common on glibc).
> >>>>
> >>>> Using the i686 strategy of a vDSO bridge symbol would require to always
> >>>> fallback to 'sc' to still use the same cancellation strategy (and
> >>>> thus defeating this optimization in such cases).
> >>>
> >>> Yes, I assumed it would be the same, ignoring the new syscall
> >>> mechanism for cancellable syscalls. While there are some exceptions,
> >>> cancellable syscalls are generally not hot paths but things that are
> >>> expected to block and to have significant amounts of work to do in
> >>> kernelspace, so saving a few tens of cycles is rather pointless.
> >>>
> >>> It's possible to do a branch/multiple versions of the syscall asm for
> >>> cancellation but would require extending the cancellation handler to
> >>> support checking against multiple independent address ranges or using
> >>> some alternate markup of them.
> >>
> >> The main issue is at least for glibc dynamic linking is way more common
> >> than static linking and once the program become multithread the fallback
> >> will be always used.
> >
> > I'm not relying on static linking optimizing out the cancellable
> > version. I'm talking about how cancellable syscalls are pretty much
> > all "heavy" operations to begin with where a few tens of cycles are in
> > the realm of "measurement noise" relative to the dominating time
> > costs.
>
> Yes I am aware, but at same time I am not sure how it plays on real world.
> For instance, some workloads might issue kernel query syscalls, such as
> recv, where buffer copying might not be dominant factor. So I see that if
> the idea is optimizing syscall mechanism, we should try to leverage it
> as whole in libc.
Have you timed a minimal recv? I'm not assuming buffer copying is the
dominant factor. I'm assuming the overhead of all the kernel layers
involved is dominant.
> >> And besides the cancellation performance issue, a new bridge vDSO mechanism
> >> will still require to setup some extra bridge for the case of the older
> >> kernel. In the scheme you suggested:
> >>
> >> __asm__("indirect call" ... with common clobbers);
> >>
> >> The indirect call will be either the vDSO bridge or an libc provided that
> >> fallback to 'sc' for !PPC_FEATURE2_SCV. I am not this is really a gain
> >> against:
> >>
> >> if (hwcap & PPC_FEATURE2_SCV) {
> >> __asm__(... with some clobbers);
> >> } else {
> >> __asm__(... with different clobbers);
> >> }
> >
> > If the indirect call can be made roughly as efficiently as the sc
> > sequence now (which already have some cost due to handling the nasty
> > error return convention, making the indirect call likely just as small
> > or smaller), it's O(1) additional code size (and thus icache usage)
> > rather than O(n) where n is number of syscall points.
> >
> > Of course it would work just as well (for avoiding O(n) growth) to
> > have a direct call to out-of-line branch like you suggested.
>
> Yes, but does it really matter to optimize this specific usage case
> for size? glibc, for instance, tries to leverage the syscall mechanism
> by adding some complex pre-processor asm directives. It optimizes
> the syscall code size in most cases. For instance, kill in static case
> generates on x86_64:
>
> 0000000000000000 <__kill>:
> 0: b8 3e 00 00 00 mov $0x3e,%eax
> 5: 0f 05 syscall
> 7: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
> d: 0f 83 00 00 00 00 jae 13 <__kill+0x13>
> 13: c3 retq
>
> While on musl:
>
> 0000000000000000 <kill>:
> 0: 48 83 ec 08 sub $0x8,%rsp
> 4: 48 63 ff movslq %edi,%rdi
> 7: 48 63 f6 movslq %esi,%rsi
> a: b8 3e 00 00 00 mov $0x3e,%eax
> f: 0f 05 syscall
> 11: 48 89 c7 mov %rax,%rdi
> 14: e8 00 00 00 00 callq 19 <kill+0x19>
> 19: 5a pop %rdx
> 1a: c3 retq
Wow that's some extraordinarily bad codegen going on by gcc... The
sign-extension is semantically needed and I don't see a good way
around it (glibc's asm is kinda a hack taking advantage of kernel not
looking at high bits, I think), but the gratuitous stack adjustment
and refusal to generate a tail call isn't. I'll see if we can track
down what's going on and get it fixed.
> But I hardly think it pays off the required code complexity. Some
> for providing a O(1) bridge: this will require additional complexity
> to write it and setup correctly.
In some sense I agree, but inline instructions are a lot more
expensive on ppc (being 32-bit each), and it might take out-of-lining
anyway to get rid of stack frame setups if that ends up being a
problem.
> >> Specially if 'hwcap & PPC_FEATURE2_SCV' could be optimized with a
> >> TCB member (as we do on glibc) and if we could make the asm clever
> >> enough to not require different clobbers (although not sure if
> >> it would be possible).
> >
> > The easy way not to require different clobbers is just using the union
> > of the clobbers, no? Does the proposed new method clobber any
> > call-saved registers that would make it painful (requiring new call
> > frames to save them in)?
>
> As far I can tell, it should be ok.
Note that because lr is clobbered we need at least once normally
call-clobbered register that's not syscall clobbered to save lr in.
Otherwise stack frame setup is required to spill it. (And I'm not even
sure if gcc does things right to avoid it by using a register -- we
should check that I guess...)
Rich
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Adhemerval Zanella @ 2020-04-16 18:18 UTC (permalink / raw)
To: Rich Felker; +Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <20200416175932.GZ11469@brightrain.aerifal.cx>
On 16/04/2020 14:59, Rich Felker wrote:
> On Thu, Apr 16, 2020 at 02:50:18PM -0300, Adhemerval Zanella wrote:
>>
>>
>> On 16/04/2020 12:37, Rich Felker wrote:
>>> On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote:
>>>>> My preference would be that it work just like the i386 AT_SYSINFO
>>>>> where you just replace "int $128" with "call *%%gs:16" and the kernel
>>>>> provides a stub in the vdso that performs either scv or the old
>>>>> mechanism with the same calling convention. Then if the kernel doesn't
>>>>> provide it (because the kernel is too old) libc would have to provide
>>>>> its own stub that uses the legacy method and matches the calling
>>>>> convention of the one the kernel is expected to provide.
>>>>
>>>> What about pthread cancellation and the requirement of checking the
>>>> cancellable syscall anchors in asynchronous cancellation? My plan is
>>>> still to use musl strategy on glibc (BZ#12683) and for i686 it
>>>> requires to always use old int$128 for program that uses cancellation
>>>> (static case) or just threads (dynamic mode, which should be more
>>>> common on glibc).
>>>>
>>>> Using the i686 strategy of a vDSO bridge symbol would require to always
>>>> fallback to 'sc' to still use the same cancellation strategy (and
>>>> thus defeating this optimization in such cases).
>>>
>>> Yes, I assumed it would be the same, ignoring the new syscall
>>> mechanism for cancellable syscalls. While there are some exceptions,
>>> cancellable syscalls are generally not hot paths but things that are
>>> expected to block and to have significant amounts of work to do in
>>> kernelspace, so saving a few tens of cycles is rather pointless.
>>>
>>> It's possible to do a branch/multiple versions of the syscall asm for
>>> cancellation but would require extending the cancellation handler to
>>> support checking against multiple independent address ranges or using
>>> some alternate markup of them.
>>
>> The main issue is at least for glibc dynamic linking is way more common
>> than static linking and once the program become multithread the fallback
>> will be always used.
>
> I'm not relying on static linking optimizing out the cancellable
> version. I'm talking about how cancellable syscalls are pretty much
> all "heavy" operations to begin with where a few tens of cycles are in
> the realm of "measurement noise" relative to the dominating time
> costs.
Yes I am aware, but at same time I am not sure how it plays on real world.
For instance, some workloads might issue kernel query syscalls, such as
recv, where buffer copying might not be dominant factor. So I see that if
the idea is optimizing syscall mechanism, we should try to leverage it
as whole in libc.
>
>> And besides the cancellation performance issue, a new bridge vDSO mechanism
>> will still require to setup some extra bridge for the case of the older
>> kernel. In the scheme you suggested:
>>
>> __asm__("indirect call" ... with common clobbers);
>>
>> The indirect call will be either the vDSO bridge or an libc provided that
>> fallback to 'sc' for !PPC_FEATURE2_SCV. I am not this is really a gain
>> against:
>>
>> if (hwcap & PPC_FEATURE2_SCV) {
>> __asm__(... with some clobbers);
>> } else {
>> __asm__(... with different clobbers);
>> }
>
> If the indirect call can be made roughly as efficiently as the sc
> sequence now (which already have some cost due to handling the nasty
> error return convention, making the indirect call likely just as small
> or smaller), it's O(1) additional code size (and thus icache usage)
> rather than O(n) where n is number of syscall points.
>
> Of course it would work just as well (for avoiding O(n) growth) to
> have a direct call to out-of-line branch like you suggested.
Yes, but does it really matter to optimize this specific usage case
for size? glibc, for instance, tries to leverage the syscall mechanism
by adding some complex pre-processor asm directives. It optimizes
the syscall code size in most cases. For instance, kill in static case
generates on x86_64:
0000000000000000 <__kill>:
0: b8 3e 00 00 00 mov $0x3e,%eax
5: 0f 05 syscall
7: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
d: 0f 83 00 00 00 00 jae 13 <__kill+0x13>
13: c3 retq
While on musl:
0000000000000000 <kill>:
0: 48 83 ec 08 sub $0x8,%rsp
4: 48 63 ff movslq %edi,%rdi
7: 48 63 f6 movslq %esi,%rsi
a: b8 3e 00 00 00 mov $0x3e,%eax
f: 0f 05 syscall
11: 48 89 c7 mov %rax,%rdi
14: e8 00 00 00 00 callq 19 <kill+0x19>
19: 5a pop %rdx
1a: c3 retq
But I hardly think it pays off the required code complexity. Some
for providing a O(1) bridge: this will require additional complexity
to write it and setup correctly.
>
>> Specially if 'hwcap & PPC_FEATURE2_SCV' could be optimized with a
>> TCB member (as we do on glibc) and if we could make the asm clever
>> enough to not require different clobbers (although not sure if
>> it would be possible).
>
> The easy way not to require different clobbers is just using the union
> of the clobbers, no? Does the proposed new method clobber any
> call-saved registers that would make it painful (requiring new call
> frames to save them in)?
As far I can tell, it should be ok.
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Florian Weimer @ 2020-04-16 18:12 UTC (permalink / raw)
To: Rich Felker; +Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <20200416165257.GY11469@brightrain.aerifal.cx>
* Rich Felker:
> On Thu, Apr 16, 2020 at 06:42:32PM +0200, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote:
>> >> * Rich Felker:
>> >>
>> >> > My preference would be that it work just like the i386 AT_SYSINFO
>> >> > where you just replace "int $128" with "call *%%gs:16" and the kernel
>> >> > provides a stub in the vdso that performs either scv or the old
>> >> > mechanism with the same calling convention.
>> >>
>> >> The i386 mechanism has received some criticism because it provides an
>> >> effective means to redirect execution flow to anyone who can write to
>> >> the TCB. I am not sure if it makes sense to copy it.
>> >
>> > Indeed that's a good point. Do you have ideas for making it equally
>> > efficient without use of a function pointer in the TCB?
>>
>> We could add a shared non-writable mapping at a 64K offset from the
>> thread pointer and store the function pointer or the code there. Then
>> it would be safe.
>>
>> However, since this is apparently tied to POWER9 and we already have a
>> POWER9 multilib, and assuming that we are going to backport the kernel
>> change, I would tweak the selection criterion for that multilib to
>> include the new HWCAP2 flag. If a user runs this glibc on a kernel
>> which does not have support, they will get set baseline (POWER8)
>> multilib, which still works. This way, outside the dynamic loader, no
>> run-time dispatch is needed at all. I guess this is not at all the
>> answer you were looking for. 8-)
>
> How does this work with -static? :-)
-static is not supported. 8-) (If you use the unsupported static
libraries, you get POWER8 code.)
(Just to be clear, in case someone doesn't get the joke: This is about
a potential approach for a heavily constrained, vertically integrated
environment. It does not reflect general glibc recommendations.)
>> If a single binary is needed, I would perhaps follow what Arm did for
>> -moutline-atomics: lay out the code so that its easy to execute for
>> the non-POWER9 case, assuming that POWER9 machines will be better at
>> predicting things than their predecessors.
>>
>> Or you could also put the function pointer into a RELRO segment. Then
>> there's overlap with the __libc_single_threaded discussion, where
>> people objected to this kind of optimization (although I did not
>> propose to change the TCB ABI, that would be required for
>> __libc_single_threaded because it's an external interface).
>
> Of course you can use a normal global, but now every call point needs
> to setup a TOC pointer (= two entry points and more icache lines for
> otherwise trivial functions).
>
> I think my choice would be just making the inline syscall be a single
> call insn to an asm source file that out-of-lines the loading of TOC
> pointer and call through it or branch based on hwcap so that it's not
> repeated all over the place.
I don't know how problematic control flow out of an inline asm is on
POWER. But this is basically the -moutline-atomics approach.
> Alternatively, it would perhaps work to just put hwcap in the TCB and
> branch on it rather than making an indirect call to a function pointer
> in the TCB, so that the worst you could do by clobbering it is execute
> the wrong syscall insn and thereby get SIGILL.
The HWCAP is already in the TCB. I expect this is what generic glibc
builds are going to use (perhaps with a bit of tweaking favorable to
POWER8 implementations, but we'll see).
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 17:59 UTC (permalink / raw)
To: Adhemerval Zanella
Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <4b2a7a56-dd2b-1863-50e5-2f4cdbeef47c@linaro.org>
On Thu, Apr 16, 2020 at 02:50:18PM -0300, Adhemerval Zanella wrote:
>
>
> On 16/04/2020 12:37, Rich Felker wrote:
> > On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote:
> >>> My preference would be that it work just like the i386 AT_SYSINFO
> >>> where you just replace "int $128" with "call *%%gs:16" and the kernel
> >>> provides a stub in the vdso that performs either scv or the old
> >>> mechanism with the same calling convention. Then if the kernel doesn't
> >>> provide it (because the kernel is too old) libc would have to provide
> >>> its own stub that uses the legacy method and matches the calling
> >>> convention of the one the kernel is expected to provide.
> >>
> >> What about pthread cancellation and the requirement of checking the
> >> cancellable syscall anchors in asynchronous cancellation? My plan is
> >> still to use musl strategy on glibc (BZ#12683) and for i686 it
> >> requires to always use old int$128 for program that uses cancellation
> >> (static case) or just threads (dynamic mode, which should be more
> >> common on glibc).
> >>
> >> Using the i686 strategy of a vDSO bridge symbol would require to always
> >> fallback to 'sc' to still use the same cancellation strategy (and
> >> thus defeating this optimization in such cases).
> >
> > Yes, I assumed it would be the same, ignoring the new syscall
> > mechanism for cancellable syscalls. While there are some exceptions,
> > cancellable syscalls are generally not hot paths but things that are
> > expected to block and to have significant amounts of work to do in
> > kernelspace, so saving a few tens of cycles is rather pointless.
> >
> > It's possible to do a branch/multiple versions of the syscall asm for
> > cancellation but would require extending the cancellation handler to
> > support checking against multiple independent address ranges or using
> > some alternate markup of them.
>
> The main issue is at least for glibc dynamic linking is way more common
> than static linking and once the program become multithread the fallback
> will be always used.
I'm not relying on static linking optimizing out the cancellable
version. I'm talking about how cancellable syscalls are pretty much
all "heavy" operations to begin with where a few tens of cycles are in
the realm of "measurement noise" relative to the dominating time
costs.
> And besides the cancellation performance issue, a new bridge vDSO mechanism
> will still require to setup some extra bridge for the case of the older
> kernel. In the scheme you suggested:
>
> __asm__("indirect call" ... with common clobbers);
>
> The indirect call will be either the vDSO bridge or an libc provided that
> fallback to 'sc' for !PPC_FEATURE2_SCV. I am not this is really a gain
> against:
>
> if (hwcap & PPC_FEATURE2_SCV) {
> __asm__(... with some clobbers);
> } else {
> __asm__(... with different clobbers);
> }
If the indirect call can be made roughly as efficiently as the sc
sequence now (which already have some cost due to handling the nasty
error return convention, making the indirect call likely just as small
or smaller), it's O(1) additional code size (and thus icache usage)
rather than O(n) where n is number of syscall points.
Of course it would work just as well (for avoiding O(n) growth) to
have a direct call to out-of-line branch like you suggested.
> Specially if 'hwcap & PPC_FEATURE2_SCV' could be optimized with a
> TCB member (as we do on glibc) and if we could make the asm clever
> enough to not require different clobbers (although not sure if
> it would be possible).
The easy way not to require different clobbers is just using the union
of the clobbers, no? Does the proposed new method clobber any
call-saved registers that would make it painful (requiring new call
frames to save them in)?
Rich
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Adhemerval Zanella @ 2020-04-16 17:50 UTC (permalink / raw)
To: Rich Felker; +Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <20200416153756.GU11469@brightrain.aerifal.cx>
On 16/04/2020 12:37, Rich Felker wrote:
> On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote:
>>> My preference would be that it work just like the i386 AT_SYSINFO
>>> where you just replace "int $128" with "call *%%gs:16" and the kernel
>>> provides a stub in the vdso that performs either scv or the old
>>> mechanism with the same calling convention. Then if the kernel doesn't
>>> provide it (because the kernel is too old) libc would have to provide
>>> its own stub that uses the legacy method and matches the calling
>>> convention of the one the kernel is expected to provide.
>>
>> What about pthread cancellation and the requirement of checking the
>> cancellable syscall anchors in asynchronous cancellation? My plan is
>> still to use musl strategy on glibc (BZ#12683) and for i686 it
>> requires to always use old int$128 for program that uses cancellation
>> (static case) or just threads (dynamic mode, which should be more
>> common on glibc).
>>
>> Using the i686 strategy of a vDSO bridge symbol would require to always
>> fallback to 'sc' to still use the same cancellation strategy (and
>> thus defeating this optimization in such cases).
>
> Yes, I assumed it would be the same, ignoring the new syscall
> mechanism for cancellable syscalls. While there are some exceptions,
> cancellable syscalls are generally not hot paths but things that are
> expected to block and to have significant amounts of work to do in
> kernelspace, so saving a few tens of cycles is rather pointless.
>
> It's possible to do a branch/multiple versions of the syscall asm for
> cancellation but would require extending the cancellation handler to
> support checking against multiple independent address ranges or using
> some alternate markup of them.
The main issue is at least for glibc dynamic linking is way more common
than static linking and once the program become multithread the fallback
will be always used.
And besides the cancellation performance issue, a new bridge vDSO mechanism
will still require to setup some extra bridge for the case of the older
kernel. In the scheme you suggested:
__asm__("indirect call" ... with common clobbers);
The indirect call will be either the vDSO bridge or an libc provided that
fallback to 'sc' for !PPC_FEATURE2_SCV. I am not this is really a gain
against:
if (hwcap & PPC_FEATURE2_SCV) {
__asm__(... with some clobbers);
} else {
__asm__(... with different clobbers);
}
Specially if 'hwcap & PPC_FEATURE2_SCV' could be optimized with a
TCB member (as we do on glibc) and if we could make the asm clever
enough to not require different clobbers (although not sure if
it would be possible).
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 16:52 UTC (permalink / raw)
To: Florian Weimer; +Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <87sgh3e613.fsf@mid.deneb.enyo.de>
On Thu, Apr 16, 2020 at 06:42:32PM +0200, Florian Weimer wrote:
> * Rich Felker:
>
> > On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > My preference would be that it work just like the i386 AT_SYSINFO
> >> > where you just replace "int $128" with "call *%%gs:16" and the kernel
> >> > provides a stub in the vdso that performs either scv or the old
> >> > mechanism with the same calling convention.
> >>
> >> The i386 mechanism has received some criticism because it provides an
> >> effective means to redirect execution flow to anyone who can write to
> >> the TCB. I am not sure if it makes sense to copy it.
> >
> > Indeed that's a good point. Do you have ideas for making it equally
> > efficient without use of a function pointer in the TCB?
>
> We could add a shared non-writable mapping at a 64K offset from the
> thread pointer and store the function pointer or the code there. Then
> it would be safe.
>
> However, since this is apparently tied to POWER9 and we already have a
> POWER9 multilib, and assuming that we are going to backport the kernel
> change, I would tweak the selection criterion for that multilib to
> include the new HWCAP2 flag. If a user runs this glibc on a kernel
> which does not have support, they will get set baseline (POWER8)
> multilib, which still works. This way, outside the dynamic loader, no
> run-time dispatch is needed at all. I guess this is not at all the
> answer you were looking for. 8-)
How does this work with -static? :-)
> If a single binary is needed, I would perhaps follow what Arm did for
> -moutline-atomics: lay out the code so that its easy to execute for
> the non-POWER9 case, assuming that POWER9 machines will be better at
> predicting things than their predecessors.
>
> Or you could also put the function pointer into a RELRO segment. Then
> there's overlap with the __libc_single_threaded discussion, where
> people objected to this kind of optimization (although I did not
> propose to change the TCB ABI, that would be required for
> __libc_single_threaded because it's an external interface).
Of course you can use a normal global, but now every call point needs
to setup a TOC pointer (= two entry points and more icache lines for
otherwise trivial functions).
I think my choice would be just making the inline syscall be a single
call insn to an asm source file that out-of-lines the loading of TOC
pointer and call through it or branch based on hwcap so that it's not
repeated all over the place.
Alternatively, it would perhaps work to just put hwcap in the TCB and
branch on it rather than making an indirect call to a function pointer
in the TCB, so that the worst you could do by clobbering it is execute
the wrong syscall insn and thereby get SIGILL.
Rich
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Florian Weimer @ 2020-04-16 16:42 UTC (permalink / raw)
To: Rich Felker; +Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <20200416153509.GT11469@brightrain.aerifal.cx>
* Rich Felker:
> On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > My preference would be that it work just like the i386 AT_SYSINFO
>> > where you just replace "int $128" with "call *%%gs:16" and the kernel
>> > provides a stub in the vdso that performs either scv or the old
>> > mechanism with the same calling convention.
>>
>> The i386 mechanism has received some criticism because it provides an
>> effective means to redirect execution flow to anyone who can write to
>> the TCB. I am not sure if it makes sense to copy it.
>
> Indeed that's a good point. Do you have ideas for making it equally
> efficient without use of a function pointer in the TCB?
We could add a shared non-writable mapping at a 64K offset from the
thread pointer and store the function pointer or the code there. Then
it would be safe.
However, since this is apparently tied to POWER9 and we already have a
POWER9 multilib, and assuming that we are going to backport the kernel
change, I would tweak the selection criterion for that multilib to
include the new HWCAP2 flag. If a user runs this glibc on a kernel
which does not have support, they will get set baseline (POWER8)
multilib, which still works. This way, outside the dynamic loader, no
run-time dispatch is needed at all. I guess this is not at all the
answer you were looking for. 8-)
If a single binary is needed, I would perhaps follow what Arm did for
-moutline-atomics: lay out the code so that its easy to execute for
the non-POWER9 case, assuming that POWER9 machines will be better at
predicting things than their predecessors.
Or you could also put the function pointer into a RELRO segment. Then
there's overlap with the __libc_single_threaded discussion, where
people objected to this kind of optimization (although I did not
propose to change the TCB ABI, that would be required for
__libc_single_threaded because it's an external interface).
^ permalink raw reply
* [PATCH] KVM: PPC: Book3S HV: read ibm,secure-memory nodes
From: Laurent Dufour @ 2020-04-16 16:27 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev; +Cc: Alexey Kardashevskiy, paulus, linux-kernel
The newly introduced ibm,secure-memory nodes supersede the
ibm,uv-firmware's property secure-memory-ranges.
Firmware will no more expose the secure-memory-ranges property so first
read the new one and if not found rollback to the older one.
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 53b88cae3e73..ad950f8996e0 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -735,6 +735,20 @@ static u64 kvmppc_get_secmem_size(void)
const __be32 *prop;
u64 size = 0;
+ /*
+ * First try the new ibm,secure-memory nodes which supersede the
+ * secure-memory-ranges property.
+ * If we found somes, no need to read the deprecated one.
+ */
+ for_each_compatible_node(np, NULL, "ibm,secure-memory") {
+ prop = of_get_property(np, "reg", &len);
+ if (!prop)
+ continue;
+ size += of_read_number(prop + 2, 2);
+ }
+ if (size)
+ return size;
+
np = of_find_compatible_node(NULL, NULL, "ibm,uv-firmware");
if (!np)
goto out;
--
2.26.1
^ permalink raw reply related
* Re: [PATCH v4,3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
From: Christophe Leroy @ 2020-04-16 15:46 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200416153537.23736-4-wenhu.wang@vivo.com>
Le 16/04/2020 à 17:35, Wang Wenhu a écrit :
> Function instantiate_cache_sram should not be linked into the init
> section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
> Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> Warning information:
> MODPOST vmlinux.o
> WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram()
> The function mpc85xx_l2ctlr_of_probe() references
> the function __init instantiate_cache_sram().
> This is often because mpc85xx_l2ctlr_of_probe lacks a __init
> annotation or the annotation of instantiate_cache_sram is wrong.
> ---
> Changes since v1:
> * None
> Changes since v2:
> * None
> Changes since v3:
> * None
> ---
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> index be3aef4229d7..3de5ac8382c0 100644
> --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> @@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr)
> }
> EXPORT_SYMBOL(mpc85xx_cache_sram_free);
>
> -int __init instantiate_cache_sram(struct platform_device *dev,
> +int instantiate_cache_sram(struct platform_device *dev,
> struct sram_parameters sram_params)
> {
> int ret = 0;
>
^ permalink raw reply
* Re: [PATCH v4,2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
From: Christophe Leroy @ 2020-04-16 15:45 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200416153537.23736-3-wenhu.wang@vivo.com>
Le 16/04/2020 à 17:35, Wang Wenhu a écrit :
> Include linux/io.h into fsl_85xx_cache_sram.c to fix the
> implicit-declaration compile error when building Cache-Sram.
>
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration]
> cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> ^~~~~~~~~~~~~~~~
> bitmap_complement
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
> cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
> ^
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration]
> iounmap(cache_sram->base_virt);
> ^~~~~~~
> roundup
> cc1: all warnings being treated as errors
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
> Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> Changes since v1:
> * None
> Changes since v2:
> * None
> Changes since v3:
> * None
> ---
> arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> index f6c665dac725..be3aef4229d7 100644
> --- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> +++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
> @@ -17,6 +17,7 @@
> #include <linux/of_platform.h>
> #include <asm/pgtable.h>
> #include <asm/fsl_85xx_cache_sram.h>
> +#include <linux/io.h>
>
> #include "fsl_85xx_cache_ctlr.h"
>
>
^ permalink raw reply
* Re: [PATCH v4,1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
From: Christophe Leroy @ 2020-04-16 15:45 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200416153537.23736-2-wenhu.wang@vivo.com>
Le 16/04/2020 à 17:35, Wang Wenhu a écrit :
> Include "linux/of_address.h" to fix the compile error for
> mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
>
> CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration]
> l2ctlr = of_iomap(dev->dev.of_node, 0);
> ^~~~~~~~
> pci_iomap
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
> l2ctlr = of_iomap(dev->dev.of_node, 0);
> ^
> cc1: all warnings being treated as errors
> scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed
> make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
> Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> Changes since v1:
> * None
> Changes since v2:
> * None
> Changes since v3:
> * None
> ---
> arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
> index 2d0af0c517bb..7533572492f0 100644
> --- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
> +++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
> @@ -10,6 +10,7 @@
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/of_platform.h>
> +#include <linux/of_address.h>
> #include <asm/io.h>
>
> #include "fsl_85xx_cache_ctlr.h"
>
^ permalink raw reply
* Re: [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram
From: Christophe Leroy @ 2020-04-16 15:43 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200416153537.23736-5-wenhu.wang@vivo.com>
Le 16/04/2020 à 17:35, Wang Wenhu a écrit :
> A driver for freescale 85xx platforms to access the Cache-Sram form
> user level. This is extremely helpful for some user-space applications
> that require high performance memory accesses.
>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
> ---
> Changes since v1:
> * Addressed comments from Greg K-H
> * Moved kfree(info->name) into uio_info_free_internal()
> Changes since v2:
> * Addressed comments from Greg, Scott and Christophe
> * Use "uiomem->internal_addr" as if condition for sram memory free,
> and memset the uiomem entry
> * of_match_table modified to be apart from HW info which belong to
> the HW level driver fsl_85xx_cache_sram to match
> * Use roundup_pow_of_two for align calc(really learned a lot from Christophe)
> * Remove useless clear block of uiomem entries.
> * Use UIO_INFO_VER micro for info->version, and define it as
> "devicetree,pseudo", meaning this is pseudo device and probed from
> device tree configuration
> Changes since v3:
> * Addressed comments from Christophe(use devm_xxx memory alloc interfaces)
> ---
> drivers/uio/Kconfig | 9 ++
> drivers/uio/Makefile | 1 +
> drivers/uio/uio_fsl_85xx_cache_sram.c | 148 ++++++++++++++++++++++++++
> 3 files changed, 158 insertions(+)
> create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
>
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 202ee81cfc2b..9c3b47461b71 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -105,6 +105,15 @@ config UIO_NETX
> To compile this driver as a module, choose M here; the module
> will be called uio_netx.
>
> +config UIO_FSL_85XX_CACHE_SRAM
> + tristate "Freescale 85xx Cache-Sram driver"
> + depends on FSL_SOC_BOOKE && PPC32
> + select FSL_85XX_CACHE_SRAM
> + help
> + Generic driver for accessing the Cache-Sram form user level. This
> + is extremely helpful for some user-space applications that require
> + high performance memory accesses.
> +
> config UIO_FSL_ELBC_GPCM
> tristate "eLBC/GPCM driver"
> depends on FSL_LBC
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index c285dd2a4539..be2056cffc21 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o
> obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
> obj-$(CONFIG_UIO_MF624) += uio_mf624.o
> obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o
> +obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o
> obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
> diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c
> new file mode 100644
> index 000000000000..cb339d1f9019
> --- /dev/null
> +++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
> + * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com>
> + * All rights reserved.
> + */
> +
> +#include <linux/platform_device.h>
> +#include <linux/uio_driver.h>
> +#include <linux/stringify.h>
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <asm/fsl_85xx_cache_sram.h>
> +
> +#define DRIVER_NAME "uio_fsl_85xx_cache_sram"
> +#define UIO_INFO_VER "devicetree,pseudo"
> +#define UIO_NAME "uio_cache_sram"
> +
> +static void uio_info_free_internal(struct uio_info *info)
> +{
> + int i;
> +
> + for (i = 0; i < MAX_UIO_MAPS; i++) {
> + struct uio_mem *uiomem = &info->mem[i];
> +
> + if (uiomem->internal_addr) {
> + mpc85xx_cache_sram_free(uiomem->internal_addr);
> + memset(uiomem, 0, sizeof(*uiomem));
> + }
> + }
> +}
> +
> +static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev)
> +{
> + struct device_node *parent = pdev->dev.of_node;
> + struct device_node *node = NULL;
> + struct uio_info *info;
> + struct uio_mem *uiomem;
> + const char *dt_name;
> + u32 mem_size;
> + int ret;
> +
> + /* alloc uio_info for one device */
> + info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
> + if (!info)
> + return -ENOMEM;
> +
> + /* get optional uio name */
> + if (of_property_read_string(parent, "uio_name", &dt_name))
> + dt_name = UIO_NAME;
> +
> + info->name = devm_kstrdup(&pdev->dev, dt_name, GFP_KERNEL);
> + if (!info->name)
> + return -ENOMEM;
> +
> + uiomem = info->mem;
> + for_each_child_of_node(parent, node) {
> + void *virt;
> + phys_addr_t phys;
> +
> + ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
> + if (ret) {
> + ret = -EINVAL;
> + goto err_out;
> + }
> +
> + if (mem_size == 0) {
> + dev_err(&pdev->dev, "error cache-mem-size should not be 0\n");
> + ret = -EINVAL;
> + goto err_out;
> + }
> +
> + virt = mpc85xx_cache_sram_alloc(mem_size, &phys,
> + roundup_pow_of_two(mem_size));
> + if (!virt) {
> + /* mpc85xx_cache_sram_alloc to define the real cause */
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + uiomem->memtype = UIO_MEM_PHYS;
> + uiomem->addr = phys;
> + uiomem->size = mem_size;
> + uiomem->name = kstrdup(node->name, GFP_KERNEL);;
> + uiomem->internal_addr = virt;
> + uiomem++;
> +
> + if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
> + dev_warn(&pdev->dev, "more than %d uio-maps for device.\n",
> + MAX_UIO_MAPS);
> + break;
> + }
> + }
> +
> + if (uiomem == info->mem) {
> + dev_err(&pdev->dev, "error no valid uio-map configuration found\n");
> + return -EINVAL;
> + }
> +
> + info->version = UIO_INFO_VER;
> +
> + /* register uio device */
> + if (uio_register_device(&pdev->dev, info)) {
> + dev_err(&pdev->dev, "error uio,cache-sram registration failed\n");
> + ret = -ENODEV;
> + goto err_out;
> + }
> +
> + platform_set_drvdata(pdev, info);
> +
> + return 0;
> +err_out:
> + uio_info_free_internal(info);
> + return ret;
> +}
> +
> +static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev)
> +{
> + struct uio_info *info = platform_get_drvdata(pdev);
> +
> + uio_unregister_device(info);
> +
> + uio_info_free_internal(info);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> + { .compatible = "uio,mpc85xx-cache-sram", },
> + {},
> +};
> +
> +static struct platform_driver uio_fsl_85xx_cache_sram = {
> + .probe = uio_fsl_85xx_cache_sram_probe,
> + .remove = uio_fsl_85xx_cache_sram_remove,
> + .driver = {
> + .name = DRIVER_NAME,
> + .owner = THIS_MODULE,
> + .of_match_table = uio_mpc85xx_l2ctlr_of_match,
> + },
> +};
> +
> +module_platform_driver(uio_fsl_85xx_cache_sram);
> +
> +MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>");
> +MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
> +MODULE_ALIAS("platform:" DRIVER_NAME);
> +MODULE_LICENSE("GPL v2");
>
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 15:40 UTC (permalink / raw)
To: Jeffrey Walton; +Cc: libc-alpha, musl, linuxppc-dev, libc-dev
In-Reply-To: <CAH8yC8k7dJdVS1LJRrGkxhbeVeXeGX2CWfC6sT--aso69Ksp6Q@mail.gmail.com>
On Thu, Apr 16, 2020 at 11:21:56AM -0400, Jeffrey Walton wrote:
> On Wed, Apr 15, 2020 at 8:17 PM Nicholas Piggin <npiggin@gmail.com> wrote:
> >
> > Excerpts from Rich Felker's message of April 16, 2020 8:55 am:
> > > On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
> > >> I would like to enable Linux support for the powerpc 'scv' instruction,
> > >> as a faster system call instruction.
> > >>
> > >> This requires two things to be defined: Firstly a way to advertise to
> > >> userspace that kernel supports scv, and a way to allocate and advertise
> > >> support for individual scv vectors. Secondly, a calling convention ABI
> > >> for this new instruction.
> > >> ...
> > > Note that any libc that actually makes use of the new functionality is
> > > not going to be able to make clobbers conditional on support for it;
> > > branching around different clobbers is going to defeat any gains vs
> > > always just treating anything clobbered by either method as clobbered.
> >
> > Well it would have to test HWCAP and patch in or branch to two
> > completely different sequences including register save/restores yes.
> > You could have the same asm and matching clobbers to put the sequence
> > inline and then you could patch the one sc/scv instruction I suppose.
>
> Could GCC function multiversioning work here?
> https://gcc.gnu.org/wiki/FunctionMultiVersioning
>
> It seems like selecting a runtime version of a function is the sort of
> thing you are trying to do.
On glibc it potentially could. This is ifunc-based functionality
though and musl explicitly does not (and will not) support ifunc
because of lots of fundamental problems it entails. But even on glibc
the underlying mechanisms for ifunc are just the same as a normal
indirect call and there's no real reason to prefer implementing it
with ifunc/multiversioning vs directly.
Rich
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 15:37 UTC (permalink / raw)
To: Adhemerval Zanella
Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <c2612908-67f7-cceb-d121-700dea096016@linaro.org>
On Thu, Apr 16, 2020 at 11:16:04AM -0300, Adhemerval Zanella wrote:
> > My preference would be that it work just like the i386 AT_SYSINFO
> > where you just replace "int $128" with "call *%%gs:16" and the kernel
> > provides a stub in the vdso that performs either scv or the old
> > mechanism with the same calling convention. Then if the kernel doesn't
> > provide it (because the kernel is too old) libc would have to provide
> > its own stub that uses the legacy method and matches the calling
> > convention of the one the kernel is expected to provide.
>
> What about pthread cancellation and the requirement of checking the
> cancellable syscall anchors in asynchronous cancellation? My plan is
> still to use musl strategy on glibc (BZ#12683) and for i686 it
> requires to always use old int$128 for program that uses cancellation
> (static case) or just threads (dynamic mode, which should be more
> common on glibc).
>
> Using the i686 strategy of a vDSO bridge symbol would require to always
> fallback to 'sc' to still use the same cancellation strategy (and
> thus defeating this optimization in such cases).
Yes, I assumed it would be the same, ignoring the new syscall
mechanism for cancellable syscalls. While there are some exceptions,
cancellable syscalls are generally not hot paths but things that are
expected to block and to have significant amounts of work to do in
kernelspace, so saving a few tens of cycles is rather pointless.
It's possible to do a branch/multiple versions of the syscall asm for
cancellation but would require extending the cancellation handler to
support checking against multiple independent address ranges or using
some alternate markup of them.
Rich
^ permalink raw reply
* [PATCH v4, 3/4] powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 15:35 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416153537.23736-1-wenhu.wang@vivo.com>
Function instantiate_cache_sram should not be linked into the init
section for its caller mpc85xx_l2ctlr_of_probe is none-__init.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
Warning information:
MODPOST vmlinux.o
WARNING: modpost: vmlinux.o(.text+0x1e540): Section mismatch in reference from the function mpc85xx_l2ctlr_of_probe() to the function .init.text:instantiate_cache_sram()
The function mpc85xx_l2ctlr_of_probe() references
the function __init instantiate_cache_sram().
This is often because mpc85xx_l2ctlr_of_probe lacks a __init
annotation or the annotation of instantiate_cache_sram is wrong.
---
Changes since v1:
* None
Changes since v2:
* None
Changes since v3:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index be3aef4229d7..3de5ac8382c0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -68,7 +68,7 @@ void mpc85xx_cache_sram_free(void *ptr)
}
EXPORT_SYMBOL(mpc85xx_cache_sram_free);
-int __init instantiate_cache_sram(struct platform_device *dev,
+int instantiate_cache_sram(struct platform_device *dev,
struct sram_parameters sram_params)
{
int ret = 0;
--
2.17.1
^ permalink raw reply related
* [PATCH v4,4/4] drivers: uio: new driver for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 15:35 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416153537.23736-1-wenhu.wang@vivo.com>
A driver for freescale 85xx platforms to access the Cache-Sram form
user level. This is extremely helpful for some user-space applications
that require high performance memory accesses.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* of_match_table modified to be apart from HW info which belong to
the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calc(really learned a lot from Christophe)
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
Changes since v3:
* Addressed comments from Christophe(use devm_xxx memory alloc interfaces)
---
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 148 ++++++++++++++++++++++++++
3 files changed, 158 insertions(+)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
index 202ee81cfc2b..9c3b47461b71 100644
--- a/drivers/uio/Kconfig
+++ b/drivers/uio/Kconfig
@@ -105,6 +105,15 @@ config UIO_NETX
To compile this driver as a module, choose M here; the module
will be called uio_netx.
+config UIO_FSL_85XX_CACHE_SRAM
+ tristate "Freescale 85xx Cache-Sram driver"
+ depends on FSL_SOC_BOOKE && PPC32
+ select FSL_85XX_CACHE_SRAM
+ help
+ Generic driver for accessing the Cache-Sram form user level. This
+ is extremely helpful for some user-space applications that require
+ high performance memory accesses.
+
config UIO_FSL_ELBC_GPCM
tristate "eLBC/GPCM driver"
depends on FSL_LBC
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index c285dd2a4539..be2056cffc21 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -10,4 +10,5 @@ obj-$(CONFIG_UIO_NETX) += uio_netx.o
obj-$(CONFIG_UIO_PRUSS) += uio_pruss.o
obj-$(CONFIG_UIO_MF624) += uio_mf624.o
obj-$(CONFIG_UIO_FSL_ELBC_GPCM) += uio_fsl_elbc_gpcm.o
+obj-$(CONFIG_UIO_FSL_85XX_CACHE_SRAM) += uio_fsl_85xx_cache_sram.o
obj-$(CONFIG_UIO_HV_GENERIC) += uio_hv_generic.o
diff --git a/drivers/uio/uio_fsl_85xx_cache_sram.c b/drivers/uio/uio_fsl_85xx_cache_sram.c
new file mode 100644
index 000000000000..cb339d1f9019
--- /dev/null
+++ b/drivers/uio/uio_fsl_85xx_cache_sram.c
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Vivo Communication Technology Co. Ltd.
+ * Copyright (C) 2020 Wang Wenhu <wenhu.wang@vivo.com>
+ * All rights reserved.
+ */
+
+#include <linux/platform_device.h>
+#include <linux/uio_driver.h>
+#include <linux/stringify.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <asm/fsl_85xx_cache_sram.h>
+
+#define DRIVER_NAME "uio_fsl_85xx_cache_sram"
+#define UIO_INFO_VER "devicetree,pseudo"
+#define UIO_NAME "uio_cache_sram"
+
+static void uio_info_free_internal(struct uio_info *info)
+{
+ int i;
+
+ for (i = 0; i < MAX_UIO_MAPS; i++) {
+ struct uio_mem *uiomem = &info->mem[i];
+
+ if (uiomem->internal_addr) {
+ mpc85xx_cache_sram_free(uiomem->internal_addr);
+ memset(uiomem, 0, sizeof(*uiomem));
+ }
+ }
+}
+
+static int uio_fsl_85xx_cache_sram_probe(struct platform_device *pdev)
+{
+ struct device_node *parent = pdev->dev.of_node;
+ struct device_node *node = NULL;
+ struct uio_info *info;
+ struct uio_mem *uiomem;
+ const char *dt_name;
+ u32 mem_size;
+ int ret;
+
+ /* alloc uio_info for one device */
+ info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ /* get optional uio name */
+ if (of_property_read_string(parent, "uio_name", &dt_name))
+ dt_name = UIO_NAME;
+
+ info->name = devm_kstrdup(&pdev->dev, dt_name, GFP_KERNEL);
+ if (!info->name)
+ return -ENOMEM;
+
+ uiomem = info->mem;
+ for_each_child_of_node(parent, node) {
+ void *virt;
+ phys_addr_t phys;
+
+ ret = of_property_read_u32(node, "cache-mem-size", &mem_size);
+ if (ret) {
+ ret = -EINVAL;
+ goto err_out;
+ }
+
+ if (mem_size == 0) {
+ dev_err(&pdev->dev, "error cache-mem-size should not be 0\n");
+ ret = -EINVAL;
+ goto err_out;
+ }
+
+ virt = mpc85xx_cache_sram_alloc(mem_size, &phys,
+ roundup_pow_of_two(mem_size));
+ if (!virt) {
+ /* mpc85xx_cache_sram_alloc to define the real cause */
+ ret = -ENOMEM;
+ goto err_out;
+ }
+
+ uiomem->memtype = UIO_MEM_PHYS;
+ uiomem->addr = phys;
+ uiomem->size = mem_size;
+ uiomem->name = kstrdup(node->name, GFP_KERNEL);;
+ uiomem->internal_addr = virt;
+ uiomem++;
+
+ if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
+ dev_warn(&pdev->dev, "more than %d uio-maps for device.\n",
+ MAX_UIO_MAPS);
+ break;
+ }
+ }
+
+ if (uiomem == info->mem) {
+ dev_err(&pdev->dev, "error no valid uio-map configuration found\n");
+ return -EINVAL;
+ }
+
+ info->version = UIO_INFO_VER;
+
+ /* register uio device */
+ if (uio_register_device(&pdev->dev, info)) {
+ dev_err(&pdev->dev, "error uio,cache-sram registration failed\n");
+ ret = -ENODEV;
+ goto err_out;
+ }
+
+ platform_set_drvdata(pdev, info);
+
+ return 0;
+err_out:
+ uio_info_free_internal(info);
+ return ret;
+}
+
+static int uio_fsl_85xx_cache_sram_remove(struct platform_device *pdev)
+{
+ struct uio_info *info = platform_get_drvdata(pdev);
+
+ uio_unregister_device(info);
+
+ uio_info_free_internal(info);
+
+ return 0;
+}
+
+static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
+ { .compatible = "uio,mpc85xx-cache-sram", },
+ {},
+};
+
+static struct platform_driver uio_fsl_85xx_cache_sram = {
+ .probe = uio_fsl_85xx_cache_sram_probe,
+ .remove = uio_fsl_85xx_cache_sram_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .owner = THIS_MODULE,
+ .of_match_table = uio_mpc85xx_l2ctlr_of_match,
+ },
+};
+
+module_platform_driver(uio_fsl_85xx_cache_sram);
+
+MODULE_AUTHOR("Wang Wenhu <wenhu.wang@vivo.com>");
+MODULE_DESCRIPTION("Freescale MPC85xx Cache-Sram UIO Platform Driver");
+MODULE_ALIAS("platform:" DRIVER_NAME);
+MODULE_LICENSE("GPL v2");
--
2.17.1
^ permalink raw reply related
* [PATCH v4, 1/4] powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
From: Wang Wenhu @ 2020-04-16 15:35 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416153537.23736-1-wenhu.wang@vivo.com>
Include "linux/of_address.h" to fix the compile error for
mpc85xx_l2ctlr_of_probe() when compiling fsl_85xx_cache_sram.c.
CC arch/powerpc/sysdev/fsl_85xx_l2ctlr.o
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c: In function ‘mpc85xx_l2ctlr_of_probe’:
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:11: error: implicit declaration of function ‘of_iomap’; did you mean ‘pci_iomap’? [-Werror=implicit-function-declaration]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^~~~~~~~
pci_iomap
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c:90:9: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
l2ctlr = of_iomap(dev->dev.of_node, 0);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:267: recipe for target 'arch/powerpc/sysdev/fsl_85xx_l2ctlr.o' failed
make[2]: *** [arch/powerpc/sysdev/fsl_85xx_l2ctlr.o] Error 1
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
Changes since v2:
* None
Changes since v3:
* None
---
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
index 2d0af0c517bb..7533572492f0 100644
--- a/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
+++ b/arch/powerpc/sysdev/fsl_85xx_l2ctlr.c
@@ -10,6 +10,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of_platform.h>
+#include <linux/of_address.h>
#include <asm/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
* [PATCH v4, 2/4] powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 15:35 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
In-Reply-To: <20200416153537.23736-1-wenhu.wang@vivo.com>
Include linux/io.h into fsl_85xx_cache_sram.c to fix the
implicit-declaration compile error when building Cache-Sram.
arch/powerpc/sysdev/fsl_85xx_cache_sram.c: In function ‘instantiate_cache_sram’:
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:26: error: implicit declaration of function ‘ioremap_coherent’; did you mean ‘bitmap_complement’? [-Werror=implicit-function-declaration]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^~~~~~~~~~~~~~~~
bitmap_complement
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:97:24: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]
cache_sram->base_virt = ioremap_coherent(cache_sram->base_phys,
^
arch/powerpc/sysdev/fsl_85xx_cache_sram.c:123:2: error: implicit declaration of function ‘iounmap’; did you mean ‘roundup’? [-Werror=implicit-function-declaration]
iounmap(cache_sram->base_virt);
^~~~~~~
roundup
cc1: all warnings being treated as errors
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Scott Wood <oss@buserror.net>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Fixes: 6db92cc9d07d ("powerpc/85xx: add cache-sram support")
Signed-off-by: Wang Wenhu <wenhu.wang@vivo.com>
---
Changes since v1:
* None
Changes since v2:
* None
Changes since v3:
* None
---
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
index f6c665dac725..be3aef4229d7 100644
--- a/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
+++ b/arch/powerpc/sysdev/fsl_85xx_cache_sram.c
@@ -17,6 +17,7 @@
#include <linux/of_platform.h>
#include <asm/pgtable.h>
#include <asm/fsl_85xx_cache_sram.h>
+#include <linux/io.h>
#include "fsl_85xx_cache_ctlr.h"
--
2.17.1
^ permalink raw reply related
* [PATCH v4,0/4] drivers: uio: new driver uio_fsl_85xx_cache_sram
From: Wang Wenhu @ 2020-04-16 15:35 UTC (permalink / raw)
To: gregkh, linux-kernel, oss, christophe.leroy, linuxppc-dev
Cc: kernel, Wang Wenhu
Changes since v1:
* Addressed comments from Greg K-H
* Moved kfree(info->name) into uio_info_free_internal()
Changes since v2:
* Drop the patch that modifies Kconfigs of arch/powerpc/platforms
and modified the sequence of patches:
01:dropped, 02->03, 03->02, 04->01, 05->04
* Addressed comments from Greg, Scott and Christophe
* Use "uiomem->internal_addr" as if condition for sram memory free,
and memset the uiomem entry
* Modified of_match_table make the driver apart from Cache-Sram HW info
which belong to the HW level driver fsl_85xx_cache_sram to match
* Use roundup_pow_of_two for align calc(really learned a lot from Christophe)
* Remove useless clear block of uiomem entries.
* Use UIO_INFO_VER micro for info->version, and define it as
"devicetree,pseudo", meaning this is pseudo device and probed from
device tree configuration
* Select FSL_85XX_CACHE_SRAM rather than depends on it
Changes since v3:
* Addressed comments from Christophe(use devm_xxx memory alloc interfaces)
Wang Wenhu (4):
powerpc: sysdev: fix compile error for fsl_85xx_l2ctlr
powerpc: sysdev: fix compile error for fsl_85xx_cache_sram
powerpc: sysdev: fix compile warning for fsl_85xx_cache_sram
drivers: uio: new driver for fsl_85xx_cache_sram
arch/powerpc/sysdev/fsl_85xx_cache_sram.c | 3 +-
arch/powerpc/sysdev/fsl_85xx_l2ctlr.c | 1 +
drivers/uio/Kconfig | 9 ++
drivers/uio/Makefile | 1 +
drivers/uio/uio_fsl_85xx_cache_sram.c | 148 ++++++++++++++++++++++
5 files changed, 161 insertions(+), 1 deletion(-)
create mode 100644 drivers/uio/uio_fsl_85xx_cache_sram.c
--
2.17.1
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 15:35 UTC (permalink / raw)
To: Florian Weimer; +Cc: musl, libc-alpha, linuxppc-dev, Nicholas Piggin, libc-dev
In-Reply-To: <87k12gf32r.fsf@mid.deneb.enyo.de>
On Thu, Apr 16, 2020 at 06:48:44AM +0200, Florian Weimer wrote:
> * Rich Felker:
>
> > My preference would be that it work just like the i386 AT_SYSINFO
> > where you just replace "int $128" with "call *%%gs:16" and the kernel
> > provides a stub in the vdso that performs either scv or the old
> > mechanism with the same calling convention.
>
> The i386 mechanism has received some criticism because it provides an
> effective means to redirect execution flow to anyone who can write to
> the TCB. I am not sure if it makes sense to copy it.
Indeed that's a good point. Do you have ideas for making it equally
efficient without use of a function pointer in the TCB?
Rich
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox