Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let's fork linux to our individual repositories. #1038

Open
wants to merge 10,000 commits into
base: arm64-uaccess
Choose a base branch
from

Conversation

TYDQSoft
Copy link

Since Linus and Greg have been stripped all Russian contributors for politics reason,we reckon that linux is the proprietary possession of the America,Linux Foundation and their leaders,open source operating system is the surface,not the intrinsic quality.The Linux leaders brazenly violate the open source protocol and lead the politics element in open source project which is widely accepted that non-politicial campaign.
As a consequence,We should promote the division of Linux community due to the leaders' transgression behaviour.I am convinced of open-source community will naturally functioning without the Linux Foundation and Linux Leaders themselves.I have forked out according to my repository.

Kent Overstreet and others added 30 commits October 18, 2024 00:49
This helped with discovering some filesystem corruption fsck has having
trouble with: the str_hash type had gotten flipped on one snapshot's
version of an inode.

All versions of a given inode number have the same hash seed and hash
type, since lookups will be done with a single hash/seed and type and
see dirents/xattrs from multiple snapshots.

Signed-off-by: Kent Overstreet <[email protected]>
Different versions of the same inode (same inode number, different
snapshot ID) must have the same hash seed and type - lookups require
this, since they see keys from different snapshots simultaneously.

To repair we only need to make the inodes consistent, hash_check_key()
will do the rest.

Signed-off-by: Kent Overstreet <[email protected]>
Add a variant of bch2_hash_set_in_snapshot() that returns the existing
key on -EEXIST.

Signed-off-by: Kent Overstreet <[email protected]>
hash_check_key() checks and repairs the hash table btrees: dirents and
xattrs are open addressing hash tables.

We recently had a corruption reported where the hash type on an inode
somehow got flipped, which made the existing dirents invisible and
allowed new ones to be created with the same name.

Now, hash_check_key() can repair duplicates: it will delete one of them,
if it has an xattr or dangling dirent, but if it has two valid dirents
one of them gets renamed.

Signed-off-by: Kent Overstreet <[email protected]>
Commit 2fae6bb ("xen/privcmd: Add new syscall to get gsi from dev")
adds a weak reverse dependency to the config XEN_PRIVCMD definition, that
dependency causes xen-privcmd can't be loaded on domU, because dependent
xen-pciback isn't always be loaded successfully on domU.

To solve above problem, remove that dependency, and do not call
pcistub_get_gsi_from_sbdf() directly, instead add a hook in
drivers/xen/apci.c, xen-pciback register the real call function, then in
privcmd_ioctl_pcidev_get_gsi call that hook.

Fixes: 2fae6bb ("xen/privcmd: Add new syscall to get gsi from dev")
Reported-by: Marek Marczykowski-Górecki <[email protected]>
Signed-off-by: Jiqian Chen <[email protected]>
Reviewed-by: Juergen Gross <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Juergen Gross <[email protected]>
…linux/kernel/git/johan/usb-serial into usb-linus

Johan writes:

USB-serial device ids for 6.12-rc4

Here are some new modem device ids.

Everything has been in linux-next over night with no reported issues.

* tag 'usb-serial-6.12-rc4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
  USB: serial: option: add Telit FN920C04 MBIM compositions
  USB: serial: option: add support for Quectel EG916Q-GL
Patch for Goodix 27c6:0d42 touchpads found in Inspiron 5515 laptops.

After resume from suspend, one can communicate with this device just fine.
We can read data from it or request a reset,
but for some reason the interrupt line will not go up
when new events are available.
(it can correctly respond to a reset with an interrupt tho)

The only way I found to wake this device up
is to send anything to it after ~1.5s mark,
for example a simple read request, or power mode change.

In this patch, I simply delay the resume steps with msleep,
this will cause the set_power request to happen after
the ~1.5s barrier causing the device to resume its event interrupts.

Sleep was used rather than delayed_work
to make this workaround as non-invasive as possible.

