[PATCH] powerpc: remove PReP
PPC_PREP is marked as BROKEN since v2.6.15. Remove all PReP specific code now. Signed-off-by: Paul Bolle --- 0) Suggested by Michael. 1) Sent as one patch. powerpc is the biggest chunk (if one includes the doc changes). Is it easier if I split this into a number maintainer specific patches? Ie, split into: powerpc, doc, pnp and fb. 2) None of this is tested. None! Since I'm not actually involved in powerpc in any way, not everyone might consider me the first choice to do this cleanup. 3) I removed two files in documentation that are almost entirely PReP specific. The remaining lines looked uninteresting. 4) I grepped thoroughly for second order effects. I also grepped for remaining references to PReP. This patch has all things I thought that could be dropped. Perhaps doing git grep -n PReP | grep -v -i -e rewritten -e dougan might still reveal, to those familiar with PReP, a few places of outdated stuff. Documentation/powerpc/00-INDEX | 4 -- Documentation/powerpc/sound.txt | 81 - Documentation/powerpc/zImage_layout.txt | 47 --- arch/powerpc/Kconfig| 8 ++-- arch/powerpc/include/asm/dma.h | 5 -- arch/powerpc/include/asm/io.h | 4 -- arch/powerpc/include/asm/processor.h| 9 +--- arch/powerpc/kernel/setup-common.c | 6 --- arch/powerpc/platforms/Kconfig | 3 +- arch/powerpc/platforms/prep/Kconfig | 23 -- drivers/pnp/pnpbios/core.c | 9 +--- drivers/video/cirrusfb.c| 62 + 12 files changed, 19 insertions(+), 242 deletions(-) delete mode 100644 Documentation/powerpc/sound.txt delete mode 100644 Documentation/powerpc/zImage_layout.txt delete mode 100644 arch/powerpc/platforms/prep/Kconfig diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index 5620fb5..dd9e928 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX @@ -14,10 +14,6 @@ hvcs.txt - IBM "Hypervisor Virtual Console Server" Installation Guide mpc52xx.txt - Linux 2.6.x on MPC52xx family -sound.txt - - info on sound support under Linux/PPC -zImage_layout.txt - - info on the kernel images for Linux/PPC qe_firmware.txt - describes the layout of firmware binaries for the Freescale QUICC Engine and the code that parses and uploads the microcode therein. diff --git a/Documentation/powerpc/sound.txt b/Documentation/powerpc/sound.txt deleted file mode 100644 index df23d95..000 --- a/Documentation/powerpc/sound.txt +++ /dev/null @@ -1,81 +0,0 @@ -Information about PowerPC Sound support -= - -Please mail me (Cort Dougan, c...@fsmlabs.com) if you have questions, -comments or corrections. - -Last Change: 6.16.99 - -This just covers sound on the PReP and CHRP systems for now and later -will contain information on the PowerMac's. - -Sound on PReP has been tested and is working with the PowerStack and IBM -Power Series onboard sound systems which are based on the cs4231(2) chip. -The sound options when doing the make config are a bit different from -the default, though. - -The I/O base, irq and dma lines that you enter during the make config -are ignored and are set when booting according to the machine type. -This is so that one binary can be used for Motorola and IBM machines -which use different values and isn't allowed by the driver, so things -are hacked together in such a way as to allow this information to be -set automatically on boot. - -1. Motorola PowerStack PReP machines - - Enable support for "Crystal CS4232 based (PnP) cards" and for the - Microsoft Sound System. The MSS isn't used, but some of the routines - that the CS4232 driver uses are in it. - - Although the options you set are ignored and determined automatically - on boot these are included for information only: - - (830) CS4232 audio I/O base 530, 604, E80 or F40 - (10) CS4232 audio IRQ 5, 7, 9, 11, 12 or 15 - (6) CS4232 audio DMA 0, 1 or 3 - (7) CS4232 second (duplex) DMA 0, 1 or 3 - - This will allow simultaneous record and playback, as 2 different dma - channels are used. - - The sound will be all left channel and very low volume since the - auxiliary input isn't muted by default. I had the changes necessary - for this in the kernel but the sound driver maintainer didn't want - to include them since it wasn't common in other machines. To fix this - you need to mute it using a mixer utility of some sort (if you find one - please let me know) or by patching the driver yourself and recompiling. - - There is a problem on the PowerStack 2's (PowerStack Pro's) using a - different irq/drq than the kernel expects. Unfortunately, I don't know - which irq/drq it is so if anyone knows please email me. - - Midi is not supported since the cs4232 driver doesn't support midi yet. - -2. I
Re: [PATCH] powerpc: drop even more unused Kconfig symbols
On Thu, 2013-03-21 at 12:10 +0100, Paul Bolle wrote: > diff --git a/arch/powerpc/platforms/wsp/Kconfig > b/arch/powerpc/platforms/wsp/Kconfig > index 79d2225..9eea710 100644 > --- a/arch/powerpc/platforms/wsp/Kconfig > +++ b/arch/powerpc/platforms/wsp/Kconfig > @@ -29,7 +29,3 @@ config PPC_CHROMA > default y > > endmenu > - > -config PPC_A2_DD2 > - bool "Support for DD2 based A2/WSP systems" > - depends on PPC_A2 This part was not included in the "powerpc: remove PReP" follow up patch. Should I resend separately? Paul Bolle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove PReP
On Wed, Mar 27, 2013 at 11:47 AM, Paul Bolle wrote:
> 3) I removed two files in documentation that are almost entirely PReP
> specific. The remaining lines looked uninteresting.
> --- a/Documentation/powerpc/sound.txt
> +++ /dev/null
> -2. IBM CHRP
> -
> - I have only tested this on the 43P-150. Build the kernel with the cs4232
> - set as a module and load the module with irq=9 dma=1 dma2=2 io=0x550
This section is CHRP-specific. The cs4232 driver also worked on the
CHRP LongTrail.
But I don't remember if the parameter values above also applied to LongTrail.
I do remember it didn't work without specifing the right parameters, so you
probably want to keep this section.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove PReP
On Wed, 2013-03-27 at 13:05 +0100, Geert Uytterhoeven wrote: > This section is CHRP-specific. The cs4232 driver also worked on the > CHRP LongTrail. > But I don't remember if the parameter values above also applied to LongTrail. > I do remember it didn't work without specifing the right parameters, so you > probably want to keep this section. My reasoning was quite simply that this file was 14 years old so that probably nobody is using that stuff anymore. Are people actually using CHRP (whatever that is)? Anyhow, cs4232 is mentioned in some other files too: $ git grep -l -n cs4232 Documentation/ Documentation/powerpc/sound.txt Documentation/sound/alsa/ALSA-Configuration.txt Documentation/sound/alsa/alsa-parameters.txt Documentation/sound/oss/Introduction Documentation/sound/oss/Tropez+ Could these few lines be dumped in one of these (except powerpc/sound.txt, of course)? Paul Bolle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove PReP
By the way, I get bounces from Adam's address: > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > > For further assistance, please send mail to > > If you do so, please include this problem report. You can > delete your own text from the attached returned message. > > : 550 5.1.1 ... User unknown (It's now removed from the CC line.) Does anyone know what's going on here? Paul Bolle ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function
On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote: > But we also know pdev is a PCIe device, and I think a PCIe device on a > root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec > 1.3.2.3). Such a device does not have a link at all, so there's no > point in fiddling with its link speed. This is where our IBM hypervisor makes things murky. It doesn't expose the PCIe parents (basically somewhat makes PCIe look like PCI except we still have the PCIe caps on the child devices, just no access to the parent device). It's garbage but can't be fixed (would break AIX :-) However we might be able to populate the bus->max_bus_speed from some architecture specific quirk and have radeon use that. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: remove PReP
On 2013-03-27 06:42, Paul Bolle wrote: On Wed, 2013-03-27 at 13:05 +0100, Geert Uytterhoeven wrote: This section is CHRP-specific. The cs4232 driver also worked on the CHRP LongTrail. But I don't remember if the parameter values above also applied to LongTrail. I do remember it didn't work without specifing the right parameters, so you probably want to keep this section. My reasoning was quite simply that this file was 14 years old so that probably nobody is using that stuff anymore. Are people actually using CHRP (whatever that is)? Anyhow, cs4232 is mentioned in some other files Common Hardware Reference Platform - see http://en.wikipedia.org/wiki/Common_Hardware_Reference_Platform too: $ git grep -l -n cs4232 Documentation/ Documentation/powerpc/sound.txt Documentation/sound/alsa/ALSA-Configuration.txt Documentation/sound/alsa/alsa-parameters.txt Documentation/sound/oss/Introduction Documentation/sound/oss/Tropez+ Could these few lines be dumped in one of these (except powerpc/sound.txt, of course)? Seeing this stuff go marks the end of an era (the PreP and CHRP platforms were some of the very first devices to run Linux back in 1995...) I just sent my last one to the recycler a few months back :-( -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7 v2] KVM: PPC: e500: Expose MMU registers via ONE_REG
On 26.03.2013, at 23:05, Mihai Caraman wrote:
> MMU registers were exposed to user-space using sregs interface. Add them
> to ONE_REG interface and use kvmppc_get_one_reg/kvmppc_set_one_reg delegation
> interface introduced by book3s.
>
> Signed-off-by: Mihai Caraman
> ---
> v2:
> - Restrict set_one_reg operation for MMU registers to HW values
>
> Documentation/virtual/kvm/api.txt | 11 +
> arch/powerpc/include/uapi/asm/kvm.h | 17 +++
> arch/powerpc/kvm/44x.c | 12 +
> arch/powerpc/kvm/booke.c| 83 --
> arch/powerpc/kvm/e500.c | 14 ++
> arch/powerpc/kvm/e500.h |4 ++
> arch/powerpc/kvm/e500_mmu.c | 84 +++
> arch/powerpc/kvm/e500mc.c | 14 ++
> 8 files changed, 205 insertions(+), 34 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index 976eb65..1a76663 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1792,6 +1792,17 @@ registers, find a list below:
> PPC | KVM_REG_PPC_TSR | 32
> PPC | KVM_REG_PPC_OR_TSR | 32
> PPC | KVM_REG_PPC_CLEAR_TSR | 32
> + PPC | KVM_REG_PPC_MAS0 | 32
> + PPC | KVM_REG_PPC_MAS1 | 32
> + PPC | KVM_REG_PPC_MAS2 | 64
> + PPC | KVM_REG_PPC_MAS7_3 | 64
> + PPC | KVM_REG_PPC_MAS4 | 32
> + PPC | KVM_REG_PPC_MAS6 | 32
> + PPC | KVM_REG_PPC_MMUCFG | 32
> + PPC | KVM_REG_PPC_TLB0CFG| 32
> + PPC | KVM_REG_PPC_TLB1CFG| 32
> + PPC | KVM_REG_PPC_TLB2CFG| 32
> + PPC | KVM_REG_PPC_TLB3CFG| 32
>
> ARM registers are mapped using the lower 32 bits. The upper 16 of that
> is the register group type, or coprocessor number:
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h
> b/arch/powerpc/include/uapi/asm/kvm.h
> index ef072b1..777dc81 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -422,4 +422,21 @@ struct kvm_get_htab_header {
> #define KVM_REG_PPC_CLEAR_TSR (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x88)
> #define KVM_REG_PPC_TCR (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x89)
> #define KVM_REG_PPC_TSR (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x8a)
> +
> +/* MMU registers */
> +#define KVM_REG_PPC_MAS0 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x8b)
> +#define KVM_REG_PPC_MAS1 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x8c)
> +#define KVM_REG_PPC_MAS2 (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x8d)
> +#define KVM_REG_PPC_MAS7_3 (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x8e)
> +#define KVM_REG_PPC_MAS4 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x8f)
> +#define KVM_REG_PPC_MAS6 (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x90)
> +#define KVM_REG_PPC_MMUCFG (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x91)
> +/*
> + * TLBnCFG fields TLBnCFG_N_ENTRY and TLBnCFG_ASSOC can be changed only using
> + * KVM_CAP_SW_TLB ioctl
> + */
> +#define KVM_REG_PPC_TLB0CFG (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x92)
> +#define KVM_REG_PPC_TLB1CFG (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x93)
> +#define KVM_REG_PPC_TLB2CFG (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x94)
> +#define KVM_REG_PPC_TLB3CFG (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x95)
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
> index 3d7fd21..2f5c6b6 100644
> --- a/arch/powerpc/kvm/44x.c
> +++ b/arch/powerpc/kvm/44x.c
> @@ -124,6 +124,18 @@ int kvmppc_core_set_sregs(struct kvm_vcpu *vcpu, struct
> kvm_sregs *sregs)
> return kvmppc_set_sregs_ivor(vcpu, sregs);
> }
>
> +int kvmppc_get_one_reg(struct kvm_vcpu *vcpu, u64 id,
> + union kvmppc_one_reg *val)
> +{
> + return -EINVAL;
> +}
> +
> +int kvmppc_set_one_reg(struct kvm_vcpu *vcpu, u64 id,
> +union kvmppc_one_reg *val)
> +{
> + return -EINVAL;
> +}
> +
> struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
> {
> struct kvmppc_vcpu_44x *vcpu_44x;
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index 58057d6..c67e99f 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1412,111 +1412,126 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu
> *vcpu,
>
> int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, struct kvm_one_reg *reg)
> {
> - int r = -EINVAL;
> + int r = 0;
> + union kvmppc_one_reg val;
> + int size;
> + long int i;
> +
> + size = one_reg_size(reg->id);
> + if (size > sizeof(val))
> + return -EINVAL;
>
> switch (reg->id) {
> case KVM_REG_PPC_IAC1:
> case KVM_REG_PPC_IAC2:
> case KVM_REG_PPC_IAC3:
> case KVM_REG_PPC_IAC4: {
> - int iac = reg->id - KVM_REG_PPC_IAC1;
> - r = copy_to_user((u64 __user *)(long)reg->addr,
> - &vcpu->arch.dbg_reg.iac[iac], sizeof(u64));
> + i = reg->id - KVM_REG_PPC_IAC1;
> +
Re: [PATCH] powerpc: remove PReP
On Wed, 2013-03-27 at 13:05 +0100, Geert Uytterhoeven wrote:
> On Wed, Mar 27, 2013 at 11:47 AM, Paul Bolle wrote:
> > 3) I removed two files in documentation that are almost entirely PReP
> > specific. The remaining lines looked uninteresting.
>
> > --- a/Documentation/powerpc/sound.txt
> > +++ /dev/null
>
> > -2. IBM CHRP
> > -
> > - I have only tested this on the 43P-150. Build the kernel with the cs4232
> > - set as a module and load the module with irq=9 dma=1 dma2=2 io=0x550
>
> This section is CHRP-specific. The cs4232 driver also worked on the
> CHRP LongTrail.
> But I don't remember if the parameter values above also applied to LongTrail.
> I do remember it didn't work without specifing the right parameters, so you
> probably want to keep this section.
Isn't LongTrail support LongDead ? Can we still boot these things at
all ? Anybody still has a functional one ?
Cheers,
Ben.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function
On Wed, Mar 27, 2013 at 9:25 AM, Benjamin Herrenschmidt wrote: > On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote: >> But we also know pdev is a PCIe device, and I think a PCIe device on a >> root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec >> 1.3.2.3). Such a device does not have a link at all, so there's no >> point in fiddling with its link speed. > > This is where our IBM hypervisor makes things murky. It doesn't expose > the PCIe parents (basically somewhat makes PCIe look like PCI except we > still have the PCIe caps on the child devices, just no access to the > parent device). Interesting. I wonder if we'll trip over this anywhere else, e.g., ASPM or other link-related things. I guess we'll just have to see if anything else breaks. > It's garbage but can't be fixed (would break AIX :-) > > However we might be able to populate the bus->max_bus_speed from some > architecture specific quirk and have radeon use that. That sounds like a good solution to me. It seems like it's really an arch-specific deviation from the spec, so it'd be nice to have an arch-specific solution for it. Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/mpic: add global timer support
On 03/26/2013 10:23:38 PM, Wang Dongsheng-B40534 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, March 27, 2013 1:32 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
> Li Yang-R58472
> Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
>
> On 03/25/2013 10:29:58 PM, Wang Dongsheng-B40534 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Saturday, March 23, 2013 6:30 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Gala Kumar-B11780;
> > linuxppc-dev@lists.ozlabs.org;
> > > Li Yang-R58472
> > > Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
> > >
> > > On 03/22/2013 01:14:51 AM, Wang Dongsheng-B40534 wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, March 21, 2013 7:00 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Wood Scott-B07421; Gala Kumar-B11780;
> > > > linuxppc-dev@lists.ozlabs.org;
> > > > > Li Yang-R58472
> > > > > Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer
support
> > > > >
> > > > > BTW, the input clock frequency has been similarly scaled,
yet
> > you
> > > > don't
> > > > > try to scrounge up that information to get further
precision...
> > > > >
> > > > Let's go back patch, do you think the code is repeated?
> > > > I will remove "if (!(priv->flags & FSL_GLOBAL_TIMER))" branch,
> > there
> > > > will be no redundant code.
> > >
> > > I'd rather that branch be kept and the more complicated branch
> > deleted,
> > > and priv->timerfreq frequency be adjusted on initialization to
> > account
> > > for the scaler.
> >
> > static void convert_ticks_to_time(struct timer_group_priv *priv,
> > const u64 ticks, struct timeval *time) {
> > u64 tmp_sec;
> >
> > time->tv_sec = (__kernel_time_t)div_u64(ticks,
> > priv->timerfreq);
> > tmp_sec = (u64)time->tv_sec * (u64)priv->timerfreq;
> >
> > time->tv_usec = (__kernel_suseconds_t)
> > div_u64((ticks - tmp_sec) * 100,
priv->timerfreq);
> >
> > return;
> > }
> >
> > timer_group_get_freq() {
> > ...
> > if (priv->flags & FSL_GLOBAL_TIMER) {
> > div = (1 << (MPIC_TIMER_TCR_CLKDIV_64 >> 8)) * 8;
> > priv->timerfreq /= div;
> > }
> > ...
> > }
> > Do you want to do that?
>
>if (priv->flags & FSL_GLOBAL_TIMER)
>priv->timerfreq /= 64;
>
> ...but otherwise yes.
Ok, I would like do this.
if (priv->flags & FSL_GLOBAL_TIMER) {
div = (1 << (MPIC_TIMER_TCR_CLKDIV_64 >> 8)) * 8;
priv->timerfreq /= div;
Why? What do you get out of that obfuscation?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/7 v2] KVM: PPC: e500: Add support for EPTCFG register
On 26.03.2013, at 23:05, Mihai Caraman wrote:
> EPTCFG register defined by E.PT is accessed unconditionally by Linux guests
> in the presence of MAV 2.0. Support it now.
>
> Signed-off-by: Mihai Caraman
> ---
> v2:
> - Use has_feature() function
>
> Documentation/virtual/kvm/api.txt |1 +
> arch/powerpc/include/asm/kvm_host.h |1 +
> arch/powerpc/include/uapi/asm/kvm.h |1 +
> arch/powerpc/kvm/e500.h |5 +
> arch/powerpc/kvm/e500_emulate.c |9 +
> arch/powerpc/kvm/e500_mmu.c | 11 +++
> 6 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt
> b/Documentation/virtual/kvm/api.txt
> index f045377..a1f2200 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -1807,6 +1807,7 @@ registers, find a list below:
> PPC | KVM_REG_PPC_TLB1PS | 32
> PPC | KVM_REG_PPC_TLB2PS | 32
> PPC | KVM_REG_PPC_TLB3PS | 32
> + PPC | KVM_REG_PPC_EPTCFG | 32
>
> ARM registers are mapped using the lower 32 bits. The upper 16 of that
> is the register group type, or coprocessor number:
> diff --git a/arch/powerpc/include/asm/kvm_host.h
> b/arch/powerpc/include/asm/kvm_host.h
> index 3b6cee3..8a48e68 100644
> --- a/arch/powerpc/include/asm/kvm_host.h
> +++ b/arch/powerpc/include/asm/kvm_host.h
> @@ -504,6 +504,7 @@ struct kvm_vcpu_arch {
> u32 tlbcfg[4];
> u32 tlbps[4];
> u32 mmucfg;
> + u32 eptcfg;
> u32 epr;
> u32 crit_save;
> struct kvmppc_booke_debug_reg dbg_reg;
> diff --git a/arch/powerpc/include/uapi/asm/kvm.h
> b/arch/powerpc/include/uapi/asm/kvm.h
> index 7cfd13f..9d7fbf0 100644
> --- a/arch/powerpc/include/uapi/asm/kvm.h
> +++ b/arch/powerpc/include/uapi/asm/kvm.h
> @@ -443,4 +443,5 @@ struct kvm_get_htab_header {
> #define KVM_REG_PPC_TLB1PS(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x97)
> #define KVM_REG_PPC_TLB2PS(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x98)
> #define KVM_REG_PPC_TLB3PS(KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x99)
> +#define KVM_REG_PPC_EPTCFG (KVM_REG_PPC | KVM_REG_SIZE_U32 | 0x9a)
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/arch/powerpc/kvm/e500.h b/arch/powerpc/kvm/e500.h
> index 795934d..6cfc669 100644
> --- a/arch/powerpc/kvm/e500.h
> +++ b/arch/powerpc/kvm/e500.h
> @@ -24,6 +24,7 @@
> #include
>
> #define VCPU_FTR_MMU_V2 0
> +#define VCPU_FTR_E_PT1
>
> #define E500_PID_NUM 3
> #define E500_TLB_NUM 2
> @@ -309,6 +310,10 @@ static inline bool has_feature(const struct kvm_vcpu
> *vcpu,
> case VCPU_FTR_MMU_V2:
> has_ftr = ((vcpu->arch.mmucfg & MMUCFG_MAVN) == MMUCFG_MAVN_V2);
> break;
> + case VCPU_FTR_E_PT:
> + has_ftr = ((vcpu->arch.tlbcfg[1] & TLBnCFG_IND) &&
> +(vcpu->arch.tlbcfg[0] & TLBnCFG_PT));
> + break;
> default:
> has_ftr = false;
> }
> diff --git a/arch/powerpc/kvm/e500_emulate.c b/arch/powerpc/kvm/e500_emulate.c
> index 12b8de2..b10a012 100644
> --- a/arch/powerpc/kvm/e500_emulate.c
> +++ b/arch/powerpc/kvm/e500_emulate.c
> @@ -317,6 +317,15 @@ int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int
> sprn, ulong *spr_val)
> case SPRN_MMUCFG:
> *spr_val = vcpu->arch.mmucfg;
> break;
> + case SPRN_EPTCFG:
> + if (!has_feature(vcpu, VCPU_FTR_MMU_V2))
> + return EMULATE_FAIL;
> + /*
> + * Legacy Linux guests access EPTCFG register even if the E.PT
> + * category is disabled in the VM. Give them a chance to live.
> + */
> + *spr_val = vcpu->arch.eptcfg;
> + break;
>
> /* extra exceptions */
> case SPRN_IVOR32:
> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> index e354fa1..cf60db1 100644
> --- a/arch/powerpc/kvm/e500_mmu.c
> +++ b/arch/powerpc/kvm/e500_mmu.c
> @@ -617,6 +617,8 @@ int kvmppc_get_one_reg_e500_tlb(struct kvm_vcpu *vcpu,
> u64 id,
> *val = get_reg_val(id, vcpu->arch.shared->mas6);
> case KVM_REG_PPC_MMUCFG:
> *val = get_reg_val(id, vcpu->arch.mmucfg);
> + case KVM_REG_PPC_EPTCFG:
> + *val = get_reg_val(id, vcpu->arch.eptcfg);
> case KVM_REG_PPC_TLB0CFG:
> case KVM_REG_PPC_TLB1CFG:
> case KVM_REG_PPC_TLB2CFG:
> @@ -668,6 +670,10 @@ int kvmppc_set_one_reg_e500_tlb(struct kvm_vcpu *vcpu,
> u64 id,
> r = -EINVAL;
> break;
> }
> + case KVM_REG_PPC_EPTCFG:
> + if (set_reg_val(id, *val) != vcpu->arch.eptcfg)
> + r = -EINVAL;
> + break;
> case KVM_REG_PPC_TLB0CFG:
> case KVM_REG_PPC_TLB1CFG:
> case KVM_REG_PPC_TLB2CFG:
> @@ -861,6 +867,11 @@ static int vcpu_mmu_init(struct kvm_vcpu *vcpu,
> vcpu->arch.tlbcfg[1] |= params[1].ways << TLBnCFG_ASSOC_SHIFT;
>
>
Re: [PATCH 5/7 v2] KVM: PPC: e500: Remove E.PT and E.HV.LRAT categories from VCPUs
On 26.03.2013, at 23:05, Mihai Caraman wrote:
> Embedded.Page Table (E.PT) category in VMs requires indirect tlb entries
> emulation which is not supported yet. Configure TLBnCFG to remove E.PT
> and E.HV.LRAT categories from VCPUs.
>
> Signed-off-by: Mihai Caraman
> ---
> v2:
> - Remove E.HV.LRAT from vcpus
>
> arch/powerpc/kvm/e500_mmu.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> index cf60db1..0d2a293 100644
> --- a/arch/powerpc/kvm/e500_mmu.c
> +++ b/arch/powerpc/kvm/e500_mmu.c
> @@ -867,11 +867,17 @@ static int vcpu_mmu_init(struct kvm_vcpu *vcpu,
> vcpu->arch.tlbcfg[1] |= params[1].ways << TLBnCFG_ASSOC_SHIFT;
>
> if (has_feature(vcpu, VCPU_FTR_MMU_V2)) {
> + vcpu->arch.mmucfg &= ~MMUCFG_LRAT;
> +
> if (has_feature(vcpu, VCPU_FTR_E_PT))
> vcpu->arch.eptcfg = mfspr(SPRN_EPTCFG);
> else
> vcpu->arch.eptcfg = 0;
>
> + /* Guest mmu emulation currently doesn't handle E.PT */
> + vcpu->arch.tlbcfg[0] &= ~TLBnCFG_PT;
> + vcpu->arch.tlbcfg[1] &= ~TLBnCFG_IND;
Can we make this conditional on bits in EPTCFG? Then by initializing it to 0
today, we always mask PT/IND out, but later when we support EPT, we only have
to set the bit in EPTCFG and everyone's happy?
Alex
> +
> vcpu->arch.tlbps[0] = mfspr(SPRN_TLB0PS);
> vcpu->arch.tlbps[1] = mfspr(SPRN_TLB1PS);
> }
> --
> 1.7.4.1
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/7 v2] KVM: PPC: e500: Remove E.PT and E.HV.LRAT categories from VCPUs
On 03/26/2013 05:05:10 PM, Mihai Caraman wrote:
Embedded.Page Table (E.PT) category in VMs requires indirect tlb
entries
emulation which is not supported yet. Configure TLBnCFG to remove E.PT
and E.HV.LRAT categories from VCPUs.
Signed-off-by: Mihai Caraman
---
v2:
- Remove E.HV.LRAT from vcpus
arch/powerpc/kvm/e500_mmu.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
index cf60db1..0d2a293 100644
--- a/arch/powerpc/kvm/e500_mmu.c
+++ b/arch/powerpc/kvm/e500_mmu.c
@@ -867,11 +867,17 @@ static int vcpu_mmu_init(struct kvm_vcpu *vcpu,
vcpu->arch.tlbcfg[1] |= params[1].ways << TLBnCFG_ASSOC_SHIFT;
if (has_feature(vcpu, VCPU_FTR_MMU_V2)) {
+ vcpu->arch.mmucfg &= ~MMUCFG_LRAT;
+
if (has_feature(vcpu, VCPU_FTR_E_PT))
vcpu->arch.eptcfg = mfspr(SPRN_EPTCFG);
else
vcpu->arch.eptcfg = 0;
+ /* Guest mmu emulation currently doesn't handle E.PT */
+ vcpu->arch.tlbcfg[0] &= ~TLBnCFG_PT;
+ vcpu->arch.tlbcfg[1] &= ~TLBnCFG_IND;
You're clearing these bits *after* calling has_feature() -- doesn't
has_feature() depend on those bits being cleared to not advertise E_PT
support?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] cpufreq: Add cpufreq driver for Freescale e500mc SOCs
On Tue, 26 Mar 2013 10:36:31 +0800
wrote:
> +static int __init ppc_corenet_cpufreq_init(void)
> +{
> + int ret = 0;
> + struct device_node *np;
> + const struct of_device_id *match;
> +
> + np = of_find_matching_node(NULL, node_matches);
> + if (!np)
> + return -ENODEV;
> +
> + match = of_match_node(node_matches, np);
> + freq_data.cpus_per_cluster = (long)match->data;
> + mutex_init(&freq_data.cpufreq_lock);
> + of_node_put(np);
> +
> + ret = cpufreq_register_driver(&ppc_corenet_cpufreq_driver);
> + if (ret)
> + return ret;
> +
> + pr_info("Freescale PowerPC corenet CPU frequency scaling driver\n");
> +
> + return ret;
> +}
> +
> +static void __exit ppc_corenet_cpufreq_exit(void)
> +{
> + cpufreq_unregister_driver(&ppc_corenet_cpufreq_driver);
> +}
> +
> +module_init(ppc_corenet_cpufreq_init);
> +module_exit(ppc_corenet_cpufreq_exit);
this needs to be a module_platform_driver.
Kim
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] x86/mm/numa: use setup_nr_node_ids() instead of opencoding.
On 03/26/2013 10:56 AM, Yinghai Lu wrote: > > For 1 and 2, > > Acked-by: Yinghai Lu > Similarly: Acked-by: H. Peter Anvin -hpa ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 04/22] block: Convert bio_for_each_segment() to bvec_iter
More prep work for immutable biovecs - with immutable bvecs drivers
won't be able to use the biovec directly, they'll need to use helpers
that take into account bio->bi_iter.bi_bvec_done.
This updates callers for the new usage without changing the
implementation yet.
Signed-off-by: Kent Overstreet
Cc: Jens Axboe
Cc: Geert Uytterhoeven
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: "Ed L. Cashin"
Cc: Nick Piggin
Cc: Lars Ellenberg
Cc: Jiri Kosina
Cc: Paul Clements
Cc: Jim Paris
Cc: Geoff Levand
Cc: Yehuda Sadeh
Cc: Sage Weil
Cc: Alex Elder
Cc: ceph-de...@vger.kernel.org
Cc: Joshua Morris
Cc: Philip Kelleher
Cc: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge
Cc: Neil Brown
Cc: Martin Schwidefsky
Cc: Heiko Carstens
Cc: linux...@de.ibm.com
Cc: Nagalakshmi Nandigama
Cc: Sreekanth Reddy
Cc: supp...@lsi.com
Cc: "James E.J. Bottomley"
Cc: Greg Kroah-Hartman
Cc: Alexander Viro
Cc: Steven Whitehouse
Cc: Kent Overstreet
Cc: Herton Ronaldo Krzesinski
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Guo Chao
Cc: Asai Thambi S P
Cc: Selvan Mani
Cc: Sam Bradshaw
Cc: Matthew Wilcox
Cc: Keith Busch
Cc: Stephen Hemminger
Cc: Quoc-Son Anh
Cc: Sebastian Ott
Cc: Nitin Gupta
Cc: Minchan Kim
Cc: Jerome Marchand
Cc: Seth Jennings
Cc: "Martin K. Petersen"
Cc: Mike Snitzer
Cc: Vivek Goyal
Cc: "Darrick J. Wong"
Cc: Chris Metcalf
Cc: Jan Kara
Cc: linux-m...@lists.linux-m68k.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: drbd-u...@lists.linbit.com
Cc: nbd-gene...@lists.sourceforge.net
Cc: cbe-oss-...@lists.ozlabs.org
Cc: xen-de...@lists.xensource.com
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-r...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Cc: dl-mptfusionli...@lsi.com
Cc: linux-s...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: linux-fsde...@vger.kernel.org
Cc: cluster-de...@redhat.com
Cc: linux...@kvack.org
---
arch/m68k/emu/nfblock.c | 11 ---
arch/powerpc/sysdev/axonram.c| 18 +--
block/blk-merge.c| 45 ++-
drivers/block/aoe/aoecmd.c | 16 +-
drivers/block/brd.c | 12
drivers/block/drbd/drbd_main.c | 27 +
drivers/block/drbd/drbd_receiver.c | 13
drivers/block/drbd/drbd_worker.c | 8 ++---
drivers/block/floppy.c | 12
drivers/block/loop.c | 23 +++---
drivers/block/mtip32xx/mtip32xx.c| 13
drivers/block/nbd.c | 12
drivers/block/nvme.c | 27 +
drivers/block/ps3vram.c | 10 +++---
drivers/block/rbd.c | 36 +++---
drivers/block/rsxx/dma.c | 11 ---
drivers/block/xen-blkfront.c | 14 -
drivers/md/md.c | 16 +-
drivers/md/raid5.c | 12
drivers/s390/block/dcssblk.c | 14 -
drivers/s390/block/xpram.c | 10 +++---
drivers/scsi/mpt2sas/mpt2sas_transport.c | 31 ++-
drivers/scsi/mpt3sas/mpt3sas_transport.c | 31 ++-
drivers/staging/zram/zram_drv.c | 19 ++--
fs/bio-integrity.c | 30 +-
fs/bio.c | 16 +-
fs/gfs2/lops.c | 10 +++---
include/linux/bio.h | 25 ---
include/linux/blkdev.h | 7 +++--
mm/bounce.c | 52 +++-
30 files changed, 296 insertions(+), 285 deletions(-)
diff --git a/arch/m68k/emu/nfblock.c b/arch/m68k/emu/nfblock.c
index 9070d6c..d2b260c 100644
--- a/arch/m68k/emu/nfblock.c
+++ b/arch/m68k/emu/nfblock.c
@@ -62,17 +62,18 @@ struct nfhd_device {
static void nfhd_make_request(struct request_queue *queue, struct bio *bio)
{
struct nfhd_device *dev = queue->queuedata;
- struct bio_vec *bvec;
- int i, dir, len, shift;
+ struct bio_vec bvec;
+ struct bvec_iter iter;
+ int dir, len, shift;
sector_t sec = bio->bi_iter.bi_sector;
dir = bio_data_dir(bio);
shift = dev->bshift;
- bio_for_each_segment(bvec, bio, i) {
- len = bvec->bv_len;
+ bio_for_each_segment(bvec, bio, iter) {
+ len = bvec.bv_len;
len >>= 9;
nfhd_read_write(dev->id, 0, dir, sec >> shift, len >> shift,
- bvec_to_phys(bvec));
+ bvec_to_phys(&bvec));
sec += len;
}
bio_endio(bio, 0);
diff --git a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
index f33bcba..47b6b9f 100644
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -109,28 +109,28 @@ axon_ram_make_request(struct request_que
Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
On 03/26/2013 10:21:04 PM, Wang Dongsheng-B40534 wrote:
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, March 27, 2013 1:36 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Gala Kumar-B11780;
linuxppc-dev@lists.ozlabs.org;
> Zhao Chenhui-B35336; Li Yang-R58472
> Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
>
> On 03/25/2013 10:27:24 PM, Wang Dongsheng-B40534 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Saturday, March 23, 2013 6:11 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Gala Kumar-B11780;
> > linuxppc-dev@lists.ozlabs.org;
> > > Zhao Chenhui-B35336; Li Yang-R58472
> > > Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup
support
> > >
> > > On 03/22/2013 12:46:24 AM, Wang Dongsheng-B40534 wrote:
> > > > Under what case is unsafe, please make sense.
> > >
> > > char buffer[1] = { '5' };
> > > write(fd, &buffer, 1);
> > >
> > > What comes after that '5' byte in the pointer you pass to
kstrtol?
> > >
> > The buffer is userspace. It will fall in the kernel space.
> > Kernel will get a free page, and copy the buffer to page.
> > This page has been cleared before copy to page.
> > The page has already have null-terminated.
>
> It doesn't allocate a whole page, it uses kmalloc (not kzalloc!).
Even
> if kzalloc were used, a larger user buffer could be the exact size
of the
> region that was allocated.
>
> See memdup_user() in mm/util.c
>
Did you miss something?
See fill_write_buffer() in fs/sysfs/file.c. It's used
get_zeroed_page()...
OK, I was looking at fs/sysfs/bin.c which is something slightly
different.
fill_write_buffer() forces the size to be no more than "PAGE_SIZE - 1"
so we know there's a terminator.
Perhaps kernel/rtmutex-tester.c and kernel/time/clocksource.c are
similarly confused?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: drop even more unused Kconfig symbols
On Wed, Mar 27, 2013 at 11:51:35AM +0100, Paul Bolle wrote: > On Thu, 2013-03-21 at 12:10 +0100, Paul Bolle wrote: > > diff --git a/arch/powerpc/platforms/wsp/Kconfig > > b/arch/powerpc/platforms/wsp/Kconfig > > index 79d2225..9eea710 100644 > > --- a/arch/powerpc/platforms/wsp/Kconfig > > +++ b/arch/powerpc/platforms/wsp/Kconfig > > @@ -29,7 +29,3 @@ config PPC_CHROMA > > default y > > > > endmenu > > - > > -config PPC_A2_DD2 > > - bool "Support for DD2 based A2/WSP systems" > > - depends on PPC_A2 > > This part was not included in the "powerpc: remove PReP" follow up > patch. Should I resend separately? Yes thanks. It was added in commit a1d0d98 "Add WSP platform" but should not have been, it was to support bringup hacks that were never merged upstream. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3] powerpc/mpic: add global timer support
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, March 28, 2013 1:12 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
> Li Yang-R58472
> Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
>
> On 03/26/2013 10:23:38 PM, Wang Dongsheng-B40534 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, March 27, 2013 1:32 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Gala Kumar-B11780;
> > linuxppc-dev@lists.ozlabs.org;
> > > Li Yang-R58472
> > > Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
> > >
> > > On 03/25/2013 10:29:58 PM, Wang Dongsheng-B40534 wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Saturday, March 23, 2013 6:30 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Wood Scott-B07421; Gala Kumar-B11780;
> > > > linuxppc-dev@lists.ozlabs.org;
> > > > > Li Yang-R58472
> > > > > Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer support
> > > > >
> > > > > On 03/22/2013 01:14:51 AM, Wang Dongsheng-B40534 wrote:
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Thursday, March 21, 2013 7:00 AM
> > > > > > > To: Wang Dongsheng-B40534
> > > > > > > Cc: Wood Scott-B07421; Gala Kumar-B11780;
> > > > > > linuxppc-dev@lists.ozlabs.org;
> > > > > > > Li Yang-R58472
> > > > > > > Subject: Re: [PATCH 2/3] powerpc/mpic: add global timer
> > support
> > > > > > >
> > > > > > > BTW, the input clock frequency has been similarly scaled,
> > yet
> > > > you
> > > > > > don't
> > > > > > > try to scrounge up that information to get further
> > precision...
> > > > > > >
> > > > > > Let's go back patch, do you think the code is repeated?
> > > > > > I will remove "if (!(priv->flags & FSL_GLOBAL_TIMER))" branch,
> > > > there
> > > > > > will be no redundant code.
> > > > >
> > > > > I'd rather that branch be kept and the more complicated branch
> > > > deleted,
> > > > > and priv->timerfreq frequency be adjusted on initialization to
> > > > account
> > > > > for the scaler.
> > > >
> > > > static void convert_ticks_to_time(struct timer_group_priv *priv,
> > > > const u64 ticks, struct timeval *time) {
> > > > u64 tmp_sec;
> > > >
> > > > time->tv_sec = (__kernel_time_t)div_u64(ticks,
> > > > priv->timerfreq);
> > > > tmp_sec = (u64)time->tv_sec * (u64)priv->timerfreq;
> > > >
> > > > time->tv_usec = (__kernel_suseconds_t)
> > > > div_u64((ticks - tmp_sec) * 100,
> > priv->timerfreq);
> > > >
> > > > return;
> > > > }
> > > >
> > > > timer_group_get_freq() {
> > > > ...
> > > > if (priv->flags & FSL_GLOBAL_TIMER) {
> > > > div = (1 << (MPIC_TIMER_TCR_CLKDIV_64 >> 8)) * 8;
> > > > priv->timerfreq /= div;
> > > > }
> > > > ...
> > > > }
> > > > Do you want to do that?
> > >
> > > if (priv->flags & FSL_GLOBAL_TIMER)
> > > priv->timerfreq /= 64;
> > >
> > > ...but otherwise yes.
> > Ok, I would like do this.
> >
> > if (priv->flags & FSL_GLOBAL_TIMER) {
> > div = (1 << (MPIC_TIMER_TCR_CLKDIV_64 >> 8)) * 8;
> > priv->timerfreq /= div;
>
> Why? What do you get out of that obfuscation?
>
Change MPIC_TIMER_TCR_CLKDIV_64 to MPIC_TIMER_TCR_CLKDIV
/* Clock Ratio
* Divide by 64 0x0300
* Divide by 32 0x0200
* Divide by 16 0x0100
* Divide by 8 0x (Hardware default div)
*/
#define MPIC_TIMER_TCR_CLKDIV 0x0300
timer_group_init() {
...
/* Init FSL timer hardware */
if (priv->flags & FSL_GLOBAL_TIMER)
setbits32(priv->group_tcr, MPIC_TIMER_TCR_CLKDIV);
...
}
mpic_timer_resume() {
...
/* Init FSL timer hardware */
if (priv->flags & FSL_GLOBAL_TIMER)
setbits32(priv->group_tcr, MPIC_TIMER_TCR_CLKDIV);
...
}
Because macro is friendly, and other functions also used the macro.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] cpufreq: Add cpufreq driver for Freescale e500mc SOCs
> > + return ret;
> > +
> > + pr_info("Freescale PowerPC corenet CPU frequency scaling driver\n");
> > +
> > + return ret;
> > +}
> > +
> > +static void __exit ppc_corenet_cpufreq_exit(void) {
> > + cpufreq_unregister_driver(&ppc_corenet_cpufreq_driver);
> > +}
> > +
> > +module_init(ppc_corenet_cpufreq_init);
> > +module_exit(ppc_corenet_cpufreq_exit);
>
> this needs to be a module_platform_driver.
>
The compatible string is used for clock driver.
This driver can not be a platform_driver.
-Yuantian
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, March 28, 2013 4:26 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Gala Kumar-B11780; linuxppc-dev@lists.ozlabs.org;
> Zhao Chenhui-B35336; Li Yang-R58472
> Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
>
> On 03/26/2013 10:21:04 PM, Wang Dongsheng-B40534 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, March 27, 2013 1:36 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Gala Kumar-B11780;
> > linuxppc-dev@lists.ozlabs.org;
> > > Zhao Chenhui-B35336; Li Yang-R58472
> > > Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup support
> > >
> > > On 03/25/2013 10:27:24 PM, Wang Dongsheng-B40534 wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Saturday, March 23, 2013 6:11 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Wood Scott-B07421; Gala Kumar-B11780;
> > > > linuxppc-dev@lists.ozlabs.org;
> > > > > Zhao Chenhui-B35336; Li Yang-R58472
> > > > > Subject: Re: [PATCH 3/3] powerpc/fsl: add MPIC timer wakeup
> > support
> > > > >
> > > > > On 03/22/2013 12:46:24 AM, Wang Dongsheng-B40534 wrote:
> > > > > > Under what case is unsafe, please make sense.
> > > > >
> > > > > char buffer[1] = { '5' };
> > > > > write(fd, &buffer, 1);
> > > > >
> > > > > What comes after that '5' byte in the pointer you pass to
> > kstrtol?
> > > > >
> > > > The buffer is userspace. It will fall in the kernel space.
> > > > Kernel will get a free page, and copy the buffer to page.
> > > > This page has been cleared before copy to page.
> > > > The page has already have null-terminated.
> > >
> > > It doesn't allocate a whole page, it uses kmalloc (not kzalloc!).
> > Even
> > > if kzalloc were used, a larger user buffer could be the exact size
> > of the
> > > region that was allocated.
> > >
> > > See memdup_user() in mm/util.c
> > >
> > Did you miss something?
> > See fill_write_buffer() in fs/sysfs/file.c. It's used
> > get_zeroed_page()...
>
> OK, I was looking at fs/sysfs/bin.c which is something slightly different.
>
> fill_write_buffer() forces the size to be no more than "PAGE_SIZE - 1"
> so we know there's a terminator.
>
> Perhaps kernel/rtmutex-tester.c and kernel/time/clocksource.c are
> similarly confused?
>
Yes. But its depends on file->f_op.
See vfs_write in fs/read_write.c.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
