-
Notifications
You must be signed in to change notification settings - Fork 58.5k
Stmmac sun8i wip next 20170216 #392
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
Stmmac sun8i wip next 20170216 #392
Conversation
* pci/host-exynos: PCI: exynos: Refactor to make it easier to support other SoCs PCI: exynos: Remove duplicated code PCI: exynos: Use the bitops BIT() macro to build bitmasks PCI: exynos: Remove unnecessary local variables PCI: exynos: Replace the *_blk/*_phy/*_elb accessors PCI: exynos: Rename all pointer names from "exynos_pcie" to "ep"
* pci/host-hisi: PCI: generic: Call pci_fixup_irqs() only on ARM PCI: Disable MSI for HiSilicon Hip06/Hip07 Root Ports PCI: hisi: Rename config space accessors to remove "acpi" PCI: hisi: Add DT almost-ECAM support for Hip06/Hip07 host controllers PCI: hisi: Use of_device_get_match_data() to simplify probe
* pci/host-hv: PCI: hv: Fix wslot_to_devfn() to fix warnings on device removal
The buffered write failure handling code in xfs_file_iomap_end_delalloc() has a couple minor problems. First, if written == 0, start_fsb is not rounded down and it fails to kill off a delalloc block if the start offset is block unaligned. This results in a lingering delalloc block and broken delalloc block accounting detected at unmount time. Fix this by rounding down start_fsb in the unlikely event that written == 0. Second, it is possible for a failed overwrite of a delalloc extent to leave dirty pagecache around over a hole in the file. This is because is possible to hit ->iomap_end() on write failure before the iomap code has attempted to allocate pagecache, and thus has no need to clean it up. If the targeted delalloc extent was successfully written by a previous write, however, then it does still have dirty pages when ->iomap_end() punches out the underlying blocks. This ultimately results in writeback over a hole. To fix this problem, unconditionally punch out the pagecache from XFS before the associated delalloc range. Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
A debug mode write failure mechanism was introduced to XFS in commit 801cc4e ("xfs: debug mode forced buffered write failure") to facilitate targeted testing of delalloc indirect reservation management from userspace. This code was subsequently rendered ineffective by the move to iomap based buffered writes in commit 68a9f5e ("xfs: implement iomap based buffered write path"). This likely went unnoticed because the associated userspace code had not made it into xfstests. Resurrect this mechanism to facilitate effective indlen reservation testing from xfstests. The move to iomap based buffered writes relocated the hook this mechanism needs to return write failure from XFS to generic code. The failure trigger must remain in XFS. Given that limitation, convert this from a write failure mechanism to one that simply drops writes without returning failure to userspace. Rename all "fail_writes" references to "drop_writes" to illustrate the point. This is more hacky than preferred, but still triggers the XFS error handling behavior required to drive the indlen tests. This is only available in DEBUG mode and for testing purposes only. Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
When a delalloc extent is created, it can be merged with pre-existing, contiguous, delalloc extents. When this occurs, xfs_bmap_add_extent_hole_delay() merges the extents along with the associated indirect block reservations. The expectation here is that the combined worst case indlen reservation is always less than or equal to the indlen reservation for the individual extents. This is not always the case, however, as existing extents can less than the expected indlen reservation if the extent was previously split due to a hole punch. If a new extent merges with such an extent, the total indlen requirement may be larger than the sum of the indlen reservations held by both extents. xfs_bmap_add_extent_hole_delay() assumes that the worst case indlen reservation is always available and assigns it to the merged extent without consideration for the indlen held by the pre-existing extent. As a result, the subsequent xfs_mod_fdblocks() call can attempt an unintentional allocation rather than a free (indicated by an ASSERT() failure). Further, if the allocation happens to fail in this context, the failure goes unhandled and creates a filesystem wide block accounting inconsistency. Fix xfs_bmap_add_extent_hole_delay() to function as designed. Cap the indlen reservation assigned to the merged extent to the sum of the indlen reservations held by each of the individual extents. Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Certain workoads that punch holes into speculative preallocation can cause delalloc indirect reservation splits when the delalloc extent is split in two. If further splits occur, an already short-handed extent can be split into two in a manner that leaves zero indirect blocks for one of the two new extents. This occurs because the shortage is large enough that the xfs_bmap_split_indlen() algorithm completely drains the requested indlen of one of the extents before it honors the existing reservation. This ultimately results in a warning from xfs_bmap_del_extent(). This has been observed during file copies of large, sparse files using 'cp --sparse=always.' To avoid this problem, update xfs_bmap_split_indlen() to explicitly apply the reservation shortage fairly between both extents. This smooths out the overall indlen shortage and defers the situation where we end up with a delalloc extent with zero indlen reservation to extreme circumstances. Reported-by: Patrick Dung <mpatdung@gmail.com> Signed-off-by: Brian Foster <bfoster@redhat.com> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Fix an uninitialize variable. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
The length is now passed by reference, so the assertion has to be updated to match the other changes, as pointed out by this W=1 warning: fs/xfs/xfs_extent_busy.c: In function 'xfs_extent_busy_trim': fs/xfs/xfs_extent_busy.c:356:13: error: ordered comparison of pointer with integer zero [-Werror=extra] Fixes: ebf5587 ("xfs: improve handling of busy extents in the low-level allocator") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Replace all occurrences of sprintf with scnprintf in coresight driver for consistency. scnprintf is also a safer alternative to sprintf. Signed-off-by: Olav Haugan <ohaugan@codeaurora.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
cntr_val_show function does not print the intended information. It is only printing the latest counter value. Fix this. Signed-off-by: Olav Haugan <ohaugan@codeaurora.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
md still need bio clone(not the fast version) for behind write, and it is more efficient to use bio_clone_bioset_partial(). The idea is simple and just copy the bvecs range specified from parameters. Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jens Axboe <axboe@fb.com> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Shaohua Li <shli@fb.com>
The current behaviour is to fall back to allocate bio from 'fs_bio_set', that isn't a correct way because it might cause deadlock. So this patch simply return failure if mddev->bio_set can't be created. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Shaohua Li <shli@fb.com>
Write behind need to replace pages in bio's bvecs, and we have to clone a fresh bio with new bvec table, so use the introduced bio_clone_bioset_partial() for it. For other bio_clone_mddev() cases, we will use fast clone since they don't need to touch bvec table. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Shaohua Li <shli@fb.com>
mddev is never NULL and neither is ->bio_set, so remove the check. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Shaohua Li <shli@fb.com>
Firstly bio_clone_mddev() is used in raid normal I/O and isn't in resync I/O path. Secondly all the direct access to bvec table in raid happens on resync I/O except for write behind of raid1, in which we still use bio_clone() for allocating new bvec table. So this patch replaces bio_clone() with bio_clone_fast() in bio_clone_mddev(). Also kill bio_clone_mddev() and call bio_clone_fast() directly, as suggested by Christoph Hellwig. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: Shaohua Li <shli@fb.com>
Like for Sunrise Point, the total stream number of Lewisburg's input and output stream exceeds 15 (GCAP is 0x9701), which will cause some streams do not work because of the overflow on SDxCTL.STRM field if using the legacy stream tag allocation method. Fixes: 5cf92c8 ("ALSA: hda - Add Intel Lewisburg device IDs Audio") Signed-off-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
It seems that newer Intel chipsets have more than 15 I/O streams (total). This patch forces the separate stream tags, when this hardware is detected to avoid SDxCTL.STRM field overflow and an unexpected behaviour. Signed-off-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* v4.10/fixes: ARM64: dts: meson-gx: Add firmware reserved memory zones ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
On a large SMP system with many CPUs, the global pool_lock may become a performance bottleneck as all the CPUs that need to allocate or free debug objects have to take the lock. That can sometimes cause soft lockups like: NMI watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [rcuos/1:21] ... RIP: 0010:[<ffffffff817c216b>] [<ffffffff817c216b>] _raw_spin_unlock_irqrestore+0x3b/0x60 ... Call Trace: [<ffffffff813f40d1>] free_object+0x81/0xb0 [<ffffffff813f4f33>] debug_check_no_obj_freed+0x193/0x220 [<ffffffff81101a59>] ? trace_hardirqs_on_caller+0xf9/0x1c0 [<ffffffff81284996>] ? file_free_rcu+0x36/0x60 [<ffffffff81251712>] kmem_cache_free+0xd2/0x380 [<ffffffff81284960>] ? fput+0x90/0x90 [<ffffffff81284996>] file_free_rcu+0x36/0x60 [<ffffffff81124c23>] rcu_nocb_kthread+0x1b3/0x550 [<ffffffff81124b71>] ? rcu_nocb_kthread+0x101/0x550 [<ffffffff81124a70>] ? sync_exp_work_done.constprop.63+0x50/0x50 [<ffffffff810c59d1>] kthread+0x101/0x120 [<ffffffff81101a59>] ? trace_hardirqs_on_caller+0xf9/0x1c0 [<ffffffff817c2d32>] ret_from_fork+0x22/0x50 To reduce the amount of contention on the pool_lock, the actual kmem_cache_free() of the debug objects will be delayed if the pool_lock is busy. This will temporarily increase the amount of free objects available at the free pool when the system is busy. As a result, the number of kmem_cache allocation and freeing should be reduced. This patch also groups the freeing of debug objects in a batch of 4 to reduce the total number of lock/unlock cycles. Link: http://lkml.kernel.org/r/1483647425-4135-4-git-send-email-longman@redhat.com Signed-off-by: Waiman Long <longman@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "Du Changbin" <changbin.du@intel.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Jan Stancek <jstancek@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
For dwmac-sun8i, some actions must be done for enabling attached PHY. Thoses actions must be done after stmmac_probe_config_dt() and at start of stmmac_init_phy(). The best way to handle that is to add an optional init_phy() function. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Thoses symbol will be needed for the dwmac-sun8i ethernet driver. For letting it to be build as module, they need to be exported. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Instead of ading more ifthen login for adding a new mac_device_info setup function, it is easier to add a function pointer to the function needed. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This patch adds documentation for Device-Tree bindings for the Allwinner dwmac-sun8i driver. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i is a heavy hacked version of stmmac hardware by allwinner. In fact the only common part is the descriptor management and the first register function. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This patch add the dt node for the syscon register present on the Allwinner H3. Only two register are present in this syscon and the only one useful is the one dedicated to EMAC clock. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i is an ethernet MAC hardware that support 10/100/1000 speed. This patch enable the dwmac-sun8i on the Allwinner H3 SoC Device-tree. The SoC H3 have an internal PHY, so optionals syscon and ephy are set. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This patch add pinctrl node for dwmac-sun8i on H3. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Banana Pi M2+ It uses an external PHY rtl8211e via RGMII. This patch create the needed regulator, emac and phy nodes. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI PC. It uses the internal PHY. This patch create the needed emac node. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI 2. It uses the internal PHY. This patch create the needed emac node. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI One. It uses the internal PHY. This patch create the needed emac node. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the Orange PI plus. It uses an external PHY rtl8211e via RGMII. This patch create the needed regulator, emac and phy nodes. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
On the Orange Pi PC Plus, the polarity of the LEDs on the RJ45 Ethernet port were changed from active low to active high. Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This patch add the dt node for the syscon register present on the Allwinner A64. Only two register are present in this syscon and the only one useful is the one dedicated to EMAC clock. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit connections. It is very similar to the device found in the Allwinner H3, but lacks the internal 100 Mbit PHY and its associated control bits. This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps it disabled at this level. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the pine64 It uses an external PHY via RMII. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the pine64 plus. It uses an external PHY rtl8211e via RGMII. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
The dwmac-sun8i hardware is present on the BananaPi M64. It uses an external PHY rtl8211e via RGMII. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Enable the dwmac-sun8i driver in the sunxi default configuration Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
Enable the dwmac-sun8i driver in the multi_v7 default configuration Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
|
Hi @mozesslackware! Thanks for your contribution to the Linux kernel! Linux kernel development happens on mailing lists, rather than on GitHub - this GitHub repository is a read-only mirror that isn't used for accepting contributions. So that your change can become part of Linux, please email it to us as a patch. Sending patches isn't quite as simple as sending a pull request, but fortunately it is a well documented process. Here's what to do:
How do I format my contribution?The Linux kernel community is notoriously picky about how contributions are formatted and sent. Fortunately, they have documented their expectations. Firstly, all contributions need to be formatted as patches. A patch is a plain text document showing the change you want to make to the code, and documenting why it is a good idea. You can create patches with Secondly, patches need 'commit messages', which is the human-friendly documentation explaining what the change is and why it's necessary. Thirdly, changes have some technical requirements. There is a Linux kernel coding style, and there are licensing requirements you need to comply with. Both of these are documented in the Submitting Patches documentation that is part of the kernel. Note that you will almost certainly have to modify your existing git commits to satisfy these requirements. Don't worry: there are many guides on the internet for doing this. Who do I send my contribution to?The Linux kernel is composed of a number of subsystems. These subsystems are maintained by different people, and have different mailing lists where they discuss proposed changes. If you don't already know what subsystem your change belongs to, the
Make sure that your list of recipients includes a mailing list. If you can't find a more specific mailing list, then LKML - the Linux Kernel Mailing List - is the place to send your patches. It's not usually necessary to subscribe to the mailing list before you send the patches, but if you're interested in kernel development, subscribing to a subsystem mailing list is a good idea. (At this point, you probably don't need to subscribe to LKML - it is a very high traffic list with about a thousand messages per day, which is often not useful for beginners.) How do I send my contribution?Use For more information about using How do I get help if I'm stuck?Firstly, don't get discouraged! There are an enormous number of resources on the internet, and many kernel developers who would like to see you succeed. Many issues - especially about how to use certain tools - can be resolved by using your favourite internet search engine. If you can't find an answer, there are a few places you can turn:
If you get really, really stuck, you could try the owners of this bot, @daxtens and @ajdlinux. Please be aware that we do have full-time jobs, so we are almost certainly the slowest way to get answers! I sent my patch - now what?You wait. You can check that your email has been received by checking the mailing list archives for the mailing list you sent your patch to. Messages may not be received instantly, so be patient. Kernel developers are generally very busy people, so it may take a few weeks before your patch is looked at. Then, you keep waiting. Three things may happen:
Further information
Happy hacking! This message was posted by a bot - if you have any questions or suggestions, please talk to my owners, @ajdlinux and @daxtens, or raise an issue at https://github.com/ajdlinux/KernelPRBot. |
rust: require mutable references when initialising sync primitives.
During OBEX Abort command, iOS may return an incomplete SDU packet which ends with the reply to the Abort command. During OBEX Abort command, iOS may return the L2CAP_SAR_END packet before the normal end of the SAR packets: < ACL Data TX: Handle 21 [2/8] flags 0x00 dlen 11 torvalds#194 [hci0] 14.923741 Channel: 3080 len 7 ctrl 0x060a [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Unsegmented TxSeq 5 ReqSeq 6 0a 06 ff 00 03 47 84 .....G. ... > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#382 [hci0] 19.701854 Channel: 65 len 1006 ctrl 0x460e [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Start (len 32767) TxSeq 7 ReqSeq 6 0e 46 ff 7f 90 7f ff 48 7f fc 43 48 41 52 53 45 .F.....H..CHARSE ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#383 [hci0] 19.701854 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#384 [hci0] 19.755918 Channel: 65 len 1006 ctrl 0xc610 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 8 ReqSeq 6 10 c6 6e 6f 73 61 69 72 65 73 64 65 73 69 67 6e ..nosairesdesign ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#385 [hci0] 19.775016 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#386 [hci0] 19.775024 Channel: 65 len 1006 ctrl 0xc612 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 9 ReqSeq 6 12 c6 69 63 6f 20 43 69 74 79 20 54 65 63 68 20 ..ico City Tech ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#387 [hci0] 19.775024 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#388 [hci0] 19.821542 Channel: 65 len 1006 ctrl 0xc614 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 10 ReqSeq 6 14 c6 6c 74 69 6e 67 20 50 61 72 74 6e 65 72 0d ..lting Partner. ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#389 [hci0] 19.821610 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#390 [hci0] 19.821610 Channel: 65 len 1006 ctrl 0xc616 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 11 ReqSeq 6 16 c6 6c 74 69 6e 67 2e 63 6f 6d 0d 0a 55 49 44 ..lting.com..UID ... > ACL Data RX: Handle 21 flags 0x02 dlen 11 torvalds#391 [hci0] 19.821610 Channel: 65 len 7 ctrl 0x8618 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: End TxSeq 12 ReqSeq 6 18 86 a0 00 03 3e 5d .....>] < ACL Data TX: Handle 21 [1/8] flags 0x00 dlen 12 torvalds#392 [hci0] 19.822491 L2CAP: Disconnection Request (0x06) ident 10 len 4 Destination CID: 3080 Source CID: 65 In this case the re-assembled packet should be 32767 bytes as defined in Start packet (torvalds#382), i.e. 33 segmented packets, but the End packet is sent as the 6th packet. The l2cap_reassemble_sdu() function returns error -EINVAL if reassembled packet size != expected size, triggering the L2CAP disconnection, which disconnects the OBEX session, preventing further OBEX actions. Log this, discard previous segmented packet data and only send data from SAR End packet to upstream. Closes: bluez/bluetooth-next#17 Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
During OBEX Abort command, iOS may return an incomplete SDU packet which ends with the reply to the Abort command. During OBEX Abort command, iOS may return the L2CAP_SAR_END packet before the normal end of the SAR packets: < ACL Data TX: Handle 21 [2/8] flags 0x00 dlen 11 torvalds#194 [hci0] 14.923741 Channel: 3080 len 7 ctrl 0x060a [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Unsegmented TxSeq 5 ReqSeq 6 0a 06 ff 00 03 47 84 .....G. ... > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#382 [hci0] 19.701854 Channel: 65 len 1006 ctrl 0x460e [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Start (len 32767) TxSeq 7 ReqSeq 6 0e 46 ff 7f 90 7f ff 48 7f fc 43 48 41 52 53 45 .F.....H..CHARSE ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#383 [hci0] 19.701854 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#384 [hci0] 19.755918 Channel: 65 len 1006 ctrl 0xc610 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 8 ReqSeq 6 10 c6 6e 6f 73 61 69 72 65 73 64 65 73 69 67 6e ..nosairesdesign ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#385 [hci0] 19.775016 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#386 [hci0] 19.775024 Channel: 65 len 1006 ctrl 0xc612 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 9 ReqSeq 6 12 c6 69 63 6f 20 43 69 74 79 20 54 65 63 68 20 ..ico City Tech ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#387 [hci0] 19.775024 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#388 [hci0] 19.821542 Channel: 65 len 1006 ctrl 0xc614 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 10 ReqSeq 6 14 c6 6c 74 69 6e 67 20 50 61 72 74 6e 65 72 0d ..lting Partner. ... > ACL Data RX: Handle 21 flags 0x02 dlen 552 torvalds#389 [hci0] 19.821610 > ACL Data RX: Handle 21 flags 0x01 dlen 458 torvalds#390 [hci0] 19.821610 Channel: 65 len 1006 ctrl 0xc616 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: Continuation TxSeq 11 ReqSeq 6 16 c6 6c 74 69 6e 67 2e 63 6f 6d 0d 0a 55 49 44 ..lting.com..UID ... > ACL Data RX: Handle 21 flags 0x02 dlen 11 torvalds#391 [hci0] 19.821610 Channel: 65 len 7 ctrl 0x8618 [PSM 4101 mode Enhanced Retransmission (0x03)] {chan 0} I-frame: End TxSeq 12 ReqSeq 6 18 86 a0 00 03 3e 5d .....>] < ACL Data TX: Handle 21 [1/8] flags 0x00 dlen 12 torvalds#392 [hci0] 19.822491 L2CAP: Disconnection Request (0x06) ident 10 len 4 Destination CID: 3080 Source CID: 65 In this case the re-assembled packet should be 32767 bytes as defined in Start packet (torvalds#382), i.e. 33 segmented packets, but the End packet is sent as the 6th packet. The l2cap_reassemble_sdu() function returns error -EINVAL if reassembled packet size != expected size, triggering the L2CAP disconnection, which disconnects the OBEX session, preventing further OBEX actions. Log this, discard previous segmented packet data and only send data from SAR End packet to upstream. Closes: bluez/bluetooth-next#17 Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>
No description provided.