le.com wrote:
> > From: Roman Kiryanov
> >
> > Since the driver provides no workaround prevent in cases if structs do
> > no fit into a memory page, it is better to fail complation to find about
> > the issue earlt instead of returning errors at runtime.
>
>
Hi Greg,
the get_maintainer script gave only the mailing list. Do you happen to
know if I need to mail my change somewhere else?
Regards,
Roman.
On Thu, Jul 19, 2018 at 4:07 PM wrote:
>
> From: Roman Kiryanov
>
> Not used by goldfish.
>
> Signed-off-by: Roman Kiryanov
Hi Greg,
could you please confirm you received my patch?
Regards,
Roman.
On Mon, Jul 23, 2018 at 3:47 PM wrote:
>
> From: Roman Kiryanov
>
> goldfish.h refers to external symbols such as
> dma_addr_t and writel. This causes compilation errors
> if this file is included b
> Then why not just make it a #define?
With "const" the diff is smaller.
> No need to waste the memory of a variable, right?
I believe the compiler will produce the same binary for const and for
#define if optimization is enabled.
Hi, thank you for looking into my patches.
> You can not break the build on one patch, and then fix it up on a later
> one.
Thank you catching this. Please drop this patch.
Hi. Thank you for looking into my patch.
> If they can not, then just remove the
> WARN_ON check as it is not needed at all.
No, these things don't happen. I will remove these lines.
> Why isn't this in drivers/platform/goldfish/ ?
I was not sure where to put, but this driver is not a platform one, it
is a pci one.
> You should only allocate memory at probe time
probe does not know what memory to allocate. We have several versions
of the driver (with different init) and different versions allocate
different state.
>, not init time as what
> happens if the hardware is not present yet your driver is loaded?
> > This is the v2 driver. v1 will be added later.
>
> If you want to add a new driver later, great, but don't change the name
> of an existing driver for no good reason.
I want our "v2" driver to be in a "v2" file and our "v1" driver in a
"v1" file. I think this is reasonable.
> > probe does not know what memory to allocate. We have several versions
> > of the driver (with different init) and different versions allocate
> > different state.
>
> I only see one driver here.
It will be added in "PATCH v3 15/15". There will be two init functions
allocating
different states.
> > I want our "v2" driver to be in a "v2" file and our "v1" driver in a
> > "v1" file. I think this is reasonable.
>
> The in kernel driver is the "v1" one.
I believe v2 (on our end) was upstream as goldfish_pipe.c instead of
goldfish_pipe_v2.c.
> Why do you need a totally new driver file at al
> This function can not fail, why are you returning 0 always? That
> doesn't make sense.
remove in struct platform_driver requires returning something, we have
to have "return" somewhere.
I think we want to return closer to the place where we do something useful.
> I think we are getting our terms confused here.
>
> "init" usually means module_init(), is that what you are referring to
> here?
This is just a function that probe calls to, goldfish_pipe_device_v2_init.
https://android.googlesource.com/kernel/goldfish/+/android-goldfish-4.14-dev/drivers/platf
> > I don't want to mix v1 and v2.
>
> Why? What is the difference?
> Why do you even need/want 2 different drivers here
In old emulators we implemented the device differently, so we need a
different driver.
> for something that really should be done with the virtio
> interface instead?
We are
On Sat, Nov 14, 2020 at 1:48 AM Jiaxun Yang wrote:
> Thus I do think it shouldn't be retired as for now. If nobody comes in
> I'd also willing to maintain
Hi Jiaxun and Hancai,
I sent a patch to add you to MAINTAINERS for goldfish-rtc. Could you
please ack there?
Regards,
Roman.
> > +M: Jiaxun Yang
> > +M: Huacai Chen
>
> It would be nice to get an ack from the people you are removing and
> adding to this entry :(
Hi Jiaxun and Huacai, could you please ack this change?
On Thu, Nov 19, 2020 at 2:43 PM Roman Kiryanov wrote:
>
> > > +M: Jiaxun Yang
> > > +M: Huacai Chen
> >
> > It would be nice to get an ack from the people you are removing and
> > adding to this entry :(
>
> Hi Jiaxun and Huacai, could you please ack this change?
Gentle ping.
On Fri, Feb 5, 2021 at 6:31 PM wrote:
>
> From: Roman Kiryanov
>
> This will allow to use the BATTERY_GOLDFISH driver
> without enabling GOLDFISH.
Hi Sebastian, could you please take a look at my patch?
Thank you.
+Thoman, +Ingo, +Borislav
On Mon, Dec 14, 2020 at 1:20 PM Roman Kiryanov wrote:
>
> On Mon, Nov 16, 2020 at 6:55 PM wrote:
> >
> > From: Roman Kiryanov
> >
> > The Android Studio Emulator (aka goldfish) does not
> > use arch/x86/platform/goldfish since 5.4
On Mon, Nov 16, 2020 at 6:55 PM wrote:
>
> From: Roman Kiryanov
>
> The Android Studio Emulator (aka goldfish) does not
> use arch/x86/platform/goldfish since 5.4 kernel.
>
> Signed-off-by: Roman Kiryanov
Gentle ping.
Hi, I am sorry for this warning. I remember I checked all changes I
sent, maybe missed this one.
At the bottom the file says
MODULE_LICENSE("GPL");
and
// SPDX-License-Identifier: GPL-2.0
makes it inconsistent.
Regards,
Roman.
On Tue, Mar 19, 2019 at 7:51 AM Thomas Gleixner wrote:
>
> spdxc
> How does QEMU do this today? There isn't a virtio or some other virtual
> memory device that allows memory regions to be shared? I can't believe
> that there isn't one yet. If not, then this should be some kind of
> "generic" QEMU memory device, not a "goldfish" specific one, right?
I also th
> > Do you have a pointer to the QEMU commit that matches up with the device
> > that this driver is supposed to be supporting?
>
> The device code is here:
>
> https://android.googlesource.com/platform/external/qemu/+/emu-master-dev/hw/pci/goldfish_address_space.c
Hi Greg, do you need anything el
> You have a number of WARN_ON() calls in here that are not needed, please
> remove.
Thank you for noticing, I will remove them.
> Also, why is this driver needed at all? Why can't you use the "normal"
> drm sync api interface? Why write a custom ioctl driver just for this
> one kernel interfac
> Do you have a pointer to the QEMU commit that matches up with the device
> that this driver is supposed to be supporting?
The device code is here:
https://android.googlesource.com/platform/external/qemu/+/emu-master-dev/hw/pci/goldfish_address_space.c
Regards,
Roman.
Yes, in the later change I am going to retire this variable
completely. Could you please accept this patch as it?
On Fri, Sep 14, 2018 at 6:30 AM Greg KH wrote:
>
> On Mon, Aug 27, 2018 at 11:23:02AM -0700, r...@google.com wrote:
> > From: Roman Kiryanov
> >
> > There
Hi, thank you for looking into my patches.
> A whole new api needs some others to review it becides just me. Please
> get some more signed off by on this.
Yes, I will find more people.
> If you have a spdx line, you don't need the gpl boiler-plate text
> either.
Agree.
> But, this is a uapi f
> I don't see a "global" variable here, what are you referring to.
>
> This one:
>
> > -static DECLARE_TASKLET(goldfish_interrupt_tasklet,
> > goldfish_interrupt_task, 0);
>
> ?
Yes.
> That looks static to this file to me.
> what am I missing here?
It has a global lifetime but it is visible onl
> I only received 3 emails in this series. Always resend them all.
Hi. It was not obvious to me to resend all patches.
Do I mark all other patches "v2" as well? What do I put there in the
"Changelog"?
Hi Greg, thank you for looking into this.
On Thu, Nov 12, 2020 at 11:44 PM Greg KH wrote:
>
> On Thu, Nov 12, 2020 at 03:49:07PM -0800, r...@google.com wrote:
> > From: Roman Kiryanov
> >
> > Android Studio Emulator (goldfish) migrated
> > to Intel HDA.
>
&g
Hi Rob, thank you for looking into this.
On Fri, Nov 13, 2020 at 1:07 PM Rob Herring wrote:
>
> On Fri, Nov 13, 2020 at 12:52:33PM -0800, r...@google.com wrote:
> > From: Roman Kiryanov
> >
> > The only user of RTC_DRV_GOLDFISH is
> > the MIPS flavor of Android
Hi Hancai,
I see you added /arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts which
refers to goldfish-rtc in 39c1485c8baa47aa20caefc1ec0a3410fbad6c81.
We (Android Studio Emulator aka "goldfish") do not support MIPS anymore.
Do you know if goldfish-rtc still works and is assumed to be avail
+Greg KH
On Fri, Nov 13, 2020 at 2:02 PM Roman Kiryanov wrote:
>
> Hi Hancai,
>
> I see you added /arch/mips/boot/dts/loongson/loongson64v_4core_virtio.dts
> which
> refers to goldfish-rtc in 39c1485c8baa47aa20caefc1ec0a3410fbad6c81.
> We (Android Studio Emulator aka "
ould keep it in kernel.
>
> Huacai
>
>
> -- Original --
> From: "Greg KH";
> Date: Sat, Nov 14, 2020 07:43 AM
> To: "Roman Kiryanov";
> Cc: "chenhc"; "Paul Walmsley";
> "LKML"; &
> > Thus I do think it shouldn't be retired as for now. If nobody comes in I'd
> > also willing to maintain
> > it.
>
> Ok, can someone submit a patch to update the MAINTAINERS file for this
> so we know who to route issues to over time?
I will send a patch to update MAINTAINERS for goldfish-rtc.
On Fri, Sep 18, 2020 at 3:25 PM Pavel Machek wrote:
>
> On Tue 2020-09-15 11:36:13, Roman Kiryanov wrote:
> > On Tue, Sep 15, 2020 at 11:27 AM Borislav Petkov wrote:
> > > > I believe the kernel makes a questionable assumption on how clang
> > > > uses reg
On Tue, Sep 15, 2020 at 10:46 AM Borislav Petkov wrote:
Hi Borislav, thank you for a quick response.
> Ok, google guys, pls make sure you Cc LKML too as this is where *all*
> patches and discussions are archived. Adding it now to Cc.
Thank you, I did not know this.
> Ok, so why is the kernel s
On Tue, Sep 15, 2020 at 11:27 AM Borislav Petkov wrote:
> > I believe the kernel makes a questionable assumption on how clang
> > uses registers (gs will not be used if stack protection is disabled).
> > Both kernel and clang behaves unfortunate here.
>
> If the kernel is at fault here and this sa
On Tue, Sep 15, 2020 at 11:52 AM Borislav Petkov wrote:
>
> On Tue, Sep 15, 2020 at 11:36:13AM -0700, Roman Kiryanov wrote:
> > This is fair. Unfortunately I am not an x86 asm expert. I expect the proper
> > fix should land into arch/x86/kernel/acpi/wakeup_64.S to init %gs
&g
> Also, why does the other Android "emulator", cuttlefish, not need
> special drivers like this and the other goldfish drivers? Shouldn't you
> be using the same interfaces that they use that are already merged
> upstream?
> Actually, now that cuttlefish works on a mainline kernel, can't we just
>
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 2b29eed3f201b49feb92fdd0178b10825a5528f4
Gitweb:
https://git.kernel.org/tip/2b29eed3f201b49feb92fdd0178b10825a5528f4
Author:Roman Kiryanov
AuthorDate:Mon, 16 Nov 2020 18:55:22 -08:00
41 matches
Mail list logo
