From: Sasha Levin <sashal@kernel.org>
To: Jiri Kosina <jikos@kernel.org>
Cc: Vladis Dronov <vdronov@redhat.com>, stable@vger.kernel.org
Subject: Re: [PATCH v3] HID: debug: fix the ring buffer implementation
Date: Wed, 30 Jan 2019 12:52:02 -0500 [thread overview]
Message-ID: <20190130175202.GS3973@sasha-vm> (raw)
In-Reply-To: <nycvar.YFH.7.76.1901301758170.6626@cbobk.fhfr.pm>
On Wed, Jan 30, 2019 at 05:59:43PM +0100, Jiri Kosina wrote:
>On Wed, 30 Jan 2019, Sasha Levin wrote:
>
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a "Fixes:" tag,
>> fixing commit: cd667ce24796 HID: use debugfs for events/reports dumping.
>>
>> The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96, v4.9.153, v4.4.172, v3.18.133.
>>
>> v4.20.5: Build OK!
>> v4.19.18: Build OK!
>> v4.14.96: Failed to apply! Possible dependencies:
>> 0eecc636e5a2 ("bus: ti-sysc: Add minimal TI sysc interconnect target driver")
>> 49a0a3d805df ("bus: ti-sysc: Make omap_hwmod_sysc_fields into sysc_regbits platform data")
>> 566a9b05e1fa ("bus: ti-sysc: Handle module quirks based dts configuration")
>> 6396bb221514 ("treewide: kzalloc() -> kcalloc()")
>> 695eea3d2c7f ("ARM: OMAP2+: Enable ti-sysc to use device tree data for smartreflex")
>> 70a65240efb1 ("bus: ti-sysc: Add register bits for interconnect target modules")
>> a7199e2b91de ("bus: ti-sysc: Detect i2c interconnect target module based on register layout")
>> bf8070522298 ("ARM: OMAP2+: Move all omap_hwmod_sysc_fields to omap_hwmod_common_data.c")
>> c5a2de97fbd2 ("bus: ti-sysc: Add parsing of module capabilities")
>> d060b40523dc ("ARM: OMAP2+: Prepare to pass auxdata for smartreflex")
>> ef70b0bdeaf8 ("bus: ti-sysc: Add support for platform data callbacks")
>>
>> v4.9.153: Failed to apply! Possible dependencies:
>> 174cd4b1e5fb ("sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>")
>> 1cec20f0ea0e ("dma-buf: Restart reservation_object_wait_timeout_rcu() after writes")
>> 555570d744f8 ("sched/clock: Update static_key usage")
>> 78010cd9736e ("dma-buf/fence: add an lockdep_assert_held()")
>> 983de5f97169 ("firmware: tegra: Add BPMP support")
>> 9881b024b7d7 ("sched/clock: Delay switching sched_clock to stable")
>> acb04058de49 ("sched/clock: Fix hotplug crash")
>> ae7e81c077d6 ("sched/headers: Prepare for new header dependencies before moving code to <uapi/linux/sched/types.h>")
>> b52992c06c90 ("drm/i915: Support asynchronous waits on struct fence from i915_gem_request")
>> ca791d7f4256 ("firmware: tegra: Add IVC library")
>> e601757102cf ("sched/headers: Prepare for new header dependencies before moving code to <linux/sched/clock.h>")
>> ea8b1c4a6019 ("drivers: psci: PSCI checker module")
>> f54d1867005c ("dma-buf: Rename struct fence to dma_fence")
>> fedf54132d24 ("dma-buf: Restart reservation_object_get_fences_rcu() after writes")
>>
>> v4.4.172: Failed to apply! Possible dependencies:
>> 0529900a01cb ("crypto: omap-aes - Support crypto engine framework")
>> 0bc40be85f33 ("drm/i915: Rename intel_engine_cs function parameters")
>> 174cd4b1e5fb ("sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>")
>> 2589ad84047f ("crypto: engine - move crypto engine to its own header")
>> 4cba7cf025f3 ("crypto: engine - permit to enqueue ashash_request")
>> 735d37b5424b ("crypto: engine - Introduce the block request crypto engine framework")
>> ae7e81c077d6 ("sched/headers: Prepare for new header dependencies before moving code to <uapi/linux/sched/types.h>")
>> c81d46138da6 ("drm/i915: Convert trace-irq to the breadcrumb waiter")
>> ca82580c9cea ("drm/i915: Do not call API requiring struct_mutex where it is not available")
>> cbdc12a9fc9d ("drm/i915: make A0 wa's applied to A1")
>> e87a005d90c3 ("drm/i915: add helpers for platform specific revision id range checks")
>> ea8b1c4a6019 ("drivers: psci: PSCI checker module")
>> ef712bb4b700 ("drm/i915: remove parens around revision ids")
>> f1b77aaca85a ("crypto: omap-des - Integrate with the crypto engine framework")
>> fffda3f4fb49 ("drm/i915/bxt: add revision id for A1 stepping and use it")
>>
>> v3.18.133: Failed to apply! Possible dependencies:
>> 00aa37206e1a ("of/reconfig: Add debug output for OF_RECONFIG notifiers")
>> 0529900a01cb ("crypto: omap-aes - Support crypto engine framework")
>> 174cd4b1e5fb ("sched/headers: Prepare to move signal wakeup & sigpending methods from <linux/sched.h> into <linux/sched/signal.h>")
>> 2589ad84047f ("crypto: engine - move crypto engine to its own header")
>> 310b0d55f030 ("crypto: omap-aes - Fix CTR mode")
>> 4cba7cf025f3 ("crypto: engine - permit to enqueue ashash_request")
>> 596103cf8fb0 ("crypto: drivers - Fix Kconfig selects")
>> 6c5063434098 ("crypto: ccp - Add ACPI support")
>> 7011a122383e ("crypto: nx - add NX-842 platform frontend driver")
>> 735d37b5424b ("crypto: engine - Introduce the block request crypto engine framework")
>> 8c98ebd7a6ff ("crypto: img-hash - CRYPTO_DEV_IMGTEC_HASH should depend on HAS_DMA")
>> a5bd093af0d1 ("crypto: ccp - Update CCP build support")
>> ae7e81c077d6 ("sched/headers: Prepare for new header dependencies before moving code to <uapi/linux/sched/types.h>")
>> b53a2340d0d3 ("of/reconfig: Add of_reconfig_get_state_change() of notifier helper.")
>> cfa8e7e70341 ("crypto: img-hash - Fix Kconfig selections")
>> d2e3ae6f3aba ("crypto: vmx - Enabling VMX module for PPC64")
>> d358f1abbf71 ("crypto: img-hash - Add Imagination Technologies hw hash accelerator")
>> f1b77aaca85a ("crypto: omap-des - Integrate with the crypto engine framework")
>> f5242e5a883b ("of/reconfig: Always use the same structure for notifiers")
>> f6892d193fb9 ("of/reconfig: Add empty stubs for the of_reconfig methods")
>> fdd05e4b9ae2 ("crypto: nx - rename nx-842.c to nx-842-pseries.c")
>
>FWIW the list of possible dependencies looks completely confused. If this
>is not some interminnent bug, the way how it's generated should probably
>be revisited.
It's actually somewhat accurate, but useless in this case :)
The reason for that mess is that on <=4.14 kernels, there is a
dependency on 6396bb22151 ("treewide: kzalloc() -> kcalloc()"), but
since that patch is a treewide change, to bring that in we need a big
pile of seemingly random patches from all over the tree, which is the
output you see.
--
Thanks,
Sasha
next prev parent reply other threads:[~2019-01-30 17:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-29 10:58 [PATCH v3] HID: debug: fix the ring buffer implementation Vladis Dronov
2019-01-29 12:55 ` Benjamin Tissoires
[not found] ` <20190130144646.2C96A218A4@mail.kernel.org>
2019-01-30 16:59 ` Jiri Kosina
2019-01-30 17:52 ` Sasha Levin [this message]
2019-01-30 18:13 ` Vladis Dronov
2019-02-08 14:45 ` Vladis Dronov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190130175202.GS3973@sasha-vm \
--to=sashal@kernel.org \
--cc=jikos@kernel.org \
--cc=stable@vger.kernel.org \
--cc=vdronov@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox