On Sat, 2008-02-23 at 10:18 -0800, Andrew Morton wrote:
> > Renaming is not an option - "current" is an electronic term for
> which
> > there is no alternative.
>
> amps, milliamps,
Are units of current, not current itself.
> amperage (the latter of which I've always disliked)
Ugh.
--
To uns
On Sun, 2008-02-24 at 09:51 +0100, Pavel Machek wrote:
> And what? You can't measure anything but current in amps, so ambiguity
> is not a problem.
It not is the credible validation of the language English. Thanking you kindly.
-Ian
--
To unsubscribe from this list: send the line &
Hi guys.
This patchset contains support for three toshiba multifunction devices.
This patch adds the core support code for three TMIO based MFDs.
There are no complete datasheets for these chips so their drivers are not
100% complete, however they do work.
0002-Preliminary-support-for-Toshibas
Hi guys.
This patchset contains support for three toshiba multifunction devices.
This adds necessary IRQ and GPIO definitions for use by the e-series
platform support code.
0003-add-IRQ-and-GPIO-definitions-for-eseries.patch
Description: application/mbox
Hi guys.
This patchset contains support for three toshiba multifunction devices.
This patch adds platform support for the TMIO devices used by the various
e-series platforms.
It depends on the previous patch in this series.
0004-add-eseries-platform-support-for-the-TMIO-multifunct.patch
Descri
Hi guys.
This patchset contains support for three toshiba multifunction devices.
This patch introduces some useful library functions that handle common
features in this type of MFD - local memory and IRQ resources.
0001-Reuseable-SOC-core-code-suitable-for-multifunction-c.patch
Description: app
Hi guys.
This patchset contains support for three toshiba multifunction devices.
it introduces a small but useful bit of code as a library for similar
devices, and includes support for these chips on the toshiba e-series
family of handhelds.
please copy me on reply!
-
To unsubscribe from this l
On Wed, 2007-11-21 at 01:04 +0300, Dmitry Baryshkov wrote:
> Just to note, that there is an alternative implementation for at least
> the tc6393 chip devices. Most current version of those patches can be
> found in the OpenEmbedded monotone.
Yes, this is true. The core code in both cases origina
On Wed, 2007-11-21 at 10:23 +0800, eric miao wrote:
> Roughly went through the patch, looks good, here comes the remind, though :-)
>
> 1. is it possible to use some name other than "soc_core", maybe
> "tmio_core" so that other multifunction chips sharing a core base
> will live easier.
It's (soc
On Wed, 2007-11-21 at 12:05 +0800, eric miao wrote:
> On Nov 21, 2007 11:54 AM, ian <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-11-21 at 10:23 +0800, eric miao wrote:
> > > Roughly went through the patch, looks good, here comes the remind, though
> > > :-)
>
On Thu, 2007-11-22 at 00:52 +, Russell King - ARM Linux wrote:
> On Thu, Nov 22, 2007 at 12:34:09AM +0000, ian wrote:
> Unfortunately, this is broken as designed (in fact this whole file is.)
Fix attached below.
> (Not looked at the rest because you really really need to get thi
oples way.
If I get time to work on it in future, I'll let you all know.
-Ian
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 2007-06-20 at 16:08 -0700, Jeremy Fitzhardinge wrote:
arm26 changes acked-by: Ian Molton <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kern
On Sun, 2007-04-15 at 21:57 -0300, Henrique de Moraes Holschuh wrote:
>
> No, that won't help much. IMO, we want the sanest set of standard
> attributes we can get, and weird as it might be, average reporting are
> common properties of battery control firmware on laptops (maybe
> because of SBS,
On Mon, 2007-04-16 at 07:12 +0400, Anton Vorontsov wrote:
> Why? With current battery class we can do whatever everyone needs. No
> need for wrappers.
> Because of your original design, simple batteries are stay simple, and
> no noticing that there is some "complicated" attributes exists at all
On Fri, 2007-05-04 at 01:31 +0400, Anton Vorontsov wrote:
> # cat /sys/class/power\ supply/ac/type
> AC
>
> # cat /sys/class/power\ supply/usb/type
> USB
isnt that a bit redundant?
I'd have thought sys/class/power\ supply/supplyX/type would be better?
-
To unsubscri
On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote:
> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any
> control signaling over the USB bus for power-control purposes),
it might be dumb, but it is useful to know wether the PDA is charging
from usb or mains p
On Thu, 2007-04-26 at 11:10 -0400, Robert P. J. Day wrote:
The below is clearly correct. Consider it...
Acked-by: Ian Molton <[EMAIL PROTECTED]>
> arch/arm/Kconfig |3 ---
> arch/arm26/Kconfig |3 ---
> 2 files changed, 6 deletions(-)
>
> diff --git a/arch/a
On Tue, 2007-05-01 at 09:39 +0100, Ben Dooks wrote:
>
> Wow, platform devices with a new name. I don't see how any of this is
> not handled by platfrom device.
No, not so. That was a criticism levelled at a previous incarnation of
this code which has since been addressed - this is now a convienie
On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote:
> Hi Paul,
> I think your referring to the term "SoC (system-on-chip)" is confusing
> (at least for me). You rather consider companion chips than SoCs.
A 'System' does not imply a CPU. A 'Computer System' would but the word
system itse
On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote:
> If you used ASIC acronym it would be more appropriate and not so
> ambiguous.
Actually, thats not bad. I'd be ok with that is SoC isnt used.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
ponse.
Best Regards,
Ian.
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
someone who has these things handled ;)
--
Ian Kumlien -- http://demius.net || http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On Thu, Nov 29, 2012 at 10:26:21AM +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 12:20:02AM +0100, Ian Kumlien wrote:
> > Hi,
> >
> > Due to unexplained dns problems, I'll be using google plus to post the
> > photo of the bug output.
> &g
On Thu, Nov 29, 2012 at 03:22:20PM +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 01:27:08PM +0100, Ian Kumlien wrote:
> > I think that chrome does traceing all the time as a part of it's
> > sandbox - this is most likely chrome monitoring flash...
>
> Ah, ok
On tor, 2012-11-29 at 20:25 +0100, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 05:24:03PM +0100, Ian Kumlien wrote:
> > > Can you do:
> > >
> > > make arch/x86/kernel/ptrace.lst
> > >
> > > and send me that file, privately is fine to
ests didn't catch it. I'll drop the patch from my tree. Sorry for the
pain.
I am still having to revert this commit :-(
Sorry Stephen - There's a new patch series, that should resolve this,
undergoing review at the moment so that patch should be reverted...
for now.
coming architectures this inverted check seem to be the best solution, since
> it will not require them to change this #if again (unless they are 64bit
> only).
>
> Signed-off-by: Helge Deller
> CC: James Bottomley
> CC: Catalin Marinas
> CC: Rolf Eike Beer
> CC: H.
gned-off-by: Claudiu Ghioc
Signed-off-by: Ian Kent
---
fs/autofs4/root.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c
index 9bd1625..085da86 100644
--- a/fs/autofs4/root.c
+++ b/fs/autofs4/root.c
@@ -408,7 +408,7 @@ done:
re
ned-off-by: Ian Kent
Cc: sta...@vger.kernel.org
---
fs/autofs4/expire.c |9 -
1 file changed, 9 deletions(-)
diff --git a/fs/autofs4/expire.c b/fs/autofs4/expire.c
index 01443ce..13ddec9 100644
--- a/fs/autofs4/expire.c
+++ b/fs/autofs4/expire.c
@@ -61,15 +61,6 @@ static int autofs4_
ct pci_device_id *ent)
{
/* could use a variant of comedi_pci_auto_config() here */
return comedi_auto_config(&pdev->dev, &foobar_comedi_driver,
ent->driver_data);
}
static struct pci_driver foobar_pci_driver = {
.name = &quo
On 2013-01-30 11:04, Ian Abbott wrote:
static int foobar_auto_attach(struct comedi_device *dev,
unsigned long context_bn)
{
struct pci_dev *pcidev = comedi_to_pci_dev(dev);
struct foobar_board *thisboard = &foobar_boards[bn_foo];
Oops, I m
ed by user space.
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordom
On 2013-01-30 17:54, H Hartley Sweeten wrote:
On Wednesday, January 30, 2013 4:04 AM, Ian Abbott wrote:
Here's some code to illustrate what I'm on about in the above description:
struct foobar_board {
const char *name;
unsigned int ai_chans;
unsigned int ai_bi
patch to do the exact opposite
previously, but I've no problem doing it this way if it saves some code.
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
--
To unsubscribe from this list: send the line "unsubscribe
On 2013/01/24 09:30 PM, Peter Huewe wrote:
> Am Donnerstag, 24. Januar 2013, 11:02:35 schrieb Ian Abbott:
>> On 2013-01-22 23:03, Peter Huewe wrote:
>>> Since comedi_pci_auto_unconfig cannot be inlined anymore after
>>>
>>> staging/comedi: Use c
Hi all,
I have a atl1c networking card in my laptop - it's not connected since i
use wifi instead.
After a while of uptime it seems like it goes haywire, tools are
currently reporting data transfers of ~9GB/s
ifconfig eth0
eth0: flags=4099 mtu 1500
ether 48:5b:39:5e:b0:4b txqueuelen 1
From: Graeme Gregory
Number of voltages for SMPS regulators was off by one.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
Acked-by: Laxman Dewangan
---
drivers/regulator/palmas-regulator.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator
palmas_read_product_id_and_revs used by palmas_i2c_probe to get
the device id, design and software revisions
id field of pamas struct renamed to device_id
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/mfd/palmas.c | 88
h (and the EXPERIMENTAL) makes sense.
> >
> > So could you respin it please with the text removed as well - and I will
> > queue it up in the branch that carries the PVH feature?
>
> We also have the same flag on Xen ARM, and the reason is that the ABI is
> not stable yet. As soon as it is (I think soon
is_palmas_charger checks for the presence of charging
functionality in the device
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
include/linux/mfd/palmas.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd
this patch depenfs on [PATCH] mfd: palmas: is_palmas_charger needed by multiple
drivers
Palmas charger has 16 GPIOs
add palmas_gpio_[read|write|update] api to take account
second bank of GPIOs
Signed-off-by: Ian Lartey
Signed-off-by: Graeme Gregory
---
drivers/gpio/gpio-palmas.c | 73
On 26/02/13 13:58, Laxman Dewangan wrote:
On Tuesday 26 February 2013 06:51 PM, Ian Lartey wrote:
this patch depenfs on [PATCH] mfd: palmas: is_palmas_charger needed by
multiple drivers
Palmas charger has 16 GPIOs
add palmas_gpio_[read|write|update] api to take account
second bank of GPIOs
is_palmas_charger checks for the presence of charging
functionality in the device
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
Acked-by: Laxman Dewangan
---
include/linux/mfd/palmas.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/mfd
this patch depends on [PATCH] mfd: palmas: is_palmas_charger needed by multiple
drivers
Palmas charger has 16 GPIOs
add palmas_gpio_[read|write|update] api to take account
second bank of GPIOs
Signed-off-by: Ian Lartey
Signed-off-by: Graeme Gregory
---
drivers/gpio/gpio-palmas.c | 75
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/leds/leds-palmas.c | 574
Add the Kconfig and Makefile for the Palmas LED driver.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/leds/Kconfig |9 +
drivers/leds/Makefile |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds
Add the Kconfig and MAkefile for the Palmas Watchdog driver
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/watchdog/Kconfig |7 +++
drivers/watchdog/Makefile |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/watchdog/Kconfig b
From: Graeme Gregory
Add support for the Palmas watchdog timer which has a timeout configurable
from 1s to 128s.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/watchdog/palmas_wdt.c | 291 +
1 files changed, 291 insertions(+), 0
On 27/02/13 18:38, Stephen Warren wrote:
On 02/27/2013 11:36 AM, Ian Lartey wrote:
From: Graeme Gregory
Add support for the Palmas watchdog timer which has a timeout configurable
from 1s to 128s.
diff --git a/drivers/watchdog/palmas_wdt.c b/drivers/watchdog/palmas_wdt.c
+static struct
On 27/02/13 20:36, Stephen Warren wrote:
On 02/27/2013 01:17 PM, Ian Lartey wrote:
On 27/02/13 18:38, Stephen Warren wrote:
On 02/27/2013 11:36 AM, Ian Lartey wrote:
From: Graeme Gregory
Add support for the Palmas watchdog timer which has a timeout
configurable
from 1s to 128s.
diff
On 28/02/13 01:12, Jingoo Han wrote:
On Wednesday, February 27, 2013 10:13 PM, Ian Lartey wrote:
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.
Hi Ian
On 28/02/13 11:20, Ian Lartey wrote:
On 28/02/13 01:12, Jingoo Han wrote:
On Wednesday, February 27, 2013 10:13 PM, Ian Lartey wrote:
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the
On 28/02/13 05:44, Laxman Dewangan wrote:
On Wednesday 27 February 2013 06:43 PM, Ian Lartey wrote:
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.
Signed-off
On 28/02/13 11:52, Ian Lartey wrote:
On 28/02/13 05:44, Laxman Dewangan wrote:
On Wednesday 27 February 2013 06:43 PM, Ian Lartey wrote:
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/leds/leds-palmas.c | 560
Add the Kconfig and Makefile for the Palmas LED driver.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/leds/Kconfig |9 +
drivers/leds/Makefile |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds
On 28/02/13 18:36, Stephen Warren wrote:
On 02/28/2013 08:21 AM, Ian Lartey wrote:
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.
+static struct
xenvif_connect() (which normally would be done on the path
> coming through xenvif_disconnect()).
Perhaps Andrew was looking at the tree before "xen-netback: correctly
return errors from netbk_count_requests()" which fixed a different case
of a double put which may have appeared to be fixed
ect()).
A few people have made this mistake already, perhaps this helps make it
more obvious what is going on...
8<
>From 7b93077e2cda5881b594d9c7e733e617df87d7c0 Mon Sep 17 00:00:00 2001
From: Ian Campbell
Date: Tue, 19 Feb 2013 10:46:12 +
Subject
x86.
Since this is an ABI change on ARM I hope we can get this in for the 3.9
merge window. I have deferred the other changes which I previously
posted along side this since they are not so critical.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell
Cc: Jan Beulich
Cc: Keir (Xen.org)
Cc: Tim Deegan
Cc: Stefano Stabellini
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell
Cc: Jan Beulich
Cc: Keir (Xen.org)
Cc: Tim Deegan
Cc: Stefano Stabellini
Cc: Konrad Rzeszutek Wilk
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de
ng
> > > attributes: MT_MEMORY.
> >
> > Do you want to push this to Linus yourself or should I just include it
> > in my 'for-39' tree?
> >
> > Do you have other patches for 3.9?
>
> Ian has two patches ("linux: public interface changes fo
On Tue, 2013-02-19 at 17:11 +, Stefano Stabellini wrote:
> On Tue, 19 Feb 2013, Ian Campbell wrote:
> > On ARM we want these to be the same size on 32- and 64-bit.
> >
> > This is an ABI change on ARM. X86 does not change.
> >
> > Signed-off-by: Ian Camp
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell
Cc: Jan Beulich
Cc: Keir (Xen.org)
Cc: Tim Deegan
Cc: Stefano Stabellini
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
Cc: Konrad
On Tue, 2013-02-19 at 17:26 +, Tim Deegan wrote:
> At 17:17 + on 19 Feb (1361294248), Ian Campbell wrote:
> > On Tue, 2013-02-19 at 17:11 +, Stefano Stabellini wrote:
> > > On Tue, 19 Feb 2013, Ian Campbell wrote:
> > > > +/*
> > > > + * We can
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell
Cc: Jan Beulich
Cc: Keir (Xen.org)
Cc: Tim Deegan
Cc: Stefano Stabellini
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
Cc: Konrad
On Wed, 2013-02-20 at 03:09 +, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 09:07:27PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 19, 2013 at 05:29:11PM +, Ian Campbell wrote:
> > > On ARM we want these to be the same size on 32- and 64-bit.
> >
On Tue, 2013-02-19 at 18:06 +, David Miller wrote:
> From: Ian Campbell
> Date: Tue, 19 Feb 2013 08:58:44 +
>
> > On Tue, 2013-02-19 at 08:03 +, Jan Beulich wrote:
> >> >>> On 19.02.13 at 06:53, David Miller wrote:
> >> > From: Andrew
s ioremap on x86 (no behavioral changes).
> On ARM it explicitly calls __arm_ioremap with the right caching
> attributes: MT_MEMORY.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Ian Campbell
If you were respinning for any reason I might suggest
s/xen_remap/xen_map_shared/ or someth
On ARM we want these to be the same size on 32- and 64-bit.
This is an ABI change on ARM. X86 does not change.
Signed-off-by: Ian Campbell
Cc: Jan Beulich
Cc: Keir (Xen.org)
Cc: Tim Deegan
Cc: Stefano Stabellini
Cc: linux-arm-ker...@lists.infradead.org
Cc: xen-de...@lists.xen.org
Cc: Konrad
On Tue, 2013-02-19 at 14:49 +, Ian Campbell wrote:
> On ARM we want these to be the same size on 32- and 64-bit.
>
> This is an ABI change on ARM. X86 does not change.
>
> Signed-off-by: Ian Campbell
> Cc: Jan Beulich
> Cc: Keir (Xen.org)
Are you guys (un)happy with
uptible()
instead of msleep_interruptible().
Signed-off-by: Ian Abbott
---
Documentation/timers/timers-howto.txt | 11 +--
include/linux/delay.h | 2 ++
kernel/timer.c| 32 +++-
3 files changed, 38 insertions(+), 7 deletions(-)
diff -
From: Graeme Gregory
Number of voltages for SMPS regulators was off by one.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian Lartey
---
drivers/regulator/palmas-regulator.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b
From: Graeme Gregory
Read the chip varient and the OTP information from the chip and display
this on probe to aid in debugging of issues.
Older palmas chips do not have the USB_ID programmed and will therefore
return 0x for this field.
Signed-off-by: Graeme Gregory
Signed-off-by: Ian
On Thu, 2013-02-21 at 18:43 +, Keir Fraser wrote:
> On 21/02/2013 17:16, "Ian Campbell" wrote:
>
> > On Tue, 2013-02-19 at 14:49 +, Ian Campbell wrote:
> >> On ARM we want these to be the same size on 32- and 64-bit.
> >>
> >>
On Fri, 2013-02-22 at 08:12 +, Jan Beulich wrote:
> >>> On 21.02.13 at 18:16, Ian Campbell wrote:
> > On Tue, 2013-02-19 at 14:49 +, Ian Campbell wrote:
> >> On ARM we want these to be the same size on 32- and 64-bit.
> >>
> >> This
On Fri, 2013-02-22 at 08:48 +, Jan Beulich wrote:
> >>> On 22.02.13 at 09:28, Ian Campbell wrote:
> > On Fri, 2013-02-22 at 08:12 +, Jan Beulich wrote:
> >> >>> On 21.02.13 at 18:16, Ian Campbell wrote:
> >> > On Tue, 2013-02-19 at 14:49 +
On 2013-02-22 06:07, Kumar Amit Mehta wrote:
This patch fixes an instance of DMA buffer on stack(being passed to
usb_control_msg)for the USB-DUXsigma Board driver. Found using smatch.
Looks good here too.
Reviewed-by: Ian Abbott
Would you mind doing the same for usbdux.c and usbduxfast.c
On 2013-02-22 14:26, Kumar amit mehta wrote:
On Fri, Feb 22, 2013 at 10:02:44AM +, Ian Abbott wrote:
On 2013-02-22 06:07, Kumar Amit Mehta wrote:
This patch fixes an instance of DMA buffer on stack(being passed to
usb_control_msg)for the USB-DUXsigma Board driver. Found using smatch
On 22/02/13 10:30, Laxman Dewangan wrote:
On Friday 22 February 2013 06:22 AM, Ian Lartey wrote:
From: Graeme Gregory
Read the chip varient and the OTP information from the chip and display
this on probe to aid in debugging of issues.
+/* Read varient info from the device
or a bit before forwarding to stable
which is likely why they aren't there yet
http://marc.info/?l=xen-devel&m=136029801624783&w=2
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On 12/03/13 18:57, Bryan Wu wrote:
On Thu, Feb 28, 2013 at 7:21 AM, Ian Lartey wrote:
The Palmas familly of chips has LED support. This is not always muxed
to output pins so depending on the setting of the mux this driver
will create the appropriate LED class devices.
Signed-off-by: Graeme
On 13/03/13 14:15, Linus Walleij wrote:
Sorry for slow replies :-(
On Thu, Mar 7, 2013 at 2:17 PM, Ian Lartey wrote:
+static int palmas_gpio_read(struct palmas *palmas, unsigned int reg,
+ int gpio, unsigned int *dest)
I don't like "int gpio" here, please
ptr = ni_boards + board;
- boardtype = comedi_board(dev)
+ boardtype = comedi_board(dev);
printk(" %s", boardtype->name);
dev->board_name = boardtype->name;
Ironically, that was introduced by a patch titled "staging: comedi:
ni_atmio: fix buil
/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB
Signed-off-by: Ian Chen
Reviewed-by: Namjae Jeon
Acked-by: Jaehoon Chung
Reviewed-by: Linus Walleij
---
drivers/mmc/card/block.c | 24 +++-
include/linux/mmc/card.h |1 +
2 files changed, 24 insertions(+), 1 deletions
/21pTYfTsCkB#111398485184813224730/posts/21pTYfTsCkB
Signed-off-by: Ian Chen
Reviewed-by: Namjae Jeon
Acked-by: Jaehoon Chung
Reviewed-by: Linus Walleij
---
drivers/mmc/card/block.c | 24 +++-
include/linux/mmc/card.h |1 +
2 files changed, 24 insertions(+), 1 deletions
;
SECURE option, this issue might cause damage.
Therefore, we skip secure for these known devices.
Regards,
Ian
-Original Message-
From: Chris Ball [mailto:c...@laptop.org]
Sent: Wednesday, August 29, 2012 7:27 PM
Hi,
On Wed, Aug 29 2012, IAN CHEN wrote:
> For several MoviNAND, the
so be called by udf_direct_IO().
Also change the whitespace in udf_aops and udf_adinicb_aops to make them
a bit neater.
Signed-off-by: Ian Abbott
---
v2: Rework error handling in udf_direct_IO to avoid calling deprecated
vmtruncate().
v3: Rebased to next-20120904.
---
fs/u
o use that for UDF announcements etc. so people caring
about UDF can watch there and don't have to read high-volume LKML).
Oops, sorry about the misspelling. Also, I've noted the linux-fsdevel
for future (I was just following what it said in MAINTAINERS).
On Tue 04-09-12 10:49:39, Ia
Some rbtree documentation fixes/changes. After applying these changes,
the rb_entry() macro only gets a single mention in the document to say
it does the same thing as container_of().
1) Documentation/rbtree.txt: Fix possible typo in example
2) Documentation/rbtree.txt: Remove bogus description o
a
patch by Wang Tinggong back in May/June 2009. However, the example code
uses rb_entry() to access the containing structure whereas the preceding
paragraph (now) only mentions container_of(), so change the example to
match the preceding text.
Signed-off-by: Ian Abbott
---
Documentation
The example code for rb_erase() usage has a function call to mysearch().
Presumably this ought to be my_search() to match the example code
earlier in the document.
Signed-off-by: Ian Abbott
---
Documentation/rbtree.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Mention that rb_entry() can be used as a synonym for the standard
container_of() macro.
Signed-off-by: Ian Abbott
---
Documentation/rbtree.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt
index 47a8cb5..55008c3 100644
On 2012-09-04 16:11, Ian Abbott wrote:
On 2012-09-04 15:39, Jan Kara wrote:
On Tue 04-09-12 10:49:39, Ian Abbott wrote:
Add support for the O_DIRECT flag. There are two cases to deal with:
Out of curiosity, do you have a use for this feature or is it mostly
academic interest?
I&#
oes CODING_STYLE say that it is forbidden to just write 0.
Ian.
--
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/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Ian Jackson writes ("Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile
warnings when using plain integer instead of NULL pointer."):
> Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH 09/10] xen/swiotlb: Fix
> compile warnings when using plain integer instead of NULL
Ian Jackson writes ("Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile
warnings when using plain integer instead of NULL pointer."):
> Oh wait this is Linux kernel code, not in Xen? Still,
> Documentation/CodingStyle doesn't say that NULL is required.
Someone on irc fo
t_table.h.html#Enum_grant_status
I notice the specific wording of the error msg is different here too.
It'd probably be best to use the same wording as the Xen definition, so
all OSes end up with the same name for the same condition (else bug
reports will be confusing).
Ian.
--
To unsubscribe f
1 - 100 of 4143 matches
Mail list logo
