There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refactor the code according to the use of a flexible-array member in
struct phm_acp_clock_voltage_dependency_table, instead of a one-element
array, and use the struct_size() helper to calculate the size for the
allocation.
Also, save some heap space as the original code is multiplying
table->numEntries by sizeof(struct phm_acp_clock_voltage_dependency_table)
when it should have multiplied it by sizeof(phm_acp_clock_voltage_dependency_record)
instead.
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
Build-tested-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/lkml/5f7c5d3c.TyfOhg%2FA6JycL6ZN%25lkp@intel.com/
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refactor the code according to the use of a flexible-array member in
struct phm_uvd_clock_voltage_dependency_table, instead of a one-element
array, and use the struct_size() helper to calculate the size for the
allocation.
Also, save some heap space as the original code is multiplying
table->numEntries by sizeof(struct phm_uvd_clock_voltage_dependency_table)
when it should have multiplied it by sizeof(phm_uvd_clock_voltage_dependency_record)
instead.
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
Build-tested-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/lkml/5f7c433e.pXkC6KsN6HN%2FLdhj%25lkp@intel.com/
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refactor the code according to the use of a flexible-array member in
struct phm_clock_array, instead of a one-element array, and use the
struct_size() helper to calculate the size for the allocation.
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
Build-tested-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/lkml/5f7c433f.ZyMD+YUIVAwiHGVe%25lkp@intel.com/
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is a regular need in the kernel to provide a way to declare having
a dynamically sized set of trailing elements in a structure. Kernel code
should always use “flexible array members”[1] for these cases. The older
style of one-element or zero-length arrays should no longer be used[2].
Refactor the code according to the use of a flexible-array member in
struct phm_clock_voltage_dependency_table, instead of a one-element
array, and use the struct_size() helper to calculate the size for the
allocation.
[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays
Build-tested-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/lkml/5f7c295c.8iqp1Ifc6oiVDq%2F%2F%25lkp@intel.com/
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Just a single change to revert enablement of packet error checking
for battery data on Chromebooks, since some of their embedded
controllers do not handle it correctly.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE72YNB0Y/i3JqeVQT2O7X88g7+poFAl+AoycACgkQ2O7X88g7
+pqMCQ//UIISw36pIoARWoPqGYY3vqemN8TjC5QjmkyIoAhK/GY2vcEfBA+uBs/j
pb2C5V1MQOsQRQWobAQh47NVonU10SZupodZtQBw6xQFRvwrkzMJCw0wpo+7jppl
pZkyxjcojdZeAlhHwMalLi/sQEOLlF0aj6rFZcEz2kMaqB/xsXZmwtH3TzH560qi
Z+H1qWZnuqh+KoyQE+Wwo1yc75kjondkMZGcDqe7n6uST2UF90xg61snCr9mXnbr
8FlRxBuPVcud+7lEwvS9PFZR1qiH6NjPmTDecBIuvBAarnLlMxsVOIeJXbHjU40s
nitqjXUSHbYEeotRhWd8BHcu2REzCL1oyLRZsNgL0E/d6/9twcjzWVkuvA8gRb7h
ptbe0VCLnnDgZFji9ZxMhISZ1cQw8xRGq73GnZseaetNDBn7YxuNt3jNOxPw/dp8
KHci8q60YQpLIvyaxO+2Z06EgTop18AG7tFmz1PQEd6yWTMdGm0aRwotZHzgOO/C
1np6TXJOtg4A7FhEluWchBvpDi17aHxNt+dcxzie/KtxlJKxInd7/TxsJk3uukxH
OJWODi5k0sDzZj2Rnw70uCiKfI89iXAev13gwfee+v8zTeujHdKe/dEpvPOQBqtY
2QA9wFdBDsgZ6I1smVL0fz05aDJ8hrzNj/Y1yc9tLhzrVoEwmjE=
=VEU/
-----END PGP SIGNATURE-----
Merge tag 'for-v5.9-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
Pull power supply fix from Sebastian Reichel:
"Just a single change to revert enablement of packet error checking for
battery data on Chromebooks, since some of their embedded controllers
do not handle it correctly"
* tag 'for-v5.9-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply:
power: supply: sbs-battery: chromebook workaround for PEC
After commit 923218f616 ("blk-mq: don't allocate driver tag upfront
for flush rq"), blk_mq_submit_bio() will call blk_insert_flush()
directly to handle flush request rather than blk_mq_sched_insert_request()
in the case of elevator.
Then, all flush request either have set RQF_FLUSH_SEQ flag when call
blk_mq_sched_insert_request(), or have inserted into hctx->dispatch.
So, remove the dead code path.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Since whole elevator register is protectd by sysfs_lock, we
don't need extras 'has_elevator'. Just use q->elevator directly.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
After commit b89f625e28 ("block: don't release queue's sysfs
lock during switching elevator"), whole elevator register and
unregister function are covered by sysfs_lock. So, remove wrong
comment and add lockdep assert.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We have introduced helper function blk_mq_hctx_stopped() to test
BLK_MQ_S_STOPPED.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We have defined common interface blk_queue_registered() to
test QUEUE_FLAG_REGISTERED. Just use it.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
elv_support_iosched() will check queue_is_mq() for us. So, remove
the redundant check to clean code.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
We will register debugfs for scheduler no matter whether it have
defined callback funciton .exit_sched. So, blk_mq_exit_sched()
is always needed to unregister debugfs. Also, q->elevator should
be set as NULL after exiting scheduler.
For now, since all register scheduler have defined .exit_sched,
it will not cause any actual problem. But It will be more reasonable
to do this change.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
- Fix a compilation issue with User Mode Linux.
- Handle spurious interrupts properly in the PCA953x driver.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAl+AHKoACgkQQRCzN7AZ
XXPYZA//WRC6B4jSm5Fjg55Wik/L9FwWyZRSEWvFg0+vfEhJ3W/Q9seGHGhsN+J0
SASL72NTJLVkX4UKIrC+7wMe6HgDtpu+0CjXSoHsQOcHDl1a69qGWpjsIVfT+2yQ
sz8Gn8SjWmSRMaoW30UWZ3FdCJK3OSyQt0OWIClxk172TaAhcYqqlv2Ix97JdFd8
8EEBvXFJ2w6qEy3lg+0FEcC0atzmaxLqlMbQrj+43eXlOkB1RpW52CUlblumnTul
Thyd1A3FNTKJDyr/gVGqyLci32fopQDsT2DO5PNzjOHJo8Ep/INyloGid5qEm34z
XxaOoD87CSlcwgLOTN4TmnlKh9wP9K+6TWXRoxG/gjDJbpWR5d6H5DDnPGzLCeQ4
576IuwuIcsMbSZhCTnAIzNoMBGgdwFThFxCz9zCWzQwVRpWkNjYZfr2FAHPLVSAP
3wceCAhID0/1kN0Jys/3T+eHRlEuDDF1AbaTiePjB8pTk0tICJnGPddTEeZqYgy1
kk5zXhmGCoEX5Ne/UvoaJ9rerGUow2E1TREnpRV3Cj+nqmJRP4TCM47pLIXW5W9S
CkFKAn6EWYH/5lH1jBdkbrLjLXSvVUTXViHa9xa9VNT42+fpRM+3L3qXnStPPN3f
BY3lH4LebsmSO4XgpoRo03dw/bINrX0L0xccYylEX235Dm2iZps=
=yEo/
-----END PGP SIGNATURE-----
Merge tag 'gpio-v5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"Some late fixes: one IRQ issue and one compilation issue for UML.
- Fix a compilation issue with User Mode Linux
- Handle spurious interrupts properly in the PCA953x driver"
* tag 'gpio-v5.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: pca953x: Survive spurious interrupts
gpiolib: Disable compat ->read() code in UML case
We can't check ref->data->confirm_switch directly in __percpu_ref_exit(), since
ref->data may not be allocated in one not-initialized refcount.
Fixes: 2b0d3d3e4f ("percpu_ref: reduce memory footprint of percpu_ref in fast path")
Reported-by: syzbot+fd15ff734dace9e16437@syzkaller.appspotmail.com
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
when the hardware isn't going to use the aux plane there's no
real point in dealing with the relevant hardware restrictions.
So let's just skip all that when not necessary.
We can now also remove the offset=~0xfff behaviour for unused
color planes. Let's just zero out everyting so as to not leave
stale garbage behind to confuse people debugging the code.
v2: Explicitly set AUX_DIST to zero when there is no aux plane
Reviewed-by: Imre Deak <imre.deak@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201009120028.32422-1-ville.syrjala@linux.intel.com
When the number of potential color planes grew to 4 we stopped
setting all unused color plane offsets to ~0xfff. The code
still tries to do this, but actually does nothing since the
loop limits are bogus.
skl_check_main_surface() actually depends on this ~0xfff
behaviour as it will make sure to move the main surface
offset below the aux surface offset because the hardware
AUX_DIST must be a non-negative value [1], and for simplicity
it doesn't bother checking if the AUX plane is actually
needed or not. So currently it may end up shuffling the
main surface around based on some stale leftover AUX offset.
The skl+ plane code also just blindly calculates the AUX_DIST
whether or not the AUX plane is actually needed by the hw or
not, and that too will now potentially use some stale AUX
surface offset in the calculation. Would seem nicer to
guarantee a consistent non-negative AUX_DIST always.
So bring back the original ~0xfff offset behaviour for
unused color planes. Though it doesn't seem super likely
that this inconsistency would cause any real issues.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Fixes: 2dfbf9d287 ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008101608.8652-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
i915_{save,restore}_state() are actually all about the display.
Currently they are split into display part + SWF part. But since
the SWF part is also related to the display let's just move that
part into its own thing and flip the roles around so that the
current display part is the main function.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201005171441.26612-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
As with eDP and LVDS we should also respect the power cycle
delay on DSI panels. We are not using the power sequencer
for these, and we have no optimizations around the sleep
duration, so we just msleep() the whole thing away.
Note that the ICL+ DSI code doesn't seem to have any power
off/power cycle delay handling whatsoever. The only thing it
handles is the power on delay. As that looks pretty busted
in general I won't bother dealing with it for the time being.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Just like with eDP let's wait for the power sequencer power
cycle delay before we reboot the machine, as otherwise we
can't guarantee the panel's minimum power cycle delay will
be respected.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Extend the eDP panel power cycle delay wait on reboot handling
to cover all platforms. No reason to think that VLV/CHV are
in any way special since the documentation states that the
hardware power cycle delay goes back to its default value on
reset, and that may not be enough for all panels.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently VLV/CHV use a reboot notifier to make sure the panel
power cycle delay isn't violated across a system reboot. Replace
that with the new encoder .shutdown() hook.
And let's also stop overriding the power cycle delay with the
max value. No idea why the current code does that. The already
programmed delay should be correct.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Implement the pci .shutdown() hook in order to quiesce the
hardware prior to reboot. The main purpose here is to turn
all displays off. Some displays/other drivers tend to get
confused if the state after reboot isn't exactly as they
expected.
One specific example was the Dell UP2414Q in MST mode.
It would require me to pull the power cord after a reboot
or else it would just not come back to life. Sadly I don't
have that at hand anymore so not sure if it's still
misbehaving without the graceful shutdown, or if we
managed to fix something else since I last tested it.
For good measure we do a gem suspend as well, so that
we match the suspend flow more closely. Also stopping
all DMA and whatnot is probably a good idea for kexec.
I would expect that some kind of GT reset happens on
normal reboot so probably not totally necessary there.
v2: Use the pci .shutdown() hook instead of a reboot notifier (Lukas)
Do the gem suspend for kexec (Chris)
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201001151640.14590-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
If compressed inode has inconsistent fields on i_compress_algorithm,
i_compr_blocks and i_log_cluster_size, we missed to set SBI_NEED_FSCK
to notice fsck to repair the inode, fix it.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
AMD Family 19h Models 20h-2Fh use the same PCI IDs as Family 17h Models
70h-7Fh. The same family ops and number of channels also apply.
Use the Family17h Model 70h family_type and ops for Family 19h Models
20h-2Fh. Update the controller name to match the system.
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201009171803.3214354-1-Yazen.Ghannam@amd.com
- Assign a proper discard granularity rather than incorrectly set it to 0
-----BEGIN PGP SIGNATURE-----
iQJLBAABCgA1FiEEugLDXPmKSktSkQsV/iaEJXNYjCkFAl+ABO0XHHVsZi5oYW5z
c29uQGxpbmFyby5vcmcACgkQ/iaEJXNYjCkRwQ//cQ2cb3bb7ASbzKOCvm29Q3/c
u9ZfXH3Mg+GsP5htZOapO0PpHOMYohG8FpPe6NCAmVmdEGc6JhrjKX7xwGaoBOFX
SsUaRMO/5PjWJeCu6vzeBJCy2UJrDEYaBtQyL0U+/y84aNlmJ+74wACgG/dT6sgL
W/eejh5ynp/KMIkLQTZ3Ml1kNXJ77upDgN8npGCJXjG7PH9LsF5TwSrkV6PP96ML
4FoEDdM/QCRV7QloG+T1/yPDKExKiuQxLjsRqrdJIeoWb4otWLE1eTc5DveBMYwR
EZMbDTy4P+EBmhKB1BoM8PfDna/OxMnt4LAAYFKN5NzscI5YIb0my/smUtEINUKN
q/cFi+kMauHXMSchvTCGhmtXEXO/Gp0Eu6Eul3ouFKGlJLGw92J/P1nLoVRYeXf2
Z3gCdTMsLWQgIxY1dtZTJ0CCGaBVZUfUwFiRC0GfduWZsAa1ihn3IByaPcLNhgMY
vxSrjCFJPP+f13LG4hBwko+S+LWomY0+1U7sDmPBinh3EdVPM507yE9/nf1/U17Q
sTd6izhwm8WKIBW6S0m06LIMpt42ED0Za2m8fWnyBiUnSG4Xh+cH9fDF8TxzYP2F
Q/JZlC5nA0thdK3wlbgE2eMxC1xZdpPhyaOxU7kw0vct1IC01W7q+zViy2bTp3WI
jOP0LPH0uqk8mh/Rttk=
=S62I
-----END PGP SIGNATURE-----
Merge tag 'mmc-v5.9-rc4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fix from Ulf Hansson:
"Assign a proper discard granularity rather than incorrectly set it to
zero"
* tag 'mmc-v5.9-rc4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: core: don't set limits.discard_granularity as 0
amdgpu:
- Fix a crash on renoir if you override the IP discovery parameter
- Fix the build on ARC platforms
- Display fix for Sienna Cichlid
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJff+O4AAoJEAx081l5xIa+RTYQAIJ/AOXL1WgpUEx1z+gESGcg
Vdh4/itUp0NI4UTknqb6Kx0jQAkiFWDXSe44QOyZJv/aOpv5+SJCQhudtnVx+Kgi
jbhE7FKsdcxyIeKkvkK6uylzueLefqfwhrJhxCzlVwapDaR5DPjkppR2xbxVqDBu
Ve/OrlCPN6Myt/O1Z98AEiTl00dMC7OIJUFHatwmguFCHtxI9JPBGz/qvMCtzltm
HO9DoPyPFamJhEkAzkIru5Rwk6F9JB2A27FES9vP9l2ERY34yhjx3rLaYVjywdhu
K7xaVWPtm2jbTWqEF/GsmXf0WEqJWEakEDVGIRpyyhTnWC/vhlMjX3W3sZstR49u
h/qN6PA0GDoNoAsd6ldRo+Ey8DudZ/UDY49FXO86cIiT6IJFLWG01bm9fzDWOdQg
V/iqcU8jf3xC2Wsb2fUodbvMvvaoR1HeBjseYL5EWKvJpux905pgJS7IzepGvZct
67ObfhS+3bqW1hPU18OmZlth/mAZOw5FtYFforMsyAbNHAFKNQ65OjYk/jmpM2I3
P0m03/v1hTgneTIwa0HO9/XuWDERv7Ay/Z5niD8OwSRLUXDAEYrAGqgNosbYDu29
bX1BEhUQLclUcBCJbzSjwu7WlQzElGdNVU+AAbtlhr/HeLhxYEh9iZDAUUgxWsID
G2/kaJBywsmIrdVFU5uN
=EI05
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2020-10-09' of git://anongit.freedesktop.org/drm/drm
Pull amdgpu drm fixes from Dave Airlie:
"Fixes trickling in this week.
Alex had a final fix for the newest GPU they introduced in rc1, along
with one build regression and one crasher fix.
Cross my fingers that's it for 5.9:
- Fix a crash on renoir if you override the IP discovery parameter
- Fix the build on ARC platforms
- Display fix for Sienna Cichlid"
* tag 'drm-fixes-2020-10-09' of git://anongit.freedesktop.org/drm/drm:
drm/amd/display: Change ABM config init interface
drm/amdgpu/swsmu: fix ARC build errors
drm/amdgpu: fix NULL pointer dereference for Renoir
Amlogic SoC devices report the following errors frequently causing excessive
dmesg log spam and early log rotataion, although the errors appear to be
harmless as everything works fine:
[ 7.202702] panfrost ffe40000.gpu: error powering up gpu L2
[ 7.203760] panfrost ffe40000.gpu: error powering up gpu shader
ARM staff have advised increasing the timeout values to eliminate the errors
in most normal scenarios, and testing with several different G31/G52 devices
shows 20000 to be a reliable value.
Fixes: f3ba91228e ("drm/panfrost: Add initial panfrost driver")
Suggested-by: Steven Price <steven.price@arm.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201008141738.13560-1-christianshewitt@gmail.com
These have been required by the Debian policy for a while, even though
the tooling can detect and workaround their omission, but are a hard
requirement when using rootless builds.
[masahiro:
The following Debian policy is particularly important for rootless builds:
"Both binary-* targets should depend on the build target, or on the
appropriate build-arch or build-indep target, so that the package is
built if it has not been already."
]
Signed-off-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
sysfs-pci and sysfs-tagging were mis-filed: their locations within
Documentation/ implied that they were related to file systems. Actually,
each topic is about a very specific *use* of sysfs, and sysfs *happens*
to be a (virtual) filesystem, so this is not really the right place.
It's jarring to be reading about filesystems in general and then come
across these specific details about PCI, and tagging...and then back to
general filesystems again.
Move sysfs-pci to PCI, and move sysfs-tagging to networking. (Thanks to
Jonathan Corbet for coming up with the final locations.)
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Link: https://lore.kernel.org/r/20201009070128.118639-1-jhubbard@nvidia.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Even though there is not much happening for libata PATA drivers
I don't have time to look after them anymore.
Since Jens is maintaining the whole libata anyway just remove
"LIBATA PATA DRIVERS" entry.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
using packetdrill it's possible to observe the same MPTCP DSN being acked
by different subflows with DACK4 and DACK8. This is in contrast with what
specified in RFC8684 §3.3.2: if an MPTCP endpoint transmits a 64-bit wide
DSN, it MUST be acknowledged with a 64-bit wide DACK. Fix 'use_64bit_ack'
variable to make it a property of MPTCP sockets, not TCP subflows.
Fixes: a0c1d0eafd ("mptcp: Use 32-bit DATA_ACK when possible")
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The phy_reset_after_clk_enable() does a PHY reset, which means the PHY
loses its register settings. The fec_enet_mii_probe() starts the PHY
and does the necessary calls to configure the PHY via PHY framework,
and loads the correct register settings into the PHY. Therefore,
fec_enet_mii_probe() should be called only after the PHY has been
reset, not before as it is now.
Fixes: 1b0a83ac04 ("net: fec: add phy_reset_after_clk_enable() support")
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Richard Leitner <richard.leitner@skidata.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
kmalloc() of sufficiently big portion of memory is cache-aligned
in regular conditions. If some debugging options are used,
there is no reason qdisc structures would need 64-byte alignment
if most other kernel structures are not aligned.
This get rid of QDISC_ALIGN and QDISC_ALIGNTO.
Addition of privdata field will help implementing
the reverse of qdisc_priv() and documents where
the private data is.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Allen Pais <allen.lkml@gmail.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pull MD updates from Song:
"The main changes are:
- Bug fixes in bitmap code, from Zhao Heming.
- Fix a work queue check, from Guoqing Jiang.
- Fix raid5 oops with reshape, from Song Liu.
- Clean up unused code, from Jason Yan."
* 'md-next' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md:
md/raid5: fix oops during stripe resizing
md/bitmap: fix memory leak of temporary bitmap
md: fix the checking of wrong work queue
md/bitmap: md_bitmap_get_counter returns wrong blocks
md/bitmap: md_bitmap_read_sb uses wrong bitmap blocks
md/raid0: remove unused function is_io_in_chunk_boundary()
There are no bugs here that I've spotted, it's just easier to use the
normal API and there are no performance advantages to using the more
verbose advanced API.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The xas_store() wasn't paired with an xas_nomem() loop, so if it couldn't
allocate memory using GFP_NOWAIT, it would leak the reference to the file
descriptor. Also the node pointed to by the xas could be freed between
the call to xas_load() under the rcu_read_lock() and the acquisition of
the xa_lock.
It's easier to just use the normal xa_load/xa_store interface here.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
[axboe: fix missing assign after alloc, cur_uring -> tctx rename]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
This makes it possible to build the Debian packages without requiring
(pseudo-)root privileges, when the build drivers support this mode
of operation.
See-Also: /usr/share/doc/dpkg/rootless-builds.txt.gz
Signed-off-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
We should not be encoding the timestamp, otherwise we end up generating
unreproducible files that cascade into unreproducible packages.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Currently, the build log shows KSYM + object name.
Precisely speaking, kallsyms generates a .S file and then the compiler
compiles it into a .o file. Split the build log into two.
[Before]
GEN modules.builtin
LD .tmp_vmlinux.kallsyms1
KSYM .tmp_vmlinux.kallsyms1.o
LD .tmp_vmlinux.kallsyms2
KSYM .tmp_vmlinux.kallsyms2.o
LD vmlinux
[After]
GEN modules.builtin
LD .tmp_vmlinux.kallsyms1
KSYMS .tmp_vmlinux.kallsyms1.S
AS .tmp_vmlinux.kallsyms1.o
LD .tmp_vmlinux.kallsyms2
KSYMS .tmp_vmlinux.kallsyms2.S
AS .tmp_vmlinux.kallsyms2.o
LD vmlinux
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
ld's --build-id defaults to "sha1" style, while lld defaults to "fast".
The build IDs are very different between the two, which may confuse
programs that reference them.
Signed-off-by: Bill Wendling <morbo@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
We have to drop the lock during each iteration, so there's no advantage
to using the advanced API. Convert this to a standard xa_for_each() loop.
Reported-by: syzbot+27c12725d8ff0bfe1a13@syzkaller.appspotmail.com
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
