Re: [PATCH 00/25] Change tty_port(standard)_install's return type

On Tue, 4 Sep 2018 11:44:26 +0900 Jaejoong Kim wrote: > Many drivers with tty use the tty_stand_install(). But, there is no > need to handle the error, since it always returns 0. And what happens if another change means it can fail again. It's just a property of the current implementation

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

On Thu, 22 Jun 2017 10:48:14 -0600 Logan Gunthorpe wrote: > Alpha implements its own io operation and doesn't use the > common library. Thus to make ioread64 and iowrite64 globally > available we need to add implementations for alpha. > > For this, we simply use calls that

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

On Thu, 22 Jun 2017 14:24:58 -0600 Logan Gunthorpe <log...@deltatee.com> wrote: > On 6/22/2017 2:14 PM, Alan Cox wrote: > > If a platform doesn't support 64bit I/O operations from the CPU then you > > either need to use some kind of platform/architecture specific int

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

On Thu, 22 Jun 2017 10:48:13 -0600 Logan Gunthorpe wrote: > Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y > and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not > universally available, it makes them unusable for driver developers. > This

Re: [PATCH] Powerpc 8xx CPM_UART setting MAXIDL register proportionaly to baud rate

4ms. At 9600 bauds it gives a timeout of 4 characters, which is the timeout on the 8250 UART. Signed-off-by: Christophe Leroy christophe.le...@c-s.fr Looks good tome - series Acked-by: Alan Cox a...@linux.intel.com ___ Linuxppc-dev mailing list

Re: [PATCH] Powerpc 8xx CPM_UART delay in receive

