atmel-maxtouch #412

dhruvka · 2017-05-15T15:25:11Z

No description provided.

It is not necessary to download these values to the maXTouch chip on every probe, since they are stored in NVRAM. It makes life difficult when tuning the device to keep them in sync with the config array/file, and requires a new kernel build for minor tweaks. These parameters only represent a tiny subset of the available configuration options, tracking all of these options in platform data would be a endless task. In addition, different versions of maXTouch chips may have these values in different places or may not even have them at all. Having these values also makes life more complex for device tree and other platforms where having to define a static configuration isn't helpful. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

* The mapping of the GPIO numbers into the T19 status byte varies between different maXTouch chips. Some have up to 7 GPIOs. Allowing a keycode array of up to 8 items is simpler and more generic. So replace #define with configurable number of keys which also allows the removal of is_tp. * Rename platform data parameters to include "t19" to prevent confusion with T15 key array. * Probe aborts early on when pdata is NULL, so no need to check. * Move "int i" to beginning of function (mixed declarations and code) * Use API calls rather than __set_bit() * Remove unused dev variable. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Yufeng Shen <[email protected]> Reviewed-by: Henrik Rydberg <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

These two object table entry fields are reported 1 less than their value. When used, however, we always want the actual size and instances. To keep the object size and instances 1-byte fields, and thus preserve the object-table struct's 6-byte packed alignment, add some convenient accessor functions that do the +1 every time these fields are accessed. Signed-off-by: Daniel Kurtz <[email protected]> Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

The driver should not immediately read bootloader status when in Application Update Mode. The CHG line will assert when the device has made a state transition and is ready to report a new status via i2c. This change adds a wait for completion in mxt_check_bootloader, and changes the mxt_interrupt handler to signal the completion. Signed-off-by: Benson Leung <[email protected]> Signed-off-by: Daniel Kurtz <[email protected]> Signed-off-by: Nick Dyer <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Rather than msleep for MXT_RESET_TIME and MXT_FWRESET_TIME during the transition to bootloader mode and the transition back from app, wait for the CHG assert to indicate that the transition is done. This change replaces the msleep with a wait for completion that the mxt_interrupt handler signals. Also add CHG poll after last firmware frame - some bootloader versions will assert the interrupt line after the final frame, in testing this meant that the driver attempts to read the info block too early whilst the chip is still resetting. This improves firmware update time as we no longer wait longer than necessary for each reset. Signed-off-by: Benson Leung <[email protected]> Signed-off-by: Daniel Kurtz <[email protected]> Signed-off-by: Nick Dyer <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

…l chips The delay before the chip can be accessed after reset varies between different chips in maXTouch family. Waiting for an interrupt and a T6 status message with the RESET bit set is a better behaviour. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

- Add error messages for probe errors - Report type in invalid object type - Tweak some other debug output messages Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

The configuration is stored in NVRAM on the maXTouch chip. When the device is reset it reports a CRC of the stored configuration values. Therefore it isn't necessary to send the configuration on each probe - we can check the CRC matches and avoid a timeconsuming backup/reset cycle. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

The existing implementation which encodes the configuration as a binary blob in platform data is unsatisfactory since it requires a kernel recompile for the configuration to be changed, and it doesn't deal well with firmware changes that move values around on the chip. Atmel define an ASCII format for the configuration which can be exported from their tools. This patch implements a parser for that format which loads the configuration via the firmware loader and sends it to the MXT chip. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

By validating the checksum, we can identify if the configuration is corrupt. In addition, this patch writes the configuration in a short series of block writes rather than as many individual values. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Move bootloaders reads/writes into separate functions. Instead of switching client->addr, define new field bootloader_addr in mxt_data. Implement lookup calculation for bootloader addresses. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

By implementing a frame counter, print out fewer debug messages (the firmware may contain hundreds of frames). Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Atmel supplies firmware files in ASCII HEX format (.enc) which must be converted before they can be loaded by kernel driver. Try to detect the error and print a friendly error message rather than feeding junk to the bootloader. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

