On Thu, Jan 16, 2014 at 7:01 AM, Sascha Hauer wrote:
> Before we had the PWM framework we used to have a barebone PWM api. The
> HAVE_PWM Kconfig symbol used to be selected by the PWM drivers to specify
> the PWM API is present in the kernel. Since the last legacy driver is gone
> the HAVE_PWM sym
If MODPUBKEY is specified and other than default ./signing_key.x509, use
that key instead of generating one on-the-fly.
Signed-off-by: Eric Miao
Cc: David Howells
Cc: Dan Willemsen
---
kernel/Makefile | 8
1 file changed, 8 insertions(+)
diff --git a/kernel/Makefile b/kernel
Even if MODULE_SIG_FORCE is turned on, it is still useful if module
can export sig_enforce, so user space will know if module signature
is turned on and forced.
Signed-off-by: Eric Miao
Cc: David Howells
Cc: Dan Willemsen
---
kernel/module.c | 8
1 file changed, 8 insertions(+)
diff
On Sat, Jul 6, 2013 at 1:42 PM, Michael Opdenacker
wrote:
> This flag is a NOOP since 2.6.35 and can be removed.
>
> Signed-off-by: Michael Opdenacker
Indeed. Acked-by: Eric Miao
> ---
> arch/arm/mach-pxa/am200epd.c | 3 +--
> arch/arm/mach-pxa/am300epd.c |
IG_OF is not defined.
> If COFNIG_OF is defined, but PWM is not defined in device tree
> configuration file. The device
> can still match the driver is the id_table is matched or name is matched.
> So I covered addtional situation
> 1. PWM is not defined in DT configuration file
iff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index aa4bea7..c8d59a2 100644
> --- a/drivers/pwm/pwm-pxa.c
> +++ b/drivers/pwm/pwm-pxa.c
> @@ -9,6 +9,8 @@
> *
> * 2008-02-13 initial version
> * eric miao
> + * 2013-04-24 add device tree suppo
ao Xie
Looks good to me,
Acked-by: Eric Miao
> ---
> drivers/pwm/pwm-pxa.c | 12 +---
> 1 files changed, 1 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
> index dee6ab55..aa4bea7 100644
> --- a/drivers/pwm/pwm-p
On Mon, May 6, 2013 at 9:29 AM, Chao Xie wrote:
> The PWM driver is not only used by ARCH_PXA but also ARCH_MMP.
>
> Signed-off-by: Chao Xie
Looks good to me.
Acked-by: Eric Miao
> ---
> drivers/pwm/Kconfig |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-
ed-off-by: Andy Shevchenko
>> Reported-by: Mika Westerberg
>> Cc: Eric Miao
>> Cc: Greg Kroah-Hartman
>> ---
>> drivers/base/platform.c |4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/platform.c
ed-off-by: Andy Shevchenko
>> Reported-by: Mika Westerberg
>> Cc: Eric Miao
>> Cc: Greg Kroah-Hartman
>> ---
>> drivers/base/platform.c |4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/platform.c
ondary_pwm? */
> { "pxa25x-pwm", 0 },
> - { "pxa27x-pwm", 0 | HAS_SECONDARY_PWM },
> - { "pxa168-pwm", 1 },
> - { "pxa910-pwm", 1 },
> + { "pxa27x-pwm", HAS_SECONDARY_PWM },
> + { "pxa168-pwm
On Mon, Apr 1, 2013 at 3:32 PM, Axel Lin wrote:
> 2013/4/1 Eric Miao :
>> On Sun, Mar 31, 2013 at 11:04 PM, Axel Lin wrote:
>>> clk_enable/clk_disable maintain an enable_count, clk_prepare and
>>> clk_unprepare
>>> also maintain a prepare_count. These
On Sun, Mar 31, 2013 at 11:04 PM, Axel Lin wrote:
> clk_enable/clk_disable maintain an enable_count, clk_prepare and clk_unprepare
> also maintain a prepare_count. These APIs will do prepare/enable when the
> first
> user calling these APIs, and do disable/unprepare when the corresponding
> coun
On Mon, Apr 1, 2013 at 12:12 AM, Axel Lin wrote:
> The driver_data field was used to store information about PWM_ID_BASE and
> HAS_SECONDARY_PWM. PWM_ID_BASE is not used now after convert to pwm framework.
> This patch stores the pwm_nr in driver_data field to simplify the code.
>
> Signed-off-by:
On Sun, Mar 31, 2013 at 2:45 PM, Viresh Kumar wrote:
> On 31 March 2013 10:54, Eric Miao wrote:
>> On Sun, Mar 31, 2013 at 11:52 AM, Viresh Kumar
>> wrote:
>>> Eric/Haojian,
>>>
>>> On 25 March 2013 15:41, Viresh Kumar wrote:
>>>> This p
On Sun, Mar 31, 2013 at 11:52 AM, Viresh Kumar wrote:
> Eric/Haojian,
>
> On 25 March 2013 15:41, Viresh Kumar wrote:
>> This patch moves cpufreq driver of ARM based pxa3xx platform to
>> drivers/cpufreq.
>>
>> Cc: Eric Miao
Acked-by: Eric Miao
>&g
On Mon, Jan 7, 2013 at 6:44 PM, Mika Westerberg
wrote:
> In addition fix following warnings seen when compiling 64-bit:
>
> drivers/spi/spi-pxa2xx.c: In function ‘map_dma_buffers’:
> drivers/spi/spi-pxa2xx.c:384:7: warning: cast from pointer to integer of
> different size [-Wpointer-to-int-cast]
nd
> eventually lead to a complete removal of struct sys_timer.
>
> Cc: Eric Miao
> Cc: Russell King
> Cc: Haojian Zhuang
> Signed-off-by: Stephen Warren
Acked-by: Eric Miao
> ---
> arch/arm/mach-pxa/time.c | 76
> +++-
On Fri, Oct 5, 2012 at 3:13 AM, Thierry Reding
wrote:
> On Thu, Oct 04, 2012 at 08:48:54PM +0200, Lars-Peter Clausen wrote:
>> On 10/04/2012 08:29 PM, Thierry Reding wrote:
>> > On Thu, Oct 04, 2012 at 05:00:23PM +0200, Lars-Peter Clausen wrote:
>> >> On 10/04/2012 08:06 AM, Thierry Reding wrote:
an just remove the function.
>
> Without this patch, building corgi_defconfig results in:
>
> /home/arnd/linux-arm/arch/arm/mach-pxa/sharpsl_pm.c:693:12: warning:
> 'sharpsl_fatal_check' defined but not used [-Wunused-function]
>
> Signed-off-by: Arnd Bergmann
&
On Fri, Sep 21, 2012 at 3:19 PM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function clk_get() returns ERR_PTR()
> and never returns NULL pointer. The NULL test in the error
> handling should be replaced with IS_ERR().
>
> dpatch engine is used to auto generated this patch.
On Tue, Sep 18, 2012 at 1:56 PM, Haojian Zhuang
wrote:
> On Tue, Sep 18, 2012 at 1:43 PM, Eric Miao wrote:
>> On Mon, Sep 17, 2012 at 6:56 PM, Linus Walleij
>> wrote:
>>> On Fri, Sep 14, 2012 at 4:36 AM, Wei Yongjun wrote:
>>>
>>>> From: Wei Y
//coccinelle.lip6.fr/)
>>
>> Signed-off-by: Wei Yongjun
>
> PXA maintainers: does this look OK?
I seem to have Acked this already in another mail, if that got lost, here
it is:
Acked-by: Eric Miao
>
> Yours,
> Linus Walleij
--
To unsubscribe from this list: send t
On Fri, Sep 14, 2012 at 10:30 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Using for_each_set_bit() to simplify the code.
>
> spatch with a semantic match is used to found this.
> (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Wei Yongjun
Great API, this is g
On Mon, Aug 6, 2012 at 1:56 AM, Daniel Mack wrote:
> On 05.08.2012 18:56, Haojian Zhuang wrote:
>> On Mon, Aug 6, 2012 at 12:22 AM, Daniel Mack wrote:
>>> On 24.07.2012 20:01, Daniel Mack wrote:
On 23.07.2012 18:51, Dmitry Torokhov wrote:
> On Thu, Jul 19, 2012 at 05:36:12PM +0200, Danie
On Fri, Feb 22, 2008 at 12:26 AM, Liam Girdwood
<[EMAIL PROTECTED]> wrote:
> On Thu, 2008-02-21 at 08:41 +, Russell King - ARM Linux wrote:
> > On Wed, Feb 20, 2008 at 05:08:46PM +, Liam Girdwood wrote:
> > > This patch series provides a generic framework to allow device drivers
> > > to
On Jan 31, 2008 3:21 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Wednesday 30 January 2008, Kumar Gala wrote:
> > Was wondering if anyone was looking at the cause of this warning in
> > top of linus's tree (8af03e782cae1e0a0f530ddd22301cdd12cf9dc0)
> >
> > drivers/spi/Kconfig:156:warning: 's
> > From: eric miao <[EMAIL PROTECTED]>
> >
> > This patch adds the generic IRQ support for the PCA9539 on-chip GPIOs.
>
> This one bothers me a bit on some technical grounds. One problem is
> that these chips are not designed for reliable IRQ management, so
On Dec 19, 2007 5:01 PM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Eric,
>
>
> On Wed, 19 Dec 2007 16:45:00 +0800, eric miao wrote:
> > Updated as follows, the driver name is left unchanged, while
> > Kconfig and Documentation are modified so that
> > 1. ma
Updated as follows, the driver name is left unchanged, while
Kconfig and Documentation are modified so that
1. mark it as deprecated
2. exclusive selection of SENSOR_PCA9539 and GPIO_PCA9539
>From c58dc1119355dc94d80763aef9d9bc999abda6df Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PRO
avid,
>
>
> On Mon, 17 Dec 2007 10:09:53 -0800, David Brownell wrote:
> > > Date: Mon, 17 Dec 2007 14:33:27 +0800
> > > From: "eric miao" <[EMAIL PROTECTED]>
> > >
> > > for the following reasons:
> > >
> > > 1. there is cu
[ Updated according to Jean's suggestion, thanks ]
>From 5b4d907da17d57ec168643ebd847278e8d7267f9 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c and related files
for
[updated according to David's suggestion to handle the error
of I2C transfer]
>From c9b78718488dadc702f40789bd532d1f1765d76e Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bi
[ forget about the previous patch, sorry for my carelessness not to
free the chip structure, below is the correct one ]
>From c4be69e8dad28dc75e80b393f9c60f740cca7047 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiol
[ Yup, it's an issue, patch updated as below:]
>From 8de0246423cbbd0c6bb03a20baf61d360930c350 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit r
Jean,
I'd like to postpone the corresponding change to the point that
polling i2c patch is merged.
On Dec 15, 2007 12:16 AM, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Hi Eric,
>
>
> On Mon, 10 Dec 2007 17:37:05 +0800, eric miao wrote:
> > Support for PCA9539 as a GP
>From 0bca662f68e7ffe84f333d7d26df25d846713db2 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Sat, 15 Dec 2007 12:07:26 +0800
Subject: [PATCH] gpiolib: obsolete drivers/i2c/chips/pca9539.c
for the following reasons:
1. there is currently no known users of this drive
>From b45be77acbf592b9c2085ed03ab5f16d780fa8c7 Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:24:36 +0800
Subject: [PATCH] gpiolib: add Generic IRQ support for 16-bit PCA9539
GPIO expander
This patch adds the generic IRQ support for the PCA953
>From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:12 +0800
Subject: [PATCH] gpiolib: basic support for 16-bit PCA9539 GPIO expander
1. use 16-bit register access to simplify the logic, cache OUTP
[updated] support for PCA9539 as a GPIO chip is separated into three patches:
0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander
0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
0003 - gpiolib: obsolete drivers/i2c/chips/pca9539.c
The 2nd one uses workqueue for
I'd like to create another thread in LKML for the updated version, sorry.
On Dec 15, 2007 11:56 AM, eric miao <[EMAIL PROTECTED]> wrote:
> OK,
>
> Here's the updated version, which
> 1. modify the author info but still preserve Ben's credit in the source head
. preserve initial output/direction register settings
Also I'd like to fire another patch to obsolete drivers/i2c/chips/pca9539.c
as everyone agreed.
>From 5ebe07236b99587296cbf603a965d284ceaf Mon Sep 17 00:00:00 2001
From: eric miao <[EMAIL PROTECTED]>
Date: Mon, 10 Dec 2007 17:19:
On Dec 10, 2007 6:14 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 10 December 2007, eric miao wrote:
> > +config GPIO_PCA9539_GENERIC_IRQ
> > +bool " Generic IRQ support for PCA9539"
> > +depends on GPIO_PCA9539=y
>
> Also depends on GENE
.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig | 10 +++-
drivers/gpio/pca9539.c | 184
2 files changed, 193 insertions(+), 1 deletions(-)
diff --git a/drivers/gp
1. use 16-bit register access to simplify the logic, cache OUTPUT
and DIRECTION registers for fast access
2. platform code is required to setup
a) the numbering of GPIO for PCA9539 (base and number)
c) pass "pca9539_platform_data" within "i2c_board_info"
Signed-off-b
Support for PCA9539 as a GPIO chip is separated into two patches:
0001 - gpiolib: basic support for 16-bit PCA9539 GPIO expander
0002 - gpiolib: add Generic IRQ support for 16-bit PCA9539 GPIO expander
the 2nd one uses workqueue for IRQ handling due to the interrupt mode
nature of the i2c-core, t
work with chips with different numbers of GPIOs,
> and to avoid holes in GPIOs number sequences. Those holes can cost a
> lot of unusable irq_desc space for GPIOs that act as IRQs.
>
> Based on a patch from Eric Miao.
>
> # NOT signed-off yet ... purely for comment. It's
IZE(chips); id++) {
- chip = chips[id];
- if (!chip)
- continue;
-
- seq_printf(s, "%sGPIOs %d-%d, %s%s:\n",
- started ? "\n" : "",
- chip->base, chip-&
OK, here's the all-in-one patch based on David's most recent gpiolib fix,
Changes include:
1. use per gpio structure "gpio_desc", thus eliminating the restriction of
ARCH_GPIOS_PER_CHIP, thus making it possible leaving no holes in GPIOs
numbering
Note: the number of GPIOs on different G
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
> > :-)
> >
> > 1. is it possible to use some name other than "so
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.
2. those C++ style comments "//" are not so pleasant...
- eric
On Nov
Y, the IRQ <--> GPIO mapping is another thing I'm concerned about. Other than
that, all the other part of the gpiolib is a great work, actually,
I've been waiting
for this for quite a long time and just don't have time for a hands-on until
recently.
So let's get more feedback on this.
On Nov 14,
On Nov 14, 2007 12:36 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > Subject: [PATCH 5/5] move per GPIO "requested" to "struct gpio_desc"
> >
>
> > struct gpio_desc {
> >
On Nov 14, 2007 12:18 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > Here comes the point of "struct gpio_desc"
> >
> > Subject: [PATCH 3/5] use a per GPIO "struct gpio_desc" and chain
> > &q
On Nov 14, 2007 11:30 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > > > Can we use "per gpio based" structure instead of "per gpio_chip" based
> > > > one,
> > > > just like what
On Nov 14, 2007 11:25 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> >
> > Here comes a bunch of patches to illustrate my idea, some are not related to
> > the point I mentioned, and they are not mature for now :-)
>
Subject: [PATCH 5/5] move per GPIO "requested" to "struct gpio_desc"
---
include/asm-generic/gpio.h | 17 +++-
lib/gpiolib.c | 62 ---
2 files changed, 39 insertions(+), 40 deletions(-)
diff --git a/include/asm-generic/gpio.h b/inc
Here comes the point of "struct gpio_desc"
Subject: [PATCH 3/5] use a per GPIO "struct gpio_desc" and chain
"gpio_chip" to a list
---
include/asm-generic/gpio.h |7 +
lib/gpiolib.c | 64 ++--
2 files changed, 39 insertions(+), 32 del
Subject: [PATCH] move per GPIO "is_out" to "struct gpio_desc"
---
include/asm-generic/gpio.h |4 +---
lib/gpiolib.c | 18 +++---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 783adcf..d
so that requested will always be used, only *requested_str will be used
for DEBUG_FS tracking assistance
Subject: [PATCH 2/5] define gpio_chip.requested_str as a debugfs tracking string
---
include/asm-generic/gpio.h | 11 ++-
lib/gpiolib.c | 34 ++---
Here comes a bunch of patches to illustrate my idea, some are not related to
the point I mentioned, and they are not mature for now :-)
Subject: [PATCH 1/5] add gpio_is_onchip() for commonly used gpio range checking
---
lib/gpiolib.c | 32 ++--
1 files changed, 22 i
On Nov 14, 2007 3:06 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 12 November 2007, eric miao wrote:
> > Hi David,
> >
> > I hope I was not late giving my humble feedback on this framework :-)
> >
> > Can we use "per gpio based" structu
Hi David,
I hope I was not late giving my humble feedback on this framework :-)
Can we use "per gpio based" structure instead of "per gpio_chip" based one,
just like what the generic IRQ layer is doing nowadays? So that
a. you don't have to declare per gpio_chip "can_sleep", "is_out" and
"reques
On Nov 11, 2007 1:08 AM, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 09, 2007 at 05:02:38PM -0800, Andrew Morton ([EMAIL PROTECTED])
> wrote:
> > > @@ -351,6 +351,10 @@ static int ds1wm_probe(struct platform_device *pdev)
> > > goto err0;
> > > }
> > > plat = pdev
Do a sanity check for the "struct ds1wm_platform_data" pointer passed in
by the platform_device, and so to enforce each platform to provide a
valid structure.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
---
drivers/w1/masters/ds1wm.c |4
1 files changed, 4 insertions
All,
I found in recent kernel that dev_() macros will print out duplicate
device name, which is a bit ugly. And this is true at least for platform_device.
The reason is due to dev_printk() printing out both dev_driver_string(dev)
and (dev)->bus_id, the latter is assigned with the same driver
On 10/19/07, Kristoffer Ericson <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> I've been trying to implement proper suspend on my jornada 720 machine. But
> as far as I can see it never reaches
> the sa11x0_suspend code.
>
> I've linked power button event to produce APM_SUSPEND and I can see that it
And if you purpose is only to download that tree, my suggestion is that
some of the git trees are not public like linux-arm so the owner can do
whatever he likes in the tree, and don't ever try to have access to it.
for linux-arm, it will be constantly pulled by Linus, unless you really
want the _
it looks ok, but I have several questions:
1. why should we bind this to platform_device, what if the gpio device
is not actually a "platform_device", say, a I2C device, a SPI device or
even a USB device?
2. I still doubt the benefit of using of a structure for a gpio, isn't a gpio
number not en
69 matches
Mail list logo
