ydell wrote:
> >> > > The one SA1110 machine:
> >> > >
> >> > > collie Sharp SL-5500 (Collie) PDA (SA-1110)
> >> > >
> >> > I do test collie.
>
> Adding Linus Walleij and Stefan Lehner to Cc, as they were
>
On Thu, May 19, 2022 at 4:23 PM Icenowy Zheng wrote:
> 在 2020-11-18星期三的 00:39 +0100，Linus Walleij写道：
> > It was brought to my attention that this bug from 2018 was
> > still unresolved: 32 bit emulators like QEMU were given
> > 64 bit hashes when running 32 bit emulat
/bugzilla.kernel.org/show_bug.cgi?id=205957
Signed-off-by: Linus Walleij
---
ChangeLog v3 RESEND 1-> v4:
- Update the example in the commit message to a read/modify/write
version.
- Notice that Yonggang Luo sees the sema problem on i386 binaries
as we see on ARM 32bit binaries.
ChangeLo
would ask the QEMU people how a user program would expect
the flag to behave.
Yours,
Linus Walleij
Cc: Andy Lutomirski
Suggested-by: Theodore Ts'o
Link: https://bugs.launchpad.net/qemu/+bug/1805913
Link: https://lore.kernel.org/lkml/87bm56vqg4@mid.deneb.enyo.de/
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205957
Signed-off-by: Linus Walleij
---
ChangeLog v3->v3 RESEN
Cc: Andy Lutomirski
Suggested-by: Theodore Ts'o
Link: https://bugs.launchpad.net/qemu/+bug/1805913
Link: https://lore.kernel.org/lkml/87bm56vqg4@mid.deneb.enyo.de/
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205957
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Realiz
On Sun, Jul 19, 2020 at 2:34 PM Linus Walleij wrote:
> On Mon, Jul 6, 2020 at 10:54 AM Linus Walleij
> wrote:
>
> > Ted, can you merge this patch?
> >
> > It seems QEMU is happy and AFICT it uses the approach you want :)
>
> Gentle ping!
Special merge-windo
On Mon, Jul 6, 2020 at 10:54 AM Linus Walleij wrote:
> Ted, can you merge this patch?
>
> It seems QEMU is happy and AFICT it uses the approach you want :)
Gentle ping!
Yours,
Linus Walleij
On Tue, Jun 23, 2020 at 12:08 PM Peter Maydell wrote:
> On Fri, 29 May 2020 at 08:22, Linus Walleij wrote:
> >
> > It was brought to my attention that this bug from 2018 was
> > still unresolved: 32 bit emulators like QEMU were given
> > 64 bit hashes when running
Cc: Andy Lutomirski
Suggested-by: Theodore Ts'o
Link: https://bugs.launchpad.net/qemu/+bug/1805913
Link: https://lore.kernel.org/lkml/87bm56vqg4@mid.deneb.enyo.de/
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205957
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Use a ne
o be especially upset, I think I just accept this
heuristic.
It is pretty clearly cut I think, and fits very well with the
aggregator use case, which is an important one.
Yours,
Linus Walleij
Hi Geert,
I have queued this v7 patch set in an immutable branch for testing and also
merged to my "devel" branch for testing.
If all goes well it also hits linux-next soon.
Yours,
Linus Walleij
tomirski
Suggested-by: Theodore Ts'o
Link: https://bugs.launchpad.net/qemu/+bug/1805913
Link: https://lore.kernel.org/lkml/87bm56vqg4@mid.deneb.enyo.de/
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205957
Signed-off-by: Linus Walleij
---
fs/fcntl.c | 4
inc
e the existing gpiod_set_debounce() helper as a wrapper around
> gpiod_set_config(), to avoid duplication.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v6:
> - New.
Patch applied in preparation for the next kernel cycle
so we get Geert's patch stack down.
Yours,
Linus Walleij
On Fri, Mar 27, 2020 at 9:45 AM Geert Uytterhoeven wrote:
> On Thu, Mar 26, 2020 at 10:26 PM Linus Walleij
> wrote:
> > On Tue, Mar 24, 2020 at 2:57 PM Geert Uytterhoeven
> > wrote:
> > > The GPIO Aggregator will need a method to forward a .set_config() call
&
at I tried to apply) byt Yue's cleanup patch
commit d18fddff061d2796525e6d4a958cb3d30aed8efd
"gpiolib: Remove duplicated function gpio_do_set_config()"
makes none of them apply :/
Yours,
Linus Walleij
.
I suppose we need to document that the line name look-up
will be on a first-come-first-served basis: whatever line
we find first with this name is what you will get a reference
to, no matter what chip it is on, and it is possible albeit
not recommended that some other chip has a line with the
same name.
Yours,
Linus Walleij
be nice, too.
I simply applied this patch for v5.7 in the GPIO tree since I am the
maintainer of this platform, and I might want to change stuff around
Integrator next cycle so it's good to have this covered.
Yours,
Linus Walleij
ng a personality flag/number.
>
> Linus, do you have what you need to do a respin of the patch?
Absolutely, I'm a bit occupied this week but I will try to get to it
early next week!
Thanks a lot for the directions here, it's highly valuable.
Yours,
Linus Walleij
On Thu, Mar 19, 2020 at 4:25 PM Peter Maydell wrote:
> On Thu, 19 Mar 2020 at 15:13, Linus Walleij wrote:
> > On Tue, Mar 17, 2020 at 12:58 PM Peter Maydell
> > wrote:
> > > What in particular does this personality setting affect?
> > > My copy of the
e QEMU
packages...
The problem still stands that userspace need to somehow
inform kernelspace that 32bit is going on, and this was the
best I could think of.
Yours,
Linus Walleij
On Tue, Mar 17, 2020 at 12:58 PM Peter Maydell wrote:
> On Tue, 17 Mar 2020 at 11:31, Linus Walleij wrote:
> >
> > It was brought to my attention that this bug from 2018 was
> > still unresolved: 32 bit emulators like QEMU were given
> > 64 bit hashes when running
rogram can set the flag, any process can.
Yours,
Linus Walleij
ps://bugzilla.kernel.org/show_bug.cgi?id=205957
Signed-off-by: Linus Walleij
---
fs/ext4/dir.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c
index 9aa1f75409b0..3faf9edf3e92 100644
--- a/fs/ext4/dir.c
+++ b/fs/ext4/dir.c
@@ -27,6 +27,7 @@
#include
#
of things like probe order which
can be random, or because someone compiled a
kernel with a new driver for a gpiochip that wasn't
detected before. This recently happened to Raspberry Pi,
that added gpio driver for "firmware GPIOs" (IIRC).
The label on the chip is going to be more stable
I think, so it is better to use that.
This should also rid the need to include "gpiolib.h"
which makes me nervous.
Yours,
Linus Walleij
he device name in these
tables and not just labels.
(Possibly again I will realize it...)
Yours,
Linus Walleij
d help a lot if the
commit message
would state the technical reason to why we need to do this change,
like what it is that you want to do and why you cannot do it without
this change.
Yours,
Linus Walleij
adding a
> GPIO_INVERTED flag.
>
> Shall I rip that out, incorporate review comments, and report?
Don't know, if it blocks progress I guess the diplomatic solution is to
do that, divide and conquer. But review is a social process so I don't really
know the right strategy.
Yours,
Linus Walleij
Sorry for slowness... christmas.
On Thu, Dec 12, 2019 at 4:24 PM Geert Uytterhoeven wrote:
> On Thu, Dec 12, 2019 at 3:34 PM Linus Walleij
> wrote:
> > > + This can serve the following purposes:
> > > + 1. Assign a collection of GPIOs t
On Thu, Dec 12, 2019 at 3:48 PM Geert Uytterhoeven wrote:
> On Thu, Dec 12, 2019 at 3:42 PM Linus Walleij
> wrote:
> > On Wed, Nov 27, 2019 at 9:43 AM Geert Uytterhoeven
> > wrote:
> > > +The GPIO Aggregator allows access control for individual GPIOs, by
&g
ign guidelines for
these machines so that they can cleanly tear down aggregators
previously created by the crashed VM?
Yours,
Linus Walleij
On Thu, Dec 12, 2019 at 2:33 PM Geert Uytterhoeven wrote:
> On Thu, Dec 12, 2019 at 2:20 PM Linus Walleij
> wrote:
> > On Wed, Nov 27, 2019 at 9:43 AM Geert Uytterhoeven
> > wrote:
> > > Currently GPIO controllers can only be referred to by label in GPIO
> >
the way that the .gpio_fwd_set_config() is coded
it looks like you can just unconditionally assign it and
only check the cansleep condition in this loop.
> +}
> +
> +
> + /*
> +* Common GPIO Aggregator/Repeater platform device
> +*/
> +
Nitpick: weird and excess spacing again.
> + for (i = 0; i < n; i++) {
> + descs[i] = devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
> + if (IS_ERR(descs[i]))
> + return PTR_ERR(descs[i]);
> + }
If this succeeds none of the obtained gpio_desc:s can be
invalid.
Yours,
Linus Walleij
y".
But I'm not entirely convinced about reusing the existing
struct gpio_lookup for this.
What about constructing a new lookup struct specifically for this?
I understand it is more work, but will that not be more
maintainable and readable?
Yours,
Linus Walleij
ata)
{
const char *name = data;
if (!strcmp(chip->label, name))
return 0;
return !strcmp(dev_name(>gpiodev->dev), name);
}
We should I guess also add some kerneldoc to say we first
match on the label and second on dev_name().
Yours,
Linus Walleij
gt; - New.
This is a good patch on its own merits so I have applied
this with the ACKs. (Haven't looked at the rest yet...)
Yours,
Linus Walleij
inky/)
I'm looping in my friends at Google for this discussion.
They need a virtualized gpio_chip for their Android emulator,
and their current approach for other devices has been around
using virtio in most cases and an emulated AC97 for the
audio case as far as I remember.
It would be great to have their input on this so we can create a
virtualization/aggregate that works for all.
Please include ade...@google.com on future postings of this!
Yours,
Linus Walleij
On Mon, Aug 5, 2019 at 12:21 PM Marc Zyngier wrote:
> On 01/08/2019 09:41, Linus Walleij wrote:
> > I would even go so far as to call it "gpio-virtualization" or
> > "gpio-virtualized" rather than "gpio-virtual" so it is clear what the
> &
orward way with this
I see it quickly becoming a very useful tool for industrial automation
where you want to run each control system in isolation and just
respawn the virtual machine if something goes wrong.
Since this might be very popular we need some scrutiny but the
concept as a whole is very appetizing!
Yours,
Linus Walleij
On Tue, Feb 27, 2018 at 6:26 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 27 February 2018 at 10:48, Linus Walleij <linus.wall...@linaro.org> wrote:
>> This series adds proper display bridge/connector emulation
>> for the Versatile Express, implementing a s
l the time but in the actual component it only
appears once activated inside the SiI9022, so ideally it should
be added and removed to the bus by the SiI9022. However for this
purpose it works fine to just have it around.
Cc: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Linus Wal
, but with the Versatile I2C it surely
does not work.
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
hw/i2c/i2c-ddc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/i2c/i2c-ddc.c b/hw/i2c/i2c-ddc.c
index
cludes two refactorings from Corey and a
minor bug fix for the i2c-ddc so that everything is smoothly
integrated.
Corey Minyard (2):
i2c: Fix some brace style issues
i2c: Move the bus class to i2c.h
Linus Walleij (3):
hw/i2c-ddc: Do not fail writes
hw/sii9022: Add support for Silicon Image SII
the QEMU EDID to the emulated
platform.
Cc: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
ChangeLog v1->v2:
- Update license to GPLv2 or later + SPDX identifier
- Instantiate the DDC I2C as part of the class realization so
we do
From: Corey Minyard <cminy...@mvista.com>
Signed-off-by: Corey Minyard <cminy...@mvista.com>
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
hw/i2c/core.c| 3 +--
include/hw/i2c/i2c.h | 6 ++
From: Corey Minyard <cminy...@mvista.com>
Some devices need access to it.
Signed-off-by: Corey Minyard <cminy...@mvista.com>
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
hw/i2c/core.c| 17 -
On Tue, Feb 27, 2018 at 11:09 AM, Peter Maydell
<peter.mayd...@linaro.org> wrote:
> On 27 February 2018 at 07:41, Linus Walleij <linus.wall...@linaro.org> wrote:
>> On Sat, Feb 17, 2018 at 7:32 PM, Philippe Mathieu-Daudé <f4...@amsat.org>
>> wrote:
>>
, ## __VA_ARGS__); \
>> +} \
>> +} while (0)
>
> Can you replace DPRINTF() by trace events?
Absolutely but which ones?
I do not feel senior enough to also invent new trace events
for displays or I2C devices...
Yours,
Linus Walleij
On Mon, Feb 19, 2018 at 4:20 PM, <miny...@acm.org> wrote:
> From: Corey Minyard <cminy...@mvista.com>
>
> Some devices need access to it.
>
> Signed-off-by: Corey Minyard <cminy...@mvista.com>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
On Thu, Feb 22, 2018 at 4:44 PM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 22 February 2018 at 15:39, Linus Walleij <linus.wall...@linaro.org> wrote:
>> On Tue, Feb 20, 2018 at 2:06 PM, Corey Minyard <miny...@acm.org> wrote:
>>> Linus, Philippe, do y
insertions(+), 17 deletions(-)
>>
>> Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
>
>
> Linus, Philippe, do you want me to submit this, or do you want
> to take it? You can pull it from:
>
> https://github.com/cminyard/qemu.git tags/i2c-bus-move
I don't have any commit rights, if you can push this to the
QEMU master I will happily rebase my stuff and resubmit :)
Yours,
Linus Walleij
On Mon, Feb 19, 2018 at 4:20 PM, <miny...@acm.org> wrote:
> From: Corey Minyard <cminy...@mvista.com>
>
> Signed-off-by: Corey Minyard <cminy...@mvista.com>
Reviewed-by: Linus Walleij <linus.wall...@linaro.org>
Yours,
Linus Walleij
On Sat, Feb 17, 2018 at 7:28 PM, Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
> On 02/17/2018 11:00 AM, Linus Walleij wrote:
>> The assignment of the SiI9022 at address 0x39 and the EDID
>> DDC I2C at address 0x50 is not strictly correct: the DDC I2C
>> is there all
l the time but in the actual component it only
appears once activated inside the SiI9022, so ideally it should
be added and removed to the bus by the SiI9022. However for this
purpose it works fine to just have it around.
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
default-configs
the QEMU EDID to the emulated
platform.
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
hw/display/Makefile.objs | 1 +
hw/display/sii9022.c | 185 +++
2 files changed, 186 insertions(+)
create mode 100644 hw/display/sii9022.c
diff
, but with the Versatile I2C it surely
does not work.
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
hw/i2c/i2c-ddc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/i2c/i2c-ddc.c b/hw/i2c/i2c-ddc.c
index 199dac9e41c1..bec0c91e2dd0 100644
--- a/hw/i2c/i2c-ddc.c
++
eter.mayd...@linaro.org>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
hw/display/pl110.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/hw/display/pl110.c b/hw/display/pl110.c
index 8c7dcc6f0a69..777bb3f44503 100644
--- a/hw/displa
need a baseline to send a pull request for my cleanup of the
Integrator PCI, and I'd probably like to move the PCIv3
controller as well if I can use the same baseline as you for
this.
Yours,
Linus Walleij
a property for forcing the behaviour, so that
if there are further cases we didn't know about, at least users have
a command line workaround they can enable.
This looks like a viable approach to me. So FWIW:
Acked-by: Linus Walleij linus.wall...@linaro.org
Yours,
Linus Walleij
59 matches
Mail list logo
