Re: [PATCH v6 0/2] memory: Introduce ti-emif-sram driver
On 11/30/17 2:56 PM, Dave Gerlach wrote:
This is a resend of v5 of this series found here [1]. It introduces
relocatable PM handlers for the emif that are copied to sram and
run from there during low power mode entry.
The patches still have the previous ACKs but have a small change to
accomodate a change made by Tony in commit cd57dc5a2099 ("ARM: dts:
Add missing hwmod related nodes for am33xx"). If there are objections
to this let me know ASAP.
Now that a hwmod is present for the am335x EMIF, on probe fail the call to
pm_runtime_put_sync causes the board to hang. In fact, this emif driver should
never alter the PM state of the hardware at all through normal kernel calls, it
is the job of the suspend handlers that are added, that is the whole point of
this driver. Because of this, I have dropped all runtime pm calls, as any
change to the PM state while the kernel is running is dangerous as we may shut
of the memory controller. It makes the most sense just to drop runtime PM from
the driver entirely. Besides that patch is unchanged.
This code is required for low-power modes to work on AM335x and AM437x and a
forthcoming PM series for those platforms will depend on this series. After
both this and the PM series are reviewed I will send the necessary device tree
changes for both, but in the meantime all remaining patches for am335x and
am437x PM can be found here [2].
Applied
Re: [PATCH 0/6] 66AK2G: Add DT nodes for few peripherals
On 11/22/17 11:51 PM, Vignesh R wrote: This patch series adds DT nodes for bunch of peripherials on 66AK2G EVM and 66AK2G ICE boards. Tested on 66AK2G EVM and ICE boards Vignesh R (6): ARM: dts: keystone-k2g: Add QSPI DT entry ARM: dts: keystone-k2g-evm: Fix botched up merge ARM: dts: keystone-k2g: Move ti,non-removable property to board dts ARM: dts: keystone-k2g-evm: Add QSPI DT node. ARM: dts: keystone-k2g-ice: Add DT nodes for few peripherals ARM: configs: keystone_defconfig: Enable few peripheral drivers Series applied. Please submit the follow up patch for multi-v7 config. Regards, Santosh
Re: [RESEND PATCH 2/4] ARM: dts: keystone: Add generic compatible string for I2C EEPROM
On 11/24/17 8:27 AM, Javier Martinez Canillas wrote: The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken into account so the driver defines only a set of compatible strings using the "atmel" vendor as a generic fallback for compatible I2C devices. So add this generic fallback to the device node compatible string to make the device to match the driver using the OF device ID table. Signed-off-by: Javier Martinez Canillas --- Applied
Re: [PATCH] Staging: pi433: fix brace coding style issues in pi433_if.c
On 12/02/2017 10:50 PM, Joe Perches wrote:
> On Sat, 2017-12-02 at 22:05 +0100, Tomas Marek wrote:
>> This patch fix several brace on next line, braces not necessary, space
>> around =/<, and space before/after open/close parenthesis coding style
>> errors find by checkpatch in pi433_if.c.
>>
>> Signed-off-by: Tomas Marek
>> ---
>> drivers/staging/pi433/pi433_if.c | 130
>> ---
>> 1 file changed, 40 insertions(+), 90 deletions(-)
>>
>> diff --git a/drivers/staging/pi433/pi433_if.c
>> b/drivers/staging/pi433/pi433_if.c
>> index 2a205c6..795ae36 100644
>> --- a/drivers/staging/pi433/pi433_if.c
>> +++ b/drivers/staging/pi433/pi433_if.c
>> @@ -133,19 +133,14 @@ static irqreturn_t DIO0_irq_handler(int irq, void
>> *dev_id)
>> {
>> struct pi433_device *device = dev_id;
>>
>> -if (device->irq_state[DIO0] == DIO_PacketSent)
>> -{
>> +if (device->irq_state[DIO0] == DIO_PacketSent) {
>> device->free_in_fifo = FIFO_SIZE;
>> dev_dbg(device->dev, "DIO0 irq: Packet sent\n");
>> wake_up_interruptible(&device->fifo_wait_queue);
>> -}
>> -else if (device->irq_state[DIO0] == DIO_Rssi_DIO0)
>> -{
>> +} else if (device->irq_state[DIO0] == DIO_Rssi_DIO0) {
>> dev_dbg(device->dev, "DIO0 irq: RSSI level over threshold\n");
>> wake_up_interruptible(&device->rx_wait_queue);
>> -}
>> -else if (device->irq_state[DIO0] == DIO_PayloadReady)
>> -{
>> +} else if (device->irq_state[DIO0] == DIO_PayloadReady) {
>> dev_dbg(device->dev, "DIO0 irq: PayloadReady\n");
>> device->free_in_fifo = 0;
>> wake_up_interruptible(&device->fifo_wait_queue);
> I suggest using a switch/case and presumably the
> dev_dbg should be dev_dbg_ratelimited.
>
> Perhaps:
>
> {
> const char *msg = NULL;
> struct wait_queue_head *wqh;
>
> switch (device->irq_state[DIO0]) {
> case DIO_PacketSent:
> device_free_in_fifo = FIFO_SIZE;
> wqh = &device->fifo_wait_queue;
> msg = "Packet sent";
> break;
> case DIO_PayloadReady:
> device_free_in_fifo = 0;
> wqh = &device->fifo_wait_queue;
> msg = "PayloadReady";
> break;
> case DIO_Rssi_DIO0:
> wqh = &device->rx_wait_queue;
> msg = "RSSI level over
> threshold";
> break;
> }
>
> if (msg) {
> dev_dbg_ratelimited(device->dev, "DIO0 irq: %s\n", msg);
> wake_up_interruptible(whq);
> }
>
> return IRQ_HANDLED;
> }
Thanks for the input. Initially, I plan just a simple fix of errors reported by
checkpatch to get familiar with patch submit procedure. Anyway, proposed change
seems to be reasonable and I will try to implement it (and take advantage to
send also v2 patch).
Would you like to be noted in v2 as suggested-by?
v2 coming up soon
Thank you again
Tomas
>
>> @@ -158,12 +153,9 @@ static irqreturn_t DIO1_irq_handler(int irq, void
>> *dev_id)
>> {
>> struct pi433_device *device = dev_id;
>>
>> -if (device->irq_state[DIO1] == DIO_FifoNotEmpty_DIO1)
>> -{
>> +if (device->irq_state[DIO1] == DIO_FifoNotEmpty_DIO1) {
>> device->free_in_fifo = FIFO_SIZE;
>> -}
>> -else if (device->irq_state[DIO1] == DIO_FifoLevel)
>> -{
>> +} else if (device->irq_state[DIO1] == DIO_FifoLevel) {
>> if (device->rx_active) device->free_in_fifo = FIFO_THRESHOLD -
>> 1;
>> elsedevice->free_in_fifo = FIFO_SIZE -
>> FIFO_THRESHOLD - 1;
>> }
>> @@ -198,12 +190,9 @@ static irqreturn_t DIO1_irq_handler(int irq, void
>> *dev_id)
>> /* packet config */
>> /* enable */
>> SET_CHECKED(rf69_set_sync_enable(dev->spi, rx_cfg->enable_sync));
>> -if (rx_cfg->enable_sync == optionOn)
>> -{
>> +if (rx_cfg->enable_sync == optionOn) {
>> SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi,
>> afterSyncInterrupt));
>> -}
>> -else
>> -{
>> +} else {
>> SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, always));
>> }
>> if (rx_cfg->enable_length_byte == optionOn) {
>> @@ -220,29 +209,22 @@ static irqreturn_t DIO1_irq_handler(int irq, void
>> *dev_id)
>>
>> /* lengths */
>> SET_CHECKED(rf69_set_sync_size(dev->spi, rx_cfg->sync_length));
>> -if (rx_cfg->enable_length_byte == optionOn)
>> -{
>> +if (rx_cfg->enable_length_byte == optionOn) {
>> SET_CHECKED(rf69_set_payload_length(dev->spi, 0xff));
>> -}
>> -else if (rx_cfg->fixed_message_length != 0)
>> -{
>> +} else if (rx_cfg->fixed_message_length != 0) {
>> payload_length = rx_cfg->fixed_message_length;
>> if (rx_cfg->enable_length_byte == optionOn) payload_length++;
>> if (rx_cfg->enable_address_filtering !=
Re: [PATCH net-next v4 2/2] net: ethernet: socionext: add AVE ethernet driver
Hi Kunihiko,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Kunihiko-Hayashi/dt-bindings-net-add-DT-bindings-for-Socionext-UniPhier-AVE/20171203-095248
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
In file included from arch/ia64/include/asm/smp.h:21:0,
from include/linux/smp.h:64,
from include/linux/percpu.h:7,
from include/linux/percpu-rwsem.h:7,
from include/linux/fs.h:33,
from include/linux/net.h:27,
from include/linux/skbuff.h:29,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from drivers/net/ethernet/socionext/sni_ave.c:19:
drivers/net/ethernet/socionext/sni_ave.c: In function
'ave_pfsel_set_promisc':
arch/ia64/include/asm/io.h:396:30: warning: large integer implicitly
truncated to unsigned type [-Woverflow]
#define writel(v,a) __writel((v), (a))
^
>> drivers/net/ethernet/socionext/sni_ave.c:1046:2: note: in expansion of macro
>> 'writel'
writel(AVE_PFMBYTE_MASK0, priv->base + AVE_PFMBYTE(entry));
^~
vim +/writel +1046 drivers/net/ethernet/socionext/sni_ave.c
1034
1035 static void ave_pfsel_set_promisc(struct net_device *ndev,
1036unsigned int entry, u32 rxring)
1037 {
1038 struct ave_private *priv = netdev_priv(ndev);
1039
1040 if (WARN_ON(entry > AVE_PF_SIZE))
1041 return;
1042
1043 ave_pfsel_stop(ndev, entry);
1044
1045 /* set byte mask */
> 1046 writel(AVE_PFMBYTE_MASK0, priv->base + AVE_PFMBYTE(entry));
1047 writel(AVE_PFMBYTE_MASK1, priv->base + AVE_PFMBYTE(entry) + 4);
1048
1049 /* set bit mask filter */
1050 writel(AVE_PFMBIT_MASK, priv->base + AVE_PFMBIT(entry));
1051
1052 /* set selector to rxring */
1053 writel(rxring, priv->base + AVE_PFSEL(entry));
1054
1055 ave_pfsel_start(ndev, entry);
1056 }
1057
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v2] NTB: ntb_tool: Add full multi-port NTB API support
Hi Serge,
I love your patch! Yet something to improve:
[auto build test ERROR on v4.15-rc1]
[cannot apply to ntb/ntb-next next-20171201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Serge-Semin/NTB-ntb_tool-Add-full-multi-port-NTB-API-support/20171203-171239
config: x86_64-randconfig-x012-201749 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/ntb/test/ntb_tool.c: In function 'tool_inmsg_read':
>> drivers/ntb/test/ntb_tool.c:1276:36: warning: passing argument 2 of
>> 'ntb_msg_read' makes integer from pointer without a cast [-Wint-conversion]
data = ntb_msg_read(msg->tc->ntb, &pidx, msg->midx);
^
In file included from drivers/ntb/test/ntb_tool.c:193:0:
include/linux/ntb.h:1473:19: note: expected 'int' but argument is of type
'int *'
static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx,
^~~~
>> drivers/ntb/test/ntb_tool.c:1276:43: warning: passing argument 3 of
>> 'ntb_msg_read' makes pointer from integer without a cast [-Wint-conversion]
data = ntb_msg_read(msg->tc->ntb, &pidx, msg->midx);
^~~
In file included from drivers/ntb/test/ntb_tool.c:193:0:
include/linux/ntb.h:1473:19: note: expected 'int *' but argument is of type
'int'
static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx,
^~~~
>> drivers/ntb/test/ntb_tool.c:1276:9: error: too few arguments to function
>> 'ntb_msg_read'
data = ntb_msg_read(msg->tc->ntb, &pidx, msg->midx);
^~~~
In file included from drivers/ntb/test/ntb_tool.c:193:0:
include/linux/ntb.h:1473:19: note: declared here
static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx,
^~~~
drivers/ntb/test/ntb_tool.c: In function 'tool_outmsg_write':
>> drivers/ntb/test/ntb_tool.c:1299:8: error: implicit declaration of function
>> 'ntb_peer_msg_write'; did you mean 'ntb_peer_spad_write'?
>> [-Werror=implicit-function-declaration]
ret = ntb_peer_msg_write(msg->tc->ntb, msg->pidx, msg->midx, val);
^~
ntb_peer_spad_write
In file included from include/linux/init.h:5:0,
from drivers/ntb/test/ntb_tool.c:183:
drivers/ntb/test/ntb_tool.c: At top level:
include/linux/compiler.h:64:4: warning: '__f' is static but declared in
inline function 'strcpy' which is not static
__f = { \
^
include/linux/compiler.h:56:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
include/linux/string.h:422:2: note: in expansion of macro 'if'
if (p_size == (size_t)-1 && q_size == (size_t)-1)
^~
include/linux/compiler.h:64:4: warning: '__f' is static but declared in
inline function 'kmemdup' which is not static
__f = { \
^
include/linux/compiler.h:56:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
include/linux/string.h:412:2: note: in expansion of macro 'if'
if (p_size < size)
^~
include/linux/compiler.h:64:4: warning: '__f' is static but declared in
inline function 'kmemdup' which is not static
__f = { \
^
include/linux/compiler.h:56:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
include/linux/string.h:410:2: note: in expansion of macro 'if'
if (__builtin_constant_p(size) && p_size < size)
^~
include/linux/compiler.h:64:4: warning: '__f' is static but declared in
inline function 'memchr_inv' which is not static
__f = { \
^
include/linux/compiler.h:56:23: note: in expansion of macro '__trace_if'
#define if(cond, ...) __trace_if( (cond , ## __VA_ARGS__) )
^~
include/linux/string.h:401:2: note: in expansion of macro 'if'
if (p_size < size)
^~
include/linux/compiler.h:64:4: warning: '__f' is static but declared in
inline function 'memchr_inv' which is no
Re: [PATCH v2] NTB: ntb_tool: Add full multi-port NTB API support
Hi Serge,
I love your patch! Yet something to improve:
[auto build test ERROR on v4.15-rc1]
[cannot apply to ntb/ntb-next next-20171201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Serge-Semin/NTB-ntb_tool-Add-full-multi-port-NTB-API-support/20171203-171239
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
drivers/ntb/test/ntb_tool.c: In function 'tool_inmsg_read':
drivers/ntb/test/ntb_tool.c:1276:9: warning: passing argument 2 of
'ntb_msg_read' makes integer from pointer without a cast
data = ntb_msg_read(msg->tc->ntb, &pidx, msg->midx);
^
In file included from drivers/ntb/test/ntb_tool.c:193:0:
include/linux/ntb.h:1473:19: note: expected 'int' but argument is of type
'int *'
static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx,
^
drivers/ntb/test/ntb_tool.c:1276:9: warning: passing argument 3 of
'ntb_msg_read' makes pointer from integer without a cast
data = ntb_msg_read(msg->tc->ntb, &pidx, msg->midx);
^
In file included from drivers/ntb/test/ntb_tool.c:193:0:
include/linux/ntb.h:1473:19: note: expected 'int *' but argument is of type
'int'
static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx,
^
drivers/ntb/test/ntb_tool.c:1276:9: error: too few arguments to function
'ntb_msg_read'
data = ntb_msg_read(msg->tc->ntb, &pidx, msg->midx);
^
In file included from drivers/ntb/test/ntb_tool.c:193:0:
include/linux/ntb.h:1473:19: note: declared here
static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx,
^
drivers/ntb/test/ntb_tool.c: In function 'tool_outmsg_write':
>> drivers/ntb/test/ntb_tool.c:1299:2: error: implicit declaration of function
>> 'ntb_peer_msg_write' [-Werror=implicit-function-declaration]
ret = ntb_peer_msg_write(msg->tc->ntb, msg->pidx, msg->midx, val);
^
cc1: some warnings being treated as errors
vim +/ntb_peer_msg_write +1299 drivers/ntb/test/ntb_tool.c
1261
1262
/*==
1263 * Messages read/write methods
1264
*==
1265 */
1266
1267 static ssize_t tool_inmsg_read(struct file *filep, char __user *ubuf,
1268 size_t size, loff_t *offp)
1269 {
1270 struct tool_msg *msg = filep->private_data;
1271 char buf[32];
1272 ssize_t pos;
1273 u32 data;
1274 int pidx;
1275
> 1276 data = ntb_msg_read(msg->tc->ntb, &pidx, msg->midx);
1277
1278 pos = scnprintf(buf, sizeof(buf), "0x%08x<-%d\n", data, pidx);
1279
1280 return simple_read_from_buffer(ubuf, size, offp, buf, pos);
1281 }
1282
1283 static TOOL_FOPS_RDWR(tool_inmsg_fops,
1284tool_inmsg_read,
1285NULL);
1286
1287 static ssize_t tool_outmsg_write(struct file *filep,
1288 const char __user *ubuf,
1289 size_t size, loff_t *offp)
1290 {
1291 struct tool_msg *msg = filep->private_data;
1292 u32 val;
1293 int ret;
1294
1295 ret = kstrtou32_from_user(ubuf, size, 0, &val);
1296 if (ret)
1297 return ret;
1298
> 1299 ret = ntb_peer_msg_write(msg->tc->ntb, msg->pidx, msg->midx,
> val);
1300
1301 return ret ? : size;
1302 }
1303
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: Memory corruption in powerpc guests with virtio_balloon (was Re: [PATCH v3] virtio_balloon: fix deadlock on OOM)
"Michael S. Tsirkin" writes: > On Fri, Dec 01, 2017 at 11:31:08PM +1100, Michael Ellerman wrote: >> "Michael S. Tsirkin" writes: >> >> > fill_balloon doing memory allocations under balloon_lock >> > can cause a deadlock when leak_balloon is called from >> > virtballoon_oom_notify and tries to take same lock. ... >> >> >> Somehow this commit seems to be killing powerpc guests. ... > > Thanks for the report! > A fix was just posted: > virtio_balloon: fix increment of vb->num_pfns in fill_balloon() > > Would appreciate testing. Yep that fixes it. Thanks. Tested-by: Michael Ellerman cheers
[PATCH,v2] Make TI_ST a menuconfig to ease disabling it all
v2: using bool instead of tristate
[PATCH] Make TI_ST a menuconfig to ease disabling it all
No need to get into the submenu to disable all TI_ST-related config entries Signed-off-by: Vincent Legoll --- drivers/misc/ti-st/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/misc/ti-st/Kconfig b/drivers/misc/ti-st/Kconfig index f34dcc514730..f007cfa82b89 100644 --- a/drivers/misc/ti-st/Kconfig +++ b/drivers/misc/ti-st/Kconfig @@ -2,10 +2,12 @@ # TI's shared transport line discipline and the protocol # drivers (BT, FM and GPS) # -menu "Texas Instruments shared transport line discipline" +menuconfig TIST + bool "Texas Instruments shared transport line discipline" + config TI_ST tristate "Shared transport core driver" - depends on NET && GPIOLIB && TTY + depends on TIST && NET && GPIOLIB && TTY select FW_LOADER help This enables the shared transport core driver for TI @@ -13,5 +15,3 @@ config TI_ST to register themselves with core and send data, the responses are returned to relevant protocol drivers based on their packet types. - -endmenu -- 2.11.0
Re: [PATCHv3 resend] uapi libc compat: add fallback for unsupported libcs
On 11/12/2017 07:30 PM, Felix Janda wrote: > libc-compat.h aims to prevent symbol collisions between uapi and libc > headers for each supported libc. This requires continuous coordination > between them. > > The goal of this commit is to improve the situation for libcs (such as > musl) which are not yet supported and/or do not wish to be explicitly > supported, while not affecting supported libcs. More precisely, with > this commit, unsupported libcs can request the suppression of any > specific uapi definition by defining the correspondings _UAPI_DEF_* > macro as 0. This can fix symbol collisions for them, as long as the > libc headers are included before the uapi headers. Inclusion in the > other order is outside the scope of this commit. > > All infrastructure in order to enable this fallback for unsupported > libcs is already in place, except that libc-compat.h unconditionally > defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that > any previous definitions are ignored. In order to fix this, this commit > merely makes these definitions conditional. > > This commit together with the musl libc commit > > http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 > > fixes for example the following compiler errors when is > included after musl's : > > ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr' > ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6' > ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq' > > Signed-off-by: Felix Janda > Reviewed-by: Hauke Mehrtens > --- > v3: Fix typos, add a comment to the file and use #ifndef. > v2: The only change to the previous version is the commit title and > message. > --- > include/uapi/linux/libc-compat.h | 55 > +++- > 1 file changed, 54 insertions(+), 1 deletion(-) > I would really like to see this in the mainline kernel as this is needed to use the kernel headers with the musl libc, so probably every user of the musl libc needs this. A similar patch is in OpenWrt / LEDE and is mandatory when building the musl toolchain used in OpenWrt / LEDE, which is the default. I would like to get closer to build OpenWrt / LEDE with an unmodified Linux kernel and getting this into mainline is one part of it. As this patch is on the mailling lists since multiple months without any reaction it looks like there is no maintainer for: include/uapi/linux/libc-compat.h Should we send this in the next merge window directly to Linus? If I am wrong please correct me. Post on the mailling list: patch v2: https://patchwork.kernel.org/patch/9831533/ patch v3: https://patchwork.kernel.org/patch/9869953/ Hauke
[PATCH] Make FSI a menuconfig to ease disabling it all
No need to get into the submenu to disable all FSI-related config entries Signed-off-by: Vincent Legoll --- drivers/fsi/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig index 6821ed0cd5e8..513e35173aaa 100644 --- a/drivers/fsi/Kconfig +++ b/drivers/fsi/Kconfig @@ -2,9 +2,7 @@ # FSI subsystem # -menu "FSI support" - -config FSI +menuconfig FSI tristate "FSI support" select CRC4 ---help--- @@ -34,5 +32,3 @@ config FSI_SCOM This option enables an FSI based SCOM device driver. endif - -endmenu -- 2.11.0
Re: [PATCH 1/2] dt-bindings: trivial: add tfa9879 device
Hi Peter, On Sun, Dec 3, 2017 at 4:59 AM, Peter Rosin wrote: > Right. However, the patch adding that should have been sent to me, the > maintainer of the driver. That is carefully recorded in MAINTAINERS. So, > forgive me for assuming that nothing had changed in the driver behind my > back. > > Had that patch been sent my way as it should have been, I would have > insisted that maintenance of the bindings had been kept together with > the maintenance of the driver. When I sent this patch ./scripts/get_maintainer.pl did lot list your name, so that's why I did not put you on Cc, sorry. 4.15-rc1 still does not list you, but linux-next does. Would you like me to send the following patch so that new binding updates go to you? --- a/MAINTAINERS +++ b/MAINTAINERS @@ -9808,6 +9808,7 @@ NXP TFA9879 DRIVER M: Peter Rosin L: alsa-de...@alsa-project.org (moderated for non-subscribers) S: Maintained +F: Documentation/devicetree/bindings/sound/tfa9879.txt F: sound/soc/codecs/tfa9879*
RE: [PATCH] arm: l2c: unlock ways when in non-secure mode
Hi Russell, > > > > > > > > > > > > On Sun, Nov 26, 2017 at 08:25:30PM +0800, Peng Fan wrote: > > > > > > > To boot Linux in Non-secure mode with l2x0, the l2x0 > > > > > > > controller is enabled in secure mode and ways locked to make > > > > > > > it seems L2 cache disabled during linux boot process. So > > > > > > > during l2x0 initialization, need to unlock the ways to make > > > > > > > l2x0 could > > cache data/inst. > > > > > > > > > > > > Why was this chosen instead of doing what everyone else does? > > > > > > > > > > I am not aware of how other platform handles the l2x0 unlock in > > > > > non secure mode. Could you please share with me what others choose? > > > > > > > > That's not what I was asking. > > > > > > > > Everyone else provides a way for the l2x0 controller to be enabled > > > > and disabled from non-secure mode. > > > > > > Thanks for the information. I see that some platforms implements > > l2c_write_sec. > > > > > > > > > > > Why have you decided to enable the l2x0 controller and leave it > > > > enabled, and then lock down all the cache ways - which means you > > > > need the kernel to do something entirely different for your platform. > > > > > > Currently we are running OP-TEE on i.MX6/7 with Linux in non-secure > > > mode. See In > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > > it > > > hub.com%2FOP- > > TEE%2Foptee_os%2Fblob%2Fmaster%2Fcore%2Farch%2Farm%2Fkern > > > > > el%2Fgeneric_entry_a32.S%23L428&data=02%7C01%7Cpeng.fan%40nxp.com% > > 7C32 > > > > > > e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > > C0% > > > > > > 7C0%7C636473747645673295&sdata=ZGaxxhs8mPNcqk5l2aSiStkPRFNxLzFFj45w > > kj% > > > 2Ff%2Fu4%3D&reserved=0 > > > Pl310 is enabled. And In > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg > > > it > > > hub.com%2FOP- > > TEE%2Foptee_os%2Fblob%2Fmaster%2Fcore%2Farch%2Farm%2Fkern > > > > > el%2Fgeneric_entry_a32.S%23L461&data=02%7C01%7Cpeng.fan%40nxp.com% > > 7C32 > > > > > > e10e1e643f4def0d9508d535805486%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > > C0% > > > > > > 7C0%7C636473747645673295&sdata=rO1LG3639lfclvtgzZRTTPcSAGDQNG0Clqb > > D1wC > > > 4wGk%3D&reserved=0 > > > pl310 locked before returning back to Linux. > > > > > > I see ti platform not enabled pl310 in OP-TEE, leaving Linux to > > > enable it. platform-sam/stm/ zynq7k/imx Have pl310 enabled in OP-TEE. > > > > > > I could switch to use l2c_write_sec dedicated for i.MX. But I think > > > this patch is > > also a valid point. > > > What do you suggest? > > > > What I'm concerned about is that there's a valid scenario where the L2 > > cache would be enabled and left enabled by the secure mode code - that > > is if the secure mode wishes to take advantage of the L2 cache, and > > has locked down some ways for its own use. > > > > In this scenario, the secure world would have set the L2 cache up to > > prevent the non-secure side unlocking those ways. This would mean > > that the NS_LOCKDOWN bit in the auxiliary control register would be > > clear. The PL310 TRM has this to say: > > > > "On reset the Non-Secure Lockdown Enable bit is set to 0 and Lockdown > > Registers are not permitted to be modified by non-secure accesses. In > > that configuration, if a non-secure access tries to write to those > > registers, the write response returns a DECERR response." > > > > which means that if we blindly try and unlock the ways, we will end up > > triggering an exception, and that will crash the kernel. Just have a follow up question. If implementing l2c_write_sec, the kernel image could not only running in non-secure world. If we want the image to support running in secure and non-secure world, do you have any suggestions about the l2c things? Thanks, Peng. > > Currently, we set auxiliary control register to let NS could unlock. BIT26 > set to 1. > But you bring a valid point is if TEE would like to lock down some ways for > its > own use, l2c_write_sec should be used, to avoid Linux to directly unlock. > > > > > Given that the kernel does _not_ handle this scenario today, I fail to > > see why OP-TEE would decide that, on ARM by default, it will enable > > the L2 cache and lock all ways. > > > > As you have already found, at least OMAP has decided to do things > > sensibly. I fail to see why everyone else can't also decide to do the > > sensible > thing. > > Most platforms just set BIT26 to allow non-secure unlock ways without > considering reserving ways dedicated to TEE. > > i.MX also has BIT26 set, so if l2c_init is not a good place, do you think > moving > unlock to imx_init_l2cache is ok? But this means "enabling(unlock)" L2C > earlier > which is before l2c_init > > > > > Please talk to the OP-TEE folk to see whether the OP-TEE behaviour can > > be changed first. > > +OP-TEE maintainers Etienne, Jens > Do you have comments on this? > > Thanks, > Peng. > > > > > -- > > RMK's Patch system: > > > https://emea01.safel
Re: [PATCHv3 resend] uapi libc compat: add fallback for unsupported libcs
Hi, On Sun, Nov 12, 2017 at 01:30:17PM -0500, Felix Janda wrote: > libc-compat.h aims to prevent symbol collisions between uapi and libc > headers for each supported libc. This requires continuous coordination > between them. > > The goal of this commit is to improve the situation for libcs (such as > musl) which are not yet supported and/or do not wish to be explicitly > supported, while not affecting supported libcs. More precisely, with > this commit, unsupported libcs can request the suppression of any > specific uapi definition by defining the correspondings _UAPI_DEF_* > macro as 0. This can fix symbol collisions for them, as long as the > libc headers are included before the uapi headers. Inclusion in the > other order is outside the scope of this commit. > > All infrastructure in order to enable this fallback for unsupported > libcs is already in place, except that libc-compat.h unconditionally > defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that > any previous definitions are ignored. In order to fix this, this commit > merely makes these definitions conditional. > > This commit together with the musl libc commit > > http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964ff944fbb8258 > > fixes for example the following compiler errors when is > included after musl's : > > ./linux/in6.h:32:8: error: redefinition of 'struct in6_addr' > ./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6' > ./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq' > > Signed-off-by: Felix Janda > Reviewed-by: Hauke Mehrtens > --- > v3: Fix typos, add a comment to the file and use #ifndef. > v2: The only change to the previous version is the commit title and > message. > --- > include/uapi/linux/libc-compat.h | 55 > +++- > 1 file changed, 54 insertions(+), 1 deletion(-) > > diff --git a/include/uapi/linux/libc-compat.h > b/include/uapi/linux/libc-compat.h > index 44b8a6bd5fe1..65db6b26d790 100644 > --- a/include/uapi/linux/libc-compat.h > +++ b/include/uapi/linux/libc-compat.h > @@ -167,46 +167,99 @@ > > /* If we did not see any headers from any supported C libraries, > * or we are being included in the kernel, then define everything > - * that we need. */ > + * that we need. Check for previous __UAPI_* definitions to give > + * unsupported C libraries a way to opt out of any kernel definition. */ > #else /* !defined(__GLIBC__) */ > > /* Definitions for if.h */ > +#ifndef __UAPI_DEF_IF_IFCONF > #define __UAPI_DEF_IF_IFCONF 1 > +#endif > +#ifndef __UAPI_DEF_IF_IFMAP > #define __UAPI_DEF_IF_IFMAP 1 > +#endif > +#ifndef __UAPI_DEF_IF_IFNAMSIZ > #define __UAPI_DEF_IF_IFNAMSIZ 1 > +#endif > +#ifndef __UAPI_DEF_IF_IFREQ > #define __UAPI_DEF_IF_IFREQ 1 > +#endif > /* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */ > +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS > #define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1 > +#endif > /* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */ > +#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO > #define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1 > +#endif Please double-check that mentioning glibc in comments of this !__GLIBC__ section is relevant. > > /* Definitions for in.h */ > +#ifndef __UAPI_DEF_IN_ADDR > #define __UAPI_DEF_IN_ADDR 1 > +#endif > +#ifndef __UAPI_DEF_IN_IPPROTO > #define __UAPI_DEF_IN_IPPROTO1 > +#endif > +#ifndef __UAPI_DEF_IN_PKTINFO > #define __UAPI_DEF_IN_PKTINFO1 > +#endif > +#ifndef __UAPI_DEF_IP_MREQ > #define __UAPI_DEF_IP_MREQ 1 > +#endif > +#ifndef __UAPI_DEF_SOCKADDR_IN > #define __UAPI_DEF_SOCKADDR_IN 1 > +#endif > +#ifndef __UAPI_DEF_IN_CLASS > #define __UAPI_DEF_IN_CLASS 1 > +#endif > > /* Definitions for in6.h */ > +#ifndef __UAPI_DEF_IN6_ADDR > #define __UAPI_DEF_IN6_ADDR 1 > +#endif > +#ifndef __UAPI_DEF_IN6_ADDR_ALT > #define __UAPI_DEF_IN6_ADDR_ALT 1 > +#endif > +#ifndef __UAPI_DEF_SOCKADDR_IN6 > #define __UAPI_DEF_SOCKADDR_IN6 1 > +#endif > +#ifndef __UAPI_DEF_IPV6_MREQ > #define __UAPI_DEF_IPV6_MREQ 1 > +#endif > +#ifndef __UAPI_DEF_IPPROTO_V6 > #define __UAPI_DEF_IPPROTO_V61 > +#endif > +#ifndef __UAPI_DEF_IPV6_OPTIONS > #define __UAPI_DEF_IPV6_OPTIONS 1 > +#endif > +#ifndef __UAPI_DEF_IN6_PKTINFO > #define __UAPI_DEF_IN6_PKTINFO 1 > +#endif > +#ifndef __UAPI_DEF_IP6_MTUINFO > #define __UAPI_DEF_IP6_MTUINFO 1 > +#endif > > /* Definitions for ipx.h */ > +#ifndef __UAPI_DEF_SOCKADDR_IPX > #define __UAPI_DEF_SOCKADDR_IPX 1 > +#endif > +#ifndef __UAPI_DEF_IPX_ROUTE_DEFINITION > #define __UAPI_DEF_IPX_ROUTE_DEFINITION 1 > +#endif > +#ifndef __UAPI_DEF_IPX_INTERFACE_DEFINITION > #define __UAPI_DEF_IPX_INTERFACE_DEFINITION 1 > +#endif > +#ifndef __UAPI
Re: KASAN: slab-out-of-bounds Read in strcmp
On 2017/12/02 3:52, syzbot wrote:
> ==
> BUG: KASAN: slab-out-of-bounds in strcmp+0x96/0xb0 lib/string.c:328
> Read of size 1 at addr 8801cd99d2c1 by task syzkaller242593/3087
>
> CPU: 0 PID: 3087 Comm: syzkaller242593 Not tainted 4.15.0-rc1-next-20171201+
> #57
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> print_address_description+0x73/0x250 mm/kasan/report.c:252
> kasan_report_error mm/kasan/report.c:351 [inline]
> kasan_report+0x25b/0x340 mm/kasan/report.c:409
> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
> strcmp+0x96/0xb0 lib/string.c:328
This seems to be out of bound read for "scontext" at
for (i = 1; i < SECINITSID_NUM; i++) {
if (!strcmp(initial_sid_to_string[i], scontext)) {
*sid = i;
return 0;
}
}
because "initial_sid_to_string[i]" is "const char *".
> security_context_to_sid_core+0x437/0x620 security/selinux/ss/services.c:1420
> security_context_to_sid+0x32/0x40 security/selinux/ss/services.c:1479
> selinux_setprocattr+0x51c/0xb50 security/selinux/hooks.c:5986
> security_setprocattr+0x85/0xc0 security/security.c:1264
If "value" does not terminate with '\0' or '\n', "value" and
"size" are as-is passed to "scontext" and "scontext_len" above
/* Obtain a SID for the context, if one was specified. */
if (size && str[0] && str[0] != '\n') {
if (str[size-1] == '\n') {
str[size-1] = 0;
size--;
}
error = security_context_to_sid(value, size, &sid, GFP_KERNEL);
which will allow strcmp() to trigger out of bound read when "size" is
larger than strlen(initial_sid_to_string[i]).
Thus, I guess the simplest fix is to use strncmp() instead of strcmp().
> proc_pid_attr_write+0x1e6/0x280 fs/proc/base.c:2574
> __vfs_write+0xef/0x970 fs/read_write.c:480
> __kernel_write+0xfe/0x350 fs/read_write.c:501
> write_pipe_buf+0x175/0x220 fs/splice.c:797
> splice_from_pipe_feed fs/splice.c:502 [inline]
> __splice_from_pipe+0x328/0x730 fs/splice.c:626
> splice_from_pipe+0x1e9/0x330 fs/splice.c:661
> default_file_splice_write+0x40/0x90 fs/splice.c:809
> do_splice_from fs/splice.c:851 [inline]
> direct_splice_actor+0x125/0x180 fs/splice.c:1018
> splice_direct_to_actor+0x2c1/0x820 fs/splice.c:973
> do_splice_direct+0x2a7/0x3d0 fs/splice.c:1061
> do_sendfile+0x5d5/0xe90 fs/read_write.c:1413
> SYSC_sendfile64 fs/read_write.c:1468 [inline]
> SyS_sendfile64+0xbd/0x160 fs/read_write.c:1460
> entry_SYSCALL_64_fastpath+0x1f/0x96
Re: [PATCH] ARM: dts: exynos: Add missing interrupt-controller properties to Exynos5410 PMU
On Wed, Nov 29, 2017 at 07:36:10PM +0100, Krzysztof Kozlowski wrote: > PMU (system-controller@1004) is used as interrupt-parent for certain > nodes thus it should be marked as interrupt-controller to silence > warnings when building Exynos5410-based DTBs: > > arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property): > Missing interrupt-controller or interrupt-map property in > /soc/system-controller@1004 > arch/arm/boot/dts/exynos5410-odroidxu.dtb: Warning (interrupts_property): > Missing #interrupt-cells in interrupt-parent > /soc/system-controller@1004 > > Signed-off-by: Krzysztof Kozlowski > --- > arch/arm/boot/dts/exynos5410.dtsi | 3 +++ > 1 file changed, 3 insertions(+) For the record, applied. Best regards, Krzysztof
Re: [RFC] Rebasing the IDR
On Thu, Nov 30, 2017 at 10:09 PM, Matthew Wilcox wrote: > On Thu, Nov 30, 2017 at 08:56:43PM +0100, Daniel Vetter wrote: >> Adding dri-devel, I think a pile of those are in drm. > > Yeah, quite a lot! This is a good thing; means you didn't invent your > own custom ID allocator. > >> On Thu, Nov 30, 2017 at 6:36 PM, Matthew Wilcox wrote: >> > About 40 of the approximately 180 users of the IDR in the kernel are >> > "1-based" instead of "0-based". That is, they never want to have ID 0 >> > allocated; they want to see IDs allocated between 1 and N. Usually, that's >> > expressed like this: >> > >> > /* Get the user-visible handle using idr. */ >> > ret = idr_alloc(&file_priv->object_idr, obj, 1, 0, GFP_KERNEL); >> > > >> Just quick context on why we do this: We need to marshal/demarshal >> NULL in a ton of our ioctls, mapping that to 0 is natural. > > Yep. You could actually store NULL at IDR index 0; the IDR distinguishes > between an allocated NULL and an unallocated entry. We're storing NULL in a few interim cases already, to solve issues around init/teardown of objects (where we need to keep the index reserved, but not pointing to anything). So if I could pick, I'd prefer to distinguish that from the always-NULL case for 0. Since doing that would mean in our driver unload code we'd then have to check for that NULL pointer in the usual cleanup loops (where we know all the interim NULL values are definitely gone). >> And yes I very much like this, and totally fine with trading an >> idr_init_base when we can nuke the explicit index ranges at every >> alloc side instead. So if you give me an idr_alloc function that >> doesn't take a range as icing, that would be great. > > I think the API is definitely bad at making the easy things easy ... I'd > call the current idr_alloc() idr_alloc_range(). But I don't want to change > 200+ call sites, so I'll settle for a new name. > > ret = idr_get(&file_priv->object_idr, obj, GFP_KERNEL); > > I have another new API in the works for after the xarray lands and we can > simplify the locking -- > > int __must_check idr_alloc_u32(struct idr *idr, void *ptr, > unsigned int *nextid, unsigned int max, gfp_t gfp) > > The trick is that we store to nextid before inserting the ptr into the > xarray, so this will enable more users to dispense with their own locking > (or avoid awful i-looked-up-this-object-but-it's-not-initialised-so- > pretend-i-didn't-see-it dances). > > (There's also an idr_alloc_ul for completeness, but I think this is > actually a bad idea; the radix tree gets pretty unwieldy at large sparse > indices and I don't want to encourage people to go outside unsigned int). +1 on idr_get. A bit confusing since get/put is usually used for refcounting in the kernel (we're switching the drm subsystem from ref/unref to get/put for more consistency), but oh well, flag days are not pretty either. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] Make MIC a menuconfig to ease disabling it all
No need to get into the submenu to disable all MIC-related config entries Signed-off-by: Vincent Legoll --- drivers/misc/mic/Kconfig | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/misc/mic/Kconfig b/drivers/misc/mic/Kconfig index 227cc7443671..badc84356715 100644 --- a/drivers/misc/mic/Kconfig +++ b/drivers/misc/mic/Kconfig @@ -1,4 +1,7 @@ -menu "Intel MIC & related support" +menuconfig INTEL_MISC_BUS + bool "Intel MIC & related support" + +if INTEL_MISC_BUS comment "Intel MIC Bus Driver" @@ -153,4 +156,4 @@ if VOP source "drivers/vhost/Kconfig.vringh" endif -endmenu +endif # INTEL_MISC_BUS -- 2.11.0
Re: [PATCH v3 3/5] kasan: support alloca() poisoning
On Fri, Dec 1, 2017 at 10:36 PM, Paul Lawrence wrote:
> clang's AddressSanitizer implementation adds redzones on either side of
> alloca()ed buffers. These redzones are 32-byte aligned and at least 32
> bytes long.
>
> __asan_alloca_poison() is passed the size and address of the allocated
> buffer, *excluding* the redzones on either side. The left redzone will
> always be to the immediate left of this buffer; but AddressSanitizer may
> need to add padding between the end of the buffer and the right redzone.
> If there are any 8-byte chunks inside this padding, we should poison
> those too.
>
> __asan_allocas_unpoison() is just passed the top and bottom of the
> dynamic stack area, so unpoisoning is simpler.
>
> Signed-off-by: Greg Hackmann
> Signed-off-by: Paul Lawrence
> ---
> mm/kasan/kasan.c | 34 ++
> mm/kasan/kasan.h | 8
> mm/kasan/report.c | 4
> scripts/Makefile.kasan | 3 ++-
> 4 files changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index 405bba487df5..d96b36088b2f 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -736,6 +736,40 @@ void __asan_unpoison_stack_memory(const void *addr,
> size_t size)
> }
> EXPORT_SYMBOL(__asan_unpoison_stack_memory);
>
> +/* Emitted by compiler to poison alloca()ed objects. */
> +void __asan_alloca_poison(unsigned long addr, size_t size)
> +{
> + size_t rounded_up_size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
> + size_t padding_size = round_up(size, KASAN_ALLOCA_REDZONE_SIZE) -
> + rounded_up_size;
> + size_t rounded_down_size = round_down(size, KASAN_SHADOW_SCALE_SIZE);
> +
> + const void *left_redzone = (const void *)(addr -
> + KASAN_ALLOCA_REDZONE_SIZE);
> + const void *right_redzone = (const void *)(addr + rounded_up_size);
> +
> + WARN_ON(!IS_ALIGNED(addr, KASAN_ALLOCA_REDZONE_SIZE));
> +
> + kasan_unpoison_shadow((const void *)(addr + rounded_down_size),
> + size - rounded_down_size);
> + kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
> + KASAN_ALLOCA_LEFT);
> + kasan_poison_shadow(right_redzone,
> + padding_size + KASAN_ALLOCA_REDZONE_SIZE,
> + KASAN_ALLOCA_RIGHT);
> +}
> +EXPORT_SYMBOL(__asan_alloca_poison);
> +
> +/* Emitted by compiler to unpoison alloca()ed areas when the stack unwinds.
> */
> +void __asan_allocas_unpoison(const void *stack_top, const void *stack_bottom)
> +{
> + if (unlikely(!stack_top || stack_top > stack_bottom))
> + return;
> +
> + kasan_unpoison_shadow(stack_top, stack_bottom - stack_top);
> +}
> +EXPORT_SYMBOL(__asan_allocas_unpoison);
> +
> #ifdef CONFIG_MEMORY_HOTPLUG
> static int __meminit kasan_mem_notifier(struct notifier_block *nb,
> unsigned long action, void *data)
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index c70851a9a6a4..7c0bcd1f4c0d 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -24,6 +24,14 @@
> #define KASAN_STACK_PARTIAL 0xF4
> #define KASAN_USE_AFTER_SCOPE 0xF8
>
> +/*
> + * alloca redzone shadow values
> + */
> +#define KASAN_ALLOCA_LEFT 0xCA
> +#define KASAN_ALLOCA_RIGHT 0xCB
> +
> +#define KASAN_ALLOCA_REDZONE_SIZE 32
> +
> /* Don't break randconfig/all*config builds */
> #ifndef KASAN_ABI_VERSION
> #define KASAN_ABI_VERSION 1
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 410c8235e671..eff12e040498 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -102,6 +102,10 @@ static const char *get_shadow_bug_type(struct
> kasan_access_info *info)
> case KASAN_USE_AFTER_SCOPE:
> bug_type = "use-after-scope";
> break;
> + case KASAN_ALLOCA_LEFT:
> + case KASAN_ALLOCA_RIGHT:
> + bug_type = "alloca-out-of-bounds";
> + break;
> }
>
> return bug_type;
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 7c00be9216f4..b4983cf8a9d4 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -32,7 +32,8 @@ else
> $(call cc-param,asan-globals=1) \
> $(call
> cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \
> $(call cc-param,asan-stack=1) \
> - $(call cc-param,asan-use-after-scope=1)
> + $(call cc-param,asan-use-after-scope=1) \
> + $(call cc-param,asan-instrument-allocas=1)
> endif
>
> endif
Reviewed-by: Dmitry Vyukov
Re: [PATCH v3 0/5] kasan: support alloca, LLVM
On Fri, Dec 1, 2017 at 10:36 PM, Paul Lawrence wrote: > [PATCH v3 1/5] kasan: add compiler support for clang > Moved to start of patchset > > [PATCH v3 2/5] kasan/Makefile: Support LLVM style asan parameters. > Using Andrey's version. > Fixed up bug with testing CFLAGS_KASAN_SHADOW > Modifed to not output gcc style options on llvm > > [PATCH v3 3/5] kasan: support alloca() poisoning > Added alloca makefile option here > Modified to only unpoison the last block > > [PATCH v3 4/5] kasan: Add tests for alloca poisoning > No change > > [PATCH v3 5/5] kasan: added functions for unpoisoning stack variables > No change > > Paul Lawrence (5): > kasan: add compiler support for clang > kasan/Makefile: Support LLVM style asan parameters. > kasan: support alloca() poisoning > kasan: Add tests for alloca poisonong > kasan: added functions for unpoisoning stack variables > > include/linux/compiler-clang.h | 8 +++ > lib/test_kasan.c | 22 +++ > mm/kasan/kasan.c | 49 > ++ > mm/kasan/kasan.h | 8 +++ > mm/kasan/report.c | 4 > scripts/Makefile.kasan | 30 -- > 6 files changed, 110 insertions(+), 11 deletions(-) The series looks good to me. Thanks for working on this, we need clang.
[PATCH net-next 0/8] Hisilicon Network Subsystem 3 VF Ethernet Driver
This patch-set contains the support of the HNS3 (Hisilicon Network Subsystem 3)
Virtual Function Ethernet driver for hip08 family of SoCs. The Physical Function
driver is already part of the Linux mainline.
This VF driver has its Hardware Compatibility Layer and has commom/unified ENET
layer/client/ethtool code with the PF driver. The basic architecture of VF
driver
is derivative of the PF driver. Just like PF driver, this driver is also PCI
Express based.
This driver is the ongoing development work and HNS3 VF Ethernet driver would be
incrementally enhanced with more new features.
High Level Architecture:
[ Ethtool ]
|
[ Ethernet Client ] ... [ RoCE Client ]
| |
[ HNAE Device ] |
| | |
- |
|
[ HNAE3 Framework (Register/unregister) ] |
|
- |
| |
[ VF HCLGE Layer ]|
| | |
| | |
| | |
| [ VF Mailbox (To PF via IMP) ] |
| | |
[ IMP command Interface ] [ IMP command Interface ]
| |
| |
(A B O V E R U N S O N G U E S T S Y S T E M)
-
Q E M U / V F I O / K V M (on Host System)
-
HIP08 H A R D W A R E (limited to VF by SMMU)
[ IMP/Mgmt Processor ] (hardware common to system/cmd based)
Fig 1. HNS3 Virtual Function Driver
[ dcbnl ] [ Ethtool ]
| |
[ Ethernet Client ] [ ODP/UIO Client ] . . .[ RoCE Client ]
|_| |
| _|
[ HNAE Device ] ||
| ||
- |
|
[ HNAE3 Framework (Register/unregister) ]|
|
- |
||
[ HCLGE Layer ] |
|_ |
|| | |
[ DCB ] | | |
|| | |
[ Scheduler/Shaper ] [ MDIO ] [ PF Mailbox ] |
|| | |
||_| |
||
[ IMP command Interface ] [ IMP command Interface ]
HIP08 H A R D W A R E
[ IMP/Mgmt Processor ] (hardware common to system/cmd based)
Fig 2.Existing HNS3 PF Driver (added with mailbox)
NOTE: This patch depends upon https://lkml.org/lkml/2017/11/30/1079
Salil Mehta (8):
net: hns3: Add HNS3 VF IMP(Integrated Management Proc) cmd interface
net: hns3: Add mailbox support to VF driver
net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support
net: hns3: Add HNS3 VF driver to kernel build framework
net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC
net: hns3: Add mailbox support to PF driver
net: hns3: Change PF to add ring-vect binding & resetQ to mailbox
net: hns3: Add mailbox interrupt handling to PF driver
drivers/net/ethernet/hisilicon/Kconfig | 28 +-
drivers/net/ethernet/hisilicon/hns3/Makefile |7 +-
drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h| 94 ++
drivers/net/ethernet/hisilicon/hns3/hnae3.c| 14 +-
drivers/net/ethernet/hisilicon/hns3/hnae3.h|7 +-
.../hisilicon/hns3/{hns3pf => }/hns3_dcbnl.c |2 +-
.../hisilicon/hns3/{hns3pf => }/hns3_enet.c|2 +
.../hisilicon/hns3/{hns3pf => }/hns3_enet.h|0
.../hisilicon/hns3/{hns3pf => }/hns3_ethtool.c | 22 +-
.../net/ethernet/hisilicon/hns3/hns3pf/Makefile|
[PATCH net-next 7/8] net: hns3: Change PF to add ring-vect binding & resetQ to mailbox
This patch is required to support ring-vector binding and reset
of TQPs requested by the VF driver to the PF driver. Mailbox
handler is added with corresponding VF commands/messages to
handle the request.
Signed-off-by: Salil Mehta
Signed-off-by: lipeng
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 136 +++--
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 7 +-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 106
3 files changed, 157 insertions(+), 92 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index af9d92a3800e..7d9fa4e2b16a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3252,49 +3252,46 @@ int hclge_rss_init_hw(struct hclge_dev *hdev)
return ret;
}
-int hclge_map_vport_ring_to_vector(struct hclge_vport *vport, int vector_id,
- struct hnae3_ring_chain_node *ring_chain)
+int hclge_bind_ring_with_vector(struct hclge_vport *vport,
+ int vector_id, bool en,
+ struct hnae3_ring_chain_node *ring_chain)
{
struct hclge_dev *hdev = vport->back;
- struct hclge_ctrl_vector_chain_cmd *req;
struct hnae3_ring_chain_node *node;
struct hclge_desc desc;
- int ret;
+ struct hclge_ctrl_vector_chain_cmd *req
+ = (struct hclge_ctrl_vector_chain_cmd *)desc.data;
+ enum hclge_cmd_status status;
+ enum hclge_opcode_type op;
int i;
- hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_ADD_RING_TO_VECTOR, false);
-
- req = (struct hclge_ctrl_vector_chain_cmd *)desc.data;
+ op = en ? HCLGE_OPC_ADD_RING_TO_VECTOR : HCLGE_OPC_DEL_RING_TO_VECTOR;
+ hclge_cmd_setup_basic_desc(&desc, op, false);
req->int_vector_id = vector_id;
i = 0;
for (node = ring_chain; node; node = node->next) {
- u16 type_and_id = 0;
-
- hnae_set_field(type_and_id, HCLGE_INT_TYPE_M, HCLGE_INT_TYPE_S,
+ hnae_set_field(req->tqp_type_and_id[i], HCLGE_INT_TYPE_M,
+ HCLGE_INT_TYPE_S,
hnae_get_bit(node->flag, HNAE3_RING_TYPE_B));
- hnae_set_field(type_and_id, HCLGE_TQP_ID_M, HCLGE_TQP_ID_S,
- node->tqp_index);
- hnae_set_field(type_and_id, HCLGE_INT_GL_IDX_M,
- HCLGE_INT_GL_IDX_S,
- hnae_get_bit(node->flag, HNAE3_RING_TYPE_B));
- req->tqp_type_and_id[i] = cpu_to_le16(type_and_id);
- req->vfid = vport->vport_id;
-
+ hnae_set_field(req->tqp_type_and_id[i], HCLGE_TQP_ID_M,
+ HCLGE_TQP_ID_S, node->tqp_index);
+ req->tqp_type_and_id[i] = cpu_to_le16(req->tqp_type_and_id[i]);
if (++i >= HCLGE_VECTOR_ELEMENTS_PER_CMD) {
req->int_cause_num = HCLGE_VECTOR_ELEMENTS_PER_CMD;
+ req->vfid = vport->vport_id;
- ret = hclge_cmd_send(&hdev->hw, &desc, 1);
- if (ret) {
+ status = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (status) {
dev_err(&hdev->pdev->dev,
"Map TQP fail, status is %d.\n",
- ret);
- return ret;
+ status);
+ return -EIO;
}
i = 0;
hclge_cmd_setup_basic_desc(&desc,
- HCLGE_OPC_ADD_RING_TO_VECTOR,
+ op,
false);
req->int_vector_id = vector_id;
}
@@ -3302,21 +3299,21 @@ int hclge_map_vport_ring_to_vector(struct hclge_vport
*vport, int vector_id,
if (i > 0) {
req->int_cause_num = i;
-
- ret = hclge_cmd_send(&hdev->hw, &desc, 1);
- if (ret) {
+ req->vfid = vport->vport_id;
+ status = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (status) {
dev_err(&hdev->pdev->dev,
- "Map TQP fail, status is %d.\n", ret);
- return ret;
+ "Map TQP fail, status is %d.\n", status);
+ return -EIO;
}
}
return 0;
}
-static int hclge_map_handle_ring_to_vector(
- struct hnae3_handle *handle, int vector,
- struct hnae3_ring_chain_node *ring_chain)
+sta
[PATCH net-next 6/8] net: hns3: Add mailbox support to PF driver
Command queue provides the provision of Mailbox command which
can be used for communication between PF and VF. PF handles
messages from various VFs for fetching various information like,
queue, vlan, link status related etc. It also handles the request
from various VFs to perform certain privileged operations.
This patch adds the support of a message handler for handling
such various command requests from VF.
Signed-off-by: Salil Mehta
Signed-off-by: lipeng
---
.../net/ethernet/hisilicon/hns3/hns3pf/Makefile| 2 +-
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 1 +
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 2 +
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c | 309 +
4 files changed, 313 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile
index d077fa02b66e..393a1b379efb 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/Makefile
@@ -5,6 +5,6 @@
ccflags-y := -Idrivers/net/ethernet/hisilicon/hns3
obj-$(CONFIG_HNS3_HCLGE) += hclge.o
-hclge-objs = hclge_main.o hclge_cmd.o hclge_mdio.o hclge_tm.o
+hclge-objs = hclge_main.o hclge_cmd.o hclge_mdio.o hclge_tm.o hclge_mbx.o
hclge-$(CONFIG_HNS3_DCB) += hclge_dcb.o
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 063be1c50a1d..af9d92a3800e 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -21,6 +21,7 @@
#include "hclge_cmd.h"
#include "hclge_dcb.h"
#include "hclge_main.h"
+#include "hclge_mbx.h"
#include "hclge_mdio.h"
#include "hclge_tm.h"
#include "hnae3.h"
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index aacec438b933..028817c7d67c 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
@@ -554,4 +554,6 @@ int hclge_set_vf_vlan_common(struct hclge_dev *vport, int
vfid,
int hclge_buffer_alloc(struct hclge_dev *hdev);
int hclge_rss_init_hw(struct hclge_dev *hdev);
+
+void hclge_mbx_handler(struct hclge_dev *hdev);
#endif
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
new file mode 100644
index ..da8b0c9ef353
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_mbx.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (c) 2016-2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include "hclge_main.h"
+#include "hclge_mbx.h"
+#include "hnae3.h"
+
+/* hclge_gen_resp_to_vf: used to generate a synchronous response to VF when PF
+ * receives a mailbox message from VF.
+ * @vport: pointer to struct hclge_vport
+ * @vf_to_pf_req: pointer to hclge_mbx_vf_to_pf_cmd of the original mailbox
+ * message
+ * @resp_status: indicate to VF whether its request success(0) or failed.
+ */
+static int hclge_gen_resp_to_vf(struct hclge_vport *vport,
+ struct hclge_mbx_vf_to_pf_cmd *vf_to_pf_req,
+ int resp_status,
+ u8 *resp_data, u16 resp_data_len)
+{
+ struct hclge_mbx_pf_to_vf_cmd *resp_pf_to_vf;
+ struct hclge_dev *hdev = vport->back;
+ enum hclge_cmd_status status;
+ struct hclge_desc desc;
+
+ resp_pf_to_vf = (struct hclge_mbx_pf_to_vf_cmd *)desc.data;
+
+ if (resp_data_len > HCLGE_MBX_MAX_RESP_DATA_SIZE) {
+ dev_err(&hdev->pdev->dev,
+ "PF fail to gen resp to VF len %d exceeds max len %d\n",
+ resp_data_len,
+ HCLGE_MBX_MAX_RESP_DATA_SIZE);
+ }
+
+ hclge_cmd_setup_basic_desc(&desc, HCLGEVF_OPC_MBX_PF_TO_VF, false);
+
+ resp_pf_to_vf->dest_vfid = cpu_to_le16(vf_to_pf_req->mbx_src_vfid);
+ resp_pf_to_vf->msg_len = vf_to_pf_req->msg_len;
+
+ resp_pf_to_vf->msg[0] = HCLGE_MBX_PF_VF_RESP;
+ resp_pf_to_vf->msg[1] = vf_to_pf_req->msg[0];
+ resp_pf_to_vf->msg[2] = vf_to_pf_req->msg[1];
+ resp_pf_to_vf->msg[3] = (resp_status == 0) ? 0 : 1;
+
+ if (resp_data && resp_data_len > 0)
+ memcpy(&resp_pf_to_vf->msg[4], resp_data, resp_data_len);
+
+ status = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (status)
+ dev_err(&hdev->pdev->dev,
+ "PF failed(=%d) to send response to VF\n", status);
+
+ return status;
+
[PATCH net-next 5/8] net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC
Most of the NAPI handling interface, skb buffer management,
management of the RX/TX descriptors, ethool interface etc.
has quite a bit of code which is common to VF and PF driver.
This patch makes the exisitng PF's HNS3 ENET driver as the
common ENET driver for both Virtual & Physical Function. This
will help in reduction of redundancy and better management of
code.
Signed-off-by: Salil Mehta
Signed-off-by: lipeng
---
drivers/net/ethernet/hisilicon/hns3/Makefile | 6 +-
drivers/net/ethernet/hisilicon/hns3/hnae3.c| 14 --
drivers/net/ethernet/hisilicon/hns3/hnae3.h| 7 ---
.../hisilicon/hns3/{hns3pf => }/hns3_dcbnl.c | 2 +-
.../hisilicon/hns3/{hns3pf => }/hns3_enet.c| 2 ++
.../hisilicon/hns3/{hns3pf => }/hns3_enet.h| 0
.../hisilicon/hns3/{hns3pf => }/hns3_ethtool.c | 22 +-
.../net/ethernet/hisilicon/hns3/hns3pf/Makefile| 5 -
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 1 +
9 files changed, 46 insertions(+), 13 deletions(-)
rename drivers/net/ethernet/hisilicon/hns3/{hns3pf => }/hns3_dcbnl.c (97%)
rename drivers/net/ethernet/hisilicon/hns3/{hns3pf => }/hns3_enet.c (99%)
rename drivers/net/ethernet/hisilicon/hns3/{hns3pf => }/hns3_enet.h (100%)
rename drivers/net/ethernet/hisilicon/hns3/{hns3pf => }/hns3_ethtool.c (97%)
diff --git a/drivers/net/ethernet/hisilicon/hns3/Makefile
b/drivers/net/ethernet/hisilicon/hns3/Makefile
index 244664b5f24f..48af9b1717f3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/Makefile
+++ b/drivers/net/ethernet/hisilicon/hns3/Makefile
@@ -1,8 +1,12 @@
#
# Makefile for the HISILICON network device drivers.
#
-
obj-$(CONFIG_HNS3) += hns3pf/
obj-$(CONFIG_HNS3) += hns3vf/
obj-$(CONFIG_HNS3) += hnae3.o
+
+obj-$(CONFIG_HNS3_ENET) += hns3.o
+hns3-objs = hns3_enet.o hns3_ethtool.o
+
+hns3-$(CONFIG_HNS3_DCB) += hns3_dcbnl.o
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
index 5bcb2238acb2..02145f2de820 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.c
@@ -196,9 +196,18 @@ int hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
const struct pci_device_id *id;
struct hnae3_ae_algo *ae_algo;
struct hnae3_client *client;
- int ret = 0;
+ int ret = 0, lock_acquired;
+
+ /* we can get deadlocked if SRIOV is being enabled in context to probe
+* and probe gets called again in same context. This can happen when
+* pci_enable_sriov() is called to create VFs from PF probes context.
+* Therefore, for simplicity uniformly defering further probing in all
+* cases where we detect contention.
+*/
+ lock_acquired = mutex_trylock(&hnae3_common_lock);
+ if (!lock_acquired)
+ return -EPROBE_DEFER;
- mutex_lock(&hnae3_common_lock);
list_add_tail(&ae_dev->node, &hnae3_ae_dev_list);
/* Check if there are matched ae_algo */
@@ -211,6 +220,7 @@ int hnae3_register_ae_dev(struct hnae3_ae_dev *ae_dev)
if (!ae_dev->ops) {
dev_err(&ae_dev->pdev->dev, "ae_dev ops are null\n");
+ ret = -EOPNOTSUPP;
goto out_err;
}
diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 67c59e1039f2..a9e2b32834c5 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -452,9 +452,10 @@ struct hnae3_unic_private_info {
struct hnae3_queue **tqp; /* array base of all TQPs of this instance */
};
-#define HNAE3_SUPPORT_MAC_LOOPBACK1
-#define HNAE3_SUPPORT_PHY_LOOPBACK2
-#define HNAE3_SUPPORT_SERDES_LOOPBACK 4
+#define HNAE3_SUPPORT_MAC_LOOPBACKBIT(0)
+#define HNAE3_SUPPORT_PHY_LOOPBACKBIT(1)
+#define HNAE3_SUPPORT_SERDES_LOOPBACK BIT(2)
+#define HNAE3_SUPPORT_VF BIT(3)
struct hnae3_handle {
struct hnae3_client *client;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_dcbnl.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_dcbnl.c
similarity index 97%
rename from drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_dcbnl.c
rename to drivers/net/ethernet/hisilicon/hns3/hns3_dcbnl.c
index 925619a7c50a..eb82700da7d0 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_dcbnl.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_dcbnl.c
@@ -93,7 +93,7 @@ void hns3_dcbnl_setup(struct hnae3_handle *handle)
{
struct net_device *dev = handle->kinfo.netdev;
- if (!handle->kinfo.dcb_ops)
+ if ((!handle->kinfo.dcb_ops) || (handle->flags & HNAE3_SUPPORT_VF))
return;
dev->dcbnl_ops = &hns3_dcbnl_ops;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
similarity index 99%
rename from drivers/net/ethernet
[PATCH net-next 2/8] net: hns3: Add mailbox support to VF driver
This patch adds the support of the mailbox to the VF driver. The
mailbox shall be used as an interface to communicate with the
PF driver for various purposes like {set|get} MAC related
operations, reset, link status etc. The mailbox supports both
synchronous and asynchronous command send to PF driver.
Signed-off-by: Salil Mehta
Signed-off-by: lipeng
---
drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h| 94 +++
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c | 187 +
2 files changed, 281 insertions(+)
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
new file mode 100644
index ..f9a5cf5ef28c
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
@@ -0,0 +1,94 @@
+/*
+ * Copyright (c) 2016-2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __HCLGE_MBX_H
+#define __HCLGE_MBX_H
+#include
+#include
+#include
+
+#define HCLGE_MBX_VF_MSG_DATA_NUM 16
+
+enum HCLGE_MBX_OPCODE {
+ HCLGE_MBX_RESET = 0x01, /* (VF -> PF) assert reset */
+ HCLGE_MBX_SET_UNICAST, /* (VF -> PF) set UC addr */
+ HCLGE_MBX_SET_MULTICAST,/* (VF -> PF) set MC addr */
+ HCLGE_MBX_SET_VLAN, /* (VF -> PF) set VLAN */
+ HCLGE_MBX_MAP_RING_TO_VECTOR, /* (VF -> PF) map ring-to-vector */
+ HCLGE_MBX_UNMAP_RING_TO_VECTOR, /* (VF -> PF) unamp ring-to-vector */
+ HCLGE_MBX_SET_PROMISC_MODE, /* (VF -> PF) set promiscuous mode */
+ HCLGE_MBX_SET_MACVLAN, /* (VF -> PF) set unicast filter */
+ HCLGE_MBX_API_NEGOTIATE,/* (VF -> PF) negotiate API version */
+ HCLGE_MBX_GET_QINFO,/* (VF -> PF) get queue config */
+ HCLGE_MBX_GET_TCINFO, /* (VF -> PF) get TC config */
+ HCLGE_MBX_GET_RETA, /* (VF -> PF) get RETA */
+ HCLGE_MBX_GET_RSS_KEY, /* (VF -> PF) get RSS key */
+ HCLGE_MBX_GET_MAC_ADDR, /* (VF -> PF) get MAC addr */
+ HCLGE_MBX_PF_VF_RESP, /* (PF -> VF) generate respone to VF */
+ HCLGE_MBX_GET_BDNUM,/* (VF -> PF) get BD num */
+ HCLGE_MBX_GET_BUFSIZE, /* (VF -> PF) get buffer size */
+ HCLGE_MBX_GET_STREAMID, /* (VF -> PF) get stream id */
+ HCLGE_MBX_SET_AESTART, /* (VF -> PF) start ae */
+ HCLGE_MBX_SET_TSOSTATS, /* (VF -> PF) get tso stats */
+ HCLGE_MBX_LINK_STAT_CHANGE, /* (PF -> VF) link status has changed */
+ HCLGE_MBX_GET_BASE_CONFIG, /* (VF -> PF) get config */
+ HCLGE_MBX_BIND_FUNC_QUEUE, /* (VF -> PF) bind function and queue */
+ HCLGE_MBX_GET_LINK_STATUS, /* (VF -> PF) get link status */
+ HCLGE_MBX_QUEUE_RESET, /* (VF -> PF) reset queue */
+};
+
+/* below are per-VF mac-vlan subcodes */
+enum hclge_mbx_mac_vlan_subcode {
+ HCLGE_MBX_MAC_VLAN_UC_MODIFY = 0, /* modify UC mac addr */
+ HCLGE_MBX_MAC_VLAN_UC_ADD, /* add a new UC mac addr */
+ HCLGE_MBX_MAC_VLAN_UC_REMOVE, /* remove a new UC mac addr */
+ HCLGE_MBX_MAC_VLAN_MC_MODIFY, /* modify MC mac addr */
+ HCLGE_MBX_MAC_VLAN_MC_ADD, /* add new MC mac addr */
+ HCLGE_MBX_MAC_VLAN_MC_REMOVE, /* remove MC mac addr */
+ HCLGE_MBX_MAC_VLAN_MC_FUNC_MTA_ENABLE, /* config func MTA enable */
+};
+
+/* below are per-VF vlan cfg subcodes */
+enum hclge_mbx_vlan_cfg_subcode {
+ HCLGE_MBX_VLAN_FILTER = 0, /* set vlan filter */
+ HCLGE_MBX_VLAN_TX_OFF_CFG, /* set tx side vlan offload */
+ HCLGE_MBX_VLAN_RX_OFF_CFG, /* set rx side vlan offload */
+};
+
+#define HCLGE_MBX_MAX_MSG_SIZE 16
+#define HCLGE_MBX_MAX_RESP_DATA_SIZE 8
+
+struct hclgevf_mbx_resp_status {
+ struct mutex mbx_mutex; /* protects against contending sync cmd resp */
+ u32 origin_mbx_msg;
+ bool received_resp;
+ int resp_status;
+ u8 additional_info[HCLGE_MBX_MAX_RESP_DATA_SIZE];
+};
+
+struct hclge_mbx_vf_to_pf_cmd {
+ u8 rsv;
+ u8 mbx_src_vfid; /* Auto filled by IMP */
+ u8 rsv1[2];
+ u8 msg_len;
+ u8 rsv2[3];
+ u8 msg[HCLGE_MBX_MAX_MSG_SIZE];
+};
+
+struct hclge_mbx_pf_to_vf_cmd {
+ u16 dest_vfid;
+ u8 rsv[2];
+ u8 msg_len;
+ u8 rsv1[3];
+ u16 msg[8];
+};
+
+#define hclge_mbx_ring_ptr_move_crq(crq) \
+ (crq->next_to_use = (crq->next_to_use + 1) % crq->desc_num)
+#endif
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_mbx.c
[PATCH net-next 4/8] net: hns3: Add HNS3 VF driver to kernel build framework
This patch introduces the new Makefiles and updates existing Makefiles required to build the HNS3 Virtual Function driver. This also updates the Kconfig for introduction of new menuconfig entries related to VF driver. Signed-off-by: Salil Mehta Signed-off-by: lipeng --- drivers/net/ethernet/hisilicon/Kconfig | 28 +++--- drivers/net/ethernet/hisilicon/hns3/Makefile | 1 + .../net/ethernet/hisilicon/hns3/hns3vf/Makefile| 8 +++ 3 files changed, 28 insertions(+), 9 deletions(-) create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile diff --git a/drivers/net/ethernet/hisilicon/Kconfig b/drivers/net/ethernet/hisilicon/Kconfig index 3b6aa7b8..8bcf470ff5f3 100644 --- a/drivers/net/ethernet/hisilicon/Kconfig +++ b/drivers/net/ethernet/hisilicon/Kconfig @@ -94,15 +94,6 @@ config HNS3_HCLGE compatibility layer. The engine would be used in Hisilicon hip08 family of SoCs and further upcoming SoCs. -config HNS3_ENET - tristate "Hisilicon HNS3 Ethernet Device Support" - depends on 64BIT && PCI - depends on HNS3 && HNS3_HCLGE - ---help--- - This selects the Ethernet Driver for Hisilicon Network Subsystem 3 for hip08 - family of SoCs. This module depends upon HNAE3 driver to access the HNAE3 - devices and their associated operations. - config HNS3_DCB bool "Hisilicon HNS3 Data Center Bridge Support" default n @@ -112,4 +103,23 @@ config HNS3_DCB If unsure, say N. +config HNS3_HCLGEVF +tristate "Hisilicon HNS3VF Acceleration Engine & Compatibility Layer Support" +depends on PCI_MSI +depends on HNS3 + depends on HNS3_HCLGE +---help--- + This selects the HNS3 VF drivers network acceleration engine & its hardware + compatibility layer. The engine would be used in Hisilicon hip08 family of + SoCs and further upcoming SoCs. + +config HNS3_ENET + tristate "Hisilicon HNS3 Ethernet Device Support" + depends on 64BIT && PCI + depends on HNS3 + ---help--- + This selects the Ethernet Driver for Hisilicon Network Subsystem 3 for hip08 + family of SoCs. This module depends upon HNAE3 driver to access the HNAE3 + devices and their associated operations. + endif # NET_VENDOR_HISILICON diff --git a/drivers/net/ethernet/hisilicon/hns3/Makefile b/drivers/net/ethernet/hisilicon/hns3/Makefile index a9349e1f3e51..244664b5f24f 100644 --- a/drivers/net/ethernet/hisilicon/hns3/Makefile +++ b/drivers/net/ethernet/hisilicon/hns3/Makefile @@ -3,5 +3,6 @@ # obj-$(CONFIG_HNS3) += hns3pf/ +obj-$(CONFIG_HNS3) += hns3vf/ obj-$(CONFIG_HNS3) += hnae3.o diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile b/drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile new file mode 100644 index ..a513d009de8a --- /dev/null +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/Makefile @@ -0,0 +1,8 @@ +# +# Makefile for the HISILICON network device drivers. +# + +ccflags-y := -Idrivers/net/ethernet/hisilicon/hns3 + +obj-$(CONFIG_HNS3_HCLGEVF) += hclgevf.o +hclgevf-objs = hclgevf_main.o hclgevf_cmd.o hclgevf_mbx.o \ No newline at end of file -- 2.11.0
[PATCH net-next 8/8] net: hns3: Add mailbox interrupt handling to PF driver
All PF mailbox events are conveyed through a common interrupt
(vector 0). This interrupt vector is shared by reset and mailbox.
This patch adds the handling of mailbox interrupt event and its
deferred processing in context to a separate mailbox task.
Signed-off-by: Salil Mehta
Signed-off-by: lipeng
---
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 66 --
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.h| 8 ++-
2 files changed, 69 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 7d9fa4e2b16a..58ef3cf94e3f 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2227,6 +2227,12 @@ static int hclge_mac_init(struct hclge_dev *hdev)
return hclge_cfg_func_mta_filter(hdev, 0, hdev->accept_mta_mc);
}
+static void hclge_mbx_task_schedule(struct hclge_dev *hdev)
+{
+ if (!test_and_set_bit(HCLGE_STATE_MBX_SERVICE_SCHED, &hdev->state))
+ schedule_work(&hdev->mbx_service_task);
+}
+
static void hclge_reset_task_schedule(struct hclge_dev *hdev)
{
if (!test_and_set_bit(HCLGE_STATE_RST_SERVICE_SCHED, &hdev->state))
@@ -2372,9 +2378,18 @@ static void hclge_service_complete(struct hclge_dev
*hdev)
static u32 hclge_check_event_cause(struct hclge_dev *hdev, u32 *clearval)
{
u32 rst_src_reg;
+ u32 cmdq_src_reg;
/* fetch the events from their corresponding regs */
rst_src_reg = hclge_read_dev(&hdev->hw, HCLGE_MISC_RESET_STS_REG);
+ cmdq_src_reg = hclge_read_dev(&hdev->hw, HCLGE_VECTOR0_CMDQ_SRC_REG);
+
+ /* Assumption: If by any chance reset and mailbox events are reported
+* together then we will only process reset event in this go and will
+* defer the processing of the mailbox events. Since, we would have not
+* cleared RX CMDQ event this time we would receive again another
+* interrupt from H/W just for the mailbox.
+*/
/* check for vector0 reset event sources */
if (BIT(HCLGE_VECTOR0_GLOBALRESET_INT_B) & rst_src_reg) {
@@ -2395,14 +2410,27 @@ static u32 hclge_check_event_cause(struct hclge_dev
*hdev, u32 *clearval)
return HCLGE_VECTOR0_EVENT_RST;
}
+ /* check for vector0 mailbox(=CMDQ RX) event source */
+ if (BIT(HCLGE_VECTOR0_RX_CMDQ_INT_B) & cmdq_src_reg) {
+ cmdq_src_reg &= ~BIT(HCLGE_VECTOR0_RX_CMDQ_INT_B);
+ *clearval = cmdq_src_reg;
+ return HCLGE_VECTOR0_EVENT_MBX;
+ }
+
return HCLGE_VECTOR0_EVENT_OTHER;
}
static void hclge_clear_event_cause(struct hclge_dev *hdev, u32 event_type,
u32 regclr)
{
- if (event_type == HCLGE_VECTOR0_EVENT_RST)
+ switch (event_type) {
+ case HCLGE_VECTOR0_EVENT_RST:
hclge_write_dev(&hdev->hw, HCLGE_MISC_RESET_STS_REG, regclr);
+ break;
+ case HCLGE_VECTOR0_EVENT_MBX:
+ hclge_write_dev(&hdev->hw, HCLGE_VECTOR0_CMDQ_SRC_REG, regclr);
+ break;
+ }
}
static void hclge_enable_vector(struct hclge_misc_vector *vector, bool enable)
@@ -2419,13 +2447,23 @@ static irqreturn_t hclge_misc_irq_handle(int irq, void
*data)
hclge_enable_vector(&hdev->misc_vector, false);
event_cause = hclge_check_event_cause(hdev, &clearval);
- /* vector 0 interrupt is shared with reset and mailbox source events.
-* For now, we are not handling mailbox events.
-*/
+ /* vector 0 interrupt is shared with reset and mailbox source events.*/
switch (event_cause) {
case HCLGE_VECTOR0_EVENT_RST:
hclge_reset_task_schedule(hdev);
break;
+ case HCLGE_VECTOR0_EVENT_MBX:
+ /* If we are here then,
+* 1. Either we are not handling any mbx task and we are not
+*scheduled as well
+*OR
+* 2. We could be handling a mbx task but nothing more is
+*scheduled.
+* In both cases, we should schedule mbx task as there are more
+* mbx messages reported by this interrupt.
+*/
+ hclge_mbx_task_schedule(hdev);
+
default:
dev_dbg(&hdev->pdev->dev,
"received unknown or unhandled event of vector0\n");
@@ -2704,6 +2742,21 @@ static void hclge_reset_service_task(struct work_struct
*work)
clear_bit(HCLGE_STATE_RST_HANDLING, &hdev->state);
}
+static void hclge_mailbox_service_task(struct work_struct *work)
+{
+ struct hclge_dev *hdev =
+ container_of(work, struct hclge_dev, mbx_service_task);
+
+ if (test_and_set_bit(HCLGE_STATE_MBX_HANDLING, &hdev->state))
+ return;
+
+ clear
[PATCH net-next 3/8] net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support
This patch adds the support of hardware compatibiltiy layer to the
HNS3 VF Driver. This layer implements various {set|get} operations
over MAC address for a virtual port, RSS related configuration,
fetches the link status info from PF, does various VLAN related
configuration over the virtual port, queries the statistics from
the hardware etc.
This layer can directly interact with hardware through the
IMP(Integrated Mangement Processor) interface or can use mailbox
to interact with the PF driver.
Signed-off-by: Salil Mehta
Signed-off-by: lipeng
---
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 1490
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h | 170 +++
2 files changed, 1660 insertions(+)
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.h
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
new file mode 100644
index ..dd721a0dae3c
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -0,0 +1,1490 @@
+/*
+ * Copyright (c) 2016-2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include "hclgevf_cmd.h"
+#include "hclgevf_main.h"
+#include "hclge_mbx.h"
+#include "hnae3.h"
+
+#define HCLGEVF_NAME "hclgevf"
+
+static struct hnae3_ae_algo ae_algovf;
+
+static const struct pci_device_id ae_algovf_pci_tbl[] = {
+ {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_100G_VF), 0},
+ {PCI_VDEVICE(HUAWEI, HNAE3_DEV_ID_100G_RDMA_DCB_PFC_VF), 0},
+ /* required last entry */
+ {0, }
+};
+
+static inline struct hclgevf_dev *hclgevf_ae_get_hdev(
+ struct hnae3_handle *handle)
+{
+ return container_of(handle, struct hclgevf_dev, nic);
+}
+
+static int hclgevf_tqps_update_stats(struct hnae3_handle *handle)
+{
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+ struct hclgevf_desc desc;
+ struct hnae3_queue *queue;
+ struct hclgevf_tqp *tqp;
+ int status;
+ int i;
+
+ for (i = 0; i < hdev->num_tqps; i++) {
+ queue = handle->kinfo.tqp[i];
+ tqp = container_of(queue, struct hclgevf_tqp, q);
+ hclgevf_cmd_setup_basic_desc(&desc,
+HCLGEVF_OPC_QUERY_RX_STATUS,
+true);
+
+ desc.data[0] = cpu_to_le32(tqp->index & 0x1ff);
+ status = hclgevf_cmd_send(&hdev->hw, &desc, 1);
+ if (status) {
+ dev_err(&hdev->pdev->dev,
+ "Query tqp stat fail, status = %d,queue = %d\n",
+ status, i);
+ return status;
+ }
+ tqp->tqp_stats.rcb_rx_ring_pktnum_rcd +=
+ le32_to_cpu(desc.data[4]);
+
+ hclgevf_cmd_setup_basic_desc(&desc, HCLGEVF_OPC_QUERY_TX_STATUS,
+true);
+
+ desc.data[0] = cpu_to_le32(tqp->index & 0x1ff);
+ status = hclgevf_cmd_send(&hdev->hw, &desc, 1);
+ if (status) {
+ dev_err(&hdev->pdev->dev,
+ "Query tqp stat fail, status = %d,queue = %d\n",
+ status, i);
+ return status;
+ }
+ tqp->tqp_stats.rcb_tx_ring_pktnum_rcd +=
+ le32_to_cpu(desc.data[4]);
+ }
+
+ return 0;
+}
+
+static u64 *hclgevf_tqps_get_stats(struct hnae3_handle *handle, u64 *data)
+{
+ struct hnae3_knic_private_info *kinfo = &handle->kinfo;
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+ struct hclgevf_tqp *tqp;
+ u64 *buff = data;
+ int i;
+
+ for (i = 0; i < hdev->num_tqps; i++) {
+ tqp = container_of(handle->kinfo.tqp[i], struct hclgevf_tqp, q);
+ *buff++ = cpu_to_le64(tqp->tqp_stats.rcb_tx_ring_pktnum_rcd);
+ }
+ for (i = 0; i < kinfo->num_tqps; i++) {
+ tqp = container_of(handle->kinfo.tqp[i], struct hclgevf_tqp, q);
+ *buff++ = cpu_to_le64(tqp->tqp_stats.rcb_rx_ring_pktnum_rcd);
+ }
+
+ return buff;
+}
+
+static int hclgevf_tqps_get_sset_count(struct hnae3_handle *handle, int strset)
+{
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+
+ return hdev->num_tqps * 2;
+}
+
+static u8 *hclgevf_tqps_get_strings(struct hnae3_handle *handle, u8 *data)
+{
+ struct hclgevf_dev *hdev = hclgevf_ae_get_hdev(handle);
+ u8 *buff = data;
+ int i = 0;
+
+ for
[PATCH net-next 1/8] net: hns3: Add HNS3 VF IMP(Integrated Management Proc) cmd interface
This patch adds support of command interface for communication with
the IMP(Integrated Management Processor) for HNS3 Virtual Function
Driver.
Each VF has support of CQP(Command Queue Pair) ring interface.
Each CQP consis of send queue CSQ and receive queue CRQ.
There are various commands a VF may support, like to query frimware
version, TQP management, statistics, interrupt related, mailbox etc.
This also contains code to initialize the command queue, manage the
command queue descriptors and Rx/Tx protocol with the command processor
in the form of various commands/results and acknowledgements.
Signed-off-by: Salil Mehta
Signed-off-by: lipeng
---
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 341 +
.../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h | 262
2 files changed, 603 insertions(+)
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
create mode 100644 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.h
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
new file mode 100644
index ..c5372a5a8c33
--- /dev/null
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -0,0 +1,341 @@
+/*
+ * Copyright (c) 2016-2017 Hisilicon Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "hclgevf_cmd.h"
+#include "hclgevf_main.h"
+#include "hnae3.h"
+
+#define hclgevf_is_csq(ring) ((ring)->flag & HCLGEVF_TYPE_CSQ)
+#define hclgevf_ring_to_dma_dir(ring) (hclgevf_is_csq(ring) ? \
+ DMA_TO_DEVICE : DMA_FROM_DEVICE)
+#define cmq_ring_to_dev(ring) (&(ring)->dev->pdev->dev)
+
+static int hclgevf_ring_space(struct hclgevf_cmq_ring *ring)
+{
+ int ntu = ring->next_to_use;
+ int ntc = ring->next_to_clean;
+ int used = (ntu - ntc + ring->desc_num) % ring->desc_num;
+
+ return ring->desc_num - used - 1;
+}
+
+static int hclgevf_cmd_csq_clean(struct hclgevf_hw *hw)
+{
+ struct hclgevf_cmq_ring *csq = &hw->cmq.csq;
+ u16 ntc = csq->next_to_clean;
+ struct hclgevf_desc *desc;
+ int clean = 0;
+ u32 head;
+
+ desc = &csq->desc[ntc];
+ head = hclgevf_read_dev(hw, HCLGEVF_NIC_CSQ_HEAD_REG);
+ while (head != ntc) {
+ memset(desc, 0, sizeof(*desc));
+ ntc++;
+ if (ntc == csq->desc_num)
+ ntc = 0;
+ desc = &csq->desc[ntc];
+ clean++;
+ }
+ csq->next_to_clean = ntc;
+
+ return clean;
+}
+
+static int hclgevf_cmd_csq_done(struct hclgevf_hw *hw)
+{
+ u32 head = hclgevf_read_dev(hw, HCLGEVF_NIC_CSQ_HEAD_REG);
+ return head == hw->cmq.csq.next_to_use;
+}
+
+static bool hclgevf_is_special_opcode(u16 opcode)
+{
+ u16 spec_opcode[] = {0x30, 0x31, 0x32};
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(spec_opcode); i++) {
+ if (spec_opcode[i] == opcode)
+ return true;
+ }
+
+ return false;
+}
+
+static int hclgevf_alloc_cmd_desc(struct hclgevf_cmq_ring *ring)
+{
+ int size = ring->desc_num * sizeof(struct hclgevf_desc);
+
+ ring->desc = kzalloc(size, GFP_KERNEL);
+ if (!ring->desc)
+ return -ENOMEM;
+
+ ring->desc_dma_addr = dma_map_single(cmq_ring_to_dev(ring), ring->desc,
+size, DMA_BIDIRECTIONAL);
+
+ if (dma_mapping_error(cmq_ring_to_dev(ring), ring->desc_dma_addr)) {
+ ring->desc_dma_addr = 0;
+ kfree(ring->desc);
+ ring->desc = NULL;
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void hclgevf_free_cmd_desc(struct hclgevf_cmq_ring *ring)
+{
+ dma_unmap_single(cmq_ring_to_dev(ring), ring->desc_dma_addr,
+ring->desc_num * sizeof(ring->desc[0]),
+hclgevf_ring_to_dma_dir(ring));
+ ring->desc_dma_addr = 0;
+ kfree(ring->desc);
+ ring->desc = NULL;
+}
+
+static int hclgevf_init_cmd_queue(struct hclgevf_dev *hdev,
+ struct hclgevf_cmq_ring *ring)
+{
+ struct hclgevf_hw *hw = &hdev->hw;
+ int ring_type = ring->flag;
+ u32 reg_val;
+ int ret;
+
+ ring->desc_num = HCLGEVF_NIC_CMQ_DESC_NUM;
+ spin_lock_init(&ring->lock);
+ ring->next_to_clean = 0;
+ ring->next_to_use = 0;
+ ring->dev = hdev;
+
+ /* allocate CSQ/CRQ descriptor */
+ ret = hclgevf_alloc_cmd_desc(ring);
+ if (ret) {
+ dev_err(&hdev->pdev->dev, "failed(%d) to alloc %s desc\n", ret,
+
Re: [PATCH 2/3, V2] kernel: Move groups_sort to the caller of set_groups.
Hi Thiago,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.15-rc1 next-20171201]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Thiago-Rafael-Becker/kernel-Move-groups_sort-to-the-caller-of-set_groups/20171203-191757
config: x86_64-randconfig-x011-201749 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
kernel/uid16.c: In function 'SYSC_setgroups16':
>> kernel/uid16.c:195:2: error: implicit declaration of function 'groups_sort';
>> did you mean 'cgroup_fork'? [-Werror=implicit-function-declaration]
groups_sort(group_info);
^~~
cgroup_fork
cc1: some warnings being treated as errors
vim +195 kernel/uid16.c
175
176 SYSCALL_DEFINE2(setgroups16, int, gidsetsize, old_gid_t __user *,
grouplist)
177 {
178 struct group_info *group_info;
179 int retval;
180
181 if (!may_setgroups())
182 return -EPERM;
183 if ((unsigned)gidsetsize > NGROUPS_MAX)
184 return -EINVAL;
185
186 group_info = groups_alloc(gidsetsize);
187 if (!group_info)
188 return -ENOMEM;
189 retval = groups16_from_user(group_info, grouplist);
190 if (retval) {
191 put_group_info(group_info);
192 return retval;
193 }
194
> 195 groups_sort(group_info);
196 retval = set_current_groups(group_info);
197 put_group_info(group_info);
198
199 return retval;
200 }
201
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
[question] handle the page table RAS error
Hi all, Sorry to disturb you. Now the ARM64 has supported the RAS, when enabling this feature, we encounter a issue. If the user space application happen page table RAS error, Memory error handler(memory_failure()) will do nothing except make a poisoned page flag, and fault handler in arch/arm64/mm/fault.c will deliver a signal to kill this application. when this application exit, it will call unmap_vmas () to release his vma resource, but here it will touch the error page table again, then will trigger RAS error again, so this application cannot be killed and system will be panic, the log is shown in [2]. As shown the stack in [1], unmap_page_range() will touch the error page table, so system will panic, does this panic behavior is expected? How the x86 handle the page table RAS error? If user space application happen page table RAS error, I think the expected behavior should be killing the application instead of panic OS. In current code, when release application vma resource, I do not see it will check whether table page is poisoned, could you give me some suggestion about how to handle this case? Thanks a lot. [1]: get_signal() do_group_exit() mmput() exit_mmap() unmap_vmas() unmap_single_vma() unmap_page_range() [2] [ 676.669053] Synchronous External Abort: level 0 (translation table walk) (0x82000214) at 0x33ff7008 [ 676.686469] Memory failure: 0xcd4b: already hardware poisoned [ 676.700652] Synchronous External Abort: synchronous external abort (0x96000410) at 0x33ff7008 [ 676.723301] Internal error: : 96000410 [#1] PREEMPT SMP [ 676.723616] Modules linked in: inject_memory_error(O) [ 676.724601] CPU: 0 PID: 1506 Comm: mca-recover Tainted: G O 4.14.0-rc8-00019-g5b5c6f4-dirty #109 [ 676.724844] task: 8cd41d00 task.stack: 09b3 [ 676.726616] PC is at unmap_page_range+0x78/0x6fc [ 676.726960] LR is at unmap_single_vma+0x88/0xdc [ 676.727122] pc : [] lr : [] pstate: 80400149 [ 676.727227] sp : 09b339b0 [ 676.727348] x29: 09b339b0 x28: 8cd41d00 [ 676.727653] x27: x26: 8cd42410 [ 676.727919] x25: 8cd41d00 x24: 8cd1e180 [ 676.728161] x23: 8ce22300 x22: [ 676.728407] x21: 09b33b28 x20: 0040 [ 676.728642] x19: 8cd1e180 x18: 016d [ 676.728875] x17: 0190 x16: 0064 [ 676.729117] x15: 0339 x14: [ 676.729344] x13: 61a8 x12: 0339 [ 676.729582] x11: 0018 x10: 0a80 [ 676.729829] x9 : 09b33c60 x8 : 8cd427e0 [ 676.730065] x7 : 09b33de8 x6 : 004a2000 [ 676.730287] x5 : 0040 x4 : 8cd4b000 [ 676.730517] x3 : 004a1fff x2 : 0080 [ 676.730741] x1 : 007f x0 : 0080 [ 676.731101] Process mca-recover (pid: 1506, stack limit = 0x09b3) [ 676.731281] Call trace: [ 676.734196] [] unmap_page_range+0x78/0x6fc [ 676.734539] [] unmap_single_vma+0x88/0xdc [ 676.734892] [] unmap_vmas+0x68/0xb4 [ 676.735456] [] exit_mmap+0x90/0x140 [ 676.736468] [] mmput+0x60/0x118 [ 676.736791] [] do_exit+0x240/0x9cc [ 676.736997] [] do_group_exit+0x38/0x98 [ 676.737384] [] get_signal+0x1ec/0x548 [ 676.738313] [] do_signal+0x7c/0x668 [ 676.738617] [] do_notify_resume+0xcc/0x114 [ 676.740983] [] work_pending+0x8/0x10 [ 676.741360] Code: f94043a4 f9404ba2 f94037a3 d1000441 (f9400080) [ 676.741745] ---[ end trace e42d453027313552 ]--- [ 676.804174] Fixing recursive fault but reboot is needed! [ 677.462082] Memory failure: 0xcd4b: already hardware poisoned
Re: [PATCH] cpu/hotplug: merge cpuhp_bp_states&cpuhp_ap_states as cpuhp_hp_states
On Sun, Dec 3, 2017 at 2:33 PM, Paul E. McKenney
wrote:
> On Fri, Dec 01, 2017 at 09:50:05PM +0800, Lai Jiangshan wrote:
>> cpuhp_bp_states&cpuhp_ap_states have diffent set of steps
>> without any conflicting configed steps, so that they can
>> be merged.
>>
>> The original `[CPUHP_BRINGUP_CPU] = { },` is removed, because
>> the new cpuhp_hp_states has CPUHP_ONLINE index which is larger
>> than CPUHP_BRINGUP_CPU.
>>
>> Signed-off-by: Lai Jiangshan
>
> Hello, Lai,
>
> What is this against? I tried testing it, but it doesn't apply to
> v4.15-rc1 or v4.14.
Hello, Paul,
It assumes my previous patch applied.
"smp/hotplug: move step CPUHP_AP_SMPCFD_DYING to the correct place"
https://www.spinics.net/lists/linux-tip-commits/msg41542.html
Thanks,
Lai
>
> Thanx, Paul
>
>> ---
>> kernel/cpu.c | 42 +++---
>> 1 file changed, 15 insertions(+), 27 deletions(-)
>>
>> diff --git a/kernel/cpu.c b/kernel/cpu.c
>> index 7891aecc6aec..c27963066333 100644
>> --- a/kernel/cpu.c
>> +++ b/kernel/cpu.c
>> @@ -124,8 +124,7 @@ struct cpuhp_step {
>> };
>>
>> static DEFINE_MUTEX(cpuhp_state_mutex);
>> -static struct cpuhp_step cpuhp_bp_states[];
>> -static struct cpuhp_step cpuhp_ap_states[];
>> +static struct cpuhp_step cpuhp_hp_states[];
>>
>> static bool cpuhp_is_ap_state(enum cpuhp_state state)
>> {
>> @@ -138,10 +137,7 @@ static bool cpuhp_is_ap_state(enum cpuhp_state state)
>>
>> static struct cpuhp_step *cpuhp_get_step(enum cpuhp_state state)
>> {
>> - struct cpuhp_step *sp;
>> -
>> - sp = cpuhp_is_ap_state(state) ? cpuhp_ap_states : cpuhp_bp_states;
>> - return sp + state;
>> + return cpuhp_hp_states + state;
>> }
>>
>> /**
>> @@ -1224,7 +1220,7 @@ int __boot_cpu_id;
>> #endif /* CONFIG_SMP */
>>
>> /* Boot processor state steps */
>> -static struct cpuhp_step cpuhp_bp_states[] = {
>> +static struct cpuhp_step cpuhp_hp_states[] = {
>> [CPUHP_OFFLINE] = {
>> .name = "offline",
>> .startup.single = NULL,
>> @@ -1289,24 +1285,6 @@ static struct cpuhp_step cpuhp_bp_states[] = {
>> .teardown.single= NULL,
>> .cant_stop = true,
>> },
>> - /*
>> - * Handled on controll processor until the plugged processor manages
>> - * this itself.
>> - */
>> - [CPUHP_TEARDOWN_CPU] = {
>> - .name = "cpu:teardown",
>> - .startup.single = NULL,
>> - .teardown.single= takedown_cpu,
>> - .cant_stop = true,
>> - },
>> -#else
>> - [CPUHP_BRINGUP_CPU] = { },
>> -#endif
>> -};
>> -
>> -/* Application processor state steps */
>> -static struct cpuhp_step cpuhp_ap_states[] = {
>> -#ifdef CONFIG_SMP
>> /* Final state before CPU kills itself */
>> [CPUHP_AP_IDLE_DEAD] = {
>> .name = "idle:dead",
>> @@ -1340,6 +1318,16 @@ static struct cpuhp_step cpuhp_ap_states[] = {
>> [CPUHP_AP_ONLINE] = {
>> .name = "ap:online",
>> },
>> + /*
>> + * Handled on controll processor until the plugged processor manages
>> + * this itself.
>> + */
>> + [CPUHP_TEARDOWN_CPU] = {
>> + .name = "cpu:teardown",
>> + .startup.single = NULL,
>> + .teardown.single= takedown_cpu,
>> + .cant_stop = true,
>> + },
>> /* Handle smpboot threads park/unpark */
>> [CPUHP_AP_SMPBOOT_THREADS] = {
>> .name = "smpboot/threads:online",
>> @@ -1408,11 +1396,11 @@ static int cpuhp_reserve_state(enum cpuhp_state
>> state)
>>
>> switch (state) {
>> case CPUHP_AP_ONLINE_DYN:
>> - step = cpuhp_ap_states + CPUHP_AP_ONLINE_DYN;
>> + step = cpuhp_hp_states + CPUHP_AP_ONLINE_DYN;
>> end = CPUHP_AP_ONLINE_DYN_END;
>> break;
>> case CPUHP_BP_PREPARE_DYN:
>> - step = cpuhp_bp_states + CPUHP_BP_PREPARE_DYN;
>> + step = cpuhp_hp_states + CPUHP_BP_PREPARE_DYN;
>> end = CPUHP_BP_PREPARE_DYN_END;
>> break;
>> default:
>> --
>> 2.13.6 (Apple Git-96)
>>
>
Re: [PATCH v6 4/6] dt: bindings: lp8860: Update the bindings to the standard
Dan,
On 12/01/2017 05:56 PM, Dan Murphy wrote:
> Update the lp8860 dt binding to the LED standard where
> the LED should have a child node and also adding a
> LED trigger entry.
>
> Signed-off-by: Dan Murphy
> ---
>
> v6 - New patch to fix binding documentation
>
> Documentation/devicetree/bindings/leds/leds-lp8860.txt | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
> b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
> index aad38dd94d4b..4cf396de6eba 100644
> --- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
> +++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
> @@ -12,17 +12,24 @@ Required properties:
> - label - Used for naming LEDs
>
> Optional properties:
> - - enable-gpio - gpio pin to enable/disable the device.
> - - supply - "vled" - LED supply
> + - enable-gpios : gpio pin to enable/disable the device.
> + - vled-supply : LED supply
> + - label : see Documentation/devicetree/bindings/leds/common.txt
> + - linux,default-trigger : (optional)
> +see Documentation/devicetree/bindings/leds/common.txt
>
> Example:
>
> -leds: leds@6 {
> +lp8860@2d {
> compatible = "ti,lp8860";
> reg = <0x2d>;
> - label = "display_cluster";
> enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> vled-supply = <&vbatt>;
> +
> + backlight: backlight@0 {
> + label = "backlight_cluster";
You'll need to change this to:
label = "white:backlight_cluster"
Please always cc your patches with DT bindings to
devicet...@vger.kernel.org and related maintainers.
> + linux,default-trigger = "backlight";
> + };
> }
>
> For more product information please see the link below:
>
--
Best regards,
Jacek Anaszewski
Re: KASAN: slab-out-of-bounds Read in strcmp
Tetsuo Handa wrote:
> which will allow strcmp() to trigger out of bound read when "size" is
> larger than strlen(initial_sid_to_string[i]).
Oops. "smaller" than.
>
> Thus, I guess the simplest fix is to use strncmp() instead of strcmp().
Can somebody test below patch? (My CentOS 7 environment does not support
enabling SELinux in linux.git . Userspace tool is too old to support?)
--
>From 3efab617f7c22360361a2bd89a0ccaf3bcd47951 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 3 Dec 2017 22:12:17 +0900
Subject: [PATCH] selinux: Fix out of bounds read at
security_context_to_sid_core()
Syzbot caught an out of bounds read at security_context_to_sid_core()
because security_context_to_sid_core() assumed that the value written to
/proc/pid/attr interface is terminated with either '\0' or '\n'.
When the value is not terminated with either '\0' or '\n' and
scontext_len < strlen(initial_sid_to_string[i]) is true, strcmp() will
trigger out of bounds read.
--
BUG: KASAN: slab-out-of-bounds in strcmp+0x96/0xb0 lib/string.c:328
Read of size 1 at addr 8801cd99d2c1 by task syzkaller242593/3087
CPU: 0 PID: 3087 Comm: syzkaller242593 Not tainted 4.15.0-rc1-next-20171201+ #57
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
strcmp+0x96/0xb0 lib/string.c:328
security_context_to_sid_core+0x437/0x620 security/selinux/ss/services.c:1420
security_context_to_sid+0x32/0x40 security/selinux/ss/services.c:1479
selinux_setprocattr+0x51c/0xb50 security/selinux/hooks.c:5986
security_setprocattr+0x85/0xc0 security/security.c:1264
proc_pid_attr_write+0x1e6/0x280 fs/proc/base.c:2574
__vfs_write+0xef/0x970 fs/read_write.c:480
__kernel_write+0xfe/0x350 fs/read_write.c:501
write_pipe_buf+0x175/0x220 fs/splice.c:797
splice_from_pipe_feed fs/splice.c:502 [inline]
__splice_from_pipe+0x328/0x730 fs/splice.c:626
splice_from_pipe+0x1e9/0x330 fs/splice.c:661
default_file_splice_write+0x40/0x90 fs/splice.c:809
do_splice_from fs/splice.c:851 [inline]
direct_splice_actor+0x125/0x180 fs/splice.c:1018
splice_direct_to_actor+0x2c1/0x820 fs/splice.c:973
do_splice_direct+0x2a7/0x3d0 fs/splice.c:1061
do_sendfile+0x5d5/0xe90 fs/read_write.c:1413
SYSC_sendfile64 fs/read_write.c:1468 [inline]
SyS_sendfile64+0xbd/0x160 fs/read_write.c:1460
entry_SYSCALL_64_fastpath+0x1f/0x96
--
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
---
security/selinux/ss/services.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index 33cfe5d..2b2ce3e 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1417,7 +1417,9 @@ static int security_context_to_sid_core(const char
*scontext, u32 scontext_len,
int i;
for (i = 1; i < SECINITSID_NUM; i++) {
- if (!strcmp(initial_sid_to_string[i], scontext)) {
+ if (!strncmp(initial_sid_to_string[i], scontext,
+scontext_len) &&
+ !initial_sid_to_string[i][scontext_len]) {
*sid = i;
return 0;
}
--
1.8.3.1
Re: [PATCH v6 1/6] leds: Add new API to derive a LED name
Dan,
On 12/01/2017 05:56 PM, Dan Murphy wrote:
> Create an API that is called to derive the
> LED name from either the DT label in the child
> node or if that does not exist from the parent
> node name and an alternate label that is passed in.
>
> Signed-off-by: Dan Murphy
> ---
>
> v6 - New patch to add the api to generate a LED label
>
> drivers/leds/led-class.c | 34 ++
> include/linux/leds.h | 6 ++
> 2 files changed, 40 insertions(+)
>
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index b0e2d55acbd6..d3e035488737 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -243,6 +244,39 @@ static int led_classdev_next_name(const char *init_name,
> char *name,
> return i;
> }
>
> +/**
> + * of_led_compose_name - derive the LED name based on DT or alternate name.
> + *
> + * @parent: parent of LED device
> + * @child: child node of LED device
> + * @alt_name: an alternate name if the label node is not found
> + * @len: length of the alt_name
> + * @led_name: derived name from either DT label or alt_name
> + */
> +void of_led_compose_name(struct device_node *parent,
> + struct device_node *child,
> + const char *alt_name,
> + size_t len,
> + char *led_name)
> +{
> + int ret;
> + int length;
> + const char *name;
> +
> + if (len == 0 || alt_name == NULL)
> + return;
> +
> + ret = of_property_read_string(child, "label", &name);
> + if (!ret) {
> + strlcpy(led_name, name, sizeof(led_name));
> + } else {
> + length = len + strlen(parent->name) + 1;
> + snprintf(led_name, len, "%s:%s", parent->name, alt_name);
> + }
It looks different from what I meant, i.e. that devicename
segment shouldn't be present in the label, but derived
from the parent DT node name.
This is however to be decided whether it wouldn't be better to leave
the decision to the driver on how to obtain devicename - from parent
DT node or from the driver hardcoded string. Some LED class drivers
prefer the latter way, so if their parent node name differs a bit from
the string they currently use for devicename, then the resulting
LED class device name will change after switching to using this
new API. In order to avoid that we would have to modify related
DT node names in *.dts files, which would make unnecessary noise.
Since it may take a while to agree on the final semantics
of this new API, especially after my recent patch [0], I propose
to put below piece of code directly in the driver:
ret = of_property_read_string(child_node, "label", &name);
if (!ret)
snprintf(led->label, sizeof(led->label), "%s:%s",
np->name, name)
else
snprintf(led->label, sizeof(led->label),
"%s::%s", np->name, name)
Please note that "::" means leaving colour section blank,
because we don't know the LED colour if label DT property was not
provided.
> +}
> +EXPORT_SYMBOL_GPL(of_led_compose_name);
> +
> /**
> * of_led_classdev_register - register a new object of led_classdev class.
> *
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index 5579c64c8fd6..9e18dbe196e2 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -123,6 +123,12 @@ struct led_classdev {
> struct mutexled_access;
> };
>
> +extern void of_led_compose_name(struct device_node *parent,
> + struct device_node *child,
> + const char *alt_name,
> + size_t len,
> + char *led_name);
> +
> extern int of_led_classdev_register(struct device *parent,
> struct device_node *np,
> struct led_classdev *led_cdev);
>
[0] https://patchwork.kernel.org/patch/10089047
--
Best regards,
Jacek Anaszewski
Re: [PATCH v4 2/2] arm64: Add software workaround for Falkor erratum 1041
Hi Will, thanks for your review comments. On 12/01/2017 05:24 AM, Will Deacon wrote: > On Mon, Nov 27, 2017 at 05:18:00PM -0600, Shanker Donthineni wrote: >> The ARM architecture defines the memory locations that are permitted >> to be accessed as the result of a speculative instruction fetch from >> an exception level for which all stages of translation are disabled. >> Specifically, the core is permitted to speculatively fetch from the >> 4KB region containing the current program counter 4K and next 4K. >> >> When translation is changed from enabled to disabled for the running >> exception level (SCTLR_ELn[M] changed from a value of 1 to 0), the >> Falkor core may errantly speculatively access memory locations outside >> of the 4KB region permitted by the architecture. The errant memory >> access may lead to one of the following unexpected behaviors. >> >> 1) A System Error Interrupt (SEI) being raised by the Falkor core due >>to the errant memory access attempting to access a region of memory >>that is protected by a slave-side memory protection unit. >> 2) Unpredictable device behavior due to a speculative read from device >>memory. This behavior may only occur if the instruction cache is >>disabled prior to or coincident with translation being changed from >>enabled to disabled. >> >> The conditions leading to this erratum will not occur when either of the >> following occur: >> 1) A higher exception level disables translation of a lower exception level >>(e.g. EL2 changing SCTLR_EL1[M] from a value of 1 to 0). >> 2) An exception level disabling its stage-1 translation if its stage-2 >> translation is enabled (e.g. EL1 changing SCTLR_EL1[M] from a value of 1 >> to 0 when HCR_EL2[VM] has a value of 1). >> >> To avoid the errant behavior, software must execute an ISB immediately >> prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0. >> >> Signed-off-by: Shanker Donthineni >> --- >> Changes since v3: >> Rebased to kernel v4.15-rc1. >> Changes since v2: >> Repost the corrected patches. >> Changes since v1: >> Apply the workaround where it's required. >> >> Documentation/arm64/silicon-errata.txt | 1 + >> arch/arm64/Kconfig | 12 +++- >> arch/arm64/include/asm/assembler.h | 19 +++ >> arch/arm64/include/asm/cpucaps.h | 3 ++- >> arch/arm64/kernel/cpu-reset.S | 1 + >> arch/arm64/kernel/cpu_errata.c | 16 >> arch/arm64/kernel/efi-entry.S | 2 ++ >> arch/arm64/kernel/head.S | 1 + >> arch/arm64/kernel/relocate_kernel.S| 1 + >> arch/arm64/kvm/hyp-init.S | 1 + > > This is an awful lot of code just to add an ISB instruction prior to > disabling the MMU. Why do you need to go through the alternatives framework > for this? Just do it with an #ifdef; this isn't a fastpath. > We can avoid changes to only two files cpu_errata.c and cpucaps.h without using the alternatives framework. Even though it's in slow path, cpu-errata.c changes provides a nice debug message which indicates the erratum E1041 is applied. Erratum log information would be very useful to conform our customers using the right kernel with E1014 patch by looking at dmesg. Other than that I don't have any other strong opinion to avoid alternatives and handle using #idef. Should I go head and post v5 patch without alternatives? > Will > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- Shanker Donthineni Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH v6 4/6] dt: bindings: lp8860: Update the bindings to the standard
Hi Dan,
Thanks for the patch.
On 12/01/2017 05:56 PM, Dan Murphy wrote:
> Update the lp8860 dt binding to the LED standard where
> the LED should have a child node and also adding a
> LED trigger entry.
>
> Signed-off-by: Dan Murphy
> ---
>
> v6 - New patch to fix binding documentation
>
> Documentation/devicetree/bindings/leds/leds-lp8860.txt | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
> b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
> index aad38dd94d4b..4cf396de6eba 100644
> --- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
> +++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
> @@ -12,17 +12,24 @@ Required properties:
> - label - Used for naming LEDs
>
> Optional properties:
> - - enable-gpio - gpio pin to enable/disable the device.
> - - supply - "vled" - LED supply
> + - enable-gpios : gpio pin to enable/disable the device.
> + - vled-supply : LED supply
> + - label : see Documentation/devicetree/bindings/leds/common.txt
> + - linux,default-trigger : (optional)
> +see Documentation/devicetree/bindings/leds/common.txt
Related driver doesn't parse this DT property AFAICS.
> Example:
>
> -leds: leds@6 {
> +lp8860@2d {
> compatible = "ti,lp8860";
> reg = <0x2d>;
> - label = "display_cluster";
> enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
s/gpio/gpios/
> vled-supply = <&vbatt>;
> +
> + backlight: backlight@0 {
> + label = "backlight_cluster";
> + linux,default-trigger = "backlight";
> + };
> }
>
> For more product information please see the link below:
>
--
Best regards,
Jacek Anaszewski
[PATCH] perf tools: set GUI mode after returning from perf_session__new()
If perf_session__new() returns NULL with use_browser set to 2 via --gtk option
previously, perf dies quietly without printing any errors.
The reason behind this is that GTK is not yet initialized when the caller
inside perf_session__new() is trying to print error message to the screen.
Reorder code to print the messages to stdio when GTK is not yet ready.
Signed-off-by: Song Seok Ho <0xdev...@gmail.com>
---
tools/perf/builtin-report.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 1394cd8d96f7..0cd80b8c432e 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -918,13 +918,6 @@ int cmd_report(int argc, const char **argv)
return -EINVAL;
}
- if (report.use_stdio)
- use_browser = 0;
- else if (report.use_tui)
- use_browser = 1;
- else if (report.use_gtk)
- use_browser = 2;
-
if (report.inverted_callchain)
callchain_param.order = ORDER_CALLER;
if (symbol_conf.cumulate_callchain && !callchain_param.order_set)
@@ -949,6 +942,13 @@ int cmd_report(int argc, const char **argv)
if (session == NULL)
return -1;
+ if (report.use_stdio)
+ use_browser = 0;
+ else if (report.use_tui)
+ use_browser = 1;
+ else if (report.use_gtk)
+ use_browser = 2;
+
if (report.queue_size) {
ordered_events__set_alloc_size(&session->ordered_events,
report.queue_size);
--
2.15.1
Re: [PATCH v6 5/6] leds: lp8860: Update the LED label generation
Dan,
On 12/01/2017 05:56 PM, Dan Murphy wrote:
> Fix the LED label generation for the LP8860 to
> conform with the
>
> Documentation/devicetree/bindings/leds/common.txt
>
> document indicating the LED label should be part of a
> child node to the device parent. If no label is
> in the child node then the LED label is created based
> on the parent node name and the alternate name passed in.
>
> Signed-off-by: Dan Murphy
> ---
>
> v6 - New patch to use the new LED class API
>
> drivers/leds/leds-lp8860.c | 27 +++
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
> index 3e70775a2d54..26bbfa144402 100644
> --- a/drivers/leds/leds-lp8860.c
> +++ b/drivers/leds/leds-lp8860.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #define LP8860_DISP_CL1_BRT_MSB 0x00
> #define LP8860_DISP_CL1_BRT_LSB 0x01
> @@ -86,8 +87,6 @@
>
> #define LP8860_CLEAR_FAULTS 0x01
>
> -#define LP8860_DISP_LED_NAME "display_cluster"
> -
> /**
> * struct lp8860_led -
> * @lock - Lock for reading/writing the device
> @@ -107,7 +106,7 @@ struct lp8860_led {
> struct regmap *eeprom_regmap;
> struct gpio_desc *enable_gpio;
> struct regulator *regulator;
> - const char *label;
> + char label[LED_MAX_NAME_SIZE];
> };
>
> struct lp8860_eeprom_reg {
> @@ -318,7 +317,7 @@ static const struct regmap_config lp8860_regmap_config = {
> .max_register = LP8860_EEPROM_UNLOCK,
> .reg_defaults = lp8860_reg_defs,
> .num_reg_defaults = ARRAY_SIZE(lp8860_reg_defs),
> - .cache_type = REGCACHE_NONE,
> + .cache_type = REGCACHE_RBTREE,
This seems to be an unrelated change.
Please split it to the separate patch and explain its merit.
> };
>
> static const struct reg_default lp8860_eeprom_defs[] = {
> @@ -356,7 +355,7 @@ static const struct regmap_config
> lp8860_eeprom_regmap_config = {
> .max_register = LP8860_EEPROM_REG_24,
> .reg_defaults = lp8860_eeprom_defs,
> .num_reg_defaults = ARRAY_SIZE(lp8860_eeprom_defs),
> - .cache_type = REGCACHE_NONE,
> + .cache_type = REGCACHE_RBTREE,
> };
>
> static int lp8860_probe(struct i2c_client *client,
> @@ -365,19 +364,23 @@ static int lp8860_probe(struct i2c_client *client,
> int ret;
> struct lp8860_led *led;
> struct device_node *np = client->dev.of_node;
> + struct device_node *child_node;
> +
> + if (!client->dev.of_node)
> + return -ENODEV;
>
> led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
> if (!led)
> return -ENOMEM;
>
> - led->label = LP8860_DISP_LED_NAME;
> + for_each_available_child_of_node(np, child_node) {
> + led->led_dev.default_trigger = of_get_property(child_node,
> + "linux,default-trigger",
> + NULL);
>
> - if (client->dev.of_node) {
> - ret = of_property_read_string(np, "label", &led->label);
> - if (ret) {
> - dev_err(&client->dev, "Missing label in dt\n");
> - return -EINVAL;
> - }
> + of_led_compose_name(np, child_node, "white:backlight",
> + sizeof("white:backlight"),
> + led->label);
Let's skip it for now.
Please also CC driver author always when you're modifying it.
> }
>
> led->enable_gpio = devm_gpiod_get_optional(&client->dev,
>
--
Best regards,
Jacek Anaszewski
[PATCH 00/10] staging: ccree: cleanups & fixes
Another batch of ccree work. Includes the usual mix of mostly cleanups and one fix. Also includes an updated TODO to reflect recent progress and removal of interim documentation of device tree strings as the official string and documentation thereof got blessed into the crypto tree. Gilad Ben-Yossef (10): staging: ccree: remove inline qualifiers staging: ccree: remove unproven likely/unlikely staging: ccree: remove more unnecessary parentheses staging: ccree: fix indentation of var assignment staging: ccree: remove braces for single statement blocks staging: ccree: remove interim DT docs staging: ccree: update TODO list staging: ccree: NULLify backup_info when unused staging: ccree: fix AEAD func naming convention staging: ccree: amend aead func def for readability .../devicetree/bindings/crypto/arm-cryptocell.txt | 27 - drivers/staging/ccree/TODO | 23 +- drivers/staging/ccree/ssi_aead.c | 706 ++--- drivers/staging/ccree/ssi_aead.h | 4 +- drivers/staging/ccree/ssi_buffer_mgr.c | 189 +++--- drivers/staging/ccree/ssi_cipher.c | 61 +- drivers/staging/ccree/ssi_driver.c | 40 +- drivers/staging/ccree/ssi_hash.c | 105 ++- drivers/staging/ccree/ssi_ivgen.c | 2 +- drivers/staging/ccree/ssi_request_mgr.c| 33 +- drivers/staging/ccree/ssi_sram_mgr.c | 4 +- 11 files changed, 541 insertions(+), 653 deletions(-) delete mode 100644 drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt -- 2.7.4
[PATCH 05/10] staging: ccree: remove braces for single statement blocks
Remove braces from single statement if clause.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_request_mgr.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/ccree/ssi_request_mgr.c
b/drivers/staging/ccree/ssi_request_mgr.c
index e890cb6..5f34336 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -228,9 +228,8 @@ static int request_mgr_queues_status_check(
for (poll_queue = 0; poll_queue < SSI_MAX_POLL_ITER ; poll_queue++) {
req_mgr_h->q_free_slots =
cc_ioread(drvdata, CC_REG(DSCRPTR_QUEUE_CONTENT));
- if (req_mgr_h->q_free_slots < req_mgr_h->min_free_hw_slots) {
+ if (req_mgr_h->q_free_slots < req_mgr_h->min_free_hw_slots)
req_mgr_h->min_free_hw_slots = req_mgr_h->q_free_slots;
- }
if (req_mgr_h->q_free_slots >= total_seq_len) {
/* If there is enough place return */
--
2.7.4
[PATCH 07/10] staging: ccree: update TODO list
Update the ccree staging TODO list in light of recent work. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/TODO | 23 ++- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/drivers/staging/ccree/TODO b/drivers/staging/ccree/TODO index c9f5754..f44edcd 100644 --- a/drivers/staging/ccree/TODO +++ b/drivers/staging/ccree/TODO @@ -6,25 +6,6 @@ * * * -ccree specific items -a.k.a stuff fixing for this driver to move out of staging -~ +1. Migrate sysfs to debugfs. +2. Handle HW FIFO fullness more cleanly. -1. Move to using Crypto Engine to handle backlog queueing. -2. Remove synchronous algorithm support leftovers. -3. Separate platform specific code for FIPS and power management into separate platform modules. -4. Drop legacy kernel support code. -5. Move most (all?) #ifdef CONFIG into inline functions. -6. Remove all unused definitions. -7. Re-factor to accomediate newer/older HW revisions besides the 712. -8. Handle the many checkpatch errors. -9. Implement ahash import/export correctly. -10. Go through a proper review of DT bindings and sysfs ABI -11. Sort out FIPS mode: bake tests into testmgr, sort out behaviour on error, -figure if 3DES weak key check is needed - -Kernel infrastructure items -a.k.a stuff we either neither need to fix in the kernel or understand what we're doing wrong - -1. ahash import/export context has a PAGE_SIZE/8 size limit. We need more. -2. Crypto Engine seems to be built for HW with hardware queue depth of 1, we have 600++. -- 2.7.4
[PATCH 04/10] staging: ccree: fix indentation of var assignment
Fix indentation of var assignment split across lines for
better readability.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 0b085dc..f214df7 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -1238,10 +1238,10 @@ static enum cc_flow_mode ssi_aead_get_data_flow_mode(
} else { /* Decrypt */
if (setup_flow_mode == S_DIN_to_AES)
data_flow_mode = is_single_pass ?
- AES_and_HASH : DIN_AES_DOUT;
+ AES_and_HASH : DIN_AES_DOUT;
else
data_flow_mode = is_single_pass ?
- DES_and_HASH : DIN_DES_DOUT;
+ DES_and_HASH : DIN_DES_DOUT;
}
return data_flow_mode;
--
2.7.4
[PATCH 01/10] staging: ccree: remove inline qualifiers
The ccree drivers was marking a lot of big functions in C file as static inline for no good reason. Remove the inline qualifier from any but the few truly single line functions. Signed-off-by: Gilad Ben-Yossef --- drivers/staging/ccree/ssi_aead.c| 40 - drivers/staging/ccree/ssi_buffer_mgr.c | 35 ++--- drivers/staging/ccree/ssi_cipher.c | 6 ++--- drivers/staging/ccree/ssi_hash.c| 2 +- drivers/staging/ccree/ssi_request_mgr.c | 4 ++-- 5 files changed, 43 insertions(+), 44 deletions(-) diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c index 2cd2b0f..56a4059 100644 --- a/drivers/staging/ccree/ssi_aead.c +++ b/drivers/staging/ccree/ssi_aead.c @@ -733,7 +733,7 @@ static int ssi_ccm_setauthsize(struct crypto_aead *authenc, } #endif /*SSI_CC_HAS_AES_CCM*/ -static inline void +static void ssi_aead_create_assoc_desc( struct aead_request *areq, unsigned int flow_mode, @@ -776,7 +776,7 @@ ssi_aead_create_assoc_desc( *seq_size = (++idx); } -static inline void +static void ssi_aead_process_authenc_data_desc( struct aead_request *areq, unsigned int flow_mode, @@ -843,7 +843,7 @@ ssi_aead_process_authenc_data_desc( *seq_size = (++idx); } -static inline void +static void ssi_aead_process_cipher_data_desc( struct aead_request *areq, unsigned int flow_mode, @@ -891,7 +891,7 @@ ssi_aead_process_cipher_data_desc( *seq_size = (++idx); } -static inline void ssi_aead_process_digest_result_desc( +static void ssi_aead_process_digest_result_desc( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -942,7 +942,7 @@ static inline void ssi_aead_process_digest_result_desc( *seq_size = (++idx); } -static inline void ssi_aead_setup_cipher_desc( +static void ssi_aead_setup_cipher_desc( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -988,7 +988,7 @@ static inline void ssi_aead_setup_cipher_desc( *seq_size = idx; } -static inline void ssi_aead_process_cipher( +static void ssi_aead_process_cipher( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size, @@ -1014,7 +1014,7 @@ static inline void ssi_aead_process_cipher( *seq_size = idx; } -static inline void ssi_aead_hmac_setup_digest_desc( +static void ssi_aead_hmac_setup_digest_desc( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -1051,7 +1051,7 @@ static inline void ssi_aead_hmac_setup_digest_desc( *seq_size = idx; } -static inline void ssi_aead_xcbc_setup_digest_desc( +static void ssi_aead_xcbc_setup_digest_desc( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -1113,7 +1113,7 @@ static inline void ssi_aead_xcbc_setup_digest_desc( *seq_size = idx; } -static inline void ssi_aead_process_digest_header_desc( +static void ssi_aead_process_digest_header_desc( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -1127,7 +1127,7 @@ static inline void ssi_aead_process_digest_header_desc( *seq_size = idx; } -static inline void ssi_aead_process_digest_scheme_desc( +static void ssi_aead_process_digest_scheme_desc( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -1192,7 +1192,7 @@ static inline void ssi_aead_process_digest_scheme_desc( *seq_size = idx; } -static inline void ssi_aead_load_mlli_to_sram( +static void ssi_aead_load_mlli_to_sram( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -1222,7 +1222,7 @@ static inline void ssi_aead_load_mlli_to_sram( } } -static inline enum cc_flow_mode ssi_aead_get_data_flow_mode( +static enum cc_flow_mode ssi_aead_get_data_flow_mode( enum drv_crypto_direction direct, enum cc_flow_mode setup_flow_mode, bool is_single_pass) @@ -1248,7 +1248,7 @@ static inline enum cc_flow_mode ssi_aead_get_data_flow_mode( return data_flow_mode; } -static inline void ssi_aead_hmac_authenc( +static void ssi_aead_hmac_authenc( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -1304,7 +1304,7 @@ static inline void ssi_aead_hmac_authenc( } } -static inline void +static void ssi_aead_xcbc_authenc( struct aead_request *req, struct cc_hw_desc desc[], @@ -1456,7 +1456,7 @@ static int set_msg_len(u8 *block, unsigned int msglen, unsigned int csize) return 0; } -static inline int ssi_aead_ccm( +static int ssi_aead_ccm( struct aead_request *req, struct cc_hw_desc desc[], unsigned int *seq_size) @@ -1667,7 +1667,7 @@ static void ssi_rfc4309_ccm
[PATCH 02/10] staging: ccree: remove unproven likely/unlikely
The ccree code made a lot of use of likely/unlikely qualifiers without
proven measurements showing any benefits. Remove them all until we
see what is justified and what is not.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 57 ++--
drivers/staging/ccree/ssi_buffer_mgr.c | 154 +++-
drivers/staging/ccree/ssi_cipher.c | 54 +--
drivers/staging/ccree/ssi_driver.c | 34 +++
drivers/staging/ccree/ssi_hash.c| 103 ++---
drivers/staging/ccree/ssi_ivgen.c | 2 +-
drivers/staging/ccree/ssi_request_mgr.c | 28 +++---
drivers/staging/ccree/ssi_sram_mgr.c| 4 +-
8 files changed, 209 insertions(+), 227 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 56a4059..0b085dc 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -251,7 +251,7 @@ static void ssi_aead_complete(struct device *dev, void
*ssi_req)
err = -EBADMSG;
}
} else { /*ENCRYPT*/
- if (unlikely(areq_ctx->is_icv_fragmented)) {
+ if (areq_ctx->is_icv_fragmented) {
u32 skip = areq->cryptlen + areq_ctx->dst_offset;
cc_copy_sg_portion(dev, areq_ctx->mac_buf,
@@ -412,7 +412,7 @@ static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
return -EINVAL;
}
/* Check cipher key size */
- if (unlikely(ctx->flow_mode == S_DIN_to_DES)) {
+ if (ctx->flow_mode == S_DIN_to_DES) {
if (ctx->enc_keylen != DES3_EDE_KEY_SIZE) {
dev_err(dev, "Invalid cipher(3DES) key size: %u\n",
ctx->enc_keylen);
@@ -465,10 +465,10 @@ ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8
*key,
hashmode = DRV_HASH_HW_SHA256;
}
- if (likely(keylen != 0)) {
+ if (keylen != 0) {
key_dma_addr = dma_map_single(dev, (void *)key, keylen,
DMA_TO_DEVICE);
- if (unlikely(dma_mapping_error(dev, key_dma_addr))) {
+ if (dma_mapping_error(dev, key_dma_addr)) {
dev_err(dev, "Mapping key va=0x%p len=%u for DMA
failed\n",
key, keylen);
return -ENOMEM;
@@ -547,10 +547,10 @@ ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8
*key,
}
rc = send_request(ctx->drvdata, &ssi_req, desc, idx, 0);
- if (unlikely(rc))
+ if (rc)
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
- if (likely(key_dma_addr))
+ if (key_dma_addr)
dma_unmap_single(dev, key_dma_addr, keylen, DMA_TO_DEVICE);
return rc;
@@ -607,7 +607,7 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key,
unsigned int keylen)
}
rc = validate_keys_sizes(ctx);
- if (unlikely(rc))
+ if (rc)
goto badkey;
/* STAT_PHASE_1: Copy key to ctx */
@@ -646,7 +646,7 @@ ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key,
unsigned int keylen)
if (seq_len > 0) { /* For CCM there is no sequence to setup the key */
rc = send_request(ctx->drvdata, &ssi_req, desc, seq_len, 0);
- if (unlikely(rc)) {
+ if (rc) {
dev_err(dev, "send_request() failed (rc=%d)\n", rc);
goto setkey_error;
}
@@ -818,7 +818,7 @@ ssi_aead_process_authenc_data_desc(
ssi_sram_addr_t mlli_addr = areq_ctx->assoc.sram_addr;
u32 mlli_nents = areq_ctx->assoc.mlli_nents;
- if (likely(areq_ctx->is_single_pass)) {
+ if (areq_ctx->is_single_pass) {
if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) {
mlli_addr = areq_ctx->dst.sram_addr;
mlli_nents = areq_ctx->dst.mlli_nents;
@@ -1202,10 +1202,9 @@ static void ssi_aead_load_mlli_to_sram(
struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct device *dev = drvdata_to_dev(ctx->drvdata);
- if (unlikely(
- req_ctx->assoc_buff_type == SSI_DMA_BUF_MLLI ||
- req_ctx->data_buff_type == SSI_DMA_BUF_MLLI ||
- !req_ctx->is_single_pass)) {
+ if (req_ctx->assoc_buff_type == SSI_DMA_BUF_MLLI ||
+ req_ctx->data_buff_type == SSI_DMA_BUF_MLLI ||
+ !req_ctx->is_single_pass) {
dev_dbg(dev, "Copy-to-sram: mlli_dma=%08x, mlli_size=%u\n",
(unsigned int)ctx->drvdata->mlli_sram_addr,
req_ctx->mlli_params.mlli_len);
@@ -1231,17 +1230,17 @@ static enum cc_flow_mode ssi_aead_get_data_flow_mode(
if (direct == DRV_CRYPTO_DIRECTION_ENCRYPT) {
if (set
[PATCH 08/10] staging: ccree: NULLify backup_info when unused
backup_info field is only allocated for decrypt code path.
The field was not nullified when not used causing a kfree
in an error handling path to attempt to free random
addresses as uncovered in stress testing.
Fixes: 737aed947f9b ("staging: ccree: save ciphertext for CTS IV")
Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_cipher.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/ccree/ssi_cipher.c
b/drivers/staging/ccree/ssi_cipher.c
index 9019615..7b484f1 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -907,6 +907,7 @@ static int ssi_ablkcipher_encrypt(struct ablkcipher_request
*req)
unsigned int ivsize = crypto_ablkcipher_ivsize(ablk_tfm);
req_ctx->is_giv = false;
+ req_ctx->backup_info = NULL;
return ssi_blkcipher_process(tfm, req_ctx, req->dst, req->src,
req->nbytes, req->info, ivsize,
--
2.7.4
[PATCH 10/10] staging: ccree: amend aead func def for readability
Func definitions in the aead implementation were did not adhere to
coding style. Fix them for better readability.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 141 ++-
1 file changed, 51 insertions(+), 90 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index 54edd99..5548c7b 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -678,9 +678,8 @@ static int cc_rfc4309_ccm_setkey(struct crypto_aead *tfm,
const u8 *key,
}
#endif /*SSI_CC_HAS_AES_CCM*/
-static int cc_aead_setauthsize(
- struct crypto_aead *authenc,
- unsigned int authsize)
+static int cc_aead_setauthsize(struct crypto_aead *authenc,
+ unsigned int authsize)
{
struct cc_aead_ctx *ctx = crypto_aead_ctx(authenc);
struct device *dev = drvdata_to_dev(ctx->drvdata);
@@ -733,12 +732,8 @@ static int cc_ccm_setauthsize(struct crypto_aead *authenc,
}
#endif /*SSI_CC_HAS_AES_CCM*/
-static void
-cc_set_assoc_desc(
- struct aead_request *areq,
- unsigned int flow_mode,
- struct cc_hw_desc desc[],
- unsigned int *seq_size)
+static void cc_set_assoc_desc(struct aead_request *areq, unsigned int
flow_mode,
+ struct cc_hw_desc desc[], unsigned int *seq_size)
{
struct crypto_aead *tfm = crypto_aead_reqtfm(areq);
struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
@@ -776,13 +771,10 @@ cc_set_assoc_desc(
*seq_size = (++idx);
}
-static void
-cc_proc_authen_desc(
- struct aead_request *areq,
- unsigned int flow_mode,
- struct cc_hw_desc desc[],
- unsigned int *seq_size,
- int direct)
+static void cc_proc_authen_desc(struct aead_request *areq,
+ unsigned int flow_mode,
+ struct cc_hw_desc desc[],
+ unsigned int *seq_size, int direct)
{
struct aead_req_ctx *areq_ctx = aead_request_ctx(areq);
enum ssi_req_dma_buf_type data_dma_type = areq_ctx->data_buff_type;
@@ -843,12 +835,10 @@ cc_proc_authen_desc(
*seq_size = (++idx);
}
-static void
-cc_proc_cipher_desc(
- struct aead_request *areq,
- unsigned int flow_mode,
- struct cc_hw_desc desc[],
- unsigned int *seq_size)
+static void cc_proc_cipher_desc(struct aead_request *areq,
+ unsigned int flow_mode,
+ struct cc_hw_desc desc[],
+ unsigned int *seq_size)
{
unsigned int idx = *seq_size;
struct aead_req_ctx *areq_ctx = aead_request_ctx(areq);
@@ -891,10 +881,9 @@ cc_proc_cipher_desc(
*seq_size = (++idx);
}
-static void cc_proc_digest_desc(
- struct aead_request *req,
- struct cc_hw_desc desc[],
- unsigned int *seq_size)
+static void cc_proc_digest_desc(struct aead_request *req,
+ struct cc_hw_desc desc[],
+ unsigned int *seq_size)
{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
@@ -942,10 +931,9 @@ static void cc_proc_digest_desc(
*seq_size = (++idx);
}
-static void cc_set_cipher_desc(
- struct aead_request *req,
- struct cc_hw_desc desc[],
- unsigned int *seq_size)
+static void cc_set_cipher_desc(struct aead_request *req,
+ struct cc_hw_desc desc[],
+ unsigned int *seq_size)
{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
@@ -988,11 +976,8 @@ static void cc_set_cipher_desc(
*seq_size = idx;
}
-static void cc_proc_cipher(
- struct aead_request *req,
- struct cc_hw_desc desc[],
- unsigned int *seq_size,
- unsigned int data_flow_mode)
+static void cc_proc_cipher(struct aead_request *req, struct cc_hw_desc desc[],
+ unsigned int *seq_size, unsigned int data_flow_mode)
{
struct aead_req_ctx *req_ctx = aead_request_ctx(req);
int direct = req_ctx->gen_ctx.op_type;
@@ -1014,10 +999,8 @@ static void cc_proc_cipher(
*seq_size = idx;
}
-static void cc_set_hmac_desc(
- struct aead_request *req,
- struct cc_hw_desc desc[],
- unsigned int *seq_size)
+static void cc_set_hmac_desc(struct aead_request *req, struct cc_hw_desc
desc[],
+unsigned int *seq_size)
{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
@@ -1051,10 +1034,8 @@ static void cc_set_hmac_desc(
*seq_size = idx;
}
-static void cc_set_xcbc_desc(
- struct aead_request *req,
- struct cc_hw_desc desc[],
- unsigned int *seq_size)
+static void cc_set_xcbc_desc(struct aead_request *req,
[PATCH 09/10] staging: ccree: fix AEAD func naming convention
The aead files was using a func naming convention which was inconsistent
(ssi vs. cc), included a useless prefix (ssi_aead) and often used
too long function names producing monster func names such as
ssi_aead_gcm_setup_ghash_desc() that made the call site code hard
to read.
Make the code more readable by switching to a simpler, consistent naming
conventionfor all the function defined in the file.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c | 544 ++---
drivers/staging/ccree/ssi_aead.h | 4 +-
drivers/staging/ccree/ssi_driver.c | 6 +-
3 files changed, 273 insertions(+), 281 deletions(-)
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/ssi_aead.c
index f214df7..54edd99 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/ssi_aead.c
@@ -51,7 +51,7 @@
/* Value of each ICV_CMP byte (of 8) in case of success */
#define ICV_VERIF_OK 0x01
-struct ssi_aead_handle {
+struct cc_aead_handle {
ssi_sram_addr_t sram_workspace_addr;
struct list_head aead_list;
};
@@ -68,7 +68,7 @@ struct cc_xcbc_s {
dma_addr_t xcbc_keys_dma_addr;
};
-struct ssi_aead_ctx {
+struct cc_aead_ctx {
struct ssi_drvdata *drvdata;
u8 ctr_nonce[MAX_NONCE_SIZE]; /* used for ctr3686 iv and aes ccm */
u8 *enckey;
@@ -90,9 +90,9 @@ static inline bool valid_assoclen(struct aead_request *req)
return ((req->assoclen == 16) || (req->assoclen == 20));
}
-static void ssi_aead_exit(struct crypto_aead *tfm)
+static void cc_aead_exit(struct crypto_aead *tfm)
{
- struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
+ struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct device *dev = drvdata_to_dev(ctx->drvdata);
dev_dbg(dev, "Clearing context @%p for %s\n", crypto_aead_ctx(tfm),
@@ -144,10 +144,10 @@ static void ssi_aead_exit(struct crypto_aead *tfm)
}
}
-static int ssi_aead_init(struct crypto_aead *tfm)
+static int cc_aead_init(struct crypto_aead *tfm)
{
struct aead_alg *alg = crypto_aead_alg(tfm);
- struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
+ struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct ssi_crypto_alg *ssi_alg =
container_of(alg, struct ssi_crypto_alg, aead_alg);
struct device *dev = drvdata_to_dev(ssi_alg->drvdata);
@@ -222,16 +222,16 @@ static int ssi_aead_init(struct crypto_aead *tfm)
return 0;
init_failed:
- ssi_aead_exit(tfm);
+ cc_aead_exit(tfm);
return -ENOMEM;
}
-static void ssi_aead_complete(struct device *dev, void *ssi_req)
+static void cc_aead_complete(struct device *dev, void *ssi_req)
{
struct aead_request *areq = (struct aead_request *)ssi_req;
struct aead_req_ctx *areq_ctx = aead_request_ctx(areq);
struct crypto_aead *tfm = crypto_aead_reqtfm(ssi_req);
- struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
+ struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
int err = 0;
cc_unmap_aead_request(dev, areq);
@@ -277,7 +277,7 @@ static void ssi_aead_complete(struct device *dev, void
*ssi_req)
aead_request_complete(areq, err);
}
-static int xcbc_setkey(struct cc_hw_desc *desc, struct ssi_aead_ctx *ctx)
+static int xcbc_setkey(struct cc_hw_desc *desc, struct cc_aead_ctx *ctx)
{
/* Load the AES key */
hw_desc_init(&desc[0]);
@@ -317,7 +317,7 @@ static int xcbc_setkey(struct cc_hw_desc *desc, struct
ssi_aead_ctx *ctx)
return 4;
}
-static int hmac_setkey(struct cc_hw_desc *desc, struct ssi_aead_ctx *ctx)
+static int hmac_setkey(struct cc_hw_desc *desc, struct cc_aead_ctx *ctx)
{
unsigned int hmac_pad_const[2] = { HMAC_IPAD_CONST, HMAC_OPAD_CONST };
unsigned int digest_ofs = 0;
@@ -386,7 +386,7 @@ static int hmac_setkey(struct cc_hw_desc *desc, struct
ssi_aead_ctx *ctx)
return idx;
}
-static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
+static int validate_keys_sizes(struct cc_aead_ctx *ctx)
{
struct device *dev = drvdata_to_dev(ctx->drvdata);
@@ -435,11 +435,11 @@ static int validate_keys_sizes(struct ssi_aead_ctx *ctx)
* (copy to intenral buffer or hash in case of key longer than block
*/
static int
-ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8 *key,
- unsigned int keylen)
+cc_get_plain_hmac_key(struct crypto_aead *tfm, const u8 *key,
+ unsigned int keylen)
{
dma_addr_t key_dma_addr = 0;
- struct ssi_aead_ctx *ctx = crypto_aead_ctx(tfm);
+ struct cc_aead_ctx *ctx = crypto_aead_ctx(tfm);
struct device *dev = drvdata_to_dev(ctx->drvdata);
u32 larval_addr = cc_larval_digest_addr(ctx->drvdata, ctx->auth_mode);
struct ssi_crypto_req ssi_req = {};
@@ -557,9 +557,9 @@ ssi_get_plain_hmac_key(struct crypto_aead *tfm, const u8
*key,
}
static int
-ssi_aead_setkey(struct crypto_aead *tfm, const u8 *key
[PATCH 06/10] staging: ccree: remove interim DT docs
As proper DT bindings doc where submitted and ACKed,
remove the interim one.
Signed-off-by: Gilad Ben-Yossef
---
.../devicetree/bindings/crypto/arm-cryptocell.txt | 27 --
1 file changed, 27 deletions(-)
delete mode 100644
drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
diff --git
a/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
b/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
deleted file mode 100644
index 2ea6517..000
---
a/drivers/staging/ccree/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
+++ /dev/null
@@ -1,27 +0,0 @@
-Arm TrustZone CryptoCell cryptographic accelerators
-
-Required properties:
-- compatible: must be "arm,cryptocell-712-ree".
-- reg: shall contain base register location and length.
- Typically length is 0x1.
-- interrupts: shall contain the interrupt for the device.
-
-Optional properties:
-- interrupt-parent: can designate the interrupt controller the
- device interrupt is connected to, if needed.
-- clocks: may contain the clock handling the device, if needed.
-- power-domains: may contain a reference to the PM domain, if applicable.
-
-
-Examples:
-
-Zynq FPGA device
-
-
- arm_cc7x: arm_cc7x@8000 {
- compatible = "arm,cryptocell-712-ree";
- interrupt-parent = <&intc>;
- interrupts = < 0 30 4 >;
- reg = < 0x8000 0x1 >;
- };
-
--
2.7.4
Re: [PATCH v6 5/6] leds: lp8860: Update the LED label generation
Dan,
On 12/01/2017 05:59 PM, Dan Murphy wrote:
> On 12/01/2017 10:56 AM, Dan Murphy wrote:
>> Fix the LED label generation for the LP8860 to
>> conform with the
>>
>> Documentation/devicetree/bindings/leds/common.txt
>>
>> document indicating the LED label should be part of a
>> child node to the device parent. If no label is
>> in the child node then the LED label is created based
>> on the parent node name and the alternate name passed in.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v6 - New patch to use the new LED class API
>>
>> drivers/leds/leds-lp8860.c | 27 +++
>> 1 file changed, 15 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/leds/leds-lp8860.c b/drivers/leds/leds-lp8860.c
>> index 3e70775a2d54..26bbfa144402 100644
>> --- a/drivers/leds/leds-lp8860.c
>> +++ b/drivers/leds/leds-lp8860.c
>> @@ -22,6 +22,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #define LP8860_DISP_CL1_BRT_MSB 0x00
>> #define LP8860_DISP_CL1_BRT_LSB 0x01
>> @@ -86,8 +87,6 @@
>>
>> #define LP8860_CLEAR_FAULTS 0x01
>>
>> -#define LP8860_DISP_LED_NAME"display_cluster"
>> -
>> /**
>> * struct lp8860_led -
>> * @lock - Lock for reading/writing the device
>> @@ -107,7 +106,7 @@ struct lp8860_led {
>> struct regmap *eeprom_regmap;
>> struct gpio_desc *enable_gpio;
>> struct regulator *regulator;
>> -const char *label;
>> +char label[LED_MAX_NAME_SIZE];
>> };
>>
>> struct lp8860_eeprom_reg {
>> @@ -318,7 +317,7 @@ static const struct regmap_config lp8860_regmap_config =
>> {
>> .max_register = LP8860_EEPROM_UNLOCK,
>> .reg_defaults = lp8860_reg_defs,
>> .num_reg_defaults = ARRAY_SIZE(lp8860_reg_defs),
>> -.cache_type = REGCACHE_NONE,
>> +.cache_type = REGCACHE_RBTREE,
>> };
>>
>> static const struct reg_default lp8860_eeprom_defs[] = {
>> @@ -356,7 +355,7 @@ static const struct regmap_config
>> lp8860_eeprom_regmap_config = {
>> .max_register = LP8860_EEPROM_REG_24,
>> .reg_defaults = lp8860_eeprom_defs,
>> .num_reg_defaults = ARRAY_SIZE(lp8860_eeprom_defs),
>> -.cache_type = REGCACHE_NONE,
>> +.cache_type = REGCACHE_RBTREE,
>> };
>>
>> static int lp8860_probe(struct i2c_client *client,
>> @@ -365,19 +364,23 @@ static int lp8860_probe(struct i2c_client *client,
>> int ret;
>> struct lp8860_led *led;
>> struct device_node *np = client->dev.of_node;
>> +struct device_node *child_node;
>> +
>> +if (!client->dev.of_node)
>> +return -ENODEV;
>
> This is actually a bug in the driver. I can submit this independently or
> keep this here
>
>>
>> led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
>> if (!led)
>> return -ENOMEM;
>>
>> -led->label = LP8860_DISP_LED_NAME;
>> +for_each_available_child_of_node(np, child_node) {
>> +led->led_dev.default_trigger = of_get_property(child_node,
>> +"linux,default-trigger",
>> +NULL);
>
> Not sure if you want me to pull this out into a different patch or just add
> it to the
> commit message
Yes, it would be nice. Also related change in DT bindings should be
placed in the same patch.
>>
>> -if (client->dev.of_node) {
>> -ret = of_property_read_string(np, "label", &led->label);
>> -if (ret) {
>> -dev_err(&client->dev, "Missing label in dt\n");
>> -return -EINVAL;
>> -}
>> +of_led_compose_name(np, child_node, "white:backlight",
>> +sizeof("white:backlight"),
>> +led->label);
>> }
>>
>> led->enable_gpio = devm_gpiod_get_optional(&client->dev,
>>
>
>
--
Best regards,
Jacek Anaszewski
[PATCH 03/10] staging: ccree: remove more unnecessary parentheses
The removal of likely/unlikely unearthed some more
unnecessary parentheses. Remove them for better readability.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_buffer_mgr.c | 4 ++--
drivers/staging/ccree/ssi_driver.c | 6 +++---
drivers/staging/ccree/ssi_request_mgr.c | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 7ceee91..bac9d12 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -882,7 +882,7 @@ static int cc_aead_chain_assoc(
else
areq_ctx->assoc_buff_type = SSI_DMA_BUF_MLLI;
- if ((do_chain) || areq_ctx->assoc_buff_type == SSI_DMA_BUF_MLLI) {
+ if (do_chain || areq_ctx->assoc_buff_type == SSI_DMA_BUF_MLLI) {
dev_dbg(dev, "Chain assoc: buff_type=%s nents=%u\n",
cc_dma_buf_type(areq_ctx->assoc_buff_type),
areq_ctx->assoc.nents);
@@ -1656,7 +1656,7 @@ void cc_unmap_hash_request(struct device *dev, void *ctx,
areq_ctx->mlli_params.mlli_dma_addr);
}
- if ((src) && areq_ctx->in_nents) {
+ if (src && areq_ctx->in_nents) {
dev_dbg(dev, "Unmapped sg src: virt=%pK dma=%pad len=0x%X\n",
sg_virt(src), &sg_dma_address(src), sg_dma_len(src));
dma_unmap_sg(dev, src,
diff --git a/drivers/staging/ccree/ssi_driver.c
b/drivers/staging/ccree/ssi_driver.c
index 6282c37..0b2593f 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -111,7 +111,7 @@ static irqreturn_t cc_isr(int irq, void *dev_id)
drvdata->irq = irr;
/* Completion interrupt - most probable */
- if ((irr & SSI_COMP_IRQ_MASK)) {
+ if (irr & SSI_COMP_IRQ_MASK) {
/* Mask AXI completion interrupt - will be unmasked in
* Deferred service handler
*/
@@ -121,7 +121,7 @@ static irqreturn_t cc_isr(int irq, void *dev_id)
}
#ifdef CC_SUPPORT_FIPS
/* TEE FIPS interrupt */
- if ((irr & SSI_GPR0_IRQ_MASK)) {
+ if (irr & SSI_GPR0_IRQ_MASK) {
/* Mask interrupt - will be unmasked in Deferred service
* handler
*/
@@ -131,7 +131,7 @@ static irqreturn_t cc_isr(int irq, void *dev_id)
}
#endif
/* AXI error interrupt */
- if ((irr & SSI_AXI_ERR_IRQ_MASK)) {
+ if (irr & SSI_AXI_ERR_IRQ_MASK) {
u32 axi_err;
/* Read the AXI error ID */
diff --git a/drivers/staging/ccree/ssi_request_mgr.c
b/drivers/staging/ccree/ssi_request_mgr.c
index 7a653f6..e890cb6 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -221,7 +221,7 @@ static int request_mgr_queues_status_check(
return -EBUSY;
}
- if ((req_mgr_h->q_free_slots >= total_seq_len))
+ if (req_mgr_h->q_free_slots >= total_seq_len)
return 0;
/* Wait for space in HW queue. Poll constant num of iterations. */
--
2.7.4
Re: [PATCH v5.1 1/2] ARM64: dts: meson-gx: use stable UART bindings with correct gate clock
Hi,
Am 21.06.2017 um 16:42 schrieb Neil Armstrong:
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 17d3efd..ea53cc2 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -682,6 +682,31 @@
> clocks = <&clkc CLKID_SPI>;
> };
>
> +&uart_A {
> + clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_AO {
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_AO_B {
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_B {
> + clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
Looking at the meson_uart driver, it only looks for a "pclk" clock,
never for "core", and the only unnamed clock used should be the first.
There is no bindings documentation for "core", so I assume this was an
oversight and should be "pclk" everywhere?
> +};
> +
> +&uart_C {
> + clocks = <&xtal>, <&clkc CLKID_UART2>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
> +};
The issue I'm facing is that uart_C on NanoPi K2 is not working in
4.14.1. To my surprise it appears to be probing okay though.
Sadly just overwriting the clock-names property via overlay does not fix
my issue. Any ideas?
> +
> &vpu {
> compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> index 8d4f316..9e67444 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
> @@ -623,6 +623,31 @@
> clocks = <&clkc CLKID_SPI>;
> };
>
> +&uart_A {
> + clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
Same issue spotted here and below.
> +};
> +
> +&uart_AO {
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_AO_B {
> + clocks = <&xtal>, <&clkc CLKID_CLK81>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> +};
> +
> +&uart_B {
> + clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
> +};
> +
> +&uart_C {
> + clocks = <&xtal>, <&clkc CLKID_UART2>, <&xtal>;
> + clock-names = "xtal", "core", "baud";
> +};
> +
> &vpu {
> compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
> };
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Difficulties for compilation without extra optimisation
Hello,
I came along some software modules where I suggested source code adjustments.
Example:
nfs/write: Use common error handling code in nfs_lock_and_join_requests()
https://lkml.org/lkml/2017/11/7/599
https://patchwork.kernel.org/patch/10047013/
https://lkml.kernel.org/r/<7f072f78-eef4-6d87-d233-cee71dac5...@users.sourceforge.net>
I would like to check corresponding build results then without extra
optimisation applied by the compiler.
But I got surprised by error messages for a command like the following.
elfring@Sonne:~/Projekte/Linux/next-patched> my_cc=/usr/bin/gcc-7 && LANG=C
make -j4 CC="${my_cc}" HOSTCC="${my_cc}" EXTRA_CFLAGS='-O0' allmodconfig
fs/nfs/write.o
…
In file included from ./include/linux/compiler.h:58:0,
from ./include/uapi/linux/stddef.h:1,
from ./include/linux/stddef.h:4,
from ./include/uapi/linux/posix_types.h:4,
from ./include/uapi/linux/types.h:13,
from ./include/linux/types.h:5,
from fs/nfs/write.c:9:
./arch/x86/include/asm/jump_label.h: In function
‘trace_nfs_writeback_page_enter’:
./include/linux/compiler-gcc.h:275:38: warning: asm operand 0 probably doesn’t
match constraints
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
…
How do you think about to improve this software situation anyhow?
Regards,
Markus
Re: [PATCH v4 1/2] Input: Add driver for Cypress Generation 5 touchscreen
Hi Mylène, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on input/next] [also build test WARNING on v4.15-rc1 next-20171201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Myl-ne-Josserand/Input-Add-driver-for-Cypress-Generation-5-touchscreen/20171203-203557 base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next coccinelle warnings: (new ones prefixed by >>) >> drivers/input/touchscreen/cyttsp5.c:1098:3-8: No need to set .owner here. >> The core will do it. Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[PATCH] Input: fix platform_no_drv_owner.cocci warnings
drivers/input/touchscreen/cyttsp5.c:1098:3-8: No need to set .owner here. The
core will do it.
Remove .owner field if calls are used which set it automatically
Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
Fixes: 68d0bd1e4815 ("Input: Add driver for Cypress Generation 5 touchscreen")
CC: Mylène Josserand
Signed-off-by: Fengguang Wu
---
cyttsp5.c |1 -
1 file changed, 1 deletion(-)
--- a/drivers/input/touchscreen/cyttsp5.c
+++ b/drivers/input/touchscreen/cyttsp5.c
@@ -1095,7 +1095,6 @@ static int cyttsp5_i2c_remove(struct i2c
static struct i2c_driver cyttsp5_i2c_driver = {
.driver = {
.name = CYTTSP5_NAME,
- .owner = THIS_MODULE,
.of_match_table = of_match_ptr(cyttsp5_of_match),
},
.probe = cyttsp5_i2c_probe,
Re: [PATCH v6 4/6] dt: bindings: lp8860: Update the bindings to the standard
On 12/03/2017 02:49 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> Thanks for the patch.
>
> On 12/01/2017 05:56 PM, Dan Murphy wrote:
>> Update the lp8860 dt binding to the LED standard where
>> the LED should have a child node and also adding a
>> LED trigger entry.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v6 - New patch to fix binding documentation
>>
>> Documentation/devicetree/bindings/leds/leds-lp8860.txt | 15 +++
>> 1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
>> b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
>> index aad38dd94d4b..4cf396de6eba 100644
>> --- a/Documentation/devicetree/bindings/leds/leds-lp8860.txt
>> +++ b/Documentation/devicetree/bindings/leds/leds-lp8860.txt
>> @@ -12,17 +12,24 @@ Required properties:
>> - label - Used for naming LEDs
>>
>> Optional properties:
>> -- enable-gpio - gpio pin to enable/disable the device.
>> -- supply - "vled" - LED supply
>> +- enable-gpios : gpio pin to enable/disable the device.
>> +- vled-supply : LED supply
>> +- label : see Documentation/devicetree/bindings/leds/common.txt
>> +- linux,default-trigger : (optional)
>> + see Documentation/devicetree/bindings/leds/common.txt
>
> Related driver doesn't parse this DT property AFAICS.
Ah, I missed that you're adding it in 5/6.
>
>> Example:
>>
>> -leds: leds@6 {
>> +lp8860@2d {
>> compatible = "ti,lp8860";
>> reg = <0x2d>;
>> -label = "display_cluster";
>> enable-gpio = <&gpio1 28 GPIO_ACTIVE_HIGH>;
>
> s/gpio/gpios/
>
>> vled-supply = <&vbatt>;
>> +
>> +backlight: backlight@0 {
>> +label = "backlight_cluster";
>> +linux,default-trigger = "backlight";
>> +};
>> }
>>
>> For more product information please see the link below:
>>
>
Re: BUG: workqueue lockup (2)
On Sun, Dec 3, 2017 at 3:31 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 2db767d9889cef087149a5eaa35c1497671fa40f > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > > Unfortunately, I don't have any reproducer for this bug yet. > > > BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 48s! > BUG: workqueue lockup - pool cpus=0-1 flags=0x4 nice=0 stuck for 47s! > Showing busy workqueues and worker pools: > workqueue events: flags=0x0 > pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=4/256 > pending: perf_sched_delayed, vmstat_shepherd, jump_label_update_timeout, > cache_reap > workqueue events_power_efficient: flags=0x80 > pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=4/256 > pending: neigh_periodic_work, neigh_periodic_work, do_cache_clean, > reg_check_chans_work > workqueue mm_percpu_wq: flags=0x8 > pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 > pending: vmstat_update > workqueue writeback: flags=0x4e > pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256 > in-flight: 3401:wb_workfn > workqueue kblockd: flags=0x18 > pwq 1: cpus=0 node=0 flags=0x0 nice=-20 active=1/256 > pending: blk_mq_timeout_work > pool 4: cpus=0-1 flags=0x4 nice=0 hung=0s workers=11 idle: 3423 4249 92 21 This error report does not look actionable. Perhaps if code that detect it would dump cpu/task stacks, it would be actionable. > 3549 34 4803 5 4243 3414 > audit: type=1326 audit(1512291140.021:615): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=202 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.044:616): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=202 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.045:617): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=55 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.045:618): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=202 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.045:619): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=202 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.047:620): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=257 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.047:621): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=202 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.047:622): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=202 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.048:623): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=16 compat=0 > ip=0x4529d9 code=0x7ffc > audit: type=1326 audit(1512291140.049:624): auid=4294967295 uid=0 gid=0 > ses=4294967295 subj=kernel pid=7002 comm="syz-executor7" > exe="/root/syz-executor7" sig=0 arch=c03e syscall=202 compat=0 > ip=0x4529d9 code=0x7ffc > netlink: 2 bytes leftover after parsing attributes in process > `syz-executor2'. > netlink: 2 bytes leftover after parsing attributes in process > `syz-executor2'. > netlink: 17 bytes leftover after parsing attributes in process > `syz-executor7'. > device gre0 entered promiscuous mode > device gre0 entered promiscuous mode > could not allocate digest TFM handle [vmnet1% > could not allocate digest TFM handle [vmnet1% > SELinux: unrecognized netlink message: protocol=0 nlmsg_type=7 > sclass=netlink_route_socket pig=7627 comm=syz-executor3 > sock: sock_set_timeout: `syz-executor6' (pid 7625) tries to set negative > timeout > Can not set IPV6_FL_F_REFLECT if flowlabel_consistency sysctl is enable > SELinux: unrecognized netlink message: protocol=0 nlmsg_type=0 > sclass=netlink_route_socket pig=7648 comm=syz-executor3 > sock: sock_set_timeout: `syz-executor6' (pid 7625) tries to set negative > timeout > Can not set IPV6_FL_F_REFLECT if flowlabel_consistency sysctl is enable > SELinux: unrecognized netlink message: protocol=0 nlmsg_type=7 > sclass=netlink_route_socket pig=7648 comm=syz-executor3 > SELinux: unrecognized netlink
Re: BUG: workqueue lockup (2)
On Sun, 3 Dec 2017, Dmitry Vyukov wrote: > On Sun, Dec 3, 2017 at 3:31 PM, syzbot > > wrote: > > Hello, > > > > syzkaller hit the following crash on > > 2db767d9889cef087149a5eaa35c1497671fa40f > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > > compiler: gcc (GCC) 7.1.1 20170620 > > .config is attached > > Raw console output is attached. > > > > Unfortunately, I don't have any reproducer for this bug yet. > > > > > > BUG: workqueue lockup - pool cpus=0 node=0 flags=0x0 nice=0 stuck for 48s! > > BUG: workqueue lockup - pool cpus=0-1 flags=0x4 nice=0 stuck for 47s! > > Showing busy workqueues and worker pools: > > workqueue events: flags=0x0 > > pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=4/256 > > pending: perf_sched_delayed, vmstat_shepherd, jump_label_update_timeout, > > cache_reap > > workqueue events_power_efficient: flags=0x80 > > pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=4/256 > > pending: neigh_periodic_work, neigh_periodic_work, do_cache_clean, > > reg_check_chans_work > > workqueue mm_percpu_wq: flags=0x8 > > pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 > > pending: vmstat_update > > workqueue writeback: flags=0x4e > > pwq 4: cpus=0-1 flags=0x4 nice=0 active=1/256 > > in-flight: 3401:wb_workfn > > workqueue kblockd: flags=0x18 > > pwq 1: cpus=0 node=0 flags=0x0 nice=-20 active=1/256 > > pending: blk_mq_timeout_work > > pool 4: cpus=0-1 flags=0x4 nice=0 hung=0s workers=11 idle: 3423 4249 92 21 > > > This error report does not look actionable. Perhaps if code that > detect it would dump cpu/task stacks, it would be actionable. That might be related to the RCU stall issue we are chasing, where a timer does not fire for yet unknown reasons. We have a reproducer now and hopefully a solution in the next days. Thanks, tglx
Re: [PATCH] liquidio: fix incorrect indentation of assignment statement
From: Colin King Date: Fri, 1 Dec 2017 12:38:11 + > From: Colin Ian King > > Remove one extraneous level of indentation on assignment statement. > > Signed-off-by: Colin Ian King Applied.
Re: [PATCH net] rxrpc: Use correct netns source in rxrpc_release_sock()
From: David Howells
Date: Fri, 01 Dec 2017 11:09:53 +
> In rxrpc_release_sock() there may be no rx->local value to access, so we
> can't unconditionally follow it to the rxrpc network namespace information
> to poke the connection reapers.
>
> Instead, use the socket's namespace pointer to find the namespace.
>
> This unfixed code causes the following static checker warning:
>
> net/rxrpc/af_rxrpc.c:898 rxrpc_release_sock()
> error: we previously assumed 'rx->local' could be null (see line 887)
>
> Fixes: 3d18cbb7fd0c ("rxrpc: Fix conn expiry timers")
> Reported-by: Dan Carpenter
> Signed-off-by: David Howells
Applied.
Re: [PATCH net] rxrpc: Fix the MAINTAINERS record
From: David Howells Date: Fri, 01 Dec 2017 11:10:37 + > Fix the MAINTAINERS record so that it's more obvious who the maintainer for > AF_RXRPC is. > > Reported-by: Joe Perches > Reported-by: David Miller > Signed-off-by: David Howells Applied.
[PULL REQUEST] i2c for 4.15
Linus, here are two bugfixes for I2C, fixing a memleak in the core and irq allocation for i801. Also, three bugfixes for the at24 eeprom driver which Bartosz collected while taking over maintainership for this driver. Good start, Bartosz! Please pull. Thanks, Wolfram The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323: Linux 4.15-rc1 (2017-11-26 16:01:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to edef30980dc06bea547baefcfc8d910682b6e060: Merge tag 'at24-4.15-fixes-for-wolfram' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux into i2c/for-current (2017-12-03 15:55:20 +0100) Bartosz Golaszewski (1): eeprom: at24: correctly set the size for at24mac402 Colin Ian King (1): i2c: i2c-boardinfo: fix memory leaks on devinfo Hans de Goede (1): i2c: i801: Fix Failed to allocate irq -2147483648 error Heiner Kallweit (2): eeprom: at24: fix reading from 24MAC402/24MAC602 eeprom: at24: check at24_read/write arguments Wolfram Sang (1): Merge tag 'at24-4.15-fixes-for-wolfram' of git://git.kernel.org/.../brgl/linux into i2c/for-current drivers/i2c/busses/i2c-i801.c | 3 +++ drivers/i2c/i2c-boardinfo.c | 2 ++ drivers/misc/eeprom/at24.c| 19 ++- 3 files changed, 23 insertions(+), 1 deletion(-) signature.asc Description: PGP signature
Re: [PATCH v3] doc: add maintainer book
On Thu, 30 Nov 2017 12:55:07 +1100 "Tobin C. Harding" wrote: > Create a new kernel documentation book 'how to be a maintainer' > (suggested by Jonathan Corbet). Add chapters on 'configuring git' and > 'creating a pull request'. So I've finally gotten around to giving this a look. It seems like a good starting point to me...send me a version with the tweaks from Mauro (and his Reviewed-by tag) and I'll apply it. Thanks, jon
[PATCH 0/6] Fix indentation and CamelCase issues in staging/pi433
These patches fixes a bunch of code style issues in staging/pi433. The first patch fixes indentation in rf69_enum.h and the rest of the patches fixes CamelCase issues in all of staging/pi433. In total the patches get rids of around 140 warnings generated by checkpatch.pl. - Simon --- Simon Sandström (6): staging: pi433: Fix indentation in rf69_enum.h staging: pi433: Capitalize constant definitions staging: pi433: Rename variable in struct pi433_rx_cfg staging: pi433: Rename enum optionOnOff in rf69_enum.h staging: pi433: Rename enum dataMode in rf69_enum.h staging: pi433: Rename enum modShaping in rf69_enum.h drivers/staging/pi433/pi433_if.c | 72 +-- drivers/staging/pi433/pi433_if.h | 20 ++-- drivers/staging/pi433/rf69.c | 76 ++-- drivers/staging/pi433/rf69.h | 19 +-- drivers/staging/pi433/rf69_enum.h | 213 - drivers/staging/pi433/rf69_registers.h | 44 +++ 6 files changed, 227 insertions(+), 217 deletions(-) -- 2.11.0
[PATCH 1/6] staging: pi433: Fix indentation in rf69_enum.h
Basically just 's//\t/', to fix checkpatch.pl warnings:
"please, no spaces at the start of a line".
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/rf69_enum.h | 207 +++---
1 file changed, 103 insertions(+), 104 deletions(-)
diff --git a/drivers/staging/pi433/rf69_enum.h
b/drivers/staging/pi433/rf69_enum.h
index 86429aa66ad1..babe597e2ec6 100644
--- a/drivers/staging/pi433/rf69_enum.h
+++ b/drivers/staging/pi433/rf69_enum.h
@@ -19,164 +19,163 @@
#define RF69_ENUM_H
enum optionOnOff {
-optionOff,
-optionOn
+ optionOff,
+ optionOn
};
enum mode {
-mode_sleep,
-standby,
-synthesizer,
-transmit,
-receive
+ mode_sleep,
+ standby,
+ synthesizer,
+ transmit,
+ receive
};
enum dataMode {
-packet,
-continuous,
-continuousNoSync
+ packet,
+ continuous,
+ continuousNoSync
};
enum modulation {
-OOK,
-FSK
+ OOK,
+ FSK
};
enum modShaping {
-shapingOff,
-shaping1_0,
-shaping0_5,
-shaping0_3,
-shapingBR,
-shaping2BR
+ shapingOff,
+ shaping1_0,
+ shaping0_5,
+ shaping0_3,
+ shapingBR,
+ shaping2BR
};
enum paRamp {
-ramp3400,
-ramp2000,
-ramp1000,
-ramp500,
-ramp250,
-ramp125,
-ramp100,
-ramp62,
-ramp50,
-ramp40,
-ramp31,
-ramp25,
-ramp20,
-ramp15,
-ramp12,
-ramp10
+ ramp3400,
+ ramp2000,
+ ramp1000,
+ ramp500,
+ ramp250,
+ ramp125,
+ ramp100,
+ ramp62,
+ ramp50,
+ ramp40,
+ ramp31,
+ ramp25,
+ ramp20,
+ ramp15,
+ ramp12,
+ ramp10
};
enum antennaImpedance {
-fiftyOhm,
-twohundretOhm
+ fiftyOhm,
+ twohundretOhm
};
enum lnaGain {
-automatic,
-max,
-maxMinus6,
-maxMinus12,
-maxMinus24,
-maxMinus36,
-maxMinus48,
-undefined
+ automatic,
+ max,
+ maxMinus6,
+ maxMinus12,
+ maxMinus24,
+ maxMinus36,
+ maxMinus48,
+ undefined
};
enum dccPercent {
-dcc16Percent,
-dcc8Percent,
-dcc4Percent,
-dcc2Percent,
-dcc1Percent,
-dcc0_5Percent,
-dcc0_25Percent,
-dcc0_125Percent
+ dcc16Percent,
+ dcc8Percent,
+ dcc4Percent,
+ dcc2Percent,
+ dcc1Percent,
+ dcc0_5Percent,
+ dcc0_25Percent,
+ dcc0_125Percent
};
enum mantisse {
-mantisse16,
-mantisse20,
-mantisse24
+ mantisse16,
+ mantisse20,
+ mantisse24
};
enum thresholdType {
-fixed,
-peak,
-average
+ fixed,
+ peak,
+ average
};
enum thresholdStep {
-step_0_5db,
-step_1_0db,
-step_1_5db,
-step_2_0db,
-step_3_0db,
-step_4_0db,
-step_5_0db,
-step_6_0db
+ step_0_5db,
+ step_1_0db,
+ step_1_5db,
+ step_2_0db,
+ step_3_0db,
+ step_4_0db,
+ step_5_0db,
+ step_6_0db
};
enum thresholdDecrement {
-dec_every8th,
-dec_every4th,
-dec_every2nd,
-dec_once,
-dec_twice,
-dec_4times,
-dec_8times,
-dec_16times
+ dec_every8th,
+ dec_every4th,
+ dec_every2nd,
+ dec_once,
+ dec_twice,
+ dec_4times,
+ dec_8times,
+ dec_16times
};
enum flag {
-modeSwitchCompleted,
-readyToReceive,
-readyToSend,
-pllLocked,
-rssiExceededThreshold,
-timeout,
-automode,
-syncAddressMatch,
-fifoFull,
-//fifoNotEmpty, collision with next enum; replaced by following enum...
-fifoEmpty,
-fifoLevelBelowThreshold,
-fifoOverrun,
-packetSent,
-payloadReady,
-crcOk,
-batteryLow
+ modeSwitchCompleted,
+ readyToReceive,
+ readyToSend,
+ pllLocked,
+ rssiExceededThreshold,
+ timeout,
+ automode,
+ syncAddressMatch,
+ fifoFull,
+// fifoNotEmpty, collision with next enum; replaced by following enum...
+ fifoEmpty,
+ fifoLevelBelowThreshold,
+ fifoOverrun,
+ packetSent,
+ payloadReady,
+ crcOk,
+ batteryLow
};
enum fifoFillCondition {
-afterSyncInterrupt,
-always
+ afterSyncInterrupt,
+ always
};
enum packetFormat {
-packetLengthFix,
-packetLengthVar
+ packetLengthFix,
+ packetLengthVar
};
enum txStartCondition {
-fifoLevel,
-fifoNotEmpty
+ fifoLevel,
+ fifoNotEmpty
};
enum addressFiltering {
-filteringOff,
-nodeAddress,
-nodeOrBroadcastAddress
+ filteringOff,
+ nodeAddress,
+ nodeOrBroadcastAddress
};
enum dagc {
-normalMode,
-improve,
-improve4LowModulationIndex
+ normalMode,
+ improve,
+ improve4LowModulationIndex
};
-
#endif
--
2.11.0
[PATCH 5/6] staging: pi433: Rename enum dataMode in rf69_enum.h
Renames enum dataMode and its values packet, continuous, continuousNoSync
to enum data_mode and PACKET, CONTINUOUS, CONTINUOUS_NO_SYNC. Fixes
checkpatch.pl warnings: "Avoid CamelCase: , ".
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/pi433_if.c | 2 +-
drivers/staging/pi433/rf69.c | 10 +-
drivers/staging/pi433/rf69.h | 2 +-
drivers/staging/pi433/rf69_enum.h | 8
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 4f6830f369e9..e7a730d312c5 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -1090,7 +1090,7 @@ static int pi433_probe(struct spi_device *spi)
/* setup the radio module */
SET_CHECKED(rf69_set_mode (spi, standby));
- SET_CHECKED(rf69_set_data_mode (spi, packet));
+ SET_CHECKED(rf69_set_data_mode (spi, PACKET));
SET_CHECKED(rf69_set_amplifier_0(spi, OPTION_ON));
SET_CHECKED(rf69_set_amplifier_1(spi, OPTION_OFF));
SET_CHECKED(rf69_set_amplifier_2(spi, OPTION_OFF));
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index ebb3ddd1a957..cf833ac23c06 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -61,16 +61,16 @@ int rf69_set_mode(struct spi_device *spi, enum mode mode)
}
-int rf69_set_data_mode(struct spi_device *spi, enum dataMode dataMode)
+int rf69_set_data_mode(struct spi_device *spi, enum data_mode data_mode)
{
#ifdef DEBUG
dev_dbg(&spi->dev, "set: data mode");
#endif
- switch (dataMode) {
- case packet:return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_PACKET);
- case continuous:return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_CONTINUOUS);
- case continuousNoSync: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) |
DATAMODUL_MODE_CONTINUOUS_NOSYNC);
+ switch (data_mode) {
+ case PACKET: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_PACKET);
+ case CONTINUOUS: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) | DATAMODUL_MODE_CONTINUOUS);
+ case CONTINUOUS_NO_SYNC: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODE) |
DATAMODUL_MODE_CONTINUOUS_NOSYNC);
default:
dev_dbg(&spi->dev, "set: illegal input param");
return -EINVAL;
diff --git a/drivers/staging/pi433/rf69.h b/drivers/staging/pi433/rf69.h
index 12c2e106785e..090743716326 100644
--- a/drivers/staging/pi433/rf69.h
+++ b/drivers/staging/pi433/rf69.h
@@ -26,7 +26,7 @@
#define FIFO_THRESHOLD 15 /* in byte */
int rf69_set_mode(struct spi_device *spi, enum mode mode);
-int rf69_set_data_mode(struct spi_device *spi, enum dataMode dataMode);
+int rf69_set_data_mode(struct spi_device *spi, enum data_mode data_mode);
int rf69_set_modulation(struct spi_device *spi, enum modulation modulation);
enum modulation rf69_get_modulation(struct spi_device *spi);
int rf69_set_modulation_shaping(struct spi_device *spi, enum modShaping
modShaping);
diff --git a/drivers/staging/pi433/rf69_enum.h
b/drivers/staging/pi433/rf69_enum.h
index 5247e9269de9..a55528a72f47 100644
--- a/drivers/staging/pi433/rf69_enum.h
+++ b/drivers/staging/pi433/rf69_enum.h
@@ -31,10 +31,10 @@ enum mode {
receive
};
-enum dataMode {
- packet,
- continuous,
- continuousNoSync
+enum data_mode {
+ PACKET,
+ CONTINUOUS,
+ CONTINUOUS_NO_SYNC,
};
enum modulation {
--
2.11.0
Re: Difficulties for compilation without extra optimisation
On Sun, 2017-12-03 at 15:15 +0100, SF Markus Elfring wrote:
> Hello,
>
> I came along some software modules where I suggested source code
> adjustments.
>
> Example:
> nfs/write: Use common error handling code in
> nfs_lock_and_join_requests()
>
> https://lkml.org/lkml/2017/11/7/599
> https://patchwork.kernel.org/patch/10047013/
> https://lkml.kernel.org/r/<7f072f78-eef4-6d87-d233-cee71dac5a32@users
> .sourceforge.net>;
>
> I would like to check corresponding build results then without extra
> optimisation applied by the compiler.
> But I got surprised by error messages for a command like the
> following.
>
> elfring@Sonne:~/Projekte/Linux/next-patched> my_cc=/usr/bin/gcc-7 &&
> LANG=C make -j4 CC="${my_cc}" HOSTCC="${my_cc}" EXTRA_CFLAGS='-O0'
> allmodconfig fs/nfs/write.o
> …
> In file included from ./include/linux/compiler.h:58:0,
> from ./include/uapi/linux/stddef.h:1,
> from ./include/linux/stddef.h:4,
> from ./include/uapi/linux/posix_types.h:4,
> from ./include/uapi/linux/types.h:13,
> from ./include/linux/types.h:5,
> from fs/nfs/write.c:9:
> ./arch/x86/include/asm/jump_label.h: In function
> ‘trace_nfs_writeback_page_enter’:
> ./include/linux/compiler-gcc.h:275:38: warning: asm operand 0
> probably doesn’t match constraints
> #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while
> (0)
> …
>
>
> How do you think about to improve this software situation anyhow?
I'm not seeing anything obviously wrong with the NFS use of tracepoints
there, and the warning suggests rather that gcc has an issue with the
inlined assembly code in jump_label.h.
Ccing Peter Zijlstra (who appears to have been the last person to touch
that assembly code) and Steven Rostedt.
--
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.mykleb...@primarydata.com
[PATCH 6/6] staging: pi433: Rename enum modShaping in rf69_enum.h
Renames enum modShaping and its values to get rid of checkpatch.pl
warnings: "Avoid CamelCase: ".
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/pi433_if.c | 2 +-
drivers/staging/pi433/pi433_if.h | 2 +-
drivers/staging/pi433/rf69.c | 21 +++--
drivers/staging/pi433/rf69.h | 2 +-
drivers/staging/pi433/rf69_enum.h | 14 +++---
5 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index e7a730d312c5..e457fae110cc 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -260,7 +260,7 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
SET_CHECKED(rf69_set_modulation (dev->spi, tx_cfg->modulation));
SET_CHECKED(rf69_set_deviation (dev->spi, tx_cfg->dev_frequency));
SET_CHECKED(rf69_set_pa_ramp(dev->spi, tx_cfg->pa_ramp));
- SET_CHECKED(rf69_set_modulation_shaping(dev->spi, tx_cfg->modShaping));
+ SET_CHECKED(rf69_set_modulation_shaping(dev->spi, tx_cfg->mod_shaping));
SET_CHECKED(rf69_set_tx_start_condition(dev->spi,
tx_cfg->tx_start_condition));
/* packet format enable */
diff --git a/drivers/staging/pi433/pi433_if.h b/drivers/staging/pi433/pi433_if.h
index 34ff0d4807bd..bcfe29840889 100644
--- a/drivers/staging/pi433/pi433_if.h
+++ b/drivers/staging/pi433/pi433_if.h
@@ -63,7 +63,7 @@ struct pi433_tx_cfg {
__u16 bit_rate;
__u32 dev_frequency;
enum modulation modulation;
- enum modShaping modShaping;
+ enum mod_shapingmod_shaping;
enum paRamp pa_ramp;
diff --git a/drivers/staging/pi433/rf69.c b/drivers/staging/pi433/rf69.c
index cf833ac23c06..4a5de403f984 100644
--- a/drivers/staging/pi433/rf69.c
+++ b/drivers/staging/pi433/rf69.c
@@ -109,27 +109,28 @@ enum modulation rf69_get_modulation(struct spi_device
*spi)
}
}
-int rf69_set_modulation_shaping(struct spi_device *spi, enum modShaping
modShaping)
+int rf69_set_modulation_shaping(struct spi_device *spi,
+ enum mod_shaping mod_shaping)
{
#ifdef DEBUG
dev_dbg(&spi->dev, "set: mod shaping");
#endif
if (rf69_get_modulation(spi) == FSK) {
- switch (modShaping) {
- case shapingOff: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_NONE);
- case shaping1_0: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_1_0);
- case shaping0_5: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_0_3);
- case shaping0_3: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_0_5);
+ switch (mod_shaping) {
+ case SHAPING_OFF: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_NONE);
+ case SHAPING_1_0: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_1_0);
+ case SHAPING_0_5: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_0_3);
+ case SHAPING_0_3: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_0_5);
default:
dev_dbg(&spi->dev, "set: illegal input param");
return -EINVAL;
}
} else {
- switch (modShaping) {
- case shapingOff: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_NONE);
- case shapingBR: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_BR);
- case shaping2BR: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_2BR);
+ switch (mod_shaping) {
+ case SHAPING_OFF: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_NONE);
+ case SHAPING_BR: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_BR);
+ case SHAPING_2BR: return WRITE_REG(REG_DATAMODUL,
(READ_REG(REG_DATAMODUL) & ~MASK_DATAMODUL_MODULATION_SHAPE) |
DATAMODUL_MODULATION_SHAPE_2BR);
[PATCH 4/6] staging: pi433: Rename enum optionOnOff in rf69_enum.h
Renames the enum optionOnOff and its values optionOn, optionOff to enum
option_on_off and OPTION_ON, OPTION_OFF. Fixes checkpatch.pl warnings:
"Avoid CamelCase: , , ".
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/pi433_if.c | 34 ++---
drivers/staging/pi433/pi433_if.h | 16 +++---
drivers/staging/pi433/rf69.c | 45 ++-
drivers/staging/pi433/rf69.h | 15 -
drivers/staging/pi433/rf69_enum.h | 6 +++---
5 files changed, 63 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index b8efe6a74a2a..4f6830f369e9 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -198,7 +198,7 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
/* packet config */
/* enable */
SET_CHECKED(rf69_set_sync_enable(dev->spi, rx_cfg->enable_sync));
- if (rx_cfg->enable_sync == optionOn)
+ if (rx_cfg->enable_sync == OPTION_ON)
{
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi,
afterSyncInterrupt));
}
@@ -206,7 +206,7 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
{
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, always));
}
- if (rx_cfg->enable_length_byte == optionOn) {
+ if (rx_cfg->enable_length_byte == OPTION_ON) {
ret = rf69_set_packet_format(dev->spi, packetLengthVar);
if (ret < 0)
return ret;
@@ -220,14 +220,14 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
/* lengths */
SET_CHECKED(rf69_set_sync_size(dev->spi, rx_cfg->sync_length));
- if (rx_cfg->enable_length_byte == optionOn)
+ if (rx_cfg->enable_length_byte == OPTION_ON)
{
SET_CHECKED(rf69_set_payload_length(dev->spi, 0xff));
}
else if (rx_cfg->fixed_message_length != 0)
{
payload_length = rx_cfg->fixed_message_length;
- if (rx_cfg->enable_length_byte == optionOn) payload_length++;
+ if (rx_cfg->enable_length_byte == OPTION_ON) payload_length++;
if (rx_cfg->enable_address_filtering != filteringOff)
payload_length++;
SET_CHECKED(rf69_set_payload_length(dev->spi, payload_length));
}
@@ -237,7 +237,7 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
}
/* values */
- if (rx_cfg->enable_sync == optionOn)
+ if (rx_cfg->enable_sync == OPTION_ON)
{
SET_CHECKED(rf69_set_sync_values(dev->spi,
rx_cfg->sync_pattern));
}
@@ -264,7 +264,7 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
SET_CHECKED(rf69_set_tx_start_condition(dev->spi,
tx_cfg->tx_start_condition));
/* packet format enable */
- if (tx_cfg->enable_preamble == optionOn)
+ if (tx_cfg->enable_preamble == OPTION_ON)
{
SET_CHECKED(rf69_set_preamble_length(dev->spi,
tx_cfg->preamble_length));
}
@@ -273,7 +273,7 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
SET_CHECKED(rf69_set_preamble_length(dev->spi, 0));
}
SET_CHECKED(rf69_set_sync_enable (dev->spi, tx_cfg->enable_sync));
- if (tx_cfg->enable_length_byte == optionOn) {
+ if (tx_cfg->enable_length_byte == OPTION_ON) {
ret = rf69_set_packet_format(dev->spi, packetLengthVar);
if (ret < 0)
return ret;
@@ -285,7 +285,7 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
SET_CHECKED(rf69_set_crc_enable (dev->spi, tx_cfg->enable_crc));
/* configure sync, if enabled */
- if (tx_cfg->enable_sync == optionOn) {
+ if (tx_cfg->enable_sync == OPTION_ON) {
SET_CHECKED(rf69_set_sync_size(dev->spi, tx_cfg->sync_length));
SET_CHECKED(rf69_set_sync_values(dev->spi,
tx_cfg->sync_pattern));
}
@@ -400,7 +400,7 @@ pi433_receive(void *data)
}
/* length byte enabled? */
- if (dev->rx_cfg.enable_length_byte == optionOn)
+ if (dev->rx_cfg.enable_length_byte == OPTION_ON)
{
retval = wait_event_interruptible(dev->fifo_wait_queue,
dev->free_in_fifo <
FIFO_SIZE);
@@ -525,11 +525,11 @@ pi433_tx_thread(void *data)
size = tx_cfg.fixed_message_length;
/* increase size, if len byte is requested */
- if (tx_cfg.enable_length_byte == optionOn)
+ if (tx_cfg.enable_length_byte == OPTION_ON)
size++;
/* increase size, if adr byte is requested */
- if (tx_cfg.enable_address_byte == option
[PATCH 3/6] staging: pi433: Rename variable in struct pi433_rx_cfg
Renames variable thresholdDecrement in struct pi433_rx_cfg to
threshold_decrement to get rid of checkpatch.pl warning
"Avoid CamelCase: ".
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/pi433_if.c | 2 +-
drivers/staging/pi433/pi433_if.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 840a7c7bf19a..b8efe6a74a2a 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -188,7 +188,7 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
SET_CHECKED(rf69_set_modulation (dev->spi, rx_cfg->modulation));
SET_CHECKED(rf69_set_antenna_impedance (dev->spi,
rx_cfg->antenna_impedance));
SET_CHECKED(rf69_set_rssi_threshold (dev->spi,
rx_cfg->rssi_threshold));
- SET_CHECKED(rf69_set_ook_threshold_dec (dev->spi,
rx_cfg->thresholdDecrement));
+ SET_CHECKED(rf69_set_ook_threshold_dec (dev->spi,
rx_cfg->threshold_decrement));
SET_CHECKED(rf69_set_bandwidth (dev->spi,
rx_cfg->bw_mantisse, rx_cfg->bw_exponent));
SET_CHECKED(rf69_set_bandwidth_during_afc(dev->spi,
rx_cfg->bw_mantisse, rx_cfg->bw_exponent));
SET_CHECKED(rf69_set_dagc(dev->spi, rx_cfg->dagc));
diff --git a/drivers/staging/pi433/pi433_if.h b/drivers/staging/pi433/pi433_if.h
index fc842c48c33e..6b31c1584b3a 100644
--- a/drivers/staging/pi433/pi433_if.h
+++ b/drivers/staging/pi433/pi433_if.h
@@ -115,7 +115,7 @@ struct pi433_rx_cfg {
enum modulation modulation;
__u8rssi_threshold;
- enum thresholdDecrement thresholdDecrement;
+ enum thresholdDecrement threshold_decrement;
enum antennaImpedance antenna_impedance;
enum lnaGainlna_gain;
enum mantisse bw_mantisse;/* normal: 0x50 */
--
2.11.0
[PATCH 2/6] staging: pi433: Capitalize constant definitions
Fixes checkpatch.pl warnings "Avoid CamelCase ".
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/pi433_if.c | 32 -
drivers/staging/pi433/rf69_registers.h | 44 +-
2 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 3404cb9722c9..840a7c7bf19a 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -133,20 +133,20 @@ static irqreturn_t DIO0_irq_handler(int irq, void *dev_id)
{
struct pi433_device *device = dev_id;
- if (device->irq_state[DIO0] == DIO_PacketSent)
+ if (device->irq_state[DIO0] == DIO_PACKET_SENT)
{
device->free_in_fifo = FIFO_SIZE;
dev_dbg(device->dev, "DIO0 irq: Packet sent\n");
wake_up_interruptible(&device->fifo_wait_queue);
}
- else if (device->irq_state[DIO0] == DIO_Rssi_DIO0)
+ else if (device->irq_state[DIO0] == DIO_RSSI_DIO0)
{
dev_dbg(device->dev, "DIO0 irq: RSSI level over threshold\n");
wake_up_interruptible(&device->rx_wait_queue);
}
- else if (device->irq_state[DIO0] == DIO_PayloadReady)
+ else if (device->irq_state[DIO0] == DIO_PAYLOAD_READY)
{
- dev_dbg(device->dev, "DIO0 irq: PayloadReady\n");
+ dev_dbg(device->dev, "DIO0 irq: Payload ready\n");
device->free_in_fifo = 0;
wake_up_interruptible(&device->fifo_wait_queue);
}
@@ -158,11 +158,11 @@ static irqreturn_t DIO1_irq_handler(int irq, void *dev_id)
{
struct pi433_device *device = dev_id;
- if (device->irq_state[DIO1] == DIO_FifoNotEmpty_DIO1)
+ if (device->irq_state[DIO1] == DIO_FIFO_NOT_EMPTY_DIO1)
{
device->free_in_fifo = FIFO_SIZE;
}
- else if (device->irq_state[DIO1] == DIO_FifoLevel)
+ else if (device->irq_state[DIO1] == DIO_FIFO_LEVEL)
{
if (device->rx_active) device->free_in_fifo = FIFO_THRESHOLD -
1;
elsedevice->free_in_fifo = FIFO_SIZE -
FIFO_THRESHOLD - 1;
@@ -309,14 +309,14 @@ pi433_start_rx(struct pi433_device *dev)
if (retval) return retval;
/* setup rssi irq */
- SET_CHECKED(rf69_set_dio_mapping(dev->spi, DIO0, DIO_Rssi_DIO0));
- dev->irq_state[DIO0] = DIO_Rssi_DIO0;
+ SET_CHECKED(rf69_set_dio_mapping(dev->spi, DIO0, DIO_RSSI_DIO0));
+ dev->irq_state[DIO0] = DIO_RSSI_DIO0;
irq_set_irq_type(dev->irq_num[DIO0], IRQ_TYPE_EDGE_RISING);
/* setup fifo level interrupt */
SET_CHECKED(rf69_set_fifo_threshold(dev->spi, FIFO_SIZE -
FIFO_THRESHOLD));
- SET_CHECKED(rf69_set_dio_mapping(dev->spi, DIO1, DIO_FifoLevel));
- dev->irq_state[DIO1] = DIO_FifoLevel;
+ SET_CHECKED(rf69_set_dio_mapping(dev->spi, DIO1, DIO_FIFO_LEVEL));
+ dev->irq_state[DIO1] = DIO_FIFO_LEVEL;
irq_set_irq_type(dev->irq_num[DIO1], IRQ_TYPE_EDGE_RISING);
/* set module to receiving mode */
@@ -378,8 +378,8 @@ pi433_receive(void *data)
}
/* configure payload ready irq */
- SET_CHECKED(rf69_set_dio_mapping(spi, DIO0, DIO_PayloadReady));
- dev->irq_state[DIO0] = DIO_PayloadReady;
+ SET_CHECKED(rf69_set_dio_mapping(spi, DIO0, DIO_PAYLOAD_READY));
+ dev->irq_state[DIO0] = DIO_PAYLOAD_READY;
irq_set_irq_type(dev->irq_num[DIO0], IRQ_TYPE_EDGE_RISING);
/* fixed or unlimited length? */
@@ -590,13 +590,13 @@ pi433_tx_thread(void *data)
rf69_set_tx_cfg(device, &tx_cfg);
/* enable fifo level interrupt */
- SET_CHECKED(rf69_set_dio_mapping(spi, DIO1, DIO_FifoLevel));
- device->irq_state[DIO1] = DIO_FifoLevel;
+ SET_CHECKED(rf69_set_dio_mapping(spi, DIO1, DIO_FIFO_LEVEL));
+ device->irq_state[DIO1] = DIO_FIFO_LEVEL;
irq_set_irq_type(device->irq_num[DIO1], IRQ_TYPE_EDGE_FALLING);
/* enable packet sent interrupt */
- SET_CHECKED(rf69_set_dio_mapping(spi, DIO0, DIO_PacketSent));
- device->irq_state[DIO0] = DIO_PacketSent;
+ SET_CHECKED(rf69_set_dio_mapping(spi, DIO0, DIO_PACKET_SENT));
+ device->irq_state[DIO0] = DIO_PACKET_SENT;
irq_set_irq_type(device->irq_num[DIO0], IRQ_TYPE_EDGE_RISING);
enable_irq(device->irq_num[DIO0]); /* was disabled by rx active
check */
diff --git a/drivers/staging/pi433/rf69_registers.h
b/drivers/staging/pi433/rf69_registers.h
index 6335d42142fe..d23b8b668ef5 100644
--- a/drivers/staging/pi433/rf69_registers.h
+++ b/drivers/staging/pi433/rf69_registers.h
@@ -346,28 +346,28 @@
#define DIO5 5
/* DIO Mapping values (packet mode) */
-#define DIO_ModeReady_DIO4
What Has Kept You Waiting?
Attention We are surprised as you have not responded to our previous notification concerning your $650,000, United Nations has decided to compensate you as part of the empowerment program to reinstate those who have lost money to scammers in the past. To commence facilitating your transfer, kindly re-confirm the following 1. Your Names 2. Your Address 3. Your Phone 4. Your Age 5. Your Occupation 6. Copy of your ID 7. Your Country Waiting for your confirmation, remember further delay will result in cancellation of your file as unclaimed and your fund will be diverted to government treasury. Best regards, Mr Light Adam
Hello
-- GREETINGS, I AM BORTE ,I WAS DIAGNOSE OF OVARIAN CANCER,WHICH DOCTORS HAVE CONFIRMED THAT I HAVE ONLY FEW WEEKS TO LIVE, SO I HAVE DECIDED TO DONATE EVERYTHING I HAVE TO THE ORPHANAGE AND THE POOR WIDOWS THROUGH YOU .PLEASE KINDLY REPLY ME(missbortiogo...@gmail.com) AS SOON AS POSIBLE TO ENABLE ME GIVE YOU MORE INFORMATION ABOUT MYSELF AND HOW TO GO ABOUT IT . THANKS MISS BORTE --
[PATCH] [FIX] staging: pi433: fix last commit indentation
fix indentation in commit:
- 928150e1dbb8638f309493b7dc72d56c20896704 staging: pi433: fix coding style in
function rf69_set_rx_cfg()
Signed-off-by: Victor Carvalho
---
drivers/staging/pi433/pi433_if.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 97ab5fa27059..a9fd7fc209d6 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -203,11 +203,12 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
/* packet config */
/* enable */
SET_CHECKED(rf69_set_sync_enable(dev->spi, rx_cfg->enable_sync));
- if (rx_cfg->enable_sync == optionOn)
+ if (rx_cfg->enable_sync == optionOn) {
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi,
afterSyncInterrupt));
- else
+ } else {
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, always));
+ }
if (rx_cfg->enable_length_byte == optionOn) {
ret = rf69_set_packet_format(dev->spi, packetLengthVar);
--
2.14.3
Re: [PATCH RFC] stat.2: Document that stat can fail with EINTR
Am 03.12.2017 01:23, schrieb Keno Fischer: > Particularly on network file systems, a stat call may require > submitting a message over the network and waiting interruptably > for a reply. > > Signed-off-by: Keno Fischer > --- > > The catalyst for this patch was me experiencing EINTR errors when > using the 9p file system. In linux commit 9523feac, the 9p file > system was changed to use wait_event_killable instead of > wait_event_interruptible, which does indeed address my problem, > but also makes me a bit unhappy, because uninterruptable waits > prevents things like ^C'ing the execution and some debugging > tools which depend on being able to cancel long-running operations > by sending signals. I'd like to ask the user space applications I > care about to properly handle such situations (either by using > SA_RESTART or by explicitly handling EINTR), but it's a bit of a > hard sell if EINTR isn't documented to be a possibility. I'm hoping > this doc PATCH will generate a discussion of whether EINTR is an > appropriate thing for stat (as a stand in for a file system call that's > not read/write) to return. If so, I'd be happy to submit > patches to other file system-related syscalls along these same lines. > > I realize I'm probably 20 years too late here, but it feels like > clarificaion on what to expect from the kernel would still go a long > way here. > no matter, if it can happen it should be document. Nothing is more anoying that triggering an undocumented error. > man2/stat.2 | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/man2/stat.2 b/man2/stat.2 > index dad9a01..f10235a 100644 > --- a/man2/stat.2 > +++ b/man2/stat.2 > @@ -452,6 +452,11 @@ Invalid flag specified in > is relative and > .I dirfd > is a file descriptor referring to a file other than a directory. > +.TP > +.B EINTR > +The call was interrupted by delivery of a signal caught by a handler; see What is about: The call was interrupted by a .BR signal (7). > +.BR signal (7). > +The possibility of this error is file-system dependent. You mean: This error is file-system dependent. just my 2 cents, re, wh > .SH VERSIONS > .BR fstatat () > was added to Linux in kernel 2.6.16;
Linux 4.15-rc2
It's Sunday, but a few hours earlier than usual, since I'm on the east coast, three hours ahead of my normal release schedule. It's a slightly bigger rc2 than I would have wished for, but this early in the release process I don't worry about it. The appended shortlog gives the details, it's fixes all over the place - architectures, drivers, filesystems, networking, core kernel. One thing I'll point out is that I'm trying to get some kernel ASLR leaks plugged, and as part of that we now hash any pointers printed by "%p' by default. That won't affect a lot of people, but where it is a debugging problem (rather than leaking interesting kernel pointers), we will have to fix things up. It can be a small annoyance, but the alternatives (trying to actually find all the cases where we might be leaking) were worse. But let's see if anybody even notices - a lot of the pointer printouts are stale debug information from when some driver was originally written, and aren't actually really interesting. There will probably be some more leak fixes during this rc process, we'll see how that all sorts out. Linus --- Abhishek Goel (2): cpupowerutils: bench - Fix cpu online check cpupower : Fix cpupower working when cpu0 is offline Adrian Hunter (4): mmc: block: Fix missing blk_put_request() mmc: block: Check return value of blk_get_request() mmc: core: Do not leave the block driver in a suspended state mmc: block: Ensure that debugfs files are removed Ahmad Fatoum (1): e1000: Fix off-by-one in debug message Alex Deucher (4): drm/amdgpu/gfx7: cache raster_config values drm/amdgpu: used cached gca values for cik_read_register Revert "drm/amdgpu: fix rmmod KCQ disable failed error" drm/amdgpu: drop experimental flag for raven Amritha Nambiar (1): i40e: Fix reporting incorrect error codes Andrew Elble (2): nfsd: fix locking validator warning on nfs4_ol_stateid->st_mutex class nfsd: check for use of the closed special stateid Andrew Jiang (1): drm/amd/display: Don't reject 3D timings Andrew Waterman (3): RISC-V: Add VDSO entries for clock_get/gettimeofday/getcpu RISC-V: Flush I$ when making a dirty page executable RISC-V: Allow userspace to flush the instruction cache Andrey Grodzovsky (1): drm/amd/display: Switch to drm_atomic_helper_wait_for_flip_done Andrey Gusakov (6): drm/bridge: tc358767: do no fail on hi-res displays drm/bridge: tc358767: filter out too high modes drm/bridge: tc358767: fix DP0_MISC register set drm/bridge: tc358767: fix timing calculations drm/bridge: tc358767: fix AUXDATAn registers access drm/bridge: tc358767: fix 1-lane behavior Andy Shevchenko (1): scripts/bloat-o-meter: don't fail with division by 0 Antoine Tenart (4): net: mvpp2: fix the txq_init error path net: mvpp2: cleanup probed ports in the probe error path net: mvpp2: check ethtool sets the Tx ring size is to a valid min value net: phy: marvell10g: fix the PHY id mask Ard Biesheuvel (2): arm64: module-plts: factor out PLT generation code for ftrace arm64: ftrace: emit ftrace-mod.o contents through code Arnd Bergmann (2): drm/i915: fix intel_backlight_device_register declaration drm/omap: displays: panel-dpi: add backlight dependency Bartosz Golaszewski (1): eeprom: at24: correctly set the size for at24mac402 Bastian Stender (2): mmc: core: prepend 0x to pre_eol_info entry in sysfs mmc: core: prepend 0x to OCR entry in sysfs Benjamin Gaignard (1): ethernet: dwmac-stm32: Fix copyright Bhawanpreet Lakha (1): drm/amd/display: Add null check for 24BPP (xfm and dpp) Bhumika Goyal (3): sunrpc: make the function arg as const NFSD: make cache_detail structures const SUNRPC: make cache_detail structures const Bjorn Andersson (1): mmc: sdhci-msm: Optionally wait for signal level changes Carlos Maiolino (1): xfs: Properly retry failed dquot items in case of error during buffer writeback Changbin Du (1): drm/i915/gvt: Fix unsafe locking caused by spin_unlock_bh Chao Yu (1): quota: propagate error from __dquot_initialize Charlene Liu (2): drm/amd/display: fix seq issue: turn on clock before programming afmt. drm/amd/display: try to find matching audio inst for enc inst first Chris Wilson (3): drm/i915: Clear breadcrumb node when cancelling signaling drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM drm/i915/fbdev: Serialise early hotplug events with async fbdev config Christian Borntraeger (1): s390/debug: use pK for kernel pointers Christian König (2): drm/amdgpu: don't try to move pinned BOs drm/ttm: fix populate_and_map() functions once more Christoph Hellwig (1): move libgcc.h to include/linux Christophe JAILLET (2): bnxt_en: Fix an error handling path in 'b
Re: [GIT PULL] revert ARM SCPI changes for v4.15-rc1
Am 03.12.2017 um 02:04 schrieb Olof Johansson: > On Fri, Dec 01, 2017 at 11:53:05AM -0800, Kevin Hilman wrote: >> Arnd, Olof, >> >> These ARM SCPI changes caused SCPI regressions resulting in CPUfreq >> failures on most Amlogic SoCs (found by kernelci.org.) >> >> Unfortunately, this was not caught in linux-next due to other >> bugs/panics on these platforms masking this problem so we've only found >> it since we've fixed the other issues. >> >> Since we're already in the -rc cycle, I'd prefer to revert to a known >> working state (that of v4.14) rather than finding/reverting a subset, >> which would just lead to another untested state. >> >> These changes can then have some time to be better reviewed and tested >> and resubmitted for v4.16. >> >> I've tested this revert on the affect Amlogic SoCs and verified that >> we're back to the previous (working) condition. >> >> Also, I'm sending the pull directly to arm-soc instead of Sudeeep >> because I understand that Sudeep is currently out-of-office and unlikely >> to be able to address this himself during the -rc cycle. >> > > Sounds like the right approach here. I've merged this and added the above text > to the merge commit as well. > I can't reproduce the issue on my systems, however I'm quite sure that commit 931cf0c53e69 "firmware: arm_scpi: pre-populate dvfs info in scpi_probe" causes the problem. I could re-submit the series w/o this patch, the other patches then need some re-basing. I'd include a patch addressing the following question from Kevin because I was asking myself the same thing too: "Also, is this the expected result for the pre-1.0 firmware: scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version" In case a legacy firmware doesn't provide version information I propose to print the following message instead: scpi_protocol scpi: SCP Protocol legacy pre-1.0 firmware The series could be applied to a devel branch first to give the Baylibre Amlogic team some time for testing. Rgds, Heiner > > -Olof >
Re: [PATCH v5 net-next,mips 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.
From: David Daney
Date: Fri, 1 Dec 2017 15:18:06 -0800
> +static char *mix_port;
> +module_param(mix_port, charp, 0444);
> +MODULE_PARM_DESC(mix_port, "Specifies which ports connect to MIX
> interfaces.");
> +
> +static char *pki_port;
> +module_param(pki_port, charp, 0444);
> +MODULE_PARM_DESC(pki_port, "Specifies which ports connect to the PKI.");
Please no module parameters.
Please instead find a way to determine or configure these elements
at run time with generic configuration interfaces.
> +
> +static int bgx_probe(struct platform_device *pdev)
> +{
> + struct mac_platform_data platform_data;
> + const __be32 *reg;
> + u32 port;
> + u64 addr;
> + struct device_node *child;
> + struct platform_device *new_dev;
> + struct platform_device *pki_dev;
> + int numa_node, interface;
> + int i;
> + int r = 0;
> + char id[64];
> + u64 data;
Please use reverse-christmas-tree ordering (longest to shortest line) for
local variable declarations.
Please fix this in your entire submission.
> +static int bgx_mix_init_from_fdt(void)
> +{
> + struct device_node *node;
> + struct device_node *parent = NULL;
> + int mix = 0;
> +
Please do not use tabs like this when declaring local variables.
Much worse, some functions use this style whereas others do not,
be consistent otherwise your code is very hard to read.
Please fix this for your entire submission not just this specific
case I am pointing out.
Thanks.
Re: [PATCH v6 0/2] memory: Introduce ti-emif-sram driver
* santosh.shilim...@oracle.com [171203 04:03]:
>
>
> On 11/30/17 2:56 PM, Dave Gerlach wrote:
> > This is a resend of v5 of this series found here [1]. It introduces
> > relocatable PM handlers for the emif that are copied to sram and
> > run from there during low power mode entry.
> >
> > The patches still have the previous ACKs but have a small change to
> > accomodate a change made by Tony in commit cd57dc5a2099 ("ARM: dts:
> > Add missing hwmod related nodes for am33xx"). If there are objections
> > to this let me know ASAP.
> >
> > Now that a hwmod is present for the am335x EMIF, on probe fail the call to
> > pm_runtime_put_sync causes the board to hang. In fact, this emif driver
> > should
> > never alter the PM state of the hardware at all through normal kernel
> > calls, it
> > is the job of the suspend handlers that are added, that is the whole point
> > of
> > this driver. Because of this, I have dropped all runtime pm calls, as any
> > change to the PM state while the kernel is running is dangerous as we may
> > shut
> > of the memory controller. It makes the most sense just to drop runtime PM
> > from
> > the driver entirely. Besides that patch is unchanged.
> >
> > This code is required for low-power modes to work on AM335x and AM437x and a
> > forthcoming PM series for those platforms will depend on this series. After
> > both this and the PM series are reviewed I will send the necessary device
> > tree
> > changes for both, but in the meantime all remaining patches for am335x and
> > am437x PM can be found here [2].
> >
> Applied
OK, do you have some immutable commit for these I can pull in too for
the related SoC changes?
Regards,
Tony
Re: [alsa-devel] [PATCH v4 03/15] soundwire: Add Master registration
On Fri, Dec 01, 2017 at 04:10:55PM -0600, Pierre-Louis Bossart wrote:
> On 12/1/17 3:56 AM, Vinod Koul wrote:
> >A Master registers with SoundWire bus and scans the firmware provided
>
> nitpick: is the 'register' correct? You create a bus instance for each
> hardware master interface. Or is my brain fried?
naah, thankfully it is not :)
I will reword this, I see it can cause ambguity :)
> >+int sdw_add_bus_master(struct sdw_bus *bus)
> >+{
> >+int ret;
> >+
> >+if (!bus->dev) {
> >+pr_err("SoundWire bus has no device");
> >+return -ENODEV;
> >+}
> >+
> >+mutex_init(&bus->bus_lock);
> >+INIT_LIST_HEAD(&bus->slaves);
> >+
> >+/*
> >+ * Device numbers in SoundWire are 0 thru 15 with 0 being
> >+ * Enumeration device number and 15 broadcast device number. So
> >+ * they are not used for assignment so mask these and other
> >+ * higher bits
>
> device 14 is used for the master and is not supported by these patches.
> While allowed, if you use device 12 and 13 (groups) you can't get the status
> information in a PING command so the recommendation is to avoid them.
> Those device numbers should never be used really (on top of 0 and 15 as
> explained above)
Yeah we should also exclude 12 thru 14 here. The group alllocation when done
need to do differently that this one, so will mask those too.
> >+void sdw_extract_slave_id(struct sdw_bus *bus,
> >+u64 addr, struct sdw_slave_id *id)
> >+{
> >+dev_dbg(bus->dev, "SDW Slave Addr: %llx", addr);
> >+
> >+/*
> >+ * Spec definition
> >+ * Register Bit Contents
> >+ * DevId_0 [7:4] 47:44 sdw_version
> >+ * DevId_0 [3:0] 43:40 unique_id
> >+ * DevId_139:32 mfg_id [15:8]
> >+ * DevId_231:24 mfg_id [7:0]
>
> Add a reference to mid.mipi.org (here or in the summary) ?
Will add in summary, makes sense on that page
> >+int sdw_acpi_find_slaves(struct sdw_bus *bus)
> >+{
> >+struct acpi_device *adev, *parent;
> >+
> >+parent = ACPI_COMPANION(bus->dev);
> >+if (!parent) {
> >+dev_err(bus->dev, "Can't find parent for acpi bind\n");
> >+return -ENODEV;
> >+}
> >+
> >+list_for_each_entry(adev, &parent->children, node) {
> >+unsigned long long addr;
> >+struct sdw_slave_id id;
> >+unsigned int link_id;
> >+acpi_status status;
> >+
> >+status = acpi_evaluate_integer(adev->handle,
> >+METHOD_NAME__ADR, NULL, &addr);
> >+
> >+if (ACPI_FAILURE(status)) {
> >+dev_err(bus->dev, "_ADR resolution failed: %x\n",
> >+status);
> >+return status;
> >+}
> >+
> >+/* Extract link id from ADR, it is from 48 to 51 bits */
>
> nitpick: in bits 51..48 as defined in the MIPI SoundWire DisCo spec.
ok
> >+/* SDW Enumeration Device Number */
> >+#define SDW_ENUM_DEV_NUM0
>
> add
> SDW_GROUP12_DEV_NUM 12
> SDW_GROUP12_DEV_NUM 13
you mean SDW_GROUP13_DEV_NUM :D
> SDW_MASTER_DEV_NUM14 /* not supported in these patches */
These dont help now as we dont support, so kind of dead code.
Lets add them when we really support it
--
~Vinod
Re: WARNING in kvm_arch_vcpu_ioctl_run (2)
On Mon, Nov 20, 2017 at 10:19 AM, Wanpeng Li wrote: > Hi Dmitry, > 2017-11-20 12:09 GMT+08:00 Wanpeng Li : >> 2017-11-18 4:22 GMT+08:00 syzbot >> : >>> Hello, >>> >>> syzbot has tested the proposed patch but the reproducer still triggered >>> crash: >>> WARNING in kvm_arch_vcpu_ioctl_run >>> >>> VMExit: intr_info= errcode= ilen= >>> reason=8021 qualification= >>> IDTVectoring: info= errcode= >>> TSC Offset = 0xffeeb46bc6ac >>> EPT pointer = 0x0001ce37601e >>> WARNING: CPU: 0 PID: 3023 at arch/x86/kvm/x86.c:7293 >>> kvm_arch_vcpu_ioctl_run+0x213/0x5d20 >>> Kernel panic - not syncing: panic_on_warn set ... >>> >>> CPU: 0 PID: 3023 Comm: syz-executor4 Not tainted 4.14.0-next-20171117+ #9 >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS >>> Google 01/01/2011 >>> Call Trace: >>> dump_stack+0x173/0x237 >>> panic+0x1e4/0x41c >>> __warn+0x1d9/0x1f0 >>> report_bug+0x20a/0x2d0 >>> fixup_bug.part.10+0x32/0x80 >>> do_error_trap+0x29c/0x370 >>> invalid_op+0x18/0x20 >>> RIP: 0010:kvm_arch_vcpu_ioctl_run+0x213/0x5d20 >>> RSP: 0018:8801ce197680 EFLAGS: 00010293 >>> RAX: 8801ce588440 RBX: 8801d5b8f000 RCX: 810d4003 >>> RDX: RSI: RDI: 8801ce0e02b8 >>> RBP: 8801ce197a50 R08: 0001 R09: 0001 >>> R10: R11: 0001 R12: >>> R13: 8801ce0e0168 R14: 8801cec10980 R15: 8801ce0e0080 >>> kvm_vcpu_ioctl+0x619/0xf80 >>> do_vfs_ioctl+0x18b/0x13e0 >>> SyS_ioctl+0x7e/0xb0 >>> entry_SYSCALL_64_fastpath+0x1f/0x96 >>> RIP: 0033:0x452879 >>> RSP: 002b:7f4bc97fdbe8 EFLAGS: 0212 ORIG_RAX: 0010 >>> RAX: ffda RBX: 0082 RCX: 00452879 >>> RDX: RSI: ae80 RDI: 0004 >>> RBP: 7ffce1993510 R08: R09: >>> R10: R11: 0212 R12: >>> R13: 7ffce199348f R14: 7f4bc97fe9c0 R15: 0006 >>> Dumping ftrace buffer: >>>(ftrace buffer empty) >>> Kernel Offset: disabled >>> Rebooting in 86400 seconds.. >> >> I will have a look. > > Please have a try. https://lkml.org/lkml/2017/11/20/118 Hi Wanpeng, Please also follow this part: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > Note: all commands must start from beginning of the line. It will greatly help to keep overall process running. Thanks
Re: [alsa-devel] [PATCH v4 04/15] soundwire: Add MIPI DisCo property helpers
On Fri, Dec 01, 2017 at 04:49:01PM -0600, Pierre-Louis Bossart wrote:
> >+int sdw_master_read_prop(struct sdw_bus *bus)
> >+{
> >+struct sdw_master_prop *prop = &bus->prop;
> >+struct fwnode_handle *link;
> >+unsigned int count = 0;
> >+char name[32];
> >+int nval, i;
> >+
> >+device_property_read_u32(bus->dev,
> >+"mipi-sdw-sw-interface-revision", &prop->revision);
> >+device_property_read_u32(bus->dev, "mipi-sdw-master-count", &count);
> >+
> >+/* Find link handle */
> >+snprintf(name, sizeof(name),
> >+"mipi-sdw-link-%d-subproperties", bus->link_id);
>
> if you follow the DisCo spec, this property is at the controller level,
> isn't there a confusion between controller/master here, and consequently are
> we reading the same things multiple times or using the wrong bus parameter?
Not sure I follow, this one is for a specific master ie a specfic link.
we need to read respective master thru mipi-sdw-link-N-subproperties
> If I look at intel_probe(), there is a clear reference to a link_id, and
> then you set the pointer to this read_prop which reads the number of links,
> which looks like the wrong order. You can't assign a link ID before knowing
> how many links there are - or you may be unable to detect issues.
Sorry I dont follow this part. FWIW, when master driver is enumerated it
know the link_id value and then sets the read_prop and then these are read.
Here we are reading "a specific link property" with the knowledge of link_id
value...
> >+fwnode_property_read_u32(link, "mipi-sdw-default-frame-rate",
> >+&prop->default_frame_rate);
> >+fwnode_property_read_u32(link, "mipi-sdw-default-frame-row-size",
> >+&prop->default_row);
> >+fwnode_property_read_u32(link, "mipi-sdw-default-frame-col-size",
>
> This is fine, just wondering if we should warnings if the values make no
> sense, e.g. the DisCo spec states in Note1 page 15 that the values are
> interrelated.
I think we discussed in past and that would kind of form the firmware
validation. We check all the values to see if firmware gave us sane values..
> >+/*
> >+ * Based on each DPn port, get source and sink dpn properties.
> >+ * Also, some ports can operate as both source or sink.
> >+ */
> >+
> >+/* Allocate memory for set bits in port lists */
> >+nval = hweight32(prop->source_ports);
> >+num_of_ports += nval;
>
> this and...
>
> >+prop->src_dpn_prop = devm_kcalloc(&slave->dev, nval,
> >+sizeof(*prop->src_dpn_prop), GFP_KERNEL);
> >+if (!prop->src_dpn_prop)
> >+return -ENOMEM;
> >+
> >+/* Read dpn properties for source port(s) */
> >+sdw_slave_read_dpn(slave, prop->src_dpn_prop, nval,
> >+prop->source_ports, "source");
> >+
> >+nval = hweight32(prop->sink_ports);
> >+num_of_ports += nval;
>
> ... this is no longer needed since...
>
> >+prop->sink_dpn_prop = devm_kcalloc(&slave->dev, nval,
> >+sizeof(*prop->sink_dpn_prop), GFP_KERNEL);
> >+if (!prop->sink_dpn_prop)
> >+return -ENOMEM;
> >+
> >+/* Read dpn properties for sink port(s) */
> >+sdw_slave_read_dpn(slave, prop->sink_dpn_prop, nval,
> >+prop->sink_ports, "sink");
> >+
> >+/* some ports are bidirectional so check total ports by ORing */
> >+nval = prop->source_ports | prop->sink_ports;
> >+num_of_ports = hweight32(nval) + 1; /* add 1 for DP0 */
>
> ... you reassign the value here. That was one earlier feedback from me but
> you left the variable incrementation in the code.
This seems to have artifact of merge conflicts as I clearly remember removing
this, thanks for pointing will remove these..
> >+/**
> >+ * enum sdw_clk_stop_mode - Clock Stop modes
> >+ * @SDW_CLK_STOP_MODE0: Slave can continue operation seamlessly on clock
> >+ * restart
> >+ * @SDW_CLK_STOP_MODE1: Slave may have entered a deeper power-saving mode,
> >+ * not capable of continuing operation seamlessly when the clock restarts
> >+ */
> >+enum sdw_clk_stop_mode {
> >+SDW_CLK_STOP_MODE0 = 1,
> >+SDW_CLK_STOP_MODE1 = 2,
>
> why not 0 and 1?
why not 1 and 2 :D
I think it was to ensure we have a non zero value, but am not sure, will
check though..
--
~Vinod
Re: [PATCH 4/6] staging: pi433: Rename enum optionOnOff in rf69_enum.h
Am 03.12.2017 um 17:17 schrieb Simon Sandström:
Renames the enum optionOnOff and its values optionOn, optionOff to enum
option_on_off and OPTION_ON, OPTION_OFF. Fixes checkpatch.pl warnings:
"Avoid CamelCase: , , ".
Signed-off-by: Simon Sandström
---
drivers/staging/pi433/pi433_if.c | 34 ++---
drivers/staging/pi433/pi433_if.h | 16 +++---
drivers/staging/pi433/rf69.c | 45 ++-
drivers/staging/pi433/rf69.h | 15 -
drivers/staging/pi433/rf69_enum.h | 6 +++---
5 files changed, 63 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index b8efe6a74a2a..4f6830f369e9 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -198,7 +198,7 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
/* packet config */
/* enable */
SET_CHECKED(rf69_set_sync_enable(dev->spi, rx_cfg->enable_sync));
- if (rx_cfg->enable_sync == optionOn)
+ if (rx_cfg->enable_sync == OPTION_ON)
{
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi,
afterSyncInterrupt));
}
@@ -206,7 +206,7 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
{
SET_CHECKED(rf69_set_fifo_fill_condition(dev->spi, always));
}
- if (rx_cfg->enable_length_byte == optionOn) {
+ if (rx_cfg->enable_length_byte == OPTION_ON) {
ret = rf69_set_packet_format(dev->spi, packetLengthVar);
if (ret < 0)
return ret;
@@ -220,14 +220,14 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
/* lengths */
SET_CHECKED(rf69_set_sync_size(dev->spi, rx_cfg->sync_length));
- if (rx_cfg->enable_length_byte == optionOn)
+ if (rx_cfg->enable_length_byte == OPTION_ON)
{
SET_CHECKED(rf69_set_payload_length(dev->spi, 0xff));
}
else if (rx_cfg->fixed_message_length != 0)
{
payload_length = rx_cfg->fixed_message_length;
- if (rx_cfg->enable_length_byte == optionOn) payload_length++;
+ if (rx_cfg->enable_length_byte == OPTION_ON) payload_length++;
if (rx_cfg->enable_address_filtering != filteringOff)
payload_length++;
SET_CHECKED(rf69_set_payload_length(dev->spi, payload_length));
}
@@ -237,7 +237,7 @@ rf69_set_rx_cfg(struct pi433_device *dev, struct
pi433_rx_cfg *rx_cfg)
}
/* values */
- if (rx_cfg->enable_sync == optionOn)
+ if (rx_cfg->enable_sync == OPTION_ON)
{
SET_CHECKED(rf69_set_sync_values(dev->spi,
rx_cfg->sync_pattern));
}
@@ -264,7 +264,7 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
SET_CHECKED(rf69_set_tx_start_condition(dev->spi,
tx_cfg->tx_start_condition));
/* packet format enable */
- if (tx_cfg->enable_preamble == optionOn)
+ if (tx_cfg->enable_preamble == OPTION_ON)
{
SET_CHECKED(rf69_set_preamble_length(dev->spi,
tx_cfg->preamble_length));
}
@@ -273,7 +273,7 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
SET_CHECKED(rf69_set_preamble_length(dev->spi, 0));
}
SET_CHECKED(rf69_set_sync_enable (dev->spi, tx_cfg->enable_sync));
- if (tx_cfg->enable_length_byte == optionOn) {
+ if (tx_cfg->enable_length_byte == OPTION_ON) {
ret = rf69_set_packet_format(dev->spi, packetLengthVar);
if (ret < 0)
return ret;
@@ -285,7 +285,7 @@ rf69_set_tx_cfg(struct pi433_device *dev, struct
pi433_tx_cfg *tx_cfg)
SET_CHECKED(rf69_set_crc_enable (dev->spi, tx_cfg->enable_crc));
/* configure sync, if enabled */
- if (tx_cfg->enable_sync == optionOn) {
+ if (tx_cfg->enable_sync == OPTION_ON) {
SET_CHECKED(rf69_set_sync_size(dev->spi, tx_cfg->sync_length));
SET_CHECKED(rf69_set_sync_values(dev->spi,
tx_cfg->sync_pattern));
}
@@ -400,7 +400,7 @@ pi433_receive(void *data)
}
/* length byte enabled? */
- if (dev->rx_cfg.enable_length_byte == optionOn)
+ if (dev->rx_cfg.enable_length_byte == OPTION_ON)
{
retval = wait_event_interruptible(dev->fifo_wait_queue,
dev->free_in_fifo <
FIFO_SIZE);
@@ -525,11 +525,11 @@ pi433_tx_thread(void *data)
size = tx_cfg.fixed_message_length;
/* increase size, if len byte is requested */
- if (tx_cfg.enable_length_byte == optionOn)
+ if (tx_cfg.enable_length_byte == OPTION_ON)
size++;
/* increase size, if adr byte is requested */
- if (tx_cfg.enable
[PATCH][next] x86/mm: make function clear_non_loaded_ctxs static
From: Colin Ian King
The function clear_non_loaded_ctxs is local to the source and does
not need to be in global scope, so make it static.
Cleans up sparse warning:
arch/x86/mm/tlb.c:37:6: warning: symbol 'clear_non_loaded_ctxs' was
not declared. Should it be static?
Signed-off-by: Colin Ian King
---
arch/x86/mm/tlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index f75b6eb47a6d..6ecbd8fc292e 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -34,7 +34,7 @@
* necessary invalidation by clearing out the 'ctx_id' which
* forces a TLB flush when the context is loaded.
*/
-void clear_non_loaded_ctxs(void)
+static void clear_non_loaded_ctxs(void)
{
u16 asid;
--
2.14.1
Re: [alsa-devel] [PATCH v4 06/15] soundwire: Add IO transfer
On Fri, Dec 01, 2017 at 05:27:31PM -0600, Pierre-Louis Bossart wrote:
> >+static inline int find_response_code(enum sdw_command_response resp)
> >+{
> >+switch (resp) {
> >+case SDW_CMD_OK:
> >+return 0;
> >+
> >+case SDW_CMD_IGNORED:
> >+return -ENODATA;
> >+
> >+case SDW_CMD_TIMEOUT:
> >+return -ETIMEDOUT;
> >+
> >+default:
> >+return -EIO;
>
> the 'default' case will handle both SDW_CMD_FAIL (which is a bus event
> usually due to bus clash or parity issues) and SDW_CMD_FAIL_OTHER (which is
> an imp-def IP event).
>
> Do they really belong in the same basket? From a debug perspective there is
> quite a bit of information lost.
at higher level the error handling is same. the information is not lost as
it is expected that you would log it at error source.
> >+static inline int do_transfer(struct sdw_bus *bus, struct sdw_msg *msg)
> >+{
> >+int retry = bus->prop.err_threshold;
> >+enum sdw_command_response resp;
> >+int ret = 0, i;
> >+
> >+for (i = 0; i <= retry; i++) {
> >+resp = bus->ops->xfer_msg(bus, msg);
> >+ret = find_response_code(resp);
> >+
> >+/* if cmd is ok or ignored return */
> >+if (ret == 0 || ret == -ENODATA)
>
> Can you document why you don't retry on a CMD_IGNORED? I know there was a
> reason, I just can't remember it.
CMD_IGNORED can be okay on broadcast. User of this API can retry all they
want!
>
> Now that I think of it, the retry on TIMEOUT makes no sense to me. The retry
> was intended for bus-level issues, where maybe a single bit error causes an
> issue without consequences, but the TIMEOUT is a completely different beast,
> it's the master IP that doesn't answer really, a completely different case.
well in those cases where you have blue wires, it actually helps :)
> >+/**
> >+ * sdw_transfer() - Synchronous transfer message to a SDW Slave device
> >+ * @bus: SDW bus
> >+ * @slave: SDW Slave
>
> is this just me or this argument is not used?
That's what happens where API gets reworked umpteen times, thanks for
pointing. Earlier slave was required to get the page address calculation,
now that it is removed, it is no longer required !
> >+int sdw_fill_msg(struct sdw_msg *msg, struct sdw_slave *slave,
> >+u32 addr, size_t count, u16 dev_num, u8 flags, u8 *buf)
> >+{
> >+memset(msg, 0, sizeof(*msg));
> >+msg->addr = addr;
>
> add comment on implicit truncation to 16-bit address
Sure..
> >+msg->len = count;
> >+msg->dev_num = dev_num;
> >+msg->flags = flags;
> >+msg->buf = buf;
> >+msg->ssp_sync = false;
> >+msg->page = false;
> >+
> >+if (addr < SDW_REG_NO_PAGE) { /* no paging area */
> >+return 0;
> >+} else if (addr >= SDW_REG_MAX) { /* illegal addr */
> >+pr_err("SDW: Invalid address %x passed\n", addr);
> >+return -EINVAL;
> >+}
> >+
> >+if (addr < SDW_REG_OPTIONAL_PAGE) { /* 32k but no page */
> >+if (slave && !slave->prop.paging_support)
> >+return 0;
> >+/* no need for else as that will fall thru to paging */
> >+}
> >+
> >+/* paging madatory */
>
> mandatory
thanks for spotting
>
> >+if (dev_num == SDW_ENUM_DEV_NUM || dev_num == SDW_BROADCAST_DEV_NUM) {
> >+pr_err("SDW: Invalid device for paging :%d\n", dev_num);
> >+return -EINVAL;
> >+}
> >+
> >+if (!slave) {
> >+pr_err("SDW: No slave for paging addr\n");
> >+return -EINVAL;
>
> I would move this test up, since if you have a NULL slave you should return
> an error in all case, otherwise there will be an oops in the code below ...
naah, this fn is called for all IO, like broadcast where we have no slave.
So it is really optional for API, but for paging it is mandatory!
>
> >+} else if (!slave->prop.paging_support) {
this wont oops as slave null would never come here
> >+dev_err(&slave->dev,
> >+"address %x needs paging but no support", addr);
> >+return -EINVAL;
> >+}
> >+
> >+msg->addr_page1 = (addr >> SDW_REG_SHIFT(SDW_SCP_ADDRPAGE1_MASK));
> >+msg->addr_page2 = (addr >> SDW_REG_SHIFT(SDW_SCP_ADDRPAGE2_MASK));
> >+msg->addr |= BIT(15);
> >+msg->page = true;
>
> looks ok :-)
finally !!! yeah the paging and IO code has given me most headache till now!
> >+int sdw_nread(struct sdw_slave *slave, u32 addr, size_t count, u8 *val)
> >+{
> >+struct sdw_msg msg;
> >+int ret;
> >+
> >+ret = sdw_fill_msg(&msg, slave, addr, count,
> >+slave->dev_num, SDW_MSG_FLAG_READ, val);
> >+if (ret < 0)
> >+return ret;
> >+
>
> ... if you don't test for the slave argument in the sdw_fill_msg but the
> address is correct then the rest of the code will bomb out.
I dont think so..
> >+struct sdw_msg {
> >+u16 addr;
> >+u16 len;
> >+u16 dev_num;
>
> was th
Re: [PATCH v3 1/6] perf: prepare perf_event.h for new types perf_kprobe and perf_uprobe
On Thu, Nov 30, 2017 at 03:50:18PM -0800, Song Liu wrote:
> Two new perf types, perf_kprobe and perf_uprobe, will be added to allow
> creating [k,u]probe with perf_event_open. These [k,u]probe are associated
> with the file decriptor created by perf_event_open, thus are easy to
> clean when the file descriptor is destroyed.
>
> kprobe_func and uprobe_path are added to union config1 for pointers to
> function name for kprobe or binary path for uprobe.
>
> kprobe_addr and probe_offset are added to union config2 for kernel
> address (when kprobe_func is NULL), or [k,u]probe offset.
>
> Signed-off-by: Song Liu
> Reviewed-by: Yonghong Song
> Reviewed-by: Josef Bacik
> Acked-by: Alexei Starovoitov
> ---
> include/uapi/linux/perf_event.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index 362493a..247c6cb 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -299,6 +299,8 @@ enum perf_event_read_format {
> #define PERF_ATTR_SIZE_VER4 104 /* add: sample_regs_intr */
> #define PERF_ATTR_SIZE_VER5 112 /* add: aux_watermark */
>
> +#define MAX_PROBE_FUNC_NAME_LEN 64
I think we have to remove this restriction.
There are already functions with names longer than 64 characters
in the current vmlinux:
trace_event_define_fields_ext4_ext_convert_to_initialized_fastpath
trace_event_define_fields_mm_vmscan_direct_reclaim_begin_template
How about we drop this restriction and use NAME_MAX internally
without adding new uapi defines ?
Re: [alsa-devel] [PATCH v4 08/15] soundwire: Add Slave status handling helpers
On Fri, Dec 01, 2017 at 05:36:47PM -0600, Pierre-Louis Bossart wrote:
> >+/* called with bus_lock held */
> >+static int sdw_get_device_num(struct sdw_slave *slave)
> >+{
> >+int bit;
> >+
> >+bit = find_first_zero_bit(slave->bus->assigned, SDW_MAX_DEVICES);
> >+if (bit == SDW_MAX_DEVICES) {
> >+bit = -ENODEV;
> >+goto err;
>
> My brain is starting to fry but is this correct? Bit11 seems like a valid
> value. Should it be bit > 15 (assuming bit 12,13,14 are set to avoid using
> groups and master)?
this is correct. You are confusing SDW concept and API return types!
That should be hint for you to start weekend if you didn't do so :D
This API returns max value it was provided (last arg) if it doesn't
find free bit. That's an indication to caller that we ran out of devices
hence ENODEV error!
> >+static int sdw_program_device_num(struct sdw_bus *bus)
> >+{
> >+u8 buf[SDW_NUM_DEV_ID_REGISTERS] = {0};
> >+struct sdw_slave *slave, *_s;
> >+struct sdw_slave_id id;
> >+struct sdw_msg msg;
> >+bool found = false;
> >+int count = 0, ret;
> >+u64 addr;
> >+
> >+/* No Slave, so use raw xfer api */
> >+ret = sdw_fill_msg(&msg, NULL, SDW_SCP_DEVID_0,
> >+SDW_NUM_DEV_ID_REGISTERS, 0, SDW_MSG_FLAG_READ, buf);
> >+if (ret < 0)
> >+return ret;
> >+
> >+do {
> >+ret = sdw_transfer(bus, NULL, &msg);
> >+if (ret == -ENODATA) { /* end of device id reads */
> >+ret = 0;
> >+break;
> >+}
> >+if (ret < 0) {
> >+dev_err(bus->dev, "DEVID read fail:%d\n", ret);
> >+break;
> >+}
> >+
> >+/*
> >+ * Construct the addr and extract. Cast the higher shift
> >+ * bits to avoid truncation due to size limit.
> >+ */
> >+addr = buf[5] | (buf[4] << 8) | (buf[3] << 16) |
> >+(buf[2] << 24) | ((unsigned long long)buf[1] << 32) |
> >+((unsigned long long)buf[0] << 40);
> >+
> >+sdw_extract_slave_id(bus, addr, &id);
> >+
> >+/* Now compare with entries */
> >+list_for_each_entry_safe(slave, _s, &bus->slaves, node) {
> >+if (sdw_compare_devid(slave, id) == 0) {
> >+found = true;
> >+
> >+/*
> >+ * Assign a new dev_num to this Slave and
> >+ * not mark it present. It will be marked
> >+ * present after it reports ATTACHED on new
> >+ * dev_num
> >+ */
> >+ret = sdw_assign_device_num(slave);
> >+if (ret) {
> >+dev_err(slave->bus->dev,
> >+"Assign dev_num failed:%d",
> >+ret);
> >+return ret;
> >+}
> >+
> >+break;
> >+}
> >+}
> >+
> >+if (found == false) {
> >+/* TODO: Park this device in Group 13 */
> >+dev_err(bus->dev, "Slave Entry not found");
> >+}
> >+
> >+count++;
> >+
> >+} while (ret == 0 && count < (SDW_MAX_DEVICES * 2));
>
> explain that the last condition is intentional - this is not a bug -, some
> devices can drop off during enumeration and rejoin so might be counted
> twice.
ok will add
--
~Vinod
Re: [alsa-devel] [PATCH v4 12/15] soundwire: cdns: Add sdw_master_ops and IO transfer support
On Fri, Dec 01, 2017 at 06:02:24PM -0600, Pierre-Louis Bossart wrote:
>
> > struct sdw_cdns {
> > struct device *dev;
> > struct sdw_bus bus;
> > unsigned int instance;
> >+u32 response_buf[0x80];
>
> last nit-pick: use a #define for the size.
okay last one huh :) yeah will add.
> Also are you sure about the value? I vaguely recall that the FIFO was
> 32-deep, you are confusing bytes and words here?
I dont think this is related to FIFO depth, this is buffer to hold values.
Will check though..
--
~Vinod
Re: [alsa-devel] [PATCH v4 09/15] soundwire: Add slave status handling
On Fri, Dec 01, 2017 at 05:52:03PM -0600, Pierre-Louis Bossart wrote:
> >+status = sdw_read(slave, SDW_DP0_INT);
> >+if (status < 0) {
> >+dev_err(slave->bus->dev,
> >+"SDW_DP0_INT read failed:%d", status);
> >+return status;
> >+}
> >+
> >+count++;
> >+
> >+/* we can get alerts while processing so keep retrying */
>
> This is not incorrect, but this goes beyond what the spec requires.
>
> The additional read is to make sure some interrupts are not lost due to a
> known race condition. It would be enough to mask the status read the second
> time to only check if the interrupts sources which were cleared are still
> signaling something.
>
> With the code as it is, you may catch *new* interrupt sources, which could
> impact the arbitration/priority/policy in handling interrupts. It's not
> necessarily bad, but you'd need to document whether you want to deal with
> the race condition described in the MIPI spec or try to be smarter.
This was based on your last comment, lets discuss more offline on this to
see what else is required here.
--
~Vinod
Re: [alsa-devel] [PATCH v4 00/15] soundwire: Add a new SoundWire subsystem
On Fri, Dec 01, 2017 at 06:24:10PM -0600, Pierre-Louis Bossart wrote: > On 12/1/17 3:56 AM, Vinod Koul wrote: > >This patch series adds a new SoundWire subsystem which implements a > >new MIPI bus protocol 'SoundWire'. > > Sorry for the late feedback Vinod and team. > > Overall the code looks very good to me and aligned with the MIPI specs, > there are only a couple of points that were added (or some code not removed) > during the code cleanups, e.g. > - device12..14 should not be used > - device_property handling (master/controller confusion?) > - error cases on transfers > - spec race condition on interrupt clear (not bad but to be discussed > further) > - some comments and code nit-picks > > This is starting to get into second-order reviews really, which shows this > is becoming quite mature. And for the record this work isn't just scratching > the surface, it helped identify a couple of documentation issues in the MIPI > specs which will lead to clarifications in future revisions. Thanks for the good word, most the stuff you pointed needs a very detailed review, so many thaks for spending time on this one. > Looking forward to a v5 ;-) Yeah should be there in next few days.. -- ~Vinod
Use-after-free with deferred driver probing and __initconst
Hi all,
[[ CC'ed: folks relating to the original __*_refok family of attributes,
deferred probing, Open Firmware maintainer, drivers/base/ maintainer,
kernel harderning, LKML ]]
It seems that it is possible to cause a use-after-free in the base driver
platform code using a set of combined circumstances which I describe below.
The instance of the issue happens on a patched 4.4 kernel at a client of
mine.
[6.173692] Process kworker/u12:3 (pid: 173, stack limit =
0xfc3ea92b8000)
[6.180902] Call trace:
[6.183345] [] __of_match_node+0x48/0x8c
[6.188820] [] of_match_node+0x44/0x68
[6.194125] [] of_match_device+0x34/0x48
[6.199603] [] platform_match+0x34/0xa8
[6.204991] [] __device_attach_driver+0x60/0xc8
[6.211077] [] bus_for_each_drv+0x60/0xac
[6.216640] [] __device_attach+0x98/0x124
[6.03] [] device_initial_probe+0x24/0x30
[6.228111] [] bus_probe_device+0x38/0xa0
[6.233677] [] deferred_probe_work_func+0x108/0x128
[6.240111] [] process_one_work+0x268/0x444
[6.245849] [] worker_thread+0x274/0x404
[6.251329] [] kthread+0xe0/0xe8
[6.256114] [] ret_from_fork+0x10/0x50
[6.261415] ---[ end trace fccad0f7d2c2142a ]---
[6.271293] note: kworker/u12:3[173] exited with preempt_count 1
[6.277342] Unable to handle kernel paging request at virtual address
ffd8
It happens while booting, and among other things it requires having platform
OF drivers marking their `of_driver_id` arrays as `__initconst`, e.g:
static const struct of_device_id some_driver_of[] __initconst = {
...
{},
};
Given a platform driver that uses deferred probing, these arrays marked as
`__initconst` could be accessed from a deferred probe path after the init
section of the kernel has been freed. I have not seen anything in the API
related deferred probing that can guard from this scenario.
On kernels prior to KASLR the access is not detected, but it can still happen,
potentially accessing memory that was returned to the page allocator.
On 4.15-rc1, the following shows the ratio between instances of `of_device_id`
arrays and the number of them which are declared`__initconst`:
$ git grep 'struct of_device_id.*\[\]' | wc -l
3089
$ git grep 'struct of_device_id.*\[\]' | grep __initconst | wc -l
117
Not all of these instances are platform drivers, but perhaps deferred
probing with other types of drivers may cause similar issues.
Perhaps it is worthwhile patching stable kernels for the removal of
`__initconst` on these arrays?
And for the larger question -
Freeing of init sections poses an exploitable vulnerability if that memory
is not unmapped, _and_ if there are still accesses taking place due to bugs
of this kind. Linux's build process is supposed to detect references from
non-freed sections to the freed sections, but clearly this instance has
not been detected during build, particularly because we have the `__ref`,
`__refdata`, and `__refconst` attributes which suppress those checks.
Perhaps as a harderning measure, older kernels should be patched with a
config option for not freeing init sections?
--
Dan Aloni
Re: [PATCH 2/2] TESTING! KVM: x86: add invalidate_range mmu notifier
On Fri, Dec 01, 2017 at 04:15:37PM +0100, Paolo Bonzini wrote: > On 30/11/2017 19:05, Radim Krčmář wrote: > > Does roughly what kvm_mmu_notifier_invalidate_page did before. > > > > I am not certain why this would be needed. It might mean that we have > > another bug with start/end or just that I missed something. > > I don't think this is needed, because we don't have shared page tables. > My understanding is that without shared page tables, you can assume that > all page modifications go through invalidate_range_start/end. With > shared page tables, there are additional TLB flushes to take care of, > which require invalidate_range. Agreed, invalidate_range only is ever needed if you the secondary MMU (i.e. KVM) shares the same pagetables of the primary MMU in the host. Only in such case we need a special secondary MMU invalidate in the tlb gather before the page is freed because there's no way to block the secondary MMU from walking the host pagetables in invalidate_range_start. In KVM case the secondary MMU always go through the shadow pagetables, so all shadow pagetable invalidates can happen in invalidate_range_start and patch 2/2 is not needed here. Note that the host kernel could have always decided to call invalidate_range_start/end and never to call invalidate_page even before invalidate_page was removed. So the problem in practice could only be noticed after the removal of invalidate_page of course, but in more theoretical terms 1/2 is actually fixing a longstanding bug. The removal of invalidate_page made the lack of kvm_arch_mmu_notifier_invalidate_page call in invalidate_range_start more apparent. Thanks, Andrea
Re: [PATCH 1/2] KVM: x86: fix APIC page invalidation
On Thu, Nov 30, 2017 at 07:05:45PM +0100, Radim Krčmář wrote: > Implementation of the unpinned APIC page didn't update the VMCS address > cache when invalidation was done through range mmu notifiers. > This became a problem when the page notifier was removed. > > Re-introduce the arch-specific helper and call it from ...range_start. Reviewed-by: Andrea Arcangeli Cc: Thanks, Andrea
Re: [PATCH] refcount_t: documentation for memory ordering differences
On 12/02/2017 10:20 PM, Andrea Parri wrote: > On Fri, Dec 01, 2017 at 12:34:23PM -0800, Randy Dunlap wrote: >> On 11/29/2017 04:36 AM, Elena Reshetova wrote: >>> Some functions from refcount_t API provide different >>> memory ordering guarantees that their atomic counterparts. >>> This adds a document outlining these differences. >>> >>> Signed-off-by: Elena Reshetova >>> --- >>> Documentation/core-api/index.rst | 1 + >>> Documentation/core-api/refcount-vs-atomic.rst | 129 >>> ++ >>> 2 files changed, 130 insertions(+) >>> create mode 100644 Documentation/core-api/refcount-vs-atomic.rst >> >>> diff --git a/Documentation/core-api/refcount-vs-atomic.rst >>> b/Documentation/core-api/refcount-vs-atomic.rst >>> new file mode 100644 >>> index 000..5619d48 >>> --- /dev/null >>> +++ b/Documentation/core-api/refcount-vs-atomic.rst >>> @@ -0,0 +1,129 @@ >>> +=== >>> +refcount_t API compared to atomic_t >>> +=== >>> + >>> +The goal of refcount_t API is to provide a minimal API for implementing >>> +an object's reference counters. While a generic architecture-independent >>> +implementation from lib/refcount.c uses atomic operations underneath, >>> +there are a number of differences between some of the refcount_*() and >>> +atomic_*() functions with regards to the memory ordering guarantees. >>> +This document outlines the differences and provides respective examples >>> +in order to help maintainers validate their code against the change in >>> +these memory ordering guarantees. >>> + >>> +memory-barriers.txt and atomic_t.txt provide more background to the >>> +memory ordering in general and for atomic operations specifically. >>> + >>> +Relevant types of memory ordering >>> += >>> + >>> +**Note**: the following section only covers some of the memory >>> +ordering types that are relevant for the atomics and reference >>> +counters and used through this document. For a much broader picture >>> +please consult memory-barriers.txt document. >>> + >>> +In the absence of any memory ordering guarantees (i.e. fully unordered) >>> +atomics & refcounters only provide atomicity and >>> +program order (po) relation (on the same CPU). It guarantees that >>> +each atomic_*() and refcount_*() operation is atomic and instructions >>> +are executed in program order on a single CPU. >>> +This is implemented using READ_ONCE()/WRITE_ONCE() and >>> +compare-and-swap primitives. >>> + >>> +A strong (full) memory ordering guarantees that all prior loads and >>> +stores (all po-earlier instructions) on the same CPU are completed >>> +before any po-later instruction is executed on the same CPU. >>> +It also guarantees that all po-earlier stores on the same CPU >>> +and all propagated stores from other CPUs must propagate to all >>> +other CPUs before any po-later instruction is executed on the original >>> +CPU (A-cumulative property). This is implemented using smp_mb(). >> >> I don't know what "A-cumulative property" means, and google search didn't >> either. > > The description above seems to follow the (informal) definition given in: > > > https://github.com/aparri/memory-model/blob/master/Documentation/explanation.txt > (c.f., in part., Sect. 13-14) > > and formalized by the LKMM. (The notion of A-cumulativity also appears, in > different contexts, in some memory consistency literature, e.g., > > http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/index.html > http://www.cl.cam.ac.uk/~pes20/armv8-mca/ > https://arxiv.org/abs/1308.6810 ) Got it. Thanks. -- ~Randy
Re: [PATCH 1/5] bpf: correct broken uapi for BPF_PROG_TYPE_PERF_EVENT program type
On Fri, Dec 01, 2017 at 03:19:04PM +0100, Hendrik Brueckner wrote:
> Commit 0515e5999a466dfe ("bpf: introduce BPF_PROG_TYPE_PERF_EVENT
> program type") introduced the bpf_perf_event_data structure which
> exports the pt_regs structure. This is OK for multiple architectures
> but fail for s390 and arm64 which do not export pt_regs. Programs
> using them, for example, the bpf selftest fail to compile on these
> architectures.
>
> For s390, exporting the pt_regs is not an option because s390 wants
> to allow changes to it. For arm64, there is a user_pt_regs structure
> that covers parts of the pt_regs structure for use by user space.
>
> To solve the broken uapi for s390 and arm64, introduce an abstract
> type for pt_regs and add an asm/bpf_perf_event.h file that concretes
> the type. An asm-generic header file covers the architectures that
> export pt_regs today.
>
> The arch-specific enablement for s390 and arm64 follows in separate
> commits.
>
> Reported-by: Thomas Richter
> Fixes: 0515e5999a466dfe ("bpf: introduce BPF_PROG_TYPE_PERF_EVENT program
> type")
> Signed-off-by: Hendrik Brueckner
> Reviewed-and-tested-by: Thomas Richter
> Cc: Arnaldo Carvalho de Melo
> Cc: Peter Zijlstra
> Cc: Ingo Molnar
> Cc: Alexander Shishkin
> Cc: Jiri Olsa
> Cc: Namhyung Kim
> Cc: Arnd Bergmann
> Cc: Alexei Starovoitov
> Cc: Daniel Borkmann
> ---
> include/linux/perf_event.h| 6 +-
> include/uapi/asm-generic/bpf_perf_event.h | 9 +
> include/uapi/linux/bpf_perf_event.h | 5 ++---
> kernel/events/core.c | 2 +-
> 4 files changed, 17 insertions(+), 5 deletions(-)
> create mode 100644 include/uapi/asm-generic/bpf_perf_event.h
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 2c9c87d..7546822 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -15,6 +15,7 @@
> #define _LINUX_PERF_EVENT_H
>
> #include
> +#include
>
> /*
> * Kernel-internal data types and definitions:
> @@ -787,7 +788,7 @@ struct perf_output_handle {
> };
>
> struct bpf_perf_event_data_kern {
> - struct pt_regs *regs;
> + bpf_user_pt_regs_t *regs;
> struct perf_sample_data *data;
> struct perf_event *event;
> };
> @@ -1177,6 +1178,9 @@ extern void perf_tp_event(u16 event_type, u64 count,
> void *record,
> (user_mode(regs) ? PERF_RECORD_MISC_USER :
> PERF_RECORD_MISC_KERNEL)
> # define perf_instruction_pointer(regs) instruction_pointer(regs)
> #endif
> +#ifndef perf_arch_bpf_user_pt_regs
> +# define perf_arch_bpf_user_pt_regs(regs) regs
> +#endif
>
> static inline bool has_branch_stack(struct perf_event *event)
> {
> diff --git a/include/uapi/asm-generic/bpf_perf_event.h
> b/include/uapi/asm-generic/bpf_perf_event.h
> new file mode 100644
> index 000..53815d2
> --- /dev/null
> +++ b/include/uapi/asm-generic/bpf_perf_event.h
> @@ -0,0 +1,9 @@
> +#ifndef _UAPI__ASM_GENERIC_BPF_PERF_EVENT_H__
> +#define _UAPI__ASM_GENERIC_BPF_PERF_EVENT_H__
> +
> +#include
> +
> +/* Export kernel pt_regs structure */
> +typedef struct pt_regs bpf_user_pt_regs_t;
> +
> +#endif /* _UAPI__ASM_GENERIC_BPF_PERF_EVENT_H__ */
> diff --git a/include/uapi/linux/bpf_perf_event.h
> b/include/uapi/linux/bpf_perf_event.h
> index af549d4..8f95303 100644
> --- a/include/uapi/linux/bpf_perf_event.h
> +++ b/include/uapi/linux/bpf_perf_event.h
> @@ -8,11 +8,10 @@
> #ifndef _UAPI__LINUX_BPF_PERF_EVENT_H__
> #define _UAPI__LINUX_BPF_PERF_EVENT_H__
>
> -#include
> -#include
> +#include
>
> struct bpf_perf_event_data {
> - struct pt_regs regs;
> + bpf_user_pt_regs_t regs;
> __u64 sample_period;
> };
Thank you for working on this problem.
The fix looks great to me.
While applying it I noticed few nits:
Applying: selftests/bpf: sync kernel headers and introduce arch support in
Makefile
/w/bpf/.git/rebase-apply/patch:253: trailing whitespace.
freg_t fprs[NUM_FPRS];
/w/bpf/.git/rebase-apply/patch:262: trailing whitespace.
typedef struct
/w/bpf/.git/rebase-apply/patch:439: trailing whitespace.
} lowcore;
/w/bpf/.git/rebase-apply/patch:490: trailing whitespace.
} ptprot_area;
warning: 4 lines add whitespace errors.
Could you please fix those and resubmit ?
With that fixed feel free to add my
Acked-by: Alexei Starovoitov
to the patches.
I've tested it on arm64 and don't see any issues.
When resubmitting could you please reduce cc-list, since this set
went into spam folder for me and I noticed it only in patchworks.
Thanks
Re: [PATCH v2] NTB: ntb_perf: Add full multi-port NTB API support
Hi Serge, I love your patch! Yet something to improve: [auto build test ERROR on v4.15-rc1] [cannot apply to ntb/ntb-next next-20171201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Serge-Semin/NTB-ntb_perf-Add-full-multi-port-NTB-API-support/20171204-011126 config: x86_64-randconfig-x017-201749 (attached as .config) compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): drivers/ntb//test/ntb_perf.c: In function 'perf_msg_cmd_send': >> drivers/ntb//test/ntb_perf.c:375:3: error: implicit declaration of function >> 'ntb_peer_msg_write'; did you mean 'ntb_peer_spad_write'? >> [-Werror=implicit-function-declaration] ntb_peer_msg_write(perf->ntb, peer->pidx, PERF_MSG_LDATA, ^~ ntb_peer_spad_write drivers/ntb//test/ntb_perf.c: In function 'perf_msg_cmd_recv': >> drivers/ntb//test/ntb_perf.c:408:32: warning: passing argument 2 of >> 'ntb_msg_read' makes integer from pointer without a cast [-Wint-conversion] val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_CMD); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int' but argument is of type 'int *' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ >> drivers/ntb//test/ntb_perf.c:408:8: error: too few arguments to function >> 'ntb_msg_read' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_CMD); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: declared here static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:411:32: warning: passing argument 2 of 'ntb_msg_read' makes integer from pointer without a cast [-Wint-conversion] val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_LDATA); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int' but argument is of type 'int *' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ >> drivers/ntb//test/ntb_perf.c:229:25: warning: passing argument 3 of >> 'ntb_msg_read' makes pointer from integer without a cast [-Wint-conversion] #define PERF_MSG_LDATA 1 ^ >> drivers/ntb//test/ntb_perf.c:411:38: note: in expansion of macro >> 'PERF_MSG_LDATA' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_LDATA); ^~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int *' but argument is of type 'int' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:411:8: error: too few arguments to function 'ntb_msg_read' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_LDATA); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: declared here static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:414:32: warning: passing argument 2 of 'ntb_msg_read' makes integer from pointer without a cast [-Wint-conversion] val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_HDATA); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int' but argument is of type 'int *' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:230:25: warning: passing argument 3 of 'ntb_msg_read' makes pointer from integer without a cast [-Wint-conversion] #define PERF_MSG_HDATA 2 ^ >> drivers/ntb//test/ntb_perf.c:414:38: note: in expansion of macro >> 'PERF_MSG_HDATA' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_HDATA); ^~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int *' but argument is of type 'int' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:414:8: error: too few arguments to function 'ntb_msg_read' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_HDATA); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: declared here static in
Re: [PATCH v2] NTB: ntb_perf: Add full multi-port NTB API support
Hi Serge, I love your patch! Perhaps something to improve: [auto build test WARNING on v4.15-rc1] [cannot apply to ntb/ntb-next next-20171201] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Serge-Semin/NTB-ntb_perf-Add-full-multi-port-NTB-API-support/20171204-011126 config: parisc-allmodconfig (attached as .config) compiler: hppa-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=parisc All warnings (new ones prefixed by >>): drivers/ntb//test/ntb_perf.c: In function 'perf_msg_cmd_send': drivers/ntb//test/ntb_perf.c:375:3: error: implicit declaration of function 'ntb_peer_msg_write'; did you mean 'ntb_peer_spad_write'? [-Werror=implicit-function-declaration] ntb_peer_msg_write(perf->ntb, peer->pidx, PERF_MSG_LDATA, ^~ ntb_peer_spad_write drivers/ntb//test/ntb_perf.c: In function 'perf_msg_cmd_recv': drivers/ntb//test/ntb_perf.c:408:32: warning: passing argument 2 of 'ntb_msg_read' makes integer from pointer without a cast [-Wint-conversion] val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_CMD); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int' but argument is of type 'int *' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:408:8: error: too few arguments to function 'ntb_msg_read' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_CMD); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: declared here static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:411:32: warning: passing argument 2 of 'ntb_msg_read' makes integer from pointer without a cast [-Wint-conversion] val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_LDATA); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int' but argument is of type 'int *' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:229:25: warning: passing argument 3 of 'ntb_msg_read' makes pointer from integer without a cast [-Wint-conversion] #define PERF_MSG_LDATA 1 ^ drivers/ntb//test/ntb_perf.c:411:38: note: in expansion of macro 'PERF_MSG_LDATA' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_LDATA); ^~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int *' but argument is of type 'int' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:411:8: error: too few arguments to function 'ntb_msg_read' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_LDATA); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: declared here static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:414:32: warning: passing argument 2 of 'ntb_msg_read' makes integer from pointer without a cast [-Wint-conversion] val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_HDATA); ^~~~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int' but argument is of type 'int *' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:230:25: warning: passing argument 3 of 'ntb_msg_read' makes pointer from integer without a cast [-Wint-conversion] #define PERF_MSG_HDATA 2 ^ drivers/ntb//test/ntb_perf.c:414:38: note: in expansion of macro 'PERF_MSG_HDATA' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_HDATA); ^~ In file included from drivers/ntb//test/ntb_perf.c:89:0: include/linux/ntb.h:1473:19: note: expected 'int *' but argument is of type 'int' static inline int ntb_msg_read(struct ntb_dev *ntb, int midx, int *pidx, ^~~~ drivers/ntb//test/ntb_perf.c:414:8: error: too few arguments to function 'ntb_msg_read' val = ntb_msg_read(perf->ntb, pidx, PERF_MSG_HDATA); ^~~~ I
Re: [PATCH v2 3/3] i2c: at91: added slave mode support
Hi Juergen,
On Thu, Nov 09, 2017 at 06:22:29PM +0100, Juergen Fitschen wrote:
> Slave mode driver is based on the concept of i2c-designware driver.
>
Sorry to be so long to answer you. I would like to test it before acking
it. Unfortunately, I didn't have the time to perform all the tests I
have in mind but I don't way to delay the inclusion of the slave mode
support. If there are bugs or restrictions, we could fix it later.
I tested it quickly on a sama5d2 xplained board: I used an i2c-gpio
master and the eeprom driver. It works pretty well. I tried to increase
the size of the eeprom by adding:
+ { "slave-24c64", 65536 / 8 },
in i2c-slave-eeprom.c. Unfortunately, it no longer works: I get
different checksums. Looking quickly at i2c-slave-eeprom.c, I don't see
any reason why it may not work if I increase the size but I may have
missed something.
I have seen you described how you tested it thanks. Maybe you have also
tried in the same way as me? Did you experience the same behavior?
Regards
Ludovic
> Signed-off-by: Juergen Fitschen
> ---
> Changes in v2:
> - Squashed commit "take slave mode capabilities of hardware into
>account" into this commit
> - Removed unused feature bit AT91_TWI_SM_HAS_FIFO
> - Added NACK support
> - Reworked interrupt handler:
>- The interrupt handler takes into account that several events can
> occur between two handler calls and thus must be handled in one
> handler run. It caanot be assumed that every events triggers the
> handler individually.
>- Instead of using the states register of the I2c interface, a state
> machine is held in the at91_twi_dev struct. This ensures that no
> state transitions are missed due ti interrupt latency.
> - Added Kconfig option for selection whether slave mode suppurt should
>be included in the driver or not
> - Added example in Documentation/devicetree/bindings/i2c/i2c-at91.txt
> ---
> Documentation/devicetree/bindings/i2c/i2c-at91.txt | 14 ++
> drivers/i2c/busses/Kconfig | 10 +
> drivers/i2c/busses/Makefile| 3 +
> drivers/i2c/busses/i2c-at91-core.c | 23 ++-
> drivers/i2c/busses/i2c-at91-slave.c| 216
> +
> drivers/i2c/busses/i2c-at91.h | 42 +++-
> 6 files changed, 304 insertions(+), 4 deletions(-)
> create mode 100644 drivers/i2c/busses/i2c-at91-slave.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> index ef973a0..95c79a8 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> @@ -61,3 +61,17 @@ i2c0: i2c@f8034600 {
> reg = <0x1a>;
> };
> };
> +
> +i2c0: i2c@f8028000 {
> + compatible = "atmel,sama5d2-i2c";
> + reg = <0xf8028000 0x100>;
> + interrupts = <29 4 7>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&twi0_clk>;
> +
> + eeprom@64 {
> + compatible = "linux,slave-24c02";
> + reg = <0x4064>;
> + };
> +};
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 009345d..41338e8 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -380,6 +380,16 @@ config I2C_AT91
> the latency to fill the transmission register is too long. If you
> are facing this situation, use the i2c-gpio driver.
>
> +config I2C_AT91_SLAVE
> + bool "Atmel AT91 I2C Two-Wire interface (TWI) Slave"
> + depends on I2C_AT91 && I2C_SLAVE
> + help
> + This adds slave mode support to the I2C interface on Atmel AT91
> + processors.
> +
> + This is not a standalone module and must be compiled together with the
> + master mode driver.
> +
> config I2C_AU1550
> tristate "Au1550/Au1200/Au1300 SMBus interface"
> depends on MIPS_ALCHEMY
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 2a79c3d..daa2ea4 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -34,6 +34,9 @@ obj-$(CONFIG_I2C_ALTERA)+= i2c-altera.o
> obj-$(CONFIG_I2C_ASPEED) += i2c-aspeed.o
> obj-$(CONFIG_I2C_AT91) += i2c-at91.o
> i2c-at91-objs:= i2c-at91-core.o i2c-at91-master.o
> +ifeq ($(CONFIG_I2C_AT91_SLAVE),y)
> + i2c-at91-objs += i2c-at91-slave.o
> +endif
> obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
> obj-$(CONFIG_I2C_AXXIA) += i2c-axxia.o
> obj-$(CONFIG_I2C_BCM2835)+= i2c-bcm2835.o
> diff --git a/drivers/i2c/busses/i2c-at91-core.c
> b/drivers/i2c/busses/i2c-at91-core.c
> index 4fed72d..cba447e 100644
> --- a/drivers/i2c/busses/i2c-at91-core.c
> +++ b/drivers/i2c/busses/i2c-at91-core.c
> @@ -60,13 +60,16 @@ void at91_init_twi_bus(struct at91_twi_dev *dev)
> {
> at91_disable_twi_interrupts(dev);
> at91_twi_write(dev,
[GIT] Networking
1) Various TCP control block fixes, including one that crashes with SELINUX, from David Ahern and Eric Dumazet. 2) Fix ACK generation in rxrpc, from David Howells. 3) ipvlan doesn't set the mark properly in the ipv4 route lookup key, from Gao Feng. 4) SIT configuration doesn't take on the frag_off ipv4 field configuration properly, fix from Hangbin Liu. 5) TSO can fail after device down/up on stmmac, fix from Lars Persson. 6) Various bpftool fixes (mostly in JSON handling) from Quentin Monnet. 7) Various SKB leak fixes in vhost/tun/tap (mostly observed as performance problems). From Wei Xu. 8) mvpps's TX descriptors were not zero initialized, from Yan Markman. Please pull, thanks a lot! The following changes since commit b9151761021e25c024a6670df4e7c43ffbab0e1d: Merge tag 'nfsd-4.15-1' of git://linux-nfs.org/~bfields/linux (2017-11-29 14:49:26 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git for you to fetch changes up to c2eb6d07a63cb01f0ef978b28927335198c544ce: Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf (2017-12-03 13:08:30 -0500) Colin Ian King (1): liquidio: fix incorrect indentation of assignment statement Cong Wang (1): act_sample: get rid of tcf_sample_cleanup_rcu() Corentin Labbe (1): net: stmmac: dwmac-sun8i: fix allwinner,leds-active-low handling Daniel Borkmann (1): Merge branch 'bpftool-misc-fixes' David Ahern (1): tcp: use IPCB instead of TCP_SKB_CB in inet_exact_dif_match() David Howells (4): rxrpc: Clean up whitespace rxrpc: Fix ACK generation from the connection event processor rxrpc: Use correct netns source in rxrpc_release_sock() rxrpc: Fix the MAINTAINERS record David S. Miller (9): Merge tag 'rxrpc-fixes-20171129' of git://git.kernel.org/.../dhowells/linux-fs Merge branch 'sctp-prsctp-chunk-fixes' Merge branch 'sfp-phylink-fixes' Merge branch 'bnxt_en-fixes' Merge branch 'vhost-skb-leaks' Merge branch 's390-qeth-fixes' Merge tag 'linux-can-fixes-for-4.15-20171201' of git://git.kernel.org/.../mkl/linux-can Merge branch 'tcp-cb-selinux-corruption' Merge git://git.kernel.org/.../bpf/bpf Eric Dumazet (3): tcp: remove buggy call to tcp_v6_restore_cb() tcp/dccp: block bh before arming time_wait timer tcp: add tcp_v4_fill_cb()/tcp_v4_restore_cb() Florian Fainelli (1): net: dsa: bcm_sf2: Set correct CHAIN_ID and slice number mask Gao Feng (1): ipvlan: Add the skb->mark as flow4's member to lookup route Geert Uytterhoeven (1): skbuff: Grammar s/are can/can/, s/change/changes/ Gustavo A. R. Silva (1): rxrpc: Fix variable overwrite Hangbin Liu (1): sit: update frag_off info Jakub Kicinski (1): bpf: offload: add a license header Jimmy Assarsson (3): can: kvaser_usb: free buf in error paths can: kvaser_usb: Fix comparison bug in kvaser_usb_read_bulk_callback() can: kvaser_usb: ratelimit errors if incomplete messages are received Julian Wiedmann (3): s390/qeth: fix thinko in IPv4 multicast address tracking s390/qeth: fix GSO throughput regression s390/qeth: build max size GSO skbs on L2 devices Lars Persson (1): stmmac: reset last TSO segment size after device open Marc Kleine-Budde (2): can: flexcan: Update IRQ Err Passive information can: flexcan: fix VF610 state transition issue Martin Kelly (2): can: mcba_usb: fix typo can: mcba_usb: fix device disconnect bug Max Uvarov (1): net: phy-micrel: check return code in flp center function Oliver Stäbler (1): can: ti_hecc: Fix napi poll return value for repoll Quentin Monnet (6): tools: bpftool: fix crash on bad parameters with JSON tools: bpftool: clean up the JSON writer before exiting in usage() tools: bpftool: make error message from getopt_long() JSON-friendly tools: bpftool: remove spurious line break from error message tools: bpftool: unify installation directories tools: bpftool: declare phony targets as such Ray Jui (1): bnxt_en: Need to unconditionally shut down RoCE in bnxt_shutdown Russell King (4): sfp: fix RX_LOS signal handling sfp: improve RX_LOS handling sfp: warn about modules requiring address change sequence phylink: ensure we take the link down when phylink_stop() is called Sathya Perla (1): bnxt_en: fix dst/src fid for vxlan encap/decap actions Stephane Grosjean (1): can: peak/pci: fix potential bug when probe() fails Sunil Challa (1): bnxt_en: wildcard smac while creating tunnel decap filter Tommi Rantala (1): tipc: call tipc_rcv() only if bearer is up in tipc_udp_recv() Vasundhara Volam (1): bnxt_en: Fix a variable scoping in bnxt_hwrm_do_send_msg() Wei Xu (3): vhost: fix skb leak in ha
