-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
usb: increase USB_PORT_RESET_RECOVERY #1327
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sounds reasonable |
bsdimp
approved these changes
Aug 23, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Absent being able to ask Hans if there's something subtle this would break or some unintended long delay at boot, I think it's fine.
bsdimp
pushed a commit
to VexedUXR/freebsd-src
that referenced
this pull request
Sep 6, 2024
10ms seems to be too strict for some configurations, so increase to 20ms. Reviewed by: imp Pull Request: freebsd#1327
For example, printf("%+i", 1) prints "+1". However, kvprintf() did print just "1" for this example. According to PRINTF(3): A sign must always be placed before a number produced by a signed conversion. For "%+r" radix conversions, keep the "+" handling as it is, since this is a non-standard conversion. For "%+p" pointer conversions, continue to ignore the sign modifier to be in line with libc. This change allows to support the ' conversion modifier in the future. Reviewed by: imp Pull Request: freebsd#1310
10ms seems to be too strict for some configurations, so increase to 20ms. Reviewed by: imp Pull Request: freebsd#1327
Add version information to libxo output so that libxo content consumers can track changes. Reviewed by: imp, markj Pull Request: freebsd#1350
Add version information to libxo output so that libxo content consumers can track changes. Reviewed by: imp, markj Pull Request: freebsd#1350
Add version information to libxo output so that libxo content consumers can track changes. Reviewed by: imp, markj Pull Request: freebsd#1350
Add version information to libxo output so that libxo content consumers can track changes. Reviewed by: imp, markj Pull Request: freebsd#1350
Add version information to libxo output so that libxo content consumers can track changes. Reviewed by: imp, markj Pull Request: freebsd#1350
Add version information to libxo output so that libxo content consumers can track changes. Reviewed by: imp, markj Pull Request: freebsd#1350
Closes: 280538 Fixes: cf8a18 (back out logging to /var/log/adduser) MFC after: 3 days Reported by: Herbert Baerschneider <[email protected]> Reviewed by: imp Pull Request: freebsd#1354
Reviewed by: imp, emaste Pull Request: freebsd#1356
This provides functionality for a click which is partially unreleased and then allows the user to continue moving the mousepad as if were not invoked as a full click Signed-off-by: Joshua Rogers <[email protected]> Reviewed by: imp, wulf Pull Request: freebsd#1365
This patch allows scrolling with multiple fingers simultaneously, in line with how wsp trackpads function on MacOS. Two new tunables are added: hw.usb.wsp.max_finger_area and hw.usb.wsp.max_double_tap_distance. max_finger_area defines the maximum size which the driver registered an object on trackpad as a finger. Previously, this value was hardcoded as 1200, which was too low to register thumb-clicks. max_double_tap_distance defines the maximum distance between two fingers which will register as a double-click. Signed-off-by: Joshua Rogers <[email protected]> Reviewed by: imp, wulf Pull Request: freebsd#1365
Also correctly use tun.max_double_tap_distance for maximum distance of fingers for vertical scrolling. Signed-off-by: Joshua Rogers <[email protected]> Reviewed by: imp, wulf Pull Request: freebsd#1365
The struct timespec tv_sec member is of type time_t. Make sure that all variables related to this member are of the type time_t. This is important for targets where long is a 32-bit type and time_t a 64-bit type. Reviewed by: imp Pull Request: freebsd#1373
Commit e695500 updated the policy table to match RFC 6724, which obsoletes RFC 3484. Add a reference to RFC 6724, and mark it up as a technical report (%R). MFC after: 3 days Signed-off-by: Jose Luis Duran <[email protected]> Reviewed by: imp, glebius Pull Request: freebsd#1375
Update the sample ip6addrctl.conf.sample file to match the default policy, currently based on RFC 6724. MFC after: 3 days Signed-off-by: Jose Luis Duran <[email protected]> Reviewed by: imp, glebius Pull Request: freebsd#1375
Reviewed by: imp, glebius Pull Request: freebsd#1375
The error was always returned, even after handling the sysctl, breaking installworld under Linux. Sponsored by: https://www.patreon.com/valpackett Reviewed by: imp Pull Request: freebsd#1376
MFC after: 3 days Reviewed by: imp Pull Request: freebsd#1378
MFC after: 3 days Reviewed by: imp Pull Request: freebsd#1379
Fixes: 86c06f (Remove GEOM_SCHED class and gsched) MFC after: 3 days Reviewed by: imp Pull Request: freebsd#1380
MFC after: 3 days Reviewed by: imp Pull Request: freebsd#1382
+ consistent document description languague with other USB-BaseT drivers + mention newly added adapters from 6ea4d9 + attempt to mention rgephy(4) phys feed into ure interfaces Fixes: 6ea4d9 (Move RTL8156 from cdce(4) to ure(4)) MFC after: 3 days Reviewed by: imp Pull Request: freebsd#1384
Signed-off-by: Tom Hukins <[email protected]> Reviewed by: imp Pull Request: freebsd#1385
Add logic that checks if the code doesn't overflow ACPI_EXTENDED_HID_DEVICE_PATH node when searching for optional strings. If the string is not provided in the device path node default value of "\0" is used. Upstream PR: https://bugzilla.tianocore.org/show_bug.cgi?id=4555 Obtained from: tianocore/edk2@96ed60d Reviewed by: imp Pull Request: freebsd#1388
Since 26b9e1f codel was fixed but traffic was not flowing for pie too. Apply the same fix. MFC after: 1 week Sponsored by: OPNsense Differential Revision: https://reviews.freebsd.org/D46182 Also see: https://redmine.pfsense.org/issues/13996 Also see: https://forum.opnsense.org/index.php?topic=41827.0 Reviewed by: imp, markj Pull Request: freebsd#1390
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
10ms seems to be a little too short for some configurations.
I have two USB devices that needed this change (both Sinowealth mice) to work. From my tests, I could only get the issue to show up on both an
AMD 500 Series Chipset USB 3.1 XHCI Controller
and it's 400 series counterpart. Using other hubs on the system works fine. Note that these hubs work perfectly fine for every other USB device I've tried. I also tried it on two different 500 series controllers, getting the exact same result.Someone also had a similar issue (I'm 90% sure it was also caused by this) on discord a while ago, and it was fixed by moving the usb device to another hub. I don't have enough info, so I don't know what the problematic device was though.
As a sanity check, I looked at what NetBSD was doing and it looks like they came to the same conclusion.
See NetBSD/src@e988d63