From: Stefan Berger
Add support for NIST p192 keys in x509 certificates and support it in
'akcipher'.
Signed-off-by: Stefan Berger
---
crypto/asymmetric_keys/public_key.c | 3 ++
crypto/asymmetric_keys/x509_cert_parser.c | 1 +
crypto/ecc.c | 36
From: Stefan Berger
Return error code -ETIMEDOUT rather than '0' when waiting for the
rtce_buf to be set has timed out.
Fixes: d8d74ea3c002 ("tpm: ibmvtpm: Wait for buffer to be set before
proceeding")
Reported-by: Hulk Robot
Signed-off-by: Wang Hai
Signed-off-by: Stefan Berger
--
ed
> to the link speed?
>
>Andrew
Currently its static, probably I can add function that reconfigure timer during
runtime(based on link speed).
Should it be part of this series or add it afterwards?
Regards,
Stefan.
> > We cannot access PPv2 register space before enabling clocks(done in
> mvpp2_probe) , PP21 and PP22/23 have different sets of clocks.
>
> > So diff between PP21 and PP22/23 should be stored in device tree(in
> > of_device_id), with MVPP22 and MVPP21 stored as .data
&g
readl(priv->cm3_base + offset); }
>
> No inline functions in .c file please. Let the compiler decide.
>
>Andrew
Ok, I would fix.
Thanks,
Stefan.
quanta should be equal to 512 bit times.
In 10G bit time is 0.1ns.
So It actually should be:
FC_CLK_DIVIDER = 1 / 512 = ~20. I took some buffer and made it 140.
So maybe I can do it 100?
Regards,
Stefan.
> > Signed-off-by: Stefan Chulski
> > ---
> > drivers/net/ethernet/marvell/mvpp2/mvpp2.h | 24 --
> --
> > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 17 +-
> > 2 files changed, 25 insertions(+), 16 deletions(-)
> >
ch that make it if (cpu => port->priv->nthreads). Or even remove
this if.
Anyway on current Armada platforms we have only 4 CPU's and maximum 9 PPv2
threads(nthreads is min between num_present_cpus and maximum HW PPv2 threads),
so this would be always false.
Regards,
Stefan.
(i = 0; i < port->nrxqs; i++)
> mvpp2_bm_pool_update_fc(port,
> >priv->bm_pools[i],
> tx_pause);
> } else {
> mvpp2_bm_pool_update_fc(port, port->pool_long,
> tx_pause);
> mvpp2_bm_pool_update_fc(port, port->pool_short,
> tx_pause);
> }
> }
>
Ok, I would update.
Thanks,
Stefan.
Am 13.01.21 um 00:47 schrieb Jim Mattson:
On Wed, Apr 4, 2018 at 10:44 PM Paolo Bonzini wrote:
On 04/04/2018 19:35, Stefan Fritsch wrote:
On Wednesday, 4 April 2018 19:24:20 CEST Paolo Bonzini wrote:
On 04/04/2018 19:10, Konrad Rzeszutek Wilk wrote:
Should there be a corresponding test
> > From: Stefan Chulski
> >
> > This patch doesn't change any functionality, but just extend MIB
> > counter register and ethtool-statistic names with "err".
> >
> > The counter MVPP2_MIB_FRAGMENTS_RCVD in fact is Error counter.
> > Extend
Hi,
Am 11.01.21 um 04:39 schrieb Jeremy Linton:
> Hi,
>
> On 1/9/21 5:07 AM, Stefan Wahren wrote:
>> Hi Jeremy,
>>
>> +add Nicolas
>>
>> Am 08.01.21 um 22:13 schrieb Jeremy Linton:
>>> The rpi4 has a Arasan controller it carries over
>>>
>
> On Sun, Jan 10, 2021 at 06:55:11PM +, Stefan Chulski wrote:
> > > > not connected to the GOP flow control generation mechanism.
> > > > To solve this issue Armada has firmware running on CM3 CPU
> > > > dedectated for Flow Control support.
ol 0 Register.
>
> What is the minimum firmware version that supports this?
>
Support were added to firmware about two years ago.
All releases from 18.09 should has it.
Stefan,
Regards.
e.
So I can remove this use of num_active_cpus.
Stefan,
Regards.
s supported in the existing
> driver at all, given this patch set. If it isn't supported without the
> firmware's
> help, then we should _not_ be negotiating flow control with the link partner
> unless we actually support it, so the Pause and Asym_Pause bits in
> mvpp2_phylink_validate() should be cleared.
RX FC supported, issue only with TX FC.
Stefan,
Regards.
> >
> > +/* Routine calculate single queue shares address space */ static int
> > +mvpp22_calc_shared_addr_space(struct mvpp2_port *port) {
> > + /* If number of CPU's greater than number of threads, return last
> > +* address space
> > +*/
> > + if (num_active_cpus() >=
ndrew
TX FC never were really supported. MAC or PHY can negotiated flow control.
But MAC would never trigger FC frame.
Should I prepare separate patch that disable TX FC till we merge this patches?
Regards,
Stefan.
thing in this patch that disables TX flow control, which means
> this warning message is misleading.
OK, I would change to TX FC not supported.
Stefan.
m_pool_update_fc(port, port->pool_short,
> false);
> > + }
> > + }
>
>
> This looks wrong. Flow control is normally the result of auto negotiation.
> Both
> ends need to agree to it. Which is why
> mvpp2_ethtool_set_pause_param() passes the users request onto phylink.
> phylink will handle the autoneg and then ask the MAC to setup flow control
> depending on the result in mvpp2_mac_link_up().
>
> Andrew
Ok, I would move it to mvpp2_mac_link_up.
Stefan,
Thanks.
>
> > > Should there be -EPROBE_DEFER handling in here somewhere? The SRAM
> > > is a device, so it might not of been probed yet?
> >
>
> > No, firmware probed during bootloader boot and we can use SRAM. SRAM
> > memory can be safely used.
>
> A previous patch added:
>
> +
> External Email
>
> --
> On Sun, Jan 10, 2021 at 05:30:10PM +0200, stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > BM pool size increased to support Firmware Flow Control.
> > Min
> -Original Message-
> From: Andrew Lunn
> Sent: Sunday, January 10, 2021 7:05 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel.org;
Hi Jeremy,
+add Nicolas
Am 08.01.21 um 22:13 schrieb Jeremy Linton:
> The rpi4 has a Arasan controller it carries over
> from the rpi3, and a newer eMMC2 controller.
> Because of a couple "quirks" it seems wiser to bind
> these controllers to the same driver that DT is using
> on this platform
Hi,
Ricardo Mestre wrote:
> Stefan Hagen wrote:
>> I can totally relate to this one.
>>
>> Found after a conversation about muscle memory and grepping the
>> source tree for ":wq".
>>
> This issue is present in upstream [0], please take it with them.
,ats=on
>
> [1] https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg09077.html
>
> Reviewed-by: Stefan Hajnoczi
> Signed-off-by: Stefano Garzarella
> ---
>
> The patch is the same of v1, but I re-tested it with:
> - QEMU v5.2.0-551-ga05f8ecd88
> - Linux 5.9.15
On Wed, Dec 16, 2020 at 02:48:03PM +0800, Jason Wang wrote:
> This patch introduces virtqueue groups to vDPA device. The virtqueue
> group is the minimal set of virtqueues that must share an address
> space. And the adddress space identifier could only be attached to
> a specific virtqueue group.
Change the bcm2835 maintainer info in order to handle subsequent SoCs.
After this get_maintainers.pl provides the proper maintainers for
irqchip-bcm2836.
Signed-off-by: Stefan Wahren
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
> + * Locking: called with port lock held and IRQs disabled
> + */
> +#ifdef CONFIG_SERIAL_AMBA_PL011_SOFT_RS485
> +static int pl011_config_rs485(struct uart_port *port,
> + struct serial_rs485 *rs485)
> +{
> + bool was_disabled;
> + struct u
On 11/25/20 10:35 PM, Jarkko Sakkinen wrote:
On Tue, 2020-11-24 at 21:52 +0800, Wang Hai wrote:
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: d8d74ea3c002 ("tpm: ibmvtpm: Wait for buffer to be set before
proceeding")
>
> --
> On Thu, 17 Dec 2020 18:07:58 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > Patch didn't fix any issue, just improve parse flow and align ipv4
> > parse flow with i
> External Email
>
> --
> On Thu, 17 Dec 2020 14:37:28 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > During GoP port 2 Networking Complex Control mode of operation
> >
> Quoting stef...@marvell.com (2020-12-17 18:45:06)
> > From: Stefan Chulski
> >
> > Issue:
> > Flow control frame used to pause GoP(MAC) was delivered to the CPU and
> > created a load on the CPU. Since XOFF/XON frames are used only by MAC,
> > th
> External Email
>
> ------
> Hi Stefan,
>
> Quoting stef...@marvell.com (2020-12-17 18:23:11)
> > From: Stefan Chulski
> >
> > Current PPPoE+IPv6 entry is jumping to 'next-hdr'
> > fie
> On Thu, Dec 17, 2020 at 12:00:49PM +0100, Marcin Wojtas wrote:
> > Hi Stefan,
> >
> > czw., 17 gru 2020 o 10:42 napisał(a):
> > >
> > > From: Stefan Chulski
> > >
> > > Force link UP can be enabled by bootloader during tftpboot and
>
> -Original Message-
> From: Jakub Kicinski
> Sent: Thursday, December 17, 2020 2:42 AM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel.org;
>
the old didn't.
Co-developed-by: Lorena Kretzschmar
Signed-off-by: Lorena Kretzschmar
Signed-off-by: Stefan Saecherl
---
arch/x86/kernel/alternative.c | 16 +++
arch/x86/kernel/kgdb.c| 54 ---
2 files changed, 48 insertions(+), 22 deletions(-)
diff
setup: DMA
engine initialization failed
[ 6630.902835] meson8b-dwmac c941.ethernet eth0: stmmac_open: Hw setup
failed
Fixes: f29cabf240ed ("arm64: dts: meson: use the generic Ethernet PHY reset
GPIO bindings")
Reviewed-by: Martin Blumenstingl
Signed-off-by: Stefan Agner
---
arch/ar
d2310fca4c ("arm64: dts: meson-g12b-ugoos-am6: add initial
device-tree")
Reviewed-by: Martin Blumenstingl
Signed-off-by: Stefan Agner
---
arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g1
5e8f689154 ("arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY
reset line")
Reviewed-by: Martin Blumenstingl
Signed-off-by: Stefan Agner
---
arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/am
ialization failed
[ 34.687850] meson8b-dwmac ff3f.ethernet eth0: stmmac_open: Hw setup
failed
Fixes: 658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet PHY
reset line")
Reviewed-by: Martin Blumenstingl
Signed-off-by: Stefan Agner
---
arch/arm64/boot/dts/amlogic/
c6e82e5341 ("ARM: dts: meson: switch to the generic Ethernet PHY reset
bindings")
Reviewed-by: Martin Blumenstingl
Tested-by: Martin Blumenstingl # on
Odroid-C1+
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/meson8b-odroidc1.dts| 2 +-
arch/arm/boot/dts/meson8m2-mxiii-plus
On 2020-12-05 14:04, Martin Blumenstingl wrote:
> Hi Stefan,
>
> On Tue, Dec 1, 2020 at 2:21 PM Stefan Agner wrote:
>>
>> According to the datasheet (Rev. 1.9) the RTL8211F requires at least
>> 72ms "for internal circuits settling time" before accessing t
-by: Hulk Robot
> Signed-off-by: Zhang Changzhong
> ---
> drivers/vhost/scsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Acked-by: Stefan Hajnoczi
signature.asc
Description: PGP signature
A to/from the virtio-fs DAX Window happen? Yes, the guest could do
it although it's rare.
Is it a great idea to combine VFIO and virtio-fs DAX? Maybe not. It
involves pinning host page cache pages O_o.
Stefan
signature.asc
Description: PGP signature
> Adding AST2400 and AST2600 edac driver support.
>
> Signed-off-by: Troy Lee
Reviewed-by: Stefan Schaeckeler
> ---
drivers/edac/Kconfig | 6 +++---
> drivers/edac/aspeed_edac.c | 7 +--
> 2 files changed, 8 insertions(+), 5 deletions(-)
> diff --git a/d
Hello Troy,
> Hi Stefan,
>
> The driver was ported from latest ASPEED BSP, so I only test with ECC-on/off
> from u-boot and check if driver runs correctly.
I noticed now most changes are these "exports". As you removed them a later
revision, the patch looks now lean and c
Removes an obsolete TODO in the VMBus module and fixes a misleading typo
in the comment for the macro MAX_NUM_CHANNELS, where two digits have been
twisted.
Signed-off-by: Stefan Eschenbacher
Co-developed-by: Max Stolze
Signed-off-by: Max Stolze
---
drivers/hv/hyperv_vmbus.h | 3 +--
1 file
in two locations.
During module initialization sanity checks are applied which will result
in EINVAL or ERANGE if the given value is no multiple of 32 or larger than
MAX_NUM_CHANNELS.
Signed-off-by: Stefan Eschenbacher
Co-developed-by: Max Stolze
Signed-off-by: Max Stolze
---
drivers/hv
The default number of vmbus channels (macro
MAX_NUM_CHANNELS_SUPPORTED_DEFAULT) is made configurable through the new
Kconfig option HYPERV_VMBUS_DEFAULT_CHANNELS.
Signed-off-by: Stefan Eschenbacher
Co-developed-by: Max Stolze
Signed-off-by: Max Stolze
---
drivers/hv/Kconfig| 13
Fixes a misleading typo in the comment for the macro MAX_NUM_CHANNELS,
where two digits have been twisted.
Signed-off-by: Stefan Eschenbacher
Co-developed-by: Max Stolze
Signed-off-by: Max Stolze
---
drivers/hv/hyperv_vmbus.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
. So if you'd
like us to fix that we'd be happy for some input on how to settle it with
Kconfig.
Signed-off-by: Stefan Eschenbacher
Co-developed-by: Max Stolze
Signed-off-by: Max Stolze
Stefan Eschenbacher (3):
drivers/hv: make max_num_channels_supported configurable
drivers/hv: fix
On Wed, Dec 02, 2020 at 10:45:11AM -0500, Peter Xu wrote:
> On Wed, Dec 02, 2020 at 02:33:56PM +0000, Stefan Hajnoczi wrote:
> > On Wed, Nov 25, 2020 at 10:57:11AM -0500, Peter Xu wrote:
> > > On Wed, Nov 25, 2020 at 01:05:25AM +, Justin He wrote:
> > > > > I'
.
That way it just tells the driver in which direction to send packets
without implying that sibling communication is possible (it's not
allowed by default on any transport).
I don't have a strong opinion on this but wanted to suggest the idea.
Stefan
signature.asc
Description: PGP signature
window region firstly, then remap the
> > sub
> > region of that cache window with read or write permission. I guess this
> > might
> > be an security concern. Just CC virtiofs expert Stefan to answer it more
> > accurately.
>
> Yep. Since my previous sentence was cut of
5e8f689154 ("arm64: dts: meson: g12a: x96-max: fix the Ethernet PHY
reset line")
Signed-off-by: Stefan Agner
---
arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12a-x96-max.dts
b
d2310fca4c ("arm64: dts: meson-g12b-ugoos-am6: add initial
device-tree")
Signed-off-by: Stefan Agner
---
arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-w400.dtsi
b/arch/arm64/boot/dt
c6e82e5341 ("ARM: dts: meson: switch to the generic Ethernet PHY reset
bindings")
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/meson8b-odroidc1.dts| 2 +-
arch/arm/boot/dts/meson8m2-mxiii-plus.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/
ialization failed
[ 34.687850] meson8b-dwmac ff3f.ethernet eth0: stmmac_open: Hw setup
failed
Fixes: 658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet PHY
reset line")
Signed-off-by: Stefan Agner
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dtsi | 2 +
setup: DMA
engine initialization failed
[ 6630.902835] meson8b-dwmac c941.ethernet eth0: stmmac_open: Hw setup
failed
Fixes: f29cabf240ed ("arm64: dts: meson: use the generic Ethernet PHY reset
GPIO bindings")
Signed-off-by: Stefan Agner
---
arch/arm64/boot/dts/amlogic/meson-gxb
On 2020-12-01 09:31, Jerome Brunet wrote:
> On Tue 01 Dec 2020 at 01:25, Stefan Agner wrote:
>
>> According to the datasheet (Rev. 1.4, page 30) the RTL8211F requires
>> at least 50ms "for internal circuits settling time" before accessing
>> the PHY re
MA
engine initialization failed
[ 34.687850] meson8b-dwmac ff3f.ethernet eth0: stmmac_open: Hw setup
failed
Fixes: 658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet PHY
reset line")
Signed-off-by: Stefan Agner
---
arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2
re are quite some non-trivial changes. I'll have a look over the coming
weekend.
Testing an edac driver comes with challenges. Did you test your code? If so,
how?
That's how I was testing my original edac 2500 driver
http://students.engr.scu.edu/~sschaeck/misc/aspeed-edac.html
Stefan
Hi tglx,
On 11/27/20 12:45 AM, Thomas Gleixner wrote:
> Stefan,
>
> On Wed, Nov 25 2020 at 14:41, Stefan Bühler wrote:
>> On 11/25/20 12:54 PM, Thomas Gleixner wrote:
>>> On Wed, Sep 16 2020 at 12:12, Stefan Bühler wrote:
>>> Can you please provide the output
Hi tglx,
On 11/25/20 12:54 PM, Thomas Gleixner wrote:
> Stefan,
>
> On Wed, Sep 16 2020 at 12:12, Stefan Bühler wrote:
>
> sorry for the delay. This fell through the cracks.
>
>> this quirk breaks our serial ports PCIe card (i.e. we don't see any
>> output from
static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
ibmvtpm->rtce_buf != NULL,
HZ)) {
dev_err(dev, "CRQ response timed out\n");
+ rc = -ETIMEDOUT;
goto init_irq_cleanup;
}
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, November 23, 2020 7:30 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, November 23, 2020 5:52 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel
> > > On Mon, Nov 23, 2020 at 04:52:40PM +0200, stef...@marvell.com wrote:
> > > > From: Stefan Chulski
> > > >
> > > > Tx/Rx FIFO is a HW resource limited by total size, but shared by
> > > > all ports of same CP110 and impacting port-pe
> -Original Message-
> From: Russell King - ARM Linux admin
> Sent: Monday, November 23, 2020 5:11 PM
> To: Stefan Chulski
> Cc: net...@vger.kernel.org; thomas.petazz...@bootlin.com;
> da...@davemloft.net; Nadav Haklai ; Yan Markman
> ; linux-kernel@vger.kernel.org;
;
> Cc: Jorgen Hansen
> Cc: Dexuan Cui
> Fixes: c0cfa2d8a788 ("vsock: add multi-transports support")
> Reported-by: Andra Paraschiv
> Tested-by: Andra Paraschiv
> Signed-off-by: Stefano Garzarella
> ---
> net/vmw_vsock/af_vsock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Stefan Hajnoczi
signature.asc
Description: PGP signature
> -Original Message-
> From: stef...@marvell.com
> Sent: Wednesday, November 18, 2020 8:21 PM
> To: net...@vger.kernel.org
> Cc: thomas.petazz...@bootlin.com; da...@davemloft.net; Nadav Haklai
> ; Yan Markman ; linux-
> ker...@vger.kernel.org; Stefan Chulski
&
On Tue, Nov 17, 2020 at 06:38:11PM +0100, Stefano Garzarella wrote:
> On Tue, Nov 17, 2020 at 04:43:42PM +0000, Stefan Hajnoczi wrote:
> > On Tue, Nov 17, 2020 at 03:16:20PM +0100, Stefano Garzarella wrote:
> > > On Tue, Nov 17, 2020 at 11:11:21AM +, Stefan Hajnoczi wrote:
&
On Tue, Nov 17, 2020 at 03:16:20PM +0100, Stefano Garzarella wrote:
> On Tue, Nov 17, 2020 at 11:11:21AM +0000, Stefan Hajnoczi wrote:
> > On Fri, Nov 13, 2020 at 02:47:04PM +0100, Stefano Garzarella wrote:
> > > +static void vdpasim_blk_work(struct work_struct *work)
>
On Fri, Nov 13, 2020 at 02:47:12PM +0100, Stefano Garzarella wrote:
> diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
> b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
> index 8e41b3ab98d5..68e74383322f 100644
> --- a/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
> +++ b/drivers/vdpa/vdpa_sim/vdpa_sim_blk.c
> @@
virtqueue's iov field in riov and wiov
> to use them with vringh_getdesc_iotlb().
Is riov/wiov naming common? VIRTIO uses "in" (device-to-driver) and
"out" (driver-to-device). Using VIRTIO terminology might be clearer.
Stefan
signature.asc
Description: PGP signature
On Fri, Nov 13, 2020 at 02:47:06PM +0100, Stefano Garzarella wrote:
> Move device properties used during the entire life cycle in a new
> structure to simplify the copy of these fields during the vdpasim
> initialization.
>
> Signed-off-by: Stefano Garzarella
> ---
>
On Fri, Nov 13, 2020 at 02:47:04PM +0100, Stefano Garzarella wrote:
> +static void vdpasim_blk_work(struct work_struct *work)
> +{
> + struct vdpasim *vdpasim = container_of(work, struct vdpasim, work);
> + u8 status = VIRTIO_BLK_S_OK;
> + int i;
> +
> + spin_lock(>lock);
> +
> +
On Fri, Nov 13, 2020 at 02:47:01PM +0100, Stefano Garzarella wrote:
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index 2754f3069738..fb0411594963 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
ges? Wasn't aware of that.
Since only ARM_LPAE selects CONFIG_PHYS_ADDR_T_64BIT it really is safe
to assume 32 bits for non-LPAE systems.
I guess that would mean adding a #define MAX_POSSIBLE_PHYSMEM_BITS 32 to
arch/arm/include/asm/pgtable-2level.h and a MAX_POSSIBLE_PHYSMEM_BITS 40
in arch/arm/include/asm/pgtable-3level.h. Seems straight forward and
would solve the problem I had. I can prepare a patch for ARM, not sure
about the other architectures...
--
Stefan
On 2020-11-08 07:46, Mike Rapoport wrote:
> On Sat, Nov 07, 2020 at 04:22:06PM +0100, Stefan Agner wrote:
>> Most architectures define MAX_PHYSMEM_BITS in asm/sparsemem.h and don't
>> include it in asm/pgtable.h. Include asm/sparsemem.h directly to get
>> the MAX_PHYSM
On 2020-11-08 01:56, Andrew Morton wrote:
> On Sat, 7 Nov 2020 16:22:06 +0100 Stefan Agner wrote:
>
>> Most architectures define MAX_PHYSMEM_BITS in asm/sparsemem.h and don't
>> include it in asm/pgtable.h. Include asm/sparsemem.h directly to get
>> the MAX_PH
bfc0: 0003d2e0 b6f7b6f0 0076 befcbb20 befcbb28
bfe0: b6f4e060 befcbad8 b6f23e0c b6dc4a80
Code: e5927000 e0050391 e0871005 e5918018 (e5983000)
Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
Signed-off-by: Stefan Agne
Hello.
On 06.11.20 09:10, Alex Shi wrote:
Signed-off-by: Alex Shi
Cc: Alexander Aring
Cc: Stefan Schmidt
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: linux-w...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/ieee802154/nl802154.c | 4 ---
igned-off-by: Stefano Garzarella
> ---
> drivers/vhost/vsock.c | 68 +++++--
> 1 file changed, 65 insertions(+), 3 deletions(-)
Reviewed-by: Stefan Hajnoczi
signature.asc
Description: PGP signature
Greetings my beloved,
My name is Mrs.Julianna Stefan Ndoi,I am a deaf woman and also a cancer
patient who had decided to donate what I have to you for God's works. I
want to donate $8.5 million to you so that you will use part of the this
fund to help the poor ones,while you use the rest for your
Am Sonntag, den 18.10.2020, 10:05 +0200 schrieb Stefan Gottwald:
> Due to security reasons the rsp struct is not zerod out in one case this will
> also zero out the former set rsp.id which seems to be wrong.
>
> Signed-off-by: Stefan Gottwald
> ---
> net/bluetooth/a2mp.c
Due to security reasons the rsp struct is not zerod out in one case this will
also zero out the former set rsp.id which seems to be wrong.
Signed-off-by: Stefan Gottwald
---
net/bluetooth/a2mp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/a2mp.c b/net
sary to capture the full log.
I have done so today.
It's at: https://gitlab.freedesktop.org/drm/intel/-/issues/2579
--
Stefan Joosten
AT Computing BV
Sharing and growing together Tel +31 24 352 72 82
Arnhemsestraatweg 33 i...@atcomputing.nl
6881 ND Velp
Hi Laurent,
On 05.10.20 15:08, Laurent Pinchart wrote:
Hi Stefan,
On Mon, Oct 05, 2020 at 11:28:21AM +0200, Stefan Riedmüller wrote:
On 02.10.20 02:05, Laurent Pinchart wrote:
On Wed, Sep 30, 2020 at 12:51:33PM +0200, Stefan Riedmueller wrote:
From: Dirk Bender
To prevent corrupted frames
Am 07.10.20 um 12:44 schrieb Christian Borntraeger:
>
> On 07.10.20 12:39, Christoph Hellwig wrote:
>> On Wed, Oct 07, 2020 at 11:34:17AM +0200, Christian Borntraeger wrote:
>>> On 19.05.20 16:22, Stefan Haberland wrote:
>>>> The IBM partition parser requires devi
have (a link) to instructions how to flash the device?
Btw, there was also a driver for the Bluetooth controller on the ML
once, maybe a good time to revive that:
https://spinics.net/lists/linux-input/msg56288.html
--
Stefan
>
> Changelog:
> v3: - Reorder aliases per Dmitry Osipenko's rev
o Carvalho Chehab
---
Documentation/networking/ieee802154.rst | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
Acked-by: Stefan Schmidt
regards
Stefan Schmidt
On 06.10.20 16:03, Mauro Carvalho Chehab wrote:
There are some warnings produced with Sphinx 3.x:
Documentation/networking/ieee802154.rst:29: WARNING: Error in
declarator or parameters
Invalid C declaration: Expecting "(" in parameters. [error at 7]
int sd =
s.
>
> I think total sgs is actually max number of sgs and warning
> should probably be.
>
> WARN_ON(out_sgs + in_sgs > total_sgs)
>
> Stefan, WDYT?
It should be possible to calculate total_sgs precisely (not a maximum).
Treating it as a maximum could hide bugs.
Maybe sg_co
Hi Laurent,
On 02.10.20 02:06, Laurent Pinchart wrote:
Hi Stefan,
On Thu, Oct 01, 2020 at 10:56:24AM +0200, Stefan Riedmüller wrote:
On 30.09.20 13:38, Laurent Pinchart wrote:
On Wed, Sep 30, 2020 at 12:51:31PM +0200, Stefan Riedmueller wrote:
From: Enrico Scholz
Implement g_register
Hi Laurent,
On 02.10.20 01:53, Laurent Pinchart wrote:
Hi Stefan,
On Thu, Oct 01, 2020 at 11:07:00AM +0200, Stefan Riedmüller wrote:
On 30.09.20 13:42, Laurent Pinchart wrote:
On Wed, Sep 30, 2020 at 12:51:29PM +0200, Stefan Riedmueller wrote:
From: Christian Hemp
Aside from 12 bit
Hi Laurent,
On 02.10.20 02:05, Laurent Pinchart wrote:
Hi Stefan,
Thank you for the patch.
On Wed, Sep 30, 2020 at 12:51:33PM +0200, Stefan Riedmueller wrote:
From: Dirk Bender
To prevent corrupted frames after starting and stopping the sensor it's
s/it's/its/
thanks, I'll fix
send a separate patch for the DT bindings.
Regards,
Stefan
n part, the developer would only have to update the CS_N
>> > macro to the number of CS IDs that are needed.
>>
>> But in that case, shouldn't you change it to "int cs[CS_N]" and get
>> rid of the struct_size() stuff?
>
> I do agree with Jann, I think it's best to consider this a fixed-size
> array for now. If we ever want to extend the number of supported CS,
> there is much more rework involved anyway.
I agree, too, just assume this is a fixed-size array of 1 element.
In fact, I am not aware of a design which needs multiple chip selects.
--
Stefan
301 - 400 of 12116 matches
Mail list logo
