Hi Mateusz,
On Tue, Jan 12, 2021 at 03:31:59PM +0100, Mateusz Holenko wrote:
> > Upstream LiteX now defaults to using 32-bit CSR subregisters
> > (see https://github.com/enjoy-digital/litex/commit/a2b71fde).
> >
> > This patch expands on commit 22447a99c97e ("drivers/soc/litex: add
> > LiteX SoC C
Ping :)
On Sun, Dec 27, 2020 at 11:13:16AM -0500, Gabriel Somlo wrote:
> This series expands on commit 22447a99c97e ("drivers/soc/litex: add LiteX
> SoC Controller driver"), adding support for handling both 8- and 32-bit
> LiteX CSR (MMIO) subregisters, on both 32- and 64-bit CPUs.
>
> Notes v5:
On Sun, Dec 27, 2020 at 11:13:20AM -0500, Gabriel Somlo wrote:
> The 'litex_[set|get]_reg()' methods use the 'reg_size' parameter to
> specify the width of the LiteX CSR (MMIO) register being accessed.
>
> Since 'u64' is the widest data being supported, the value of 'reg_size'
> MUST be between 1
On Fri, Dec 25, 2020 at 09:21:20AM -0500, Gabriel Somlo wrote:
> Upstream LiteX now defaults to using 32-bit CSR subregisters
> (see https://github.com/enjoy-digital/litex/commit/a2b71fde).
>
> This patch expands on commit 22447a99c97e ("drivers/soc/litex: add
> LiteX SoC Controller driver"), addi
Hi Geert, Mateusz,
On Fri, Sep 25, 2020 at 03:16:02PM +0200, Geert Uytterhoeven wrote:
> Hi Mateusz,
>
> On Wed, Sep 23, 2020 at 12:10 PM Mateusz Holenko
> wrote:
> > From: Pawel Czarnecki
> >
> > This commit adds driver for the FPGA-based LiteX SoC
> > Controller from LiteX SoC builder.
> >
>
Hi Ben,
On Wed, Apr 29, 2020 at 01:21:11PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2020-04-27 at 11:13 +0200, Mateusz Holenko wrote:
> > As Gabriel Somlo suggested to me, I could still use
> > readl/writel/ioread/iowrite() standard functions providing memory
> > barriers *and* have values
Eliminate the following sparse warnings:
tcpci.c:291:38: warning: incorrect type in argument 1 (different base types)
tcpci.c:291:38:expected unsigned short [unsigned] [usertype] header
tcpci.c:291:38:got restricted __le16 const [usertype] header
tcpci.c:296:16: warning: incorrect type in
Acked-by: Gabriel Somlo
On Tue, Nov 28, 2017 at 10:40:27PM +0100, Vasyl Gomonovych wrote:
> Fix ptr_ret.cocci warnings:
> drivers/firmware/efi/efi.c:610:8-14: WARNING: PTR_ERR_OR_ZERO can be used
>
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Generated by: scripts/coccinelle/
g.c
> > > index 1f3e8545dab7..8ce5e49b7c62 100644
> > > --- a/drivers/firmware/qemu_fw_cfg.c
> > > +++ b/drivers/firmware/qemu_fw_cfg.c
> > > @@ -33,6 +33,8 @@
> > > #include
> > > #include
> > > #include
> > > +
bd9bb134900 100644
> --- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -35,6 +35,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> MODULE_AUTHOR("Gabriel L. Somlo ");
> MODULE_DESCRIPTION("QEMU fw_
On Tue, Oct 31, 2017 at 04:19:34PM +0100, Marc-André Lureau wrote:
> Signed-off-by: Marc-André Lureau
Acked-by: Gabriel Somlo
> ---
> drivers/firmware/qemu_fw_cfg.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmwa
On Tue, Oct 31, 2017 at 04:19:33PM +0100, Marc-André Lureau wrote:
> Hi,
>
> This series adds DMA operations support to the qemu fw_cfg kernel
> module and populates "etc/vmcoreinfo" with vmcoreinfo location
> details.
>
> Note: the support for this entry handling has been merged for next
> qemu
On Tue, Oct 31, 2017 at 04:19:37PM +0100, Marc-André Lureau wrote:
> The following patch is going to use the symbol from the fw_cfg module.
>
> Signed-off-by: Marc-André Lureau
Acked-by: Gabriel Somlo
> ---
> kernel/crash_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel
- a/drivers/firmware/qemu_fw_cfg.c
> +++ b/drivers/firmware/qemu_fw_cfg.c
> @@ -33,6 +33,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> MODULE_AUTHOR("Gabriel L. Somlo ");
> MODULE_DESCRIPTION("QEMU fw_cfg sysfs support");
>
On Tue, Oct 31, 2017 at 04:19:35PM +0100, Marc-André Lureau wrote:
> Add an optional kernel module (or command line) parameter
> using the following syntax:
>
> [qemu_fw_cfg.]ioport=@[::[:]]
> or
> [qemu_fw_cfg.]mmio=@[::[:]]
>
> and initializes the register address using given or d
Resolving checkpatch issue:
CHECK: 'successfuly' may be misspelled - perhaps 'successfully'?
Signed-off-by: Gabriel Somlo
---
On Tue, Jun 13, 2017 at 02:57:40PM +0200, Greg KH wrote:
> On Mon, Jun 12, 2017 at 03:43:35PM -0400, Gabriel L. Somlo wrote:
> >
Signed-off-by: Gabriel Somlo
---
drivers/staging/fsl-mc/bus/dpio/dpio-service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
b/drivers/staging/fsl-mc/bus/dpio/dpio-service.c
index e5d6674..8c45f81 100644
--- a/drivers/staging/
On Thu, May 04, 2017 at 08:07:15PM +0200, Radim Krčmář wrote:
> 2017-05-04 13:56-0400, Gabriel L. Somlo:
> > If I wanted to test this (e.g. with OS X 10.8 guests on several of my older
> > Mac boxes running Fedora), which git repo would you have me use? (The series
> > won&#x
On Thu, May 04, 2017 at 08:07:15PM +0200, Radim Krčmář wrote:
> 2017-05-04 13:56-0400, Gabriel L. Somlo:
> > If I wanted to test this (e.g. with OS X 10.8 guests on several of my older
> > Mac boxes running Fedora), which git repo would you have me use? (The series
> > won&#x
Hi Radim,
On Wed, May 03, 2017 at 09:37:29PM +0200, Radim Krčmář wrote:
> kvm_mwait_in_guest() was overcomplicated and also missed one AMD bug
> that should prevent MWAIT pass through.
>
> This series ignores errata that don't have any Linux bug defined;
> I know of two minor (not affecting the h
On Tue, Apr 11, 2017 at 08:41:11AM -0400, Gabriel L. Somlo wrote:
> On Tue, Apr 11, 2017 at 01:45:35PM +0200, Alexander Graf wrote:
> > From: "Michael S. Tsirkin"
> >
> > Guests that are heavy on futexes end up IPI'ing each other a lot. That
> > can
e consciously do *not* expose the feature in our CPUID bitmap, as most
> people will want to benefit from sleeping vCPUs to allow for over commit.
>
> Reported-by: "Gabriel L. Somlo"
That's maybe a bit inacurate, I didn't actually report anything *this*
patch is t
On Wed, Mar 22, 2017 at 03:35:18PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 21, 2017 at 05:02:25PM -0700, Nadav Amit wrote:
> >
> > > On Mar 21, 2017, at 3:51 PM, Gabriel Somlo wrote:
> > >
> > > And I get the exact same results on the MacBookAir4,2 (which exhibits
> > > no freezing or ext
On Fri, Mar 17, 2017 at 04:03:59AM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 05:14:15PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 04:17:11PM -0400, Gabriel L. Somlo wrote:
> > > On Thu, Mar 16, 2017 at 09:27:56PM +0200, Michael S. Tsirkin wro
On Thu, Mar 16, 2017 at 04:17:11PM -0400, Gabriel L. Somlo wrote:
> On Thu, Mar 16, 2017 at 09:27:56PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 16, 2017 at 03:24:41PM -0400, Gabriel L. Somlo wrote:
> > > On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote:
On Thu, Mar 16, 2017 at 09:27:56PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 03:24:41PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote:
> > > Let's take a step back and try to figure out how is
> &
On Thu, Mar 16, 2017 at 08:29:32PM +0200, Michael S. Tsirkin wrote:
> Let's take a step back and try to figure out how is
> mwait called. How about dumping code of VCPUs
> around mwait? gdb disa command will do this.
Started guest with '-s', tried to attach from gdb with
"target remote localhost:
On Thu, Mar 16, 2017 at 07:27:34PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 12:47:50PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 05:01:58PM +0100, Radim Krčmář wrote:
> > > 2017-03-16 16:35+0100, Radim Krčmář:
> > > > 2017-03-1
On Thu, Mar 16, 2017 at 06:22:44PM +0100, Radim Krčmář wrote:
> 2017-03-16 12:47-0400, Gabriel L. Somlo:
> > On Thu, Mar 16, 2017 at 05:01:58PM +0100, Radim Krčmář wrote:
> > > 2017-03-16 16:35+0100, Radim Krčmář:
> > > > 2017-03-16 10:58-0400, Gabriel L. Somlo:
>
On Thu, Mar 16, 2017 at 12:52:32PM -0400, Gabriel L. Somlo wrote:
> On Thu, Mar 16, 2017 at 06:45:02PM +0200, Michael S. Tsirkin wrote:
> > On Thu, Mar 16, 2017 at 12:16:13PM -0400, Gabriel L. Somlo wrote:
> > > On Thu, Mar 16, 2017 at 04:35:18PM +0100, Radim Krčmář wrote:
> &
On Thu, Mar 16, 2017 at 06:45:02PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 12:16:13PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Mar 16, 2017 at 04:35:18PM +0100, Radim Krčmář wrote:
> > > 2017-03-16 10:58-0400, Gabriel L. Somlo:
> > > > On Thu, Ma
On Thu, Mar 16, 2017 at 05:01:58PM +0100, Radim Krčmář wrote:
> 2017-03-16 16:35+0100, Radim Krčmář:
> > 2017-03-16 10:58-0400, Gabriel L. Somlo:
> >> The intel manual said the same thing back in 2010 as well. However,
> >> regardless of how any flags were set, inte
On Thu, Mar 16, 2017 at 04:54:06PM +0100, Radim Krčmář wrote:
> 2017-03-16 11:44-0400, Gabriel L. Somlo:
> > On Thu, Mar 16, 2017 at 03:08:07PM +0100, Radim Krčmář wrote:
> >> 2017-03-16 09:24-0400, Gabriel L. Somlo:
> >> > On Thu, Mar 16, 2017 at 01:41:28AM +
On Thu, Mar 16, 2017 at 04:35:18PM +0100, Radim Krčmář wrote:
> 2017-03-16 10:58-0400, Gabriel L. Somlo:
> > On Thu, Mar 16, 2017 at 04:04:12PM +0200, Michael S. Tsirkin wrote:
> > > On Thu, Mar 16, 2017 at 09:24:27AM -0400, Gabriel L. Somlo wrote:
> > > > After
On Thu, Mar 16, 2017 at 03:08:07PM +0100, Radim Krčmář wrote:
> 2017-03-16 09:24-0400, Gabriel L. Somlo:
> > On Thu, Mar 16, 2017 at 01:41:28AM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Mar 15, 2017 at 07:35:34PM -0400, Gabriel L. Somlo wrote:
> > > > On Wed, Ma
On Thu, Mar 16, 2017 at 04:04:12PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 16, 2017 at 09:24:27AM -0400, Gabriel L. Somlo wrote:
> > After studying your patch a bit more carefully (sorry, it's crazy
> > around here right now :) ) I realized you're simply trying to
On Thu, Mar 16, 2017 at 01:41:28AM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 15, 2017 at 07:35:34PM -0400, Gabriel L. Somlo wrote:
> > On Wed, Mar 15, 2017 at 11:22:18PM +0200, Michael S. Tsirkin wrote:
> > > Guests running Mac OS 5, 6, and 7 (Leopard through Li
taying inside L1 and
running guest-mode MWAIT in a tight loop will actually waste the host
CPU without the opportunity to yield to some other L0 thread. Sorry if
I fell into the middle of an ongoing conversation on this and missed
most of the relevant context, in which case please feel free to ig
On Wed, Mar 15, 2017 at 09:46:18PM +0100, Radim Krčmář wrote:
> 2017-03-15 16:21-0400, Gabriel L. Somlo:
> > On Wed, Mar 15, 2017 at 09:13:49PM +0100, Radim Krčmář wrote:
> >> 2017-03-15 21:28+0200, Michael S. Tsirkin:
> >> > Guests running Mac OS 5, 6, and 7 (Leopar
apability. Add a flag in the hypervisor leaf instead.
> >
> > Additionally, we add a capability for QEMU - e.g. if it knows there's an
> > isolated CPU dedicated for the VCPU it can set the standard MWAIT flag
> > to improve guest behaviour.
> >
> &g
On Wed, Mar 15, 2017 at 04:21:41PM -0400, Gabriel L. Somlo wrote:
> >
> > - do you see VM exits on the "hung" VCPU?
>
> how would I go about looking ?
>
> > - what is your CPU model?
>
> $ cat /proc/cpuinfo
> ...
> processor : 3
>
failed
make[1]: *** [arch/x86/kvm] Error 2
Makefile:1002: recipe for target 'arch/x86' failed
make: *** [arch/x86] Error 2
Did you accidentally leave out something that went into a .h file
somewhere ?
Thx,
--G
On Wed, Mar 15, 2017 at 09:29:57PM +0200, Michael S. Tsirkin wrote:
> On
On Wed, Mar 15, 2017 at 08:29:23PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 15, 2017 at 02:14:26PM -0400, Gabriel L. Somlo wrote:
> > Michael,
> >
> > I tested this on OS X 10.7 (Lion), the last version that doesn't check
> > CPUID for MWAIT support.
> &g
Michael,
I tested this on OS X 10.7 (Lion), the last version that doesn't check
CPUID for MWAIT support.
I used the latest kvm from git://git.kernel.org/pub/scm/virt/kvm/kvm.git
first as-is, then with your v2 MWAIT patch applied.
Single-(V)CPU guest works as expected (but then again, single-vcpu
within guests is not the same as on real hardware
> because halt causes an exit while mwait doesn't. For this reason it
> might not be a good idea to use the regular MWAIT flag in CPUID to
> signal this capability: halt is sometimes better as you are giving up
> the rest of your CPU
On Sun, Mar 12, 2017 at 02:01:32AM +0200, Michael S. Tsirkin wrote:
> On Fri, Mar 10, 2017 at 03:46:45PM -0800, Jim Mattson wrote:
> > On Thu, Mar 9, 2017 at 2:29 PM, Michael S. Tsirkin wrote:
> > > Some guests call mwait without checking the cpu flags. We currently
> >
> > "Some guests"? What g
On Fri, Mar 10, 2017 at 12:29:31AM +0200, Michael S. Tsirkin wrote:
> Some guests call mwait without checking the cpu flags. We currently
> emulate that as a NOP but on VMX we can do better: let guest stop the
> CPU until timer or IPI. CPU will be busy but that isn't any worse than
> a NOP emulat
On Sun, Sep 18, 2016 at 02:48:30PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 18 Sep 2016 14:43:21 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (6):
> Use kmalloc_array() in fw_cfg_register_dir_entries
On Thu, May 26, 2016 at 10:39:31PM +0200, Radim Krčmář wrote:
> 2016-05-26 10:32+0300, km...@yandex-team.ru:
> > From: Dmitry Bilunov
> >
> > Intel CPUs having Turbo Boost feature implement an MSR to provide a
> > control interface via rdmsr/wrmsr instructions. One could detect the
> > presence o
On Thu, Apr 14, 2016 at 12:33:37PM +0300, Dan Carpenter wrote:
> It acpi_acquire_global_lock() return AE_NOT_CONFIGURED then "glk" isn't
> initialized, which, if you got very unlucky, could cause a bug.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/fi
On Thu, Apr 14, 2016 at 10:12:53PM +0300, Dan Carpenter wrote:
> On Thu, Apr 14, 2016 at 02:40:06PM -0400, Gabriel L. Somlo wrote:
> > On Thu, Apr 14, 2016 at 12:33:37PM +0300, Dan Carpenter wrote:
> > > It acpi_acquire_global_lock() return AE_NOT_CONFIGURE
On Thu, Apr 14, 2016 at 12:33:37PM +0300, Dan Carpenter wrote:
> It acpi_acquire_global_lock() return AE_NOT_CONFIGURED then "glk" isn't
^ ^
Ifreturns
> initialized, which, if you got very unlucky, could cause a bug.
In principle I'm
On Tue, Apr 05, 2016 at 11:54:19AM +0300, Michael S. Tsirkin wrote:
> On Thu, Mar 17, 2016 at 09:33:40AM -0400, Gabriel L. Somlo wrote:
> > On Wed, Mar 16, 2016 at 06:57:01PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Mar 08, 2016 at 01:30:50PM -0500, Gabriel Somlo wrote:
&g
On Tue, Apr 05, 2016 at 11:31:27AM +0300, Michael S. Tsirkin wrote:
> Gabriel merged support for QEMU FW CFG interface, but there's apparently
> no official maintainer. It's also possible that this will grow more
> interfaces in future. I'll happily co-maintain it and handle pull
> requests togeth
On Sun, Apr 03, 2016 at 03:23:19PM +0300, Michael S. Tsirkin wrote:
> If platform_driver_register fails, we should
> cleanup fw_cfg_top_ko before exiting.
>
> Signed-off-by: Michael S. Tsirkin
Acked-by: Gabriel Somlo
Thanks,
--Gabriel
> ---
> drivers/firmware/qemu_fw_cfg.c | 8 +++-
> 1
On Wed, Mar 16, 2016 at 06:57:01PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 08, 2016 at 01:30:50PM -0500, Gabriel Somlo wrote:
> > Allowing for the future possibility of implementing AML-based
> > (i.e., firmware-triggered) access to the QEMU fw_cfg device,
> > acquire the global ACPI lock wh
On Tue, Feb 23, 2016 at 04:14:46PM +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 23, 2016 at 08:47:00AM -0500, Gabriel L. Somlo wrote:
> > On Tue, Feb 23, 2016 at 07:07:36AM +0200, Michael S. Tsirkin wrote:
> > > On Mon, Feb 22, 2016 at 03:26:23PM -0500, Gabriel L. Somlo wro
On Tue, Feb 23, 2016 at 07:07:36AM +0200, Michael S. Tsirkin wrote:
> On Mon, Feb 22, 2016 at 03:26:23PM -0500, Gabriel L. Somlo wrote:
> > On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabr
On Mon, Feb 22, 2016 at 10:14:50PM +0200, Michael S. Tsirkin wrote:
> On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> > > > +static void fw_cfg_io_cleanup(void)
> > > > +{
> > > > + if (fw_cfg_is_mmio) {
> >
On Sun, Feb 21, 2016 at 10:30:26AM +0200, Michael S. Tsirkin wrote:
> On Thu, Jan 28, 2016 at 09:23:11AM -0500, Gabriel L. Somlo wrote:
> > From: Gabriel Somlo
> >
> > Make fw_cfg entries of type "file" available via sysfs. Entries
> > are listed under
On Sun, Feb 21, 2016 at 03:10:30PM +0200, Michael S. Tsirkin wrote:
> On Sun, Feb 21, 2016 at 08:06:17AM -0500, Gabriel L. Somlo wrote:
> >
> > >
> > > > +#if !(defined(FW_CFG_CTRL_OFF) && defined(FW_CTRL_DATA_OFF))
> > > > +# if (defined(CONFIG
On Thu, Feb 11, 2016 at 03:23:51PM +0100, Arnd Bergmann wrote:
> Not all machines have PCI style I/O port memory, or they do not allow
> mapping it using the ioport_map() function, whcih results in a
> build error with the newly added qemu firmware code:
>
> drivers/firmware/built-in.o: In functio
On Thu, Feb 11, 2016 at 12:19:03PM +0100, Valentin Rothberg wrote:
> s/FW_CTRL_DATA_OFF/FW_CFG_DATA_OFF/
Thanks for catching that !
Acked-by: Gabriel Somlo
>
> Signed-off-by: Valentin Rothberg
> Signed-off-by: Andreas Ziegler
> ---
> v2: corrected typo in signed-off-by
>
> drivers/firmwar
On Sat, Feb 06, 2016 at 11:24:23PM -0800, Greg KH wrote:
> On Thu, Jan 28, 2016 at 09:23:12AM -0500, Gabriel L. Somlo wrote:
> > From: Gabriel Somlo
> >
> > Signed-off-by: Gabriel Somlo
> > ---
> > lib/kobject.c | 1 +
> > 1 file changed, 1 insertion(+
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
From: "Gabriel Somlo"
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and
l) offset of data register
+ *
+ * e.g.:
+ * fw_cfg.ioport=2@0x510:0:1 (the default on x86)
+ * or
+ * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Gabriel L. Somlo
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
From: Gabriel Somlo
Remove fw_cfg hardware interface details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the authoritative
documentation in the QEMU source tree.
Signed-off-by: Gabriel Somlo
Cc: Laszlo Ersek
Acked-by: Rob Herring
Reviewed-by: Lasz
tch 2/3.
>>>>>
>>>>> - Patch 2/3 adds a fw_cfg node to the pc SSDT.
>>>>>
>>>>> - Patch 3/3 adds a fw_cfg node to the arm DSDT.
>>>>>
>>>>> I made up some names - "FWCF" for the node name, and "FW
Move BIOS_CFG_IOPORT define from pc.c to pc.h, and rename
it to FW_CFG_IO_BASE.
Cc: Marc Marí
Signed-off-by: Gabriel Somlo
Reviewed-by: Laszlo Ersek
Reviewed-by: Marc Marí
---
hw/i386/pc.c | 5 ++---
include/hw/i386/pc.h | 2 ++
2 files changed, 4 insertions(+), 3 deletions(-)
diff -
From: Gabriel Somlo
Remove fw_cfg hardware interface details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the authoritative
documentation in the QEMU source tree.
Signed-off-by: Gabriel Somlo
Cc: Laszlo Ersek
Acked-by: Rob Herring
Reviewed-by: Lasz
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
tch 2/3.
>>>>>
>>>>> - Patch 2/3 adds a fw_cfg node to the pc SSDT.
>>>>>
>>>>> - Patch 3/3 adds a fw_cfg node to the arm DSDT.
>>>>>
>>>>> I made up some names - "FWCF" for the node name, and "FW
Add a fw_cfg device node to the ACPI SSDT. While the guest-side
firmware can't utilize this information (since it has to access
the hard-coded fw_cfg device to extract ACPI tables to begin with),
having fw_cfg listed in ACPI will help the guest kernel keep a more
accurate inventory of in-use IO por
cfg.ioport=2@0x510:0:1 (the default on x86)
+ * or
+ * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Gabriel L. Somlo ");
+MODULE_DESCRIPTION("QEMU fw
Signed-off-by: Gabriel Somlo
Reviewed-by: Laszlo Ersek
Reviewed-by: Marc Marí
---
docs/specs/fw_cfg.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
index 2099ad9..5414140 100644
--- a/docs/specs/fw_cfg.txt
+++ b/docs/specs/fw_cfg.tx
Expose the size of the control register (FW_CFG_CTL_SIZE) in fw_cfg.h.
Add comment to fw_cfg_io_realize() pointing out that since the
8-bit data register is always subsumed by the 16-bit control
register in the port I/O case, we use the control register width
as the *total* width of the (classic, n
From: "Gabriel Somlo"
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and
Add a fw_cfg device node to the ACPI DSDT. This is mostly
informational, as the authoritative fw_cfg MMIO region(s)
are listed in the Device Tree. However, since we are building
ACPI tables, we might as well be thorough while at it...
Signed-off-by: Gabriel Somlo
Reviewed-by: Laszlo Ersek
Tested
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
Hi Pavel,
On Sat, Dec 19, 2015 at 10:12:28AM +0100, Pavel Machek wrote:
> On Thu 2015-12-17 11:09:23, Gabriel L. Somlo wrote:
> > ping ?
> >
> > Also, for the corresponding patch set on the QEMU end of things,
> > ping on http://thread.gmane.org/gmane.comp.emulato
ping ?
Also, for the corresponding patch set on the QEMU end of things,
ping on http://thread.gmane.org/gmane.comp.emulators.qemu/376321
Thanks,
--Gabriel
On Fri, Dec 04, 2015 at 10:29:02AM -0500, Gabriel L. Somlo wrote:
> Allow access to QEMU firmware blobs, passed into the guest VM via
&g
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
From: Gabriel Somlo
Remove fw_cfg hardware interface details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the authoritative
documentation in the QEMU source tree.
Signed-off-by: Gabriel Somlo
Cc: Laszlo Ersek
Acked-by: Rob Herring
Reviewed-by: Lasz
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
cfg.ioport=2@0x510:0:1 (the default on x86)
+ * or
+ * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Gabriel L. Somlo ");
+MODULE_DESCRIPTION("QEMU fw
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
selected based on ov
On Tue, Nov 24, 2015 at 10:38:18AM -0700, Eric Blake wrote:
> On 11/24/2015 09:55 AM, Gabriel L. Somlo wrote:
> > On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:
>
> >>
> >>drivers/firmware/qemu_fw_cfg.c: In function 'fw_cfg_cm
On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:
> Hi Gabriel,
>
> [auto build test WARNING on v4.4-rc2]
> [also build test WARNING on next-20151123]
> [cannot apply to robh/for-next]
>
> url:
> https://github.com/0day-ci/linux/commits/Gabriel-L-Som
On Mon, Nov 23, 2015 at 05:35:51PM +0100, Laszlo Ersek wrote:
> On 11/23/15 16:57, Gabriel L. Somlo wrote:
> > From: Gabriel Somlo
> >
> > Remove fw_cfg hardware interface details from
> > Documentation/devicetree/bindings/arm/fw-cfg.txt,
> > and replace them wi
From: Gabriel Somlo
Signed-off-by: Gabriel Somlo
---
lib/kobject.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/kobject.c b/lib/kobject.c
index 7cbccd2..90d1be6 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -861,6 +861,7 @@ struct kobject *kset_find_obj(struct kset *kset, const c
From: Gabriel Somlo
Each fw_cfg entry of type "file" has an associated 56-char,
nul-terminated ASCII string which represents its name. While
the fw_cfg device doesn't itself impose any specific naming
convention, QEMU developers have traditionally used path name
semantics (i.e. "etc/acpi/rsdp") t
g.ioport=2@0x510:0:1 (the default on x86)
+ * or
+ * fw_cfg.mmio=0xA@0x902:8:0 (the default on arm)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_AUTHOR("Gabriel L. Somlo ");
+MODULE_DESCRIPTION("QEMU fw
From: Gabriel Somlo
Remove fw_cfg hardware interface details from
Documentation/devicetree/bindings/arm/fw-cfg.txt,
and replace them with a pointer to the authoritative
documentation in the QEMU source tree.
Signed-off-by: Gabriel Somlo
Cc: Laszlo Ersek
---
Documentation/devicetree/bindings/a
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was
selected based on ov
On Wed, Nov 18, 2015 at 02:04:24PM +0100, François Revol wrote:
> On 17/11/2015 23:14, Rob Herring wrote:
> > On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini wrote:
> >>
> >>
> >> On 15/11/2015 03:07, Rob Herring wrote:
> >>> We generally don't want DT docs to depend on other kernel documentation.
On Tue, Nov 17, 2015 at 04:14:42PM -0600, Rob Herring wrote:
> On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini wrote:
> >
> >
> > On 15/11/2015 03:07, Rob Herring wrote:
> >> We generally don't want DT docs to depend on other kernel documentation.
> >
> > DT docs do not contain a copy of the data s
On Mon, Nov 16, 2015 at 09:38:18AM +0100, Paolo Bonzini wrote:
> On 15/11/2015 03:07, Rob Herring wrote:
> > We generally don't want DT docs to depend on other kernel documentation.
>
> DT docs do not contain a copy of the data sheets, either. There is no
> reason to say how to use the device (an
From: "Gabriel Somlo"
Allow access to QEMU firmware blobs, passed into the guest VM via
the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name,
size, and fw_cfg key), as well as the raw binary blob data may be
accessed.
The SysFS access location is /sys/firmware/qemu_fw_cfg/... and
1 - 100 of 139 matches
Mail list logo
