Am 09.09.2012 21:12, schrieb Peter Hüwe:
>> That's why it may break. If you remove the depends on HAS_IOMEM, it will be
>> built on s390 and fail if that codes uses io memory functions. Depending
>> on GENERIC_IO fixes that.
>
> Everything I can select in I2C subsystem compiles fine on s390.
> (us
Hi Jean,
Am Sonntag, 9. September 2012, 20:40:36 schrieb Jean Delvare:
> There is a problem with the mux chip drivers, which then no longer
> depend on HAS_IOMEM.
The selectables on my x86 and UML machine build fine ;)
But you're correct, we should exclude/guard them.
> Also, I think it is about t
> That's why it may break. If you remove the depends on HAS_IOMEM, it will be
> built on s390 and fail if that codes uses io memory functions. Depending
> on GENERIC_IO fixes that.
Everything I can select in I2C subsystem compiles fine on s390.
(using defconfig + menuconfig).
Just compiled it.
Th
Hallo Petter,
On Sun, 9 Sep 2012 14:15:02 +0200, Peter Hüwe wrote:
> I created a patch for your proposed solution, I moved the stub driver to the
> end in order to have only one big if HAS_IOMEM.
There is a problem with the mux chip drivers, which then no longer
depend on HAS_IOMEM. Also, I thin
Am 09.09.2012 17:09, schrieb Joe Perches:
> On Sun, 2012-09-09 at 10:33 +0200, Geert Uytterhoeven wrote:
>> Ping?
>
> Richard? Are you going to pick up this patch?
> It seems sensible.
>
> Geert, I suggest sending it directly to Linus as a fix
> if Richard doesn't respond in a few days.
I'll pi
On Sun, 09 Sep 2012 17:00:54 +0200, Richard Weinberger wrote:
> Geert Uytterhoeven schrieb:
> >s390 has neither of HAS_IOMEM and GENERIC_IO, so it won't break their
> >build.
>
> That's why it may break. If you remove the depends on HAS_IOMEM, it will be
> built on s390 and fail if that codes use
On Sun, 2012-09-09 at 10:33 +0200, Geert Uytterhoeven wrote:
> Ping?
Richard? Are you going to pick up this patch?
It seems sensible.
Geert, I suggest sending it directly to Linus as a fix
if Richard doesn't respond in a few days.
> On Thu, Aug 16, 2012 at 8:15 PM, Geert Uytterhoeven
> wrote:
Geert Uytterhoeven schrieb:
>On Sun, Sep 9, 2012 at 3:27 PM, Richard Weinberger
>wrote:
>>> For my stub driver I don't need any of that, I'd be fine with the
>move of
>>> HAS_IOMEM as proposed by Jean.
>>
>> IMHO you should replace the HAS_IOMEM with GENERIC_IO.
>> Otherwise you may break the
On Sun, Sep 9, 2012 at 3:27 PM, Richard Weinberger wrote:
>> For my stub driver I don't need any of that, I'd be fine with the move of
>> HAS_IOMEM as proposed by Jean.
>
> IMHO you should replace the HAS_IOMEM with GENERIC_IO.
> Otherwise you may break the build on s390.
s390 has neither of HAS_
Am 09.09.2012 15:11, schrieb Peter Hüwe:
Maybe some parts of the I2C sub-system can also just depend on
GENERIC_IO instead of HAS_IOMEM.
An arch has GENERIC_IO=y if it supports everything defined in
generic-asm/io.h which is more than enough for most stub drivers.
>>>
>>> The on
> >> Maybe some parts of the I2C sub-system can also just depend on
> >> GENERIC_IO instead of HAS_IOMEM.
> >> An arch has GENERIC_IO=y if it supports everything defined in
> >> generic-asm/io.h which is more than enough for most stub drivers.
> >
> > The only thing which seems to be missing on UM
Am 09.09.2012 14:52, schrieb Peter Hüwe:
> Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger:
>> UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which
>> is often too coarse grained.
>> To deal with that I've introduced GENERIC_IO some time ago to support MTD
Am 09.09.2012 14:52, schrieb Peter Hüwe:
> Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger:
>> UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which
>> is often too coarse grained.
>> To deal with that I've introduced GENERIC_IO some time ago to support MTD
Am Sonntag, 9. September 2012, 14:23:06 schrieb Richard Weinberger:
> UML does not have IO_MEM but some sub-systems have "depend HAS_IOMEM" which
> is often too coarse grained.
> To deal with that I've introduced GENERIC_IO some time ago to support MTD
> (and nandsim) on UML.
> Maybe some parts of
Hi all,
Thanks for the info. I thought UML was no longer used with all the
virtualization solutions available, but apparently I was wrong.
On Sun, 9 Sep 2012 12:49:03 +0200, Peter Hüwe wrote:
> > That's because they rely on the HAS_IOMEM dependency for the whole
> > subsystem. In fact, I'm surpri
Am 09.09.2012 14:15, schrieb Peter Hüwe:
> Am Sonntag, 9. September 2012, 13:28:38 schrieb Jean Delvare:
>> Thanks for the info. I thought UML was no longer used with all the
>> virtualization solutions available, but apparently I was wrong.
> I guess it's mainly used for sandboxing, testing and de
On Sun, Sep 9, 2012 at 2:15 PM, Peter Hüwe wrote:
>> My bet is that all I2C bus drivers do use I/O or memory mapped
>> operations directly or indirectly, except i2c-stub. So it would
>> probably make more sense, and be a less intrusive change, to move the
>> HAS_IOMEM dependency to drivers/i2c/bus
Am Sonntag, 9. September 2012, 13:28:38 schrieb Jean Delvare:
> Thanks for the info. I thought UML was no longer used with all the
> virtualization solutions available, but apparently I was wrong.
I guess it's mainly used for sandboxing, testing and development ;)
> My bet is that all I2C bus dri
Hi Geert,
> That's because they rely on the HAS_IOMEM dependency for the whole
> subsystem. In fact, I'm surprised you didn't have to add HAS_IOMEM
> dependencies to more drivers.
I changed only the ones which are available in UML.
I now rewrote the patch to remove the global dependency and move i
Ping?
On Thu, Aug 16, 2012 at 8:15 PM, Geert Uytterhoeven
wrote:
> The userspace part of UML uses the asm-offsets.h generator mechanism to
> create definitions for UM_KERN_ that match the in-kernel
> KERN_ constant definitions.
>
> As of commit 04d2c8c83d0e3ac5f78aeede51babb3236200112 ("printk: c
Hi Peter,
On Sun, Sep 9, 2012 at 3:08 AM, Peter Hüwe wrote:
>> > I'm curious if there have ever been any attempts to emulate i2c devices
>> > under uml in order to facilitate driver development by using stub
>> > drivers.
>> I know none.
>
>> If there is a use case, why not. :-)
> Thanks for your
21 matches
Mail list logo
