Re: [PATCH] memblock: kill "config MAX_ACTIVE_REGIONS"
On Thu, Mar 21, 2013 at 10:27:56AM +0100, Paul Bolle wrote:
> The Kconfig symbol MAX_ACTIVE_REGIONS is unused. Commit
> 0ee332c1451869963626bf9cac88f165a90990e1 ("memblock: Kill
> early_node_map[]") removed the only place were it was actually used. But
> it did not remove its Kconfig entries (for powerpc and sh).
>
> Remove those two entries (and the entry for metag, that popped up in
> v3.9-rc1).
>
> Signed-off-by: Paul Bolle
> ---
> 0) Eyeball tested again.
>
> 1) It felt silly to split this clean up patch into three patches. But if
> the maintainers involved disagree I'm happy to split and resend it.
>
Given that it's unused now it doesn't really matter how it gets applied,
it looks fine to me.
Acked-by: Paul Mundt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] irq: Add hw continuous IRQs map to virtual continuous IRQs support
On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
> Adding a function irq_create_mapping_many() which can associate
> multiple MSIs to a continous irq mapping.
>
> This is needed to enable multiple MSI support for pSeries.
>
> +int irq_create_mapping_many(struct irq_domain *domain,
> + irq_hw_number_t hwirq_base, int count)
> +{
Other than the other review comments already made, I think you can
simplify this considerably by simply doing what irq_create_strict_mappings()
does,
and relaxing the irq_base requirements.
In any event, as you are creating a new interface, I don't think you want
to carry around half of the legacy crap that irq_create_mapping() has to
deal with. We made the decision to avoid this with irq_create_strict_mappings()
intentionally, too.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND 1/1] arch Kconfig: remove references to IRQ_PER_CPU
On Mon, Feb 04, 2013 at 10:09:43AM +, James Hogan wrote:
> The IRQ_PER_CPU Kconfig symbol was removed in the following commit:
>
> Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 ("genirq: Remove
> CONFIG_IRQ_PER_CPU") merged in v2.6.39-rc1.
>
> But IRQ_PER_CPU wasn't removed from any of the architecture Kconfig
> files where it was defined or selected. It's completely unused so remove
> the remaining references.
>
> Signed-off-by: James Hogan
> Cc: Thomas Gleixner
> Cc: Mike Frysinger
> Cc: Fenghua Yu
> Cc: Ralf Baechle
> Cc: "James E.J. Bottomley"
> Cc: Helge Deller
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Paul Mundt
> Acked-by: Tony Luck
> Acked-by: Richard Kuo
Acked-by: Paul Mundt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v3.5-rc4
On Tue, Jun 26, 2012 at 10:06:27PM +0200, Geert Uytterhoeven wrote: > On Tue, Jun 26, 2012 at 9:59 PM, Geert Uytterhoeven > wrote: > > JFYI, when comparing v3.5-rc4 to v3.5-rc3[3], the summaries are: > > ??- build errors: +11/-219 > > 11 regressions: > + arch/sh/include/asm/fixmap.h: error: implicit declaration of > function 'BUG_ON' [-Werror=implicit-function-declaration]: => 133:2 > + arch/sh/include/asm/thread_info.h: error: implicit declaration of > function 'WARN_ON' [-Werror=implicit-function-declaration]: => 172:2 > + include/linux/huge_mm.h: error: implicit declaration of function > 'BUG' [-Werror=implicit-function-declaration]: => 185:2 > > shmin_defconfig, se7712_defconfig, se7721_defconfig, sh-allnoconfig > I'm unable to reproduce any of these, is there some specific compiler version or warning flag configuration I'm supposed to be using? I'm building with 4.5.1 at the moment. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build regressions/improvements in v3.5-rc3
On Sun, Jun 17, 2012 at 09:56:59PM +0200, Geert Uytterhoeven wrote: > On Sun, Jun 17, 2012 at 9:46 PM, Geert Uytterhoeven > wrote: > > JFYI, when comparing v3.5-rc3 to v3.5-rc2[3], the summaries are: > > ??- build errors: +235/-10 > > Truckloads of powerpc "Unrecognized opcode" breakage, and > That was my fault, should be fixed up by 2603efa31a. > + drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c: error: implicit > declaration of function 'pci_iomap' > [-Werror=implicit-function-declaration]: => 90:3 > + drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c: error: implicit > declaration of function 'pci_iounmap' > [-Werror=implicit-function-declaration]: => 142:2 > Not sure about this one, it should find everything alright via: linux/io.h -> asm/io.h -> asm-generic/iomap.h -> asm-generic/pci_iomap.h in the case that PCI is enabled. None of allyesconfig/modconfig enable PCI for me though, so I'm unsure of how you got in to this configuration to begin with? > xtensa > > + error: "__ashrdi3" [fs/ntfs/ntfs.ko] undefined!: => N/A > + error: "__lshrdi3" [fs/ntfs/ntfs.ko] undefined!: => N/A > > sh4/landisk_defconfig > > + error: "__ashrdi3" [fs/xfs/xfs.ko] undefined!: => N/A > + error: "__lshrdi3" [drivers/mtd/mtd.ko] undefined!: => N/A > + error: "__lshrdi3" [fs/xfs/xfs.ko] undefined!: => N/A > These seem to be the same issue on both platforms, EXPORT_SYMBOL() doesn't work from lib-y. While it's straightforward to fix, I'm not able to reproduce __lshrdi3/__ashrdi3 references in any of the above, which compiler are you using? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 07/14] SH: adapt for dma_map_ops changes
On Tue, Mar 27, 2012 at 03:42:41PM +0200, Marek Szyprowski wrote: > From: Andrzej Pietrasiewicz > > Adapt core SH architecture code for dma_map_ops changes: replace > alloc/free_coherent with generic alloc/free methods. > > Signed-off-by: Andrzej Pietrasiewicz > Acked-by: Kyungmin Park > Signed-off-by: Marek Szyprowski > Reviewed-by: Arnd Bergmann Acked-by: Paul Mundt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the powerpc tree with the arm tree
On Fri, Mar 09, 2012 at 10:51:27AM -0600, Rob Herring wrote: > On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote: > > On Fri, 2012-03-09 at 00:39 +, Russell King wrote: > >> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote: > >>> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If > >>> I remove it, then I get Kconfig warnings: > >>> > >>> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies > >>> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ) > >> > >> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ? > > > > Nope, Grant patch didn't mention a dependency. > > My opinion is that SPARSE_IRQ shouldn't be user visible option, and the > simple solution was to just make it hidden. It wasn't clear if this was > desired or not for other arches at the time. There is a mixture of > settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves > it user selectable for 64-bit. > > I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ > a hidden option. It really just needs the okay from SuperH folks. > We basically want it always-enabled for 32-bit and it doesn't matter much about 64-bit. In the future I'll probably fix up the 64-bit stuff to use it too and then we'll just leave it on all the time, but it's not such a big deal if it's not visible for enabling on 64-bit at the moment given that it's probably broken there at the moment. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PULL] ARM mach/irqs.h cleanup for 3.4
On Tue, Jan 31, 2012 at 01:46:58PM -0600, Rob Herring wrote: > Can you please pull mach/irqs.h clean-up for 3.4. I've gotten little to > no response from the affected platform maintainers. It's primarily > superh and shmobile that have any significant changes though. > Sorry about that, it's been in my backlog. The changes as they are are fine with me, I've got some pending work that switches to dynamic use off of nr_irqs that will make most of it redundant that I had hoped to have done in time, but it can be done incrementally at a later point in time, too. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/5] treewide: Convert uses of ATTRIB_NORETURN to __noreturn
On Thu, Nov 10, 2011 at 01:41:45AM -0800, Joe Perches wrote: > Use the more commonly used __noreturn instead of ATTRIB_NORETURN. > > Signed-off-by: Joe Perches > --- > arch/ia64/kernel/machine_kexec.c |2 +- > arch/m68k/amiga/config.c |2 +- > arch/mips/include/asm/ptrace.h |2 +- > arch/mips/kernel/traps.c |2 +- > arch/mn10300/include/asm/exceptions.h |2 +- > arch/powerpc/kernel/machine_kexec_32.c |2 +- > arch/powerpc/kernel/machine_kexec_64.c |2 +- > arch/s390/include/asm/processor.h |2 +- > arch/sh/kernel/process_32.c|2 +- > arch/sh/kernel/process_64.c|2 +- > arch/tile/kernel/machine_kexec.c |2 +- > include/linux/kernel.h |6 +++--- > 12 files changed, 14 insertions(+), 14 deletions(-) > For the SH bits: Signed-off-by: Paul Mundt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [v2] drivers/video: use strings to specify the Freescale DIU monitor port
On Sat, Jul 09, 2011 at 03:38:14PM -0500, Timur Tabi wrote:
> Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow
> the user to specify the port by name ("dvi", "lvds", or "dlvds"). This works
> on the kernel command line, the module command-line, and the sysfs "monitor"
> device.
>
> Note that changing the monitor port does not currently work on the P1022DS,
> because the code that talks to the PIXIS FPGA is broken.
>
> Signed-off-by: Timur Tabi
> Acked-by: Anatolij Gustschin
> ---
> arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++-
> arch/powerpc/platforms/85xx/p1022_ds.c | 47 -
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 55 +--
> arch/powerpc/sysdev/fsl_soc.h| 25 ++---
> drivers/video/fsl-diu-fb.c | 74
> +++---
> 5 files changed, 128 insertions(+), 95 deletions(-)
>
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] fsl-diu-fb: remove check for pixel clock ranges
On Thu, Jun 23, 2011 at 03:20:26PM -0500, Timur Tabi wrote: > The Freescale DIU framebuffer driver defines two constants, MIN_PIX_CLK and > MAX_PIX_CLK, that are supposed to represent the lower and upper limits of > the pixel clock. These values, however, are true only for one platform > clock rate (533MHz) and only for the MPC8610. So the actual range for > the pixel clock is chip-specific, which means the current values are almost > always wrong. The chance of an out-of-range pixel clock being used are also > remote. > > Rather than try to detect an out-of-range clock in the DIU driver, we depend > on the board-specific pixel clock function (e.g. p1022ds_set_pixel_clock) > to clamp the pixel clock to a supported value. > > Signed-off-by: Timur Tabi Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix build warning of the defconfigs
On Thu, Jun 02, 2011 at 12:29:23AM +0800, Wanlong Gao wrote: > RTC_CLASS is changed to bool. > So value 'm' is invalid. > > Signed-off-by: Wanlong Gao > arch/sh/configs/titan_defconfig|2 +- Acked-by: Paul Mundt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] hw_breakpoint: Let the user choose not to build it (and perf too)
On Tue, May 24, 2011 at 11:52:21PM +0200, Frederic Weisbecker wrote: > Mostly just a rebase against latest upstream > updates and acks from Will Deacon added In this second version. > > Please tell me if you are ok with this set. > > Thanks. > > --- > > Frederic Weisbecker (6): > hw_breakpoints: Split hardware breakpoints config > hw_breakpoints: Migrate breakpoint conditional build under new config > x86: Allow the user not to build hw_breakpoints > hw_breakpoints: Breakpoints arch ability don't need perf events > hw_breakpoints: Only force perf events if breakpoints are selected > hw_breakpoints: Drop remaining misplaced dependency on perf > The series looks good to me: Acked-by: Paul Mundt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v5] video, sm501: add OF binding to support SM501
On Thu, Mar 17, 2011 at 07:12:56AM +0100, Heiko Schocher wrote: > Paul Mundt schrieb: > > On Tue, Mar 15, 2011 at 08:26:40AM +0100, Heiko Schocher wrote: > >>> 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious > >>> style problems and is ready for submission. > >>> > >>> Documentation/powerpc/dts-bindings/sm501.txt | 34 + > >>> drivers/mfd/sm501.c |9 +- > >>> drivers/video/sm501fb.c | 42 > >>> -- > >>> 3 files changed, 81 insertions(+), 4 deletions(-) > >>> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt > >> This patchset is pending know for a while. I got Acked by from > >> > >> Samuel Ortiz for the mfd part, see here: > >> > >> http://www.spinics.net/lists/linux-fbdev/msg02550.html > >> http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html > >> > >> and for the DTS part from Benjamin Herrenschmidt: > >> > >> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html > >> > >> Are there some more issues? > >> > > Not that I remember off the top of my head, but I think they've been lost > > in my backlog. Could you re-send the current series with the appropriate > > acked-bys? If there's nothing else obvious outstanding I'll roll them in. > > Ok, I resend them (I also rebase them to current tree, ok?) > Ok, I've dug them up on l-k in the meantime and applied 1-3. 4/4 doesn't apply due to a missing dts file, but I assume you're aware of that and will take care of it separately. Let me know if I've overlooked anything, and sorry for the delay! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v5] video, sm501: add OF binding to support SM501
On Tue, Mar 15, 2011 at 08:26:40AM +0100, Heiko Schocher wrote: > > 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style > > problems and is ready for submission. > > > > Documentation/powerpc/dts-bindings/sm501.txt | 34 + > > drivers/mfd/sm501.c |9 +- > > drivers/video/sm501fb.c | 42 > > -- > > 3 files changed, 81 insertions(+), 4 deletions(-) > > create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt > > This patchset is pending know for a while. I got Acked by from > > Samuel Ortiz for the mfd part, see here: > > http://www.spinics.net/lists/linux-fbdev/msg02550.html > http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html > > and for the DTS part from Benjamin Herrenschmidt: > > http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html > > Are there some more issues? > Not that I remember off the top of my head, but I think they've been lost in my backlog. Could you re-send the current series with the appropriate acked-bys? If there's nothing else obvious outstanding I'll roll them in. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4 v4] video, sm501: add edid and commandline support
On Mon, Jan 24, 2011 at 10:57:27AM +0100, Heiko Schocher wrote:
> @@ -1884,7 +1935,6 @@ static int __devinit sm501fb_probe(struct
> platform_device *pdev)
>
> if (info->pdata == NULL) {
> dev_info(dev, "using default configuration data\n");
> - info->pdata = &sm501fb_def_pdata;
> }
>
> /* probe for the presence of each panel */
I assume this is accidental? I don't see how you're compensating for this
in any of the other patches at least, as it's orthogonal from the default
mode settings.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v4] video, sm501: add OF binding to support SM501
On Tue, Jan 25, 2011 at 08:20:31AM +0100, Heiko Schocher wrote:
> @@ -1934,7 +1943,29 @@ static int __devinit sm501fb_probe(struct
> platform_device *pdev)
> }
>
> if (info->pdata == NULL) {
> - dev_info(dev, "using default configuration data\n");
> + int found = 0;
> +#if defined(CONFIG_OF)
> + struct device_node *np = pdev->dev.parent->of_node;
> + const u8 *prop;
> + const char *cp;
> + int len;
> +
> + info->pdata = &sm501fb_def_pdata;
> + if (np) {
> + /* Get EDID */
> + cp = of_get_property(np, "mode", &len);
> + if (cp)
> + strcpy(fb_mode, cp);
> + prop = of_get_property(np, "edid", &len);
> + if (prop && len == EDID_LENGTH) {
> + info->edid_data = kmemdup(prop, EDID_LENGTH,
> + GFP_KERNEL);
> + found = 1;
> + }
> + }
> +#endif
> + if (!found)
> + dev_info(dev, "using default configuration data\n");
> }
>
> /* probe for the presence of each panel */
Starting to get a bit pedantic.. but kmemdup() tries to do a kmalloc(),
and so can fail. Your other patches handle the info->edid_data == NULL
case, in addition to the kfree(), but you're probably going to want to
chomp that found assignment incase of the allocation failing and falling
back on the default mode.
You also don't really have any need to keep the EDID block around after
probe as far as I can tell, so you should be able to rework this in to
something more like:
info->edid_data = kmemdup(..);
...
if (info->edid_data) {
fb_edid_to_monspecs(..);
kfree(info->edid_data);
fb_videomode_to_modelist(..);
}
...
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/4 v5] powerpc, video: add SM501 support for charon board.
On Tue, Jan 25, 2011 at 07:45:46AM +0100, Heiko Schocher wrote:
> @@ -197,6 +198,15 @@
> #address-cells = <1>;
> };
>
> + display@1,0 {
> + compatible = "smi,sm501";
> + reg = <1 0x 0x0080
> +1 0x03e0 0x0020>;
> + mode = "640x480-32@60";
> + interrupts = <1 1 3>;
> + little-endian;
> + };
> +
The endian designation looks good, but it still doesn't explain why you
have a remaining CONFIG_PPC_MPC52xx ifdef encapsulating the property
check in the sm501fb patch. It shouldn't be needed at all. If the
platform supports OF then the property will need to be set one way or the
other, so there is no need for any board or CPU ifdeffery within the
driver itself.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4 v4] video, sm501: add OF binding to support SM501
On Mon, Jan 24, 2011 at 10:57:38AM +0100, Heiko Schocher wrote: > - changes since v1: > add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from > Paul Mundt. > - changes since v2: > add comments from Randy Dunlap: > - move parameter documentation to Documentation/fb/sm501.txt > - changes since v3: > - rebased against v2.6.38-rc2 > - split in 3 patches > - of support patch > - get rid of "#if defined(CONFIG_PPC_MPC52xx)" usage > hide this in DTS, as Paul suggested. > - i/o routine patch > - edid support patch > [snip] > diff --git a/drivers/video/sm501fb.c b/drivers/video/sm501fb.c > index 30b53ae..2ae57aa 100644 > --- a/drivers/video/sm501fb.c > +++ b/drivers/video/sm501fb.c > @@ -1729,6 +1729,15 @@ static int sm501fb_init_fb(struct fb_info *fb, > FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT | > FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN; > > +#if defined(CONFIG_PPC_MPC52xx) > +#ifdef __BIG_ENDIAN > + if (of_get_property(info->dev->parent->of_node, "little-endian", NULL)) > + fb->flags |= FBINFO_FOREIGN_ENDIAN; > +#else > + if (of_get_property(info->dev->parent->of_node, "big-endian", NULL)) > + fb->flags |= FBINFO_FOREIGN_ENDIAN; > +#endif > +#endif > /* fixed data */ > > fb->fix.type= FB_TYPE_PACKED_PIXELS; Missed one? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501
On Sat, Dec 11, 2010 at 07:31:15AM +0100, Heiko Schocher wrote:
> - add binding to OF, compatible name "smi,sm501"
>
> - add read/write functions for using this driver
> also on powerpc plattforms
>
> - add commandline options:
> sm501.fb_mode:
> Specify resolution as "x[-][@]"
> sm501.bpp:
> Specify bit-per-pixel if not specified mode
>
> - Add support for encoding display mode information
> in the device tree using verbatim EDID block.
>
> If the "edid" entry in the "smi,sm501" node is present,
> the driver will build mode database using EDID data
> and allow setting the display modes from this database.
>
> Signed-off-by: Heiko Schocher
> cc: linux-fb...@vger.kernel.org
> cc: devicetree-disc...@ozlabs.org
> cc: Ben Dooks
> cc: Vincent Sanders
> cc: Samuel Ortiz
> cc: linux-ker...@vger.kernel.org
>
> ---
> - changes since v1:
> add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
> Paul Mundt.
>
> Documentation/kernel-parameters.txt |7 +
> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> drivers/mfd/sm501.c | 141 --
> drivers/video/sm501fb.c | 264
> +-
> include/linux/sm501.h|8 +
> 5 files changed, 299 insertions(+), 151 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
So has this stalled out? If Samuel wants to ack the MFD bits I don't mind
taking it through the fbdev tree. I can dust off an SM501 board to make
sure it still works for the non-OF case, although most of the changes
look fairly mechanical, so I don't forsee too much difficulty.
A few minor notes however. For starters, it would be nice to see this
patch split out a bit more logically. All of the items in your changelog
are more or less independent logical changes, and should really be
independent patches. As such, I'd like to see the EDID support as one
patch, the OF binding support layered on top of that, the documentation
split out as a trivial patch, and the I/O routine thing dealt with
separately. This should also make it easier for Samuel to simply ack the
OF bindings part that touch the MFD driver without having to be bothered
with any of the other stuff should regressions pop up at a later point in
time via a bisection.
As far as the DTS bindings documentation goes, I'm not sure what the best
way to split that out is. Perhaps simply lumping it in with the OF
bindings makes the most logical sense, and it's obviously a dependency
for the architecture-specific portion as well.
> @@ -1698,6 +1727,9 @@ static int sm501fb_init_fb(struct fb_info *fb,
> fb->fbops = &par->ops;
> fb->flags = FBINFO_FLAG_DEFAULT | FBINFO_READS_FAST |
> FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
> +#if defined(CONFIG_PPC_MPC52xx)
> + FBINFO_FOREIGN_ENDIAN |
> +#endif
> FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN;
>
> /* fixed data */
This is now getting in to deep hack territory. It's also not entirely
obvious how you expect things like the imageblit op to work given that
you're not selecting any of FB_{BIG,LITTLE,BOTH,FOREIGN}_ENDIAN, which
leads me to suspect you are manually doing this in your .config in a
relatively fragile way.
In the OF case I suppose you probably want something like:
#ifdef __BIG_ENDIAN
if (of_get_property(dp, "little-endian", NULL))
foreign_endian = FBINFO_FOREIGN_ENDIAN;
#else
if (of_get_property(dp, "big-endian", NULL))
foreign_endian = FBINFO_FOREIGN_ENDIAN;
#endif
and then simply hide the details in the DTS file in order to get rid of
CPU-specific hacks.
> +#if defined(CONFIG_PPC_MPC52xx)
> +#define smc501_readl(addr) __do_readl_be((addr))
> +#define smc501_writel(val, addr) __do_writel_be((val), (addr))
> +#else
> +#define smc501_readl(addr) readl(addr)
> +#define smc501_writel(val, addr) writel(val, addr)
> +#endif
Based on the Kconfig option for endianness you could probably just wrap these
to ioread/write32{,be} and hide the semantics in your iomap implementation?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] video, sm501: add OF binding to support SM501
On Sat, Dec 04, 2010 at 09:23:47AM +0100, Heiko Schocher wrote: > - add binding to OF, compatible name "smi,sm501" > > - add read/write functions for using this driver > also on powerpc plattforms > > - add commandline options: > sm501.fb_mode: > Specify resolution as "x[-][@]" > sm501.bpp: > Specify bit-per-pixel if not specified mode > > - Add support for encoding display mode information > in the device tree using verbatim EDID block. > > If the "edid" entry in the "smi,sm501" node is present, > the driver will build mode database using EDID data > and allow setting the display modes from this database. > > Signed-off-by: Heiko Schocher > cc: linux-fb...@vger.kernel.org > cc: devicetree-disc...@ozlabs.org > --- > based against 2.6.37-rc4 > > ./scripts/checkpatch.pl > 0003-video-sm501-add-OF-binding-to-support-SM501.patch lems and is ready for > total: 0 errors, 0 warnings, 1067 lines checked > > 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style > problems and is ready for submission. > > Documentation/kernel-parameters.txt |7 + > Documentation/powerpc/dts-bindings/sm501.txt | 30 +++ > drivers/mfd/sm501.c | 141 -- > drivers/video/sm501fb.c | 264 > +- > include/linux/sm501.h|8 + > 5 files changed, 299 insertions(+), 151 deletions(-) > create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt > Given that this is all SM501 dependent, is there some particular reason why you neglected to Cc the author or the MFD folks? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] media/IR: Add missing include file to rc-map.c
On Tue, May 11, 2010 at 08:42:14PM +0200, Peter H?we wrote: > Am Mittwoch 05 Mai 2010 17:20:21 schrieb Peter H?we: > > From: Peter Huewe > > > > This patch adds a missing include linux/delay.h to prevent > > build failures[1-5] > > > > Signed-off-by: Peter Huewe > > --- > Any updates on this patch? > Issue still exists with today's linux-next tree > You might want to send this to the linux-next list at least. If the people who introduced the breakage are unresponsive (as often tends to be the case with -next) it's still worth getting trivial fixes rolled in for the interim. This change doesn't exist outside of -next and whatever tree introduced it, so there's not much else anyone can do about it at present. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: A better way to sequence driver initialization?
On Sat, Apr 10, 2010 at 08:33:53PM -0500, Bill Gatliff wrote: > Grant Likely wrote: > > On Sat, Apr 10, 2010 at 5:39 PM, Paul Mundt wrote: > > > >> In cases where you can specifically note that dependencies, doing so will > >> save you a world of pain. Despite that, it's simply not possible to do > >> this as a free-for-all. Devices or busses that can tolerate multi-threaded > >> probing need to be converted over one at a time, but even then you still > >> need the dependency tracking for those that depend on link order today. > >> > > Who's to say a function like gpio_request_wait_for_it(GPIO_NUMBER, > "dependent-driver") isn't the way to do the dependency tracking? I > can't even implement that without a context that can sleep... > In some cases that might be valid, but there are many cases where drivers can reconfigure their capability sets based on which GPIOs are and aren't available. Just because a pin isn't available doesn't make it a show-stopper for the probe path.. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: A better way to sequence driver initialization?
On Sat, Apr 10, 2010 at 08:35:41AM -0500, Bill Gatliff wrote:
> Benjamin Herrenschmidt wrote:
> > On Fri, 2010-04-09 at 14:23 -0500, Bill Gatliff wrote:
> >
> >> My recent post, "Requesting a GPIO that hasn't been registered yet", and
> >> Anton's reply thereto (thanks, Anton!) on linuxppc-dev got me thinking
> >> about the problem of dependencies between devices in different classes,
> >> and/or between drivers/devices in general. I'd like to float an idea to
> >> see if it's worth pursuing.
> >>
> >
> > I'd rather do things a bit more explicitely and less prone to break
> > existing stuff... something along the lines of, first defining a variant
> > of the initcalls to enable that "multithreaded" stuff, along with an
> > explicit wait_for_service("subsys:hid"); for example.
> >
> > One could also expose service deps via the module info, thus delaying
> > module init, or things like that (in fact, initcalls could even come
> > with a list of dependencies).
> >
>
> The general problem with your approach is that the module in question
> might not know what services it needs to wait for.
>
> Specific to my situation, the gpio-led code doesn't have any way of
> knowing that it needs to wait until my pca953x i2c devices have all been
> installed so that the gpio pin I have specified even exists. And short
> of setting up some kind of table in the board-specific code (or device
> tree, actually), I don't know how to communicate such a dependency
> without touching the generic gpio-led code--- which I'm trying to avoid.
>
This is a common problem for drivers that are all stuck on the same
initcall level and as a result are entirely dependent on link order. Some
more intelligent logic via the bus notifiers would help with some of
this, but it wouldn't help with drivers that are effectively unable to
probe for devices and that are entirely dependent on registration timing
to make sure that their backing device has become available.
You could also look at doing multi-threaded probing at the bus level
where the semantics and implications are better understood, but that
still doesn't necessarily help with ordering. (ie, registering a GPIO
expander on a PCI MFD before being able to bring up gpio-leds or
so). There has been past work for both multi-threading the probe routines
as well as constraining it and only doing it for things like PCI.
In cases where you can specifically note that dependencies, doing so will
save you a world of pain. Despite that, it's simply not possible to do
this as a free-for-all. Devices or busses that can tolerate multi-threaded
probing need to be converted over one at a time, but even then you still
need the dependency tracking for those that depend on link order today.
Vendors often end up doing this sort of work for device-specific kernels
where the underlying set of drivers is fixed, so there are also some
alternative approaches you can investigate there (OLPC comes to mind).
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] panic: Allow warnings to set different taint flags
On Sat, Apr 03, 2010 at 07:34:56PM +0100, Ben Hutchings wrote: > WARN() is used in some places to report firmware or hardware bugs that > are then worked-around. These bugs do not affect the stability of the > kernel and should not set the flag for TAINT_WARN. To allow for this, > add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint number > as argument. > > Architectures that implement warnings using trap instructions instead > of calls to warn_slowpath_*() now implement __WARN_TAINT(taint) > instead of __WARN(). > > Signed-off-by: Ben Hutchings > --- > Changes since the previous version: > - Added note to Documentation/oops-tracing.txt > - Changed the commit message to distinguish taint numbers from taint > flags > - Removed 'must' from last sentence of commit message; this patch > converts all mainline architectures > This seems to be missing my Tested-by from the last iteration, since there are no functional changes with this version feel free to add it in again. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] panic: Allow taint flag for warnings to be changed from TAINT_WARN
On Sat, Mar 20, 2010 at 11:05:40PM +, Ben Hutchings wrote: > WARN() is used in some places to report firmware or hardware bugs that > are then worked-around. These bugs do not affect the stability of the > kernel and should not set the usual TAINT_WARN flag. To allow for > this, add WARN_TAINT() and WARN_TAINT_ONCE() macros that take a taint > flag as argument. > > Architectures that implement warnings using trap instructions instead > of calls to warn_slowpath_*() must now implement __WARN_TAINT(taint) > instead of __WARN(). > > Signed-off-by: Ben Hutchings > --- > The architecture-specific changes here are untested and need to be > reviewed by architecture maintainers. > I'm a bit confused about how this is supposed to work, the TAINT_xxx values are bit positions presently from 0 to 10, while BUGFLAG_xxx are ranged from 0 up. You've set up BUGFLAG_TAINT() to that the TAINT_xxx value is shifted up 8 bits but neglected the fact that the trap type is 16-bits on most (all?) of the platforms using trap-based BUG handling. If the 'taint' in question is just the TAINT_xxx value by itself and will never be a bitmap then that's fine, but there's certainly not enough room to pass the bitmap in on top of the bugflag otherwise (I don't know if this is your intention or not though). Also note that some platforms (like SH) implement additional bugflags, so we at least want to keep the lower byte available for architecture private use. Having said that, the current patch does work for me, although I'm a bit nervous about someone thinking it's ok to pass in a taint bitmap here. Tested-by: Paul Mundt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/10] irq: move some interrupt arch_* functions into struct irq_chip.
On Sun, Mar 21, 2010 at 08:32:33PM -0700, Yinghai Lu wrote:
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 64f6f20..cafd378 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -1088,7 +1088,7 @@ int arch_early_irq_init(void)
> return 0;
> }
>
> -int arch_init_chip_data(struct irq_desc *desc, int node)
> +int arch_init_irq_desc(struct irq_desc *desc, int node, init_chip_data_fn fn)
> {
> desc->status |= IRQ_NOREQUEST;
> return 0;
>
> so this patch only change one line with powerpc code.
This API seems to be going from bad to worse. Initially we had
arch_init_chip_data(), which had precisely nothing to do with chip_data
and only concerned itself with irq_desc, and now you're renaming it to
something sensible but also trying to bolt on some ad-hoc chip_data
relation at the same time thereby nullifying any benefit obtained from
renaming the function in the first place.
Renaming to xxx_irq_desc() while preserving the existing prototypes would
make sense, even if it's ultimately just unecessary churn.
> > It looks to me like this should just be done via a current machine
> > vector or platform routine, in the same way as powerpc and (I think)
> > ia64, ie:
> >
> >> +int arch_init_irq_desc(struct irq_desc *desc, int node)
> >> +{
> >> + return current_machine->init_chip_data(desc, node);
> >> +}
> >
> looks like xen in same run time, some irqs need x86_init_chip_data,
> and some may need xen_init_chip_data later.
>
I'm afraid I am unable to grasp the meaning of this sentence, or what
precisely this has to do with not being able to utilize platform ops to
get this sorted out on x86.
You're effectively trying to have the hardirq code pass around a function
pointer for you that ultimately only serves to bail out on certain code
paths if you're running under xen, which is a concern for how the
platform chooses to initialize the irq desc, none of this has any value
or relevance to the hardirq code outside of that. The fact that the
hardirq code doesn't do anything with this information other than pass it
around for your platform should already be a clear indicator that this is
the wrong way to go.
>From a cursory look at the x86 code, this looks like precisely the sort
of thing that arch/x86/include/asm/x86_init.h is well suited for, and
indeed you already have a x86_init_irqs to expand on as needed.
The function pointer thing itself is also a bit unorthodox to say the
least. You're introducing and passing around an opaque type just so you
can get to a 'return 0' in the xen case as far as I can tell, so you
could also just make arch_init_chip_data() a weak symbol and clobber it
in the xen case, no?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC/PATCH] mm: Pass virtual address to [__]p{te, ud, md}_free_tlb()
On Tue, Jul 28, 2009 at 10:17:40AM +1000, Benjamin Herrenschmidt wrote: > On Mon, 2009-07-27 at 12:11 -0700, Linus Torvalds wrote: > > On Thu, 23 Jul 2009, Benjamin Herrenschmidt wrote: > > > > > > Hrm... my powerpc-next branch will contain stuff that depend on it, so > > > I'll probably have to pull it in though, unless I tell all my > > > sub-maintainers to also pull from that other branch first :-) > > > > Ok, I'll just apply the patch. It does look obvious enough. > > There seem to be a MIPS and SH breakage as a result but I can't see > how my patch would have broken it, ie, it looks like the bug was > already in those two archs. The error is that it complains about a > duplicate definition of __pmd_free_tlb() between those arch pgalloc.h > and pgtable-nopmd.h > > For MIPS, when CONFIG_32BIT is set, asm/pgalloc.h redefines > __pmd_free_tlb despite the fact that it's already defined by > asm-generic/pgtable-nopmd.h (via via pgtable.h via linux/mm.h). > > I -suspect- what happens is that the compiler, before, would ignore the > double definition (or maybe just warn) due to the definition being > strictly identical. With the new argument added, it's no longer the case > as it's called "a" in asm-generic and "addr" in mips... oops. > > In any case, can Ralf and Paul check if the following patch is correct ? > Yup, that seems to be what happened. I've never seen a warning about this with any compiler version, otherwise we would have caught this much earlier. As soon as the addr -> a rename took place it blew up immediately as a redefinition. Is there a magical gcc flag we can turn on to warn on identical definitions, even if just for testing? > >From 41928c7945d855ae0eb053eadad590ab6876847e Mon Sep 17 00:00:00 2001 > From: Benjamin Herrenschmidt > Date: Tue, 28 Jul 2009 10:16:48 +1000 > Subject: [PATCH] mm: Remove duplicate definitions in MIPS and SH > > Those definitions are already provided by asm-generic > > Signed-off-by: Benjamin Herrenschmidt Builds and boots fine, thanks. Acked-by: Paul Mundt ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/7] Generic RTC class driver
On Mon, Mar 09, 2009 at 02:26:16PM +0100, Geert Uytterhoeven wrote: > Paul: Feel free to add your SuperH support. > > I suppose the easiest way for this to go in is through Kyle's PA-RISC tree, as > he already has the preceding patches? Can I have your acks, please? > I'll add the SH support once the patch set is merged, it's not a very pressing matter, so no need to make the patch juggling any more complicated :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [rtc-linux] Re: [PATCH/RFC 0/5] Generic RTC class driver
On Tue, Mar 03, 2009 at 11:41:23AM +0100, Geert Uytterhoeven wrote: > So would you accept a patch series that: > 1. Adds the missing module aliases to rtc-parisc (which is a bugfix), > 2. Moves the platform device creation out of rtc-ppc and into arch-specific > code (which is also a bugfix), > 3. Consolidates rtc-parisc and rtc-ppc into rtc-generic (which is a > cleanup), > 4. Makes rtc-generic dependent on PARISC, PPC, and M68K (the existing > [sg]et_rtc_time() users): >a. without introducing ARCH_HAS_GENERIC_RTC, >b. with a big fat warning in the Kconfig comment not relaxing the > dependencies, as it's supposed to go away. > 4. Converts the PS3 RTC support into a separate driver, called rtc-ps3 > (as a bonus ;-) > > ? If yes, I'll cook it up. > > Other RTC platform support can be converted into separate drivers later. > Did you miss the rtc-firmware thread? http://groups.google.com/group/rtc-linux/browse_thread/thread/53e8d98966048f66/1d730cb4aa2f85f0?lnk=gst&q=rtc-firmware#1d730cb4aa2f85f0 http://groups.google.com/group/rtc-linux/browse_thread/thread/b3d10115c7e147f2/cb9c1530d9c3a433?lnk=gst&q=rtc-firmware#cb9c1530d9c3a433 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq
On Tue, Dec 16, 2008 at 01:41:56PM +0100, Wolfram Sang wrote: > > In addition to the stuff pointed out by Greg, I don't see what you > > actually gain by hacking the OF crap in to this driver. You would be > > better off layering the OF driver on top of this, rather than trying to > > make them live together in the same file. > > > > See pata_platform/pata_of_platform for an example of how to do this a bit > > more sanely. > > See my reply just posted. I found two ways to go, and from reading > discussions on the lists, finally decided for this way. May have been > the wrong path, but nothing that could not be changed. > I guess there are a couple of things to consider. If it fits in fairly nicely and can be optimized out for the users that don't care, then integration generally makes sense. In this case however you have a large and insular block that is ifdef'ed in and selected by Kconfig, suggesting that the only benefit is for your driver which wishes to tie in to parts of uio_pdrv_genirq, with there being no benefits the other way. This sort of situation suggests you are better off layering and simply exposing the functionality you need from uio_pdrv_genirq. This was certainly the case with pata_platform as well, and it worked out pretty well there compared to hacking it in-place. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RESEND][PATCH] uio: Add of_platform_driver to uio_pdrv_genirq
On Thu, Dec 11, 2008 at 04:05:37PM +0100, Wolfram Sang wrote:
> Make the generic uio-driver also accessible for of devices. It utilizes the
> standard 'reg' and 'interrupt' properties. A typical usage would look like
> this:
>
> fpga...@3000 {
> compatible = "generic-uio";
> reg = <0x3000 0x20>;
> interrupts = <0xa>;
> interrupt-parent = <&fpga_irq_mux>;
> };
>
> To achieve this, the probe function has been refactored, so it can be used by
> platform and of code. Then, the of driver has been added.
>
> Signed-off-by: Wolfram Sang
It is pretty poor form to not even bother to Cc the only author of the
code you are modifying, and have no Signed-off-by or Acked-by to even
suggest that it was ever even looked at. This isn't something that ought
to have to be pointed out, either.
In addition to the stuff pointed out by Greg, I don't see what you
actually gain by hacking the OF crap in to this driver. You would be
better off layering the OF driver on top of this, rather than trying to
make them live together in the same file.
See pata_platform/pata_of_platform for an example of how to do this a bit
more sanely.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] sh: dynamic ftrace support.
On Thu, Nov 20, 2008 at 03:34:16PM -0500, Steven Rostedt wrote:
> +} elsif ($arch eq "sh") {
> +$section_regex = "Disassembly of section\\s+(\\S+):";
> +$function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
> +$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\smcount\$";
> +$type = ".long";
> +
> +# force flags for this arch
> +$ld .= " -m shlelf_linux";
> +$objcopy .= " -O elf32-sh-linux";
> +$cc .= " -m32";
> +
Note that if the $alignment changes are in this version, you will also
need to add an $alignment = 2; for sh. That was in Matt's original patch,
but I stripped the alignment line out in the commit given that it was not
yet present in the mainline version of the script.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pata_of_platform: fix no irq handling
On Wed, Oct 08, 2008 at 11:59:59AM +0200, Geert Uytterhoeven wrote: > On Wed, 8 Oct 2008, Alan Cox wrote: > > On Wed, 08 Oct 2008 09:40:54 +0100 > > David Woodhouse <[EMAIL PROTECTED]> wrote: > > > > > On Tue, 2008-10-07 at 10:37 +0100, Alan Cox wrote: > > > > Zero means no IRQ. Any platform with bits of code left over exposing IRQ > > > > 0 is already not supported by lots of driver code including libata. > > > > > > ...and must implement some kind of interrupt remapping crap just to work > > > around this bogus design decision. > > > > I'll leave you to argue with Linus about that, but since that was the > > decision back in 2005 (for good C reasons) we can safely rely on it. > > `git grep NO_IRQ include arch/*/include' is still quite enlightening... > In the case of PCI where IRQ is unsigned int, that's certainly bogus. The problem originates on platforms where a 1:1 mapping between vector and IRQ exists, where 0 is a valid value. This then needs to be remapped in to an IRQ cookie that has a non-0 value in order to be assigned to dev->irq. Despite whether this is bogus or not, there's not much to be done about it. Those of us with vectored IRQ platforms generally have enough sources that the use of IRQ-0 doesn't matter, and it's not worth the headache of setting up the remapping crap. As an example, on SH, IRQ-0 is mapped to vector 0x200. It is '0' for symbolic reasons only. It's just as easy to pad out irq_desc and treat it as an off-by-1 to work around all of code that assumes NO_IRQ == 0. There is enough code in the kernel today that makes the non-zero IRQ cookie assumption that platforms that do otherwise are simply broken. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 08:59:08AM -0500, Bill Gatliff wrote: > There isn't a lot of traffic on linux-embedded, and I'm not sure how many > people > who read linux-arm-kernel also read linuxppc-dev. Lkml's topic coverage is > huge, so I don't know how many hardcore embedded developers I would encounter > there. I was hoping for a round of feedback at a lower level before pushing > anything upstream like that. > This isn't your problem. If people are interested in general embedded topics, they should be subscribed to the list. If they aren't, it's their loss. Cross posting to every potentially relevant list is a complete waste of time, and only helps to split out the discussion so nothing actually gets accomplished in a centralized location. > Hasn't been a problem so far. I posted the first version of the code on > l-a-k, > and got some feedback on the pwm_device API and a lot of feedback on the way > users wanted to use the API to realize applications. I incorporated all of > it, > and in this "release" I broadened the exposure per recommendations received > from > l-a-k. > This is precisely the problem. Stuff that gets "reviewed" on linux-arm-kernel gets reviewed for ARM only. There has been way too much crap that has been pushed into the kernel under the guise of being generic and "reviewed" that has broken _every_ architecture _except_ ARM. If you want to refute this, go look at the recent fiasco with musb, which still hasn't been solved properly, primarily because the ARM people couldn't be bothered using grep. This crap happens all the time, because stuff is reviewed and merged in private, and the only time anyone else notices is when their platform suddenly stops building. Your first version should have been to linux-embedded and linux-kernel. If you want to alert the linux-arm-kernel people to the fact that a discussion is going on in this area, then feel free to post a notification to the list with references to the relevant lists. There is no reason why public lists should have to dig in to private archives to try and play catch up. > So, you're saying the same thing as me, basically. But leaving out the lists > with very high ratios of device-specific domain knowledge, which is important > for the backend parts of what I'm proposing. Blackfin's PWM-capable > peripherals > work differently from those commonly found in ARM and PPC, for example. I > haven't run anything by the MIPS or AVR guys, but I'm guessing they would have > something to add, too. > > I'm beginning to appreciate what everyone must have had to deal with for > GPIO. :) > The GPIO mess was broken in different ways, which we're still trying to fix today. The GPIO discussion did happen out on public lists though, so all of the discussion on that was visible, even if the end result left something to be desired. If you're trying to pitch a generic API and doing your review on a private list, you've already lost. If you're talking about things that only effect arch/arm, feel free to do whatever you want. As soon as you step outside of that structure, you have to follow common convention, or you risk breaking things all over the place. I can't remember the last time I saw a "generic" API reviewed on linux-arm-kernel that didn't end up breaking every other architecture in existence. This is true for drivers, also. Better yet, don't bother dropping the ARM depedency until you've posted to a public list. Some of us are pretty damn tired of cleaning up after the ARM people. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 09:03:34AM -0500, Bill Gatliff wrote: > Paul Mundt wrote: > > This is likely because some of those lists are subscribers only, so cross > > posting is poor form. It makes sense to keep the discussion in one place, > > and to send notification messages with a pointer to the list archives to > > the other lists so folks can jump in if they really care. Splitting it > > out doesn't help matters in the least, but unfortunately this is what > > seems to happen the most when subscribers only lists are involved. > > Alright, then maybe I can do this when I post the "final" changeset for > review: > cross-post to lkml and linux-embedded, and then post one short note on l-a-k, > linuxppc-dev and elsewhere that refers those interested to the actual content. > I can live with that. > linux-arm-kernel is the only one that is subscribers only out of that list, according to MAINTAINERS. If rmk wants to mandate a broken policy, that's perfectly fine, just don't expect the rest of the kernel community to tolerate it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/6] Proposal for a Generic PWM Device API
On Fri, Oct 10, 2008 at 11:00:09AM +0200, Geert Uytterhoeven wrote: > On Thu, 9 Oct 2008, Bill Gatliff wrote: > > Benjamin Herrenschmidt wrote: > > > On Wed, 2008-10-08 at 11:43 -0500, Bill Gatliff wrote: > > >> This series proposes a "generic PWM" driver API. > > >> > > >> This proposed API is motivated by the author's need to support > > >> pluggable devices; a secondary objective is to consolidate the > > >> existing PWM implementations behind an agreeable, consistent, > > >> redundancy-reducing interface. > > > > > > .../... > > > > > > You should send your patches to the main linux kernel list ! > > > > Perhaps. But it seemed more relevant to this crowd, and the linux-embedded > > crowd, and the linux-arm-kernel crowd. > > Were did you actually sent them to? Apparently you sent them to each mailing > list (at least linux-embedded and linuxppc-dev) _separately_ (or using bcc). > > Hence different people may give the same comments without knowing about each > other, and you may have to explain everything multiple times. > > I would go for lkml and linux-embedded, _together_. > This is likely because some of those lists are subscribers only, so cross posting is poor form. It makes sense to keep the discussion in one place, and to send notification messages with a pointer to the list archives to the other lists so folks can jump in if they really care. Splitting it out doesn't help matters in the least, but unfortunately this is what seems to happen the most when subscribers only lists are involved. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] sh: Define elfcorehdr_addr in arch dependent section
On Mon, Jul 28, 2008 at 05:15:14PM -0400, Vivek Goyal wrote: > o Move elfcorehdr_addr definition in arch dependent crash dump file. This is > equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of > CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be > used irrespective of the fact whether CONFIG_PROC_VMCORE is enabled or > not. > > o I don't see sh setup code parsing the command line for elfcorehdr_addr. I > am wondering how does vmcore interface work on sh. Anyway, I am atleast > defining elfcoredhr_addr so that compilation is not broken on sh. > Hmm, you are correct, it seems like it was either lost in a merge somewhere or I simply neglected to check it in it when I was testing this stuff initially. Thanks for noticing! > Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> Acked-by: Paul Mundt <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 59/60] microblaze_v4: syscall_table.S and unistd.h
On Thu, Jun 26, 2008 at 02:30:28PM +0200, [EMAIL PROTECTED] wrote: > +#define __NR_semtimedop 325 > +#define __NR_timerfd_settime 326 > +#define __NR_timerfd_gettime 327 > + > +#ifdef __KERNEL__ > + > +#define __NR_syscalls327 > + Off-by-1 on __NR_syscalls, this should be 328. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 30/60] microblaze_v4: support for a.out
On Thu, Jun 26, 2008 at 02:29:59PM +0200, [EMAIL PROTECTED] wrote: > From: Michal Simek <[EMAIL PROTECTED]> > > > Signed-off-by: Michal Simek <[EMAIL PROTECTED]> > --- > 0 files changed, 0 insertions(+), 0 deletions(-) > create mode 100644 include/asm-microblaze/a.out.h > a.out is going away for the users that don't care, so you may wish to make sure all of your a.out references are also gone so you don't have to patch this a second time. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 29/60] microblaze_v4: traps support
On Thu, Jun 26, 2008 at 02:29:58PM +0200, [EMAIL PROTECTED] wrote:
> +static int kstack_depth_to_print = 24;
> +
x86 has a sysctl for this. It may be worth making this non-static and
generalizing the ifdef case. Plenty of other architectures could benefit
from this also.
> +void show_trace(struct task_struct *task, unsigned long *stack)
> +{
> + unsigned long addr;
> +
> + if (!stack)
> + stack = (unsigned long *)&stack;
> +
> + printk(KERN_INFO "Call Trace: ");
> +#ifdef CONFIG_KALLSYMS
> + printk(KERN_INFO "\n");
> +#endif
> + while (!kstack_end(stack)) {
> + addr = *stack++;
> + if (__kernel_text_address(addr)) {
> + printk(KERN_INFO "[<%08lx>] ", addr);
> + print_symbol("%s\n", addr);
Use print_ip_sym() here for future-proofing.
> + }
> + }
> + printk(KERN_INFO "\n");
And here you can:
if (!tsk)
tsk = current;
debug_show_held_locks(tsk);
> +}
> +
for when you get around to implementing lockdep.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 28/60] microblaze_v4: ptrace support
On Thu, Jun 26, 2008 at 02:29:57PM +0200, [EMAIL PROTECTED] wrote:
> +long arch_ptrace(struct task_struct *child, long request, long addr, long
> data)
> +{
> + int rval;
> +
> + switch (request) {
> + unsigned long val, copied;
> +
> + case PTRACE_PEEKTEXT: /* read word at location addr. */
> + case PTRACE_PEEKDATA:
> + pr_debug("PEEKTEXT/PEEKDATA at %08lX\n", addr);
> + copied = access_process_vm(child, addr, &val, sizeof(val), 0);
> + rval = -EIO;
> + if (copied != sizeof(val))
> + break;
> + rval = put_user(val, (unsigned long *)data);
> + goto out;
> +
> + case PTRACE_POKETEXT: /* write the word at location addr. */
> + case PTRACE_POKEDATA:
> + pr_debug("POKETEXT/POKEDATA to %08lX\n", addr);
> + rval = 0;
> + if (access_process_vm(child, addr, &data, sizeof(data), 1)
> + == sizeof(data))
> + break;
> + rval = -EIO;
> + goto out;
> +
You can use generic_ptrace_peekdata()/generic_ptrace_pokedata() for
these. Or kill them off and let ptrace_request() handle it.
> + /* Continue and stop at next (return from) syscall */
> + case PTRACE_SYSCALL:
> + pr_debug("PTRACE_SYSCALL\n");
> + case PTRACE_SINGLESTEP:
> + pr_debug("PTRACE_SINGLESTEP\n");
> + /* Restart after a signal. */
> + case PTRACE_CONT:
> + pr_debug("PTRACE_CONT\n");
> + rval = -EIO;
> + if (!valid_signal(data))
> + break;
> +
> + if (request == PTRACE_SYSCALL)
> + set_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
> + else
> + clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
> +
> + child->exit_code = data;
> + pr_debug("wakeup_process\n");
> + wake_up_process(child);
> + rval = 0;
> + break;
> +
This is a reimplementation of ptrace_resume(), you can kill all of these
off as well, as they are also handled generically these days.
> + /*
> + * make the child exit. Best I can do is send it a sigkill.
> + * perhaps it should be put in the status that it wants to
> + * exit.
> + */
> + case PTRACE_KILL:
> + pr_debug("PTRACE_KILL\n");
> + rval = 0;
> + if (child->exit_state == EXIT_ZOMBIE) /* already dead */
> + break;
> + child->exit_code = SIGKILL;
> + wake_up_process(child);
> + break;
> +
> + case PTRACE_DETACH: /* detach a process that was attached. */
> + pr_debug("PTRACE_DETACH\n");
> + rval = ptrace_detach(child, data);
> + break;
> +
> + default:
> + rval = -EIO;
> + goto out;
> + }
> + out:
> + return rval;
> +}
> +
Or rather, they would be, if you defaulted to ptrace_request() for the
unhandled cases.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 25/60] microblaze_v4: process and init task function
On Thu, Jun 26, 2008 at 02:29:54PM +0200, [EMAIL PROTECTED] wrote:
> +void (*pm_power_off)(void) = NULL;
> +EXPORT_SYMBOL(pm_power_off);
> +
> +void cpu_idle(void)
> +{
> + set_thread_flag(TIF_POLLING_NRFLAG);
> +
> + while (1) {
> + while (!need_resched())
> + cpu_relax();
> +
> + preempt_enable_no_resched();
> + schedule();
> + preempt_disable();
> + }
> +}
> +
A couple things to note here. You have a pm_power_off, but no pm_idle.
You set TIF_POLLING_NRFLAG but don't have any explicit clearing and
resetting of it if the CPU is sleeping. In the cpu_relax() case this is
ok, but if you have a cpu_sleep() you will want to use in the SMP case,
you will need to handle it explicitly.
Beyond that, you may also want to stub in the
tick_nohz_stop_sched_tick()/tick_nohz_restart_sched_tick() calls, then
when you implement the generic clockevents you will already have the
tickless bits in place.
check_pgt_cache() is also helpful here for quicklist trimming, though you
may not care if you never plan to have an MMU.
You can look at arch/sh/kernel/process_32.c for examples.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 24/60] microblaze_v4: asm-offsets
On Thu, Jun 26, 2008 at 02:29:53PM +0200, [EMAIL PROTECTED] wrote:
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DEFINE(sym, val) asm volatile("\n->" #sym " %0 " #val : : "i" (val))
> +#define BLANK() asm volatile("\n->" : :)
> +
There are generic definitions for these these days, include linux/kbuild.h.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/60] microblaze_v4: Kconfig patches
On Thu, Jun 26, 2008 at 02:29:30PM +0200, [EMAIL PROTECTED] wrote: > +config HZ > + int > + default 100 > + Consider using kernel/Kconfig.hz instead. > +config DEFCONFIG_LIST > + string > + default "arch/$ARCH/defconfig" > + init/Kconfig already has quite a few reasonable defaults for this, including the case you specify. You can kill this off. > +source "init/Kconfig" > + > +source "arch/microblaze/platform/Kconfig.platform" > + > +menu "Processor type and features" > + > +config PREEMPT > + bool "Preemptible Kernel" > + help > + This option reduces the latency of the kernel when reacting to > + real-time or interactive events by allowing a low priority process to > + be preempted even if it is in kernel mode executing a system call. > + This allows applications to run more reliably even when the system is > + under load. > + > + Say Y here if you are building a kernel for a desktop, embedded > + or real-time system. Say N if you are unsure. > + kernel/Kconfig.preempt > +config LARGE_ALLOCS > + bool "Allow allocating large blocks (> 1MB) of memory" > + help > + Allow the slab memory allocator to keep chains for very large > + memory sizes - up to 32MB. You may need this if your system has > + a lot of RAM, and you need to able to allocate very large > + contiguous chunks. If unsure, say N. > + Legacy bits, not used anywhere anymore. > +comment "Boot options" > + > +config CMDLINE > + string "Default kernel command string" > + default "" > + help > + On some architectures there is currently no way for the boot loader > + to pass arguments to the kernel. For these architectures, you should > + supply some command-line options at build time by entering them > + here. > + > +config CMDLINE_FORCE > + bool "Force default kernel command string" > + help > + Set this to have arguments from the default kernel command string > + override those passed by the boot loader. > + Consider CMDLINE_BOOL/CMDLINE for consistency with other architectures. It doesn't make much sense to expose CMDLINE if you don't intend to use it. Especially when people wonder why their CMDLINE changes are being clobbered by the boot loader. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] asm/ptrace.h userspace headers cleanup
On Mon, Jun 23, 2008 at 08:48:09PM +0300, Adrian Bunk wrote: > This patch contains the following cleanups for the asm/ptrace.h > userspace headers: > - include/asm-generic/Kbuild.asm already lists ptrace.h, remove > the superfluous listings in the Kbuild files of the following > architectures: > - cris > - frv > - powerpc > - x86 > - don't expose function prototypes and macros to userspace: > - arm > - blackfin > - cris > - mn10300 > - parisc > - remove #ifdef CONFIG_'s around #define's: > - blackfin > - m68knommu > - sh: AFAIK __SH5__ should work in both kernel and userspace, > no need to leak CONFIG_SUPERH64 to userspace Yes, that's fine. We've generally avoided relying entirely on the gcc builtin definitions due to the rampant stupidity surrounding __SH4_NOFPU__, but it is true that __SH5__ is always defined at least. Acked-by: Paul Mundt <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
On Fri, Dec 14, 2007 at 09:24:29PM +0300, Anton Vorontsov wrote:
> Split pata_platform_{probe,remove} into two pieces:
> 1. pata_platform_{probe,remove} -- platform_device-dependant bits;
> 2. __ptata_platform_{probe,remove} -- device type neutral bits.
>
> This is done to not duplicate code for the OF-platform driver.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> Acked-by: Olof Johansson <[EMAIL PROTECTED]>
Looks fine to me now, thanks for cleaning it up Anton.
Acked-by: Paul Mundt <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 4/4] [libata] pata_platform: s/ioport_shift/reg_shift/g
On Tue, Dec 04, 2007 at 08:07:45PM +0300, Anton Vorontsov wrote: > This patch renames ioport_shift member of pata_platform_info > structure to reg_shift. Users of pata_platform are followed > appropriately. > > Rationale of that change is: shifting applies to the whole memory > mapped region, not only to the command block of the ATA registers, > despite the fact that shifting is meaningless for ctl register. > It's called ioport_shift because of the fact it shifts an ioport, namely a struct ata_ioport *. We could rename it, but I really don't see the point. If you don't like the choice of name on your platform, add a comment to your platform-specific code noting this particular outrage so it can be grepped for by future generations ;-) Nacked-by: Paul Mundt <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 2/4] [libata] pata_of_platform: OF-Platform PATA device driver
On Tue, Dec 04, 2007 at 02:01:21PM -0600, Olof Johansson wrote: > On Tue, Dec 04, 2007 at 10:49:21PM +0300, Anton Vorontsov wrote: > > tristate "Generic platform device PATA support" > > - depends on EMBEDDED || ARCH_RPC > > + depends on EMBEDDED || ARCH_PPC > > It needs to be || PPC, not || ARCH_PPC. > Wrong. It needs to be EMBEDDED || ARCH_RPC || PPC. ARCH_RPC is not a typo, it's an ARM platform. Please grep first :-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] OF-platform PATA driver
On Tue, Nov 27, 2007 at 06:37:08PM +0300, Anton Vorontsov wrote: > Here is the second spin of the OF-platform PATA driver and > related patches. > So either the patches are missing, or I wasn't CC'ed on them. I'm going to go out on a limb and assume the latter. If you wish me to Ack them, I'm not going to start grovelling around list archives trying to find the relevant posts. This is now the second time this has happened, the first time I was only made aware of this work as Jeff forwarded them along. CC'ing the authors of code you are changing shouldn't be a cryptic requirement we have to spell out in SubmittingPatches or so, especially if you're soliciting Acked-bys. Please fix your development methodology, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/3] OF-platform PATA driver
On Mon, Nov 26, 2007 at 03:23:14AM +0300, Anton Vorontsov wrote: > On Sat, Nov 24, 2007 at 04:26:13PM +0900, Paul Mundt wrote: > > On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote: > > > Anton Vorontsov wrote: > > > >Here is the PATA Platform driver using OF infrastructure. > > > > > > > >Mostly it's just a wrapper around a bit modified pata_platform > > > >driver. > > > > > > > >Patches are well split for the easier review: > > > > > > > >First one factors out platform_device specific bits and modifies > > > >pata_platform to be a library-alike driver (with platform_device > > > >default binding). > > > > > > The only issue I have here is that this library-like version has subtle > > semantic changes that will break existing drivers. > > Actually I've tried to keep semantics intact: > > +static int __devinit pata_platform_probe(struct platform_device *pdev) > [...] > + /* > +* And the IRQ > +*/ > + irq_res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); > + if (irq_res) > + irq_res->flags = pp_info ? pp_info->irq_flags : 0; > [...] > > So, I'm passing flags from the platform data. Did you overlook these > bits, or I'm still changing semantics somewhere else? > Oh, I overlooked that. Using irq_res->flags as a temporary for pp_info->irq_flags seems a bit hacky, but as long as pp_info->irq_flags semantics are intact, I'm not too violently opposed to this anyways. > > Incidentally, we already have an include/linux/pata_platform.h. If this > > is going to be library-like, through the prototypes in there, rather than > > splitting them up betewen include/linux and drivers/ata. We don't need > > two headers. > > My intention was: keep "private" declarations in the drivers/ata/ and > "public" in the include/linux/ -- to not confuse pata_platform users > by __pata_platform_* internal stuff. But okay, I'll merge them. > I suppose that depends on whether the intent is that all pata_platform users will be stuck in drivers/ata or not. If this is treated as more of a library, implementations can simply bury themselves in arch/ land if they feel like it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/3] OF-platform PATA driver
On Fri, Nov 23, 2007 at 07:49:33PM -0500, Jeff Garzik wrote: > Anton Vorontsov wrote: > >Here is the PATA Platform driver using OF infrastructure. > > > >Mostly it's just a wrapper around a bit modified pata_platform > >driver. > > > >Patches are well split for the easier review: > > > >First one factors out platform_device specific bits and modifies > >pata_platform to be a library-alike driver (with platform_device > >default binding). > > The only issue I have here is that this library-like version has subtle semantic changes that will break existing drivers. irq_flags exists in struct pata_platform_info precisely for the IRQ resource IRQ flags (as opposed to the IORESOURCE flags, which are what the IRQ resource flags refer to instead). This change takes that for granted and just assumes we're going to be using the res->flags, which is both an invalid assumption, and will utterly break blackfin and others that depend on it. Incidentally, we already have an include/linux/pata_platform.h. If this is going to be library-like, through the prototypes in there, rather than splitting them up betewen include/linux and drivers/ata. We don't need two headers. These patches basically look fine to me otherwise, though it would be nice if the semantic-changing bits had been abstracted. So as long as the old irq_flags behaviour is maintained and that irq_res->flags stuff is ripped out, I'll add my Acked-by as well. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH (2.6.25) 2/2] suspend: clean up Kconfig
On Wed, Nov 07, 2007 at 02:58:00PM +0100, Johannes Berg wrote: > This cleans up the suspend Kconfig and removes the need to > declare centrally which architectures support suspend. All > architectures that currently support suspend are modified > accordingly. > > Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> > Cc: Rafael J. Wysocki <[EMAIL PROTECTED]> > Cc: linuxppc-dev@ozlabs.org > Cc: [EMAIL PROTECTED] > Cc: Guennadi Liakhovetski <[EMAIL PROTECTED]> > Cc: Scott Wood <[EMAIL PROTECTED]> > Cc: David Howells <[EMAIL PROTECTED]> > Cc: Ralf Baechle <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Cc: Paul Mundt <[EMAIL PROTECTED]> > Cc: Bryan Wu <[EMAIL PROTECTED]> > Cc: Russell King <[EMAIL PROTECTED]> > --- > Architecture maintainers should evaluate whether their > ARCH_SUSPEND_POSSIBLE symbol should be set only under > stricter circumstances like I've done for powerpc. > The SH bits look fine. Acked-by: Paul Mundt <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Define termios_1 functions for powerpc, s390, avr32 and frv
On Thu, Sep 13, 2007 at 05:22:36PM +1000, Michael Neuling wrote:
> > > Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
> > > kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
> > > on all architectures. However, powerpc, s390, avr32 and frv don't
> > > currently define those functions since their termios struct didn't
> > > need to be changed when the arbitrary baud rate stuff was added, and
> > > thus the kernel won't currently build on those architectures.
> >
> > alpha, parisc, sh, sparc{64,}, xtensa are still broken with this error...
>
> They need to include in asm-/termios.h
> like in powerpc.
>
> Alternatively tonyb's patch should fix them. Could also do that?
>
Is there a consensus for this? It's a bit annoying to have this stuff
broken this late in 2.6.23. If Tony's patch gets applied, then this stuff
will work itself out. Otherwise everything has to be patched for
asm-generic/termios.h. In which case.. here's the patch to define them on
sh and sh64.
Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
--
include/asm-sh/termios.h | 34 +-
include/asm-sh64/termios.h | 34 +-
2 files changed, 2 insertions(+), 66 deletions(-)
diff --git a/include/asm-sh/termios.h b/include/asm-sh/termios.h
index e7c8f86..c57f74e 100644
--- a/include/asm-sh/termios.h
+++ b/include/asm-sh/termios.h
@@ -49,39 +49,7 @@ struct termio {
*/
#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0"
-/*
- * Translate a "termio" structure into a "termios". Ugh.
- */
-#define SET_LOW_TERMIOS_BITS(termios, termio, x) { \
- unsigned short __tmp; \
- get_user(__tmp,&(termio)->x); \
- *(unsigned short *) &(termios)->x = __tmp; \
-}
-
-#define user_termio_to_kernel_termios(termios, termio) \
-({ \
- SET_LOW_TERMIOS_BITS(termios, termio, c_iflag); \
- SET_LOW_TERMIOS_BITS(termios, termio, c_oflag); \
- SET_LOW_TERMIOS_BITS(termios, termio, c_cflag); \
- SET_LOW_TERMIOS_BITS(termios, termio, c_lflag); \
- copy_from_user((termios)->c_cc, (termio)->c_cc, NCC); \
-})
-
-/*
- * Translate a "termios" structure into a "termio". Ugh.
- */
-#define kernel_termios_to_user_termio(termio, termios) \
-({ \
- put_user((termios)->c_iflag, &(termio)->c_iflag); \
- put_user((termios)->c_oflag, &(termio)->c_oflag); \
- put_user((termios)->c_cflag, &(termio)->c_cflag); \
- put_user((termios)->c_lflag, &(termio)->c_lflag); \
- put_user((termios)->c_line, &(termio)->c_line); \
- copy_to_user((termio)->c_cc, (termios)->c_cc, NCC); \
-})
-
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#include
#endif /* __KERNEL__ */
diff --git a/include/asm-sh64/termios.h b/include/asm-sh64/termios.h
index dc44e6e..b61ce95 100644
--- a/include/asm-sh64/termios.h
+++ b/include/asm-sh64/termios.h
@@ -60,39 +60,7 @@ struct termio {
*/
#define INIT_C_CC "\003\034\177\025\004\0\1\0\021\023\032\0\022\017\027\026\0"
-/*
- * Translate a "termio" structure into a "termios". Ugh.
- */
-#define SET_LOW_TERMIOS_BITS(termios, termio, x) { \
- unsigned short __tmp; \
- get_user(__tmp,&(termio)->x); \
- *(unsigned short *) &(termios)->x = __tmp; \
-}
-
-#define user_termio_to_kernel_termios(termios, termio) \
-({ \
- SET_LOW_TERMIOS_BITS(termios, termio, c_iflag); \
- SET_LOW_TERMIOS_BITS(termios, termio, c_oflag); \
- SET_LOW_TERMIOS_BITS(termios, termio, c_cflag); \
- SET_LOW_TERMIOS_BITS(termios, termio, c_lflag); \
- copy_from_user((termios)->c_cc, (termio)->c_cc, NCC); \
-})
-
-/*
- * Translate a "termios" structure into a "termio". Ugh.
- */
-#define kernel_termios_to_user_termio(termio, termios) \
-({ \
- put_user((termios)->c_iflag, &(termio)->c_iflag); \
- put_user((termios)->c_oflag, &(termio)->c_oflag); \
- put_user((termios)->c_cflag, &(termio)->c_cflag); \
- put_user((termios)->c_lflag, &(termio)->c_lflag); \
- put_user((termios)->c_line, &(termio)->c_line); \
- copy_to_user((termio)->c_cc, (termios)->c_cc, NCC); \
-})
-
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u,
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct
termios))
+#include
#endif /* __KERNEL__ */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