By reading the touchscreen configuration from the settings that the maXTouch chip is actually using, we can remove some platform data. The matrix size is not used for anything, and results in some rather confusing code to re-read it because it may change when configuration is downloaded, so don't print it out. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

By writing zero to both the active and idle cycle times the maXTouch device is put into a deep sleep mode when it consumes minimal power. It is unnecessary to change the configuration of any other objects (for example to disable T9 touchscreen). It is counterproductive to reset the chip on resume, it will result in a long delay. However it is necessary to issue a calibrate command after the chip has spent any time in deep sleep. This patch also deals with the situation where the power configuration is zero on probe, which would mean that the device never wakes up to execute commands. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

This avoids confusion with the newer T100 touchscreen object. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Signed-off-by: Nick Dyer <[email protected]>

The maXTouch chips use the CHG line to generate status events in bootloader mode, and during configuration download, before there is enough information to configure the input device. Therefore set up the interrupt handler earlier. However, this introduces states where parts of the interrupt processing must not run. Use data->object_table as a way to tell whether the chip information is valid, and data->input_dev as a way to tell whether it is valid to generate input report. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]>

It is possible for the maXTouch chip to start up in bootloader mode, where it does not have a working touchscreen but the driver can still handle updating the firmware. This means that the touchscreen initialisation must be split into a separate function so it can be called after bootloading has completed. In addition, later devices have a different touchscreen object (T100) which requires handling differently. This also reduces the complexity of the probe function. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Yufeng Shen <[email protected]>

If the bootloader fails to start the appmode image on the touch controller, it stays in bootloader mode. It is possible to reflash a working firmware image from this state. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]>

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]>

Later chips (for example mXT1664S) different mappings for bootloader addresses. This means that we must look at the family ID to determine which address to use. There is an additional complication: when we probe and we don't know the family ID yet, we need to try both possible addresses to find the bootloader. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]>

The MXT device may be in bootloader mode on probe, due to: 1) APP CRC failure, either: a) flash corruption b) bad power or other intermittent problem while checking CRC 2) If the device has been reset 10 or more times without accessing comms 3) Warm probe, device was in bootloader mode already This code attempts to recover from 1(b) and 3. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Yufeng Shen <[email protected]>

The T5 object may have various sizes depending on the objects used on the particular maXTouch chip and firmware version, therefore it can't be hardcoded in the driver. Allocate a buffer on probe instead. Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]>

On some platforms doing i2c reads of more than 255 bytes is problematic. For exampls, some chips with lots of objects have an info block larger than 255 bytes. Signed-off-by: Steven Swann <[email protected]> Signed-off-by: Nick Dyer <[email protected]>

Signed-off-by: Nick Dyer <[email protected]>

Move the initialisation of sysfs attributes. Some of the sysfs functions have guards in case they are accessed early during probe, or during firmware flash. By ensuring the attributes are not present when they can be mis-used, these guards can be removed.

TKT-010987 Release Oct 2015 driver changes to github

Signed-off-by: Nick Dyer <[email protected]>

…device() Signed-off-by: Nick Dyer <[email protected]>

Signed-off-by: Nick Dyer <[email protected]>

Updates to maxtouch-v3.14 driver

Signed-off-by: Nick Dyer <[email protected]>

Both T100 and T9 handle range and orientation in a similar fashion. Reduce duplication between the two implementations. Signed-off-by: Nick Dyer <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

The Atmel maxtouch DT binding documents that the compatible string for the device is "atmel,maxtouch" and the I2C core always reports a module alias of the form i2c:alias where alias is the compatible string model: $ grep MODALIAS /sys/devices/platform/12e00000.i2c/i2c-8/8-004b/uevent MODALIAS=i2c:maxtouch But there isn't maxtouch entry in the I2C device ID table so when the i2c:maxtouch MODALIAS uevent is reported, kmod is not able to match the alias with a module to load: $ modinfo atmel_mxt_ts | grep alias alias: of:N*T*Catmel,maxtouch alias: i2c:mXT224 alias: i2c:atmel_mxt_tp alias: i2c:atmel_mxt_ts alias: i2c:qt602240_ts So add the maxtouch entry to the I2C device ID table to allow the module to be autoloaded when the device is registered via OF. Signed-off-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Nick Dyer <[email protected]>

