64 instruction encoding tests
over to this, and having the ability to dynamically generate the params
array before iterating over the case makes that much easier to handle.
FWIW, for the series:
Acked-by: Mark Rutland
I'll see about getting those converted over and posted once this is in.
On Tue, Aug 26, 2025 at 04:31:23PM +0100, Mark Rutland wrote:
> On Tue, Aug 26, 2025 at 03:35:48PM +0100, Robin Murphy wrote:
> > On 2025-08-26 12:15 pm, Mark Rutland wrote:
> > > On Wed, Aug 13, 2025 at 06:00:54PM +0100, Robin Murphy wrote:
> > > > diff
On Tue, Aug 26, 2025 at 11:48:48AM -0700, Ian Rogers wrote:
> On Tue, Aug 26, 2025 at 8:32 AM Robin Murphy wrote:
> >
> > On 2025-08-26 2:03 pm, Peter Zijlstra wrote:
> > > On Wed, Aug 13, 2025 at 06:01:04PM +0100, Robin Murphy wrote:
> > >> It may have been different long ago, but today it seems
On Tue, Aug 26, 2025 at 11:46:02PM +0100, Robin Murphy wrote:
> On 2025-08-26 2:43 pm, Mark Rutland wrote:
> > On Wed, Aug 13, 2025 at 06:01:10PM +0100, Robin Murphy wrote:
> > To bikeshed a little here, I'm not keen on the PERF_PMU_CAP_RAW_EVENTS
> > name, because it
On Tue, Aug 26, 2025 at 04:31:23PM +0100, Mark Rutland wrote:
> On Tue, Aug 26, 2025 at 03:35:48PM +0100, Robin Murphy wrote:
> > On 2025-08-26 12:15 pm, Mark Rutland wrote:
> > > On Wed, Aug 13, 2025 at 06:00:54PM +0100, Robin Murphy wrote:
> > > > diff
On Tue, Aug 26, 2025 at 03:35:48PM +0100, Robin Murphy wrote:
> On 2025-08-26 12:15 pm, Mark Rutland wrote:
> > On Wed, Aug 13, 2025 at 06:00:54PM +0100, Robin Murphy wrote:
> > > The group validation logic shared by the HiSilicon HNS3/PCIe drivers is
> > > a bit of
On Wed, Aug 13, 2025 at 06:01:10PM +0100, Robin Murphy wrote:
> Only a handful of CPU PMUs accept PERF_TYPE_{RAW,HARDWARE,HW_CACHE}
> events without registering themselves as PERF_TYPE_RAW in the first
> place. Add an explicit opt-in for these special cases, so that we can
> make life easier for ev
On Tue, Aug 26, 2025 at 03:08:06PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 13, 2025 at 06:01:08PM +0100, Robin Murphy wrote:
> > Sampling is inherently a feature for CPU PMUs, given that the thing
> > to be sampled is a CPU context. These days, we have many more
> > uncore/system PMUs than CPU P
On Tue, Aug 26, 2025 at 12:15:23PM +0100, Mark Rutland wrote:
> On Wed, Aug 13, 2025 at 06:00:54PM +0100, Robin Murphy wrote:
> > The group validation logic shared by the HiSilicon HNS3/PCIe drivers is
> > a bit off, in that given a software group leader, it will consider that
>
On Wed, Aug 13, 2025 at 06:00:54PM +0100, Robin Murphy wrote:
> The group validation logic shared by the HiSilicon HNS3/PCIe drivers is
> a bit off, in that given a software group leader, it will consider that
> event *in place of* the actual new event being opened. At worst this
> could theoretica
Hi Robin,
On Wed, Aug 13, 2025 at 06:00:53PM +0100, Robin Murphy wrote:
> In the hypothetical case where a CMN event is opened with a software
> group leader that already has some other hardware sibling, currently
> arm_cmn_val_add_event() could try to interpret the other event's data
> as an arm_
On Thu, Dec 12, 2024 at 08:50:12AM +, Marc Zyngier wrote:
> On Thu, 12 Dec 2024 05:31:00 +,
> Pavan Kondeti wrote:
> >
> > On Wed, Dec 11, 2024 at 10:40:02AM +, Marc Zyngier wrote:
> > > On Wed, 11 Dec 2024 00:37:34 +,
> > > Pavan Kondeti wrote:
> > > >
> > > > On Tue, Dec 10, 2
On Thu, Jan 05, 2023 at 03:57:25PM +0100, Daniel Vetter wrote:
> It's more fun, for the atomic functions which don't have the atomic_
> prefix in their names, the __ prefixed versions provide the non-atomic
> implementation. This pattern was started with the long * bitops stuff for
> managing real
Hi Arnd,
This is great!
On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> During a patch discussion, Linus brought up the option of changing
> the C standard version from gnu89 to gnu99, which allows using variable
> declaration inside of a for() loop. Whi
2021 at 02:08:59PM +0100, Mark Rutland wrote:
> > > > > On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
> > > > > > On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
> > > I notice that it checks index 'fifos_state[c
fb fb fb fb fb fb
| ==
Link: https://lore.kernel.org/r/4d0c8318-bad8-2be7-e292-fc8f70c19...@samsung.com
Link:
https://lore.kernel.org/linux-arm-kernel/20210607151740.moncryl5zv3ahq4s@gilmour
Signed-off-by: Mark Rutland
Reported-by: Marek Szy
gt; -next) is causing vc4 to hang on Rpi3b due to a probable driver bug.
>
> The great news for the patch that caused it is that this has nothing to
> do with DMA alignment.
>
> > On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
> > > On Mon, Jun 07, 2021
l
>
> On Mon, Jun 07, 2021 at 02:08:59PM +0100, Mark Rutland wrote:
> > On Mon, Jun 07, 2021 at 01:01:18PM +0100, Mark Rutland wrote:
> > > On Mon, Jun 07, 2021 at 11:58:32AM +0200, Marek Szyprowski wrote:
> > > > I've just checked with the latest firmwa
On Wed, Apr 08, 2020 at 01:59:16PM +0200, Christoph Hellwig wrote:
> To help enforcing the W^X protection don't allow remapping existing
> pages as executable.
>
> Based on patch from Peter Zijlstra .
>
> Signed-off-by: Christoph Hellwig
> ---
> arch/x86/include/asm/pgtable_types.h | 6 ++
>
On Wed, Apr 08, 2020 at 01:59:24PM +0200, Christoph Hellwig wrote:
> arch_alloc_vmap_stack can use a slightly higher level vmalloc function.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/vmap_stack.h | 6 ++
>
On Thu, Aug 08, 2019 at 11:20:53AM +0100, Mark Rutland wrote:
> On Thu, Aug 08, 2019 at 09:58:27AM +0200, Christoph Hellwig wrote:
> > On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> > > For arm64, we can tear down portions of the linear map, but that ha
On Thu, Aug 08, 2019 at 09:58:27AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 07, 2019 at 05:49:59PM +0100, Mark Rutland wrote:
> > For arm64, we can tear down portions of the linear map, but that has to
> > be done explicitly, and this is only possible when using rodata_full. I
On Wed, Aug 07, 2019 at 09:15:54AM -0700, Rob Clark wrote:
> On Wed, Aug 7, 2019 at 5:38 AM Mark Rutland wrote:
> >
> > On Tue, Aug 06, 2019 at 09:31:55AM -0700, Rob Clark wrote:
> > > On Tue, Aug 6, 2019 at 7:35 AM Mark Rutland wrote:
> > > >
> > &g
On Tue, Aug 06, 2019 at 09:31:55AM -0700, Rob Clark wrote:
> On Tue, Aug 6, 2019 at 7:35 AM Mark Rutland wrote:
> >
> > On Tue, Aug 06, 2019 at 07:11:41AM -0700, Rob Clark wrote:
> > > On Tue, Aug 6, 2019 at 1:48 AM Christoph Hellwig wrote:
> > > >
>
On Tue, Aug 06, 2019 at 07:11:41AM -0700, Rob Clark wrote:
> On Tue, Aug 6, 2019 at 1:48 AM Christoph Hellwig wrote:
> >
> > This goes in the wrong direction. drm_cflush_* are a bad API we need to
> > get rid of, not add use of it. The reason for that is two-fold:
> >
> > a) it doesn't address
On Mon, Jul 09, 2018 at 07:55:20PM +0200, Daniel Vetter wrote:
> On Mon, Jul 9, 2018 at 6:12 PM, Mark Rutland wrote:
> > On Mon, Jul 09, 2018 at 06:03:42PM +0200, Peter Zijlstra wrote:
> >> On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote:
> >> > for_eac
On Mon, Jul 09, 2018 at 06:03:42PM +0200, Peter Zijlstra wrote:
> On Mon, Jul 09, 2018 at 05:52:04PM +0200, Daniel Vetter wrote:
> > for_each_something(foo)
> > if (foo->bla)
> > call_bla(foo);
> > else
> > call_default(foo);
> >
> > Totally contrived, but this comp
On Tue, Mar 07, 2017 at 10:14:20AM -0700, Jordan Crouse wrote:
> Support per-instance pagetables for 5XX targets. Per-instance
> pagetables allow each open DRM instance to have its own VM memory
> space to prevent accidently or maliciously copying or overwriting
> buffers from other instances. It a
On Mon, Oct 24, 2016 at 10:35:30AM -0700, Kevin Hilman wrote:
> Hi Mark,
>
> Mark Rutland writes:
> > On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
> >> +static int da8xx_ddrctl_probe(struct platform_device *pdev)
> >> +{
> >> + c
On Mon, Oct 24, 2016 at 06:46:36PM +0200, Bartosz Golaszewski wrote:
> Create a new driver for the da8xx DDR2/mDDR controller and implement
> support for writing to the Peripheral Bus Burst Priority Register.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> .../memory-controllers/ti-da8xx-ddrctl.t
On Fri, Jul 22, 2016 at 05:07:14PM +0800, Lin Huang wrote:
> +config ROCKCHIP_SIP
> + bool "Rockchip SIP interface"
> + depends on ARM64 && ARM_PSCI_FW
> + help
> + Say Y here if you want to enable SIP callbacks for Rockchip platforms
> + This option enables support for comm
On Fri, Jun 17, 2016 at 01:03:41PM +0100, Jon Hunter wrote:
> The I2C driver core for boards using device-tree assumes any subnode of
> an I2C adapter in the device-tree blob as being a I2C slave device.
> Although this makes complete sense, some I2C adapters may have subnodes
> which are not I2C s
On Fri, Apr 01, 2016 at 05:21:51PM +0100, Liviu Dudau wrote:
> Add DT bindings documentation for the Mali Display Processor. The bindings
> describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
>
> Cc: Rob Herring
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Ian
On Tue, Feb 23, 2016 at 11:00:21AM +0800, Xinliang Liu wrote:
> Add ADE display controller binding doc.
> Add DesignWare DSI Host Controller v1.20a binding doc.
>
> v5:
> - Remove endpoint unit address of dsi output port.
> - Add "hisilicon,noc-syscon" property for ADE NOC QoS syscon.
> - Add "res
> + /* FIXME - use of_graph_get_port_by_id(np, 1) on newer kernels */
> + in_ep = of_graph_get_next_endpoint(np, NULL);
Huh?
> + edidp = of_get_property(np, "edid", &size);
This property wasn't mentioned in the binding document.
Please describe it. If it's from a more generic bindin
On Fri, Oct 16, 2015 at 08:15:08PM +0800, CK Hu wrote:
> From: Jitao Shi
>
> Add documentation for DT properties supported by ps8640
> DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
> ---
> .../devicetree/bindings/video/bridge/ps8640.txt| 48
>
> 1 file changed, 48
On Mon, Oct 06, 2014 at 11:13:51AM +0100, Thierry Reding wrote:
> On Wed, Oct 01, 2014 at 04:53:01PM +0200, Boris Brezillon wrote:
> > From: Boris BREZILLON
> >
> > The HLCDC IP available in some Atmel SoCs (i.e. sam9x5i.e. at91sam9n12,
> > at91sam9x5 family or sama5d3 family) provide a PWM devic
On Fri, Sep 19, 2014 at 08:53:48PM +0100, Sean Paul wrote:
> Per NVidia, this clock rate should be around 70MHz in
> order to properly sample reads on data lane 0. In order
> to achieve this rate, we need to reparent the clock from
> clk_m which can only achieve 12MHz. Add parent_lp to the
> dts bi
On Tue, Aug 19, 2014 at 08:40:51PM +0100, Jyri Sarha wrote:
> On 08/19/2014 04:16 PM, Mark Rutland wrote:
> > On Mon, Aug 18, 2014 at 10:46:41PM +0100, Jyri Sarha wrote:
> >> Add machine driver support for BeagleBone-Black HDMI audio. BBB has
> >> NXP TDA998X HDMI tra
On Mon, Aug 18, 2014 at 10:46:41PM +0100, Jyri Sarha wrote:
> Add machine driver support for BeagleBone-Black HDMI audio. BBB has
> NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The
> 44100 Hz sample-rate and it's multiples can not be accurately produced
> on BBB. The only suppo
On Tue, Aug 19, 2014 at 01:23:12PM +0100, Jyri Sarha wrote:
> On 08/19/2014 02:32 PM, Mark Rutland wrote:
> > On Mon, Aug 18, 2014 at 10:46:39PM +0100, Jyri Sarha wrote:
> >> The added ti,gpio-clock is a basic clock that can be enabled and
> >> disabled trough a
On Mon, Aug 18, 2014 at 10:46:39PM +0100, Jyri Sarha wrote:
> The added ti,gpio-clock is a basic clock that can be enabled and
> disabled trough a gpio output. The DT binding document for the clock
> is also added. For EPROBE_DEFER handling the registering of the clock
> has to be delayed until of_
On Wed, Jul 02, 2014 at 10:01:40PM +0100, Rob Clark wrote:
> On Wed, Jul 2, 2014 at 2:09 PM, Mark Rutland wrote:
> > On Tue, Jul 01, 2014 at 07:57:35PM +0100, Rob Clark wrote:
> >> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
> >> add nece
On Tue, Jul 01, 2014 at 07:57:35PM +0100, Rob Clark wrote:
> Now that we (almost) have enough dependencies in place (MMCC, RPM, etc),
> add necessary DT support so that we can use drm/msm on upstream kernel.
>
> Signed-off-by: Rob Clark
> ---
> Commence bikeshedding :-)
>
> Documentation/device
On Fri, Jun 27, 2014 at 11:24:58AM +0100, Inki Dae wrote:
>
> + DT mailing list
Thanks for the Cc.
Can we get the rest of the series? Judging a series based on its
diffstat alone is a little hard...
Or is my mailbox filtering hiding the rest of these from me?
Any reason for not Ccing lakml?
M
On Mon, Jan 27, 2014 at 05:33:51PM +, Davor Joja wrote:
> Hi Mark,
>
> > On Mon, Jan 27, 2014 at 03:47:42PM +, Davor Joja wrote:
> > > Hi,
> >
> > Hi,
> >
> > >
> > > Can I please get comments about adding new vendor prefix "xylon", and on
> > > following devicetree binding for Xylon c
On Tue, Oct 29, 2013 at 08:12:32AM +, Shirish S wrote:
> This patch adds dt support to hdmiphy config settings
> as it is board specific and depends on the signal pattern
> of board.
>
> Signed-off-by: Shirish S
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt | 34 +
> d
On Tue, Oct 15, 2013 at 08:04:20AM +0100, Archit Taneja wrote:
> Enable use of DT for DMM/Tiler.
>
> Originally worked on by Andy Gross
>
> Cc: Andy Gross
> Cc: DRI Development
> Signed-off-by: Archit Taneja
> ---
> drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 11 +++
> 1 file changed,
On Mon, Oct 28, 2013 at 10:15:00AM +, Shirish S wrote:
> Hi Mark,
> Firstly thanks for reviewing.
Hi,
Please could you refrain from replying in HTML and use plaintext, it's rather
difficult to respond sensibly.
>
>
> On Mon, Oct 28, 2013 at 12:20 PM, Mark Rutland
Hi,
On Mon, Oct 28, 2013 at 06:24:22AM +, Shirish S wrote:
> This patch adds dt support to hdmiphy config settings
> as it is board specific and depends on the signal pattern
> of board.
>
> Signed-off-by: Shirish S
> ---
> .../devicetree/bindings/video/exynos_hdmi.txt | 29
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> This patch adds a dt-binding document for exynos rotator. It describes which
> nodes should be defined to use the rotator.
>
> Signed-off-by: Chanho Park
> Signed-off-by: Kyungmin Park
> ---
> .../bindings/drm/exynos/samsung-rotator
On Mon, Jul 22, 2013 at 07:49:26AM +0100, Chanho Park wrote:
> This patch adds a dt-binding document for exynos rotator. It describes which
> nodes should be defined to use the rotator.
>
> Signed-off-by: Chanho Park
> Signed-off-by: Kyungmin Park
> ---
> .../bindings/drm/exynos/samsung-rotator
52 matches
Mail list logo
