Fix the logic of the no-detached case for detach-on-destroy option - a
previous change made it so that even in the no-detached case, tmux would
always re-attach to a session, even if there weren't any detached ones.
From Martin Louazel in GitHub issue 4649.
drm/amd/display: Enable Dynamic DTBCLK Switch
From Fangzhi Zuo
a91c4c1efb9a2fd4aedcbb116f6dbd7fca024dee in linux-6.12.y/6.12.54
5949e7c4890c3cf65e783c83c355b95e21f10dba in mainline linux
drm/amd/display: Properly disable scaling on DCE6
From Timur Kristof
d74bcf4969856c1c914df5be899b96a23e2b17d7 in linux-6.12.y/6.12.54
a7dc87f3448bea5ebe054f14e861074b9c289c65 in mainline linux
drm/amd/display: Properly clear SCL_*_FILTER_CONTROL on DCE6
From Timur Kristof
00f1bd57068b2b76db1144f89a5aa1fa626f40e0 in linux-6.12.y/6.12.54
c0aa7cf49dd6cb302fe28e7183992b772cb7420c in mainline linux
drm/amd/display: Add missing DCE6 SCL_HORZ_FILTER_INIT* SRIs
From Timur Kristof
56251bdf36eee9b0abcd1e56655b1fd67bbf2e27 in linux-6.12.y/6.12.54
d60f9c45d1bff7e20ecd57492ef7a5e33c94a37c in mainline linux
drm/amdgpu: Add additional DCE6 SCL registers
From Alex Deucher
9626d3af3cd1fe79401ceb82039ed10450867a55 in linux-6.12.y/6.12.54
507296328b36ffd00ec1f4fde5b8acafb7222ec7 in mainline linux
The pmap_table array comes from Mach on luna88k and is used to specify what
memory areas should be mapped in the kernel.
In Mach, this table contained the main memory, which is why it had a
cacheability field. In BSD, main memory is handled separately, and the
pmap_table is only used to map the few hardware resources for which a driver
does not necessarily attaches - or which needs to be used by the kernel before
a driver gets a chance to attach.
Drop the cacheability field, since all entries will require cache inhibited
mappings.
Tested & ok aoyama@
Adjust 'vnode' structure in vnode(9) man page
The 'v_selectinfo' was replaced with 'v_klist' in the revision 1.169 of
sys/vnode.h, but I forgot to adjust man page.
ok miod claudio kettenis
Ensure that we specify the correct group when creating a HelloRetryRequest.
When processing the client supported groups and key shares extensions,
the group selection is currently based on client preference. However,
when building a HRR the preferred group is identified by calling
tls1_get_supported_group(). If SSL_OP_CIPHER_SERVER_PREFERENCE is enabled,
group selection will be based on server instead of client preference. This
in turn can result in the server sending a HRR for a group that the client
has already provided a key share for, violating the RFC.
Avoid this issue by storing the client preferred group when processing
the key share extension, then using this group when creating the HRR.
Thanks to dzwdz for identifying and reporting the issue.
ok beck@ tb@
Fix wording around CONFIGURE_STYLE autoconf/autoreconf, they are
normally alternatives to gnu (implying CONFIGURE_STYLE=gnu behaviour
as well), rather than modifiers to be added (like dest/old).
Pointed out by/ok tb@
Field name change: location -> locations
While at this point in time every RPKI object has only one
specific location (the 'Signed Object' acces description),
it is conceivable some form of multi-homing arises in
the future. Align names to help our future selves.
This is a cosmetic change, the field already was a sequence.
OK tb@