[[email protected]: shortlog update]
Signed-off-by: Bartłomiej Maryńczak <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
The Logitech Casa Touchpad does not reliably send touch release signals
when communicating through the Logitech Bolt wireless-to-USB receiver.

Adjusting the device class to add MT_QUIRK_NOT_SEEN_MEANS_UP to make
sure that no touches become stuck, MT_QUIRK_FORCE_MULTI_INPUT is not
needed, but harmless.

Linux does not have information on which devices are connected to the
Bolt receiver, so we have to enable this for the entire device.

Signed-off-by: Kenneth Albanowski <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
The Thinkpad X1 Tablet Gen 3 keyboard has the same Lenovo specific quirks
as the original  Thinkpad X1 Tablet keyboard.

Add the PID for the "Thinkpad X1 Tablet Gen 3 keyboard" to the hid-lenovo
driver to fix the FnLock, Mute and media buttons not working.

Suggested-by: Izhar Firdaus <[email protected]>
Closes https://bugzilla.redhat.com/show_bug.cgi?id=2315395
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Building the kernel with W=1 generates the following warning:

  fs/proc/fd.c:81: warning: This comment starts with '/**',
                   but isn't a kernel-doc comment.

Use a normal comment for the helper function proc_fdinfo_permission().

Signed-off-by: Thorsten Blum <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Christian Brauner <[email protected]>
Remove some entries due to various compliance requirements. They can come
back in the future if sufficient documentation is provided.

Link: https://lore.kernel.org/r/2024101835-tiptop-blip-09ed@gregkh
Signed-off-by: Greg Kroah-Hartman <[email protected]>
rts5228, rts5261, rts5264 are supported by the rtsx_pci driver, but
they are not mentioned in the Kconfig help when the code was added.
List those models in the Kconfig help accordingly.

Signed-off-by: Yo-Jung Lin (Leo) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
…git/s390/linux

Pull s390 fixes from Heiko Carstens:

 - Fix PCI error recovery by handling error events correctly

 - Fix CCA crypto card behavior within protected execution environment

 - Two KVM commits which fix virtual vs physical address handling bugs
   in KVM pfault handling

 - Fix return code handling in pckmo_key2protkey()

 - Deactivate sclp console as late as possible so that outstanding
   messages appear on the console instead of being dropped on reboot

 - Convert newlines to CRLF instead of LFCR for the sclp vt220 driver,
   as required by the vt220 specification

 - Initialize also psw mask in perf_arch_fetch_caller_regs() to make
   sure that user_mode(regs) will return false

 - Update defconfigs

* tag 's390-6.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390: Update defconfigs
  s390: Initialize psw mask in perf_arch_fetch_caller_regs()
  s390/sclp_vt220: Convert newlines to CRLF instead of LFCR
  s390/sclp: Deactivate sclp after all its users
  s390/pkey_pckmo: Return with success for valid protected key types
  KVM: s390: Change virtual to physical address access in diag 0x258 handler
  KVM: s390: gaccess: Check if guest address is in memslot
  s390/ap: Fix CCA crypto card behavior within protected execution environment
  s390/pci: Handle PCI error codes other than 0x3a
…el/git/powerpc/linux

Pull powerpc fix from Madhavan Srinivasan:

 - To prevent possible memory leak, free "name" on error in
   opal_event_init()

Thanks to Michael Ellerman and 2639161967.

* tag 'powerpc-6.12-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/powernv: Free name on error in opal_event_init()
…ux/kernel/git/iommu/linux

Pull iommu fixes from Joerg Roedel:
 "ARM-SMMU fixes from Will Deacon:

   - Clarify warning message when failing to disable the MMU-500
     prefetcher

   - Fix undefined behaviour in calculation of L1 stream-table index
     when 32-bit StreamIDs are implemented

   - Replace a rogue comma with a semicolon

  Intel VT-d fix from Lu Baolu:

   - Fix incorrect pci_for_each_dma_alias() for non-PCI devices"

