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 that
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 chain two 32-bit opera
On Thu, 22 Jun 2017 14:24:58 -0600
Logan Gunthorpe 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 interface
> > if present or
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 leads to ugly hacks suc
t 9600 bauds it gives a timeout of 4 characters, which is
> the timeout on the 8250 UART.
>
> Signed-off-by: Christophe Leroy
Looks good tome - series Acked-by: Alan Cox
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://list
> * 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
> 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
> 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 con
On Tue, 14 Aug 2012 16:26:28 +0200
Christophe Leroy 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 returning the recei
On Fri, 20 Jul 2012 20:45:25 +0800
Zhao Chenhui wrote:
> Add IDE support for MPC85xxCDS.
>
> Signed-off-by: Zhao Chenhui
> ---
> arch/powerpc/configs/mpc85xx_defconfig |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/configs/mpc85xx_defconfig
> b/ar
> 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
On Tue, 26 Jun 2012 15:54:29 -0400
Paul Gortmaker 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
> Cc: Greg Kroah-Hartman
> Cc: linux-ser...@vger.kernel.org
> Sig
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.
> + f
On Thu, 8 Mar 2012 15:39:31 +1100
Stephen Rothwell 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
https://lists.ozlabs.org/listinfo
this by setting the interrupt enable 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 rout
> 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
___
Linuxppc
> 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
> > 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.
__
> @@ -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->
> 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
On Fri, 25 Nov 2011 01:34:58 +1100 (EST)
Finn Thain 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
> used beforehand. It di
> There's a check for -ENOIOCTLCMD in vfs_ioctl() -- though it generates
> -EINVAL rather than -ENOTTY (why?).
Good question - perhaps someone didn't read the spec 8)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/l
On Wed, 1 Jun 2011 15:24:51 -0500
Timur Tabi 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
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
On Thu, 19 May 2011 11:05:49 -0500
Timur Tabi 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
> &g
On Thu, 19 May 2011 11:31:32 -0500
Timur Tabi 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 an
> 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 mailin
> 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_is
> + 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
> ***
On Thu, 19 May 2011 07:22:25 -0700
Greg KH 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)
> > +{
> > +
On Wed, 27 Oct 2010 12:54:27 -0400
Chris Metcalf 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 mailing list
Linuxpp
> +#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 -
> + 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
On Mon, 27 Sep 2010 10:56:09 -0500 (CDT)
Christoph Lameter 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 in
quot; so its a little more clear what the id is for.
>
> Okay, I will drop /sys/class/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
> 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 an
On Fri, 24 Sep 2010 15:14:07 +0200
Richard Cochran 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
> 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
>
> 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
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.
The
> 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
>So as far as the POSIX standard is concerned, offering a clock id
>to represent the PHC would be acceptable.
But completely useless as you may have more than one entirely different
time managed by PTP and in which you are not master but must work with
the timebases provided.
> /sys/
> Yes, hvc_push() reschedules. It doesn't sit in a tight loop burning
> electrons!
>
> Can we do something safer&smarter here?
Its a printk handler - better to lose the bytes than hang the box. I
think the current code is probably right.
___
Linuxppc-
On Tue, 14 Sep 2010 14:25:34 -0500
Timur Tabi 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/pipermai
> 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 c
> 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
>
> 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
> 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)
> > 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 an
On Wed, 19 May 2010 10:49:59 +0900
Jassi Brar wrote:
> On Thu, May 6, 2010 at 2:57 AM, Rupjyoti Sarmah 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 Synopsys) in your
> SoC and there
> 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
https://lists.ozlabs.org/listinfo/l
> >> 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 han
On Sun, 21 Mar 2010 08:04:39 +1100
Benjamin Herrenschmidt wrote:
> On Fri, 2010-03-19 at 08:18 -0700, Greg Kroah-Hartman wrote:
> > From: Amit Shah
> >
> > 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().
>
>
On Wed, 3 Mar 2010 20:59:48 +0530
Amit Shah 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 mailing list
Linuxppc-
> + 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);
>
On Tue, 19 Jan 2010 22:17:59 +0100
Wim Van Sebroeck wrote:
> Hi All,
>
> please comment on following patch.
Why move them out - why not just make them const ?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinf
> 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 p
> - 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 disc
On Wed, 19 Aug 2009 10:38:06 +0100
David Howells wrote:
> Thomas Gleixner 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.
>
> Surely it's not that
> > [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
> > [c00
> 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 ke
> > + 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.
Zer
> 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
> v2.6.16-rc1 via 33f0f88f1c51ae5c2d593d26960c760ea154c2e2
> [PATCH] TTY layer buffering revamp
>
> added this new api.
No - tty_flip_buffer_push is from 2.1.66 and with the same constraints
from the day it was added.
> Having the flag set for purely polled drivers will save delaying
> the
> > 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
*
> 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 a
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
> 'tty
> 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 thin
> Since tty_do_resize() cannot be called holding the hp spinlock; the code uses
> now tty_kref_get/put to keep track of the tty object. I am not sure if the
> use of the kref's is correct here, so please let me know if there is a better
> solution.
That looks right to me, hp->tty can go NULL but t
> + 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 poin
ty task normally. pty is special 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: Al
On Mon, 13 Oct 2008 16:17:02 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Wang Jian wrote:
> > +static void pata_platform_postreset(struct ata_link *link, unsigned int
> > *classes)
> > +{
> > + struct ata_port *ap = link->ap;
> > + struct ata_device *dev;
> > + u8 select = ATA_
> > 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
__
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 lib
> > 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 bit
> 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 mis
> 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
https://ozlabs.org/mailman/listinfo/li
gt; 2. pata_platform checks for irq_res.start > 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 PROTEC
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 I
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
> &g
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/driver
> 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 whic
> 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
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:
> > >
> >
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
> 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 letti
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
> 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 holid
On Mon, 21 Jul 2008 20:38:14 -0400
Dave Jones <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 22, 2008 at 10:25:20AM +1000, Stephen Rothwell wrote:
> > Hi Linus, Alan,
> >
> > Today's linux-next (actually just Linus' tree) build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/seri
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 Linu
> +++ 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-de
> 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 o
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.
>
> Anyway, Intel certainly seems to document that WC memory is serialized by
> any access to UC memory.
I don't believe that is actually true on Pentium Pro at least.
> So what started out as a "we can do accesses to the frame buffer more
> efficiently without anybody ever even having to kno
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
___
> 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 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 "__" ve
> 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 dr
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/driver
> 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
_
1 - 100 of 117 matches
Mail list logo