Apparently people are installing generic Linux distributions not only on Pixels but also on other Chromebooks. Unfortunately on all of them Atmel parts assigned names ATML0000 and ATML0001, and do not carry any other configuration data. So let's create generic instance of platform data that should cover most of them (we assume that they will not be using T100 objects, since with those Google mapped BTN_LEFT onto a different GPIO, so slightly different keymap would be needed, but I think we used parts with T100 on ARM devices where we thankfully have DTS and can describe the devices better). Tested-by: Rich K <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Nick Dyer <[email protected]>

Signed-off-by: Nick Dyer <[email protected]>

We use sscanf to parse the configuration file, so it's necessary to zero terminate the configuration otherwise a truncated file can cause the parser to run off into uninitialised memory. Signed-off-by: Nick Dyer <[email protected]>

Maxtouch v3.14 updates

KernelPRBot · 2017-05-15T15:30:09Z

Hi @dhruvka!

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:

Format your contribution according to kernel requirements
Decide who to send your contribution to
Set up your system to send your contribution as an email
Send your contribution and wait for feedback

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 git format-patch.

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 get_maintainer.pl script in the kernel source can help you.

get_maintainer.pl will take the patch or patches you created in the previous step, and tell you who is responsible for them, and what mailing lists are used. You can also take a look at the MAINTAINERS file by hand.

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 git send-email, which will ensure that your patches are formatted in the standard manner. In order to use git send-email, you'll need to configure git to use your SMTP email server.

For more information about using git send-email, look at the Git documentation or type git help send-email. There are a number of useful guides and tutorials about git send-email that can be found on the internet.

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:

Kernel Newbies - this website contains a lot of useful resources for new kernel developers.
If you'd like a step-by-step, challenge-based introduction to kernel development, the Eudyptula Challenge would be an excellent start.
The kernel documentation - see also the Documentation directory in the kernel tree.

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:

You might get a response to your email. Often these will be comments, which may require you to make changes to your patch, or explain why your way is the best way. You should respond to these comments, and you may need to submit another revision of your patch to address the issues raised.
Your patch might be merged into the subsystem tree. Code that becomes part of Linux isn't merged into the main repository straight away - it first goes into the subsystem tree, which is managed by the subsystem maintainer. It is then batched up with a number of other changes sent to Linus for inclusion. (This process is described in some detail in the kernel development process guide).
Your patch might be ignored completely. This happens sometimes - don't take it personally. Here's what to do:
- Wait a bit more - patches often take several weeks to get a response; more if they were sent at a busy time.
- Kernel developers often silently ignore patches that break the rules. Check for obvious violations of the the Submitting Patches guidelines, the style guidelines, and any other documentation you can find about your subsystem. Check that you're sending your patch to the right place.
- Try again later. When you resend it, don't add angry commentary, as that will get your patch ignored. It might also get you silently blacklisted.

Further information

Working with the kernel development community - the official documentation for new kernel contributors

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.