* tag 'iommu-fixes-v6.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux:
  iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices
  iommu/arm-smmu-v3: Convert comma to semicolon
  iommu/arm-smmu-v3: Fix last_sid_idx calculation for sid_bits==32
  iommu/arm-smmu: Clarify MMU-500 CPRE workaround
Merge amd-pstate driver fixes for 6.12-rc4:

 - Enable ACPI CPPC in amd_pstate_register_driver() after disabling
   it in amd_pstate_unregister_driver() during driver operation mode
   switch (Dhananjay Ugwekar).

 - Make amd-pstate use nominal performance as the maximum performance
   level when boost is disabled (Mario Limonciello).

* pm-cpufreq:
  cpufreq/amd-pstate: Use nominal perf for limits when boost is disabled
  cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems
The lockdep asserts for the new follow_pfnmap() API "knows" that a
pfnmap always has a vma->vm_file, since that's the only way to create
such a mapping.

And that's actually true for all the normal cases.  But not for the mmap
failure case, where the incomplete mapping is torn down and we have
cleared vma->vm_file because the failure occured before the file was
linked to the vma.

So this codepath does actually need to check for vm_file being NULL.

Reported-by: Jann Horn <[email protected]>
Fixes: 6da8e96 ("mm: new follow_pfnmap API")
Cc: Peter Xu <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
…kernel/git/song/md into block-6.12

Pull MD fixes from Song.

* tag 'md-6.12-20241018' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md:
  md/raid10: fix null ptr dereference in raid10_size()
  md: ensure child flush IO does not affect origin bio->bi_status
…7 regs

Turns out some registers of pre-2.5 version of rxmacro codecs are not
located at the expected offsets but 0xc further away in memory. So far
the detected registers are CDC_RX_RX2_RX_PATH_SEC7 and
CDC_RX_RX2_RX_PATH_DSM_CTL.

CDC_RX_RXn_RX_PATH_DSM_CTL(rx, n) macro incorrectly generates the address
0x540 for RX2 but it should be 0x54C and it also overwrites
CDC_RX_RX2_RX_PATH_SEC7 which is located at 0x540.
The same goes for CDC_RX_RXn_RX_PATH_SEC7(rx, n).

Fix this by introducing additional rxn_reg_stride2 offset. For 2.5 version
and above this offset will be equal to 0.
With such change the corresponding RXn() macros will generate the same
values for 2.5 codec version for all RX paths and the same old values
for pre-2.5 version for RX0 and RX1. However for the latter case with
RX2 path it will also add rxn_reg_stride2 on top.

While at this, also remove specific if-check for INTERP_AUX from
rx_macro_digital_mute() and rx_macro_enable_interp_clk(). These if-check
was used to handle such special offset for AUX interpolator but since
CDC_RX_RXn_RX_PATH_SEC7(rx, n) and CDC_RX_RXn_RX_PATH_DSM_CTL(rx, n)
macros will generate the correst addresses of dsm register, they are no
longer needed.

Cc: Srinivas Kandagatla <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Alexey Klimov <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
…trol types

On i.MX8MM the register of volume control has positive and negative
values. It is different from other platforms like i.MX8MP and i.MX93
which only have positive values. Add a volume_sx flag to use SX_TLV
volume control for this kind of platform. Use common TLV volume control
for other platforms.

Fixes: cdfa92e ("ASoC: fsl_micfil: Correct the number of steps on SX controls")
Signed-off-by: Chancel Liu <[email protected]>
Reviewed-by: Daniel Baluta <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Mark Brown <[email protected]>
…m/kernel

