On Mon, 2015-03-09 at 07:36 -0700, Tim Kryger wrote:
On Mon, Mar 9, 2015 at 6:32 AM, Alan Cox a...@linux.intel.com wrote:
Maybe the next release of the board we will upgrade the serial block to
the new version.
but the issue is that how we circumvent this problem in kernel?
What
> Besides, the "ACPI reduced hardware" case is kind of a red herring here,
> because it most likely is not the only case when we'll want has_8259_pic()
> to return 0 (quite likely, we'll want that on all BayTrail-based systems,
> for example).
No. Only those with ACPI reduced firmware. For others
> I'll do more investigation above items but I want to leave at least
> these two as the quirk today unless I am convinced I can do that because
> from my understanding, UEFI runtime services should not be supported in
> reduced hw mode.
What actually matters in this space is what Microsoft does.
Besides, the ACPI reduced hardware case is kind of a red herring here,
because it most likely is not the only case when we'll want has_8259_pic()
to return 0 (quite likely, we'll want that on all BayTrail-based systems,
for example).
No. Only those with ACPI reduced firmware. For others you
I'll do more investigation above items but I want to leave at least
these two as the quirk today unless I am convinced I can do that because
from my understanding, UEFI runtime services should not be supported in
reduced hw mode.
What actually matters in this space is what Microsoft does. The
On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
> > Sort of. What we need is a "do not touch PIC/PIT" bit for the code that
> > tries to fall back to them in some cases (which may appear to work if
> > the hardware is
On Wed, 2015-03-04 at 10:50 +0100, Borislav Petkov wrote:
> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
> > >
> > >Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
> > >is a mistake.
> >
> > ideally, the presence of that flag in the firmware table will clear/set
On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
Sort of. What we need is a do not touch PIC/PIT bit for the code that
tries to fall back to them in some cases (which may appear to work if
the hardware is
On Wed, 2015-03-04 at 10:50 +0100, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
is a mistake.
ideally, the presence of that flag in the firmware table will clear/set
more global
> > This is a long term plan, of course, but I'd like to see sysfs functions go
> > away
> > in a year or so. What do you think?
>
> hoo boy. Creating a /dev node and doing ioctls on it is really old
> school. So old school that I've forgotten why we don't do it any more.
>
> Hopefully Alan
This is a long term plan, of course, but I'd like to see sysfs functions go
away
in a year or so. What do you think?
hoo boy. Creating a /dev node and doing ioctls on it is really old
school. So old school that I've forgotten why we don't do it any more.
Hopefully Alan can recall
On Mon, 2015-02-16 at 11:29 +0900, Masanari Iida wrote:
> On Thu, Feb 12, 2015 at 12:48 AM, Greg Kroah-Hartman
> wrote:
> > On Wed, Feb 11, 2015 at 02:19:00PM +0000, Alan Cox wrote:
> >> On Wed, 2015-02-11 at 07:27 +1100, Stephen Rothwell wrote:
> >> > Hi Jim,
>
On Mon, 2015-02-16 at 11:29 +0900, Masanari Iida wrote:
On Thu, Feb 12, 2015 at 12:48 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Feb 11, 2015 at 02:19:00PM +, Alan Cox wrote:
On Wed, 2015-02-11 at 07:27 +1100, Stephen Rothwell wrote:
Hi Jim,
On Tue, 10 Feb
On Wed, 2015-02-11 at 07:27 +1100, Stephen Rothwell wrote:
> Hi Jim,
>
> On Tue, 10 Feb 2015 11:40:23 -0700 Jim Davis wrote:
> >
> > DOCPROC Documentation/DocBook/device-drivers.xml
> > docproc: .//include/linux/i2o.h: No such file or directory
> > make[1]: ***
On Wed, 2015-02-11 at 07:27 +1100, Stephen Rothwell wrote:
Hi Jim,
On Tue, 10 Feb 2015 11:40:23 -0700 Jim Davis jim.ep...@gmail.com wrote:
DOCPROC Documentation/DocBook/device-drivers.xml
docproc: .//include/linux/i2o.h: No such file or directory
make[1]: ***
A small number of systems respond to PnP dock queries with bogus values.
This causes us to keep logging an error every 2 seconds. Instead of trying
again just assume the BIOS is crapware and doesn't actually have dock
functionality.
Signed-off-by: Alan Cox
---
drivers/pnp/pnpbios/core.c |3
A small number of systems respond to PnP dock queries with bogus values.
This causes us to keep logging an error every 2 seconds. Instead of trying
again just assume the BIOS is crapware and doesn't actually have dock
functionality.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/pnp
'find_io_region':
> drivers/pcmcia/rsrc_pci.c:40:2: error: implicit declaration of function
> 'pci_bus_alloc_resource' [-Werror=implicit-function-declaration]
>
> This adds the missing include statement.
>
> Signed-off-by: Arnd Bergmann
> Cc: Alan Cox
> Cc: Greg Kroah-Hartman
>
/pcmcia/rsrc_pci.c:40:2: error: implicit declaration of function
'pci_bus_alloc_resource' [-Werror=implicit-function-declaration]
This adds the missing include statement.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: Alan Cox a...@linux.intel.com
Cc: Greg Kroah-Hartman gre
On Mon, 2015-01-12 at 17:12 +0100, Thierry Reding wrote:
> On Mon, Jan 12, 2015 at 01:29:27PM +0000, Alan Cox wrote:
> > On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote:
> > > Changes various calls in the functions,send_pkg_prepare and send_pkg_done
> >
On Mon, 2015-01-12 at 16:35 +0100, Arnd Bergmann wrote:
> On Monday 12 January 2015 21:08:21 Eddie Huang wrote:
> > Add earlycon support not only baudrate option, but also add noinit option.
> > If use noinit option, 8250 earlycon will not init serial hardware and use
> > loader setting.
> >
> >
On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote:
> Changes various calls in the functions,send_pkg_prepare and send_pkg_done
> for mdelay to msleep. These changes are needed due to use working with
> various sleep modes supported by this hardware and thus needing to sleep
> for a small
On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote:
Changes various calls in the functions,send_pkg_prepare and send_pkg_done
for mdelay to msleep. These changes are needed due to use working with
various sleep modes supported by this hardware and thus needing to sleep
for a small
On Mon, 2015-01-12 at 16:35 +0100, Arnd Bergmann wrote:
On Monday 12 January 2015 21:08:21 Eddie Huang wrote:
Add earlycon support not only baudrate option, but also add noinit option.
If use noinit option, 8250 earlycon will not init serial hardware and use
loader setting.
On Mon, 2015-01-12 at 17:12 +0100, Thierry Reding wrote:
On Mon, Jan 12, 2015 at 01:29:27PM +, Alan Cox wrote:
On Sat, 2015-01-10 at 23:31 -0500, Nicholas Krause wrote:
Changes various calls in the functions,send_pkg_prepare and send_pkg_done
for mdelay to msleep. These changes
The code bothers to probe for the device, but on failing to find it proceeds
to try and release a NULL resource, thereby ruining it's prior good
behaviour
Resolves-Bug: https://bugzilla.kernel.org/show_bug.cgi?id=88581
Signed-off-by: Alan Cox
---
drivers/staging/speakup/speakup_dtlk.c |7
The code bothers to probe for the device, but on failing to find it proceeds
to try and release a NULL resource, thereby ruining it's prior good
behaviour
Resolves-Bug: https://bugzilla.kernel.org/show_bug.cgi?id=88581
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/speakup
The driver very carefully checks if the card is the IRQ source, and if it
isn't thoughtfully spews crap at_dev_warn() level. Remove the spewage so it
can be used on a shared interrupt line.
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=88651
Signed-off-by: Alan Cox
---
.../comedi
The driver very carefully checks if the card is the IRQ source, and if it
isn't thoughtfully spews crap at_dev_warn() level. Remove the spewage so it
can be used on a shared interrupt line.
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=88651
Signed-off-by: Alan Cox
On a pure PCI platform we don't actually need all the complexity of the
rsrc_nonstatic manager, in fact we can just work directly with the pci
allocators and avoid all the complexity (and code bloat).
Signed-off-by: Alan Cox
---
drivers/pcmcia/Kconfig| 12 ++-
drivers/pcmcia/Makefile
it to the
wrong thing we only fix up apparently anonymous cards if the driver for them
has been enabled.
Signed-off-by: Alan Cox
---
drivers/pcmcia/cistpl.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia
The requery logic goes off and attempts to read the CIS of empty slots. In
most cases this happens not to do any harm - but not all!
Add the missing check and also a WARN() to catch any other offenders.
Signed-off-by: Alan Cox
---
drivers/pcmcia/cistpl.c |2 +-
drivers/pcmcia/ds.c
The current code displays warnings but then proceeds to try and reference
the data through the PCMCIA window. Instead return 0xff. This prevents bogus
CIS data sending us off into hyperspace.
Signed-off-by: Alan Cox
---
drivers/pcmcia/cistpl.c |5 -
1 file changed, 4 insertions(+), 1
less hideously convoluted resource manager that gets used
when the only PCMCIA present is via PCI bridges. In that situation the core
pci layer can do the job perfectly well for us and just needs a bit of
wrapping.
Alan
---
Alan Cox (5):
pcmcia: correct types
pcmcia cis: on an out
We should be using resource_size_t and unsigned types correctly, otherwise
we sign extend the flags on a 64bit box, which is not what we want.
Signed-off-by: Alan Cox
---
drivers/pcmcia/cs_internal.h |6 +++---
drivers/pcmcia/rsrc_mgr.c|5 +++--
2 files changed, 6 insertions(+), 5
We should be using resource_size_t and unsigned types correctly, otherwise
we sign extend the flags on a 64bit box, which is not what we want.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/pcmcia/cs_internal.h |6 +++---
drivers/pcmcia/rsrc_mgr.c|5 +++--
2 files changed
less hideously convoluted resource manager that gets used
when the only PCMCIA present is via PCI bridges. In that situation the core
pci layer can do the job perfectly well for us and just needs a bit of
wrapping.
Alan
---
Alan Cox (5):
pcmcia: correct types
pcmcia cis: on an out
The current code displays warnings but then proceeds to try and reference
the data through the PCMCIA window. Instead return 0xff. This prevents bogus
CIS data sending us off into hyperspace.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/pcmcia/cistpl.c |5 -
1 file changed, 4
The requery logic goes off and attempts to read the CIS of empty slots. In
most cases this happens not to do any harm - but not all!
Add the missing check and also a WARN() to catch any other offenders.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/pcmcia/cistpl.c |2 +-
drivers
it to the
wrong thing we only fix up apparently anonymous cards if the driver for them
has been enabled.
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/pcmcia/cistpl.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/pcmcia/cistpl.c b
On a pure PCI platform we don't actually need all the complexity of the
rsrc_nonstatic manager, in fact we can just work directly with the pci
allocators and avoid all the complexity (and code bloat).
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/pcmcia/Kconfig| 12 ++-
drivers
There is no requirement a PCMCIA card has valid CIS data or even a CIS.
The MTD layer correctly handles this but the core PCMCIA code erroneously
refuses to accept the card and prevents the MTD driver from working in
this case.
Tested with an Apple Newton 1MB SRAM card.
Signed-off-by: Alan Cox
There is no requirement a PCMCIA card has valid CIS data or even a CIS.
The MTD layer correctly handles this but the core PCMCIA code erroneously
refuses to accept the card and prevents the MTD driver from working in
this case.
Tested with an Apple Newton 1MB SRAM card.
Signed-off-by: Alan Cox
On Thu, 2014-10-09 at 10:07 +0200, Ricardo Ribalda Delgado wrote:
> Hello Alan
>
> >
> > What is the locking between setting/getting/driver use of the config ?
> > This really needs a lock (termios sem I think is perhaps appropriate
> > given when the values are normally referenced).
>
> I tried
On Thu, 2014-10-09 at 10:07 +0200, Ricardo Ribalda Delgado wrote:
Hello Alan
What is the locking between setting/getting/driver use of the config ?
This really needs a lock (termios sem I think is perhaps appropriate
given when the values are normally referenced).
I tried
On Wed, 2014-10-08 at 22:43 +0200, Ricardo Ribalda Delgado wrote:
> Hello Alan
>
> This patchset adds no extra locking features, if the drivers did not
> implement a locking mechanism (and none did) there is chance of
> conflict.
>
> I can add a call to lock/unlock around
On Wed, 2014-10-08 at 21:57 +0200, Ricardo Ribalda Delgado wrote:
> The following drivers: 8250_core, atmel_serial, max310x, mcf, omap-serial
> and sci16is7xx implement code to handle RS485 ioctls.
>
> +static int uart_get_rs485_config(struct uart_port *port,
> + struct
On Wed, 2014-10-08 at 21:57 +0200, Ricardo Ribalda Delgado wrote:
The following drivers: 8250_core, atmel_serial, max310x, mcf, omap-serial
and sci16is7xx implement code to handle RS485 ioctls.
+static int uart_get_rs485_config(struct uart_port *port,
+ struct
On Wed, 2014-10-08 at 22:43 +0200, Ricardo Ribalda Delgado wrote:
Hello Alan
This patchset adds no extra locking features, if the drivers did not
implement a locking mechanism (and none did) there is chance of
conflict.
I can add a call to lock/unlock around uart_[gs]et_rs485_config. And
On Fri, 12 Sep 2014 13:57:20 +1000
Dave Airlie wrote:
> Got an bug report from someone using a silicon motion video card in
> VGA mode about corruption that they tracked down to 64-bit memory
> operations not being supported by the video card, it appears that we
> probably shouldn't be using >
On Fri, 12 Sep 2014 13:57:20 +1000
Dave Airlie airl...@gmail.com wrote:
Got an bug report from someone using a silicon motion video card in
VGA mode about corruption that they tracked down to 64-bit memory
operations not being supported by the video card, it appears that we
probably shouldn't
accordingly.
>
> Signed-off-by: Matthias Brugger
Reviewed-by: Alan Cox
I'm happy with this version
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/maj
.
Signed-off-by: Matthias Brugger matthias@gmail.com
Reviewed-by: Alan Cox a...@linux.intel.com
I'm happy with this version
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
On Sun, 2014-08-31 at 13:02 -0700, Greg Kroah-Hartman wrote:
> Adding Alan Cox, as he pushed this driver upstream...
It's sort of a false positive. The existing code will work fine.
Arguably all of this should be using the dma_ APIs.
Alan
--
To unsubscribe from this list: send the l
On Sun, 2014-08-31 at 13:02 -0700, Greg Kroah-Hartman wrote:
Adding Alan Cox, as he pushed this driver upstream...
It's sort of a false positive. The existing code will work fine.
Arguably all of this should be using the dma_ APIs.
Alan
--
To unsubscribe from this list: send the line
> + * Some baudrates are not supported by the chip, so we use the next
> + * lower rate supported and update termios c_flag.
I don't see the termios updating being done now ?
> + data->clk = of_clk_get(np, 0);
> + if (IS_ERR(data->clk)) {
> + pr_warn("Can't get
+ * Some baudrates are not supported by the chip, so we use the next
+ * lower rate supported and update termios c_flag.
I don't see the termios updating being done now ?
+ data-clk = of_clk_get(np, 0);
+ if (IS_ERR(data-clk)) {
+ pr_warn(Can't get timer
On Tue, 2014-08-05 at 17:34 +0530, Varka Bhadram wrote:
> On 08/05/2014 05:32 PM, Alan Cox wrote:
> > On Tue, 2014-08-05 at 17:25 +0530, Varka Bhadram wrote:
> >> On 08/05/2014 04:24 PM, Matthias Brugger wrote:
> >>
> >> (...)
> >>
> >>> +#i
On Tue, 2014-08-05 at 17:25 +0530, Varka Bhadram wrote:
> On 08/05/2014 04:24 PM, Matthias Brugger wrote:
>
> (...)
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include "8250.h"
> > +
>
> Better if we have
On Tue, 2014-08-05 at 17:25 +0530, Varka Bhadram wrote:
On 08/05/2014 04:24 PM, Matthias Brugger wrote:
(...)
+#include linux/io.h
+#include linux/module.h
+#include linux/serial_8250.h
+#include linux/of_irq.h
+#include linux/of_platform.h
+#include linux/platform_device.h
On Tue, 2014-08-05 at 17:34 +0530, Varka Bhadram wrote:
On 08/05/2014 05:32 PM, Alan Cox wrote:
On Tue, 2014-08-05 at 17:25 +0530, Varka Bhadram wrote:
On 08/05/2014 04:24 PM, Matthias Brugger wrote:
(...)
+#include linux/io.h
+#include linux/module.h
+#include linux/serial_8250.h
On Sun, 2014-06-22 at 03:29 -0400, James A Shackleford wrote:
> This patch allocates a few pages and performs an ioread8_rep() from the bus
> address, which are then copied to userspace. This fixes the sparse warning:
>
> drivers/staging/goldfish/goldfish_audio.c:136:43: warning: incorrect type
On Sun, 2014-06-22 at 03:29 -0400, James A Shackleford wrote:
This patch allocates a few pages and performs an ioread8_rep() from the bus
address, which are then copied to userspace. This fixes the sparse warning:
drivers/staging/goldfish/goldfish_audio.c:136:43: warning: incorrect type in
> Wow that's junk issued by an Exchange server ... Alan, really ...
Blame evolution. It apparently thinks that if you follow up to your own
email from one address it should randomly switch to another.
> Do you have CONFIG_LBD turned on? That's supposed to let us go up to
> about 16TB before we
The block code has 32bit cleanness problems with the iterator. This
prevents things like partitioning a 32GB volume on a 32bit system.
I hit this with a volume of exactly 32GB in size (easy to duplicate with
virtual machines). Tracing at step by step through the kernel I found
the problem lines
The block code has 32bit cleanness problems with the iterator. This
prevents things like partitioning a 32GB volume on a 32bit system.
I hit this with a volume of exactly 32GB in size (easy to duplicate with
virtual machines). Tracing at step by step through the kernel I found
the problem lines
Wow that's junk issued by an Exchange server ... Alan, really ...
Blame evolution. It apparently thinks that if you follow up to your own
email from one address it should randomly switch to another.
Do you have CONFIG_LBD turned on? That's supposed to let us go up to
about 16TB before we
On Tue, 2014-06-10 at 21:41 +0530, Himangi Saraogi wrote:
> Use kstrdup when the goal of an allocation is copy a string into the
> allocated region.
>
> The Coccinelle semantic patch that makes this change is as follows:
>
> //
> @@
> expression from,to;
> expression flag,E1,E2;
> statement S;
On Tue, 2014-06-10 at 21:41 +0530, Himangi Saraogi wrote:
Use kstrdup when the goal of an allocation is copy a string into the
allocated region.
The Coccinelle semantic patch that makes this change is as follows:
// smpl
@@
expression from,to;
expression flag,E1,E2;
statement S;
@@
On Thu, 5 Jun 2014 14:27:34 +0100
Matt Fleming wrote:
> From: Matt Fleming
>
> free_bootmem_late() expects to only be passed RAM regions that the
> kernel can access, and that have a corresponding 'struct page'. It's
> possible for regions in the EFI memory map to reside in address ranges
>
On Thu, 5 Jun 2014 14:27:34 +0100
Matt Fleming m...@console-pimps.org wrote:
From: Matt Fleming matt.flem...@intel.com
free_bootmem_late() expects to only be passed RAM regions that the
kernel can access, and that have a corresponding 'struct page'. It's
possible for regions in the EFI
> > > 0day kernel testing robot got the below dmesg and the first bad commit is
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> > > staging-next
> > > commit 9b17aeec232a5f0a61ce3952c2e728a0eeddda8b
I don't believe this one is actually a bug. Or rather it's an
0day kernel testing robot got the below dmesg and the first bad commit is
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-next
commit 9b17aeec232a5f0a61ce3952c2e728a0eeddda8b
I don't believe this one is actually a bug. Or rather it's an annoyance
that was
-Wpointer-to-int-cast]
>writel((u32)(u64)pipe, dev->base + PIPE_REG_CHANNEL);
>
> Reported-by: Fengguang Wu
> Cc: Jun Tian
> Cc: Alan Cox
> Signed-off-by: Octavian Purdila
Thanks...
Both
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsub
+ PIPE_REG_CHANNEL);
Reported-by: Fengguang Wu fengguang...@intel.com
Cc: Jun Tian jun.j.t...@intel.com
Cc: Alan Cox a...@linux.intel.com
Signed-off-by: Octavian Purdila octavian.purd...@intel.com
Thanks...
Both
Acked-by: Alan Cox a...@linux.intel.com
--
To unsubscribe from this list: send
On Wed, 7 May 2014 14:42:48 -0700
Andrew Morton wrote:
> On Wed, 7 May 2014 00:33:56 +0530 Raghavendra Ganiga
> wrote:
>
> > This is a patch to add support for
> > maxim dallas rtc ds1343 and ds1344
> >
> > ...
> >
> > +static int ds1343_ioctl(struct device *dev, unsigned int cmd, unsigned
> > It was needed for some of the FRV devices I belive. Please check with
> > David Howells if it's still relevant
>
> This code has been behind (effectively) an "#if 0" check for seven
> years. So either there was no problem to begin with, the problem is
> fixed somewhere else, or no one is
On Wed, 2014-05-07 at 10:41 +0200, Thierry Reding wrote:
> On Fri, May 02, 2014 at 05:22:59PM +0200, Jan Moskyto Matejka wrote:
> > Fixing this warning:
> > drivers/pwm/pwm-lpss.c: In function ‘pwm_lpss_probe_pci’:
> > drivers/pwm/pwm-lpss.c:192:2: warning: passing argument 3 of
> >
On Wed, 2014-05-07 at 10:41 +0200, Thierry Reding wrote:
On Fri, May 02, 2014 at 05:22:59PM +0200, Jan Moskyto Matejka wrote:
Fixing this warning:
drivers/pwm/pwm-lpss.c: In function ‘pwm_lpss_probe_pci’:
drivers/pwm/pwm-lpss.c:192:2: warning: passing argument 3 of
‘pwm_lpss_probe’
It was needed for some of the FRV devices I belive. Please check with
David Howells if it's still relevant
This code has been behind (effectively) an #if 0 check for seven
years. So either there was no problem to begin with, the problem is
fixed somewhere else, or no one is actually using
On Wed, 7 May 2014 14:42:48 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Wed, 7 May 2014 00:33:56 +0530 Raghavendra Ganiga
ravi23gan...@gmail.com wrote:
This is a patch to add support for
maxim dallas rtc ds1343 and ds1344
...
+static int ds1343_ioctl(struct device
On Sun, 2014-05-04 at 13:50 +0200, Paul Bolle wrote:
> Ever since v2.6.19 the code contains a check for CONFIG_NO_ATA_LEGACY.
> But that macro has never been defined. Apparently no one ran into
> problems on platforms that do not support compatibility mode.
It was needed for some of the FRV
On Sun, 2014-05-04 at 13:50 +0200, Paul Bolle wrote:
Ever since v2.6.19 the code contains a check for CONFIG_NO_ATA_LEGACY.
But that macro has never been defined. Apparently no one ran into
problems on platforms that do not support compatibility mode.
It was needed for some of the FRV devices
This is a bug fix that has been lurking in the Google tree but not pushed
upstream.
From: Octavian Purdila
The memory region is already reserved in goldfish_init() during
platform init.
Signed-off-by: Octavian Purdila
Signed-off-by: Jun Tian
Signed-off-by: Alan Cox
---
drivers/platform
jun.j.t...@intel.com
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/platform/goldfish/pdev_bus.c |5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/platform/goldfish/pdev_bus.c
b/drivers/platform/goldfish/pdev_bus.c
index 92cc4cf..4eb2bb3 100644
--- a/drivers/platform
> At some point it was believed to be needed on the 8250 driver. Perhaps
> Alan can comment since the commit message tells us nothing:
Don't remember sorry - I guess at the time someone had ioremap on their
plaform acting as cached. It was a long time ago 8)
--
To unsubscribe from this list: send
At some point it was believed to be needed on the 8250 driver. Perhaps
Alan can comment since the commit message tells us nothing:
Don't remember sorry - I guess at the time someone had ioremap on their
plaform acting as cached. It was a long time ago 8)
--
To unsubscribe from this list: send
On Thu, 2014-03-20 at 11:34 -0500, Felipe Balbi wrote:
> Hi,
>
> when 8250 driver calls uart_write_wakeup(), the tty port lock is already
> taken. hci_ldisc.c's implementation of ->write_wakeup() calls
> tty->ops->write() to actually send the characters, but that call will
> try to acquire the
On Thu, 2014-03-20 at 11:34 -0500, Felipe Balbi wrote:
Hi,
when 8250 driver calls uart_write_wakeup(), the tty port lock is already
taken. hci_ldisc.c's implementation of -write_wakeup() calls
tty-ops-write() to actually send the characters, but that call will
try to acquire the same port
t get as far as
> the maintainers or the mailing lists.
Are people still using gcc variants that get this wrong ?
Fine by me.
Acked-by: Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
or the mailing lists.
Are people still using gcc variants that get this wrong ?
Fine by me.
Acked-by: Alan Cox a...@linux.intel.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
namically
> nowadays, but there is still configuration option for old fixed style.
> Add note to mention that configuration option too.
>
> Cc: Hans Verkuil
> Signed-off-by: Antti Palosaari
> Acked-by: Hans Verkuil
Acked-by: Alan Cox
--
To unsubscribe from this list: send t
configuration option for old fixed style.
Add note to mention that configuration option too.
Cc: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Antti Palosaari cr...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Alan Cox a...@linux.intel.com
--
To unsubscribe from this list
> Either everything is dynamic, or everything follows proper minor
> assignment process.
Ultimately everything should probably be dynamic, but trying to get there
in one step will simply mean we never get there at all.
Alan
--
To unsubscribe from this list: send the line "unsubscribe
Either everything is dynamic, or everything follows proper minor
assignment process.
Ultimately everything should probably be dynamic, but trying to get there
in one step will simply mean we never get there at all.
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Sun, 26 Jan 2014 22:09:07 +0100
Pavel Machek wrote:
> On Thu 2014-01-23 19:36:33, Mark Brown wrote:
> > On Thu, Jan 23, 2014 at 07:47:56PM +0100, Tomasz Figa wrote:
> > > On 23.01.2014 19:40, Mark Brown wrote:
> >
> > > >We'd need to leave it user selectable rather than enabling it for ARM,
On Sun, 26 Jan 2014 22:09:07 +0100
Pavel Machek pa...@ucw.cz wrote:
On Thu 2014-01-23 19:36:33, Mark Brown wrote:
On Thu, Jan 23, 2014 at 07:47:56PM +0100, Tomasz Figa wrote:
On 23.01.2014 19:40, Mark Brown wrote:
We'd need to leave it user selectable rather than enabling it for ARM,
On Fri, 24 Jan 2014 12:03:09 +
Mark Brown wrote:
> On Thu, Jan 23, 2014 at 09:33:21PM +0000, Alan Cox wrote:
> > Mark Brown wrote:
>
> > > I don't see how we can meaningfully test this on a platform - the kernel
> > > would have to be pretty demented to c
On Fri, 24 Jan 2014 12:03:09 +
Mark Brown broo...@kernel.org wrote:
On Thu, Jan 23, 2014 at 09:33:21PM +, Alan Cox wrote:
Mark Brown broo...@kernel.org wrote:
I don't see how we can meaningfully test this on a platform - the kernel
would have to be pretty demented to care, it's
On Thu, 23 Jan 2014 20:05:09 +
Mark Brown wrote:
> On Thu, Jan 23, 2014 at 07:51:44PM +0000, Alan Cox wrote:
>
> > That strikes me as rather more risky. We can propogate it through the
> > drivers as we are sure it is safe to do so on that platform and encourage
801 - 900 of 11107 matches
Mail list logo