* a value of 1 for all rates below 2400 (On 8250, fifo is set to 1 for such rates) * a value of 2 for 2400 and 4800 * a value of 4 for 9600 (which is the default on the 8250 for all rates above 2400) * a value of 8 for 19200 * a value of 16 for 38400 and above (on UCC_UART, maxidl is set to

Re: [PATCH] Powerpc 8xx CPM_UART delay in receive

The PowerPC CPM is working differently. It doesn't use a fifo but buffers. Buffers are handed to the microprocessor only when they are full or after a timeout period which is adjustable. In the driver, the Which is different how - remembering we empty the FIFO on an IRQ buffers are

Re: [PATCH] Powerpc 8xx CPM_UART delay in receive

MAX_IDL: Maximum idle characters. When a character is received, the receiver begins counting idle characters. If MAX_IDL idle characters are received before the next data character, an idle timeout occurs and the buffer is closed, generating a maskable interrupt request to the core to

Re: [PATCH] Powerpc 8xx CPM_UART delay in receive

On Tue, 14 Aug 2012 16:26:28 +0200 Christophe Leroy christophe.le...@c-s.fr wrote: Hello, I'm not sure who to address this Patch to either It fixes a delay issue with CPM UART driver on Powerpc MPC8xx. The problem is that with the actual code, the driver waits 32 IDLE patterns before

Re: [PATCH] mpc85xx_defconfig: add IDE support for MPC85xxCDS

On Fri, 20 Jul 2012 20:45:25 +0800 Zhao Chenhui chenhui.z...@freescale.com wrote: Add IDE support for MPC85xxCDS. Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com --- arch/powerpc/configs/mpc85xx_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git

Re: [PATCH 3/3] serial/8250: delete WR SBC850 UART quirk handling

On Tue, 26 Jun 2012 15:54:29 -0400 Paul Gortmaker paul.gortma...@windriver.com wrote: We've are dropping the support for the EOL SBC8560, so we can also delete this variant of the Alpha quirk support. Cc: Alan Cox a...@linux.intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc

Re: [PATCH 3/3] serial/8250: delete WR SBC850 UART quirk handling

I will, once Alpha is removed from the tree. At the moment, it still uses it. Ok I hadn't realised that. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v16 03/10]USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer (CIL)

O +void dwc_otg_flush_rx_fifo(struct core_if *core_if) +{ + ulong global_regs = core_if-core_global_regs; These are all a bit odd. The register has a given size so they ought to be u32 or u64 etc as appropriate for the register in question, ditto the cache in the structure. + for

Re: [PATCH 5/7] tty: powerpc: remove SERIAL_ICOM dependency on PPC_ISERIES

On Thu, 8 Mar 2012 15:39:31 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: The PowerPC legacy iSeries platform is being removed so this is no longer selectable. Fine by me ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [PATCH 01/16 v2] pmac_zilog: fix unexpected irq

bits only after the handler is installed and before it is uninstalled. Also move this bit flipping into a separate pmz_interrupt_control() routine. Replace all instances of these operations with calls to this routine. Signed-off-by: Finn Thain fth...@telegraphics.com.au Nice Acked-by: Alan

Re: [PATCH 0/6] RFCv2 Fix Fsl 8250 BRK bug

Anyway, have a look and see if this version of things is acceptable to all. (Again, the dts update from Kumar isn't shown here). Thanks to all who provided the feedback on v1. Looks good to me Acked-by: Alan Cox a...@linux.intel.com ___ Linuxppc

Re: [PATCH 3/3] 8250: add workaround for MPC8[356]xx UART break IRQ storm

OK, I'll simply change the above to CONFIG_PPC then. It does, the bug is in the uart IP which I don't think we ever plan on fixing, so 32 or 64-bit parts will have it for ever and ever ;) It should be runtime selected, there should be no ifdefs here.

Re: [PATCH 1/3] serial: make bugs field not specific to 8250 type uarts.

If you have an idea in mind how arch/platform code should cleanly pass data about known uart bugs to the uart driver, then let me know what you have in mind. I've no real attachment to what I proposed here -- it just happened to be the solution I thought would be the least offensive. If

Re: [PATCH 1/3] serial: make bugs field not specific to 8250 type uarts.

Make the bugs field part of the globally visible struct uart_port and remove the 8250 specific one. Except all the bits in it are 8250 specific things or names that are meaningless in generic form - no. I also don't want to encourage flags and bug bits. We already have too many and its making

Re: [PATCH 3/3] 8250: add workaround for MPC8[356]xx UART break IRQ storm

@@ -1553,7 +1554,15 @@ static void serial8250_handle_port(struct uart_8250_port *up) spin_lock_irqsave(up-port.lock, flags); - status = serial_inp(up, UART_LSR); + /* Workaround for IRQ storm errata on break with Freescale 16550 */ + if (UART_BUG_FSLBK up-port.bugs

Re: [PATCH 01/16] pmac_zilog: fix unexpected irq

On Fri, 25 Nov 2011 01:34:58 +1100 (EST) Finn Thain fth...@telegraphics.com.au wrote: On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be masked. This can be a problem when pmac_zilog starts up. For example, the serial debugging code in arch/m68k/kernel/head.S may be

Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver

O +/* One partition must be local, the other must be remote. In other +words, if source and target are both -1, or are both not -1, then +return an error. */ + if ((param.source == -1) == (param.target == -1)) + return -EINVAL; Excess brackets (I just

Re: [PATCH 7/7] [v2] drivers/misc: introduce Freescale hypervisor management driver

On Wed, 1 Jun 2011 15:24:51 -0500 Timur Tabi ti...@freescale.com wrote: Alan Cox wrote: O +/* One partition must be local, the other must be remote. In other + words, if source and target are both -1, or are both not -1, then + return an error. */ + if ((param.source

Re: [PATCH 6/7] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

On Thu, 19 May 2011 11:05:49 -0500 Timur Tabi ti...@freescale.com wrote: Alan Cox wrote: +/* Pass the received data to the tty layer. Note that this + * function calls tty_buffer_request_room(), so I'm not sure if + * we should

Re: [PATCH 6/7] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

On Thu, 19 May 2011 07:22:25 -0700 Greg KH g...@kroah.com wrote: On Thu, May 19, 2011 at 08:54:31AM -0500, Timur Tabi wrote: +/* + * The udbg subsystem calls this function to display a single character. + * We convert CR to a CR/LF. + */ +static void ehv_bc_udbg_putc(char c) +{ +

Re: [PATCH 6/7] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

+ struct tty_struct *ttys; ttys are refcounted and you have a refcounted pointer for free in your tty_port that is maintained by the tty_port logic, as well as it providing ref counted, properly locked handling for the reference. +/ TTY DRIVER

Re: [PATCH 6/7] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Under what circumstances can ttys be NULL? I currently only use this code in the RX and TX interrupt handlers, which are both enabled in the tty_port_operations.activate() function. When you add hangup support. Is this right for the TX handler: static irqreturn_t ehv_bc_tty_tx_isr(int

Re: [PATCH 6/7] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Ok, I can do that. Depends if the functionality is useful in your environment or not It is, but I'd like to add it later so that I can make the 2.6.40 window (if it isn't already too late). Seems sensible. Alan ___ Linuxppc-dev mailing list

Re: [PATCH 6/7] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

On Thu, 19 May 2011 11:31:32 -0500 Timur Tabi ti...@freescale.com wrote: Alan Cox wrote: You really also need a hangup method so vhangup() does the right thing and you can securely do logins etc and sessions on your console. As you've got no hardware entangled in this and you already use

Re: [PATCH] drivers/char/hvc_console.c: reduce max idle timeout

On Wed, 27 Oct 2010 12:54:27 -0400 Chris Metcalf cmetc...@tilera.com wrote: The tile architecture uses this framework for our serial console, That may be a mistake unless your console is genuinely only capable of polled input. Alan ___ Linuxppc-dev

Re: [PATCH V5 2/9] Add Synopsys DesignWare HS USB OTG driver framework.

+ int retval = IRQ_NONE; + + retval = dwc_otg_handle_common_intr(dwc_dev-core_if); + return IRQ_RETVAL(retval); Why assign retval first ? +} + +/** + * This function is the interrupt handler for the OverCurrent condition + * from the external charge pump (if enabled) + */

Re: [PATCH V5 1/9] Add Synopsys DesignWare HS USB OTG Control and Status Register (CSR).

+#if defined(CONFIG_DWC_OTG_REG_LE) Is it really necessary to have everything in the header twice rather than using endian switches in the I/O ? Also with the code in that form how do you build a single copy of the driver that runs on platforms which may have one or the other endian Finally -

Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

On Mon, 27 Sep 2010 10:56:09 -0500 (CDT) Christoph Lameter c...@linux.com wrote: On Fri, 24 Sep 2010, Alan Cox wrote: Whether you add new syscalls or do the fd passing using flags and hide the ugly bits in glibc is another question. Use device specific ioctls instead of syscalls

Re: [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the MPC85xx.

However, if the clock selected by the BMC is switched off, loses its network connection..., the second best clock is selected by the BMC and becomes master. This clock may be less accurate and thus our slave clock has to switch from one notion of time to another. Is that the conflict you

Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

On Fri, 24 Sep 2010 15:14:07 +0200 Richard Cochran richardcoch...@gmail.com wrote: On Thu, Sep 23, 2010 at 09:36:54PM +0100, Alan Cox wrote: Drop the clockid_t and swap it for a file handle like a proper Unix or Linux interface. The rest is much the same fd = open /sys/class

Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

You can't do that avoiding as you might like because the behaviour of file handle numbering is defined by the standards. Hence the f* versions of the calls (and of lots of other stuff) Whether you add new syscalls or do the fd passing using flags and hide the ugly bits in glibc is another

Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

/timesource (hope Alan Cox agrees :) It makes sense to hang anything off the physical id I threw it out there mostly for the sake of discussion. I imagined that there could be other properties in that directory, like time scale (TAI, UTC, etc). But it seems like we don't really need anything

Re: [PATCH 6/8] ptp: Added a clock that uses the eTSEC found on the MPC85xx.

Please do not introduce useless additional layers for clock sync. Load these ptp clocks like the other regular clock modules and make them sync system time like any other clock. I don't think you understand PTP. PTP has masters, a system can need to be honouring multiple conflicting masters at

Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

O I don't see how this is a problem, as it exposes the multiple hardware clocks via different posix clock ids. So in the boundary clock case, you can configure which side is the client and which side is the master in a config file and the PTPd will appropriately steer them individually. They

Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

There is no other scalable time source available for fast timer access than the time stamp counter in the cpu. Other time source require memory accesses which is inherently slower. On what hardware ? An accurate other time source is used to adjust this clock. NTP does that via the clock

Re: [PATCH] hvc_console: fix dropping of characters when output byte channel is full

On Tue, 14 Sep 2010 14:25:34 -0500 Timur Tabi ti...@freescale.com wrote: Alan Cox wrote: Its a printk handler - better to lose the bytes than hang the box. I think the current code is probably right. What do you think about this change: http://lists.ozlabs.org/pipermail/linuxppc-dev

Re: [PATCH] hvc_console: fix dropping of characters when output byte channel is full

Yes, hvc_push() reschedules. It doesn't sit in a tight loop burning electrons! Can we do something safersmarter here? Its a printk handler - better to lose the bytes than hang the box. I think the current code is probably right. ___ Linuxppc-dev

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

So if the clock_adjtime interface is needed, it would seem best for it to be generic enough to support not only PTP, but also the NTP kernel PLL. For the proposed clock_adjime, what else is needed to support clock adjustment in general? Multiple PLLs, at least with containers and

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

The master node in a PTP network probably takes its time from a precise external time source, like GPS. The GPS provides a 1 PPS directly to the PTP clock hardware, which latches the PTP hardware clock time on the PPS edge. This provides one sample as input to a clock servo (in the PTPd)

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

2007. If we can justify adding a clock id in this case, surely we can add one for PTP as well! But PTP isn't really a clock - its a time sync protocol. You can (and may need to) have multiple clocks of this form on the same host because it's master based and you may have to deal with multiple

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

To tell the truth, my original motivation for the patch set was to support PTP clocks and applications. I don't think that is such a bad ptp *clocks* idea. After all, the adjtimex interface was added just to support NTP. At the same time, I can understand the desire to have a generic

Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.

Sorry for causing confusion, but please understand a hardware clock with timestamping capabilities than can be used for PTP support whenever I wrote PTP or PTP clock. Ok that makes sense. Well, what I just said is not entirely true. most are bound to the PTP protocol. That may change in

Re: [PATCH]460EX on-chip SATA driver Kernel 2.6.33 resubmission

On Wed, 19 May 2010 10:49:59 +0900 Jassi Brar jassisinghb...@gmail.com wrote: On Thu, May 6, 2010 at 2:57 AM, Rupjyoti Sarmah rsar...@amcc.com wrote: This patch enables the on-chip DWC SATA controller of the AppliedMicro processor 460EX. The controller seems to be a thrid party IP (from

Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove

I don't claim to understand the tty layer, but it seems like hvc_open and hvc_close should be balanced in their kref reference counting. They should yes. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org

Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove

mount: can't find /root/proc in /etc/fstab or /etc/mtab /sbin/smart_agetty: can not determine 'console' speed OK, this gets even murkier. I don't know why taking a few krefs modifies hvc_console behaviour to such an extent. Can you see if the agetty is getting a hangup or open

Re: [PATCH 4/7] hvc_console: Fix race between hvc_close and hvc_remove

On Sun, 21 Mar 2010 08:04:39 +1100 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2010-03-19 at 08:18 -0700, Greg Kroah-Hartman wrote: From: Amit Shah amit.s...@redhat.com Alan pointed out a race in the code where hvc_remove is invoked. The recent virtio_console work is

Re: [PATCH v2] hvc_console: Fix race between hvc_close and hvc_remove

On Wed, 3 Mar 2010 20:59:48 +0530 Amit Shah amit.s...@redhat.com wrote: Alan pointed out a race in the code where hvc_remove is invoked. The recent virtio_console work is the first user of hvc_remove(). Looks better to me. Alan ___ Linuxppc-dev

Re: [PATCH] hvc_console: Fix a race between hvc_close and hvc_remove

+ tty_kref_get(hp-tty); spin_lock_irqsave(hp-lock, flags); tty = hp-tty; @@ -830,7 +833,9 @@ int hvc_remove(struct hvc_struct *hp) * cleaned up the hvc_struct. */ if (tty) - tty_hangup(tty); + tty_vhangup(tty); + +

Re: [patch 22/28] macintosh: Remove BKL from ans-lcd

There were 4 checkpatch errors on this patch, all of the type ERROR: spaces required around that '=' (ctx:WxO) #1466: FILE: drivers/macintosh/ans-lcd.c:112: + ret =-EACCES; Here's a suggestion. If a few spaces bug you that much then instead of complaining about it and

Re: Extending virtio_console to support multiple ports

- Then, are we certain that there's no case where the tty layer will call us with some lock held or in an atomic context ? To be honest, I've totally lost track of the locking rules in tty land lately so it might well be ok, but something to verify. Some of the less well behaved line

Re: spin_is_locked() broken for uniprocessor?

On Wed, 19 Aug 2009 10:38:06 +0100 David Howells dhowe...@redhat.com wrote: Thomas Gleixner t...@linutronix.de wrote: which implies to me that spin_is_locked() will always return false. Is this expected behavior. That's wrong. spin_is_locked should always return true on UP.

Re: Badness at drivers/char/tty_ldisc.c:210 during shutdown

[c0003cf6ba70] [c040a3d0] .tty_ldisc_put+0xa4/0xf4 (unreliable) [c0003cf6bb10] [c040a7c8] .tty_ldisc_reinit+0x38/0x80 [c0003cf6bba0] [c040b1d8] .tty_ldisc_hangup+0x190/0x260 [c0003cf6bc40] [c0401090] .do_tty_hangup+0x188/0x4c0

Re: [PATCH 2/2] uio: add an of_genirq driver

I did it that way because I saw IRQ 0 in /proc/interrupts on every PC... It is the job of the platform to map a physical IRQ 0 to some other representation if it exists outside of arch specific code. Funny. This was decided some years ago and a large part of the kernel simply

Re: [PATCH 2/2] uio: add an of_genirq driver

+ if (!uioinfo-irq) + uioinfo-irq = UIO_IRQ_NONE; Please don't do this. It's inconsistent if all other UIO drivers require people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was introduced because 0 may be a legal interrupt number on some platforms. Zero is not

Re: [PATCH] fix sata_sil compilation on non-DMI platforms

Ideally the DMI subsystem should be provided wrappers for platforms without DMI, rendering patches like this unnecessary. Interesting question - is the PPC OpenFirmware machine information mappable onto the DMI space ? or the various static bits of name information in the various ARM and the

Re: [BUG] hvc_console WARN() on current upstream

Seems that we are in interrupt, doing hvc_poll, which does tty_flip_buffer_push Which means that someone has tty-low_latency set and is calling tty_flip_buffer_push in an IRQ. That has never been allowed or safe, and now it hurts ;) /** * tty_flip_buffer_push- terminal *

Re: powerpc: hv{cs, si}_close() both unsigned hp-count and hvcsd-open_count cannot be negative

Also, I don't see why those changes have anything to do with unsigned things cannot be negative. As long as those counts are never zero on entry to those code sections, the existing code is fine, and I believe that assertion can be maintained. If you believe the code needs to defend against

Re: linux-next: ttydev tree build failure

On Thu, 23 Oct 2008 17:29:38 +1100 Stephen Rothwell [EMAIL PROTECTED] wrote: Hi Alan, Today's linux-next build (powerpc ppc64_defconfig) failed like this: drivers/char/hvc_console.c: In function 'hvc_set_winsz': drivers/char/hvc_console.c:532: warning: passing argument 2 of

Re: [RFC PATCH 2/5] hvc_console: Add tty driver flag TTY_DRIVER_RESET_TERMIOS

For my network-based hvc backend, a tty_hangup() is caused by a disconnect. If it is network backed then you probably do want TTY_DRIVER_TERMIOS_RESET. For a normal serial type port getty is supposed to sort the terminal settings out. So in your case it sounds like resetting it is the right

Re: [RFC PATCH 2/5] hvc_console: Add tty driver flag TTY_DRIVER_RESET_TERMIOS

as the reissue of the same pty is done as a new device (with new state). Setting this on the hvc would parallel the PC vt console behaviour but differ from most other ports. Anyway its a policy question for PPC64 so if thats how you want it to work Acked-by: Alan Cox [EMAIL PROTECTED

Re: [RFC PATCH 4/5] hvc_console: Add tty window resizing

+ hp = container_of(work, struct hvc_struct, tty_resize); + if (!hp || !hp-tty) + return; What locks hp-tty here, it can go NULL after the test on a hangup it seems ? + * hvc_resize() - Update terminal window size information. + * @hp: HVC console pointer +

Re: [PATCH] pata_of_platform: fix no irq handling

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... Good guide to platform code we should delete really

Re: [PATCH] pata_of_platform: fix no irq handling

This was discussed years ago. http://lkml.org/lkml/2005/11/22/159 http://lkml.org/lkml/2005/11/22/227 Would this break any existing platforms? If so, can those be fixed together or does it become a much bigger problem that way? Zero means no IRQ. Any platform with bits of code

Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling

Shouldn't this be - if (client-irq = NO_IRQ) instead of NO_IRQ is obsolete. client-irq != is the test and IRQ numbers are unsigned. Alan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org

Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling

I don't know the status of these platforms asm-blackfin/irq.h:#define NO_IRQ ((unsigned int)(-1)) asm-mn10300/irq.h:#define NO_IRQ INT_MAX asm-parisc/irq.h:#define NO_IRQ (-1) In need of fixing, assuming they actually use NO_IRQ for anything - don't be mislead

Re: [PATCH] pata_of_platform: fix no irq handling

On Mon, 11 Aug 2008 17:36:48 +0100 Ben Dooks [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 07:19:13PM +0400, Anton Vorontsov wrote: When no irq specified, pata_of_platform fills irq_res with -1, which is wrong to do for two reasons: 1. By definition, 'no irq' should be IRQ 0, not

Re: [PATCH] pata_of_platform: fix no irq handling

0, but since irq_res.start is unsigned type, the check will be true for `-1'. Reported-by: Steven A. Falco [EMAIL PROTECTED] Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] ___ Linuxppc-dev mailing list

[PATCH]: Remove bogons from the iSeries console

, the core tty layer has always called the ldisc ioctl method *anyway* and will call the one for the right ldisc. Signed-off-by: Alan Cox [EMAIL PROTECTED] --- drivers/char/viocons.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/char/viocons.c b/drivers/char

Re: [PATCH]: Remove bogons from the iSeries console

On Thu, 7 Aug 2008 09:43:28 +1000 Paul Mackerras [EMAIL PROTECTED] wrote: Alan Cox writes: --- a/drivers/char/viocons.c +++ b/drivers/char/viocons.c @@ -705,10 +705,6 @@ static int viotty_ioctl(struct tty_struct *tty, struct file *file, case KDSKBLED: return 0

Re: ide pmac breakage

There seems to be some confusion between warm-plugging of IDE devices and hot-plugging of IDE devices. not a single piece of HW to exercise those code path ? I don't ask you to get a powermac with a media-bay, but ide_cs seems to be a pretty important one that's part of what the ide

Re: ide pmac breakage

I could make the media-bay look like a controller hotplug if it was going to make things easier... I'm not sure it will. It may do nowdays, but the older IDE code historically was fairly broken for both cases except in 2.4. Also faking it as controller hotplug is the wrong path for libata which

Re: mISDN still breaking the allmodconfig build...

On Sun, 27 Jul 2008 20:48:05 -0400 Sean MacLennan [EMAIL PROTECTED] wrote: On Mon, 28 Jul 2008 10:13:42 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Sun, 2008-07-27 at 17:02 -0700, David Miller wrote: More fallout from the premature mISDN driver merge:

Re: [PATCH] isdn: mISDN HFC PCI support depends on virt_to_bus()

On Mon, 28 Jul 2008 02:37:32 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: On powerpc (allyesconfig build) we get this error: drivers/isdn/hardware/mISDN/hfcpci.c:1991: error: implicit declaration of function 'virt_to_bus' Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] Can we

Re: [PATCH] serial: fix struct uart_info change fallout

What is your problem with the linux-next tree. The problem was discovered and reported when I first merged the ttydev tree into linux-next on July 1. The fixes were in linux-next on July 2. Yes .. and ? The clashes kept happening despite that when I was doing the merges (and going on holiday

Re: latest tree build failure -- cpm uart gpio

On Tue, 22 Jul 2008 08:54:16 -0500 Kumar Gala [EMAIL PROTECTED] wrote: can someone look at the following compile failure in linus's tree. I'm guessing part of this has to do with Alan's tty changes (and might already be addressed?). include/asm-generic/gpio.h:131: error: implicit

Re: [PATCH] serial: fix struct uart_info change fallout

I interpreted your So much for the linux-next tree as saying well, that has been no help. I am sorry if I got that wrong. True it didn't help in the merge that much this time. I don't think that is a problem with the linux-next tree but one of the lack of tty maintainer and tty tree letting

Re: [PATCH] serial: fix struct uart_info change fallout

On Tue, 22 Jul 2008 10:25:20 +1000 Stephen Rothwell [EMAIL PROTECTED] wrote: Hi Linus, Alan, Today's linux-next (actually just Linus' tree) build (powerpc ppc64_defconfig) failed like this: Yes I know. I've been trying to get the other patches merged but each of the five pulls of Linus

Re: [PATCH 46/60] microblaze_v4: termbits.h termios.h

+++ b/include/asm-generic/termbits.h @@ -0,0 +1,200 @@ +/* c_cflag bit meaning */ + +#define CBAUD0010017 +#define B0 000 /* hang up */ You need BOTHER in here as well - especially if it is going to be generic. ___ Linuxppc-dev

Re: Linux 2.6.26-rc5

On Thu, 5 Jun 2008 13:24:36 +0200 Olaf Hering [EMAIL PROTECTED] wrote: On Wed, Jun 04, Linus Torvalds wrote: Another week, another batch of mostly pretty small fixes. Hopefully the regression list is shrinking, and we've fixed at least a couple of the oopses on Arjan's list. SATA on

Re: Linux 2.6.26-rc5 (G5 SATA broken)

And the patch I'm finding successful is below: I won't sign it off, for all I know it's reverting part of what Alan is trying to achieve; but I expect it'll help towards the right fix. Its the right fix ata_sff_check_altstatus() is a routine which does the altstatus check and may or

Re: [PATCH 1/8] [WATCHDOG] mpc83xx_wdt: fix checkpatch issues

On Mon, 2 Jun 2008 21:38:36 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote: Quite tired of these warnings ;-), checkpatch spitting them when seeing the rename patch. I've already sent the maintainer a complete overhaul of watchdog via checkpatch. Alan

Re: MMIO and gcc re-ordering issue

It's not exactly a well-established interface. Only five architectures define these functions, and there is not a single user in the kernel source outside of these architecture's io.h files. That is because the drivers using them had them removed (eg I²O) - mostly because it didn't compile on

Re: MMIO and gcc re-ordering issue

re-ordering, even though I doubt it will be visible in practice. So if you use the __ versions, you'd better have barriers even on x86! Are we also going to have __ioread*/__iowrite* ? Also is the sematics of __readl/__writel defined for all architectures - I used it ages ago in the i2o

Re: MMIO and gcc re-ordering issue

On Tue, 27 May 2008 15:53:28 -0600 Matthew Wilcox [EMAIL PROTECTED] wrote: On Tue, May 27, 2008 at 10:38:22PM +0100, Alan Cox wrote: re-ordering, even though I doubt it will be visible in practice. So if you use the __ versions, you'd better have barriers even on x86! Are we also

[PATCH] generic rtc and nvram: Push the BKL down

Switch the ioctl handlers to unlocked_ioctl and push lock_kernel into the driver instead. Signed-off-by: Alan Cox [EMAIL PROTECTED] diff --git a/drivers/char/generic_nvram.c b/drivers/char/generic_nvram.c index 2398e86..8886e51 100644 --- a/drivers/char/generic_nvram.c +++ b/drivers/char

Re: [PATCH] [POWERPC] Improve (in|out)_beXX() asm code

It looks like we rely on -fno-strict-aliasing to prevent reordering ordinary memory accesses (such as to DMA descriptors) past the I/O DMA descriptors in main memory are dependant on cache behaviour anyway and the dma_* operators should be the ones enforcing the needed behaviour. Alan

Re: [PATCH 00/18] ide: warm-plug support for IDE devices and other goodies

On Wed, 13 Feb 2008 08:04:07 +1100 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Fri, 2008-02-08 at 19:40 +1100, Benjamin Herrenschmidt wrote: On Fri, 2008-02-08 at 01:44 +0100, Bartlomiej Zolnierkiewicz wrote: - couple of fixes and preparatory patches - rework of PowerMac

Re: [PATCH/RFCv2] [POWERPC] Add support for freescale watchdog to CPM serial driver.

On Fri, 18 Jan 2008 19:47:43 +0100 Jochen Friedrich [EMAIL PROTECTED] wrote: Hi Alan, If a freescale watchdog device node is present, reset the watchdog while waiting for serial input. Why ? We normally rely on user space for watchdog management as only the fact user space is

Re: [linux-usb-devel] [PATCH 1/5] USB: Make usb_hcd_irq work for multi-role USB controllers w/ shared irq

On Fri, 23 Nov 2007 21:10:39 -0800 Greg KH [EMAIL PROTECTED] wrote: On Fri, Nov 23, 2007 at 05:24:31PM -0700, Grant Likely wrote: From: Peter Korsgaard [EMAIL PROTECTED] Some multi-role (host/peripheral) USB controllers use a shared interrupt line for all parts of the chip. Export

Re: [PATCH v2] drivers/ata: add support to Freescale 3.0Gbps SATA Controller

+ cd = pp-cmdentry + tag; + + memcpy(fis, cd-sfis, 6 * 4); /* should we use memcpy_from_io() */ If cd-sfis points at memory over the PCI bus (eg mmio or memory on the controller card) then you need to use ioread/_io type functions. If cd-sfis points into host memory where the FIS is

Re: [PATCH v2] pcmcia: Convert io_req_t to use kio_addr_t

On Fri, 21 Sep 2007 17:15:16 -0500 Olof Johansson [EMAIL PROTECTED] wrote: Convert the io_req_t members to kio_addr_t, to allow use on machines with more than 16 bits worth of IO ports (i.e. secondary busses on ppc64, etc). What about the formatting and field widths ? ulong would probably be

Re: [PATCH] powerpc: add new required termio functions

On Wed, Sep 12, 2007 at 02:49:10PM +0100, Christoph Hellwig wrote: On Wed, Sep 12, 2007 at 01:52:57PM +0200, Heiko Carstens wrote: I might be missing something, but the the right fix is probably to apply the arch patches from Alan to powerpc and s390. We don't want to be left over

Re: Define termios_1 functions for powerpc, s390, avr32 and frv

On Thu, Sep 13, 2007 at 01:16:31AM +1000, Paul Mackerras wrote: asm-generic/termios.h). Signed-off-by: Paul Mackerras [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org

Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix

Unfortunately this breaks pata_pdc2027x on my PowerMac G3: Did this ever get resolved? All went quiet so I assume its gone away ? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] mark PCI resource with start 0 as unassigned

O That's of course the smarter choice, _if_ we have a choice at all -- on PowerPC, the PCI setup on certain platforms is done by the firmware (and we don't want to mess with it for various reasons), and some _do_ map PCI legacy I/O at 0. Not in this case though, so let's just ignore that

  1   2   >