Pull drm fixes from Dave Airlie:
 "Weekly fixes, msm and xe are the two main ones, with a bunch of
  scattered fixes including a largish revert in mgag200, then amdgpu,
  vmwgfx and scattering of other minor ones.

  All seems pretty regular.

  msm:
   - Display:
      - move CRTC resource assignment to atomic_check otherwise to make
        consecutive calls to atomic_check() consistent
      - fix rounding / sign-extension issues with pclk calculation in
        case of DSC
      - cleanups to drop incorrect null checks in dpu snapshots
      - fix to use kvzalloc in dpu snapshot to avoid allocation issues
        in heavily loaded system cases
      - Fix to not program merge_3d block if dual LM is not being used
      - Fix to not flush merge_3d block if its not enabled otherwise
        this leads to false timeouts
   - GPU:
      - a7xx: add a fence wait before SMMU table update

  xe:
   - New workaround to Xe2 (Aradhya)
   - Fix unbalanced rpm put (Matthew Auld)
   - Remove fragile lock optimization (Matthew Brost)
   - Fix job release, delegating it to the drm scheduler (Matthew Brost)
   - Fix timestamp bit width for Xe2 (Lucas)
   - Fix external BO's dma-resv usag (Matthew Brost)
   - Fix returning success for timeout in wait_token (Nirmoy)
   - Initialize fence to avoid it being detected as signaled (Matthew
     Auld)
   - Improve cache flush for BMG (Matthew Auld)
   - Don't allow hflip for tile4 framebuffer on Xe2 (Juha-Pekka)

  amdgpu:
   - SR-IOV fix
   - CS chunk handling fix
   - MES fixes
   - SMU13 fixes

  amdkfd:
   - VRAM usage reporting fix

  radeon:
   - Fix possible_clones handling

  i915:
   - Two DP bandwidth related MST fixes

  ast:
   - Clear EDID on unplugged connectors

  host1x:
   - Fix boot on Tegra186
   - Set DMA parameters

  mgag200:
   - Revert VBLANK support

  panel:
   - himax-hx83192: Adjust power and gamma

  qaic:
   - Sgtable loop fixes

  vmwgfx:
   - Limit display layout allocatino size
   - Handle allocation errors in connector checks
   - Clean up KMS code for 2d-only setup
   - Report surface-check errors correctly
   - Remove NULL test around kvfree()"

* tag 'drm-fixes-2024-10-18' of https://gitlab.freedesktop.org/drm/kernel: (45 commits)
  drm/ast: vga: Clear EDID if no display is connected
  drm/ast: sil164: Clear EDID if no display is connected
  Revert "drm/mgag200: Add vblank support"
  drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs
  drm/i915/display: Don't allow tile4 framebuffer to do hflip on display20 or greater
  drm/xe/bmg: improve cache flushing behaviour
  drm/xe/xe_sync: initialise ufence.signalled
  drm/xe/ufence: ufence can be signaled right after wait_woken
  drm/xe: Use bookkeep slots for external BO's in exec IOCTL
  drm/xe/query: Increase timestamp width
  drm/xe: Don't free job in TDR
  drm/xe: Take job list lock in xe_sched_add_pending_job
  drm/xe: fix unbalanced rpm put() with declare_wedged()
  drm/xe: fix unbalanced rpm put() with fence_fini()
  drm/xe/xe2lpg: Extend Wa_15016589081 for xe2lpg
  drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible mode
  drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation
  drm/msm/a6xx+: Insert a fence wait before SMMU table update
  drm/msm/dpu: don't always program merge_3d block
  drm/msm/dpu: Don't always set merge_3d pending flush
  ...
…/kernel/git/groeck/linux-staging

Pull hwmon fix from Guenter Roeck:
 "Fix auto-detect regression in jc42 driver"

* tag 'hwmon-for-v6.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again
…git/rafael/linux-pm

Pull power management fixes from Rafael Wysocki:
 "These fix two issues in the amd-pstate cpufreq driver and update the
  intel_rapl power capping driver with a new processor ID.

  Specifics:

   - Enable ACPI CPPC in amd_pstate_register_driver() after disabling it
     in amd_pstate_unregister_driver() when switching driver operation
     modes (Dhananjay Ugwekar)

   - Make amd-pstate use nominal performance as the maximum performance
     level when boost is disabled (Mario Limonciello)

   - Add ArrowLake-H to the list of processors where PL4 is supported in
     the MSR part of the intel_rapl power capping driver (Srinivas
     Pandruvada)"

