Hi Florian,
Thanks for the info. I have enabled everything I can think of for the
ixp4xx platform:
CONFIG_GENERIC_GPIO=y
CONFIG_INPUT_GPIO_BUTTONS=m
CONFIG_I2C_GPIO=y
CONFIG_GPIO_DEVICE=y
CONFIG_LEDS_GPIO=y
I would think that I would see a /dev/gpio now as I was in 2.6.23 but I
do not, I would
Axel Gembe wrote:
> Imre Kaloz wrote:
>> I share Gregers' view, too.. Also, one central git is a chaotic mess for
>> this,
>> every target would need it's own branch.. Think ddwrt's repo :P
>>
> I dunno how the current situation differs because every target
> effectively *IS* a branch from the
Hi Mark,
There are quite some targets which implement either a GPIO lib or Generic GPIO
compatible API. You can enable the GPIO device driver for these targets, even
though it is not done automatically.
Le Friday 23 May 2008 16:43:49 Mark Kelly, vous avez écrit :
> what is the status of the new
Hey Imre,
Le Friday 23 May 2008 16:13:59 Imre Kaloz, vous avez écrit :
> I share Gregers' view, too.. Also, one central git is a chaotic mess for
> this, every target would need it's own branch.. Think ddwrt's repo :P
John and I had a short discussion about that on irc. Basically, the idea
behin
Gregers Petersen wrote:
> My comment was also a way towards: Ok if this should be done, then it
> needs to be done in an unconfusing manner - with a bit of thought and
> planning towards how such a git repository is to be integrated into what
> is already there ;-)
I totally agree, using git wit
Axel Gembe wrote:
> Imre Kaloz wrote:
>> I share Gregers' view, too.. Also, one central git is a chaotic mess for
>> this,
>> every target would need it's own branch.. Think ddwrt's repo :P
>>
> I dunno how the current situation differs because every target
> effectively *IS* a branch from the
what is the status of the new generic gpio support? In the current
trunk build, I am not seeing the /dev/gpio node being built when the
settings are enabled at least not on IXP4XX (Avila gw2345). I know this
was working in my 2.6.23 builds, but I'm unsure if I've missed a setting
in the new 2.6
Imre Kaloz wrote:
> I share Gregers' view, too.. Also, one central git is a chaotic mess for this,
> every target would need it's own branch.. Think ddwrt's repo :P
>
I dunno how the current situation differs because every target
effectively *IS* a branch from the generic kernel which is a bran
This Makefile patch adds support for the "Privacy Extensions", "IP-in-IPv6
tunnel", "Multiple Routing Tables" and "source address based routing" in the
2.6 Kernel.
Signed-off-by: "Alina Friedrichsen" <[EMAIL PROTECTED]>
---
Index: package/kernel/modules/network.mk
===
On 2008.05.23. 10:38:19 John Crispin <[EMAIL PROTECTED]> wrote:
> on the contrary, i believe it will add transparncy. if someone fels he
> needs to work in the target/ folder, then he should be familiar with
> kernel dev workflows
>
>
>
> Gregers Petersen wrote:
>> Florian Fainelli wrote:
>>> Hi d
on the contrary, i believe it will add transparncy. if someone fels he
needs to work in the target/ folder, then he should be familiar with
kernel dev workflows
Gregers Petersen wrote:
> Florian Fainelli wrote:
>> Hi devs,
>>
>> What do you think of having a Git repository for things we intend
Florian Fainelli wrote:
> Hi devs,
>
> What do you think of having a Git repository for things we intend to push
> mainline, such as updates to RB532, AR7, network drivers ... ?
>
I'm wondering if it might add confusion to things?
--
Gregers Petersen
People-stuff, layer 8 and anthropology
glp
12 matches
Mail list logo
