3.8 #111
Closed
3.8 #111
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
Implement the MXT DMA method of reading messages. On an interrupt, the T44 report always contains the number of messages pending to be read. So, read 1 byte from T44 in 1 i2c transaction, then read the N pending messages in a second transaction. The end result is a much much faster read time for all pending messages. Using 400kHz i2c, it is possible to read 10 pending messages (e.g. for 10 moving contatcts) in less than 2.8ms, which is well less than the typical 10-15ms update rate. Note: There is a possible optimization here. The T44 byte is guaranteed to always be right before the T5 address. Thus, it should be possible to always fetch the T44 message count and the first message in a single transaction. This would eliminate the overhead of a second complete read transaction for the case where there is only a single pending message. (This is actually the most common case, for instance with just 1-contact on the device touch surface). This optimization, however, is not done in this patch. Signed-off-by: Daniel Kurtz <[email protected]> BUG=chromium-os:27713 TEST=builds clean; all pending messages are processed for each interrupt. Change-Id: I9aa4627d2afdc6da14b7495e78c429d1c4ded7ae Reviewed-on: https://gerrit.chromium.org/gerrit/17956 Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> Commit-Ready: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
This function attempts to make the CHG pin high by reading a messages until the device queue is empty. Instead of throwing away the message contents, let's actually process them. Also, instead of stopping after a fixed (10) number of messages, keep reading until the device reports that it has no more valid messages - at that point, the CHG line should truly be high. Signed-off-by: Daniel Kurtz <[email protected]> BUG=chromium-os:27713 TEST=builds clean; messages after boot are processed; Config Checksum displayed in dmesg: $ grep "Config Checksum" /var/log/messages Change-Id: I3d1e266d1ac53f5640e65c5acc3fe6672a0c1451 Reviewed-on: https://gerrit.chromium.org/gerrit/17957 Commit-Ready: Daniel Kurtz <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> Reviewed-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
The matrix x/y size in the Info Block represents the max x/y lines availble on the device and it will only be updated by the firmware but not the platform data configuration, which sets the x/y lines in T9 object. BUG=None TEST=None Change-Id: I18e4f9855fe2018c2b55256ce25821a6197b9f81 Signed-off-by: Yufeng Shen <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/21547 v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
The atmel_mxt_ts T9 data contains information orientation in its 'vector' field. Parse and debug print its contents, although its value isn't actually used yet. Signed-off-by: Daniel Kurtz <[email protected]> BUG=chromium-os:27713 TEST=builds clean; vector values are reported when DEBUG is defined. Change-Id: Ida4d9aa167e5134c76d044599240a6c7e329a62c Reviewed-on: https://gerrit.chromium.org/gerrit/17951 Commit-Ready: Daniel Kurtz <[email protected]> Reviewed-by: Daniel Kurtz <[email protected]> Tested-by: Daniel Kurtz <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
Currently when system enters/leaves sleep mode, the driver dis/enables
T9 object. It has the limitation that 1) it does not allow the device
to wakeup the system 2) the device is not in it's best power saving mode
when the system is sleeping.
This patch adds the support to put the device into 1) Idle mode, when the
need of wakeup from sleep is needed 2) Deepsleep mode when wakeup from
sleep is not needed.
To achieve this, when the system enters sleep mode, the current T7 Power
Config value is first saved and then it is re-configured to be Idle mode
(with largest Idle Acquisition Interval and largest Active Acquisition
Interval) or Deepsleep mode. Also if wakeup from sleep is needed, the
current T9 Ctrl field is saved and a resonable value 0x03 is used to
enable T9 so that we can be sure touch contact will generate IRQ to wake
the system up.
When resume, before-suspend T7 and T9 values are restored accordingly.
BUG=chrome-os-partner:9413
TEST=On system with atmel trackpad
cd /sys/bus/i2c/drivers/atmel_mxt_ts/2-004b/power
echo "enabled" > wakeup
powerd_suspend
touch trackpad should wakeup the system
echo "disabled" > wakeup
powerd_suspend
touch trackpad should not wakeup the system
Change-Id: I85896691ddd69d854a923f548edf8b7d6caa9f8e
Signed-off-by: Yufeng Shen <[email protected]>
Reviewed-on: https://gerrit.chromium.org/gerrit/21919
Reviewed-by: Benson Leung <[email protected]>
v3.7 rebase:
Signed-off-by: Daniel Kurtz <[email protected]>
The object sysfs entry is used to read the current register value of all the objects. Each read on the sysfs entry can only return up to PAGE_SIZE (usually 4k) bytes, which is not enough for showing all the object values for some atmel chips. This CL moves the sysfs entry to debugfs which does not have this PAGE_SIZE limit on read. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:9253 TEST=cd /sys/kernel/debug/atmel_mxt_ts/*DEVICE-I2C-ADDR*/ cat object it should show the register value for all the objects Change-Id: Ic2f0df0c17655b5208ef5746f602fdb8af1c3467 Reviewed-on: https://gerrit.chromium.org/gerrit/21812 Commit-Ready: Yufeng Shen <[email protected]> Reviewed-by: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
… pdata This is the preparation for supporting the code path when there is platform data provided and still boot the device into a sane state with backup NVRAM config. This CL makes the irqflags default to be IRQF_TRIGGER_FALLING if no platform data is provided. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:9103 TEST=The code path for no pdata is not supported yet, so no test can be done at this point. And no funtional change along the normal code path with platform data provided. Change-Id: Icea0fff544c77b38eb380851d7e7d8f857b76745 Reviewed-on: https://gerrit.chromium.org/gerrit/22417 Reviewed-by: Daniel Kurtz <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
Add the support that the device finishes initialization even when no platform data is provided. Most of the time the device needs configured only once and later on it can just use backed up config from NVRAM. So the code path with no platform saves on device initialization time. Rename mxt_check_reg_init() to be mxt_apply_pdata_config() and move it into mxt_handle_pdata() so that all the platform data processing is in one fucntion. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:9103 TEST=Rebuild the kernel with no platform data provided, boot the device with a previously working atmel chip, and make sure the atmel chip still works. Change-Id: I2440c58ab9b9baa1160406827ba9d08aee52a554 Reviewed-on: https://gerrit.chromium.org/gerrit/22587 Commit-Ready: Yufeng Shen <[email protected]> Reviewed-by: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]>
If the atmel chip enters suspend mode and wants to be able to wakeup from suspend, T9 object has to be enabled during suspend. If T9 is enalbed from a disabled state, the chip will perform an auto calibration and send back the status of the calibration. We have to wait for these messages to be read before entering suspend, otherwise these message will wakeup the system automatically. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:8722 TEST=run powerd_suspend to put system into sleep and make sure it does not wakeup automatically. And touch the TS/TP to wake the system up Change-Id: Iaf8175c8e6d523edfd152172e1966303ac8fd65f Reviewed-on: https://gerrit.chromium.org/gerrit/22842 Reviewed-by: Benson Leung <[email protected]> Reviewed-by: Vadim Bendebury <[email protected]> Tested-by: Yufeng Shen <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
On system with more than 1 Atmel chip, a fixed firmware file name "maxtouch.fw" does not work since different chips need different firmware files. This CL adds the sysfs entry that make it possible for userspace to specify the file name of the firmware to be loaded. If no file name is specified, the default "maxtouch.fw" is used for compatibility with existing code. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:9103 TEST=cat path-to-atmel-sysfs/fw_file and make sure "maxtouch.fw" is returned echo XXX > path-to-atmel-sysfs/fw_file cat path-to-atmel-sysfs/fw_file and make sure XXX is returned echo 1 > path-to-atmel-sysfs/update_fw and make sure the driver tries to load XXX if XXX exists in /lib/firmware, check that firmware update succeeds if XXX does not exist in /lib/firmware, check that firmware update fails Change-Id: Icdff2851866b36de08c6fd75c29947a8d27f7dfe Reviewed-on: https://gerrit.chromium.org/gerrit/22867 Reviewed-by: Benson Leung <[email protected]> Tested-by: Yufeng Shen <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
In the preparation for adding support of loading atmel config data from file, this CL adds the sysfs entry config_file so that which config file to be used is configurable from userspace. The config file under /lib/firmware/ will be loaded through request_firmware() call. The default config file is "maxtouch.cfg". This support is necessary on system with more than 1 atmel chip and each needs a different configuration file. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:9103 TEST=cat path-to-atmel-sysfs/config_file and make sure "maxtouch.cfg" is returned echo XXX > path-to-atmel-sysfs/config_file cat path-to-atmel-sysfs/config_file and make sure XXX is returned Change-Id: If87a4956c46b4a27e40f689be6304691b79cbf00 Reviewed-on: https://gerrit.chromium.org/gerrit/21663 Reviewed-by: Benson Leung <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
…file Adding a sysfs entry for loading .raw Atmel config file and write it to the device memory. The format spec of .raw Atmel config file can be found at E-9078 Object-Based Chip Config File Format The input device is unregistered while the configuration data is written to ensure there are no open/close calls to the driver which may write extraneous values to the T9 control register. The input device is recreated once the device has been reset following the configuration update. Signed-off-by: Daniel Kurtz <[email protected]> Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:9103,chromium-os:33981 TEST=Provide no platform to the atmel device cd path-to-atmel-sysfs 1. cat config_file make sure maxtouch.cfg is returned. echo 1 > update_config and check the error msg in dmesg for "Unable to open config file" 2. copy maxtouch.cfg over to /lib/firmware/ echo 1 > update_config check dmesg to see the device is reconfigured. Original-Change-Id: I439d86fcc0bf05b7922619e55af56ef79c1892ab Reviewed-on: https://gerrit.chromium.org/gerrit/24532 Reviewed-by: Daniel Kurtz <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> Change-Id: If8f7ea2953f1a825cbcad4a548cf563345518c7d Reviewed-on: https://gerrit.chromium.org/gerrit/31638 v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
mxt_probe() calles mxt_initialize() to initialize the device, which includes
a soft reset and then msleep for the reset to finish. This has big impact on
the system boot time. This patch makes the mxt_initizlize() call async to
reduce the system boot time.
BUG=chrome-os-partner:15743
TEST=Boot the device and check the kernel timestamp in dmesg to see that
the device initialization is parallelized.
Signed-off-by: Yufeng Shen <[email protected]>
Original-Change-Id: If106af37a52a0fa874cdc8255c91fdde36776e1f
Reviewed-on: https://gerrit.chromium.org/gerrit/36964
Reviewed-by: Benson Leung <[email protected]>
Tested-by: Simon Que <[email protected]>
Commit-Ready: Yufeng Shen <[email protected]>
v3.7 rebase:
Signed-off-by: Daniel Kurtz <[email protected]>
[sonnyrao: removed __devinit for 3.8 rebase]
Change-Id: I81785546c6a0ff87486e7ee92cb8bab8aefe2594
Now that we conditionally load configs from pdata only if pdata exists, we no longer need to backup_nv in mxt_initialize. Backup nv should only be done if config data was provided as a part of platform data. This will save 270ms for backup to nv wait. Signed-off-by: Benson Leung <[email protected]> BUG=chromium-os:33370 TEST=Boot on a system with a touch device instantiated without pdata. Ensure that device is still functional, but that 270ms has been saved until the input device is created. Change-Id: I44ecf9237db2f866787c72e03e8962ca285db865 Reviewed-on: https://gerrit.chromium.org/gerrit/29571 Commit-Ready: Benson Leung <[email protected]> Reviewed-by: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
Fix the use of magic numbers (such as 0x83) to write to T9 Touch Control. Signed-off-by: Benson Leung <[email protected]> BUG=chromium-os:33368 TEST=Builds clean. Change-Id: I28d650becaa103490541cd88b600fdb535b4196c Reviewed-on: https://gerrit.chromium.org/gerrit/29558 Commit-Ready: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> Reviewed-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
Leave the touch device scanning and enabled, but disable reporting on mxt_stop. This will prevent a needless recalibration due to the T9_ctrl register being set to 0 (disabling the object) and then set back to 0x83. BUG=chrome-os-partner:12042,chrome-os-partner:9717 TEST=Log in to guest mode. Test the touch screen. Log out. Verify that in the next session (after X has restarted) touch performance is still good. Change-Id: If5556325d69390a329d1ed406b5bba9f0d494896 Signed-off-by: Benson Leung <[email protected]> Reviewed-on: https://gerrit.chromium.org/gerrit/29951 v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
The position information at resume time while the system is in a low power state may be garbage, so do not actually report this information up to the input layer. Just perform the reads to clear out the status on the device side. Signed-off-by: Benson Leung <[email protected]> BUG=chrome-os-partner:12318 TEST=Suspend/resume using lid close. Check that on resume, the touch device doesn't show a bunch of garbage data from when the lid was just being opened. Change-Id: I4e60ab672d6191b9141e08e9b0bfdbf42649a95e Reviewed-on: https://gerrit.chromium.org/gerrit/31194 Reviewed-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
…sabled Signed-off-by: Benson Leung <[email protected]> BUG=chrome-os-partner:12318 TEST=Close and open the lid to suspend and resume the system. Make sure that the touchscreen does not generate a lot of stray events on resume. Change-Id: I57b34aab52149cc78cd55a79640b496239bbfa5e Reviewed-on: https://gerrit.chromium.org/gerrit/31270 Reviewed-by: Yufeng Shen <[email protected]> Commit-Ready: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
Currently when going into suspend and if wakeup is enabled, the driver will check whether the T9_ctrl ENABLE bit is set and if not, it will toggle the bit so that T9 object is enabled to make wakeup possible during suspend. With recent change to T9_ctrl's default value to be 0x81, it is enabled (ENABLE bit set) but not reporting (RPTEN bit not set) which prevents touches reported back during suspend. To fix this, this patches adds checking that whether both ENABLE and RPTEN bits are set, and if not, set both of them. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:9192 TEST=Use powerd_suspend to supend the device and then make sure touching the touch device wakes up the system. Change-Id: I234531ae91627f7e1cccbef5810a18a5af6cbae9 Reviewed-on: https://gerrit.chromium.org/gerrit/33088 Reviewed-by: Vadim Bendebury <[email protected]> Reviewed-by: Benson Leung <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]>
Currently lid close/open can generate noise touch events on system suspend and resume. One case is that touch down is generated before suspend, and touch liftoff is processed on resume. The driver will discard any pending messages on resume which might make the system enter ghost finger state (touch down without ever liftoff). To workaround the ghost finger case, this patch forces release of all possible fingers on resume. And to avoid the unwanted click resulted from the forced release, move these fingers first to (0,0) and assign them with maximal PRESSURE and TOUCH_MAJOR value so to make them look like palms. Signed-off-by: Yufeng Shen <[email protected]> BUG=chromium:154383 TEST=use evtest to monitor the touch device; put fingers on the touch device; close the lid; remove fingers after making sure the system enters suspend; Open the lid; Make sure to see finger move events with pressue and touch_major = 255 and the release events. Change-Id: Ic9f0659a2e731c2db03255eb2107be88b333541a Reviewed-on: https://gerrit.chromium.org/gerrit/35046 Reviewed-by: Daniel Kurtz <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
…al configurable Create sysfs for T7 IDLE/ACTV-ACQINT settings to have a configurable power acquisition setting during system suspend. Also change the default T7 IDLE/ACTV-ACQINT values during system suspend to be 32ms to have a sensitive wakeup-from-touch response. Signed-off-by: Yufeng Shen <[email protected]> Signed-off-by: Daniel Kurtz <[email protected]> BUG=chrome-os-partner:15968 TEST=1. go to touch device sysfs directory echo 254 > power/suspend_acq_interval_ms Try powerd_suspend and use very quick, gentle touch to wake up the system and notice that sometimes the system does not wake up from touch. 2. go to touch device sysfs directory echo 32 > power/suspend_acq_interval_ms Try powerd_suspend and use very quick, gentle touch to wake up the system and make sure the system always wakes up. Change-Id: Ib7ad7a6b81699b71bcb165df06f275e55a68e7c6 Reviewed-on: https://gerrit.chromium.org/gerrit/37836 Reviewed-by: Benson Leung <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
In the suspend path, if we don't allow device wakeup, we put the chip into deepsleep mode and the chip stops scanning during suspen. On resume if the environment changes, the calibrated baseline before suspend will no longer be valid. In this patch we force a recalibration on resume if device wakeup is disabled during suspend to handle the environment change. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:16171 TEST=I don't have a controlled environment to test this. So I only test normal suspend/resume to make sure no noise touches happen on resume and touch devices work as expected. 1. With lid open, using powerd_suspend to suspend the system. Wakeup the system and make sure the touch device still works. Run "demsg | grep atmel" to make sure no calibration message reported. 2. Use lid close to suspend the system. Wakeup the system and make sure touch device still works. Run "demsg | grep atmel" to make sure calibration message are reported. 3. Also notice the case of lid open caused system resume, if something is on the touch surface (like opening the lid and quickly put the palm on the touch surface for a while), the system will get calibrated into a wrong baseline and touch device then won't work. Change-Id: I62cb47fa1c97917a2c0f968e41ee4cd13f12187c Reviewed-on: https://gerrit.chromium.org/gerrit/38051 Reviewed-by: Benson Leung <[email protected]> Commit-Ready: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> v3.7 rebase: Signed-off-by: Daniel Kurtz <[email protected]>
…ease_all_fingers() We hard-coded the maximal touch_major value to be 255 in mxt_release_all_fingers(). Fixing this by using the queried actual maximal touch_major value. Signed-off-by: Yufeng Shen <[email protected]> BUG=chrome-os-partner:17176 TEST=1. Run evtest on the touch device 2. Keep touching the device while closing the lid. 3. Release the touch after the system suspends. 4. Open the lid to resume the system 5. Check evtest result and see that there is release events with correct touch major value. Change-Id: I4c3bbb37c25c0df67c752a8b6943f6c127f01aa7 Reviewed-on: https://gerrit.chromium.org/gerrit/41031 Reviewed-by: Benson Leung <[email protected]> Commit-Queue: Yufeng Shen <[email protected]> Tested-by: Yufeng Shen <[email protected]> (cherry picked from commit 0a962d62165755547e4802da837ca9004f5d246b)
…ection Add T65 object to list of supported objects, and mark it readable and writable. Signed-off-by: Benson Leung <[email protected]> BUG=chrome-os-partner:17253 TEST=cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object Check that the following object appears: Type: 65 [ 0]: 00 (0) [ 1]: 00 (0) [ 2]: 00 (0) [ 3]: 00 (0) [ 4]: 00 (0) [ 5]: 00 (0) [ 6]: 00 (0) [ 7]: 00 (0) [ 8]: 00 (0) [ 9]: 00 (0) [10]: 00 (0) [11]: 00 (0) [12]: 00 (0) [13]: 00 (0) [14]: 00 (0) [15]: 00 (0) [16]: 00 (0) Change-Id: I8400bd53d619ff0e4af4c4d5ae7f54bb5dc6e9b8 Reviewed-on: https://gerrit.chromium.org/gerrit/41310 Reviewed-by: Yufeng Shen <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 5fd7e4778bd22252de5611a894d061a3bb64c4a2)
…suspend To work around an issue where an idle-suspended system may wake unnecessarily when the lid is closed because the B panel comes close to the trackpad, enable touch suppression (t42) when suspending. Also disable T19, for the button, to allow the button to be pressed if the case is flexed without the system waking. Signed-off-by: Benson Leung <[email protected]> BUG=chrome-os-partner:17336 TEST=1. Suspend the system with powerd_suspend with lid open. 2. Touch the touchpad. Make sure the system still wakes. 3. Suspend again with powerd_suspend 4. Close the lid. Ensure the system does not wake by observing the system status light. Change-Id: I858af27e65ce491c8eb99f5b8db13ea91f789f3e Reviewed-on: https://gerrit.chromium.org/gerrit/41678 Reviewed-by: Puneet Kumar <[email protected]> Reviewed-by: Vincent Palatin <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 6988c8d813d863007df2ba3f418172d07b63ece6) [djkurtz: v3.6: merge]
Userspace will change it to enabled if needed. Signed-off-by: Benson Leung <[email protected]> BUG=chrome-os-partner:17336 TEST=cat /sys/bus/i2c/devices/2-004a/power/wakeup Check that it returns "disabled" Suspend the system using powerd_suspend. Check that the touch device 2-004a does not wake the system. Change-Id: If5ac3b30c137d16e5592d4a2ee555fd2533b0caa Reviewed-on: https://gerrit.chromium.org/gerrit/41679 Reviewed-by: Vincent Palatin <[email protected]> Reviewed-by: Puneet Kumar <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 6625e780bacf270b6da346751819d2825f09c20a)
This is an x86 specific change for the short term. When the lid is closed, issue an mxt_stop to turn off scanning to prevent the lid from affecting the touch device and causing stray touches. Signed-off-by: Benson Leung <[email protected]> BUG=chrome-os-partner:17465 TEST=From test mode, run evtest, and watch the atmel_mxt device. Close and open the lid. Make sure there are no touch data comes from the atmel driver when the lid is being closed. Change-Id: I2163384fc7cbd45c63d05983c50d2a869975a3c9 Reviewed-on: https://gerrit.chromium.org/gerrit/42080 Reviewed-by: Vincent Palatin <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 5391ebafb8f9b72475795445ca71b02815a2a229)
Instead of using 0x81 to keep the object enabled, disable T9 on mxt_stop by writing 0x00 to it. Signed-off-by: Benson Leung <[email protected]> BUG=chrome-os-partner:17465 TEST=stop powerd (on R25 also stop powerm) close the lid, or use a magnet to trigger the lid sensor. cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object Look for Type: 9, byte 0. Check that this is 0x00 when lid is closed. When opened, this should return to 0x83. Change-Id: If794e121d1b61186fee9e5b9f97b922549d7beb8 Reviewed-on: https://gerrit.chromium.org/gerrit/42183 Reviewed-by: Puneet Kumar <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 65caaf9e0697899cd5e21eb643e018298adc781a) [djkurtz: v3.6 merge]
This is an x86 specific change for the short term. When the lid is closed on resume, make sure T9 is disabled. to prevent the lid from affecting the touch device and causing stray touches. If lid is open, restore operational settings for T9. Signed-off-by: Benson Leung <[email protected]> BUG=chrome-os-partner:17465 TEST=Close the lid to suspend in guest mode. Open the lid slowly, until you see the lights indicating resuming. Close the lid immediately upon seeing the system resume from the status light. The system should stay in S0. Check via ssh: cat /sys/kernel/debug/atmel_mxt_ts/2-004a/object Check that T9 is 0x00. On a normal suspend/resume, where the lid is opened, check that touch device is functional. Change-Id: Ibce1c8c000e4bd2a8f360bea2b116051eee35be7 Reviewed-on: https://gerrit.chromium.org/gerrit/42184 Reviewed-by: Puneet Kumar <[email protected]> Commit-Queue: Benson Leung <[email protected]> Tested-by: Benson Leung <[email protected]> (cherry picked from commit 4201ff9f7a9e114c453932662d49e34047dee59c)
Signed-off-by: Maxime Ripard <[email protected]>
Signed-off-by: Peter Rosin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
Reported-by: kbuild test robot <[email protected]> Signed-off-by: Peter Rosin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
This was overlooked in the late change to remove the I2S padding bits from S24_LE mode. The patch also limits S32_LE mode to 384kHz, the maximum according to the datasheets. Signed-off-by: Peter Rosin <[email protected]> Signed-off-by: Mark Brown <[email protected]>
This comes directly from http://www.st.com/web/en/catalog/tools/FM147/CL1818/SC1885/PF258120 This was tested outside the kernel using https://gist.github.com/jadonk/ebeef7fb784226fdc80b
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
commit 71458cf upstream. We're missing include/linux/compiler-gcc5.h which is required now because gcc branched off to v5 in trunk. Just copy the relevant bits out of include/linux/compiler-gcc4.h, no new code is added as of now. This fixes a build error when using gcc 5. Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 51b97e3 upstream. Sasha Levin reports: "gcc5 changes the default standard to c11, which makes kernel build unhappy Explicitly define the kernel standard to be gnu89 which should keep everything working exactly like it was before gcc5" There are multiple small issues with the new default, but the biggest issue seems to be that the old - and very useful - GNU extension to allow a cast in front of an initializer has gone away. Patch updated by Kirill: "I'm pretty sure all gcc versions you can build kernel with supports -std=gnu89. cc-option is redunrant. We also need to adjust HOSTCFLAGS otherwise allmodconfig fails for me" Note by Andrew Pinski: "Yes it was reported and both problems relating to this extension has been added to gnu99 and gnu11. Though there are other issues with the kernel dealing with extern inline have different semantics between gnu89 and gnu99/11" End result: we may be able to move up to a newer stdc model eventually, but right now the newer models have some annoying deficiencies, so the traditional "gnu89" model ends up being the preferred one. Signed-off-by: Sasha Levin <[email protected]> Singed-off-by: Kirill A. Shutemov <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
With the new eMMC5.1 spec, there is a new EXT_CSD register with the revision number(EXT_CSD_REV) 7. This patch updates the check for ext-csd.rev number as 7. Signed-off-by: Alim Akhtar <[email protected]> Signed-off-by: Yuvaraj Kumar C D <[email protected]> Reviewed-by: Doug Anderson <[email protected]> Signed-off-by: Chris Ball <[email protected]>
As stated by the eMMC 5.0 specification, a chip should not be rejected only because of the revision stated in the EXT_CSD_REV field of the EXT_CSD register. Remove the control on this value, the control of the CSD_STRUCTURE field should be sufficient to reject future incompatible changes. Signed-off-by: Romain Izard <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
….h files Signed-off-by: Robert Nelson <[email protected]>
[ Upstream commit 8ae9422 ] Debian started to build the gcc with -fPIE by default so the kernel build ends before it starts properly with: |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Also add to KBUILD_AFLAGS due to: |gcc -Wp,-MD,arch/x86/entry/vdso/vdso32/.note.o.d … -mfentry -DCC_USING_FENTRY … vdso/vdso32/note.S |arch/x86/entry/vdso/vdso32/note.S:1:0: sorry, unimplemented: -mfentry isn’t supported for 32-bit in combination with -fpic Tagging it stable so it is possible to compile recent stable kernels as well. Cc: [email protected] Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Michal Marek <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
Signed-off-by: Robert Nelson <[email protected]>
|
Wrong button. ;) closing for you... |
fhgwright
pushed a commit
to fhgwright/bb-linux
that referenced
this pull request
Oct 10, 2017
hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no check for that, which results in a WARNING in USB core code, when a bad USB descriptor is provided from a device: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ beagleboard#111 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: ffff88006bdc1a00 task.stack: ffff88006bde8000 RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448 RSP: 0018:ffff88006bdee3c0 EFLAGS: 00010282 RAX: 0000000000000029 RBX: ffff8800672a7200 RCX: 0000000000000000 RDX: 0000000000000029 RSI: ffff88006c815c78 RDI: ffffed000d7bdc6a RBP: ffff88006bdee4c0 R08: fffffbfff0fe00ff R09: fffffbfff0fe00ff R10: 0000000000000018 R11: fffffbfff0fe00fe R12: 1ffff1000d7bdc7f R13: 0000000000000003 R14: 0000000000000001 R15: ffff88006b02cc90 FS: 0000000000000000(0000) GS:ffff88006c800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe4daddf000 CR3: 000000006add6000 CR4: 00000000000006f0 Call Trace: hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:385 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 __device_attach+0x269/0x3c0 drivers/base/dd.c:682 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 device_add+0xcf9/0x1640 drivers/base/core.c:1703 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:385 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 __device_attach+0x269/0x3c0 drivers/base/dd.c:682 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 device_add+0xcf9/0x1640 drivers/base/core.c:1703 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4890 hub_port_connect_change drivers/usb/core/hub.c:4996 port_event drivers/usb/core/hub.c:5102 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231 kthread+0x324/0x3f0 kernel/kthread.c:231 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425 Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89 e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6 ---[ end trace 55d741234124cfc3 ]--- Check that endpoint is interrupt. Found by syzkaller. Signed-off-by: Andrey Konovalov <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
RobertCNelson
pushed a commit
that referenced
this pull request
Oct 12, 2017
commit 70e743e upstream. hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no check for that, which results in a WARNING in USB core code, when a bad USB descriptor is provided from a device: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: ffff88006bdc1a00 task.stack: ffff88006bde8000 RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448 RSP: 0018:ffff88006bdee3c0 EFLAGS: 00010282 RAX: 0000000000000029 RBX: ffff8800672a7200 RCX: 0000000000000000 RDX: 0000000000000029 RSI: ffff88006c815c78 RDI: ffffed000d7bdc6a RBP: ffff88006bdee4c0 R08: fffffbfff0fe00ff R09: fffffbfff0fe00ff R10: 0000000000000018 R11: fffffbfff0fe00fe R12: 1ffff1000d7bdc7f R13: 0000000000000003 R14: 0000000000000001 R15: ffff88006b02cc90 FS: 0000000000000000(0000) GS:ffff88006c800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe4daddf000 CR3: 000000006add6000 CR4: 00000000000006f0 Call Trace: hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:385 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 __device_attach+0x269/0x3c0 drivers/base/dd.c:682 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 device_add+0xcf9/0x1640 drivers/base/core.c:1703 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:385 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 __device_attach+0x269/0x3c0 drivers/base/dd.c:682 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 device_add+0xcf9/0x1640 drivers/base/core.c:1703 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4890 hub_port_connect_change drivers/usb/core/hub.c:4996 port_event drivers/usb/core/hub.c:5102 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231 kthread+0x324/0x3f0 kernel/kthread.c:231 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425 Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89 e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6 ---[ end trace 55d741234124cfc3 ]--- Check that endpoint is interrupt. Found by syzkaller. Signed-off-by: Andrey Konovalov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
RobertCNelson
pushed a commit
that referenced
this pull request
Jan 8, 2018
commit 70e743e upstream. hwarc_neep_init() assumes that endpoint 0 is interrupt, but there's no check for that, which results in a WARNING in USB core code, when a bad USB descriptor is provided from a device: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3 at drivers/usb/core/urb.c:449 usb_submit_urb+0xf8a/0x11d0 Modules linked in: CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.13.0+ #111 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: ffff88006bdc1a00 task.stack: ffff88006bde8000 RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448 RSP: 0018:ffff88006bdee3c0 EFLAGS: 00010282 RAX: 0000000000000029 RBX: ffff8800672a7200 RCX: 0000000000000000 RDX: 0000000000000029 RSI: ffff88006c815c78 RDI: ffffed000d7bdc6a RBP: ffff88006bdee4c0 R08: fffffbfff0fe00ff R09: fffffbfff0fe00ff R10: 0000000000000018 R11: fffffbfff0fe00fe R12: 1ffff1000d7bdc7f R13: 0000000000000003 R14: 0000000000000001 R15: ffff88006b02cc90 FS: 0000000000000000(0000) GS:ffff88006c800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe4daddf000 CR3: 000000006add6000 CR4: 00000000000006f0 Call Trace: hwarc_neep_init+0x4ce/0x9c0 drivers/uwb/hwa-rc.c:710 uwb_rc_add+0x2fb/0x730 drivers/uwb/lc-rc.c:361 hwarc_probe+0x34e/0x9b0 drivers/uwb/hwa-rc.c:858 usb_probe_interface+0x351/0x8d0 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:385 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 __device_attach+0x269/0x3c0 drivers/base/dd.c:682 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 device_add+0xcf9/0x1640 drivers/base/core.c:1703 usb_set_configuration+0x1064/0x1890 drivers/usb/core/message.c:1932 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266 really_probe drivers/base/dd.c:385 driver_probe_device+0x610/0xa00 drivers/base/dd.c:529 __device_attach_driver+0x230/0x290 drivers/base/dd.c:625 bus_for_each_drv+0x15e/0x210 drivers/base/bus.c:463 __device_attach+0x269/0x3c0 drivers/base/dd.c:682 device_initial_probe+0x1f/0x30 drivers/base/dd.c:729 bus_probe_device+0x1da/0x280 drivers/base/bus.c:523 device_add+0xcf9/0x1640 drivers/base/core.c:1703 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457 hub_port_connect drivers/usb/core/hub.c:4890 hub_port_connect_change drivers/usb/core/hub.c:4996 port_event drivers/usb/core/hub.c:5102 hub_event+0x23c8/0x37c0 drivers/usb/core/hub.c:5182 process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097 worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231 kthread+0x324/0x3f0 kernel/kthread.c:231 ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425 Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 8e 93 07 ff 45 89 e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 a0 e5 55 86 e8 20 08 8f fd <0f> ff e9 9b f7 ff ff e8 4a 04 d6 fd e9 80 f7 ff ff e8 60 11 a6 ---[ end trace 55d741234124cfc3 ]--- Check that endpoint is interrupt. Found by syzkaller. Signed-off-by: Andrey Konovalov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
RobertCNelson
pushed a commit
that referenced
this pull request
Jul 27, 2018
[ Upstream commit 945d015 ] We should put copy_skb in receive_queue only after a successful call to virtio_net_hdr_from_skb(). syzbot report : BUG: KASAN: use-after-free in __skb_unlink include/linux/skbuff.h:1843 [inline] BUG: KASAN: use-after-free in __skb_dequeue include/linux/skbuff.h:1863 [inline] BUG: KASAN: use-after-free in skb_dequeue+0x16a/0x180 net/core/skbuff.c:2815 Read of size 8 at addr ffff8801b044ecc0 by task syz-executor217/4553 CPU: 0 PID: 4553 Comm: syz-executor217 Not tainted 4.18.0-rc1+ #111 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 __skb_unlink include/linux/skbuff.h:1843 [inline] __skb_dequeue include/linux/skbuff.h:1863 [inline] skb_dequeue+0x16a/0x180 net/core/skbuff.c:2815 skb_queue_purge+0x26/0x40 net/core/skbuff.c:2852 packet_set_ring+0x675/0x1da0 net/packet/af_packet.c:4331 packet_release+0x630/0xd90 net/packet/af_packet.c:2991 __sock_release+0xd7/0x260 net/socket.c:603 sock_close+0x19/0x20 net/socket.c:1186 __fput+0x35b/0x8b0 fs/file_table.c:209 ____fput+0x15/0x20 fs/file_table.c:243 task_work_run+0x1ec/0x2a0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1b08/0x2750 kernel/exit.c:865 do_group_exit+0x177/0x440 kernel/exit.c:968 __do_sys_exit_group kernel/exit.c:979 [inline] __se_sys_exit_group kernel/exit.c:977 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4448e9 Code: Bad RIP value. RSP: 002b:00007ffd5f777ca8 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004448e9 RDX: 00000000004448e9 RSI: 000000000000fcfb RDI: 0000000000000001 RBP: 00000000006cf018 R08: 00007ffd0000a45b R09: 0000000000000000 R10: 00007ffd5f777e48 R11: 0000000000000202 R12: 00000000004021f0 R13: 0000000000402280 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 4553: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 skb_clone+0x1f5/0x500 net/core/skbuff.c:1282 tpacket_rcv+0x28f7/0x3200 net/packet/af_packet.c:2221 deliver_skb net/core/dev.c:1925 [inline] deliver_ptype_list_skb net/core/dev.c:1940 [inline] __netif_receive_skb_core+0x1bfb/0x3680 net/core/dev.c:4611 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4693 netif_receive_skb_internal+0x12e/0x7d0 net/core/dev.c:4767 netif_receive_skb+0xbf/0x420 net/core/dev.c:4791 tun_rx_batched.isra.55+0x4ba/0x8c0 drivers/net/tun.c:1571 tun_get_user+0x2af1/0x42f0 drivers/net/tun.c:1981 tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:2009 call_write_iter include/linux/fs.h:1795 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x6c6/0x9f0 fs/read_write.c:487 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 4553: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x86/0x2d0 mm/slab.c:3756 kfree_skbmem+0x154/0x230 net/core/skbuff.c:582 __kfree_skb net/core/skbuff.c:642 [inline] kfree_skb+0x1a5/0x580 net/core/skbuff.c:659 tpacket_rcv+0x189e/0x3200 net/packet/af_packet.c:2385 deliver_skb net/core/dev.c:1925 [inline] deliver_ptype_list_skb net/core/dev.c:1940 [inline] __netif_receive_skb_core+0x1bfb/0x3680 net/core/dev.c:4611 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4693 netif_receive_skb_internal+0x12e/0x7d0 net/core/dev.c:4767 netif_receive_skb+0xbf/0x420 net/core/dev.c:4791 tun_rx_batched.isra.55+0x4ba/0x8c0 drivers/net/tun.c:1571 tun_get_user+0x2af1/0x42f0 drivers/net/tun.c:1981 tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:2009 call_write_iter include/linux/fs.h:1795 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x6c6/0x9f0 fs/read_write.c:487 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8801b044ecc0 which belongs to the cache skbuff_head_cache of size 232 The buggy address is located 0 bytes inside of 232-byte region [ffff8801b044ecc0, ffff8801b044eda8) The buggy address belongs to the page: page:ffffea0006c11380 count:1 mapcount:0 mapping:ffff8801d9be96c0 index:0x0 flags: 0x2fffc0000000100(slab) raw: 02fffc0000000100 ffffea0006c17988 ffff8801d9bec248 ffff8801d9be96c0 raw: 0000000000000000 ffff8801b044e040 000000010000000c 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801b044eb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8801b044ec00: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc >ffff8801b044ec80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8801b044ed00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801b044ed80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc Fixes: 58d19b1 ("packet: vnet_hdr support for tpacket_rcv") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Cc: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
RobertCNelson
pushed a commit
that referenced
this pull request
Oct 22, 2018
[ Upstream commit 945d015 ] We should put copy_skb in receive_queue only after a successful call to virtio_net_hdr_from_skb(). syzbot report : BUG: KASAN: use-after-free in __skb_unlink include/linux/skbuff.h:1843 [inline] BUG: KASAN: use-after-free in __skb_dequeue include/linux/skbuff.h:1863 [inline] BUG: KASAN: use-after-free in skb_dequeue+0x16a/0x180 net/core/skbuff.c:2815 Read of size 8 at addr ffff8801b044ecc0 by task syz-executor217/4553 CPU: 0 PID: 4553 Comm: syz-executor217 Not tainted 4.18.0-rc1+ #111 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 print_address_description+0x6c/0x20b mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433 __skb_unlink include/linux/skbuff.h:1843 [inline] __skb_dequeue include/linux/skbuff.h:1863 [inline] skb_dequeue+0x16a/0x180 net/core/skbuff.c:2815 skb_queue_purge+0x26/0x40 net/core/skbuff.c:2852 packet_set_ring+0x675/0x1da0 net/packet/af_packet.c:4331 packet_release+0x630/0xd90 net/packet/af_packet.c:2991 __sock_release+0xd7/0x260 net/socket.c:603 sock_close+0x19/0x20 net/socket.c:1186 __fput+0x35b/0x8b0 fs/file_table.c:209 ____fput+0x15/0x20 fs/file_table.c:243 task_work_run+0x1ec/0x2a0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x1b08/0x2750 kernel/exit.c:865 do_group_exit+0x177/0x440 kernel/exit.c:968 __do_sys_exit_group kernel/exit.c:979 [inline] __se_sys_exit_group kernel/exit.c:977 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x4448e9 Code: Bad RIP value. RSP: 002b:00007ffd5f777ca8 EFLAGS: 00000202 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00000000004448e9 RDX: 00000000004448e9 RSI: 000000000000fcfb RDI: 0000000000000001 RBP: 00000000006cf018 R08: 00007ffd0000a45b R09: 0000000000000000 R10: 00007ffd5f777e48 R11: 0000000000000202 R12: 00000000004021f0 R13: 0000000000402280 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 4553: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553 kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490 kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554 skb_clone+0x1f5/0x500 net/core/skbuff.c:1282 tpacket_rcv+0x28f7/0x3200 net/packet/af_packet.c:2221 deliver_skb net/core/dev.c:1925 [inline] deliver_ptype_list_skb net/core/dev.c:1940 [inline] __netif_receive_skb_core+0x1bfb/0x3680 net/core/dev.c:4611 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4693 netif_receive_skb_internal+0x12e/0x7d0 net/core/dev.c:4767 netif_receive_skb+0xbf/0x420 net/core/dev.c:4791 tun_rx_batched.isra.55+0x4ba/0x8c0 drivers/net/tun.c:1571 tun_get_user+0x2af1/0x42f0 drivers/net/tun.c:1981 tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:2009 call_write_iter include/linux/fs.h:1795 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x6c6/0x9f0 fs/read_write.c:487 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 4553: save_stack+0x43/0xd0 mm/kasan/kasan.c:448 set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521 kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528 __cache_free mm/slab.c:3498 [inline] kmem_cache_free+0x86/0x2d0 mm/slab.c:3756 kfree_skbmem+0x154/0x230 net/core/skbuff.c:582 __kfree_skb net/core/skbuff.c:642 [inline] kfree_skb+0x1a5/0x580 net/core/skbuff.c:659 tpacket_rcv+0x189e/0x3200 net/packet/af_packet.c:2385 deliver_skb net/core/dev.c:1925 [inline] deliver_ptype_list_skb net/core/dev.c:1940 [inline] __netif_receive_skb_core+0x1bfb/0x3680 net/core/dev.c:4611 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4693 netif_receive_skb_internal+0x12e/0x7d0 net/core/dev.c:4767 netif_receive_skb+0xbf/0x420 net/core/dev.c:4791 tun_rx_batched.isra.55+0x4ba/0x8c0 drivers/net/tun.c:1571 tun_get_user+0x2af1/0x42f0 drivers/net/tun.c:1981 tun_chr_write_iter+0xb9/0x154 drivers/net/tun.c:2009 call_write_iter include/linux/fs.h:1795 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x6c6/0x9f0 fs/read_write.c:487 vfs_write+0x1f8/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8801b044ecc0 which belongs to the cache skbuff_head_cache of size 232 The buggy address is located 0 bytes inside of 232-byte region [ffff8801b044ecc0, ffff8801b044eda8) The buggy address belongs to the page: page:ffffea0006c11380 count:1 mapcount:0 mapping:ffff8801d9be96c0 index:0x0 flags: 0x2fffc0000000100(slab) raw: 02fffc0000000100 ffffea0006c17988 ffff8801d9bec248 ffff8801d9be96c0 raw: 0000000000000000 ffff8801b044e040 000000010000000c 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8801b044eb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8801b044ec00: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc >ffff8801b044ec80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8801b044ed00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8801b044ed80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc Fixes: 58d19b1 ("packet: vnet_hdr support for tpacket_rcv") Signed-off-by: Eric Dumazet <[email protected]> Reported-by: syzbot <[email protected]> Cc: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
RobertCNelson
pushed a commit
that referenced
this pull request
Dec 26, 2018
[ Upstream commit 4fa13db ] In the same spirit of the fix for QXL in commit 8610783 ("drm: qxl: Don't alloc fbdev if emulation is not supported"), prevent the Oops in the unbind path of Bochs if fbdev emulation is disabled. [ 112.176009] Oops: 0002 [#1] SMP [ 112.176009] Modules linked in: bochs_drm [ 112.176009] CPU: 0 PID: 3002 Comm: bash Not tainted 4.11.0-rc1+ #111 [ 112.176009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 [ 112.176009] task: ffff8800743bbac0 task.stack: ffffc90000b5c000 [ 112.176009] RIP: 0010:mutex_lock+0x18/0x30 [ 112.176009] RSP: 0018:ffffc90000b5fc78 EFLAGS: 00010246 [ 112.176009] RAX: 0000000000000000 RBX: 0000000000000260 RCX: 0000000000000000 [ 112.176009] RDX: ffff8800743bbac0 RSI: ffff8800787176e0 RDI: 0000000000000260 [ 112.176009] RBP: ffffc90000b5fc80 R08: ffffffff00000000 R09: 00000000ffffffff [ 112.176009] R10: ffff88007b463650 R11: 0000000000000000 R12: 0000000000000260 [ 112.176009] R13: ffff8800787176e0 R14: ffffffffa0003068 R15: 0000000000000060 [ 112.176009] FS: 00007f20564c7b40(0000) GS:ffff88007ce00000(0000) knlGS:0000000000000000 [ 112.176009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 112.176009] CR2: 0000000000000260 CR3: 000000006b89c000 CR4: 00000000000006f0 [ 112.176009] Call Trace: [ 112.176009] drm_mode_object_unregister+0x1e/0x50 [ 112.176009] drm_framebuffer_unregister_private+0x15/0x20 [ 112.176009] bochs_fbdev_fini+0x57/0x70 [bochs_drm] [ 112.176009] bochs_unload+0x16/0x50 [bochs_drm] [ 112.176009] drm_dev_unregister+0x37/0xd0 [ 112.176009] drm_put_dev+0x31/0x60 [ 112.176009] bochs_pci_remove+0x10/0x20 [bochs_drm] [ 112.176009] pci_device_remove+0x34/0xb0 [ 112.176009] device_release_driver_internal+0x150/0x200 [ 112.176009] device_release_driver+0xd/0x10 [ 112.176009] unbind_store+0x108/0x150 [ 112.176009] drv_attr_store+0x20/0x30 [ 112.176009] sysfs_kf_write+0x32/0x40 [ 112.176009] kernfs_fop_write+0x10b/0x190 [ 112.176009] __vfs_write+0x23/0x120 [ 112.176009] ? security_file_permission+0x36/0xb0 [ 112.176009] ? rw_verify_area+0x49/0xb0 [ 112.176009] vfs_write+0xb0/0x190 [ 112.176009] SyS_write+0x41/0xa0 [ 112.176009] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 112.176009] RIP: 0033:0x7f2055bd5620 [ 112.176009] RSP: 002b:00007ffed2f487d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 112.176009] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2055bd5620 [ 112.176009] RDX: 000000000000000d RSI: 0000000000ee0008 RDI: 0000000000000001 [ 112.176009] RBP: 0000000000000001 R08: 00007f2055e94760 R09: 00007f20564c7b40 [ 112.176009] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000000 [ 112.176009] R13: 00007ffed2f48d70 R14: 0000000000000000 R15: 0000000000000000 [ 112.176009] Code: 00 00 00 55 be 02 00 00 00 48 89 e5 e8 62 fb ff ff 5d c3 55 48 89 e5 53 48 89 fb e8 53 e9 ff ff 65 48 8b 14 25 40 c4 00 00 31 c0 <f0> 48 0f b1 13 48 85 c0 74 08 48 89 df e8c6 ff ff ff 5b 5d c3 [ 112.176009] RIP: mutex_lock+0x18/0x30 RSP: ffffc90000b5fc78 [ 112.176009] CR2: 0000000000000260 [ 112.205622] ---[ end trace 76189cd7a9bdd155 ]--- Signed-off-by: Gabriel Krisman Bertazi <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Gerd Hoffmann <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
RobertCNelson
pushed a commit
that referenced
this pull request
Jan 12, 2022
[ Upstream commit 349d431 ] A crash occurs when smc_cdc_tx_handler() tries to access smc_sock but smc_release() has already freed it. [ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88 [ 4570.696048] #PF: supervisor write access in kernel mode [ 4570.696728] #PF: error_code(0x0002) - not-present page [ 4570.697401] PGD 0 P4D 0 [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <...> [ 4570.711446] Call Trace: [ 4570.711746] <IRQ> [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521] irq_exit_rcu+0xc4/0xf0 [ 4570.714934] common_interrupt+0xba/0xe0 Though smc_cdc_tx_handler() checked the existence of smc connection, smc_release() may have already dismissed and released the smc socket before smc_cdc_tx_handler() further visits it. smc_cdc_tx_handler() |smc_release() if (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock freed bh_lock_sock(&smc->sk) (panic) | To make sure we won't receive any CDC messages after we free the smc_sock, add a refcount on the smc_connection for inflight CDC message(posted to the QP but haven't received related CQE), and don't release the smc_connection until all the inflight CDC messages haven been done, for both success or failed ones. Using refcount on CDC messages brings another problem: when the link is going to be destroyed, smcr_link_clear() will reset the QP, which then remove all the pending CQEs related to the QP in the CQ. To make sure all the CQEs will always come back so the refcount on the smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced by smc_ib_modify_qp_error(). And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we need to wait for all pending WQEs done, or we may encounter use-after- free when handling CQEs. For IB device removal routine, we need to wait for all the QPs on that device been destroyed before we can destroy CQs on the device, or the refcount on smc_connection won't reach 0 and smc_sock cannot be released. Fixes: 5f08318 ("smc: connection data control (CDC)") Reported-by: Wen Gu <[email protected]> Signed-off-by: Dust Li <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
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.
No description provided.