* tag 'pm-6.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  powercap: intel_rapl_msr: Add PL4 support for ArrowLake-H
  cpufreq/amd-pstate: Use nominal perf for limits when boost is disabled
  cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems
…fs-linux

Pull xfs fixes from Carlos Maiolino:

 - Fix integer overflow in xrep_bmap

 - Fix stale dealloc punching for COW IO

* tag 'xfs-6.12-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
  xfs: punch delalloc extents from the COW fork for COW writes
  xfs: set IOMAP_F_SHARED for all COW fork allocations
  xfs: share more code in xfs_buffered_write_iomap_begin
  xfs: support the COW fork in xfs_bmap_punch_delalloc_range
  xfs: IOMAP_ZERO and IOMAP_UNSHARE already hold invalidate_lock
  xfs: take XFS_MMAPLOCK_EXCL xfs_file_write_zero_eof
  xfs: factor out a xfs_file_write_zero_eof helper
  iomap: move locking out of iomap_write_delalloc_release
  iomap: remove iomap_file_buffered_write_punch_delalloc
  iomap: factor out a iomap_last_written_block helper
  xfs: fix integer overflow in xrep_bmap
…h/cifs-2.6

Pull smb client fixes from Steve French:

 - Fix possible double free setting xattrs

 - Fix slab out of bounds with large ioctl payload

 - Remove three unused functions, and an unused variable that could be
   confusing

* tag 'v6.12-rc3-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: Remove unused functions
  smb/client: Fix logically dead code
  smb: client: fix OOBs when building SMB2_IOCTL request
  smb: client: fix possible double free in smb2_set_ea()
…ejected

If enabled, we fallback to the platform keyring if the trusted keyring
doesn't have the key used to sign the ipe policy. But if pkcs7_verify()
rejects the key for other reasons, such as usage restrictions, we do not
fallback. Do so, following the same change in dm-verity.

Signed-off-by: Luca Boccassi <[email protected]>
Suggested-by: Serge Hallyn <[email protected]>
[FW: fixed some line length issues and a typo in the commit message]
Signed-off-by: Fan Wu <[email protected]>
Update Integrity Policy Enforcement (IPE) LSM tree url and
maintainer's email to the newly issued kernel.org tree/email.

Signed-off-by: Fan Wu <[email protected]>
There is a race between laundromat handling of revoked delegations
and a client sending free_stateid operation. Laundromat thread
finds that delegation has expired and needs to be revoked so it
marks the delegation stid revoked and it puts it on a reaper list
but then it unlock the state lock and the actual delegation revocation
happens without the lock. Once the stid is marked revoked a racing
free_stateid processing thread does the following (1) it calls
list_del_init() which removes it from the reaper list and (2) frees
the delegation stid structure. The laundromat thread ends up not
calling the revoke_delegation() function for this particular delegation
but that means it will no release the lock lease that exists on
the file.

Now, a new open for this file comes in and ends up finding that
lease list isn't empty and calls nfsd_breaker_owns_lease() which ends
up trying to derefence a freed delegation stateid. Leading to the
followint use-after-free KASAN warning:

kernel: ==================================================================
kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205
kernel:
kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ torvalds#9
kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024
kernel: Call trace:
kernel: dump_backtrace+0x98/0x120
kernel: show_stack+0x1c/0x30
kernel: dump_stack_lvl+0x80/0xe8
kernel: print_address_description.constprop.0+0x84/0x390
kernel: print_report+0xa4/0x268
kernel: kasan_report+0xb4/0xf8
kernel: __asan_report_load8_noabort+0x1c/0x28
kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]
kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]
kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]
kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]
kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]
kernel: nfsd4_open+0xa08/0xe80 [nfsd]
kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]
kernel: nfsd_dispatch+0x22c/0x718 [nfsd]
kernel: svc_process_common+0x8e8/0x1960 [sunrpc]
kernel: svc_process+0x3d4/0x7e0 [sunrpc]
kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]
kernel: svc_recv+0x2cc/0x6a8 [sunrpc]
kernel: nfsd+0x270/0x400 [nfsd]
kernel: kthread+0x288/0x310
kernel: ret_from_fork+0x10/0x20

This patch proposes a fixed that's based on adding 2 new additional
stid's sc_status values that help coordinate between the laundromat
and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).

First to make sure, that once the stid is marked revoked, it is not
removed by the nfsd4_free_stateid(), the laundromat take a reference
on the stateid. Then, coordinating whether the stid has been put
on the cl_revoked list or we are processing FREE_STATEID and need to
make sure to remove it from the list, each check that state and act
accordingly. If laundromat has added to the cl_revoke list before
the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove
it from the list. If nfsd4_free_stateid() finds that operations arrived
before laundromat has placed it on cl_revoke list, it marks the state
freed and then laundromat will no longer add it to the list.

Also, for nfsd4_delegreturn() when looking for the specified stid,
we need to access stid that are marked removed or freeable, it means
the laundromat has started processing it but hasn't finished and this
delegreturn needs to return nfserr_deleg_revoked and not
nfserr_bad_stateid. The latter will not trigger a FREE_STATEID and the
lack of it will leave this stid on the cl_revoked list indefinitely.

Fixes: 2d4a532 ("nfsd: ensure that clp->cl_revoked list is protected by clp->cl_lock")
CC: [email protected]
Signed-off-by: Olga Kornievskaia <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
Merge series from Bard Liao <[email protected]>:

Clean up the link DMA for playback during stop for IPC4 is required to
reset the DMA read/write pointers when the stream is prepared and
restarted after a call to snd_pcm_drain()/snd_pcm_drop().

The change is mainly on ASoC. We may go via ASoC tree with Vinod's
Acked-by tag

Ranjani Sridharan (4):
  ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs
  ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's
  soundwire: intel_ace2x: Send PDI stream number during prepare
  ASoC: SOF: Intel: hda: Always clean up link DMA during stop

 drivers/soundwire/intel_ace2x.c   | 19 +++++-----------
 sound/soc/sof/intel/hda-dai-ops.c | 23 +++++++++----------
 sound/soc/sof/intel/hda-dai.c     | 37 +++++++++++++++++++++++++++----
 sound/soc/sof/ipc4-topology.c     | 15 +++++++++++--
 4 files changed, 62 insertions(+), 32 deletions(-)

--
2.43.0
Add MSI Claw A1M controller to xpad_device match table when in xinput mode.
Add MSI VID as XPAD_XBOX360_VENDOR.

Signed-off-by: John Edwards <[email protected]>
Reviewed-by: Derek J. Clark <[email protected]>
Reviewed-by: Christopher Snowhill <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: [email protected]
Signed-off-by: Dmitry Torokhov <[email protected]>
@xuangeyouneihan
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

@CodeMasterYi
Copy link

LGTM

LGTM = Linus, Go to 'M*'(some word starting with 'M')
Is it?

@SALTWOOD
Copy link

LGTM

LGTM = Linus, Go to 'M*'(some word starting with 'M') Is it?

true dude

@peerless2012
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

@xuangeyouneihan
Copy link

xuangeyouneihan commented Oct 29, 2024

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer has requested and received approval for anonymous access. We need a platform with less limitations, rather than more limitations.

@peerless2012
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer applied for anonymous access. We need a platform with less limitations, rather than more limitations.

At least, it will not delete you because of your country, which is so simple but so difficult for GitHub.

@TYDQSoft
Copy link
Author

LGTM

LGTM = Linus, Go to 'M*'(some word starting with 'M') Is it?

Can I comprehend it as fuck Linus and Greg(Due to TM means fuck in Chinese)?

@TYDQSoft
Copy link
Author

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer applied for anonymous access. We need a platform with less limitations, rather than more limitations.

Despite many weaknesses comparing gitee with github,it is a only way that China only have gitee,I have not explode any other git website better than gitee if I neglect github.