The 0day kbuild robot reports following crash: BUG: unable to handle kernel NULL pointer dereference at 00000004 IP: tb_property_find+0xe/0x41 *pde = 00000000 Oops: 0000 [#1] CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.0-rc1-00741-ge69b6c0 torvalds#412 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014 task: 89c80000 task.stack: 89c7c000 EIP: tb_property_find+0xe/0x41 EFLAGS: 00210246 CPU: 0 EAX: 00000000 EBX: 7a368f47 ECX: 00000044 EDX: 7a368f47 ESI: 8851d340 EDI: 7a368f47 EBP: 89c7df0c ESP: 89c7defc DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 80050033 CR2: 00000004 CR3: 027a2000 CR4: 00000690 Call Trace: tb_register_property_dir+0x49/0xb9 ? cdc_mbim_driver_init+0x1b/0x1b tbnet_init+0x77/0x9f ? cdc_mbim_driver_init+0x1b/0x1b do_one_initcall+0x7e/0x145 ? parse_args+0x10c/0x1b3 ? kernel_init_freeable+0xbe/0x159 kernel_init_freeable+0xd1/0x159 ? rest_init+0x110/0x110 kernel_init+0xd/0xd0 ret_from_fork+0x19/0x30 The reason is that both Thunderbolt bus and thunderbolt-net are build into the kernel image, and the latter is linked first because drivers/net comes before drivers/thunderbolt. Since both use module_init() thunderbolt-net ends up calling Thunderbolt bus functions too early triggering the above crash. Fix this by moving Thunderbolt bus initialization to happen earlier to make sure all the data structures are ready when Thunderbolt service drivers are initialized. To be on the safe side also add a check for properly initialized xdomain_property_dir to tb_register_property_dir(). Reported-by: kernel test robot <[email protected]> Signed-off-by: Mika Westerberg <[email protected]> Signed-off-by: David S. Miller <[email protected]>

lkl: fix missing package linux-headers*.deb for dpdk build

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#47: FILE: hal/HalBtcOutSrc.h:47: +typedef enum _BTC_POWERSAVE_TYPE { WARNING: do not add new typedefs torvalds#54: FILE: hal/HalBtcOutSrc.h:54: +typedef enum _BTC_BT_REG_TYPE { WARNING: do not add new typedefs torvalds#63: FILE: hal/HalBtcOutSrc.h:63: +typedef enum _BTC_CHIP_INTERFACE { WARNING: do not add new typedefs torvalds#71: FILE: hal/HalBtcOutSrc.h:71: +typedef enum _BTC_CHIP_TYPE { WARNING: do not add new typedefs torvalds#81: FILE: hal/HalBtcOutSrc.h:81: +typedef enum _BTC_MSG_TYPE { WARNING: do not add new typedefs torvalds#167: FILE: hal/HalBtcOutSrc.h:167: +typedef struct _BTC_BOARD_INFO { WARNING: do not add new typedefs torvalds#177: FILE: hal/HalBtcOutSrc.h:177: +typedef enum _BTC_DBG_OPCODE { WARNING: do not add new typedefs torvalds#187: FILE: hal/HalBtcOutSrc.h:187: +typedef enum _BTC_RSSI_STATE { WARNING: do not add new typedefs torvalds#200: FILE: hal/HalBtcOutSrc.h:200: +typedef enum _BTC_WIFI_ROLE { WARNING: do not add new typedefs torvalds#208: FILE: hal/HalBtcOutSrc.h:208: +typedef enum _BTC_WIFI_BW_MODE { WARNING: do not add new typedefs torvalds#215: FILE: hal/HalBtcOutSrc.h:215: +typedef enum _BTC_WIFI_TRAFFIC_DIR { WARNING: do not add new typedefs torvalds#221: FILE: hal/HalBtcOutSrc.h:221: +typedef enum _BTC_WIFI_PNP { WARNING: do not add new typedefs torvalds#228: FILE: hal/HalBtcOutSrc.h:228: +typedef enum _BT_WIFI_COEX_STATE { WARNING: do not add new typedefs torvalds#239: FILE: hal/HalBtcOutSrc.h:239: +typedef enum _BTC_GET_TYPE { WARNING: do not add new typedefs torvalds#281: FILE: hal/HalBtcOutSrc.h:281: +typedef enum _BTC_SET_TYPE { WARNING: do not add new typedefs torvalds#321: FILE: hal/HalBtcOutSrc.h:321: +typedef enum _BTC_DBG_DISP_TYPE { WARNING: do not add new typedefs torvalds#328: FILE: hal/HalBtcOutSrc.h:328: +typedef enum _BTC_NOTIFY_TYPE_IPS { WARNING: do not add new typedefs torvalds#334: FILE: hal/HalBtcOutSrc.h:334: +typedef enum _BTC_NOTIFY_TYPE_LPS { WARNING: do not add new typedefs torvalds#340: FILE: hal/HalBtcOutSrc.h:340: +typedef enum _BTC_NOTIFY_TYPE_SCAN { WARNING: do not add new typedefs torvalds#346: FILE: hal/HalBtcOutSrc.h:346: +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE { WARNING: do not add new typedefs torvalds#352: FILE: hal/HalBtcOutSrc.h:352: +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS { WARNING: do not add new typedefs torvalds#358: FILE: hal/HalBtcOutSrc.h:358: +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET { WARNING: do not add new typedefs torvalds#366: FILE: hal/HalBtcOutSrc.h:366: +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION { WARNING: do not add new typedefs torvalds#374: FILE: hal/HalBtcOutSrc.h:374: +typedef enum _BTC_ANTENNA_POS { WARNING: do not add new typedefs torvalds#412: FILE: hal/HalBtcOutSrc.h:412: +typedef struct _BTC_BT_INFO { WARNING: do not add new typedefs torvalds#440: FILE: hal/HalBtcOutSrc.h:440: +typedef struct _BTC_STACK_INFO { WARNING: do not add new typedefs torvalds#455: FILE: hal/HalBtcOutSrc.h:455: +typedef struct _BTC_BT_LINK_INFO { WARNING: do not add new typedefs torvalds#468: FILE: hal/HalBtcOutSrc.h:468: +typedef struct _BTC_STATISTICS { WARNING: do not add new typedefs torvalds#487: FILE: hal/HalBtcOutSrc.h:487: +typedef struct _BTC_COEXIST { Signed-off-by: Marco Cesati <[email protected]>

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#47: FILE: hal/HalBtcOutSrc.h:47: +typedef enum _BTC_POWERSAVE_TYPE { WARNING: do not add new typedefs torvalds#54: FILE: hal/HalBtcOutSrc.h:54: +typedef enum _BTC_BT_REG_TYPE { WARNING: do not add new typedefs torvalds#63: FILE: hal/HalBtcOutSrc.h:63: +typedef enum _BTC_CHIP_INTERFACE { WARNING: do not add new typedefs torvalds#71: FILE: hal/HalBtcOutSrc.h:71: +typedef enum _BTC_CHIP_TYPE { WARNING: do not add new typedefs torvalds#81: FILE: hal/HalBtcOutSrc.h:81: +typedef enum _BTC_MSG_TYPE { WARNING: do not add new typedefs torvalds#167: FILE: hal/HalBtcOutSrc.h:167: +typedef struct _BTC_BOARD_INFO { WARNING: do not add new typedefs torvalds#177: FILE: hal/HalBtcOutSrc.h:177: +typedef enum _BTC_DBG_OPCODE { WARNING: do not add new typedefs torvalds#187: FILE: hal/HalBtcOutSrc.h:187: +typedef enum _BTC_RSSI_STATE { WARNING: do not add new typedefs torvalds#200: FILE: hal/HalBtcOutSrc.h:200: +typedef enum _BTC_WIFI_ROLE { WARNING: do not add new typedefs torvalds#208: FILE: hal/HalBtcOutSrc.h:208: +typedef enum _BTC_WIFI_BW_MODE { WARNING: do not add new typedefs torvalds#215: FILE: hal/HalBtcOutSrc.h:215: +typedef enum _BTC_WIFI_TRAFFIC_DIR { WARNING: do not add new typedefs torvalds#221: FILE: hal/HalBtcOutSrc.h:221: +typedef enum _BTC_WIFI_PNP { WARNING: do not add new typedefs torvalds#228: FILE: hal/HalBtcOutSrc.h:228: +typedef enum _BT_WIFI_COEX_STATE { WARNING: do not add new typedefs torvalds#239: FILE: hal/HalBtcOutSrc.h:239: +typedef enum _BTC_GET_TYPE { WARNING: do not add new typedefs torvalds#281: FILE: hal/HalBtcOutSrc.h:281: +typedef enum _BTC_SET_TYPE { WARNING: do not add new typedefs torvalds#321: FILE: hal/HalBtcOutSrc.h:321: +typedef enum _BTC_DBG_DISP_TYPE { WARNING: do not add new typedefs torvalds#328: FILE: hal/HalBtcOutSrc.h:328: +typedef enum _BTC_NOTIFY_TYPE_IPS { WARNING: do not add new typedefs torvalds#334: FILE: hal/HalBtcOutSrc.h:334: +typedef enum _BTC_NOTIFY_TYPE_LPS { WARNING: do not add new typedefs torvalds#340: FILE: hal/HalBtcOutSrc.h:340: +typedef enum _BTC_NOTIFY_TYPE_SCAN { WARNING: do not add new typedefs torvalds#346: FILE: hal/HalBtcOutSrc.h:346: +typedef enum _BTC_NOTIFY_TYPE_ASSOCIATE { WARNING: do not add new typedefs torvalds#352: FILE: hal/HalBtcOutSrc.h:352: +typedef enum _BTC_NOTIFY_TYPE_MEDIA_STATUS { WARNING: do not add new typedefs torvalds#358: FILE: hal/HalBtcOutSrc.h:358: +typedef enum _BTC_NOTIFY_TYPE_SPECIAL_PACKET { WARNING: do not add new typedefs torvalds#366: FILE: hal/HalBtcOutSrc.h:366: +typedef enum _BTC_NOTIFY_TYPE_STACK_OPERATION { WARNING: do not add new typedefs torvalds#374: FILE: hal/HalBtcOutSrc.h:374: +typedef enum _BTC_ANTENNA_POS { WARNING: do not add new typedefs torvalds#412: FILE: hal/HalBtcOutSrc.h:412: +typedef struct _BTC_BT_INFO { WARNING: do not add new typedefs torvalds#440: FILE: hal/HalBtcOutSrc.h:440: +typedef struct _BTC_STACK_INFO { WARNING: do not add new typedefs torvalds#455: FILE: hal/HalBtcOutSrc.h:455: +typedef struct _BTC_BT_LINK_INFO { WARNING: do not add new typedefs torvalds#468: FILE: hal/HalBtcOutSrc.h:468: +typedef struct _BTC_STATISTICS { WARNING: do not add new typedefs torvalds#487: FILE: hal/HalBtcOutSrc.h:487: +typedef struct _BTC_COEXIST { Signed-off-by: Marco Cesati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#57: FILE: ./hal/HalPhyRf_8723B.c:57: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#138: FILE: ./hal/HalPhyRf_8723B.c:138: +static void setCCKFilterCoefficient(struct DM_ODM_T * pDM_Odm, u8 CCKSwingIndex) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#162: FILE: ./hal/HalPhyRf_8723B.c:162: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#188: FILE: ./hal/HalPhyRf_8723B.c:188: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#363: FILE: ./hal/HalPhyRf_8723B.c:363: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#371: FILE: ./hal/HalPhyRf_8723B.c:371: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#412: FILE: ./hal/HalPhyRf_8723B.c:412: +void ConfigureTxpowerTrack_8723B(struct TXPWRTRACK_CFG * pConfig) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#440: FILE: ./hal/HalPhyRf_8723B.c:440: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#551: FILE: ./hal/HalPhyRf_8723B.c:551: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#765: FILE: ./hal/HalPhyRf_8723B.c:765: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#872: FILE: ./hal/HalPhyRf_8723B.c:872: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1095: FILE: ./hal/HalPhyRf_8723B.c:1095: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1097: FILE: ./hal/HalPhyRf_8723B.c:1097: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1175: FILE: ./hal/HalPhyRf_8723B.c:1175: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1177: FILE: ./hal/HalPhyRf_8723B.c:1177: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1250: FILE: ./hal/HalPhyRf_8723B.c:1250: +void ODM_SetIQCbyRFpath(struct DM_ODM_T * pDM_Odm, u32 RFpath) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1253: FILE: ./hal/HalPhyRf_8723B.c:1253: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1295: FILE: ./hal/HalPhyRf_8723B.c:1295: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1313: FILE: ./hal/HalPhyRf_8723B.c:1313: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1333: FILE: ./hal/HalPhyRf_8723B.c:1333: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1363: FILE: ./hal/HalPhyRf_8723B.c:1363: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1387: FILE: ./hal/HalPhyRf_8723B.c:1387: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1492: FILE: ./hal/HalPhyRf_8723B.c:1492: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1700: FILE: ./hal/HalPhyRf_8723B.c:1700: +static void phy_LCCalibrate_8723B(struct DM_ODM_T * pDM_Odm, bool is2T) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1787: FILE: ./hal/HalPhyRf_8723B.c:1787: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1833: FILE: ./hal/HalPhyRf_8723B.c:1833: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2041: FILE: ./hal/HalPhyRf_8723B.c:2041: +void PHY_LCCalibrate_8723B(struct DM_ODM_T * pDM_Odm) Signed-off-by: Marco Cesati <[email protected]>

This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#57: FILE: ./hal/HalPhyRf_8723B.c:57: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#138: FILE: ./hal/HalPhyRf_8723B.c:138: +static void setCCKFilterCoefficient(struct DM_ODM_T * pDM_Odm, u8 CCKSwingIndex) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#162: FILE: ./hal/HalPhyRf_8723B.c:162: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#188: FILE: ./hal/HalPhyRf_8723B.c:188: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#363: FILE: ./hal/HalPhyRf_8723B.c:363: + struct DM_ODM_T * pDM_Odm, ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#371: FILE: ./hal/HalPhyRf_8723B.c:371: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#412: FILE: ./hal/HalPhyRf_8723B.c:412: +void ConfigureTxpowerTrack_8723B(struct TXPWRTRACK_CFG * pConfig) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#440: FILE: ./hal/HalPhyRf_8723B.c:440: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#551: FILE: ./hal/HalPhyRf_8723B.c:551: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#765: FILE: ./hal/HalPhyRf_8723B.c:765: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#872: FILE: ./hal/HalPhyRf_8723B.c:872: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1095: FILE: ./hal/HalPhyRf_8723B.c:1095: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1097: FILE: ./hal/HalPhyRf_8723B.c:1097: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1175: FILE: ./hal/HalPhyRf_8723B.c:1175: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1177: FILE: ./hal/HalPhyRf_8723B.c:1177: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1250: FILE: ./hal/HalPhyRf_8723B.c:1250: +void ODM_SetIQCbyRFpath(struct DM_ODM_T * pDM_Odm, u32 RFpath) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1253: FILE: ./hal/HalPhyRf_8723B.c:1253: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1295: FILE: ./hal/HalPhyRf_8723B.c:1295: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1313: FILE: ./hal/HalPhyRf_8723B.c:1313: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1333: FILE: ./hal/HalPhyRf_8723B.c:1333: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1363: FILE: ./hal/HalPhyRf_8723B.c:1363: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1387: FILE: ./hal/HalPhyRf_8723B.c:1387: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1492: FILE: ./hal/HalPhyRf_8723B.c:1492: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1700: FILE: ./hal/HalPhyRf_8723B.c:1700: +static void phy_LCCalibrate_8723B(struct DM_ODM_T * pDM_Odm, bool is2T) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1787: FILE: ./hal/HalPhyRf_8723B.c:1787: + struct DM_ODM_T * pDM_Odm = &pHalData->odmpriv; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1833: FILE: ./hal/HalPhyRf_8723B.c:1833: + struct ODM_RF_CAL_T * pRFCalibrateInfo = &(pDM_Odm->RFCalibrateInfo); ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #2041: FILE: ./hal/HalPhyRf_8723B.c:2041: +void PHY_LCCalibrate_8723B(struct DM_ODM_T * pDM_Odm) Reviewed-by: Dan Carpenter <[email protected]> Signed-off-by: Marco Cesati <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>

rust: kernel: clean `rustdoc` warnings

ndyer and others added 30 commits May 23, 2014 16:03

Input: atmel_mxt_ts - return IRQ_NONE when interrupt handler fails

ffcc8c3

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Input: atmel_mxt_ts - select FW_LOADER for firmware code

98db726

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Input: atmel_mxt_ts - read and report bootloader version

70d9ee8

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Input: atmel_mxt_ts - implement bootloader frame retries

3a2ce18

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Input: atmel_mxt_ts - rename pressure to amplitude to match spec

8c5211f

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Input: atmel_mxt_ts - handle multiple input reports in one message

7b56b3e

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Input: atmel_mxt_ts - add Atmel copyright line

b223f50

Signed-off-by: Nick Dyer <[email protected]>

Input: atmel_mxt_ts - handle bootloader previously unlocked

9b52bc4

Signed-off-by: Nick Dyer <[email protected]> Acked-by: Benson Leung <[email protected]> Acked-by: Yufeng Shen <[email protected]>

ndyer and others added 22 commits October 29, 2015 12:33

Input: atmel_mxt_ts - Add debug for T92 gesture and T93 touch seq msgs

35b9ed6

Signed-off-by: Nick Dyer <[email protected]>

Input: atmel_mxt_ts - avoid null regulator handle

03bd7e7

Signed-off-by: Nick Dyer <[email protected]>

Input: atmel_mxt_ts - rename config_csum attribute to config_crc

57af0f6

Signed-off-by: Nick Dyer <[email protected]>

Merge pull request #10 from ndyer/maxtouch-v3.14

37ce0c5

TKT-010987 Release Oct 2015 driver changes to github

Input: atmel_mxt_ts - fix bug with entering bootloader

b63e03a

Signed-off-by: Nick Dyer <[email protected]>

Input: atmel_mxt_ts - remove duplicated code in mxt_initialize_input_…

586fec6

…device() Signed-off-by: Nick Dyer <[email protected]>

Input: atmel_mxt_ts - remove support for old T63 active stylus

9541c60

Signed-off-by: Nick Dyer <[email protected]>

Input: atmel_mxt_ts - don't register T107 stylus reports unless enabled

ecfe5ef

Signed-off-by: Nick Dyer <[email protected]>

Merge pull request #12 from ndyer/maxtouch-v3.14

7d452f7

Updates to maxtouch-v3.14 driver

Input: atmel_mxt_ts - fix warning in mxt_set_up_active_stylus

49bba71

Signed-off-by: Nick Dyer <[email protected]>

Input: atmel_mxt_ts - improve touchscreen size/orientation handling

c03ddbc

Both T100 and T9 handle range and orientation in a similar fashion. Reduce duplication between the two implementations. Signed-off-by: Nick Dyer <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>

Input: atmel_mxt_ts - use min() macro

f371bc4

Input: atmel_mxt_ts - remove debug msg in correct places

f1804f1

Input: atmel_mxt_ts - remove some blank lines

11a72ee

Input: atmel_mxt_ts - create fw attr before mxt_initialize

90ddd8b

Input: atmel_mxt_ts - refactor config update code to add context struct

f83c9bb

Signed-off-by: Nick Dyer <[email protected]>

Merge pull request #13 from ndyer/maxtouch-v3.14

72c0333

Maxtouch v3.14 updates

Mic92 pushed a commit to Mic92/linux that referenced this pull request Feb 4, 2019

Merge pull request torvalds#412 from libos-nuse/fix-dpdk-build

c415552

lkl: fix missing package linux-headers*.deb for dpdk build

ojeda added a commit to ojeda/linux that referenced this pull request Jul 2, 2021

Merge pull request torvalds#412 from ojeda/fix-doc-warn

fc4c293

rust: kernel: clean `rustdoc` warnings

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

atmel-maxtouch #412

atmel-maxtouch #412

dhruvka commented May 15, 2017

KernelPRBot commented May 15, 2017

atmel-maxtouch #412

Are you sure you want to change the base?

atmel-maxtouch #412

Conversation

dhruvka commented May 15, 2017

KernelPRBot commented May 15, 2017

How do I format my contribution?

Who do I send my contribution to?

How do I send my contribution?

How do I get help if I'm stuck?

I sent my patch - now what?

Further information