* The audit "context" and when to expect it.
From: Casey Schaufler @ 2020-05-29 17:59 UTC (permalink / raw)
To: Linux-Audit Mailing List; +Cc: Richard Guy Briggs
In-Reply-To: <45ce3357-ca82-8721-22d6-dabe751ad8fa.ref@schaufler-ca.com>
What does a NULL audit context (e.g. ab->cxt == NULL) tell
me about the status of the audit buffer? It seems like it should
be telling me that the audit buffer is being created for some
purpose unrelated to the current task. And yet there are places
where information is pulled from the current task even when
the cxt is NULL.
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: [PATCH v3 00/28] KVM: nSVM: event fixes and migration support
From: Sean Christopherson @ 2020-05-29 17:59 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: linux-kernel, kvm
In-Reply-To: <20200529153934.11694-1-pbonzini@redhat.com>
> [PATCH v3 00/28] KVM: nSVM: event fixes and migration support
You've got something funky going on with the way you generate cover letters,
looks like it doesn't count patches authored by someone else. The 'v3' is
also missing from the patches, though I suppose some heathens do that on
purpose.
> Paolo Bonzini (28):
>
> Vitaly Kuznetsov (2):
^ permalink raw reply
* Re: [PATCHv4 1/2] blk-mq: blk-mq: provide forced completion method
From: Alan Adamson @ 2020-05-29 18:02 UTC (permalink / raw)
To: Keith Busch, linux-nvme, hch, sagi, linux-block, axboe
In-Reply-To: <20200529145200.3545747-1-kbusch@kernel.org>
Passes my tests, thanks.
Reviewed-by: Alan Adamson <alan.adamson@oracle.com>
On 5/29/20 7:51 AM, Keith Busch wrote:
> Drivers may need to bypass error injection for error recovery. Rename
> __blk_mq_complete_request() to blk_mq_force_complete_rq() and export
> that function so drivers may skip potential fake timeouts after they've
> reclaimed lost requests.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
> block/blk-mq.c | 15 +++++++++++++--
> include/linux/blk-mq.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index cac11945f602..560a114a82f8 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -556,7 +556,17 @@ static void __blk_mq_complete_request_remote(void *data)
> q->mq_ops->complete(rq);
> }
>
> -static void __blk_mq_complete_request(struct request *rq)
> +/**
> + * blk_mq_force_complete_rq() - Force complete the request, bypassing any error
> + * injection that could drop the completion.
> + * @rq: Request to be force completed
> + *
> + * Drivers should use blk_mq_complete_request() to complete requests in their
> + * normal IO path. For timeout error recovery, drivers may call this forced
> + * completion routine after they've reclaimed timed out requests to bypass
> + * potentially subsequent fake timeouts.
> + */
> +void blk_mq_force_complete_rq(struct request *rq)
> {
> struct blk_mq_ctx *ctx = rq->mq_ctx;
> struct request_queue *q = rq->q;
> @@ -602,6 +612,7 @@ static void __blk_mq_complete_request(struct request *rq)
> }
> put_cpu();
> }
> +EXPORT_SYMBOL_GPL(blk_mq_force_complete_rq);
>
> static void hctx_unlock(struct blk_mq_hw_ctx *hctx, int srcu_idx)
> __releases(hctx->srcu)
> @@ -635,7 +646,7 @@ bool blk_mq_complete_request(struct request *rq)
> {
> if (unlikely(blk_should_fake_timeout(rq->q)))
> return false;
> - __blk_mq_complete_request(rq);
> + blk_mq_force_complete_rq(rq);
> return true;
> }
> EXPORT_SYMBOL(blk_mq_complete_request);
> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> index d7307795439a..856bb10993cf 100644
> --- a/include/linux/blk-mq.h
> +++ b/include/linux/blk-mq.h
> @@ -494,6 +494,7 @@ void blk_mq_requeue_request(struct request *rq, bool kick_requeue_list);
> void blk_mq_kick_requeue_list(struct request_queue *q);
> void blk_mq_delay_kick_requeue_list(struct request_queue *q, unsigned long msecs);
> bool blk_mq_complete_request(struct request *rq);
> +void blk_mq_force_complete_rq(struct request *rq);
> bool blk_mq_bio_list_merge(struct request_queue *q, struct list_head *list,
> struct bio *bio, unsigned int nr_segs);
> bool blk_mq_queue_stopped(struct request_queue *q);
^ permalink raw reply
* Re: [PATCHv4 1/2] blk-mq: blk-mq: provide forced completion method
From: Alan Adamson @ 2020-05-29 18:02 UTC (permalink / raw)
To: Keith Busch, linux-nvme, hch, sagi, linux-block, axboe
In-Reply-To: <20200529145200.3545747-1-kbusch@kernel.org>
Passes my tests, thanks.
Reviewed-by: Alan Adamson <alan.adamson@oracle.com>
On 5/29/20 7:51 AM, Keith Busch wrote:
> Drivers may need to bypass error injection for error recovery. Rename
> __blk_mq_complete_request() to blk_mq_force_complete_rq() and export
> that function so drivers may skip potential fake timeouts after they've
> reclaimed lost requests.
>
> Signed-off-by: Keith Busch <kbusch@kernel.org>
> ---
> block/blk-mq.c | 15 +++++++++++++--
> include/linux/blk-mq.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index cac11945f602..560a114a82f8 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -556,7 +556,17 @@ static void __blk_mq_complete_request_remote(void *data)
> q->mq_ops->complete(rq);
> }
>
> -static void __blk_mq_complete_request(struct request *rq)
> +/**
> + * blk_mq_force_complete_rq() - Force complete the request, bypassing any error
> + * injection that could drop the completion.
> + * @rq: Request to be force completed
> + *
> + * Drivers should use blk_mq_complete_request() to complete requests in their
> + * normal IO path. For timeout error recovery, drivers may call this forced
> + * completion routine after they've reclaimed timed out requests to bypass
> + * potentially subsequent fake timeouts.
> + */
> +void blk_mq_force_complete_rq(struct request *rq)
> {
> struct blk_mq_ctx *ctx = rq->mq_ctx;
> struct request_queue *q = rq->q;
> @@ -602,6 +612,7 @@ static void __blk_mq_complete_request(struct request *rq)
> }
> put_cpu();
> }
> +EXPORT_SYMBOL_GPL(blk_mq_force_complete_rq);
>
> static void hctx_unlock(struct blk_mq_hw_ctx *hctx, int srcu_idx)
> __releases(hctx->srcu)
> @@ -635,7 +646,7 @@ bool blk_mq_complete_request(struct request *rq)
> {
> if (unlikely(blk_should_fake_timeout(rq->q)))
> return false;
> - __blk_mq_complete_request(rq);
> + blk_mq_force_complete_rq(rq);
> return true;
> }
> EXPORT_SYMBOL(blk_mq_complete_request);
> diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
> index d7307795439a..856bb10993cf 100644
> --- a/include/linux/blk-mq.h
> +++ b/include/linux/blk-mq.h
> @@ -494,6 +494,7 @@ void blk_mq_requeue_request(struct request *rq, bool kick_requeue_list);
> void blk_mq_kick_requeue_list(struct request_queue *q);
> void blk_mq_delay_kick_requeue_list(struct request_queue *q, unsigned long msecs);
> bool blk_mq_complete_request(struct request *rq);
> +void blk_mq_force_complete_rq(struct request *rq);
> bool blk_mq_bio_list_merge(struct request_queue *q, struct list_head *list,
> struct bio *bio, unsigned int nr_segs);
> bool blk_mq_queue_stopped(struct request_queue *q);
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* [PATCH] hw/misc/imx6ul_ccm.c: Implement non writable bits in CCM registers
From: Jean-Christophe Dubois @ 2020-05-29 18:00 UTC (permalink / raw)
To: qemu-arm; +Cc: peter.maydell, peter.chubb, qemu-devel, Jean-Christophe Dubois
Some bits of the CCM registers are non writable.
This was left undone in the initial commit (all bits of registers were
writable).
This patch add the required code to protect non writable bits.
Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net>
---
hw/misc/imx6ul_ccm.c | 81 +++++++++++++++++++++++++++++++++++++-------
1 file changed, 68 insertions(+), 13 deletions(-)
diff --git a/hw/misc/imx6ul_ccm.c b/hw/misc/imx6ul_ccm.c
index a2fc1d0364a..ede845fde8e 100644
--- a/hw/misc/imx6ul_ccm.c
+++ b/hw/misc/imx6ul_ccm.c
@@ -19,6 +19,62 @@
#include "trace.h"
+static const uint32_t ccm_mask[CCM_MAX] = {
+ [CCM_CCR] = 0xf01fef80,
+ [CCM_CCDR] = 0xfffeffff,
+ [CCM_CSR] = 0xffffffff,
+ [CCM_CCSR] = 0xfffffef2,
+ [CCM_CACRR] = 0xfffffff8,
+ [CCM_CBCDR] = 0xc1f8e000,
+ [CCM_CBCMR] = 0xfc03cfff,
+ [CCM_CSCMR1] = 0x80700000,
+ [CCM_CSCMR2] = 0xe01ff003,
+ [CCM_CSCDR1] = 0xfe00c780,
+ [CCM_CS1CDR] = 0xfe00fe00,
+ [CCM_CS2CDR] = 0xf8007000,
+ [CCM_CDCDR] = 0xf00fffff,
+ [CCM_CHSCCDR] = 0xfffc01ff,
+ [CCM_CSCDR2] = 0xfe0001ff,
+ [CCM_CSCDR3] = 0xffffc1ff,
+ [CCM_CDHIPR] = 0xffffffff,
+ [CCM_CTOR] = 0x00000000,
+ [CCM_CLPCR] = 0xf39ff01c,
+ [CCM_CISR] = 0xfb85ffbe,
+ [CCM_CIMR] = 0xfb85ffbf,
+ [CCM_CCOSR] = 0xfe00fe00,
+ [CCM_CGPR] = 0xfffc3fea,
+ [CCM_CCGR0] = 0x00000000,
+ [CCM_CCGR1] = 0x00000000,
+ [CCM_CCGR2] = 0x00000000,
+ [CCM_CCGR3] = 0x00000000,
+ [CCM_CCGR4] = 0x00000000,
+ [CCM_CCGR5] = 0x00000000,
+ [CCM_CCGR6] = 0x00000000,
+ [CCM_CMEOR] = 0xafffff1f,
+};
+
+static const uint32_t analog_mask[CCM_ANALOG_MAX] = {
+ [CCM_ANALOG_PLL_ARM] = 0xfff60f80,
+ [CCM_ANALOG_PLL_USB1] = 0xfffe0fbc,
+ [CCM_ANALOG_PLL_USB2] = 0xfffe0fbc,
+ [CCM_ANALOG_PLL_SYS] = 0xfffa0ffe,
+ [CCM_ANALOG_PLL_SYS_SS] = 0x00000000,
+ [CCM_ANALOG_PLL_SYS_NUM] = 0xc0000000,
+ [CCM_ANALOG_PLL_SYS_DENOM] = 0xc0000000,
+ [CCM_ANALOG_PLL_AUDIO] = 0xffe20f80,
+ [CCM_ANALOG_PLL_AUDIO_NUM] = 0xc0000000,
+ [CCM_ANALOG_PLL_AUDIO_DENOM] = 0xc0000000,
+ [CCM_ANALOG_PLL_VIDEO] = 0xffe20f80,
+ [CCM_ANALOG_PLL_VIDEO_NUM] = 0xc0000000,
+ [CCM_ANALOG_PLL_VIDEO_DENOM] = 0xc0000000,
+ [CCM_ANALOG_PLL_ENET] = 0xffc20ff0,
+ [CCM_ANALOG_PFD_480] = 0x40404040,
+ [CCM_ANALOG_PFD_528] = 0x40404040,
+ [PMU_MISC0] = 0x01fe8306,
+ [PMU_MISC1] = 0x07fcede0,
+ [PMU_MISC2] = 0x005f5f5f,
+};
+
static const char *imx6ul_ccm_reg_name(uint32_t reg)
{
static char unknown[20];
@@ -596,11 +652,8 @@ static void imx6ul_ccm_write(void *opaque, hwaddr offset, uint64_t value,
trace_ccm_write_reg(imx6ul_ccm_reg_name(index), (uint32_t)value);
- /*
- * We will do a better implementation later. In particular some bits
- * cannot be written to.
- */
- s->ccm[index] = (uint32_t)value;
+ s->ccm[index] = (s->ccm[index] & ccm_mask[index]) |
+ ((uint32_t)value & ~ccm_mask[index]);
}
static uint64_t imx6ul_analog_read(void *opaque, hwaddr offset, unsigned size)
@@ -737,7 +790,8 @@ static void imx6ul_analog_write(void *opaque, hwaddr offset, uint64_t value,
* the REG_NAME register. So we change the value of the
* REG_NAME register, setting bits passed in the value.
*/
- s->analog[index - 1] |= value;
+ s->analog[index - 1] = s->analog[index - 1] |
+ (value & ~analog_mask[index - 1]);
break;
case CCM_ANALOG_PLL_ARM_CLR:
case CCM_ANALOG_PLL_USB1_CLR:
@@ -762,7 +816,8 @@ static void imx6ul_analog_write(void *opaque, hwaddr offset, uint64_t value,
* the REG_NAME register. So we change the value of the
* REG_NAME register, unsetting bits passed in the value.
*/
- s->analog[index - 2] &= ~value;
+ s->analog[index - 2] = s->analog[index - 2] &
+ ~(value & ~analog_mask[index - 2]);
break;
case CCM_ANALOG_PLL_ARM_TOG:
case CCM_ANALOG_PLL_USB1_TOG:
@@ -787,14 +842,14 @@ static void imx6ul_analog_write(void *opaque, hwaddr offset, uint64_t value,
* the REG_NAME register. So we change the value of the
* REG_NAME register, toggling bits passed in the value.
*/
- s->analog[index - 3] ^= value;
+ s->analog[index - 3] = (s->analog[index - 3] &
+ analog_mask[index - 3]) |
+ ((value ^ s->analog[index - 3]) &
+ ~analog_mask[index - 3]);
break;
default:
- /*
- * We will do a better implementation later. In particular some bits
- * cannot be written to.
- */
- s->analog[index] = value;
+ s->analog[index] = (s->analog[index] & analog_mask[index]) |
+ (value & ~analog_mask[index]);
break;
}
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4] fetch: allow adding a filter after initial clone.
From: Junio C Hamano @ 2020-05-29 18:00 UTC (permalink / raw)
To: Xin Li; +Cc: git, jrnieder, sandals, iankaz
In-Reply-To: <xmqqblm71sk1.fsf@gitster.c.googlers.com>
Junio C Hamano <gitster@pobox.com> writes:
> Which is slightly different from what you did with the three-way
> split of verify_repository_format(), which made the "eligibility"
> thing not to care about unknown extensions in a repository v1 and
> higher. I actually think we should refuse to update v1 or v2
> repository to v3 with a running Git that knows only about v1
> (i.e. the repository before upgrading may or may not be something we
> understand, and if we do not understand it, we shouldn't touch it).
It does not change the conclusion, but I think the above sample
situation would not make much sense---a caller that asks this
function to upgrade the repository to v3 when the version of Git it
is linked in does not understand v3 is simply buggy.
But we should still refuse to update v1 to v2 with a version of Git
that understands v2 if the repository has some extension that we do
not know about, so
(1) if upgrading from v0, there must be no "extensions.*"; and
(2) if upgrading from other versions, there must be no
"extensions.*" we do not recognise.
I suggested would still be the reasonably defensive rule.
Thanks.
^ permalink raw reply
* Re: [PATCH 8/8] ARM: OMAP2: Use custom soc attribute group instead of device_create_file
From: Tony Lindgren @ 2020-05-29 18:01 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-kernel, linux-arm-kernel, Arnd Bergmann, Greg Kroah-Hartman,
linux-omap
In-Reply-To: <20200523170859.50003-9-sudeep.holla@arm.com>
* Sudeep Holla <sudeep.holla@arm.com> [200523 17:10]:
> Commit c31e73121f4c ("base: soc: Handle custom soc information sysfs
> entries") introduced custom soc attribute group in soc_device_attribute
> structure but there are no users treewide. While trying to understand
> the motivation and tried to use it, it was found lot of existing custom
> attributes can moved to use it instead of device_create_file.
>
> Though most of these never remove/cleanup the custom attribute as they
> never call soc_device_unregister, using these custom attribute group
> eliminate the need for any cleanup as the driver infrastructure will
> take care of that.
>
> Let us remove device_create_file and start using the custom attribute
> group in soc_device_attribute.
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH 8/8] ARM: OMAP2: Use custom soc attribute group instead of device_create_file
From: Tony Lindgren @ 2020-05-29 18:01 UTC (permalink / raw)
To: Sudeep Holla
Cc: Greg Kroah-Hartman, linux-omap, Arnd Bergmann, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200523170859.50003-9-sudeep.holla@arm.com>
* Sudeep Holla <sudeep.holla@arm.com> [200523 17:10]:
> Commit c31e73121f4c ("base: soc: Handle custom soc information sysfs
> entries") introduced custom soc attribute group in soc_device_attribute
> structure but there are no users treewide. While trying to understand
> the motivation and tried to use it, it was found lot of existing custom
> attributes can moved to use it instead of device_create_file.
>
> Though most of these never remove/cleanup the custom attribute as they
> never call soc_device_unregister, using these custom attribute group
> eliminate the need for any cleanup as the driver infrastructure will
> take care of that.
>
> Let us remove device_create_file and start using the custom attribute
> group in soc_device_attribute.
Acked-by: Tony Lindgren <tony@atomide.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] hw/net/imx_fec.c: Convert debug fprintf() to trace event
From: Jean-Christophe Dubois @ 2020-05-29 18:00 UTC (permalink / raw)
To: qemu-arm; +Cc: peter.maydell, peter.chubb, qemu-devel, Jean-Christophe Dubois
Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net>
---
hw/net/imx_fec.c | 101 ++++++++++++++++++--------------------------
hw/net/trace-events | 18 ++++++++
2 files changed, 58 insertions(+), 61 deletions(-)
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
index 7adcc9df654..823dac0603b 100644
--- a/hw/net/imx_fec.c
+++ b/hw/net/imx_fec.c
@@ -31,34 +31,11 @@
#include "qemu/module.h"
#include "net/checksum.h"
#include "net/eth.h"
+#include "trace.h"
/* For crc32 */
#include <zlib.h>
-#ifndef DEBUG_IMX_FEC
-#define DEBUG_IMX_FEC 0
-#endif
-
-#define FEC_PRINTF(fmt, args...) \
- do { \
- if (DEBUG_IMX_FEC) { \
- fprintf(stderr, "[%s]%s: " fmt , TYPE_IMX_FEC, \
- __func__, ##args); \
- } \
- } while (0)
-
-#ifndef DEBUG_IMX_PHY
-#define DEBUG_IMX_PHY 0
-#endif
-
-#define PHY_PRINTF(fmt, args...) \
- do { \
- if (DEBUG_IMX_PHY) { \
- fprintf(stderr, "[%s.phy]%s: " fmt , TYPE_IMX_FEC, \
- __func__, ##args); \
- } \
- } while (0)
-
#define IMX_MAX_DESC 1024
static const char *imx_default_reg_name(IMXFECState *s, uint32_t index)
@@ -262,43 +239,45 @@ static void imx_eth_update(IMXFECState *s);
* For now we don't handle any GPIO/interrupt line, so the OS will
* have to poll for the PHY status.
*/
-static void phy_update_irq(IMXFECState *s)
+static void imx_phy_update_irq(IMXFECState *s)
{
imx_eth_update(s);
}
-static void phy_update_link(IMXFECState *s)
+static void imx_phy_update_link(IMXFECState *s)
{
/* Autonegotiation status mirrors link status. */
if (qemu_get_queue(s->nic)->link_down) {
- PHY_PRINTF("link is down\n");
+ trace_imx_phy_update_link("down");
s->phy_status &= ~0x0024;
s->phy_int |= PHY_INT_DOWN;
} else {
- PHY_PRINTF("link is up\n");
+ trace_imx_phy_update_link("up");
s->phy_status |= 0x0024;
s->phy_int |= PHY_INT_ENERGYON;
s->phy_int |= PHY_INT_AUTONEG_COMPLETE;
}
- phy_update_irq(s);
+ imx_phy_update_irq(s);
}
static void imx_eth_set_link(NetClientState *nc)
{
- phy_update_link(IMX_FEC(qemu_get_nic_opaque(nc)));
+ imx_phy_update_link(IMX_FEC(qemu_get_nic_opaque(nc)));
}
-static void phy_reset(IMXFECState *s)
+static void imx_phy_reset(IMXFECState *s)
{
+ trace_imx_phy_reset();
+
s->phy_status = 0x7809;
s->phy_control = 0x3000;
s->phy_advertise = 0x01e1;
s->phy_int_mask = 0;
s->phy_int = 0;
- phy_update_link(s);
+ imx_phy_update_link(s);
}
-static uint32_t do_phy_read(IMXFECState *s, int reg)
+static uint32_t imx_phy_read(IMXFECState *s, int reg)
{
uint32_t val;
@@ -332,7 +311,7 @@ static uint32_t do_phy_read(IMXFECState *s, int reg)
case 29: /* Interrupt source. */
val = s->phy_int;
s->phy_int = 0;
- phy_update_irq(s);
+ imx_phy_update_irq(s);
break;
case 30: /* Interrupt mask */
val = s->phy_int_mask;
@@ -352,14 +331,14 @@ static uint32_t do_phy_read(IMXFECState *s, int reg)
break;
}
- PHY_PRINTF("read 0x%04x @ %d\n", val, reg);
+ trace_imx_phy_read(val, reg);
return val;
}
-static void do_phy_write(IMXFECState *s, int reg, uint32_t val)
+static void imx_phy_write(IMXFECState *s, int reg, uint32_t val)
{
- PHY_PRINTF("write 0x%04x @ %d\n", val, reg);
+ trace_imx_phy_write(val, reg);
if (reg > 31) {
/* we only advertise one phy */
@@ -369,7 +348,7 @@ static void do_phy_write(IMXFECState *s, int reg, uint32_t val)
switch (reg) {
case 0: /* Basic Control */
if (val & 0x8000) {
- phy_reset(s);
+ imx_phy_reset(s);
} else {
s->phy_control = val & 0x7980;
/* Complete autonegotiation immediately. */
@@ -383,7 +362,7 @@ static void do_phy_write(IMXFECState *s, int reg, uint32_t val)
break;
case 30: /* Interrupt mask */
s->phy_int_mask = val & 0xff;
- phy_update_irq(s);
+ imx_phy_update_irq(s);
break;
case 17:
case 18:
@@ -402,6 +381,8 @@ static void do_phy_write(IMXFECState *s, int reg, uint32_t val)
static void imx_fec_read_bd(IMXFECBufDesc *bd, dma_addr_t addr)
{
dma_memory_read(&address_space_memory, addr, bd, sizeof(*bd));
+
+ trace_imx_fec_read_bd(addr, bd->flags, bd->length, bd->data);
}
static void imx_fec_write_bd(IMXFECBufDesc *bd, dma_addr_t addr)
@@ -412,6 +393,9 @@ static void imx_fec_write_bd(IMXFECBufDesc *bd, dma_addr_t addr)
static void imx_enet_read_bd(IMXENETBufDesc *bd, dma_addr_t addr)
{
dma_memory_read(&address_space_memory, addr, bd, sizeof(*bd));
+
+ trace_imx_enet_read_bd(addr, bd->flags, bd->length, bd->data,
+ bd->option, bd->status);
}
static void imx_enet_write_bd(IMXENETBufDesc *bd, dma_addr_t addr)
@@ -471,11 +455,9 @@ static void imx_fec_do_tx(IMXFECState *s)
int len;
imx_fec_read_bd(&bd, addr);
- FEC_PRINTF("tx_bd %x flags %04x len %d data %08x\n",
- addr, bd.flags, bd.length, bd.data);
if ((bd.flags & ENET_BD_R) == 0) {
/* Run out of descriptors to transmit. */
- FEC_PRINTF("tx_bd ran out of descriptors to transmit\n");
+ trace_imx_fec_do_tx();
break;
}
len = bd.length;
@@ -552,9 +534,6 @@ static void imx_enet_do_tx(IMXFECState *s, uint32_t index)
int len;
imx_enet_read_bd(&bd, addr);
- FEC_PRINTF("tx_bd %x flags %04x len %d data %08x option %04x "
- "status %04x\n", addr, bd.flags, bd.length, bd.data,
- bd.option, bd.status);
if ((bd.flags & ENET_BD_R) == 0) {
/* Run out of descriptors to transmit. */
break;
@@ -633,7 +612,7 @@ static void imx_eth_enable_rx(IMXFECState *s, bool flush)
s->regs[ENET_RDAR] = (bd.flags & ENET_BD_E) ? ENET_RDAR_RDAR : 0;
if (!s->regs[ENET_RDAR]) {
- FEC_PRINTF("RX buffer full\n");
+ trace_imx_eth_enable_rx();
} else if (flush) {
qemu_flush_queued_packets(qemu_get_queue(s->nic));
}
@@ -676,7 +655,7 @@ static void imx_eth_reset(DeviceState *d)
memset(s->tx_descriptor, 0, sizeof(s->tx_descriptor));
/* We also reset the PHY */
- phy_reset(s);
+ imx_phy_reset(s);
}
static uint32_t imx_default_read(IMXFECState *s, uint32_t index)
@@ -774,8 +753,7 @@ static uint64_t imx_eth_read(void *opaque, hwaddr offset, unsigned size)
break;
}
- FEC_PRINTF("reg[%s] => 0x%" PRIx32 "\n", imx_eth_reg_name(s, index),
- value);
+ trace_imx_eth_read(imx_eth_reg_name(s, index), value);
return value;
}
@@ -884,8 +862,7 @@ static void imx_eth_write(void *opaque, hwaddr offset, uint64_t value,
const bool single_tx_ring = !imx_eth_is_multi_tx_ring(s);
uint32_t index = offset >> 2;
- FEC_PRINTF("reg[%s] <= 0x%" PRIx32 "\n", imx_eth_reg_name(s, index),
- (uint32_t)value);
+ trace_imx_eth_write(imx_eth_reg_name(s, index), (uint32_t)value);
switch (index) {
case ENET_EIR:
@@ -940,12 +917,12 @@ static void imx_eth_write(void *opaque, hwaddr offset, uint64_t value,
if (extract32(value, 29, 1)) {
/* This is a read operation */
s->regs[ENET_MMFR] = deposit32(s->regs[ENET_MMFR], 0, 16,
- do_phy_read(s,
+ imx_phy_read(s,
extract32(value,
18, 10)));
} else {
/* This a write operation */
- do_phy_write(s, extract32(value, 18, 10), extract32(value, 0, 16));
+ imx_phy_write(s, extract32(value, 18, 10), extract32(value, 0, 16));
}
/* raise the interrupt as the PHY operation is done */
s->regs[ENET_EIR] |= ENET_INT_MII;
@@ -1053,8 +1030,6 @@ static bool imx_eth_can_receive(NetClientState *nc)
{
IMXFECState *s = IMX_FEC(qemu_get_nic_opaque(nc));
- FEC_PRINTF("\n");
-
return !!s->regs[ENET_RDAR];
}
@@ -1071,7 +1046,7 @@ static ssize_t imx_fec_receive(NetClientState *nc, const uint8_t *buf,
unsigned int buf_len;
size_t size = len;
- FEC_PRINTF("len %d\n", (int)size);
+ trace_imx_fec_receive(size);
if (!s->regs[ENET_RDAR]) {
qemu_log_mask(LOG_GUEST_ERROR, "[%s]%s: Unexpected packet\n",
@@ -1113,7 +1088,7 @@ static ssize_t imx_fec_receive(NetClientState *nc, const uint8_t *buf,
bd.length = buf_len;
size -= buf_len;
- FEC_PRINTF("rx_bd 0x%x length %d\n", addr, bd.length);
+ trace_imx_fec_receive_len(addr, bd.length);
/* The last 4 bytes are the CRC. */
if (size < 4) {
@@ -1131,7 +1106,9 @@ static ssize_t imx_fec_receive(NetClientState *nc, const uint8_t *buf,
if (size == 0) {
/* Last buffer in frame. */
bd.flags |= flags | ENET_BD_L;
- FEC_PRINTF("rx frame flags %04x\n", bd.flags);
+
+ trace_imx_fec_receive_last(bd.flags);
+
s->regs[ENET_EIR] |= ENET_INT_RXF;
} else {
s->regs[ENET_EIR] |= ENET_INT_RXB;
@@ -1164,7 +1141,7 @@ static ssize_t imx_enet_receive(NetClientState *nc, const uint8_t *buf,
size_t size = len;
bool shift16 = s->regs[ENET_RACC] & ENET_RACC_SHIFT16;
- FEC_PRINTF("len %d\n", (int)size);
+ trace_imx_enet_receive(size);
if (!s->regs[ENET_RDAR]) {
qemu_log_mask(LOG_GUEST_ERROR, "[%s]%s: Unexpected packet\n",
@@ -1210,7 +1187,7 @@ static ssize_t imx_enet_receive(NetClientState *nc, const uint8_t *buf,
bd.length = buf_len;
size -= buf_len;
- FEC_PRINTF("rx_bd 0x%x length %d\n", addr, bd.length);
+ trace_imx_enet_receive_len(addr, bd.length);
/* The last 4 bytes are the CRC. */
if (size < 4) {
@@ -1246,7 +1223,9 @@ static ssize_t imx_enet_receive(NetClientState *nc, const uint8_t *buf,
if (size == 0) {
/* Last buffer in frame. */
bd.flags |= flags | ENET_BD_L;
- FEC_PRINTF("rx frame flags %04x\n", bd.flags);
+
+ trace_imx_enet_receive_last(bd.flags);
+
/* Indicate that we've updated the last buffer descriptor. */
bd.last_buffer = ENET_BD_BDU;
if (bd.option & ENET_BD_RX_INT) {
diff --git a/hw/net/trace-events b/hw/net/trace-events
index e18f883cfd4..0bc74d98fec 100644
--- a/hw/net/trace-events
+++ b/hw/net/trace-events
@@ -408,3 +408,21 @@ i82596_receive_packet(size_t sz) "len=%zu"
i82596_new_mac(const char *id_with_mac) "New MAC for: %s"
i82596_set_multicast(uint16_t count) "Added %d multicast entries"
i82596_channel_attention(void *s) "%p: Received CHANNEL ATTENTION"
+
+# imx_fec.c
+imx_phy_read(uint32_t val, int reg) "0x%04x <= reg[%d]"
+imx_phy_write(uint32_t val, int reg) "0x%04x => reg[%d]"
+imx_phy_update_link(const char *s) "%s"
+imx_phy_reset(void) ""
+imx_fec_read_bd(uint64_t addr, int flags, int len, int data) "tx_bd %lx flags %04x len %d data %08x"
+imx_enet_read_bd(uint64_t addr, int flags, int len, int data, int options, int status) "tx_bd %lx flags %04x len %d data %08x option %04x status %04x"
+imx_fec_do_tx(void) "tx_bd ran out of descriptors to transmit"
+imx_eth_enable_rx(void) "RX buffer is full"
+imx_eth_read(const char *reg, uint32_t value) "reg[%s] => 0x%08x"
+imx_eth_write(const char *reg, uint32_t value) "reg[%s] <= 0x%08x"
+imx_fec_receive(size_t size) "len %ld"
+imx_fec_receive_len(uint64_t addr, int len) "rx_bd 0x%lx length %d"
+imx_fec_receive_last(int last) "rx frame flags %04x"
+imx_enet_receive(size_t size) "len %ld"
+imx_enet_receive_len(uint64_t addr, int len) "rx_bd 0x%lx length %d"
+imx_enet_receive_last(int last) "rx frame flags %04x"
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] ARM: dts: imx53: ppd: alarm LEDs use kernel LED interface
From: Sebastian Reichel @ 2020-05-29 18:03 UTC (permalink / raw)
To: Pavel Machek
Cc: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, devicetree, linux-kernel, kernel,
Ian Ray, Samu Nuutamo
In-Reply-To: <20200529160204.GA6025@duo.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 2664 bytes --]
Hi,
On Fri, May 29, 2020 at 06:02:04PM +0200, Pavel Machek wrote:
> > ping?
>
> Well, I thought that we maybe do not need standard LEDs on medical hardware.
The discussion died and the patch was not applied :) In general
IDK how worthwhile it is to use standard LED names for them. I
suppose the number of people planning to create something like
OpenWRT for medical devices is not so big.
> > On Fri, Apr 24, 2020 at 02:44:23PM +0200, Sebastian Reichel wrote:
> > > On Fri, Apr 24, 2020 at 11:32:26AM +0200, Pavel Machek wrote:
> > > > On Thu 2020-04-16 16:51:23, Sebastian Reichel wrote:
> > > > > From: Ian Ray <ian.ray@ge.com>
> > > > >
> > > > > Use kernel LED interface for the alarm LEDs.
> > > >
> > > > Could we get these changes cced to LED maintainers?
> > >
> > > Sorry, you are not turning up via get_maintainer.pl and usually
> > > subsystem maintainers are not CC'd for every DT device instance.
> > > E.g. I do not want to be always CC'd for DT board file containing
> > > a battery/charger. I'm quite surprised you want to be CC'd for
> > > them, just looking at ARM DT files there are over 1000 instances
> > > of leds.
>
> Well, we have mess in the naming; I'd like to clear it up.
I understand.
> > > > > + alarm1 {
> > > > > + label = "alarm:red";
> > > > > + gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> > > > > + };
> > > >
> > > > So... What is function of these leds, and can we get naming more
> > > > consistent with rest of the kernel?
> > >
> > > The device is a medical patient monitor and these are alarm LEDs
> > > informing about critical device or patient status. They are
> > > referenced by their color (those are discrete LEDs, not a
> > > multi-color one) basically everywhere. The only exception is
> > > "silenced", which means that audible alarm is surpressed. I
> > > don't think we have something comparable for any of those LEDs
> > > in the mainline tree.
>
> Actually, we have "platform:*:mute" LEDs, that could be used for
> "silenced".
I see you point, but wonder if mute is the right choice. The LED
signals a silenced alarm, which IMHO is not the same:
* The alarm silencing is temporary and system unsilences after
1-2 minutes.
* LED is usually blinking instead of solid like a laptop mute LED
(so that operator is aware of silenced alarm)
* Device usually cannot be put into silenced mode before the alarm
appears
* Some medical devices still generate perodic beeps
AFAIK this is named alarm silencing by basically everyone for
medical devices. So I think naming this platfrom:*:mute would
increase the mess.
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* 5.5 kernel: using nouveau or something else just long enough to turn off Quadro RTX 4000 Mobile for hybrid graphics?
From: Marc MERLIN @ 2020-05-29 18:03 UTC (permalink / raw)
To: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Howdy,
So, I have a Thinkpad P70 with hybrid graphics.
01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro M600M] (rev a2)
that one works fine, I can use i915 for the main screen, and nouveau to
display on the external ports (external ports are only wired to nvidia
chip, so it's impossible to use them without turning the nvidia chip
on).
I now got a newer P73 also with the same hybrid graphics (setup as such
in the bios). It runs fine with i915, and I don't need to use external
display with nouveau for now (it almost works, but I only see the mouse
cursor on the external screen, no window or anything else can get
displayed, very weird).
01:00.0 VGA compatible controller: NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q] (rev a1)
What I need for now is either nouveau, or bbswitch if it still works to
turn the nvidia chip off every time I power on/reboot/plug/unplug
external power.
if I don't load the nouveau module, I get this in powertop:
Bad Runtime PM for PCI Device NVIDIA Corporation TU104GLM [Quadro RTX 4000 Mobile / Max-Q]
powertop cannot really turn it off and I get
The battery reports a discharge rate of 63.0 W
If I load the nouveau driver, the chip gets turned off (great), but it's
unstable and hard crashes my laptop when I plug/unplug it from power
after a few times.
This is what I got in my logs after the last crash:
intel-lpss 0000:00:15.0: power state changed by ACPI to D3cold
intel-lpss 0000:00:15.1: power state changed by ACPI to D3cold
snd_hda_intel 0000:00:1f.3: PME# enabled
intel-lpss 0000:00:1e.0: power state changed by ACPI to D3cold
snd_hda_intel 0000:00:1f.3: power state changed by ACPI to D3hot
xhci_hcd 0000:01:00.2: PME# enabled
nvidia-gpu 0000:01:00.3: PME# enabled
pcieport 0000:05:00.0: PME# enabled
xhci_hcd 0000:2c:00.0: PME# enabled
pcieport 0000:05:02.0: PME# enabled
pcieport 0000:04:00.0: PME# enabled
pcieport 0000:00:1c.0: PME# enabled
pcieport 0000:00:1c.0: power state changed by ACPI to D3cold
nouveau 0000:01:00.0: power state changed by ACPI to D3cold
pcieport 0000:00:01.0: PME# enabled
pcieport 0000:00:01.0: power state changed by ACPI to D3cold
I am using TLP to manage battery use, the driver might not like things getting turned off to save power
(although when it works, I can get the laptop down to 10W)
Any suggestions on my best way to just keep the nvidia chip off reliably?
nouveau? bbswitch? other?
(and before you ask, no, you cannot turn it off in the bios, it's hybrid or nvidia only)
If that helps, here is what I got when I tried to use hybrid graphics to power an external
monitor (just pasting for completeness, I don't need this to work for now)
pci 0000:01:00.0: optimus capabilities: enabled, status dynamic power, hda bios codec supported
VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle
nouveau: detected PR support, will not use DSM
nouveau 0000:01:00.0: runtime IRQ mapping not provided by arch
nouveau 0000:01:00.0: NVIDIA TU104 (164000a1)
nouveau 0000:01:00.0: bios: version 90.04.4d.00.2c
nouveau 0000:01:00.0: enabling bus mastering
nouveau 0000:01:00.0: fb: 8192 MiB GDDR6
vga_switcheroo: enabled
[TTM] Zone kernel: Available graphics memory: 32730618 KiB
[TTM] Zone dma32: Available graphics memory: 2097152 KiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
nouveau 0000:01:00.0: DRM: VRAM: 8192 MiB
nouveau 0000:01:00.0: DRM: GART: 536870912 MiB
nouveau 0000:01:00.0: DRM: BIT table 'A' not found
nouveau 0000:01:00.0: DRM: BIT table 'L' not found
nouveau 0000:01:00.0: DRM: TMDS table version 2.0
nouveau 0000:01:00.0: DRM: DCB version 4.1
nouveau 0000:01:00.0: DRM: DCB outp 00: 02800f66 04600020
nouveau 0000:01:00.0: DRM: DCB outp 01: 02011f52 00020010
nouveau 0000:01:00.0: DRM: DCB outp 02: 01022f36 04600010
nouveau 0000:01:00.0: DRM: DCB outp 03: 04033f76 04600010
nouveau 0000:01:00.0: DRM: DCB outp 04: 04044f86 04600020
nouveau 0000:01:00.0: DRM: DCB conn 00: 00020047
nouveau 0000:01:00.0: DRM: DCB conn 01: 00010161
nouveau 0000:01:00.0: DRM: DCB conn 02: 00001248
nouveau 0000:01:00.0: DRM: DCB conn 03: 01000348
nouveau 0000:01:00.0: DRM: DCB conn 04: 02000471
nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22
nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
nouveau 0000:01:00.0: DRM: unknown connector type 48
nouveau 0000:01:00.0: DRM: unknown connector type 48
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
memmap_init_zone_device initialised 2097152 pages in 16ms
nouveau 0000:01:00.0: DRM: DMEM: registered 8192MB of device memory
nouveau 0000:01:00.0: DRM: allocated 2560x1600 fb: 0x200000, bo 0000000018f13ee1
nouveau 0000:01:00.0: fb1: nouveaudrmfb frame buffer device
sauron:~$ xrandr --setprovideroutputsource 1 0
sauron:~$ xrandr --listactivemonitors
Monitors: 1
0: +*eDP-1 3840/382x2160/214+0+0 eDP-1
sauron:~$ xrandr --auto
sauron:~$ xrandr --listactivemonitors
Monitors: 2
0: +*eDP-1 3840/382x2160/214+0+0 eDP-1
1: +HDMI-1-1 2560/641x1600/400+3840+0 HDMI-1-1
moving to new window moves the mouse, but not windows get displayed.
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Home page: http://marc.merlins.org/
^ permalink raw reply
* [PATCH v2 0/2] fuzz: Skip QTest serialization
From: Alexander Bulekov @ 2020-05-29 18:02 UTC (permalink / raw)
To: qemu-devel; +Cc: darren.kenny, bsd, f4bug, stefanha, Alexander Bulekov
In the same vein as Philippe's patch:
https://patchew.org/QEMU/20200528165303.1877-1-f4bug@amsat.org/
This uses linker trickery to wrap calls to libqtest functions and
directly call the corresponding read/write functions, rather than
relying on the ASCII-serialized QTest protocol.
v2: applies properly
Alexander Bulekov (2):
fuzz: skip QTest serialization
fuzz: Add support for logging QTest commands
tests/qtest/fuzz/Makefile.include | 21 +++++++++++++++++++++
tests/qtest/fuzz/fuzz.c | 22 +++++++++++++++++++++-
tests/qtest/fuzz/fuzz.h | 3 +++
3 files changed, 45 insertions(+), 1 deletion(-)
--
2.26.2
^ permalink raw reply
* [PATCH v2 1/2] fuzz: skip QTest serialization
From: Alexander Bulekov @ 2020-05-29 18:02 UTC (permalink / raw)
To: qemu-devel
Cc: Laurent Vivier, Thomas Huth, Alexander Bulekov, f4bug,
darren.kenny, bsd, stefanha, Paolo Bonzini
In-Reply-To: <20200529180210.28120-1-alxndr@bu.edu>
The QTest server usually parses ASCII commands from clients. Since we
fuzz within the QEMU process, skip the QTest serialization and server
for most QTest commands. Leave the option to use the ASCII protocol, to
generate readable traces for crash reproducers.
Inspired-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
---
tests/qtest/fuzz/Makefile.include | 21 +++++++++++++++++++++
tests/qtest/fuzz/fuzz.c | 14 +++++++++++++-
tests/qtest/fuzz/fuzz.h | 3 +++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/tests/qtest/fuzz/Makefile.include b/tests/qtest/fuzz/Makefile.include
index f259d866c9..5bde793bf2 100644
--- a/tests/qtest/fuzz/Makefile.include
+++ b/tests/qtest/fuzz/Makefile.include
@@ -5,6 +5,7 @@ fuzz-obj-y += $(libqos-obj-y)
fuzz-obj-y += tests/qtest/fuzz/fuzz.o # Fuzzer skeleton
fuzz-obj-y += tests/qtest/fuzz/fork_fuzz.o
fuzz-obj-y += tests/qtest/fuzz/qos_fuzz.o
+fuzz-obj-y += tests/qtest/fuzz/qtest_wrappers.o
# Targets
fuzz-obj-$(CONFIG_PCI_I440FX) += tests/qtest/fuzz/i440fx_fuzz.o
@@ -16,3 +17,23 @@ FUZZ_CFLAGS += -I$(SRC_PATH)/tests -I$(SRC_PATH)/tests/qtest
# Linker Script to force coverage-counters into known regions which we can mark
# shared
FUZZ_LDFLAGS += -Xlinker -T$(SRC_PATH)/tests/qtest/fuzz/fork_fuzz.ld
+
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_inb
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_inw
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_inl
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_outb
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_outw
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_outl
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_readb
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_readw
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_readl
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_readq
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_writeb
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_writew
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_writel
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_writeq
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_memread
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_bufread
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_memwrite
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_bufwrite
+FUZZ_LDFLAGS += -Wl,-wrap,qtest_memset
diff --git a/tests/qtest/fuzz/fuzz.c b/tests/qtest/fuzz/fuzz.c
index f5c923852e..cf76a6636f 100644
--- a/tests/qtest/fuzz/fuzz.c
+++ b/tests/qtest/fuzz/fuzz.c
@@ -91,7 +91,10 @@ static void usage(char *path)
printf(" * %s : %s\n", tmp->target->name,
tmp->target->description);
}
- printf("Alternatively, add -target-FUZZ_TARGET to the executable name\n");
+ printf("Alternatively, add -target-FUZZ_TARGET to the executable name\n\n"
+ "Set the environment variable FUZZ_SERIALIZE_QTEST=1 to serialize\n"
+ "QTest commands into an ASCII protocol. Useful for building crash\n"
+ "reproducers, but slows down execution.\n");
exit(0);
}
@@ -137,6 +140,8 @@ int LLVMFuzzerInitialize(int *argc, char ***argv, char ***envp)
{
char *target_name;
+ char *dir;
+ bool serialize = false;
/* Initialize qgraph and modules */
qos_graph_init();
@@ -157,6 +162,13 @@ int LLVMFuzzerInitialize(int *argc, char ***argv, char ***envp)
usage(**argv);
}
+ /* Should we always serialize qtest commands? */
+ if (getenv("FUZZ_SERIALIZE_QTEST")) {
+ serialize = true;
+ }
+
+ fuzz_qtest_set_serialize(serialize);
+
/* Identify the fuzz target */
fuzz_target = fuzz_get_target(target_name);
if (!fuzz_target) {
diff --git a/tests/qtest/fuzz/fuzz.h b/tests/qtest/fuzz/fuzz.h
index 03901d414e..72d5710f6c 100644
--- a/tests/qtest/fuzz/fuzz.h
+++ b/tests/qtest/fuzz/fuzz.h
@@ -82,6 +82,9 @@ typedef struct FuzzTarget {
void flush_events(QTestState *);
void reboot(QTestState *);
+/* Use the QTest ASCII protocol or call address_space API directly?*/
+void fuzz_qtest_set_serialize(bool option);
+
/*
* makes a copy of *target and adds it to the target-list.
* i.e. fine to set up target on the caller's stack
--
2.26.2
^ permalink raw reply related
* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Florian Fainelli @ 2020-05-29 18:03 UTC (permalink / raw)
To: Lukas Wunner
Cc: Nicolas Saenz Julienne, Mark Brown, Ray Jui, Scott Branden,
bcm-kernel-feedback-list, Martin Sperl, linux-spi,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20200529175350.2wtoqttipa354m2m@wunner.de>
On 5/29/20 10:53 AM, Lukas Wunner wrote:
> On Fri, May 29, 2020 at 10:46:01AM -0700, Florian Fainelli wrote:
>> On 5/29/20 10:43 AM, Lukas Wunner wrote:
>>> On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
>>>> --- a/drivers/spi/spi-bcm2835.c
>>>> +++ b/drivers/spi/spi-bcm2835.c
>>>> @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
>>>> if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
>>>> bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
>>>>
>>>> + /* check if we got interrupt enabled */
>>>> + if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
>>>> + return IRQ_NONE;
>>>> +
>>>> /* Read as many bytes as possible from FIFO */
>>>> bcm2835_rd_fifo(bs);
>>>> /* Write as many bytes as possible to FIFO */
> [...]
>>> Finally, it would be nice if the check would be optimized away when
>>> compiling for pre-RasPi4 products, maybe something like:
>>>
>>> + if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
>>> + return IRQ_NONE;
>>
>> Rather than keying this off ARM_LPAE or any other option, this should be
>> keyed off a compatible string, that way we can even conditionally pass
>> IRQF_SHARED to the interrupt handler if we care so much about performance.
>
> But a compatible string can't be checked at compile time, can it?
No, but you can have a different interrupt handler that it set at
runtime if you want to completely eliminate this comparison.
My point is that CONFIG_ARM_LPAE is just too brittle, there is nothing
that prevents you from using a non-LPAE kernel on the Pi 4, even PCIe
could be made to work if using super section mappings to map the PCIe
outbound space. Even on models with over 4GB of DRAM, if you are willing
to lose some of it, it can work.
>
> The point is that at the least the Foundation compiles and ships a separate
> kernel for each of the three platforms BCM2835, BCM2837, BCM2711. It's
> unnecessary to check whether an interrupt was actually raised if we *know*
> in advance that it's not shared (as is the case with kernels compiled for
> BCM2835 and BCM2837).
I am fine with any solution that does not involve keying off
CONFIG_ARM_LPAE to discriminate 2711 from any other chip.
--
Florian
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Enable shared interrupt support
From: Florian Fainelli @ 2020-05-29 18:03 UTC (permalink / raw)
To: Lukas Wunner
Cc: linux-arm-kernel, Scott Branden, Ray Jui, linux-kernel, linux-spi,
Mark Brown, bcm-kernel-feedback-list, linux-rpi-kernel,
Martin Sperl, Nicolas Saenz Julienne
In-Reply-To: <20200529175350.2wtoqttipa354m2m@wunner.de>
On 5/29/20 10:53 AM, Lukas Wunner wrote:
> On Fri, May 29, 2020 at 10:46:01AM -0700, Florian Fainelli wrote:
>> On 5/29/20 10:43 AM, Lukas Wunner wrote:
>>> On Thu, May 28, 2020 at 08:58:04PM +0200, Nicolas Saenz Julienne wrote:
>>>> --- a/drivers/spi/spi-bcm2835.c
>>>> +++ b/drivers/spi/spi-bcm2835.c
>>>> @@ -379,6 +379,10 @@ static irqreturn_t bcm2835_spi_interrupt(int irq, void *dev_id)
>>>> if (bs->tx_len && cs & BCM2835_SPI_CS_DONE)
>>>> bcm2835_wr_fifo_blind(bs, BCM2835_SPI_FIFO_SIZE);
>>>>
>>>> + /* check if we got interrupt enabled */
>>>> + if (!(bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_INTR))
>>>> + return IRQ_NONE;
>>>> +
>>>> /* Read as many bytes as possible from FIFO */
>>>> bcm2835_rd_fifo(bs);
>>>> /* Write as many bytes as possible to FIFO */
> [...]
>>> Finally, it would be nice if the check would be optimized away when
>>> compiling for pre-RasPi4 products, maybe something like:
>>>
>>> + if (IS_ENABLED(CONFIG_ARM_LPAE) && !(cs & BCM2835_SPI_CS_INTR))
>>> + return IRQ_NONE;
>>
>> Rather than keying this off ARM_LPAE or any other option, this should be
>> keyed off a compatible string, that way we can even conditionally pass
>> IRQF_SHARED to the interrupt handler if we care so much about performance.
>
> But a compatible string can't be checked at compile time, can it?
No, but you can have a different interrupt handler that it set at
runtime if you want to completely eliminate this comparison.
My point is that CONFIG_ARM_LPAE is just too brittle, there is nothing
that prevents you from using a non-LPAE kernel on the Pi 4, even PCIe
could be made to work if using super section mappings to map the PCIe
outbound space. Even on models with over 4GB of DRAM, if you are willing
to lose some of it, it can work.
>
> The point is that at the least the Foundation compiles and ships a separate
> kernel for each of the three platforms BCM2835, BCM2837, BCM2711. It's
> unnecessary to check whether an interrupt was actually raised if we *know*
> in advance that it's not shared (as is the case with kernels compiled for
> BCM2835 and BCM2837).
I am fine with any solution that does not involve keying off
CONFIG_ARM_LPAE to discriminate 2711 from any other chip.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/amdgpu/display: drop the reduction loop when setting the sync groups
From: Alex Deucher @ 2020-05-29 18:04 UTC (permalink / raw)
To: Kazlauskas, Nicholas; +Cc: Alex Deucher, amd-gfx list
In-Reply-To: <da249d2c-1102-ad4b-1acb-1a62242ec22c@amd.com>
On Fri, May 29, 2020 at 9:56 AM Kazlauskas, Nicholas
<nicholas.kazlauskas@amd.com> wrote:
>
> On 2020-05-28 10:06 a.m., Alex Deucher wrote:
> > The logic for blanked is not the same as having a plane_state. Technically
> > you can drive an OTG without anything connected in the front end and it'll
> > just draw out the back color which is distinct from having the OTG be blanked.
> > If we add planes or unblank the OTG later then we'll still want the
> > synchronization.
> >
> > Bug: https://gitlab.freedesktop.org/drm/amd/issues/781
> > Fixes: 5fc0cbfad45648 ("drm/amd/display: determine if a pipe is synced by plane state")
> > Cc: nicholas.kazlauskas@amd.com
> > Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > ---
> > drivers/gpu/drm/amd/display/dc/core/dc.c | 8 --------
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > index 04c3d9f7e323..6279520f7873 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > @@ -1040,14 +1040,6 @@ static void program_timing_sync(
> > status->timing_sync_info.master = false;
> >
> > }
> > - /* remove any other pipes with plane as they have already been synced */
> > - for (j = j + 1; j < group_size; j++) {
> > - if (pipe_set[j]->plane_state) {
> > - group_size--;
> > - pipe_set[j] = pipe_set[group_size];
> > - j--;
> > - }
> > - }
>
>
> Looking at this again, I think I may understand the issue this was
> trying to work around.
>
> If we try to force timing synchronization on displays that are currently
> active then this is going to force reset the vertical position,
> resulting in screen corruption.
>
> So what this logic was attempting to do was ensure that timing
> synchronization only happens when committing two streams at a time
> without any image on the screen.
>
> Maybe it'd be best to just blank these streams out first, but for now,
> let's actually go back to fixing this by applying the actual dpg/tg
> check that Wenjing suggests, something like:
>
> if (pool->opps[i]->funcs->dpg_is_blanked)
> s.blank_enabled =
> pool->opps[i]->funcs->dpg_is_blanked(pool->opps[i]);
> else
> s.blank_enabled = tg->funcs->is_blanked(tg);
>
Hmm, it's not clear to me where this code needs to go. Can you point
me in the right direction or provide a quick patch?
Thanks,
Alex
>
>
> The reason why we have this issue in the first place is because
> amdgpu_dm usually commits a dc_state with the planes already in it
> instead of committing them later, so plane_state not being NULL is
> typically true.
>
> Regards,
> Nicholas Kazlauskas
>
> >
> > if (group_size > 1) {
> > dc->hwss.enable_timing_synchronization(
> >
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH nf-next v5 1/1] netfilter: ctnetlink: add kernel side filtering for dump
From: Pablo Neira Ayuso @ 2020-05-29 18:04 UTC (permalink / raw)
To: Florent Fourcot; +Cc: Romain Bellan, netfilter-devel
In-Reply-To: <66100a4b-a879-a8f4-f684-2b098a89cdc8@wifirst.fr>
Hi,
Just a followed up after including your ctnetlink update in the last
upstream pull request for net-next.
I think you already mentioned, but it should be possible to extend
the conntrack utility to support for kernel side filtering seamlessly.
The idea is to keep the userspace filtering as a fallback, regardless
the kernel supports for CTA_FILTER or not.
I'm missing one feature in the CTA_FILTER, that is the netmask
filtering for IP addresses. It would be also good to make this fit
into libnetfilter_conntrack.
Probably this patch can be extended to include two objects, the
conntrack object that represents the exact matching (values) and
another one that represent the mask:
https://patchwork.ozlabs.org/project/netfilter-devel/patch/20200129094719.670-1-romain.bellan@wifirst.fr/
The mask object would only work for the IP address and mark.
Probably rename NFCT_FILTER_DUMP_TUPLE to NFCT_FILTER_DUMP, which
would provide the most generic version to request kernel side
filtering.
Thanks.
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Implement shutdown callback
From: Florian Fainelli @ 2020-05-29 18:04 UTC (permalink / raw)
To: Lukas Wunner
Cc: linux-kernel, Mark Brown, Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, open list:SPI SUBSYSTEM,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529175831.p4dphb5luymgapzx@wunner.de>
On 5/29/20 10:58 AM, Lukas Wunner wrote:
> On Fri, May 29, 2020 at 10:48:11AM -0700, Florian Fainelli wrote:
>> On 5/29/20 10:47 AM, Lukas Wunner wrote:
>>> On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
>>>> Make sure we clear the FIFOs, stop the block, disable the clock and
>>>> release the DMA channel.
>>>
>>> To what end? Why is this change necessary? Sorry but this seems like
>>> an awfully terse commit message.
>>
>> To ensure clocks are disabled and to save power in low power modes used
>> on 7211 for instance.
>
> Thanks for the explanation, that's an important tidbit. I wasn't even
> aware that this SPI controller is used on SoCs beyond the Raspberry Pi
> ones. Does the BCM7211 use shared interrupts for this controller?
> Does it have DMA DREQ attached?
For all practical purposes you can consider that 7211 is identical to a
2711, it does use shared interrupts for this controller and there is a
DRAM DREQ attached as well. Where they differ are on the display, video,
and memory controller MAC.
--
Florian
^ permalink raw reply
* Re: [PATCH] spi: bcm2835: Implement shutdown callback
From: Florian Fainelli @ 2020-05-29 18:04 UTC (permalink / raw)
To: Lukas Wunner
Cc: moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Scott Branden, Ray Jui, linux-kernel, open list:SPI SUBSYSTEM,
Mark Brown,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne
In-Reply-To: <20200529175831.p4dphb5luymgapzx@wunner.de>
On 5/29/20 10:58 AM, Lukas Wunner wrote:
> On Fri, May 29, 2020 at 10:48:11AM -0700, Florian Fainelli wrote:
>> On 5/29/20 10:47 AM, Lukas Wunner wrote:
>>> On Thu, May 28, 2020 at 12:06:05PM -0700, Florian Fainelli wrote:
>>>> Make sure we clear the FIFOs, stop the block, disable the clock and
>>>> release the DMA channel.
>>>
>>> To what end? Why is this change necessary? Sorry but this seems like
>>> an awfully terse commit message.
>>
>> To ensure clocks are disabled and to save power in low power modes used
>> on 7211 for instance.
>
> Thanks for the explanation, that's an important tidbit. I wasn't even
> aware that this SPI controller is used on SoCs beyond the Raspberry Pi
> ones. Does the BCM7211 use shared interrupts for this controller?
> Does it have DMA DREQ attached?
For all practical purposes you can consider that 7211 is identical to a
2711, it does use shared interrupts for this controller and there is a
DRAM DREQ attached as well. Where they differ are on the display, video,
and memory controller MAC.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] [v2] PCI: tegra: Fix runtime PM imbalance on error
From: Thierry Reding @ 2020-05-29 18:05 UTC (permalink / raw)
To: Dinghao Liu
Cc: kjlu, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Jonathan Hunter, linux-tegra, linux-pci, linux-kernel
In-Reply-To: <20200521024709.2368-1-dinghao.liu@zju.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
On Thu, May 21, 2020 at 10:47:09AM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.
>
> Also, call pm_runtime_disable() when pm_runtime_get_sync() returns
> an error code.
>
> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
> ---
> drivers/pci/controller/pci-tegra.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Acked-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [RFC] decrease tsk->signal->live before profile_task_exit
From: Eric W. Biederman @ 2020-05-29 18:01 UTC (permalink / raw)
To: liuchao; +Cc: mingo, tglx, linux-kernel, hushiyuan, hewenliang4
In-Reply-To: <20200528040956.30155-1-liuchao173@huawei.com>
liuchao <liuchao173@huawei.com> writes:
> I want to dermine which thread is the last one to enter
> do_exit in profile_task_exit. But when a lot of threads
> exit, tsk->signal->live is not correct since it decrease
> after profile_task_exit.
I don't think that would be wise.
Any additional code before the sanity checks at the start of do_exit
seems like a bad idea.
We could probably move the decrement of tsk->signal->live a little
earlier, but not that much earlier in the function.
Does profile_task_exit even make sense that early in the code? If the
code is doing much of anything that is a completely inappopriate
placement of profile_task_exit.
Eric
> Signed-off-by: liuchao <liuchao173@huawei.com>
> ---
> kernel/exit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/exit.c b/kernel/exit.c
> index ce2a75bc0ade..1693764bc356 100644
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -708,6 +708,7 @@ void __noreturn do_exit(long code)
> struct task_struct *tsk = current;
> int group_dead;
>
> + group_dead = atomic_dec_and_test(&tsk->signal->live);
> profile_task_exit(tsk);
> kcov_task_exit(tsk);
>
> @@ -755,7 +756,6 @@ void __noreturn do_exit(long code)
> if (tsk->mm)
> sync_mm_rss(tsk->mm);
> acct_update_integrals(tsk);
> - group_dead = atomic_dec_and_test(&tsk->signal->live);
> if (group_dead) {
> /*
> * If the last thread of global init has exited, panic
^ permalink raw reply
* Re: [PATCH v3 1/4] dt-bindings: usb: Add documentation for SG trb cache size quirk
From: Rob Herring @ 2020-05-29 18:05 UTC (permalink / raw)
To: Tejas Joglekar; +Cc: Greg Kroah-Hartman, linux-usb, devicetree, John Youn
In-Reply-To: <d91b768b3827fce611ba052aa1bcca19ac09fd75.1590415123.git.joglekar@synopsys.com>
On Wed, May 27, 2020 at 04:10:55PM +0530, Tejas Joglekar wrote:
> This commit adds the documentation for sgl-trb-cache-size-quirk, and
> snps,sgl-trb-cache-size-quirk property. These when set enables the
> quirk for XHCI driver for consolidation of sg list into a temporary
> buffer when small buffer sizes are scattered over the sg list not
> making up to MPS or total transfer size within TRB cache size with
> Synopsys xHC.
>
> Signed-off-by: Tejas Joglekar <joglekar@synopsys.com>
> ---
> Documentation/devicetree/bindings/usb/dwc3.txt | 4 ++++
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 3 +++
> 2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
> index d03edf9d3935..0fcbaa51f66e 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -102,6 +102,10 @@ Optional properties:
> this and tx-thr-num-pkt-prd to a valid, non-zero value
> 1-16 (DWC_usb31 programming guide section 1.2.3) to
> enable periodic ESS TX threshold.
> + - snps,sgl-trb-cache-size-quirk: enable sg list consolidation - host mode
> + only. Set to use SG buffers of at least MPS size
> + by consolidating smaller SG buffers list into a
> + single buffer.
>
> - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
> - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
> diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> index dc025f126d71..c53eb19ae67e 100644
> --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
> @@ -44,6 +44,9 @@ Optional properties:
> - quirk-broken-port-ped: set if the controller has broken port disable mechanism
> - imod-interval-ns: default interrupt moderation interval is 5000ns
> - phys : see usb-hcd.yaml in the current directory
> + - sgl-trb-cache-size-quirk: set if you need to consolidate sg list into a
> + temporary buffer when small SG buffer sizes does not make upto MPS
> + size or total transfer size across the TRB cache size.
Still don't understand why you have 2 properties? Is this a generic
issue for multiple XHCI controllers? If yes, you don't need the first
one. If no, then you don't need the second one.
Really, I'd prefer neither, and this should be implied by a specific
compatible string. Having a separate property doesn't work if you find
this issue later on after already adding XHCI support. IOW, don't make
users update their DT to handle a quirk.
Rob
^ permalink raw reply
* Re: [PATCH v14 1/1] perf tools: add support for libpfm4
From: Ian Rogers @ 2020-05-29 18:06 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Peter Zijlstra, Ingo Molnar, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Namhyung Kim, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Yonghong Song, Andrii Nakryiko,
Greg Kroah-Hartman, Thomas Gleixner, Igor Lubashev,
Alexey Budankov, Florian Fainelli, Adrian Hunter, Andi Kleen,
Jiwei Sun, yuzhoujian <yuzhoujian>
In-Reply-To: <20200529173608.GA31795@kernel.org>
On Fri, May 29, 2020 at 10:36 AM Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
>
> Em Fri, May 29, 2020 at 02:23:10PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, May 29, 2020 at 10:03:51AM -0700, Ian Rogers escreveu:
> > > On Tue, May 5, 2020 at 11:29 AM Ian Rogers <irogers@google.com> wrote:
> > > >
> > > > From: Stephane Eranian <eranian@google.com>
> > > >
> > > > This patch links perf with the libpfm4 library if it is available
> > > > and LIBPFM4 is passed to the build. The libpfm4 library
> > > > contains hardware event tables for all processors supported by
> > > > perf_events. It is a helper library that helps convert from a
> > > > symbolic event name to the event encoding required by the
> > > > underlying kernel interface. This library is open-source and
> > > > available from: http://perfmon2.sf.net.
> > > >
> > > > With this patch, it is possible to specify full hardware events
> > > > by name. Hardware filters are also supported. Events must be
> > > > specified via the --pfm-events and not -e option. Both options
> > > > are active at the same time and it is possible to mix and match:
> > > >
> > > > $ perf stat --pfm-events inst_retired:any_p:c=1:i -e cycles ....
> > > >
> > > > Signed-off-by: Stephane Eranian <eranian@google.com>
> > > > Reviewed-by: Ian Rogers <irogers@google.com>
> > >
> > > Ping.
> >
> > Check my tmp.perf/core branch, I had to make some adjustments, mostly in
> > the 'perf test' entries as I merged a java demangle test that touched
> > the same files,
> >
> > I'm now doing the build tests.
>
> Talking about build tests, you forgot to add it there, like I did
> below, I'll eventually do it, as it is opt-in, no biggie at this point.
>
> I'll install libpfm-devel that is in fedora and do further tests, later
> today.
Sorry for that, tbh I wasn't sure what to do. When I test locally I
make sure the build is and isn't adding libpfm into the man pages, the
libpfm tests pass, some command line uses. It'd be great to automate
this as it is not something you'd want to do for every patch and there
is some build sensitivity that potentially could break it.
Thanks,
Ian
> - Arnaldo
>
> commit a01c205e3c4cd6d134317413f2dc3129c4ab7a5a
> Author: Arnaldo Carvalho de Melo <acme@redhat.com>
> Date: Fri May 29 11:31:23 2020 -0300
>
> perf build: Add NO_SYSCALL_TABLE=1 to the build tests
>
> So that we make sure that even on x86-64 and other architectures where
> that is the default method we test build the fallback to libaudit that
> other architectures use.
>
> I.e. now this line got added to:
>
> $ make -C tools/perf build-test
> <SNIP>
> make_no_syscall_tbl_O: cd . && make NO_SYSCALL_TABLE=1 FEATURES_DUMP=/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j12 O=/tmp/tmp.W0HtKR1mfr DESTDIR=/tmp/tmp.lNezgCVPzW
> <SNIP>
> $
>
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
>
> diff --git a/tools/perf/tests/make b/tools/perf/tests/make
> index 29ce0da7fca6..a4ffa3c7fcb6 100644
> --- a/tools/perf/tests/make
> +++ b/tools/perf/tests/make
> @@ -88,6 +88,7 @@ make_no_libbpf_DEBUG := NO_LIBBPF=1 DEBUG=1
> make_no_libcrypto := NO_LIBCRYPTO=1
> make_with_babeltrace:= LIBBABELTRACE=1
> make_no_sdt := NO_SDT=1
> +make_no_syscall_tbl := NO_SYSCALL_TABLE=1
> make_with_clangllvm := LIBCLANGLLVM=1
> make_tags := tags
> make_cscope := cscope
> @@ -113,7 +114,7 @@ make_minimal += NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1
> make_minimal += NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1
> make_minimal += NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1
> make_minimal += NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1 NO_LIBZSTD=1
> -make_minimal += NO_LIBCAP=1
> +make_minimal += NO_LIBCAP=1 NO_SYSCALL_TABLE=1
>
> # $(run) contains all available tests
> run := make_pure
> @@ -146,6 +147,7 @@ run += make_no_libbionic
> run += make_no_auxtrace
> run += make_no_libbpf
> run += make_no_libbpf_DEBUG
> +run += make_no_syscall_tbl
> run += make_with_babeltrace
> run += make_with_clangllvm
> run += make_help
^ permalink raw reply
* [PATCH v2 2/2] fuzz: Add support for logging QTest commands
From: Alexander Bulekov @ 2020-05-29 18:02 UTC (permalink / raw)
To: qemu-devel
Cc: Laurent Vivier, Thomas Huth, Alexander Bulekov, f4bug,
darren.kenny, bsd, stefanha, Paolo Bonzini
In-Reply-To: <20200529180210.28120-1-alxndr@bu.edu>
Signed-off-by: Alexander Bulekov <alxndr@bu.edu>
---
tests/qtest/fuzz/fuzz.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tests/qtest/fuzz/fuzz.c b/tests/qtest/fuzz/fuzz.c
index cf76a6636f..4842fbe7c7 100644
--- a/tests/qtest/fuzz/fuzz.c
+++ b/tests/qtest/fuzz/fuzz.c
@@ -95,6 +95,9 @@ static void usage(char *path)
"Set the environment variable FUZZ_SERIALIZE_QTEST=1 to serialize\n"
"QTest commands into an ASCII protocol. Useful for building crash\n"
"reproducers, but slows down execution.\n");
+ "reproducers, but slows down execution.\n\n"
+ "Set the environment variable QTEST_LOG=1 to log all qtest commands"
+ "\n");
exit(0);
}
@@ -183,6 +186,11 @@ int LLVMFuzzerInitialize(int *argc, char ***argv, char ***envp)
/* Run QEMU's softmmu main with the fuzz-target dependent arguments */
const char *init_cmdline = fuzz_target->get_init_cmdline(fuzz_target);
+ init_cmdline = g_strdup_printf("%s -qtest /dev/null -qtest-log %s",
+ init_cmdline,
+ getenv("QTEST_LOG") ? "/dev/fd/2"
+ : "/dev/null");
+
/* Split the runcmd into an argv and argc */
wordexp_t result;
--
2.26.2
^ permalink raw reply related
* [PATCH] dt-bindings: Merge gpio-usb-b-connector with usb-connector
From: Thierry Reding @ 2020-05-29 18:06 UTC (permalink / raw)
To: Rob Herring
Cc: Greg Kroah-Hartman, Prashant Malani, devicetree, linux-usb,
linux-kernel
From: Thierry Reding <treding@nvidia.com>
The binding for usb-connector is a superset of gpio-usb-b-connector. One
major difference is that gpio-usb-b-connector requires at least one of
the vbus-gpios and id-gpios properties to be specified. Merge the two
bindings by adding the compatible string combination for the GPIO USB-B
variant and an extra conditional for the required properties list to the
usb-connector.yaml file.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
.../bindings/connector/usb-connector.yaml | 39 +++++++++++++++++--
.../devicetree/bindings/usb/usb-conn-gpio.txt | 30 --------------
2 files changed, 35 insertions(+), 34 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml
index 03b92b6f35fa..9bd52e63c935 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
+++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
@@ -15,10 +15,15 @@ description:
properties:
compatible:
- enum:
- - usb-a-connector
- - usb-b-connector
- - usb-c-connector
+ oneOf:
+ - enum:
+ - usb-a-connector
+ - usb-b-connector
+ - usb-c-connector
+
+ - items:
+ - const: gpio-usb-b-connector
+ - const: usb-b-connector
label:
description: Symbolic name for the connector.
@@ -140,6 +145,19 @@ properties:
required:
- compatible
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: gpio-usb-b-connector
+ then:
+ anyOf:
+ - required:
+ - vbus-gpios
+ - required:
+ - id-gpios
+
examples:
# Micro-USB connector with HS lines routed via controller (MUIC).
- |
@@ -202,3 +220,16 @@ examples:
op-sink-microwatt = <10000000>;
};
};
+
+ # USB connector with GPIO control lines
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ connector {
+ compatible = "gpio-usb-b-connector", "usb-b-connector";
+ type = "micro";
+ id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
+ vbus-supply = <&usb_p0_vbus>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt b/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
deleted file mode 100644
index ec80641208a5..000000000000
--- a/Documentation/devicetree/bindings/usb/usb-conn-gpio.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-USB GPIO Based Connection Detection
-
-This is typically used to switch dual role mode from the USB ID pin connected
-to an input GPIO, and also used to enable/disable device mode from the USB
-Vbus pin connected to an input GPIO.
-
-Required properties:
-- compatible : should include "gpio-usb-b-connector" and "usb-b-connector".
-- id-gpios, vbus-gpios : input gpios, either one of them must be present,
- and both can be present as well.
- see connector/usb-connector.yaml
-
-Optional properties:
-- vbus-supply : can be present if needed when supports dual role mode.
- see connector/usb-connector.yaml
-
-- Sub-nodes:
- - port : can be present.
- see graph.txt
-
-Example:
-
-&mtu3 {
- connector {
- compatible = "gpio-usb-b-connector", "usb-b-connector";
- type = "micro";
- id-gpios = <&pio 12 GPIO_ACTIVE_HIGH>;
- vbus-supply = <&usb_p0_vbus>;
- };
-};
--
2.24.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.