@bocchi810
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer applied for anonymous access. We need a platform with less limitations, rather than more limitations.

This "repos need to be examined and verified before going public" provision is got cancelled , so you can create repo on gitee freely

@Faris90
Copy link

Faris90 commented Oct 29, 2024

I know it’s so stupid

@Faris90
Copy link

Faris90 commented Oct 29, 2024

@torvalds politics have no place in Linux

@bocchi810
Copy link

bocchi810 commented Oct 30, 2024

Despite many weaknesses comparing gitee with github,it is a only way that China only have gitee,I have not explode any other git website better than gitee if I neglect github.

I see the Gitee seem have 500MB limit per repo , i try to mirror linux offical repo , and it tell me "repo pull failed"
I have a idea: --depth=30

@zxrcs
Copy link

zxrcs commented Oct 30, 2024

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer applied for anonymous access. We need a platform with less limitations, rather than more limitations.

Despite many weaknesses comparing gitee with github,it is a only way that China only have gitee,I have not explode any other git website better than gitee if I neglect github.

You can use Gitea to set up a Git server to host your repository.

@EnderLight3336
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer has requested and received approval for anonymous access. We need a platform with less limitations, rather than more limitations.

you can try to contact to them, I believe them will welcome such a big project and its contributors :)
If you cannot, I can help you, I'm Chinese

@EnderLight3336
Copy link

Or you can try to build a git server online, for example spigotmc has its own git repo and website, although I dont know how they deploy it

@xuangeyouneihan
Copy link

xuangeyouneihan commented Oct 30, 2024

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer has requested and received approval for anonymous access. We need a platform with less limitations, rather than more limitations.

you can try to contact to them, I believe them will welcome such a big project and its contributors :) If you cannot, I can help you, I'm Chinese

我也是中国人,但我只是一个比较关注IT的吃瓜群众,感觉实在干不了啥,我联系了他们也不一定会听,不好意思。要不大佬你试试?

English translation: I'm also Chinese, but I'm just an outsider who happens to be more interested in IT, so I don't think they'll consider my proposal (migrating Linux fork to Gitee). Maybe you can give a try?


我发现我似乎理解错了你说这话的意思,你似乎是对这个PR的发起者说的,那你就不应该回我,应该直接@他,这种情况咱试着撮合一下或许还是可以的

English translation: Well, I think I misunderstood what you said. You seems to be addressing the author of this PR. Then you should not reply to me, but @ him instead. In this case maybe we can play our parts

@Elvisass
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

No, Gitee, please dont. Aside from access restrictions, China has strict censorship on any public information, and on Gitee, it reaches ridiculous levels.

A classic joke: JAVA -> J**A
It will directly overwrite your text.

@peerless2012
Copy link

Move to gitee is just a joke, are you serious? LOF

@AkemiKami201
Copy link

well, Linux is proprietary possession of the America. This is a joke....
LGTM

@bocchi810
Copy link

Or you can try to build a git server online, for example spigotmc has its own git repo and website, although I dont know how they deploy it

So where can we host the git server, China mainland?USA?Hong Kong?Germany?UK?Singapore?

@SakuraRK
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

No, Gitee, please dont. Aside from access restrictions, China has strict censorship on any public information, and on Gitee, it reaches ridiculous levels.

A classic joke: JAVA -> J**A It will directly overwrite your text.

