IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When cachefiles_cull() calls cachefiles_bury_object(), it passes
a NULL object. When this occurs, either trace_cachefiles_unlink()
or trace_cachefiles_rename() may oops due to the NULL object.
Check for NULL object in the tracepoint and if so, set debug_id
to MAX_UINT as was done in 2908f5e101.
The following oops was seen with xfstests generic/100.
BUG: kernel NULL pointer dereference, address: 0000000000000010
...
RIP: 0010:trace_event_raw_event_cachefiles_unlink+0x4e/0xa0 [cachefiles]
...
Call Trace:
cachefiles_bury_object+0x242/0x430 [cachefiles]
? __vfs_removexattr_locked+0x10f/0x150
? vfs_removexattr+0x51/0xd0
cachefiles_cull+0x84/0x120 [cachefiles]
cachefiles_daemon_cull+0xd1/0x120 [cachefiles]
cachefiles_daemon_write+0x158/0x190 [cachefiles]
vfs_write+0xbc/0x260
ksys_write+0x4f/0xc0
do_syscall_64+0x3b/0x90
The following oops was seen with xfstests generic/290.
BUG: kernel NULL pointer dereference, address: 0000000000000010
...
RIP: 0010:trace_event_raw_event_cachefiles_rename+0x54/0xa0 [cachefiles]
...
Call Trace:
cachefiles_bury_object+0x35c/0x430 [cachefiles]
cachefiles_cull+0x84/0x120 [cachefiles]
cachefiles_daemon_cull+0xd1/0x120 [cachefiles]
cachefiles_daemon_write+0x158/0x190 [cachefiles]
vfs_write+0xbc/0x260
ksys_write+0x4f/0xc0
do_syscall_64+0x3b/0x90
Fixes: 2908f5e101 ("fscache: Add a cookie debug ID and use that in traces")
Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Link: https://listman.redhat.com/archives/linux-cachefs/2021-October/msg00009.html
Looks like skl/bxt/derivatives also need the plane stride
stretch w/a when using async flips and VT-d is enabled, or
else we get corruption on screen. To my surprise this was
even documented in bspec, but only as a note on the
CHICHKEN_PIPESL register description rather than on the
w/a list.
So very much the same thing as on HSW/BDW, except the bits
moved yet again.
Cc: stable@vger.kernel.org
Cc: Karthik B S <karthik.b.s@intel.com>
Fixes: 55ea1cb178 ("drm/i915: Enable async flips in i915")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210930190943.17547-1-ville.syrjala@linux.intel.com
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
(cherry picked from commit d08df3b0bd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
the size of bdb_lfp_backlight_data structure has been increased,
causing if-statement in the parse_lfp_backlight function
that comapres this structure size to the one retrieved from BDB,
always to fail for older revisions.
This patch calculates expected size of the structure for a given
BDB version and compares it with the value gathered from BDB.
Tested on Chromebook Pixelbook (Nocturne) (reports bdb->version = 221)
Fixes: d381baad29 ("drm/i915/vbt: Fix backlight parsing for VBT 234+")
Tested-by: Lukasz Majczak <lma@semihalf.com>
Signed-off-by: Lukasz Majczak <lma@semihalf.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210930134606.227234-1-lma@semihalf.com
(cherry picked from commit 4378daf5d0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Atm during driver loading and system resume TypeC ports are accessed
before their HW/SW state is synced. Move the TypeC port sanitization to
the encoder's sync_state hook to fix this.
v2: Handle the encoder disabled case in gen11_dsi_sync_state() as well
(Jose, Jani)
Fixes: f9e76a6e68 ("drm/i915: Add an encoder hook to sanitize its state during init/resume")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210929132833.2253961-1-imre.deak@intel.com
(cherry picked from commit 7194dc998d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Commit 989634fb49 ("drm/i915/audio: set HDA link parameters in
driver") makes HDMI audio on Lenovo P350 disappear.
So in addition to TGL, extend the logic to RKL to use BIOS provided
value to fix the regression.
Fixes: 989634fb49 ("drm/i915/audio: set HDA link parameters in driver")
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210906041300.508458-1-kai.heng.feng@canonical.com
(cherry picked from commit c6b40ee330)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Both xen_pvh and xen_start_flags get written just once early during
init. Using the respective annotation then allows the open-coded placing
in .data to go away.
Additionally the former, like the latter, wants exporting, or else
xen_pvh_domain() can't be used from modules.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/8155ed26-5a1d-c06f-42d8-596d26e75849@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Two of the variables can live in .init.data, allowing the open-coded
placing in .data to go away. Another "variable" is used to communicate a
size value only to very early assembly code, which hence can be both
const and live in .init.*. Additionally two functions were lacking
__init annotations.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/3b0bb22e-43f4-e459-c5cb-169f996b5669@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
This was effectively lost while dropping PVHv1 code. Move the function
and arrange for it to be called the same way as done in PV mode. Clearly
this then needs re-introducing the XENFEAT_mmu_pt_update_preserve_ad
check that was recently removed, as that's a PV-only feature.
Since the string pointed at by pv_info.name describes the mode, drop
"paravirtualized" from the log message while moving the code.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/de03054d-a20d-2114-bb86-eec28e17b3b8@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Without announcing hvc0 as preferred it won't get used as long as tty0
gets registered earlier. This is particularly problematic with there not
being any screen output for PVH Dom0 when the screen is in graphics
mode, as the necessary information doesn't get conveyed yet from the
hypervisor.
Follow PV's model, but be conservative and do this for Dom0 only for
now.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/582328b6-c86c-37f3-d802-5539b7a86736@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
xenboot_write_console() is dealing with these quite fine so I don't see
why xenboot_console_setup() would return -ENOENT in this case.
Adjust documentation accordingly.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/3d212583-700e-8b2d-727a-845ef33ac265@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
With preferred consoles "tty" and "hvc" announced as preferred,
registering "xenboot" early won't result in use of the console: It also
needs to be registered as preferred. Generalize this from being DomU-
only so far.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/d4a34540-a476-df2c-bca6-732d0d58c5f0@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
The xen_hvm_early_write() path better wouldn't be taken in this case;
while port 0xE9 can be used, the hypercall path is quite a bit more
efficient. Put that first, as it may also work for DomU-s (see also
xen_raw_console_write()).
While there also bail from the function when the first
domU_write_console() failed - later ones aren't going to succeed.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/4fd89dcb-cfc5-c740-2e94-bb271e432d3e@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Decouple XEN_DOM0 from XEN_PV, converting some existing uses of XEN_DOM0
to a new XEN_PV_DOM0. (I'm not convinced all are really / should really
be PV-specific, but for starters I've tried to be conservative.)
For PVH Dom0 the hypervisor populates MADT with only x2APIC entries, so
without x2APIC support enabled in the kernel things aren't going to work
very well. (As opposed, DomU-s would only ever see LAPIC entries in MADT
as of now.) Note that this then requires PVH Dom0 to be 64-bit, as
X86_X2APIC depends on X86_64.
In the course of this xen_running_on_version_or_later() needs to be
available more broadly. Move it from a PV-specific to a generic file,
considering that what it does isn't really PV-specific at all anyway.
Note that xen/interface/version.h cannot be included on its own; in
enlighten.c, which uses SCHEDOP_* anyway, include xen/interface/sched.h
first to resolve the apparently sole missing type (xen_ulong_t).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/983bb72f-53df-b6af-14bd-5e088bd06a08@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Like xen_start_flags, xen_domain_type gets set before .bss gets cleared.
Hence this variable also needs to be prevented from getting put in .bss,
which is possible because XEN_NATIVE is an enumerator evaluating to
zero. Any use prior to init_hvm_pv_info() setting the variable again
would lead to wrong decisions; one such case is xenboot_console_setup()
when called as a result of "earlyprintk=xen".
Use __ro_after_init as more applicable than either __section(".data") or
__read_mostly.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/d301677b-6f22-5ae6-bd36-458e1f323d0b@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
The function doesn't use it and all of its callers say in a comment that
their respective arguments are to be non-NULL only in auto-translated
mode. Since xen_remap_domain_mfn_array() isn't supposed to be used by
non-PV, drop the parameter there as well. It was bogusly passed as non-
NULL (PRIV_VMA_LOCKED) by its only caller anyway. For
xen_remap_domain_gfn_range(), otoh, it's not clear at all why this
wouldn't want / might not need to gain auto-translated support down the
road, so the parameter is retained there despite now remaining unused
(and the only caller passing NULL); correct a respective comment as
well.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/036ad8a2-46f9-ac3d-6219-bdc93ab9e10b@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
xen_pfn_t is the same size as int only on 32-bit builds (and not even
on Arm32). Hence pfns[] can't be used directly to read individual error
values returned from xen_remap_domain_mfn_array(); every other error
indicator would be skipped/ignored on 64-bit.
Fixes: 3ad0876554 ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE")
Cc: stable@vger.kernel.org
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lore.kernel.org/r/aa6d6a67-6889-338a-a910-51e889f792d5@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Osstest has been suffering test failures for a little while from order-4
allocation failures, resulting from alloc_empty_pages() calling
kcalloc(). As there's no need for physically contiguous space here,
switch to kvcalloc().
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/6d698901-98a4-05be-c421-bcd0713f5335@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Any pending interrupt can prevent entering standby based power off state.
To avoid it, disable the GIC CPU interface.
Fixes: 8148d21360 ("ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set")
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Commit d39df15851 ("scsi: iscsi: Have abort handler get ref to conn")
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
then also changed the handling of the case where we detect an already
completed task where we now end up doing a goto to the common put/cleanup
code. This results in a iscsi_task use after free, because the common
cleanup code will do a put on the iscsi_task.
This reverts the goto and moves the iscsi_get_conn() to after we've checked
if the iscsi_task is valid.
Link: https://lore.kernel.org/r/20211004210608.9962-1-michael.christie@oracle.com
Fixes: d39df15851 ("scsi: iscsi: Have abort handler get ref to conn")
Signed-off-by: Mike Christie <michael.christie@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When an FC-GS I/O is aborted by lpfc, the driver requires a node pointer
for a dereference operation. In the abort I/O routine, the driver miscasts
a context pointer to the wrong data type and overwrites a single byte
outside of the allocated space. This miscast is done in the abort I/O
function handler because the handler works on both FC-GS and FC-LS
commands. However, the code neglected to get the correct job location for
the node.
Fix this by acquiring the necessary node pointer from the correct job
structure depending on the I/O type.
Link: https://lore.kernel.org/r/20211004231210.35524-1-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
It's not holding the lock at this stage and the IRQ "flags" are not correct
so it would restore something bogus. Delete the unlock statement.
Link: https://lore.kernel.org/r/20211004103851.GE25015@kili
Fixes: 3e6414003b ("scsi: elx: efct: SCSI I/O handling routines")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The UFS driver uses blk_mq_tagset_busy_iter() when identifying task
management requests to complete, however blk_mq_tagset_busy_iter() doesn't
work.
blk_mq_tagset_busy_iter() only iterates requests dispatched by the block
layer. That appears as if it might have started since commit 37f4a24c24
("blk-mq: centralise related handling into blk_mq_get_driver_tag") which
removed 'data->hctx->tags->rqs[rq->tag] = rq' from blk_mq_rq_ctx_init()
which gets called:
blk_get_request
blk_mq_alloc_request
__blk_mq_alloc_request
blk_mq_rq_ctx_init
Since UFS task management requests are not dispatched by the block layer,
hctx->tags->rqs[rq->tag] remains NULL, and since blk_mq_tagset_busy_iter()
relies on finding requests using hctx->tags->rqs[rq->tag], UFS task
management requests are never found by blk_mq_tagset_busy_iter().
By using blk_mq_tagset_busy_iter(), the UFS driver was relying on internal
details of the block layer, which was fragile and subsequently got
broken. Fix by removing the use of blk_mq_tagset_busy_iter() and having the
driver keep track of task management requests.
Link: https://lore.kernel.org/r/20210922091059.4040-1-adrian.hunter@intel.com
Fixes: 1235fc569e ("scsi: ufs: core: Fix task management request completion timeout")
Fixes: 69a6c269c0 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs")
Cc: stable@vger.kernel.org
Tested-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Commit 756fb6a895 ("scsi: acornscsi: Remove tagged queuing vestiges")
mistakenly introduced a reference to function scsi_cmd_to_tag(). This
function does not exist as it was removed from an earlier series version
when I upstreamed the named commit - originally authored By Hannes - but
this reference still remained.
Fix by replacing the reference to scsi_cmd_to_tag() with
scsi_cmd_to_rq(scsi_scmd)->tag, which scsi_cmd_to_tag() was a wrapper for.
Link: https://lore.kernel.org/r/1633002717-79765-1-git-send-email-john.garry@huawei.com
Fixes: 756fb6a895 ("scsi: acornscsi: Remove tagged queuing vestiges")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This contains a single patch to properly implement clone3() on rv32,
which was missing before. In theory this is a new feature, but it's
fixing a warning in checksyscalls that's now causing my build to fail so
I'm calling it a fix.
As far as I can tell this should be enabled on rv32 as well, I'm not
sure why it's rv64-only. checksyscalls is complaining about our lack of
clone3() on rv32.
Fixes: 56ac5e2139 ("riscv: enable sys_clone3 syscall for rv64")
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
This Kselftest fixes update for Linux 5.15-rc5 consists of a fix
to implicit declaration warns in drivers/dma-buf test.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEPZKym/RZuOCGeA/kCwJExA0NQxwFAmFbaykACgkQCwJExA0N
QxwXRhAAwGntF/dFNcKspMKTepdmKLFHr5Mopd1+OMbVLgjQAtXZs+wCoR0tm6RK
EZf5D7y8IpGedFnbjWJ1t18XCRJtBW7HladC6otTmR0+1SEFdHR1n4H/pqrmSagV
5rYqwh1BgTb5Eb/9GPWKlZ0zagXGujR5UVdFPqCEMWpF6be9J989NdKGzpD4Qbkq
eux3x5iaz5dsVf7iTGhzy+iSxKqIqSw5LCtSrE3PoTRbM5PS+K4I7ImafysnsYK9
kZ8zkmEzixziwoWUEJLRqFveS7cY/5l7Nd2kD9YH1WE2xBYxYQZFdj4HVWdlQePd
99UthTSfcyO6C2fplorlKkoNKuX1tlGCJyZbNjgQSHPYuVrLoau136yoSk5F+ZPg
OUFsIs52d09e7vN70nh7UD9rRqihFRWwgI4EQt9nUP1mAmYm8y7bXKSFDF5hp3ay
4VbvYl50QEkllqU0sDcEuFAodGLz72T2PZNWP5DQxg5q70Hni/CWqFm+EizztRCi
mv749twroD61b8Jziu8Mqhp5BqlO1tY8uu9z4GuRC4UIMhdARY2J4mD+8wm03JRO
4S28o+mH4StrrhyjngrCM9k8YYwa/n+XDrswiNJIpd/PmxVXD1KUP6z80sQE6Tcb
o34yFVeABzdovryC/8VwDC9n3RDYIN6SM5XqOxvX5jckdtfwCbI=
=t85S
-----END PGP SIGNATURE-----
Merge tag 'linux-kselftest-fixes-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
Pull Kselftest fixes from Shuah Khan:
"A fix to implicit declaration warns in drivers/dma-buf test"
* tag 'linux-kselftest-fixes-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
selftests: drivers/dma-buf: Fix implicit declaration warns
Change setting for 400KHz frequency support by more accurate value.
Fixes: 66b0c2846b ("i2c: mlxcpld: Add support for I2C bus frequency setting")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Value for getting frequency capability wrongly has been taken from
register offset instead of register value.
Fixes: 66b0c2846b ("i2c: mlxcpld: Add support for I2C bus frequency setting")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
make dtbs_check:
arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dt.yaml: bridge@2c: reg:0:0: 45 was expected
According to the datasheet, the I2C address can be either 0x2c or 0x2d,
depending on the ADDR control input.
Fixes: e3896e6ddd ("dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Link: https://lore.kernel.org/r/08f73c2aa0d4e580303357dfae107d084d962835.1632486753.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSQHSd0lITzzeNWNm3h3BK/laaZPAUCYVrm7wAKCRDh3BK/laaZ
PCTFAQDESDvQTW4tLj8jdb9ELVCekNtgU6bVJCgUWqR6M1iZcgD8DiqinvagWhEN
K8R/ayWMaPSMA3NEDTlLHy8Bx2iqow4=
=PvJ5
-----END PGP SIGNATURE-----
Merge tag 'ovl-fixes-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs
Pull overlayfs fixes from Miklos Szeredi:
"Fix two bugs, both of them corner cases not affecting most users"
* tag 'ovl-fixes-5.15-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
ovl: fix IOCB_DIRECT if underlying fs doesn't support direct IO
ovl: fix missing negative dentry check in ovl_rename()
-----BEGIN PGP SIGNATURE-----
iQJOBAABCAA4FiEEbt46xwy6kEcDOXoUeZbBVTGwZHAFAmFa4Q4aHHRzYm9nZW5k
QGFscGhhLmZyYW5rZW4uZGUACgkQeZbBVTGwZHCjmg/+L7RkL4LI9zDHXc3J4VXA
r+yggN/YC4OalfyfIUuNUJnI2meQidoxUOiL/5U1kV4wUN+5GMqkQOzTRNrmwJln
NRLAHuo/oyXsLFcqnzLzyU2s1S6pxbO1P65yiGDPn/4nl/+i6k8cVq3VzrDzMqIW
LhU2bQMisNU359z1jndmIlFEjdo3ECLarORlckA/HtImskCLchU7MW5MwC0CAKPK
988sb/LmNVUJ5PxKr1EopBE89kxBF2Ziz4fz3mTt6IOgWJSafxo8l0mUfYdZVLbD
RmhKwHh6lxdKP8RPRJQ3pD+PQYxAioKdk9bHE0A68Yh7rkgKrcp5SrXcQQC0it6u
RZJBQ/QNUl2yeihtXMlWuWtpE+dKMlqhqxkCtk53czepDU2CnrrxLDiUTRb1IYFD
cTtmNNN+Wa2sg/s1atK06/X6/vhkMAdaBp+ZlK+r4Q8NLWX+OG9mROMe+5Cy5/KY
zPvIlvUXpSr0/GLFjiSgi9DfAWTm5o/HHIAPVmZPnXRs9WrH4WfMZEDd76vfSAKf
9Z7X0ycRZI4fATOZEb0AllUPuOYuOzdCpGYfuVODSkRt1df047g4o3RBFYi/acAn
aGGoOUUcEdq3NWvF4+14Upio64vmwNXy3c0O8RxleidgN80c1MFiCq0M6bWyzQnX
j1EWEZmqnvb6vXJPLzywNLE=
=C4kp
-----END PGP SIGNATURE-----
Merge tag 'mips-fixes_5.15_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fix from Thomas Bogendoerfer:
"Revert workaround for buggy cpu detection because regressions"
* tag 'mips-fixes_5.15_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: Revert "add support for buggy MT7621S core detection"
The input_system_configure_channel_sensor() function lost its final
return code in a previous patch:
drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c: In function 'input_system_configure_channel_sensor':
drivers/staging/media/atomisp/pci/hive_isp_css_common/host/input_system.c:1649:1: error: control reaches end of non-void function [-Werror=return-type]
Restore what was there originally.
Link: https://lore.kernel.org/linux-media/20210802143820.1150099-1-arnd@kernel.org
Fixes: 728a5c64ae ("media: atomisp: remove dublicate code")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
While debugging an issue we've found that $DEBUGFS/block/$disk/state
doesn't decode QUEUE_FLAG_HCTX_ACTIVE but only displays its numerical
value.
Add QUEUE_FLAG(HCTX_ACTIVE) to the blk_queue_flag_name array so it'll get
decoded properly.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Link: https://lore.kernel.org/r/4351076388918075bd80ef07756f9d2ce63be12c.1633332053.git.johannes.thumshirn@wdc.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
A packet received on a trunk will have bit 2 set in Forward DSA tagged
frame. Bit 1 can be either 0 or 1 and is otherwise undefined and bit 0
indicates the frame CFI. Masking with 7 thus results in frames as
being identified as being from a trunk when in fact they are not. Fix
the mask to just look at bit 2.
Fixes: 5b60dadb71 ("net: dsa: tag_dsa: Support reception of packets from LAG devices")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
On the LS1028A this instance of the eSDHC controller is intended for
either an eMMC or eSDIO card. It doesn't provide a card detect pin and
its IO voltage is fixed at 1.8V.
Remove the bogus broken-cd property, instead add the non-removable
property. Fix the voltage-ranges property and set it to 1.8V only.
Fixes: 491d3a3fc1 ("arm64: dts: ls1028a: Add esdhc node in dts")
Signed-off-by: Michael Walle <michael@walle.cc>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The buck2 output of the PMIC is the VDD core voltage of the cpu.
Switching off this will poweroff the CPU. Add the 'regulator-always-on'
property to avoid this.
Fixes: 8668d8b2e6 ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and baseboards")
Signed-off-by: Heiko Thiery <heiko.thiery@gmail.com>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
With commit c709135e57 ("pinctrl: at91-pio4: add support for slew-rate")
and commit cbde6c823b ("pinctrl: at91-pio4: Fix slew rate disablement")
the slew-rate is enabled by default for each configured pin. The datasheet
specifies at chapter "Output Driver AC Characteristics" that HSIO
drivers (use in SDMMCx and QSPI0 peripherals), don't have a slewrate
setting but are rather calibrated against an external 1% resistor mounted
on the SDMMCx_CAL or QSPI0_CAL pins. Depending on the target signal
frequency and the external load, it is possible to adjust their target
output impedance. Thus set slew-rate = <0> for SDMMC (QSPI is not enabled
at the moment in device tree).
Fixes: 7540629e2f ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20210915074836.6574-3-claudiu.beznea@microchip.com
Datasheet chapter "EMAC Timings" specifies that while in 3.3V domain
GMAC's MDIO pins should be configured with slew-rate enabled, while the
data + signaling pins should be configured with slew-rate disabled when
GMAC works in RGMII or RMII modes. The pin controller for SAMA7G5 sets
the slew-rate as enabled for all pins. Adapt the device tree to comply
with these.
Fixes: 7540629e2f ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20210915074836.6574-2-claudiu.beznea@microchip.com
In suspend/resume procedure for AT91 architecture different controllers
(PMC, SHDWC, RAM, RAM PHY, SFRBU) are accessed to do the proper settings
for power saving. Commit f0bbf17958 ("ARM: at91: pm: add self-refresh
support for sama7g5") introduced the access to RAMC PHY controller for
SAMA7G5. The access to this controller is done after RAMC ports are
closed, thus any TLB walk necessary for RAMC PHY virtual address will
fail. In the development branch this was not encountered. However, on
current kernel the issue is reproducible.
To solve the issue the previous mechanism of pre-loading the TLB with
the RAMC PHY virtual address has been used. However, only the addition
of this new pre-load breaks the functionality for ARMv5 based
devices (SAM9X60). This behavior has been encountered previously
while debugging this code and using the same mechanism for pre-loading
address for different controllers (e.g. pin controller, the assumption
being that other requested translations are replaced from TLB).
To solve this new issue the TLB flush + the extension of pre-loading
the rest of controllers to TLB (e.g. PMC, RAMC) has been added. The
rest of the controllers should have been pre-loaded previously, anyway.
Fixes: f0bbf17958 ("ARM: at91: pm: add self-refresh support for sama7g5")
Depends-on: e42cbbe5c9 ("ARM: at91: pm: group constants and addresses loading")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20210930154219.2214051-4-claudiu.beznea@microchip.com
SAMA7G5-EK board has DDR3L type of memory soldered. This needs 1.35V. The
1.35V for DDR3L rail at run-time is selected by the proper configuration
on SELV2 pin (for 1.35V it needs to be in high-z state). When suspended
the MCP16502 PMIC soldered on SAMA7G5-EK will use different sets of
configuration registers to provide proper voltages on its rail. Run-time
configuration registers could be configured differently than suspend
configuration register for MCP16502 (VSEL2 affects only run-time
configuration). In suspend states the DDR3L memory soldered on SAMA7G5-EK
switches to self-refresh. Even on self-refresh it needs to be powered by
a 1.35V rail. Thus, make sure the PMIC is configured properly when system
is suspended.
Fixes: 7540629e2f (ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20210930154219.2214051-2-claudiu.beznea@microchip.com
