- 28 Aug, 2020 10 commits
-
-
Jérôme Pouiller authored
A binary operator should be followed by exactly one space. Signed-off-by:
Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20200825085828.399505-4-Jerome.Pouiller@silabs.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jérôme Pouiller authored
The protection of the management frames is mainly done by mac80211. However, frames for the management of the BlockAck sessions are directly sent by the device. These frames have to be protected if MFP is in use. So the driver has to pass the MFP configuration to the device. Until now, the driver directly read the RSN IE of the BSS. However, it didn't work when the BSS was MFP capable (ieee80211w=1) and the local device has disabled MFP (ieee80211w=0). This patch read the MFP information directly from the struct ieee80211_sta. This information take into account the MFP negotiated during the association. In addition, the code is far simpler. Signed-off-by:
-
Jérôme Pouiller authored
Until now, hif_map_link() get as argument the raw value for map_link_flags when map_link_flags is defined as a bitfield. It was error prone. Now hif_map_link() takes explicit value for every flags of the struct map_link_flags. Signed-off-by:
-
Jérôme Pouiller authored
The protection of the management frames is mainly done by mac80211. However, frames for the management of the BlockAck sessions are directly sent by the device. These frames have to be protected if MFP is in use. So the driver has to pass the MFP configuration to the device. Until now, the BlockAck management frames were completely unprotected whatever the status of the MFP negotiation. So, some devices dropped these frames. The device has two knobs to control the MFP. One global and one per station. Normally, the driver should always enable global MFP. Then it should enable MFP on every station with which MFP was successfully negotiated. Unfortunately, the older firmwares only provide the global control. So, this patch enable global MFP as it is exposed in the beacon. Then it marks every station with which the MFP is effective. Thus, the support for the old firmwares is not so bad. It may only encounter some difficulties to negotiate BA sessions when the local device (the AP) is MFP capable (ieee80211w=1) but the station is not. The only solution for this case is to upgrade the firmware. Signed-off-by:
-
Steff Richards authored
Indent a number of arguments so that they align with the opening parentheses of the function calls. Issues found by checkpatch. Signed-off-by:
Steff Richards <steff.richards.the.third@gmail.com> Link: https://lore.kernel.org/r/20200824165356.GA5204@steffpadSigned-off-by:
-
Ethan Edwards authored
Fixed various different checkpatch duplicate word warnings, the TODO file said to fix checkpatch warnings. Signed-off-by:
Ethan Edwards <ethancarteredwards@gmail.com> Link: https://lore.kernel.org/r/20200825002955.e3wvtwsoqqbc2cvl@archlaptop.localdomainSigned-off-by:
-
Timo A. Aranjo authored
The word "enought" was changed to read as "enough". In addition to this, there was a missing new-line after varaible declarations within a function. Signed-off-by:
Timo A. Aranjo <timo.aranjo@aol.com> Link: https://lore.kernel.org/r/20200826012101.12162-1-timo.aranjo@aol.comSigned-off-by:
-
Mauro Carvalho Chehab authored
The references inside those files were not assuming that they would end at the staging tree. Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/809bce085b0a9a9ede74d619d160e1e04723709d.1598434228.git.mchehab+huawei@kernel.orgSigned-off-by:
-
Colin Ian King authored
There is a spelling mistake in the MODULE_ALIAS, fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Colin Ian King authored
There are a couple of duplicated "for" spelling mistakes in dev_err error messages. Fix these. Signed-off-by:
-
- 18 Aug, 2020 30 commits
-
-
Mauro Carvalho Chehab authored
The regulator driver needs it, as otherwise it will produce errors when creating vmlinux. Reported-by:
-
Alex Dewar authored
Currently the module can only be test built on ARM, although it seems to build fine on x86. Change this to allow for broader test coverage. Signed-off-by:
Alex Dewar <alex.dewar90@gmail.com> Link: https://lore.kernel.org/r/20200818151133.583382-1-alex.dewar90@gmail.comSigned-off-by:
-
Mauro Carvalho Chehab authored
Add an entry for the SPMI, MFD and PMIC parts of the HiSilicon 6421v600 support. Signed-off-by:
-
Mauro Carvalho Chehab authored
Add documentation for the properties needed by the HiSilicon 6421v600 driver, and by the SPMI controller used to access the chipset. Signed-off-by:
-
Mauro Carvalho Chehab authored
It is clear that this driver is for PMIC. So, get rid of it at the compatible. Signed-off-by:
-
Mauro Carvalho Chehab authored
Add the chipset name at the compatible string, as other HiSilicon chipsets with SPMI bus might require something different. Signed-off-by:
-
Mauro Carvalho Chehab authored
Both irqnum and irqarray properties reflect the same thing: the number of bits and bytes for interrupts at this chipset. E. g.: irqnum = 8 x irqarray This can be seen by the way pending interrupts are handled: /* During probe time */ pmic->irqs = devm_kzalloc(dev, pmic->irqnum * sizeof(int), GFP_KERNEL); /* While handling IRQs */ for (i = 0; i < pmic->irqarray; i++) { pending = hi6421_spmi_pmic_read(pmic, (i + pmic->irq_addr)); pending &= 0xff; for_each_set_bit(offset, &pending, 8) generic_handle_irq(pmic->irqs[offset + i * 8]); } Going further, there are some logic at the driver which assumes that irqarray is 2: /* solve powerkey order */ if ((i == HISI_IRQ_KEY_NUM) && ((pending & HISI_IRQ_KEY_VALUE) == HISI_IRQ_KEY_VALUE)) { generic_handle_irq(pmic->irqs[HISI_IRQ_KEY_DOWN]); generic_handle_irq(pmic->irqs[HISI_IRQ_KEY_UP]); pending &= (~HISI_IRQ_KEY_VALUE); } As HISI_IRQ_KEY_DOWN and HISI_IRQ_KEY_UP are fixed values and don't depend on irqnum/irqarray. The IRQ addr and mask addr seem to be also fixed, based on some comments at the OF parsing code. So, get rid of them too, removing the of parsing function completely. Signed-off-by: -
Mauro Carvalho Chehab authored
Both the SPMI controller and the SPMI PMIC driver depends on the SPMI bus support. The dependency for the regulator is also wrong: it should depends on the SPMI version of the HiSilicon 6421, and not on the normal one. Signed-off-by:
-
Mauro Carvalho Chehab authored
Place the things that are needed to be able to move those drivers out of staging. Signed-off-by:
-
Mauro Carvalho Chehab authored
Do some code cleanup in order to make it cleaner for moving it out of staging in the future. Suggested-by:
Jonathan Cameron <Jonathan.Cameron@Huawei.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Change the binding logic to ensure that the PMIC SPMI driver will run before the regulator code and add it to the building system. Signed-off-by:
-
Mauro Carvalho Chehab authored
Fix the remaining issues complained by checkpatch. Signed-off-by:
-
Mauro Carvalho Chehab authored
Currently, an array is used to store both vsel and enable settings, mixing registers, masks and bit settings. Change it in order to have one separate property for each. This makes easier to understand the contents of the DT file, and to describe it at the Documentation/. Signed-off-by:
-
Mauro Carvalho Chehab authored
Without that, the regulator's core complains with: ldo17: ramp_delay not set For now, use the enable time, as we don't have any datasheets from this device. Signed-off-by: -
Mauro Carvalho Chehab authored
Using dev_dbg() is not too nice, as, instead of printing the name of the regulator, it prints "regulator.<number>", making harder to associate what is happening with each ldo line. So, add a debug-specific macro, which will print the rdev's name, just like the regulator core. Signed-off-by:
-
Mauro Carvalho Chehab authored
The regulator's core already handles it. Signed-off-by:
-
Mauro Carvalho Chehab authored
As the supported LDOs on this driver are all using a selector, change the implementation to use get_voltage_sel and set_voltage_sel ops. Signed-off-by:
-
Mauro Carvalho Chehab authored
Rename the functions used internally inside the driver in order for them to follow the driver's name. While here, get rid of some unused definitions at the header file. Signed-off-by:
-
Mauro Carvalho Chehab authored
Instead of implementing a custom set of properties, set valid_modes_mask based on having or not a mask for enabling the eco_mode. This makes the code clearer, and remove some uneeded props from DT. Signed-off-by:
-
Mauro Carvalho Chehab authored
Simplify the names of the OF properties, in order to make them similar to other drivers and to make easier to understand what each property means. Signed-off-by:
-
Mauro Carvalho Chehab authored
- use dev_foo() instead of pr_foo(); - cleanup the messages, making them more standard and easier to understand. Signed-off-by:
-
Mauro Carvalho Chehab authored
There are several fields on this struct that can be removed, as they already exists at struct regulator_desc. Remove them, cleaning up the code in the process. While here, rename it to hi6421v600_regulator_info, in order to better match the driver's name. Signed-off-by:
-
Mauro Carvalho Chehab authored
Change the binding logic to ensure that the PMIC SPMI driver will run before the regulator code and add it to the building system. Signed-off-by:
-
Mauro Carvalho Chehab authored
There are several issues on those drivers related to their coding style. Solve most of them. Signed-off-by:
-
Mauro Carvalho Chehab authored
The driver was originally written for Kernel 4.9. It needs to be ported to upstream: - Got rid of timeval; - Removed a bogus dependency; - Did cleanups at the header file. Signed-off-by:
-
Mauro Carvalho Chehab authored
Get rid of the sysfs code and other parts of the driver which aren't needed upstream. If needed later, this patch can be (partially?) reversed. Signed-off-by:
-
Mayulong authored
Add the regulator driver for the LDO lines provided by the HiSilicon 6421v600 SPMI PMIC device. [mchehab+huawei@kernel.org: keep just the regulator driver on this patch, renaming it to better fit at upstream namespace] The compete patch is at: https://github.com/96boards-hikey/linux/commit/08464419fba2Signed-off-by:
Mayulong <mayulong1@huawei.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
There are several small cleanups that can be done in order to make the code more prepared to be upstreamed. Suggested-by:
-
Mauro Carvalho Chehab authored
Now that the driver is ready, place it at the build system. Signed-off-by:
-
Mauro Carvalho Chehab authored
Checkpatch complains about some minor issues inside this driver that were not addressed by the previous patch. Address them. Signed-off-by:
-