I believe you're just being paranoid about this.
In the developer community in mainland China, most of this text censorship is only for some political content. And to make sure that the code is not corrupted, there are real people who do a second manual review after the machine review.
The biggest problem at the moment is that these platforms are not directly controlled by the Chinese government, but rather by a coalition of large corporate interests that ...... resembles a Wall Street near-monopoly (e.g. Huawei, who in fact the Chinese developer community doesn't like either. Even though most of them grumble about some of the Internet censorship mechanisms). The classic example is Huawei and a joint venture with the Chinese development community's infamous name call CSDN's gitcode, which has at least 5 stars of project repositories for its massive unauthorized pulling of all sorts of github stuff (including projects like notepad++, which is anathema to the Chinese community). And later only in the front-end detected access to some of the famous projects (such as notepad + + +) and pop-up a fake 404 window.
But in any case, I'm still in favor of branching existing code that “hasn't” been modified by the linux development team to other code hosting services. Maybe we mainland Chinese developers (or computer enthusiasts) and you guys can work together to think of a better way to deal with this?
This is not just a problem for you, it's a problem for almost all Internet communities, but it manifests itself in different ways in different regions, and I have to say that the behavior of the Linux team, when analyzed, is not any different from the damage done to IT professionals in these other regions.
*The above was translated using DeepL. Just because I can't read such a long English content at once . *
(There should be have some ASCII Sadly Faces)

@CuriousCodingCanadian
Copy link

CuriousCodingCanadian commented Nov 1, 2024

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer applied for anonymous access. We need a platform with less limitations, rather than more limitations.

Despite many weaknesses comparing gitee with github,it is a only way that China only have gitee,I have not explode any other git website better than gitee if I neglect github.

You can use Gitea to set up a Git server to host your repository.

Gitea has done things like merging pull requests into the paid version, and as such Forgejo is a better alternative, especially for this purpose.

@peerless2012
Copy link

If you just want to save this repo and sync it, gitee and gitcode already do this, they sync this project everyday.

Tips, these repo just sync this repo as a mirror, not support to issue or pull request,

@TYDQSoft
Copy link
Author

TYDQSoft commented Nov 2, 2024

If you just want to save this repo and sync it, gitee and gitcode already do this, they sync this project everyday.

Tips, these repo just sync this repo as a mirror, not support to issue or pull request,

However,linux repository in gitcode and gitee are too old to chase after the newest linux kernel version.We should update the linux kernel repository in China to newest linux kernel version by ourselves.

@petricavalry
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

But Gitee seems to have too much limits, for examples, repos need to be examined and verified before going public, and users need to sign in to access public repos unless the repo's maintainer has requested and received approval for anonymous access. We need a platform with less limitations, rather than more limitations.

Try sourcehut.

@stevepaesani
Copy link

Good idea.
But not on github or any other US server.

@stevepaesani
Copy link

And drop the .com, .net,.org and any tld run by a US company. They (the US) shuts down domains of US managed tlds. They did it to Alwaght.com making up some story (lie) like the Americans always do.

@stevepaesani
Copy link

More developers will work on a kernel not run by the US than one run by them and Torvalds.
Less toxic environment and better chance at compensation directly from users (novel idea) and not US corporations.
Of course there are other kernels also and with more favorable licenses than the gpl.

@stevepaesani
Copy link

Well, I think it is not safe to fork this repo to a new repo on GitHub. Instead we should fork it to a platform not controlled by the USA.

Gitee from china seems match your opinion. Because china is against USA currently now, and will not listen USA voices.

No, Gitee, please dont. Aside from access restrictions, China has strict censorship on any public information, and on Gitee, it reaches ridiculous levels.

A classic joke: JAVA -> J**A It will directly overwrite your text.

China?
Try the USA .
Any talk about the truth of Jews/Israel's invasions and genocides, the 2014coup in Ukraine heck even the USA's own history is censored. In fact the very lands the USA is on is stolen.
"China" he says.
lol

@MEMZJJY418
Copy link

好吧,我认为将此存储库分叉到 GitHub 上的新存储库并不安全。相反,我们应该将其分叉到不受美国控制的平台。

来自中国的Gitee似乎符合你的意见。因为中国现在正在反对美国,不会听美国的声音。

但Gitee似乎有太多的限制,例如s,回购协议在上市前需要经过审查和验证,并且用户需要登录才能访问公共存储库,除非存储库的维护者已请求并获得匿名访问的批准。我们需要一个限制更少的平台,而不是更多的限制。

尝试一下sourcehut

I support your opinion.
We Chinese people need to use VPN software to access Github.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment