Re: [PATCH 2/6] staging: most: aim-cdev: remove labels
On Wed, Sep 21, 2016 at 02:49:06PM +0200, Christian Gromm wrote:
> From: Andrey Shvetsov
>
> This patch removes the labels 'put_mbo' and 'unlock' and relocates the
> code accordingly making the code look simpler.
But this is the opposite of what you should normally do. Now you have
to keep track of what needs to be unlocked within each error section.
>
> Signed-off-by: Andrey Shvetsov
> Signed-off-by: Christian Gromm
> ---
> drivers/staging/most/aim-cdev/cdev.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/most/aim-cdev/cdev.c
> b/drivers/staging/most/aim-cdev/cdev.c
> index 5458fb9..f6a7b75 100644
> --- a/drivers/staging/most/aim-cdev/cdev.c
> +++ b/drivers/staging/most/aim-cdev/cdev.c
> @@ -183,7 +183,6 @@ static int aim_close(struct inode *inode, struct file
> *filp)
> static ssize_t aim_write(struct file *filp, const char __user *buf,
>size_t count, loff_t *offset)
> {
> - int ret;
> size_t actual_len;
> size_t max_len;
> struct mbo *mbo = NULL;
> @@ -201,8 +200,8 @@ static ssize_t aim_write(struct file *filp, const char
> __user *buf,
> }
>
> if (unlikely(!c->dev)) {
> - ret = -ENODEV;
> - goto unlock;
> + mutex_unlock(&c->io_mutex);
> + return -ENODEV;
> }
>
> max_len = c->cfg->buffer_size;
> @@ -210,18 +209,14 @@ static ssize_t aim_write(struct file *filp, const char
> __user *buf,
> mbo->buffer_length = actual_len;
>
> if (copy_from_user(mbo->virt_address, buf, mbo->buffer_length)) {
> - ret = -EFAULT;
> - goto put_mbo;
> + most_put_mbo(mbo);
> + mutex_unlock(&c->io_mutex);
> + return -EFAULT;
> }
>
> most_submit_mbo(mbo);
> mutex_unlock(&c->io_mutex);
> return actual_len;
> -put_mbo:
> - most_put_mbo(mbo);
> -unlock:
> - mutex_unlock(&c->io_mutex);
> - return ret;
The code is "simpler" as-is, as it follows the normal good kernel coding
style. I don't understand why you are changing this...
greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 3/6] staging: most: aim-cdev: make syscall write accept buffers of arbitrary size
On Wed, Sep 21, 2016 at 02:49:07PM +0200, Christian Gromm wrote: > From: Andrey Shvetsov > > This patch allows to call the write() function for synchronous and > isochronous channels with buffers of any size. The AIM simply waits for > data to fill up the MOST buffer object according to the network interface > controller specification for streaming channels, before it submits the > buffer to the HDM. > > The new behavior is backward compatible to the old applications, since > all known applications needed to fill the buffer completely anyway. > > Signed-off-by: Andrey Shvetsov > Signed-off-by: Christian Gromm > --- > drivers/staging/most/aim-cdev/cdev.c | 33 + > 1 file changed, 21 insertions(+), 12 deletions(-) This one didn't apply as I dropped patch 2/6 in this series, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ion: Fix checkpatch.pl coding style issues
On Thu, Sep 22, 2016 at 09:57:16AM +0300, Antti Keränen wrote: > This patch fixes two coding style issues found with checkpatch.pl. Both > of them are warnings. Ah, then this should be two separate patches :) Also, always use scripts/get_maintainer.pl to determine who to cc: on a patch. > > uapi/ion.h had an unaligned block comment. ion/hisilicon/hi6220_ion.c > had unnecessary braces around a single statement block. > > One warning in uapi/ion.h was left in place that wanted a typedef > (ion_user_handle_t) to be removed. I think the typedef makes sense so > I left it intact. Again, this paragraph makes no sense, don't talk about what you did not do, why would that matter in a changelog comment? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] rtl871x: use tabs with indentation instead of spaces
On Wed, Sep 21, 2016 at 11:12:05PM +0200, Christopher Pezley wrote: > There is a line with space indentation instead of tabs. I've changed it to > use tabs for indentation. > > Signed-off-by: Christopher H. Pezley > --- > drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This patch does not apply to my tree at all, are you sure you made it against linux-next? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/11] staging: dgnc: remove redundant initialization for
On Thu, Sep 22, 2016 at 02:20:51PM +0900, Daeseok Youn wrote: > The channel array in board_t was initialized in dgnc_found_board() > with NULL. But the channel is going to initialize in dgnc_tty_init(). > So the channel array doesn't need to set NULL for initailization. > > Signed-off-by: Daeseok Youn > --- > drivers/staging/dgnc/dgnc_driver.c | 3 --- > 1 file changed, 3 deletions(-) Your subject is odd, why end in "for"? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/11] staging: dgnc: missing NULL check for ioremap in
On Thu, Sep 22, 2016 at 02:21:38PM +0900, Daeseok Youn wrote: > The ioremap() function can be failed, so it need to have error > handling in dgnc_do_remap(). And also the return type of > dgnc_do_remap() should be changed from "void" to "int" > > Signed-off-by: Daeseok Youn > --- > drivers/staging/dgnc/dgnc_driver.c | 31 +-- > 1 file changed, 21 insertions(+), 10 deletions(-) Again, odd subject line, it seems to have been cut off. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 04/11] staging: dgnc: kfree for board structure in
On Thu, Sep 22, 2016 at 02:22:03PM +0900, Daeseok Youn wrote: > The board structure should be freed when any function was failed > in dgnc_found_board(). And the board strucure will be stored > into dgnc_board array when the dgnc_found_board() function has no error. > > Signed-off-by: Daeseok Youn > --- > drivers/staging/dgnc/dgnc_driver.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) Another shortened subject line. Please look at all of the subjects in this series, fix them up, and resend. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 3/6] staging: most: aim-cdev: make syscall write accept buffers of arbitrary size
This patch allows to call the write() function for synchronous and
isochronous channels with buffers of any size. The AIM simply waits for
data to fill up the MOST buffer object according to the network interface
controller specification for streaming channels, before it submits the
buffer to the HDM.
The new behavior is backward compatible to the old applications, since
all known applications needed to fill the buffer completely anyway.
Signed-off-by: Christian Gromm
---
v2: Since the previous patch of this series has beed dropped, this patch
needed some adaptation work to match the source tree again.
drivers/staging/most/aim-cdev/cdev.c | 37 +---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/most/aim-cdev/cdev.c
b/drivers/staging/most/aim-cdev/cdev.c
index 5458fb9..7f51024 100644
--- a/drivers/staging/most/aim-cdev/cdev.c
+++ b/drivers/staging/most/aim-cdev/cdev.c
@@ -57,7 +57,11 @@ static inline bool ch_has_mbo(struct aim_channel *c)
static inline bool ch_get_mbo(struct aim_channel *c, struct mbo **mbo)
{
- *mbo = most_get_mbo(c->iface, c->channel_id, &cdev_aim);
+ if (!kfifo_peek(&c->fifo, mbo)) {
+ *mbo = most_get_mbo(c->iface, c->channel_id, &cdev_aim);
+ if (*mbo)
+ kfifo_in(&c->fifo, mbo, 1);
+ }
return *mbo;
}
@@ -184,8 +188,7 @@ static ssize_t aim_write(struct file *filp, const char
__user *buf,
size_t count, loff_t *offset)
{
int ret;
- size_t actual_len;
- size_t max_len;
+ size_t to_copy, left;
struct mbo *mbo = NULL;
struct aim_channel *c = filp->private_data;
@@ -205,20 +208,24 @@ static ssize_t aim_write(struct file *filp, const char
__user *buf,
goto unlock;
}
- max_len = c->cfg->buffer_size;
- actual_len = min(count, max_len);
- mbo->buffer_length = actual_len;
-
- if (copy_from_user(mbo->virt_address, buf, mbo->buffer_length)) {
+ to_copy = min(count, c->cfg->buffer_size - c->mbo_offs);
+ left = copy_from_user(mbo->virt_address + c->mbo_offs, buf, to_copy);
+ if (left == to_copy) {
ret = -EFAULT;
- goto put_mbo;
+ goto unlock;
}
- most_submit_mbo(mbo);
- mutex_unlock(&c->io_mutex);
- return actual_len;
-put_mbo:
- most_put_mbo(mbo);
+ c->mbo_offs += to_copy - left;
+ if (c->mbo_offs >= c->cfg->buffer_size ||
+ c->cfg->data_type == MOST_CH_CONTROL ||
+ c->cfg->data_type == MOST_CH_ASYNC) {
+ kfifo_skip(&c->fifo);
+ mbo->buffer_length = c->mbo_offs;
+ c->mbo_offs = 0;
+ most_submit_mbo(mbo);
+ }
+
+ ret = to_copy - left;
unlock:
mutex_unlock(&c->io_mutex);
return ret;
@@ -287,7 +294,7 @@ static unsigned int aim_poll(struct file *filp, poll_table
*wait)
if (!kfifo_is_empty(&c->fifo))
mask |= POLLIN | POLLRDNORM;
} else {
- if (ch_has_mbo(c))
+ if (!kfifo_is_empty(&c->fifo) || ch_has_mbo(c))
mask |= POLLOUT | POLLWRNORM;
}
return mask;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing 998/1004] drivers/staging/i4l/act2000/act2000_isa.c:81:3: error: implicit declaration of function 'netdev_warn'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-testing
head: 2a38ef60ef4ffe135566d1b8acc197b803c48ec1
commit: 94b9eba50e3ad6fafe88d71da4a7345ebe87cdfb [998/1004] staging: i4l:
act2000: Replace printk(KERN_WARNING..) with netdev_warn(dev, ..)
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 94b9eba50e3ad6fafe88d71da4a7345ebe87cdfb
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/staging/i4l/act2000/act2000_isa.c: In function
'act2000_isa_interrupt':
>> drivers/staging/i4l/act2000/act2000_isa.c:81:3: error: implicit declaration
>> of function 'netdev_warn' [-Werror=implicit-function-declaration]
netdev_warn(dev, "act2000: errIRQ\n");
^~~
>> drivers/staging/i4l/act2000/act2000_isa.c:81:15: error: 'dev' undeclared
>> (first use in this function)
netdev_warn(dev, "act2000: errIRQ\n");
^~~
drivers/staging/i4l/act2000/act2000_isa.c:81:15: note: each undeclared
identifier is reported only once for each function it appears in
drivers/staging/i4l/act2000/act2000_isa.c: In function
'act2000_isa_config_irq':
drivers/staging/i4l/act2000/act2000_isa.c:150:15: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev, "act2000: Could not request irq %d\n", irq);
^~~
drivers/staging/i4l/act2000/act2000_isa.c: In function 'act2000_isa_receive':
drivers/staging/i4l/act2000/act2000_isa.c:248:19: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev, "act2000_isa_receive: no memory\n");
^~~
drivers/staging/i4l/act2000/act2000_isa.c: In function 'act2000_isa_getid':
drivers/staging/i4l/act2000/act2000_isa.c:370:15: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev, "act2000: No Firmware-ID!\n");
^~~
drivers/staging/i4l/act2000/act2000_isa.c: In function
'act2000_isa_download':
drivers/staging/i4l/act2000/act2000_isa.c:426:17: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev,
^~~
cc1: some warnings being treated as errors
vim +/netdev_warn +81 drivers/staging/i4l/act2000/act2000_isa.c
75 act2000_isa_receive(card);
76 outb(ISA_SIS_INT, ISA_PORT_SIS);
77 }
78 if (istatus & ISA_ISR_ERR) {
79 /* Error Interrupt */
80 istatus &= ISA_ISR_ERR_MASK;
> 81 netdev_warn(dev, "act2000: errIRQ\n");
82 }
83 if (istatus)
84 printk(KERN_DEBUG "act2000: ?IRQ %d %02x\n", card->irq,
istatus);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] iio: accel: sca3000_core: avoid potentially uninitialized variable
The newly added __sca3000_get_base_freq function handles all valid
modes of the SCA3000_REG_ADDR_MODE register, but gcc notices
that any other value (i.e. 0x00) causes the base_freq variable to
not get initialized:
drivers/staging/iio/accel/sca3000_core.c: In function 'sca3000_write_raw':
drivers/staging/iio/accel/sca3000_core.c:527:23: error: 'base_freq' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
This adds explicit error handling for unexpected register values,
to ensure this cannot happen.
Fixes: e0f3fc9b47e6 ("iio: accel: sca3000_core: implemented
IIO_CHAN_INFO_SAMP_FREQ")
Signed-off-by: Arnd Bergmann
---
drivers/staging/iio/accel/sca3000_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/iio/accel/sca3000_core.c
b/drivers/staging/iio/accel/sca3000_core.c
index d626125d7af9..564b36d4f648 100644
--- a/drivers/staging/iio/accel/sca3000_core.c
+++ b/drivers/staging/iio/accel/sca3000_core.c
@@ -468,6 +468,8 @@ static inline int __sca3000_get_base_freq(struct
sca3000_state *st,
case SCA3000_MEAS_MODE_OP_2:
*base_freq = info->option_mode_2_freq;
break;
+ default:
+ ret = -EINVAL;
}
error_ret:
return ret;
--
2.9.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 998/1004] drivers/staging/i4l/act2000/act2000_isa.c:81:3: error: implicit declaration of function 'netdev_warn'
On Thu, Sep 22, 2016 at 05:38:27PM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > staging-testing > head: 2a38ef60ef4ffe135566d1b8acc197b803c48ec1 > commit: 94b9eba50e3ad6fafe88d71da4a7345ebe87cdfb [998/1004] staging: i4l: > act2000: Replace printk(KERN_WARNING..) with netdev_warn(dev, ..) > config: i386-allmodconfig (attached as .config) > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > reproduce: > git checkout 94b9eba50e3ad6fafe88d71da4a7345ebe87cdfb > # save the attached .config to linux build tree > make ARCH=i386 > > All errors (new ones prefixed by >>): > >drivers/staging/i4l/act2000/act2000_isa.c: In function > 'act2000_isa_interrupt': > >> drivers/staging/i4l/act2000/act2000_isa.c:81:3: error: implicit > >> declaration of function 'netdev_warn' > >> [-Werror=implicit-function-declaration] > netdev_warn(dev, "act2000: errIRQ\n"); > ^~~ Ugh. sayli, I'm just going to drop this patch from my tree, please be more careful when making changes that you test build them. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/7] selftest: sync: basic tests for sw_sync framework
Emilio López writes: > These tests are based on the libsync test suite from Android. > This commit lays the ground for future tests, as well as includes > tests for a variety of basic allocation commands. Hi Emilio, Just a few comments on the Makefile. > diff --git a/tools/testing/selftests/sync/Makefile > b/tools/testing/selftests/sync/Makefile > new file mode 100644 > index 000..f67827f > --- /dev/null > +++ b/tools/testing/selftests/sync/Makefile > @@ -0,0 +1,24 @@ > +CC = $(CROSS_COMPILE)gcc lib.mk does that for you. > +CFLAGS := -O2 -g -std=gnu89 -pthread -Wall -Wextra It's more polite to just add to CFLAGS rather than defining it from scratch. That way a user can add CFLAGS via setting them in the environment. ie. this would be: CFLAGS += -O2 -g -std=gnu89 -pthread -Wall -Wextra or: CFLAGS := -O2 -g -std=gnu89 -pthread -Wall -Wextra $(CFLAGS) > +CFLAGS += -I../../../../include/uapi/ Please don't include the unprocessed uapi headers, they are not meant to be directly included in userspace programs. They even say so: include/uapi/linux/types.h:#warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders"; > +CFLAGS += -I../../../../include/ Please don't include the *kernel* headers, they're really not meant to be used in userspace programs :) > +CFLAGS += -I../../../../usr/include/ That is the correct place to get them from. They'll have been put there by 'make headers_install'. > +CFLAGS += -I../../../../drivers/dma-buf/ That's also a bit fishy. > +LDFLAGS += -pthread > + > +TEST_PROGS = sync_test > + > +all: $(TEST_PROGS) > + > +include ../lib.mk > + > +SRC = sync_test.o sync.o SRC would usually point to .c files, .o's would be in OBJS or something similar. Though it's not that important obviously. Just listing the .c files in SRC should work, make knows how to turn them into .o's for you. > +TESTS += sync_alloc.o And similarly there. So I think you could just use: SRC := sync_test.c sync.c sync_alloc.c Or if you actually just want to list all the .c files in the directory then this would also work: SRC := $(wildcard *.c) > +sync_test: $(SRC) $(TESTS) > + > +.PHONY: clean lib.mk did that for you. > + > +clean: > + $(RM) sync_test $(SRC) $(TESTS) If you redefined SRC above to be the actual sources then you obviously don't want to clean them, so here you would just use *.o. cheers ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [staging:staging-testing 998/1004] drivers/staging/i4l/act2000/act2000_isa.c:81:3: error: implicit declaration of function 'netdev_warn'
On Thu, Sep 22, 2016 at 11:53:57AM +0200, Greg Kroah-Hartman wrote: > On Thu, Sep 22, 2016 at 05:38:27PM +0800, kbuild test robot wrote: > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git > > staging-testing > > head: 2a38ef60ef4ffe135566d1b8acc197b803c48ec1 > > commit: 94b9eba50e3ad6fafe88d71da4a7345ebe87cdfb [998/1004] staging: i4l: > > act2000: Replace printk(KERN_WARNING..) with netdev_warn(dev, ..) > > config: i386-allmodconfig (attached as .config) > > compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 > > reproduce: > > git checkout 94b9eba50e3ad6fafe88d71da4a7345ebe87cdfb > > # save the attached .config to linux build tree > > make ARCH=i386 > > > > All errors (new ones prefixed by >>): > > > >drivers/staging/i4l/act2000/act2000_isa.c: In function > > 'act2000_isa_interrupt': > > >> drivers/staging/i4l/act2000/act2000_isa.c:81:3: error: implicit > > >> declaration of function 'netdev_warn' > > >> [-Werror=implicit-function-declaration] > > netdev_warn(dev, "act2000: errIRQ\n"); > > ^~~ > > Ugh. sayli, I'm just going to drop this patch from my tree, please be > more careful when making changes that you test build them. I've dropped all of the i4l patches that I just took. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[staging:staging-testing 1000/1004] drivers/staging/i4l/act2000/act2000_isa.c:385:3: error: implicit declaration of function 'netdev_dbg'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
staging-testing
head: 2a38ef60ef4ffe135566d1b8acc197b803c48ec1
commit: bce83de2578b37f1be039977278e8691a597ea7d [1000/1004] staging: i4l:
act2000: Replace printk(KERN_DEBUG..) with netdev_dbg(dev, ..)
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout bce83de2578b37f1be039977278e8691a597ea7d
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/staging/i4l/act2000/act2000_isa.c: In function
'act2000_isa_interrupt':
drivers/staging/i4l/act2000/act2000_isa.c:81:3: error: implicit declaration
of function 'netdev_warn' [-Werror=implicit-function-declaration]
netdev_warn(dev, "act2000: errIRQ\n");
^~~
drivers/staging/i4l/act2000/act2000_isa.c:81:15: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev, "act2000: errIRQ\n");
^~~
drivers/staging/i4l/act2000/act2000_isa.c:81:15: note: each undeclared
identifier is reported only once for each function it appears in
drivers/staging/i4l/act2000/act2000_isa.c: In function
'act2000_isa_config_irq':
drivers/staging/i4l/act2000/act2000_isa.c:150:15: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev, "act2000: Could not request irq %d\n", irq);
^~~
drivers/staging/i4l/act2000/act2000_isa.c: In function 'act2000_isa_receive':
drivers/staging/i4l/act2000/act2000_isa.c:248:19: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev, "act2000_isa_receive: no memory\n");
^~~
drivers/staging/i4l/act2000/act2000_isa.c: In function 'act2000_isa_getid':
drivers/staging/i4l/act2000/act2000_isa.c:371:15: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev, "act2000: No Firmware-ID!\n");
^~~
>> drivers/staging/i4l/act2000/act2000_isa.c:385:3: error: implicit declaration
>> of function 'netdev_dbg' [-Werror=implicit-function-declaration]
netdev_dbg(dev, "Enabling Interrupts ...\n");
^~
drivers/staging/i4l/act2000/act2000_isa.c: In function
'act2000_isa_download':
drivers/staging/i4l/act2000/act2000_isa.c:427:17: error: 'dev' undeclared
(first use in this function)
netdev_warn(dev,
^~~
cc1: some warnings being treated as errors
vim +/netdev_dbg +385 drivers/staging/i4l/act2000/act2000_isa.c
242
243 if (valid) {
244 card->idat.isa.rcvlen =
((actcapi_msghdr *)&card->idat.isa.rcvhdr)->len;
245 card->idat.isa.rcvskb =
dev_alloc_skb(card->idat.isa.rcvlen);
246 if (!card->idat.isa.rcvskb) {
247
card->idat.isa.rcvignore = 1;
> 248 netdev_warn(dev,
> "act2000_isa_receive: no memory\n");
249
test_and_clear_bit(ACT2000_LOCK_RX, (void *)&card->ilock);
250 return;
251 }
252
memcpy(skb_put(card->idat.isa.rcvskb, 8), card->idat.isa.rcvhdr, 8);
253 card->idat.isa.rcvptr =
skb_put(card->idat.isa.rcvskb, card->idat.isa.rcvlen - 8);
254 } else {
255 card->idat.isa.rcvidx = 0;
256 netdev_warn(dev,
"act2000_isa_receive: Invalid CAPI msg\n");
257 {
258 int i; __u8 *p; __u8
*t; __u8 tmp[30];
259
260 for (i = 0, p = (__u8
*)&card->idat.isa.rcvhdr, t = tmp; i < 8; i++)
261 t += sprintf(t,
"%02x ", *(p++));
262 netdev_warn(dev,
"act2000_isa_receive: %s\n", tmp);
263 }
264 }
265 }
266 } else {
267 if (!card->idat.isa.rcvignore)
268 *card->idat.isa.rcvptr++ = c;
269 if (++card->idat.isa.rcvidx >=
card->idat.isa.rcvlen) {
270 if (!card->idat.isa.rcvignore) {
271 skb_queue_tail(&card->rcvq,
card->idat.isa.rcvskb);
272 act2000_schedule_rx(card);
273
[PATCH v2 2/2] staging: ion: Fix a coding style issue
Correctly align an unaligned block comment
Signed-off-by: Antti Keränen
---
drivers/staging/android/uapi/ion.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/uapi/ion.h
b/drivers/staging/android/uapi/ion.h
index 647f130..e629394 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -57,7 +57,7 @@ enum ion_heap_type {
* cached, ion will do cache
* maintenance when the buffer is
* mapped for dma
- */
+*/
#define ION_FLAG_CACHED_NEEDS_SYNC 2 /*
* mappings of this buffer will created
* at mmap time, if this is set
--
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/2] staging: ion: Fix a coding style issue
Remove unnecessary braces surrounding a single statement block
Signed-off-by: Antti Keränen
---
drivers/staging/android/ion/hisilicon/hi6220_ion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
index 659aa71..bd45151 100644
--- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
+++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
@@ -82,9 +82,9 @@ static int hi6220_ion_remove(struct platform_device *pdev)
ipdev = platform_get_drvdata(pdev);
- for (i = 0; i < ipdev->data->nr; i++) {
+ for (i = 0; i < ipdev->data->nr; i++)
ion_heap_destroy(ipdev->heaps[i]);
- }
+
ion_destroy_platform_data(ipdev->data);
ion_device_destroy(ipdev->idev);
--
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 05/28] KVM: SVM: prepare for new bit definition in nested_ctl
On Mon, Aug 22, 2016 at 07:24:32PM -0400, Brijesh Singh wrote: > From: Tom Lendacky > > Currently the nested_ctl variable in the vmcb_control_area structure is > used to indicate nested paging support. The nested paging support field > is actually defined as bit 0 of the this field. In order to support a new > feature flag the usage of the nested_ctl and nested paging support must > be converted to operate on a single bit. > > Signed-off-by: Tom Lendacky > --- > arch/x86/include/asm/svm.h |2 ++ > arch/x86/kvm/svm.c |7 --- > 2 files changed, 6 insertions(+), 3 deletions(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/2] staging: ion: Fix checkpatch.pl coding style issues
This set of patches fix two coding style warnings found with checkpatch.pl I hope I got this correctly this time around :) Antti Keränen (2): staging: ion: Fix a coding style issue staging: ion: Fix a coding style issue drivers/staging/android/ion/hisilicon/hi6220_ion.c | 4 ++-- drivers/staging/android/uapi/ion.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/7] selftest: sync: basic tests for sw_sync framework
Hi Michael, El 22/09/16 a las 06:43, Michael Ellerman escribió: Emilio López writes: +CFLAGS += -I../../../../include/uapi/ Please don't include the unprocessed uapi headers, they are not meant to be directly included in userspace programs. They even say so: include/uapi/linux/types.h:#warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders"; +CFLAGS += -I../../../../include/ Please don't include the *kernel* headers, they're really not meant to be used in userspace programs :) +CFLAGS += -I../../../../usr/include/ That is the correct place to get them from. They'll have been put there by 'make headers_install'. +CFLAGS += -I../../../../drivers/dma-buf/ That's also a bit fishy. My inspiration here has been tools/testing/selftests/memfd/Makefile, which does it this way. If I only include the ones on usr then it doesn't build, as there's no sync_file.h available, even after running make headers_install. How am I supposed to use the ioctls from there? The dma-buf include path is a leftover from the previous version, there's no longer any headers there. I've fixed the other things you pointed out, the new Makefile is below if you want to take another look. Thanks for the review! :) Emilio --- CFLAGS += -O2 -g -std=gnu89 -pthread -Wall -Wextra CFLAGS += -I../../../../usr/include/ LDFLAGS += -pthread TEST_PROGS = sync_test all: $(TEST_PROGS) include ../lib.mk OBJS = sync_test.o sync.o TESTS += sync_alloc.o TESTS += sync_fence.o TESTS += sync_merge.o TESTS += sync_wait.o TESTS += sync_stress_parallelism.o TESTS += sync_stress_consumer.o TESTS += sync_stress_merge.o sync_test: $(OBJS) $(TESTS) clean: $(RM) sync_test $(OBJS) $(TESTS) ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On Mon, Aug 22, 2016 at 07:25:25PM -0400, Brijesh Singh wrote:
> From: Tom Lendacky
>
> EFI data is encrypted when the kernel is run under SEV. Update the
> page table references to be sure the EFI memory areas are accessed
> encrypted.
>
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/platform/efi/efi_64.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 0871ea4..98363f3 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -213,7 +213,7 @@ void efi_sync_low_kernel_mappings(void)
>
> int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
> {
> - unsigned long pfn, text;
> + unsigned long pfn, text, flags;
> efi_memory_desc_t *md;
> struct page *page;
> unsigned npages;
> @@ -230,6 +230,10 @@ int __init efi_setup_page_tables(unsigned long
> pa_memmap, unsigned num_pages)
> efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
> pgd = efi_pgd;
>
> + flags = _PAGE_NX | _PAGE_RW;
> + if (sev_active)
> + flags |= _PAGE_ENC;
So this is confusing me. There's this patch which says EFI data is
accessed in the clear:
https://lkml.kernel.org/r/2016083738.29880.6909.st...@tlendack-t1.amdoffice.net
but now here it is encrypted when SEV is enabled.
Do you mean, it is encrypted here because we're in the guest kernel?
Thanks.
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
--
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 22/09/2016 16:35, Borislav Petkov wrote: >> > @@ -230,6 +230,10 @@ int __init efi_setup_page_tables(unsigned long >> > pa_memmap, unsigned num_pages) >> >efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd); >> >pgd = efi_pgd; >> > >> > + flags = _PAGE_NX | _PAGE_RW; >> > + if (sev_active) >> > + flags |= _PAGE_ENC; > So this is confusing me. There's this patch which says EFI data is > accessed in the clear: > > https://lkml.kernel.org/r/2016083738.29880.6909.st...@tlendack-t1.amdoffice.net > > but now here it is encrypted when SEV is enabled. > > Do you mean, it is encrypted here because we're in the guest kernel? I suspect this patch is untested, and also wrong. :) The main difference between the SME and SEV encryption, from the point of view of the kernel, is that real-mode always writes unencrypted in SME and always writes encrypted in SEV. But UEFI can run in 64-bit mode and learn about the C bit, so EFI boot data should be unprotected in SEV guests. Because the firmware volume is written to high memory in encrypted form, and because the PEI phase runs in 32-bit mode, the firmware code will be encrypted; on the other hand, data that is placed in low memory for the kernel can be unencrypted, thus limiting differences between SME and SEV. Important: I don't know what you guys are doing for SEV and Windows guests, but if you are doing something I would really appreciate doing things in the open. If Linux and Windows end up doing different things with EFI boot data, ACPI tables, etc. it will be a huge pain. On the other hand, if we can enjoy being first, that's great. In fact, I have suggested in the QEMU list that SEV guests should always use UEFI; because BIOS runs in real-mode or 32-bit non-paging protected mode, BIOS must always write encrypted data, which becomes painful in the kernel. And regarding the above "important" point, all I know is that Microsoft for sure will be happy to restrict SEV to UEFI guests. :) There are still some differences, mostly around the real mode trampoline executed by the kernel, but they should be much smaller. Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/2] staging: r8188eu: remove rf_type member of hal_data_8188e structure
rf_type is always equal to RF_1T1R.
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/hal/bb_cfg.c| 5 +
drivers/staging/rtl8188eu/hal/phy.c | 5 +
drivers/staging/rtl8188eu/hal/rf_cfg.c| 5 +
drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 7 +--
drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c | 3 ---
drivers/staging/rtl8188eu/hal/usb_halinit.c | 2 +-
drivers/staging/rtl8188eu/include/rtl8188e_hal.h | 1 -
7 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/bb_cfg.c
b/drivers/staging/rtl8188eu/hal/bb_cfg.c
index c349923..134fa6c 100644
--- a/drivers/staging/rtl8188eu/hal/bb_cfg.c
+++ b/drivers/staging/rtl8188eu/hal/bb_cfg.c
@@ -518,8 +518,7 @@ static void store_pwrindex_offset(struct adapter *adapter,
power_level_offset[4] = data;
if (regaddr == rTxAGC_A_Mcs15_Mcs12) {
power_level_offset[5] = data;
- if (hal_data->rf_type == RF_1T1R)
- hal_data->pwrGroupCnt++;
+ hal_data->pwrGroupCnt++;
}
if (regaddr == rTxAGC_B_Rate18_06)
power_level_offset[8] = data;
@@ -537,8 +536,6 @@ static void store_pwrindex_offset(struct adapter *adapter,
power_level_offset[12] = data;
if (regaddr == rTxAGC_B_Mcs15_Mcs12) {
power_level_offset[13] = data;
- if (hal_data->rf_type != RF_1T1R)
- hal_data->pwrGroupCnt++;
}
}
diff --git a/drivers/staging/rtl8188eu/hal/phy.c
b/drivers/staging/rtl8188eu/hal/phy.c
index 4e3c2e6..aaf8c26 100644
--- a/drivers/staging/rtl8188eu/hal/phy.c
+++ b/drivers/staging/rtl8188eu/hal/phy.c
@@ -149,10 +149,7 @@ static void get_tx_power_index(struct adapter *adapt, u8
channel, u8 *cck_pwr,
u8 index = (channel - 1);
u8 TxCount = 0, path_nums;
- if ((RF_1T2R == hal_data->rf_type) || (RF_1T1R == hal_data->rf_type))
- path_nums = 1;
- else
- path_nums = 2;
+ path_nums = 1;
for (TxCount = 0; TxCount < path_nums; TxCount++) {
if (TxCount == RF_PATH_A) {
diff --git a/drivers/staging/rtl8188eu/hal/rf_cfg.c
b/drivers/staging/rtl8188eu/hal/rf_cfg.c
index dc26ad3..dde6441 100644
--- a/drivers/staging/rtl8188eu/hal/rf_cfg.c
+++ b/drivers/staging/rtl8188eu/hal/rf_cfg.c
@@ -301,10 +301,7 @@ static bool rtl88e_phy_rf6052_config(struct adapter *adapt)
{
struct hal_data_8188e *hal_data = adapt->HalData;
- if (hal_data->rf_type == RF_1T1R)
- hal_data->NumTotalRFPath = 1;
- else
- hal_data->NumTotalRFPath = 2;
+ hal_data->NumTotalRFPath = 1;
return rf6052_conf_para(adapt);
}
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
index 964b169..62c75cc 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_dm.c
@@ -57,12 +57,7 @@ static void Init_ODM_ComInfo_88E(struct adapter *Adapter)
dm_odm->PatchID = hal_data->CustomerID;
dm_odm->bWIFITest = Adapter->registrypriv.wifi_spec;
- if (hal_data->rf_type == RF_1T1R)
- dm_odm->RFType = ODM_1T1R;
- else if (hal_data->rf_type == RF_2T2R)
- dm_odm->RFType = ODM_2T2R;
- else if (hal_data->rf_type == RF_1T2R)
- dm_odm->RFType = ODM_1T2R;
+ dm_odm->RFType = ODM_1T1R;
dm_odm->AntDivType = hal_data->TRxAntDivType;
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
index a7b0375..385bc2f 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_hal_init.c
@@ -135,10 +135,7 @@ void rtw_hal_read_chip_version(struct adapter *padapter)
dump_chip_info(ChipVersion);
pHalData->VersionID = ChipVersion;
- pHalData->rf_type = RF_1T1R;
pHalData->NumTotalRFPath = 1;
-
- MSG_88E("RF_Type is %x!!\n", pHalData->rf_type);
}
void rtw_hal_set_odm_var(struct adapter *Adapter, enum hal_odm_variable
eVariable, void *pValue1, bool bSet)
diff --git a/drivers/staging/rtl8188eu/hal/usb_halinit.c
b/drivers/staging/rtl8188eu/hal/usb_halinit.c
index 113bd0b..7692ca4 100644
--- a/drivers/staging/rtl8188eu/hal/usb_halinit.c
+++ b/drivers/staging/rtl8188eu/hal/usb_halinit.c
@@ -1763,7 +1763,7 @@ void rtw_hal_get_hwreg(struct adapter *Adapter, u8
variable, u8 *val)
val[0] = (BIT(0) & usb_read8(Adapter, REG_TDECTRL+2)) ? true :
false;
break;
case HW_VAR_RF_TYPE:
- val[0] = Adapter->HalData->rf_type;
+ val[0] = RF_1T1R;
break;
case HW_VAR_FWLPS_RF_ON:
{
diff --git a/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
b/drivers/staging/rtl8188eu/include/rtl8188e_hal.h
index 34268d9..7c81e
[PATCH 2/2] staging: r8188eu: remove RFType member of odm_dm_struct structure
rf_type is always equal to ODM_1T1R.
So, only RF PATH A exists for r8188eu device...
Signed-off-by: Ivan Safonov
---
drivers/staging/rtl8188eu/hal/odm.c | 35 -
drivers/staging/rtl8188eu/hal/phy.c | 16 +++--
drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 2 --
drivers/staging/rtl8188eu/include/odm.h | 2 --
4 files changed, 12 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/rtl8188eu/hal/odm.c
b/drivers/staging/rtl8188eu/hal/odm.c
index 0677474..d983a80 100644
--- a/drivers/staging/rtl8188eu/hal/odm.c
+++ b/drivers/staging/rtl8188eu/hal/odm.c
@@ -285,7 +285,6 @@ void odm_CmnInfoInit_Debug(struct odm_dm_struct *pDM_Odm)
ODM_RT_TRACE(pDM_Odm, ODM_COMP_COMMON, ODM_DBG_LOUD,
("SupportInterface=%d\n", pDM_Odm->SupportInterface));
ODM_RT_TRACE(pDM_Odm, ODM_COMP_COMMON, ODM_DBG_LOUD,
("SupportICType=0x%x\n", pDM_Odm->SupportICType));
ODM_RT_TRACE(pDM_Odm, ODM_COMP_COMMON, ODM_DBG_LOUD,
("CutVersion=%d\n", pDM_Odm->CutVersion));
- ODM_RT_TRACE(pDM_Odm, ODM_COMP_COMMON, ODM_DBG_LOUD, ("RFType=%d\n",
pDM_Odm->RFType));
ODM_RT_TRACE(pDM_Odm, ODM_COMP_COMMON, ODM_DBG_LOUD, ("BoardType=%d\n",
pDM_Odm->BoardType));
ODM_RT_TRACE(pDM_Odm, ODM_COMP_COMMON, ODM_DBG_LOUD, ("ExtLNA=%d\n",
pDM_Odm->ExtLNA));
ODM_RT_TRACE(pDM_Odm, ODM_COMP_COMMON, ODM_DBG_LOUD, ("ExtPA=%d\n",
pDM_Odm->ExtPA));
@@ -763,37 +762,21 @@ u32 ODM_Get_Rate_Bitmap(struct odm_dm_struct *pDM_Odm,
u32 macid, u32 ra_mask, u
break;
case (ODM_WM_B|ODM_WM_G|ODM_WM_N24G):
case (ODM_WM_A|ODM_WM_B|ODM_WM_G|ODM_WM_N24G):
- if (pDM_Odm->RFType == ODM_1T2R || pDM_Odm->RFType == ODM_1T1R)
{
- if (rssi_level == DM_RATR_STA_HIGH) {
- rate_bitmap = 0x000f;
- } else if (rssi_level == DM_RATR_STA_MIDDLE) {
- rate_bitmap = 0x000ff000;
- } else {
- if (*(pDM_Odm->pBandWidth) == ODM_BW40M)
- rate_bitmap = 0x000ff015;
- else
- rate_bitmap = 0x000ff005;
- }
+ if (rssi_level == DM_RATR_STA_HIGH) {
+ rate_bitmap = 0x000f;
+ } else if (rssi_level == DM_RATR_STA_MIDDLE) {
+ rate_bitmap = 0x000ff000;
} else {
- if (rssi_level == DM_RATR_STA_HIGH) {
- rate_bitmap = 0x0f8f;
- } else if (rssi_level == DM_RATR_STA_MIDDLE) {
- rate_bitmap = 0x0f8ff000;
- } else {
- if (*(pDM_Odm->pBandWidth) == ODM_BW40M)
- rate_bitmap = 0x0f8ff015;
- else
- rate_bitmap = 0x0f8ff005;
- }
+ if (*(pDM_Odm->pBandWidth) == ODM_BW40M)
+ rate_bitmap = 0x000ff015;
+ else
+ rate_bitmap = 0x000ff005;
}
break;
default:
/* case WIRELESS_11_24N: */
/* case WIRELESS_11_5N: */
- if (pDM_Odm->RFType == RF_1T2R)
- rate_bitmap = 0x000f;
- else
- rate_bitmap = 0x0fff;
+ rate_bitmap = 0x0fff;
break;
}
diff --git a/drivers/staging/rtl8188eu/hal/phy.c
b/drivers/staging/rtl8188eu/hal/phy.c
index aaf8c26..5192ef7 100644
--- a/drivers/staging/rtl8188eu/hal/phy.c
+++ b/drivers/staging/rtl8188eu/hal/phy.c
@@ -944,16 +944,11 @@ static bool simularity_compare(struct adapter *adapt, s32
resulta[][8],
u8 c1, u8 c2)
{
u32 i, j, diff, sim_bitmap = 0, bound;
- struct odm_dm_struct *dm_odm = &adapt->HalData->odmpriv;
u8 final_candidate[2] = {0xFF, 0xFF}; /* for path A and path B */
bool result = true;
s32 tmp1 = 0, tmp2 = 0;
- if ((dm_odm->RFType == ODM_2T2R) || (dm_odm->RFType == ODM_2T3R) ||
- (dm_odm->RFType == ODM_2T4R))
- bound = 8;
- else
- bound = 4;
+ bound = 4;
for (i = 0; i < bound; i++) {
if ((i == 1) || (i == 3) || (i == 5) || (i == 7)) {
@@ -1282,7 +1277,7 @@ void rtl88eu_phy_iq_calibrate(struct adapter *adapt, bool
recovery)
rOFDM0_RxIQExtAnta};
bool is2t;
- is2t = (dm_odm->RFType == ODM_2T2R) ? true : false;
+ is2t = false;
if (!(dm_odm->SupportAbility & ODM_RF_CALIBRATION))
return;
@@ -1408,12 +1403,7 @@ void rtl88eu_phy_lc_calibrate(struct adapter *adapt)
dm_odm
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On Thu, Sep 22, 2016 at 04:45:51PM +0200, Paolo Bonzini wrote: > The main difference between the SME and SEV encryption, from the point > of view of the kernel, is that real-mode always writes unencrypted in > SME and always writes encrypted in SEV. But UEFI can run in 64-bit mode > and learn about the C bit, so EFI boot data should be unprotected in SEV > guests. Actually, it is different: you can start fully encrypted in SME, see: https://lkml.kernel.org/r/2016083539.29880.96739.st...@tlendack-t1.amdoffice.net The last paragraph alludes to a certain transparent mode where you're already encrypted and only certain pieces like EFI is not encrypted. I think the aim is to have the transparent mode be the default one, which makes most sense anyway. The EFI regions are unencrypted for obvious reasons and you need to access them as such. > Because the firmware volume is written to high memory in encrypted > form, and because the PEI phase runs in 32-bit mode, the firmware > code will be encrypted; on the other hand, data that is placed in low > memory for the kernel can be unencrypted, thus limiting differences > between SME and SEV. When you run fully encrypted, you still need to access EFI tables in the clear. That's why I'm confused about this patch here. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 04/28] x86: Secure Encrypted Virtualization (SEV) support
On Mon, Aug 22, 2016 at 07:24:19PM -0400, Brijesh Singh wrote: > From: Tom Lendacky Subject: [RFC PATCH v1 04/28] x86: Secure Encrypted Virtualization (SEV) support Please start patch commit heading with a verb, i.e.: "x86: Add AMD Secure Encrypted Virtualization (SEV) support" -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 22/09/2016 16:59, Borislav Petkov wrote: > On Thu, Sep 22, 2016 at 04:45:51PM +0200, Paolo Bonzini wrote: >> The main difference between the SME and SEV encryption, from the point >> of view of the kernel, is that real-mode always writes unencrypted in >> SME and always writes encrypted in SEV. But UEFI can run in 64-bit mode >> and learn about the C bit, so EFI boot data should be unprotected in SEV >> guests. > > Actually, it is different: you can start fully encrypted in SME, see: > > https://lkml.kernel.org/r/2016083539.29880.96739.st...@tlendack-t1.amdoffice.net > > The last paragraph alludes to a certain transparent mode where you're > already encrypted and only certain pieces like EFI is not encrypted. Which paragraph? >> Because the firmware volume is written to high memory in encrypted >> form, and because the PEI phase runs in 32-bit mode, the firmware >> code will be encrypted; on the other hand, data that is placed in low >> memory for the kernel can be unencrypted, thus limiting differences >> between SME and SEV. > > When you run fully encrypted, you still need to access EFI tables in the > clear. That's why I'm confused about this patch here. I might be wrong, but I don't think this patch was tested with OVMF or Duet. Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/2] staging: ion: Fix checkpatch.pl coding style issues
On Thu, Sep 22, 2016 at 05:13:07PM +0300, Antti Keränen wrote: > This set of patches fix two coding style warnings found with checkpatch.pl > I hope I got this correctly this time around :) > > Antti Keränen (2): > staging: ion: Fix a coding style issue > staging: ion: Fix a coding style issue Any reason you didn't use scripts/get_maintainer.pl to determine who to send these patches to? Please do so and resend them. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 1/2] staging: ion: Fix a coding style issue
Remove unnecessary braces surrounding a single statement block
Signed-off-by: Antti Keränen
---
drivers/staging/android/ion/hisilicon/hi6220_ion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
index 659aa71..bd45151 100644
--- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
+++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
@@ -82,9 +82,9 @@ static int hi6220_ion_remove(struct platform_device *pdev)
ipdev = platform_get_drvdata(pdev);
- for (i = 0; i < ipdev->data->nr; i++) {
+ for (i = 0; i < ipdev->data->nr; i++)
ion_heap_destroy(ipdev->heaps[i]);
- }
+
ion_destroy_platform_data(ipdev->data);
ion_device_destroy(ipdev->idev);
--
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3 2/2] staging: ion: Fix a coding style issue
Correctly align an unaligned block comment
Signed-off-by: Antti Keränen
---
drivers/staging/android/uapi/ion.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/uapi/ion.h
b/drivers/staging/android/uapi/ion.h
index 647f130..e629394 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -57,7 +57,7 @@ enum ion_heap_type {
* cached, ion will do cache
* maintenance when the buffer is
* mapped for dma
- */
+*/
#define ION_FLAG_CACHED_NEEDS_SYNC 2 /*
* mappings of this buffer will created
* at mmap time, if this is set
--
2.9.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On Thu, Sep 22, 2016 at 05:05:54PM +0200, Paolo Bonzini wrote: > Which paragraph? "Linux relies on BIOS to set this bit if BIOS has determined that the reduction in the physical address space as a result of enabling memory encryption..." Basically, you can enable SME in the BIOS and you're all set. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 22/09/2016 19:07, Borislav Petkov wrote: >> Which paragraph? > "Linux relies on BIOS to set this bit if BIOS has determined that the > reduction in the physical address space as a result of enabling memory > encryption..." > > Basically, you can enable SME in the BIOS and you're all set. That's not how I read it. I just figured that the BIOS has some magic things high in the physical address space and if you reduce the physical address space the BIOS (which is called from e.g. EFI runtime services) would have problems with that. Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On Thu, Sep 22, 2016 at 07:08:50PM +0200, Paolo Bonzini wrote: > That's not how I read it. I just figured that the BIOS has some magic > things high in the physical address space and if you reduce the physical > address space the BIOS (which is called from e.g. EFI runtime services) > would have problems with that. Yeah, I had to ask about that myself and Tom will have it explained better in the next version. The reduction in physical address space happens when SME enabled because you need a couple of bits in the PTE with which to say which key has encrypted that page. So it is an indelible part of the SME machinery. Btw, section "7.10 Secure Memory Encryption" has an initial writeup: http://support.amd.com/TechDocs/24593.pdf Now that I skim over it, it doesn't mention the BIOS thing but that'll be updated. HTH. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] iio: accel: sca3000_core: avoid potentially uninitialized variable
On 22/09/16 10:43, Arnd Bergmann wrote:
> The newly added __sca3000_get_base_freq function handles all valid
> modes of the SCA3000_REG_ADDR_MODE register, but gcc notices
> that any other value (i.e. 0x00) causes the base_freq variable to
> not get initialized:
>
> drivers/staging/iio/accel/sca3000_core.c: In function 'sca3000_write_raw':
> drivers/staging/iio/accel/sca3000_core.c:527:23: error: 'base_freq' may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This adds explicit error handling for unexpected register values,
> to ensure this cannot happen.
>
> Fixes: e0f3fc9b47e6 ("iio: accel: sca3000_core: implemented
> IIO_CHAN_INFO_SAMP_FREQ")
> Signed-off-by: Arnd Bergmann
Applied to the togreg branch of iio.git. Initially pushed out as testing for the
autobuilders to play with it.
'Bug' has been there a long time. The patch just move the code so I'm not
going to rush this one in. Worth hardening this corner though!
Thanks,
Jonathan
> ---
> drivers/staging/iio/accel/sca3000_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/iio/accel/sca3000_core.c
> b/drivers/staging/iio/accel/sca3000_core.c
> index d626125d7af9..564b36d4f648 100644
> --- a/drivers/staging/iio/accel/sca3000_core.c
> +++ b/drivers/staging/iio/accel/sca3000_core.c
> @@ -468,6 +468,8 @@ static inline int __sca3000_get_base_freq(struct
> sca3000_state *st,
> case SCA3000_MEAS_MODE_OP_2:
> *base_freq = info->option_mode_2_freq;
> break;
> + default:
> + ret = -EINVAL;
> }
> error_ret:
> return ret;
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging:android:io: Fix multiple styling issues
This patch fixes 1 error, 1 warning and 14 checks found by
checkpatch.
Signed-off-by: Yannis Damigos
---
drivers/staging/android/ion/ion_of.c | 49 ++--
1 file changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/android/ion/ion_of.c
b/drivers/staging/android/ion/ion_of.c
index de0899a..c930416 100644
--- a/drivers/staging/android/ion/ion_of.c
+++ b/drivers/staging/android/ion/ion_of.c
@@ -26,17 +26,17 @@
#include "ion_of.h"
int ion_parse_dt_heap_common(struct device_node *heap_node,
- struct ion_platform_heap *heap,
- struct ion_of_heap *compatible)
+struct ion_platform_heap *heap,
+struct ion_of_heap *compatible)
{
int i;
- for (i = 0; compatible[i].name != NULL; i++) {
+ for (i = 0; compatible[i].name; i++) {
if (of_device_is_compatible(heap_node, compatible[i].compat))
break;
}
- if (compatible[i].name == NULL)
+ if (!compatible[i].name)
return -ENODEV;
heap->id = compatible[i].heap_id;
@@ -47,33 +47,33 @@ int ion_parse_dt_heap_common(struct device_node *heap_node,
/* Some kind of callback function pointer? */
pr_info("%s: id %d type %d name %s align %lx\n", __func__,
- heap->id, heap->type, heap->name, heap->align);
+ heap->id, heap->type, heap->name, heap->align);
return 0;
}
int ion_setup_heap_common(struct platform_device *parent,
- struct device_node *heap_node,
- struct ion_platform_heap *heap)
+ struct device_node *heap_node,
+ struct ion_platform_heap *heap)
{
int ret = 0;
switch (heap->type) {
- case ION_HEAP_TYPE_CARVEOUT:
- case ION_HEAP_TYPE_CHUNK:
- if (heap->base && heap->size)
- return 0;
-
- ret = of_reserved_mem_device_init(heap->priv);
- break;
- default:
- break;
+ case ION_HEAP_TYPE_CARVEOUT:
+ case ION_HEAP_TYPE_CHUNK:
+ if (heap->base && heap->size)
+ return 0;
+
+ ret = of_reserved_mem_device_init(heap->priv);
+ break;
+ default:
+ break;
}
return ret;
}
struct ion_platform_data *ion_parse_dt(struct platform_device *pdev,
- struct ion_of_heap *compatible)
+ struct ion_of_heap *compatible)
{
int num_heaps, ret;
const struct device_node *dt_node = pdev->dev.of_node;
@@ -88,13 +88,13 @@ struct ion_platform_data *ion_parse_dt(struct
platform_device *pdev,
return ERR_PTR(-EINVAL);
heaps = devm_kzalloc(&pdev->dev,
- sizeof(struct ion_platform_heap)*num_heaps,
- GFP_KERNEL);
+sizeof(struct ion_platform_heap) * num_heaps,
+GFP_KERNEL);
if (!heaps)
return ERR_PTR(-ENOMEM);
data = devm_kzalloc(&pdev->dev, sizeof(struct ion_platform_data),
- GFP_KERNEL);
+ GFP_KERNEL);
if (!data)
return ERR_PTR(-ENOMEM);
@@ -106,7 +106,7 @@ struct ion_platform_data *ion_parse_dt(struct
platform_device *pdev,
return ERR_PTR(ret);
heap_pdev = of_platform_device_create(node, heaps[i].name,
- &pdev->dev);
+ &pdev->dev);
if (!pdev)
return ERR_PTR(-ENOMEM);
heap_pdev->dev.platform_data = &heaps[i];
@@ -119,7 +119,6 @@ struct ion_platform_data *ion_parse_dt(struct
platform_device *pdev,
i++;
}
-
data->heaps = heaps;
data->nr = num_heaps;
return data;
@@ -155,14 +154,13 @@ static int rmem_ion_device_init(struct reserved_mem
*rmem, struct device *dev)
heap->base = rmem->base;
heap->base = rmem->size;
pr_debug("%s: heap %s base %pa size %pa dev %p\n", __func__,
- heap->name, &rmem->base, &rmem->size, dev);
+heap->name, &rmem->base, &rmem->size, dev);
return 0;
}
static void rmem_ion_device_release(struct reserved_mem *rmem,
- struct device *dev)
+ struct device *dev)
{
- return;
}
static const struct reserved_mem_ops rmem_dma_ops = {
@@ -181,5 +179,6 @@ static int __init rmem_ion_setup(struct reserved_mem *rmem)
rmem->ops = &rmem_dma_ops;
[PATCH] drivers: wlan-ng: fixed a coding style issue
changed comparison "wlandev == NULL" to "!wlandev" to obtain the coding style. Signed-off-by: Jannik Becher --- drivers/staging/wlan-ng/cfg80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wlan-ng/cfg80211.c b/drivers/staging/wlan-ng/cfg80211.c index f46dfe6..5ba41c5 100644 --- a/drivers/staging/wlan-ng/cfg80211.c +++ b/drivers/staging/wlan-ng/cfg80211.c @@ -305,7 +305,7 @@ static int prism2_get_station(struct wiphy *wiphy, struct net_device *dev, memset(sinfo, 0, sizeof(*sinfo)); - if ((wlandev == NULL) || (wlandev->msdstate != WLAN_MSD_RUNNING)) + if ((!wlandev) || (wlandev->msdstate != WLAN_MSD_RUNNING)) return -EOPNOTSUPP; /* build request message */ -- 2.9.3 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: ks7010: add blank line after variable declarations
Fixes warnings found by checkpatch
Missing a blank line after declarations
Signed-off-by: Johan Svensson
---
drivers/staging/ks7010/ks_hostif.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/ks7010/ks_hostif.c
b/drivers/staging/ks7010/ks_hostif.c
index aad8048..c57ca58 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -35,6 +35,7 @@ static
inline u8 get_BYTE(struct ks_wlan_private *priv)
{
u8 data;
+
data = *(priv->rxp)++;
/* length check in advance ! */
--(priv->rx_size);
@@ -45,6 +46,7 @@ static
inline u16 get_WORD(struct ks_wlan_private *priv)
{
u16 data;
+
data = (get_BYTE(priv) & 0xff);
data |= ((get_BYTE(priv) << 8) & 0xff00);
return data;
@@ -54,6 +56,7 @@ static
inline u32 get_DWORD(struct ks_wlan_private *priv)
{
u32 data;
+
data = (get_BYTE(priv) & 0xff);
data |= ((get_BYTE(priv) << 8) & 0xff00);
data |= ((get_BYTE(priv) << 16) & 0x00ff);
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: sm750fb: rename getChipType to get_chip_type
Rename CamelCased function getChipType to get_chip_type.
This issue was found by checkpatch.pl
Signed-off-by: Moshe Green
---
drivers/staging/sm750fb/ddk750_chip.c | 16
drivers/staging/sm750fb/ddk750_chip.h | 2 +-
drivers/staging/sm750fb/ddk750_mode.c | 4 ++--
drivers/staging/sm750fb/ddk750_power.c | 6 +++---
drivers/staging/sm750fb/ddk750_swi2c.c | 2 +-
drivers/staging/sm750fb/sm750_hw.c | 8
6 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c
b/drivers/staging/sm750fb/ddk750_chip.c
index a887f32..66127c9 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -10,7 +10,7 @@
#define roundedDiv(num, denom) ((2 * (num) + (denom)) / (2 * (denom)))
#define MHz(x) ((x) * 100)
-logical_chip_type_t getChipType(void)
+logical_chip_type_t get_chip_type(void)
{
unsigned short physicalID;
char physicalRev;
@@ -37,7 +37,7 @@ static unsigned int get_mxclk_freq(void)
unsigned int pll_reg;
unsigned int M, N, OD, POD;
- if (getChipType() == SM750LE)
+ if (get_chip_type() == SM750LE)
return MHz(130);
pll_reg = PEEK32(MXCLK_PLL_CTRL);
@@ -60,7 +60,7 @@ static void setChipClock(unsigned int frequency)
unsigned int ulActualMxClk;
/* Cheok_0509: For SM750LE, the chip clock is fixed. Nothing to set. */
- if (getChipType() == SM750LE)
+ if (get_chip_type() == SM750LE)
return;
if (frequency) {
@@ -90,7 +90,7 @@ static void setMemoryClock(unsigned int frequency)
/* Cheok_0509: For SM750LE, the memory clock is fixed.
* Nothing to set.
*/
- if (getChipType() == SM750LE)
+ if (get_chip_type() == SM750LE)
return;
if (frequency) {
@@ -141,7 +141,7 @@ static void setMasterClock(unsigned int frequency)
/* Cheok_0509: For SM750LE, the memory clock is fixed.
* Nothing to set.
*/
- if (getChipType() == SM750LE)
+ if (get_chip_type() == SM750LE)
return;
if (frequency) {
@@ -182,7 +182,7 @@ unsigned int ddk750_getVMSize(void)
unsigned int data;
/* sm750le only use 64 mb memory*/
- if (getChipType() == SM750LE)
+ if (get_chip_type() == SM750LE)
return SZ_64M;
/* for 750,always use power mode0*/
@@ -221,7 +221,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
reg |= (CURRENT_GATE_DISPLAY | CURRENT_GATE_LOCALMEM);
setCurrentGate(reg);
- if (getChipType() != SM750LE) {
+ if (get_chip_type() != SM750LE) {
/* set panel pll and graphic mode via mmio_88 */
reg = PEEK32(VGA_CONFIGURATION);
reg |= (VGA_CONFIGURATION_PLL | VGA_CONFIGURATION_MODE);
@@ -320,7 +320,7 @@ unsigned int calcPllValue(unsigned int request_orig,
pll_value_t *pll)
const int max_OD = 3;
int max_d = 6;
- if (getChipType() == SM750LE) {
+ if (get_chip_type() == SM750LE) {
/* SM750LE don't have
* programmable PLL and M/N values to work on.
* Just return the requested clock.
diff --git a/drivers/staging/sm750fb/ddk750_chip.h
b/drivers/staging/sm750fb/ddk750_chip.h
index 0891384..3429be6 100644
--- a/drivers/staging/sm750fb/ddk750_chip.h
+++ b/drivers/staging/sm750fb/ddk750_chip.h
@@ -69,7 +69,7 @@ typedef struct _initchip_param_t {
}
initchip_param_t;
-logical_chip_type_t getChipType(void);
+logical_chip_type_t get_chip_type(void);
unsigned int calcPllValue(unsigned int request, pll_value_t *pll);
unsigned int formatPllReg(pll_value_t *pPLL);
void ddk750_set_mmio(void __iomem *, unsigned short, char);
diff --git a/drivers/staging/sm750fb/ddk750_mode.c
b/drivers/staging/sm750fb/ddk750_mode.c
index e29d4bd..9e629a5 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -117,7 +117,7 @@ static int programModeRegisters(mode_parameter_t
*pModeParam, pll_value_t *pll)
if (pModeParam->horizontal_sync_polarity)
tmp |= DISPLAY_CTRL_HSYNC_PHASE;
- if (getChipType() == SM750LE) {
+ if (get_chip_type() == SM750LE) {
displayControlAdjust_SM750LE(pModeParam, tmp);
} else {
reg = PEEK32(CRT_DISPLAY_CTRL) &
@@ -209,7 +209,7 @@ int ddk750_setModeTiming(mode_parameter_t *parm,
clock_type_t clock)
pll.clockType = clock;
uiActualPixelClk = calcPllValue(parm->pixel_clock, &pll);
- if (getChipType() == SM750LE) {
+ if (get_chip_type() == SM750LE) {
/* set graphic mode via IO method */
outb_p(0x88, 0x3d4);
outb_p(0x06, 0x3d5);
diff --git a/drivers/staging/sm750fb/ddk750_power.c
b/drivers/staging/sm750fb/ddk750_power.c
index b3c37
[PATCH 3/8] staging: rts5208: fix style warnings in rtsx_chip.h
This patch fixes the following checkpatch.pl warning in rtsx_chip.h:
WARNING: Block comments use a trailing */ on a separate line
Signed-off-by: Sergio Paracuellos
---
drivers/staging/rts5208/rtsx_chip.h | 52 +++--
1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_chip.h
b/drivers/staging/rts5208/rtsx_chip.h
index 6ef34fa..f366428 100644
--- a/drivers/staging/rts5208/rtsx_chip.h
+++ b/drivers/staging/rts5208/rtsx_chip.h
@@ -44,8 +44,10 @@
#define MG_SET_ICV_SLOW
/* HW may miss ERR/CMDNK signal when sampling INT status. */
#define MS_SAMPLE_INT_ERR
- /* HW DO NOT support Wait_INT function during READ_BYTES
-* transfer mode */
+ /*
+* HW DO NOT support Wait_INT function
+* during READ_BYTES transfer mode
+*/
#define READ_BYTES_WAIT_INT
#endif
@@ -101,17 +103,17 @@
#define TRANSPORT_NO_SENSE 2 /* Command failed, no auto-sense*/
#define TRANSPORT_ERROR3 /* Transport bad (i.e. device dead)
*/
-/*---
-Start-Stop-Unit
*/
+/*
+ * Start-Stop-Unit
+ */
#define STOP_MEDIUM0x00/* access disable */
#define MAKE_MEDIUM_READY 0x01/* access enable */
#define UNLOAD_MEDIUM 0x02/* unload */
#define LOAD_MEDIUM0x03/* load */
-/*---
-STANDARD_INQUIRY
*/
+/*
+ * STANDARD_INQUIRY
+ */
#define QULIFIRE0x00
#define AENC_FNC0x00
#define TRML_IOP0x00
@@ -128,17 +130,15 @@
#define PRDCT_REV_LEN 4 /* Product LOT Length */
/* Dynamic flag definitions: used in set_bit() etc. */
-#define RTSX_FLIDX_TRANS_ACTIVE18 /* 0x0004 transfer is
active */
-#define RTSX_FLIDX_ABORTING20 /* 0x0010 abort is in
-* progress */
-#define RTSX_FLIDX_DISCONNECTING 21 /* 0x0020 disconnect
-* in progress */
+#define RTSX_FLIDX_TRANS_ACTIVE18 /* 0x0004 transfer is
active */
+#define RTSX_FLIDX_ABORTING20 /* 0x0010 abort is in progress
*/
+#define RTSX_FLIDX_DISCONNECTING 21 /* 0x0020 disconnect in
progress */
+
#define ABORTING_OR_DISCONNECTING ((1UL << US_FLIDX_ABORTING) | \
(1UL << US_FLIDX_DISCONNECTING))
-#define RTSX_FLIDX_RESETTING 22 /* 0x0040 device reset
-* in progress */
-#define RTSX_FLIDX_TIMED_OUT 23 /* 0x0080 SCSI
-* midlayer timed out */
+
+#define RTSX_FLIDX_RESETTING 22 /* 0x0040 device reset in
progress */
+#define RTSX_FLIDX_TIMED_OUT 23 /* 0x0080 SCSI midlayer timed
out */
#define DRCT_ACCESS_DEV 0x00/* Direct Access Device */
#define RMB_DISC0x80/* The Device is Removable */
@@ -173,9 +173,9 @@
#defineFIRST_RESET 0x01
#defineUSED_EXIST 0x02
-/*---
-SENSE_DATA
*/
+/*
+ * SENSE_DATA
+ */
/* valid */
#define SENSE_VALID 0x80/* Sense data is valid as SCSI2 */
#define SENSE_INVALID 0x00/* Sense data is invalid as SCSI2 */
@@ -706,9 +706,9 @@ struct rtsx_chip {
int cur_card;
unsigned long need_release; /* need release bit map */
- unsigned long need_reset; /* need reset
-* bit map */
- /* Flag to indicate that this card is just resumed from SS state,
+ unsigned long need_reset; /* need reset bit map */
+ /*
+* Flag to indicate that this card is just resumed from SS state,
* and need released before being resetted
*/
unsigned long need_reinit;
@@ -726,8 +726,10 @@ struct rtsx_chip {
u8 card_ejected; /* card ejected bit map */
u8 card_wp;/* card write protected bit map */
- u8 lun_mc; /* flag to indicate whether to answer
-* MediaChange */
+ u8 lun_mc; /*
+* flag to indicate whether to answer
+* MediaChange
+*/
#ifndef LED_AUTO_BLINK
int led_toggle_counter;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linu
[PATCH 2/8] staging: rts5208: fix style warnings in rtsx.c
This patch fixes the following checkpatch.pl warning in rtsx.c:
WARNING: Symbolic permissions are not preferred.
Signed-off-by: Sergio Paracuellos
---
drivers/staging/rts5208/rtsx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx.c b/drivers/staging/rts5208/rtsx.c
index d7554f4..5d65a5c 100644
--- a/drivers/staging/rts5208/rtsx.c
+++ b/drivers/staging/rts5208/rtsx.c
@@ -34,27 +34,27 @@
MODULE_LICENSE("GPL");
static unsigned int delay_use = 1;
-module_param(delay_use, uint, S_IRUGO | S_IWUSR);
+module_param(delay_use, uint, 0644);
MODULE_PARM_DESC(delay_use, "seconds to delay before using a new device");
static int ss_en;
-module_param(ss_en, int, S_IRUGO | S_IWUSR);
+module_param(ss_en, int, 0644);
MODULE_PARM_DESC(ss_en, "enable selective suspend");
static int ss_interval = 50;
-module_param(ss_interval, int, S_IRUGO | S_IWUSR);
+module_param(ss_interval, int, 0644);
MODULE_PARM_DESC(ss_interval, "Interval to enter ss state in seconds");
static int auto_delink_en;
-module_param(auto_delink_en, int, S_IRUGO | S_IWUSR);
+module_param(auto_delink_en, int, 0644);
MODULE_PARM_DESC(auto_delink_en, "enable auto delink");
static unsigned char aspm_l0s_l1_en;
-module_param(aspm_l0s_l1_en, byte, S_IRUGO | S_IWUSR);
+module_param(aspm_l0s_l1_en, byte, 0644);
MODULE_PARM_DESC(aspm_l0s_l1_en, "enable device aspm");
static int msi_en;
-module_param(msi_en, int, S_IRUGO | S_IWUSR);
+module_param(msi_en, int, 0644);
MODULE_PARM_DESC(msi_en, "enable msi");
static irqreturn_t rtsx_interrupt(int irq, void *dev_id);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/8] staging: rts5208: fix style warnings in rtsx.h
This patch fixes the following checkpatch.pl warning in rtsx.h: WARNING: Block comments use a trailing */ on a separate line Signed-off-by: Sergio Paracuellos --- drivers/staging/rts5208/rtsx.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/rts5208/rtsx.h b/drivers/staging/rts5208/rtsx.h index 2de4719..e725b10 100644 --- a/drivers/staging/rts5208/rtsx.h +++ b/drivers/staging/rts5208/rtsx.h @@ -161,8 +161,10 @@ static inline void get_current_time(u8 *timeval_buf, int buf_len) timeval_buf[7] = (u8)(tv_usec); } -/* The scsi_lock() and scsi_unlock() macros protect the sm_state and the - * single queue element srb for write access */ +/* + * The scsi_lock() and scsi_unlock() macros protect the sm_state and the + * single queue element srb for write access + */ #define scsi_unlock(host) spin_unlock_irq(host->host_lock) #define scsi_lock(host)spin_lock_irq(host->host_lock) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/8] staging: rts5208: Fix several style warnings
This patchset fix several style warnings reported by checkpatch.pl script. Sergio Paracuellos (8): staging: rts5208: fix style warnings in rtsx.h staging: rts5208: fix style warnings in rtsx.c staging: rts5208: fix style warnings in rtsx_chip.h staging: rts5208: fix style warnings in rtsx.h staging: rts5208: fix style warnings in rtsx_sys.h staging: rts5208: fix style warnings in spi.c staging: rts5208: fix style warnings in sd.c staging: rts5208: fix style warnings in xd.c drivers/staging/rts5208/rtsx.c | 12 +-- drivers/staging/rts5208/rtsx.h | 10 +-- drivers/staging/rts5208/rtsx_chip.h | 54 +-- drivers/staging/rts5208/rtsx_sys.h | 2 - drivers/staging/rts5208/sd.c| 173 +--- drivers/staging/rts5208/spi.c | 3 +- drivers/staging/rts5208/xd.c| 38 +++- 7 files changed, 115 insertions(+), 177 deletions(-) -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/8] staging: rts5208: fix style warnings in rtsx_sys.h
This patch fixes the following checkpatch.pl warning in rtsx_sys.h:
WARNING: do not add new typedefs
Signed-off-by: Sergio Paracuellos
---
drivers/staging/rts5208/rtsx_sys.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx_sys.h
b/drivers/staging/rts5208/rtsx_sys.h
index 0b6b4d4..f49bed9 100644
--- a/drivers/staging/rts5208/rtsx_sys.h
+++ b/drivers/staging/rts5208/rtsx_sys.h
@@ -28,8 +28,6 @@
#include "rtsx_chip.h"
#include "rtsx_card.h"
-typedef dma_addr_t ULONG_PTR;
-
static inline void rtsx_exclusive_enter_ss(struct rtsx_chip *chip)
{
struct rtsx_dev *dev = chip->rtsx;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 8/8] staging: rts5208: fix style warnings in xd.c
This patch fixes the following checkpatch.pl warning in xd.c:
WARNING: else is not generally useful after a break or return
It also makes code more uniform with the new changes
Signed-off-by: Sergio Paracuellos
---
drivers/staging/rts5208/xd.c | 38 ++
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/staging/rts5208/xd.c b/drivers/staging/rts5208/xd.c
index ff423fa..1de02bb 100644
--- a/drivers/staging/rts5208/xd.c
+++ b/drivers/staging/rts5208/xd.c
@@ -1622,10 +1622,8 @@ static int xd_read_multiple_pages(struct rtsx_chip
*chip, u32 phy_blk,
u8 reg_val, page_cnt;
int zone_no, retval, i;
- if (start_page > end_page) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ if (start_page > end_page)
+ goto Status_Fail;
page_cnt = end_page - start_page;
zone_no = (int)(log_blk / 1000);
@@ -1641,8 +1639,7 @@ static int xd_read_multiple_pages(struct rtsx_chip *chip,
u32 phy_blk,
if (detect_card_cd(chip, XD_CARD) != STATUS_SUCCESS) {
xd_set_err_code(chip, XD_NO_CARD);
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
}
}
}
@@ -1677,8 +1674,7 @@ static int xd_read_multiple_pages(struct rtsx_chip *chip,
u32 phy_blk,
if (retval == -ETIMEDOUT) {
xd_set_err_code(chip, XD_TO_ERROR);
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
} else {
rtsx_trace(chip);
goto Fail;
@@ -1711,8 +1707,7 @@ static int xd_read_multiple_pages(struct rtsx_chip *chip,
u32 phy_blk,
if (detect_card_cd(chip, XD_CARD) != STATUS_SUCCESS) {
xd_set_err_code(chip, XD_NO_CARD);
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
}
xd_set_err_code(chip, XD_ECC_ERROR);
@@ -1720,8 +1715,7 @@ static int xd_read_multiple_pages(struct rtsx_chip *chip,
u32 phy_blk,
new_blk = xd_get_unused_block(chip, zone_no);
if (new_blk == NO_NEW_BLK) {
XD_CLR_BAD_OLDBLK(xd_card);
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
}
retval = xd_copy_page(chip, phy_blk, new_blk, 0,
@@ -1735,8 +1729,7 @@ static int xd_read_multiple_pages(struct rtsx_chip *chip,
u32 phy_blk,
XD_CLR_BAD_NEWBLK(xd_card);
}
XD_CLR_BAD_OLDBLK(xd_card);
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
}
xd_set_l2p_tbl(chip, zone_no, log_off, (u16)(new_blk & 0x3FF));
xd_erase_block(chip, phy_blk);
@@ -1744,6 +1737,7 @@ static int xd_read_multiple_pages(struct rtsx_chip *chip,
u32 phy_blk,
XD_CLR_BAD_OLDBLK(xd_card);
}
+Status_Fail:
rtsx_trace(chip);
return STATUS_FAIL;
}
@@ -1842,10 +1836,8 @@ static int xd_write_multiple_pages(struct rtsx_chip
*chip, u32 old_blk,
dev_dbg(rtsx_dev(chip), "%s, old_blk = 0x%x, new_blk = 0x%x, log_blk =
0x%x\n",
__func__, old_blk, new_blk, log_blk);
- if (start_page > end_page) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ if (start_page > end_page)
+ goto Status_Fail;
page_cnt = end_page - start_page;
zone_no = (int)(log_blk / 1000);
@@ -1854,10 +1846,8 @@ static int xd_write_multiple_pages(struct rtsx_chip
*chip, u32 old_blk,
page_addr = (new_blk << xd_card->block_shift) + start_page;
retval = xd_send_cmd(chip, READ1_1);
- if (retval != STATUS_SUCCESS) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ if (retval != STATUS_SUCCESS)
+ goto Status_Fail;
rtsx_init_cmd(chip);
@@ -1892,8 +1882,7 @@ static int xd_write_multiple_pages(struct rtsx_chip
*chip, u32 old_blk,
if (retval == -ETIMEDOUT) {
xd_set_err_code(chip, XD_TO_ERROR);
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
} else {
rtsx_trace(chip);
goto Fail;
@@ -1933,6 +1922,7 @@ static int xd_write_multiple_pages(struct rtsx_chip
*chip, u32 old_blk,
xd_mark_bad_block(chip, new_blk);
}
+Status_Fail:
[PATCH 7/8] staging: rts5208: fix style warnings in sd.c
This patch fixes the following checkpatch.pl warning in sd.c:
WARNING: else is not generally useful after a break or return
It also makes code more uniform with the new changes
Signed-off-by: Sergio Paracuellos
---
drivers/staging/rts5208/sd.c | 173 +++
1 file changed, 61 insertions(+), 112 deletions(-)
diff --git a/drivers/staging/rts5208/sd.c b/drivers/staging/rts5208/sd.c
index e72c432..b0bbb36 100644
--- a/drivers/staging/rts5208/sd.c
+++ b/drivers/staging/rts5208/sd.c
@@ -2588,16 +2588,12 @@ static int reset_sd(struct rtsx_chip *chip)
#endif
retval = sd_prepare_reset(chip);
- if (retval != STATUS_SUCCESS) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ if (retval != STATUS_SUCCESS)
+ goto Status_Fail;
retval = sd_dummy_clock(chip);
- if (retval != STATUS_SUCCESS) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ if (retval != STATUS_SUCCESS)
+ goto Status_Fail;
if (CHK_SDIO_EXIST(chip) && !CHK_SDIO_IGNORED(chip) && try_sdio) {
int rty_cnt = 0;
@@ -2605,8 +2601,7 @@ static int reset_sd(struct rtsx_chip *chip)
for (; rty_cnt < chip->sdio_retry_cnt; rty_cnt++) {
if (detect_card_cd(chip, SD_CARD) != STATUS_SUCCESS) {
sd_set_err_code(chip, SD_NO_CARD);
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
}
retval = sd_send_cmd_get_rsp(chip, IO_SEND_OP_COND, 0,
@@ -2618,8 +2613,7 @@ static int reset_sd(struct rtsx_chip *chip)
dev_dbg(rtsx_dev(chip), "SD_IO card
(Function number: %d)!\n",
func_num);
chip->sd_io = 1;
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
}
break;
@@ -2637,10 +2631,8 @@ static int reset_sd(struct rtsx_chip *chip)
RTY_SD_RST:
retval = sd_send_cmd_get_rsp(chip, GO_IDLE_STATE, 0, SD_RSP_TYPE_R0,
NULL, 0);
- if (retval != STATUS_SUCCESS) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ if (retval != STATUS_SUCCESS)
+ goto Status_Fail;
wait_timeout(20);
@@ -2658,10 +2650,8 @@ static int reset_sd(struct rtsx_chip *chip)
retval = sd_send_cmd_get_rsp(chip, GO_IDLE_STATE, 0,
SD_RSP_TYPE_R0, NULL, 0);
- if (retval != STATUS_SUCCESS) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ if (retval != STATUS_SUCCESS)
+ goto Status_Fail;
wait_timeout(20);
}
@@ -2672,39 +2662,32 @@ static int reset_sd(struct rtsx_chip *chip)
if (retval != STATUS_SUCCESS) {
if (detect_card_cd(chip, SD_CARD) != STATUS_SUCCESS) {
sd_set_err_code(chip, SD_NO_CARD);
- rtsx_trace(chip);
- return STATUS_FAIL;
+ goto Status_Fail;
}
j++;
- if (j < 3) {
+ if (j < 3)
goto RTY_SD_RST;
- } else {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ else
+ goto Status_Fail;
}
retval = sd_send_cmd_get_rsp(chip, SD_APP_OP_COND, voltage,
SD_RSP_TYPE_R3, rsp, 5);
if (retval != STATUS_SUCCESS) {
k++;
- if (k < 3) {
+ if (k < 3)
goto RTY_SD_RST;
- } else {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ else
+ goto Status_Fail;
}
i++;
wait_timeout(20);
} while (!(rsp[1] & 0x80) && (i < 255));
- if (i == 255) {
- rtsx_trace(chip);
- return STATUS_FAIL;
- }
+ if (i == 255)
+ goto Status_Fail;
if (hi_cap_flow) {
if (rsp[1] & 0x40)
@@ -2721,26 +2704,20 @@ static int reset_sd(struct rt
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 09/22/2016 09:35 AM, Borislav Petkov wrote:
> On Mon, Aug 22, 2016 at 07:25:25PM -0400, Brijesh Singh wrote:
>> From: Tom Lendacky
>>
>> EFI data is encrypted when the kernel is run under SEV. Update the
>> page table references to be sure the EFI memory areas are accessed
>> encrypted.
>>
>> Signed-off-by: Tom Lendacky
>> ---
>> arch/x86/platform/efi/efi_64.c | 14 --
>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
>> index 0871ea4..98363f3 100644
>> --- a/arch/x86/platform/efi/efi_64.c
>> +++ b/arch/x86/platform/efi/efi_64.c
>> @@ -213,7 +213,7 @@ void efi_sync_low_kernel_mappings(void)
>>
>> int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned
>> num_pages)
>> {
>> -unsigned long pfn, text;
>> +unsigned long pfn, text, flags;
>> efi_memory_desc_t *md;
>> struct page *page;
>> unsigned npages;
>> @@ -230,6 +230,10 @@ int __init efi_setup_page_tables(unsigned long
>> pa_memmap, unsigned num_pages)
>> efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
>> pgd = efi_pgd;
>>
>> +flags = _PAGE_NX | _PAGE_RW;
>> +if (sev_active)
>> +flags |= _PAGE_ENC;
>
> So this is confusing me. There's this patch which says EFI data is
> accessed in the clear:
>
> https://lkml.kernel.org/r/2016083738.29880.6909.st...@tlendack-t1.amdoffice.net
>
> but now here it is encrypted when SEV is enabled.
>
> Do you mean, it is encrypted here because we're in the guest kernel?
Yes, the idea is that the SEV guest will be running encrypted from the
start, including the BIOS/UEFI, and so all of the EFI related data will
be encrypted.
Thanks,
Tom
>
> Thanks.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/8] staging: rts5208: fix style warnings in spi.c
This patch fixes the following checkpatch.pl warning in spi.c:
WARNING: line over 80 characters
Signed-off-by: Sergio Paracuellos
---
drivers/staging/rts5208/spi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/rts5208/spi.c b/drivers/staging/rts5208/spi.c
index 26eb2a1..13c539c 100644
--- a/drivers/staging/rts5208/spi.c
+++ b/drivers/staging/rts5208/spi.c
@@ -39,7 +39,8 @@ static int spi_init(struct rtsx_chip *chip)
int retval;
retval = rtsx_write_register(chip, SPI_CONTROL, 0xFF,
-CS_POLARITY_LOW | DTO_MSB_FIRST |
SPI_MASTER | SPI_MODE0 | SPI_AUTO);
+CS_POLARITY_LOW | DTO_MSB_FIRST
+| SPI_MASTER | SPI_MODE0 | SPI_AUTO);
if (retval) {
rtsx_trace(chip);
return retval;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/8] staging: rts5208: fix style warnings in rtsx.h
This patch fixes the following checkpatch.pl warning in rtsx.h:
WARNING: do not add new typedefs
Signed-off-by: Sergio Paracuellos
---
drivers/staging/rts5208/rtsx.h | 4
drivers/staging/rts5208/rtsx_chip.h | 2 +-
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/staging/rts5208/rtsx.h b/drivers/staging/rts5208/rtsx.h
index 7a21e46..2de4719 100644
--- a/drivers/staging/rts5208/rtsx.h
+++ b/drivers/staging/rts5208/rtsx.h
@@ -88,8 +88,6 @@
#define SCSI_LUN(srb) ((srb)->device->lun)
-typedef unsigned long DELAY_PARA_T;
-
struct rtsx_chip;
struct rtsx_dev {
@@ -130,8 +128,6 @@ struct rtsx_dev {
struct rtsx_chip*chip;
};
-typedef struct rtsx_dev rtsx_dev_t;
-
/* Convert between rtsx_dev and the corresponding Scsi_Host */
static inline struct Scsi_Host *rtsx_to_host(struct rtsx_dev *dev)
{
diff --git a/drivers/staging/rts5208/rtsx_chip.h
b/drivers/staging/rts5208/rtsx_chip.h
index 132c2e6..6ef34fa 100644
--- a/drivers/staging/rts5208/rtsx_chip.h
+++ b/drivers/staging/rts5208/rtsx_chip.h
@@ -683,7 +683,7 @@ struct trace_msg_t {
#define CLR_SDIO_IGNORED(chip) ((chip)->sdio_func_exist &=
~SDIO_IGNORED)
struct rtsx_chip {
- rtsx_dev_t *rtsx;
+ struct rtsx_dev *rtsx;
u32 int_reg; /* Bus interrupt pending register */
charmax_lun;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging:android:io: Fix multiple styling issues
Hello Yannis!
There is a typo in your one-line description/subject ("ion").
On 09/22/2016 07:55 PM, Yannis Damigos wrote:
> This patch fixes 1 error, 1 warning and 14 checks found by
> checkpatch.
Please be more specific in your commit message and mention what exactly
you are doing to the code and why.
>
> Signed-off-by: Yannis Damigos
> ---
> drivers/staging/android/ion/ion_of.c | 49
> ++--
> 1 file changed, 24 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion_of.c
> b/drivers/staging/android/ion/ion_of.c
> index de0899a..c930416 100644
> --- a/drivers/staging/android/ion/ion_of.c
> +++ b/drivers/staging/android/ion/ion_of.c
> @@ -26,17 +26,17 @@
> #include "ion_of.h"
>
> int ion_parse_dt_heap_common(struct device_node *heap_node,
> - struct ion_platform_heap *heap,
> - struct ion_of_heap *compatible)
> + struct ion_platform_heap *heap,
> + struct ion_of_heap *compatible)
You are changing whitespace here, ...
> {
> int i;
>
> - for (i = 0; compatible[i].name != NULL; i++) {
> + for (i = 0; compatible[i].name; i++) {
... and are making a different kind of change here.
> (Rest of patch with yet other types of changes snipped.)
It would be nice to have each kind of change in a separate patch with a
more precise commit message.
Thanks,
Markus
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 22/09/2016 19:46, Tom Lendacky wrote: >> > Do you mean, it is encrypted here because we're in the guest kernel? > Yes, the idea is that the SEV guest will be running encrypted from the > start, including the BIOS/UEFI, and so all of the EFI related data will > be encrypted. Unless this is part of some spec, it's easier if things are the same in SME and SEV. Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On Thu, Sep 22, 2016 at 08:23:36PM +0200, Paolo Bonzini wrote: > Unless this is part of some spec, it's easier if things are the same in > SME and SEV. Yeah, I was pondering over how sprinkling sev_active checks might not be so clean. I'm wondering if we could make the EFI regions presented to the guest unencrypted too, as part of some SEV-specific init routine so that the guest kernel doesn't need to do anything different. -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 22/09/2016 20:37, Borislav Petkov wrote: >> > Unless this is part of some spec, it's easier if things are the same in >> > SME and SEV. > Yeah, I was pondering over how sprinkling sev_active checks might not be > so clean. > > I'm wondering if we could make the EFI regions presented to the guest > unencrypted too, as part of some SEV-specific init routine so that the > guest kernel doesn't need to do anything different. That too, but why not fix it in the firmware?... (Again, if there's any MSFT guy looking at this offlist, let's involve him in the discussion). Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 22/09/2016 20:47, Tom Lendacky wrote: > > Because the firmware volume is written to high memory in encrypted form, > > and because the PEI phase runs in 32-bit mode, the firmware code will be > > encrypted; on the other hand, data that is placed in low memory for the > > kernel can be unencrypted, thus limiting differences between SME and SEV. > > I like the idea of limiting the differences but it would leave the EFI > data and ACPI tables exposed and able to be manipulated. Hmm, that makes sense. So I guess this has to stay, and Borislav's proposal doesn't fly either. Paolo ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 09/22/2016 12:07 PM, Borislav Petkov wrote: > On Thu, Sep 22, 2016 at 05:05:54PM +0200, Paolo Bonzini wrote: >> Which paragraph? > > "Linux relies on BIOS to set this bit if BIOS has determined that the > reduction in the physical address space as a result of enabling memory > encryption..." > > Basically, you can enable SME in the BIOS and you're all set. That's not what I mean here. If the BIOS sets the SMEE bit in the SYS_CFG msr then, even if the encryption bit is never used, there is still a reduction in physical address space. Transparent SME (TSME) will be a BIOS option that will result in the memory controller performing encryption no matter what. In this case all data will be encrypted without a reduction in physical address space. Thanks, Tom > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] rtl871x: use tabs with indentation instead of spaces
On 09/22/2016 09:17 AM, Greg KH wrote: > On Wed, Sep 21, 2016 at 11:12:05PM +0200, Christopher Pezley wrote: >> There is a line with space indentation instead of tabs. I've changed it to >> use tabs for indentation. >> >> Signed-off-by: Christopher H. Pezley >> --- >> drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > This patch does not apply to my tree at all, are you sure you made it > against linux-next? > > thanks, > > greg k-h > It looks like I was using master instead of linux-next. Sorry for the extra noise! ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers: wlan-ng: fixed a coding style issue
removed a space after a cast to obtain the coding style.
Signed-off-by: Jannik Becher
---
drivers/staging/wlan-ng/p80211req.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/p80211req.c
b/drivers/staging/wlan-ng/p80211req.c
index 40627d5..ecd2fff 100644
--- a/drivers/staging/wlan-ng/p80211req.c
+++ b/drivers/staging/wlan-ng/p80211req.c
@@ -110,7 +110,7 @@ static void p80211req_handle_action(struct wlandevice
*wlandev, u32 *data,
*/
int p80211req_dorequest(struct wlandevice *wlandev, u8 *msgbuf)
{
- struct p80211msg *msg = (struct p80211msg *) msgbuf;
+ struct p80211msg *msg = (struct p80211msg *)msgbuf;
/* Check to make sure the MSD is running */
if (!((wlandev->msdstate == WLAN_MSD_HWPRESENT &&
--
2.10.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote: > That's not what I mean here. If the BIOS sets the SMEE bit in the > SYS_CFG msr then, even if the encryption bit is never used, there is > still a reduction in physical address space. I thought that reduction is the reservation of bits for the SME mask. What other reduction is there? > Transparent SME (TSME) will be a BIOS option that will result in the > memory controller performing encryption no matter what. In this case > all data will be encrypted without a reduction in physical address > space. Now I'm confused: aren't we reducing the address space with the SME mask? Or what reduction do you mean? -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 09/22/2016 09:59 AM, Borislav Petkov wrote: > On Thu, Sep 22, 2016 at 04:45:51PM +0200, Paolo Bonzini wrote: >> The main difference between the SME and SEV encryption, from the point >> of view of the kernel, is that real-mode always writes unencrypted in >> SME and always writes encrypted in SEV. But UEFI can run in 64-bit mode >> and learn about the C bit, so EFI boot data should be unprotected in SEV >> guests. > > Actually, it is different: you can start fully encrypted in SME, see: > > https://lkml.kernel.org/r/2016083539.29880.96739.st...@tlendack-t1.amdoffice.net > > The last paragraph alludes to a certain transparent mode where you're > already encrypted and only certain pieces like EFI is not encrypted. I > think the aim is to have the transparent mode be the default one, which > makes most sense anyway. There is a new Transparent SME mode that is now part of the overall SME support, but I'm not alluding to that in the documentation at all. In TSME mode, everything that goes through the memory controller would be encrypted and that would include EFI data, etc. TSME would be enabled through a BIOS option, thus allowing legacy OSes to benefit. > > The EFI regions are unencrypted for obvious reasons and you need to > access them as such. > >> Because the firmware volume is written to high memory in encrypted >> form, and because the PEI phase runs in 32-bit mode, the firmware >> code will be encrypted; on the other hand, data that is placed in low >> memory for the kernel can be unencrypted, thus limiting differences >> between SME and SEV. > > When you run fully encrypted, you still need to access EFI tables in the > clear. That's why I'm confused about this patch here. This patch assumes that the EFI regions of a guest would be encrypted. Thanks, Tom > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 09/22/2016 09:45 AM, Paolo Bonzini wrote: > > > On 22/09/2016 16:35, Borislav Petkov wrote: @@ -230,6 +230,10 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages) efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd); pgd = efi_pgd; + flags = _PAGE_NX | _PAGE_RW; + if (sev_active) + flags |= _PAGE_ENC; >> So this is confusing me. There's this patch which says EFI data is >> accessed in the clear: >> >> https://lkml.kernel.org/r/2016083738.29880.6909.st...@tlendack-t1.amdoffice.net >> >> but now here it is encrypted when SEV is enabled. >> >> Do you mean, it is encrypted here because we're in the guest kernel? > > I suspect this patch is untested, and also wrong. :) Yes, it is untested but not sure that it is wrong... It all depends on how we add SEV support to the guest UEFI BIOS. My take would be to have the EFI data and ACPI tables encrypted. > > The main difference between the SME and SEV encryption, from the point > of view of the kernel, is that real-mode always writes unencrypted in > SME and always writes encrypted in SEV. But UEFI can run in 64-bit mode > and learn about the C bit, so EFI boot data should be unprotected in SEV > guests. > > Because the firmware volume is written to high memory in encrypted form, > and because the PEI phase runs in 32-bit mode, the firmware code will be > encrypted; on the other hand, data that is placed in low memory for the > kernel can be unencrypted, thus limiting differences between SME and SEV. I like the idea of limiting the differences but it would leave the EFI data and ACPI tables exposed and able to be manipulated. > > Important: I don't know what you guys are doing for SEV and > Windows guests, but if you are doing something I would really > appreciate doing things in the open. If Linux and Windows end > up doing different things with EFI boot data, ACPI tables, etc. > it will be a huge pain. On the other hand, if we can enjoy > being first, that's great. We haven't discussed Windows guests under SEV yet, but as you say, we need to do things the same. Thanks, Tom > > In fact, I have suggested in the QEMU list that SEV guests should always > use UEFI; because BIOS runs in real-mode or 32-bit non-paging protected > mode, BIOS must always write encrypted data, which becomes painful in > the kernel. > > And regarding the above "important" point, all I know is that Microsoft > for sure will be happy to restrict SEV to UEFI guests. :) > > There are still some differences, mostly around the real mode trampoline > executed by the kernel, but they should be much smaller. > > Paolo > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On 09/22/2016 02:11 PM, Borislav Petkov wrote: > On Thu, Sep 22, 2016 at 02:04:27PM -0500, Tom Lendacky wrote: >> That's not what I mean here. If the BIOS sets the SMEE bit in the >> SYS_CFG msr then, even if the encryption bit is never used, there is >> still a reduction in physical address space. > > I thought that reduction is the reservation of bits for the SME mask. > > What other reduction is there? There is a reduction in physical address space for the SME mask and the bits used to aid in identifying the ASID associated with the memory request. This allows for the memory controller to determine the key to be used for the encryption operation (host/hypervisor key vs. an SEV guest key). Thanks, Tom > >> Transparent SME (TSME) will be a BIOS option that will result in the >> memory controller performing encryption no matter what. In this case >> all data will be encrypted without a reduction in physical address >> space. > > Now I'm confused: aren't we reducing the address space with the SME > mask? > > Or what reduction do you mean? > ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RFC PATCH v1 09/28] x86/efi: Access EFI data as encrypted when SEV is active
On Thu, Sep 22, 2016 at 02:49:22PM -0500, Tom Lendacky wrote: > > I thought that reduction is the reservation of bits for the SME mask. > > > > What other reduction is there? > > There is a reduction in physical address space for the SME mask and the > bits used to aid in identifying the ASID associated with the memory > request. This allows for the memory controller to determine the key to > be used for the encryption operation (host/hypervisor key vs. an SEV > guest key). Ok, I think I see what you mean: you call SME mask the bit in CPUID Fn8000_001F[EBX][5:0], i.e., the C-bit, i.e. sme_me_mask. And the other reduction is the key ASID, i.e., CPUID Fn8000_001F[EBX][11:6], i.e. sme_me_loss. I think we're on the same page - I was simply calling everything SME mask because both are together in the PTE: "Additionally, in some implementations, the physical address size of the processor may be reduced when memory encryption features are enabled, for example from 48 to 43 bits." -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/2] staging: ion: Fix a coding style issue
On 09/22/2016 08:59 AM, Antti Keränen wrote:
Remove unnecessary braces surrounding a single statement block
In the future, when sending different versions of a patch please
give a short summary of what's changed. I think this is just
a resend from v2 with more reviewers added but I'm not 100%
sure.
Signed-off-by: Antti Keränen
---
You can put your summary right here between the --- and the
diffstat.
drivers/staging/android/ion/hisilicon/hi6220_ion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
index 659aa71..bd45151 100644
--- a/drivers/staging/android/ion/hisilicon/hi6220_ion.c
+++ b/drivers/staging/android/ion/hisilicon/hi6220_ion.c
@@ -82,9 +82,9 @@ static int hi6220_ion_remove(struct platform_device *pdev)
ipdev = platform_get_drvdata(pdev);
- for (i = 0; i < ipdev->data->nr; i++) {
+ for (i = 0; i < ipdev->data->nr; i++)
ion_heap_destroy(ipdev->heaps[i]);
- }
+
ion_destroy_platform_data(ipdev->data);
ion_device_destroy(ipdev->idev);
The patch looks fine though so assuming nothing else has
changed
Acked-by: Laura Abbott
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 2/2] staging: ion: Fix a coding style issue
On 09/22/2016 08:59 AM, Antti Keränen wrote:
Correctly align an unaligned block comment
Signed-off-by: Antti Keränen
---
drivers/staging/android/uapi/ion.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/android/uapi/ion.h
b/drivers/staging/android/uapi/ion.h
index 647f130..e629394 100644
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -57,7 +57,7 @@ enum ion_heap_type {
* cached, ion will do cache
* maintenance when the buffer is
* mapped for dma
- */
+*/
#define ION_FLAG_CACHED_NEEDS_SYNC 2 /*
* mappings of this buffer will created
* at mmap time, if this is set
I've always hated these comments. Can you fix them to be regular
looking right above each #define?
Thanks,
Laura
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: wlan-ng: fixed a coding style issue
On Thu, Sep 22, 2016 at 09:11:46PM +0200, Jannik Becher wrote:
> removed a space after a cast to obtain the coding style.
>
> Signed-off-by: Jannik Becher
> ---
> drivers/staging/wlan-ng/p80211req.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/wlan-ng/p80211req.c
> b/drivers/staging/wlan-ng/p80211req.c
> index 40627d5..ecd2fff 100644
> --- a/drivers/staging/wlan-ng/p80211req.c
> +++ b/drivers/staging/wlan-ng/p80211req.c
> @@ -110,7 +110,7 @@ static void p80211req_handle_action(struct wlandevice
> *wlandev, u32 *data,
> */
> int p80211req_dorequest(struct wlandevice *wlandev, u8 *msgbuf)
> {
> - struct p80211msg *msg = (struct p80211msg *) msgbuf;
> + struct p80211msg *msg = (struct p80211msg *)msgbuf;
>
> /* Check to make sure the MSD is running */
> if (!((wlandev->msdstate == WLAN_MSD_HWPRESENT &&
checkpatch.pl shows that in this file there are other occurances of
style deviations - of same or other kinds. Could you please present work
on wider scope, e.g. on whole wlan-ng/, or at last making this one file
to pass checkpatch.pl --strict cleanly?
Not that I don't appreciate this small achievement, but I believe
maintainers won't merge this one, exactly because there is more work of
same kind in the same file.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: wlan-ng: fixed a coding style issue
On Thu, Sep 22, 2016 at 11:32:02PM +0300, Andrey Utkin wrote:
> On Thu, Sep 22, 2016 at 09:11:46PM +0200, Jannik Becher wrote:
> > removed a space after a cast to obtain the coding style.
> >
> > Signed-off-by: Jannik Becher
> > ---
> > drivers/staging/wlan-ng/p80211req.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/wlan-ng/p80211req.c
> > b/drivers/staging/wlan-ng/p80211req.c
> > index 40627d5..ecd2fff 100644
> > --- a/drivers/staging/wlan-ng/p80211req.c
> > +++ b/drivers/staging/wlan-ng/p80211req.c
> > @@ -110,7 +110,7 @@ static void p80211req_handle_action(struct wlandevice
> > *wlandev, u32 *data,
> > */
> > int p80211req_dorequest(struct wlandevice *wlandev, u8 *msgbuf)
> > {
> > - struct p80211msg *msg = (struct p80211msg *) msgbuf;
> > + struct p80211msg *msg = (struct p80211msg *)msgbuf;
> >
> > /* Check to make sure the MSD is running */
> > if (!((wlandev->msdstate == WLAN_MSD_HWPRESENT &&
>
> checkpatch.pl shows that in this file there are other occurances of
> style deviations - of same or other kinds. Could you please present work
> on wider scope, e.g. on whole wlan-ng/, or at last making this one file
> to pass checkpatch.pl --strict cleanly?
>
> Not that I don't appreciate this small achievement, but I believe
> maintainers won't merge this one, exactly because there is more work of
> same kind in the same file.
I always wondered why I shouldn't make more than one change in a patch,
but in all talks I watched they said that it's easier for them to merge
small patches.
So you think I should make one "big" patch and resend it?
Thank you for taking your time.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: ion: Align cases with switch
The preferred indentation for cases and switches has the cases at the same
level as the switch.
Signed-off-by: Christopher H. Pezley
---
drivers/staging/android/ion/ion_of.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/android/ion/ion_of.c
b/drivers/staging/android/ion/ion_of.c
index de0899a..3c050b0 100644
--- a/drivers/staging/android/ion/ion_of.c
+++ b/drivers/staging/android/ion/ion_of.c
@@ -58,15 +58,15 @@ int ion_setup_heap_common(struct platform_device *parent,
int ret = 0;
switch (heap->type) {
- case ION_HEAP_TYPE_CARVEOUT:
- case ION_HEAP_TYPE_CHUNK:
- if (heap->base && heap->size)
- return 0;
-
- ret = of_reserved_mem_device_init(heap->priv);
- break;
- default:
- break;
+ case ION_HEAP_TYPE_CARVEOUT:
+ case ION_HEAP_TYPE_CHUNK:
+ if (heap->base && heap->size)
+ return 0;
+
+ ret = of_reserved_mem_device_init(heap->priv);
+ break;
+ default:
+ break;
}
return ret;
--
2.7.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: wlan-ng: fixed a coding style issue
On Thu, 2016-09-22 at 22:52 +0200, becher.jan...@gmail.com wrote: > I always wondered why I shouldn't make more than one change in a patch, > but in all talks I watched they said that it's easier for them to merge > small patches. > > So you think I should make one "big" patch and resend it? Make separate patches for each "type" of change. Here it would be removing unnecessary space before all casts in the same file or for all specific driver files. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: wlan-ng: fixed a coding style issue
On Thu, Sep 22, 2016 at 10:52:18PM +0200, becher.jan...@gmail.com wrote: > I always wondered why I shouldn't make more than one change in a patch, > but in all talks I watched they said that it's easier for them to merge > small patches. > So you think I should make one "big" patch and resend it? > Thank you for taking your time. There is "big" and then there is "big". Walking through entire driver fixing all occurances of _same_ issues really should be done at once. Trivial style fixes don't usually go in huge series of commits (but BTW if you send several related patches, please send them as series at once). And leave granularity to conceptually different changes. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] drivers: wlan-ng: fixed a coding style issue
removed a space after a cast to obtain the coding style.
Signed-off-by: Jannik Becher
---
drivers/staging/wlan-ng/hfa384x.h | 4 ++--
drivers/staging/wlan-ng/p80211netdev.c | 12 ++--
drivers/staging/wlan-ng/p80211req.c| 16
drivers/staging/wlan-ng/prism2fw.c | 18 +-
drivers/staging/wlan-ng/prism2mgmt.c | 8
drivers/staging/wlan-ng/prism2mib.c| 16
drivers/staging/wlan-ng/prism2sta.c| 32
7 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index f8ee175..4cf4796 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -256,7 +256,7 @@ Information RID Lengths: MAC Information
include the len or code fields)
*/
#defineHFA384x_RID_DBMCOMMSQUALITY_LEN \
- ((u16) sizeof(hfa384x_dbmcommsquality_t))
+ ((u16)sizeof(hfa384x_dbmcommsquality_t))
#defineHFA384x_RID_JOINREQUEST_LEN \
((u16)sizeof(hfa384x_JoinRequest_data_t))
@@ -1380,7 +1380,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw,
u16 rid, void *val)
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
- *((u16 *) val) = le16_to_cpu(*((u16 *) val));
+ *((u16 *)val) = le16_to_cpu(*((u16 *)val));
return result;
}
diff --git a/drivers/staging/wlan-ng/p80211netdev.c
b/drivers/staging/wlan-ng/p80211netdev.c
index fb97779..38c936a 100644
--- a/drivers/staging/wlan-ng/p80211netdev.c
+++ b/drivers/staging/wlan-ng/p80211netdev.c
@@ -231,7 +231,7 @@ static int p80211_convert_to_ether(struct wlandevice
*wlandev, struct sk_buff *s
{
struct p80211_hdr_a3 *hdr;
- hdr = (struct p80211_hdr_a3 *) skb->data;
+ hdr = (struct p80211_hdr_a3 *)skb->data;
if (p80211_rx_typedrop(wlandev, hdr->fc))
return CONV_TO_ETHER_SKIPPED;
@@ -265,7 +265,7 @@ static int p80211_convert_to_ether(struct wlandevice
*wlandev, struct sk_buff *s
*/
static void p80211netdev_rx_bh(unsigned long arg)
{
- struct wlandevice *wlandev = (struct wlandevice *) arg;
+ struct wlandevice *wlandev = (struct wlandevice *)arg;
struct sk_buff *skb = NULL;
netdevice_t *dev = wlandev->netdev;
@@ -534,7 +534,7 @@ static int p80211netdev_ethtool(struct wlandevice *wlandev,
void __user *useradd
static int p80211knetdev_do_ioctl(netdevice_t *dev, struct ifreq *ifr, int cmd)
{
int result = 0;
- struct p80211ioctl_req *req = (struct p80211ioctl_req *) ifr;
+ struct p80211ioctl_req *req = (struct p80211ioctl_req *)ifr;
struct wlandevice *wlandev = dev->ml_priv;
u8 *msgbuf;
@@ -625,7 +625,7 @@ static int p80211knetdev_set_mac_address(netdevice_t *dev,
void *addr)
/* Set up some convenience pointers. */
mibattr = &dot11req.mibattribute;
- macaddr = (p80211item_pstr6_t *) &mibattr->data;
+ macaddr = (p80211item_pstr6_t *)&mibattr->data;
resultcode = &dot11req.resultcode;
/* Set up a dot11req_mibset */
@@ -633,7 +633,7 @@ static int p80211knetdev_set_mac_address(netdevice_t *dev,
void *addr)
dot11req.msgcode = DIDmsg_dot11req_mibset;
dot11req.msglen = sizeof(struct p80211msg_dot11req_mibset);
memcpy(dot11req.devname,
- ((struct wlandevice *) dev->ml_priv)->name, WLAN_DEVNAMELEN_MAX
- 1);
+ ((struct wlandevice *)dev->ml_priv)->name, WLAN_DEVNAMELEN_MAX -
1);
/* Set up the mibattribute argument */
mibattr->did = DIDmsg_dot11req_mibset_mibattribute;
@@ -653,7 +653,7 @@ static int p80211knetdev_set_mac_address(netdevice_t *dev,
void *addr)
resultcode->data = 0;
/* now fire the request */
- result = p80211req_dorequest(dev->ml_priv, (u8 *) &dot11req);
+ result = p80211req_dorequest(dev->ml_priv, (u8 *)&dot11req);
/* If the request wasn't successful, report an error and don't
* change the netdev address
diff --git a/drivers/staging/wlan-ng/p80211req.c
b/drivers/staging/wlan-ng/p80211req.c
index 40627d5..010e5dc 100644
--- a/drivers/staging/wlan-ng/p80211req.c
+++ b/drivers/staging/wlan-ng/p80211req.c
@@ -110,7 +110,7 @@ static void p80211req_handle_action(struct wlandevice
*wlandev, u32 *data,
*/
int p80211req_dorequest(struct wlandevice *wlandev, u8 *msgbuf)
{
- struct p80211msg *msg = (struct p80211msg *) msgbuf;
+ struct p80211msg *msg = (struct p80211msg *)msgbuf;
/* Check to make sure the MSD is running */
if (!((wlandev->msdstate == WLAN_MSD_HWPRESENT &&
@@ -170,7 +170,7 @@ static void p80211req_handlemsg(struct wlandevice *wlandev,
struct p80211msg *ms
case DIDmsg_lnxr
Re: [PATCH] drivers: wlan-ng: fixed a coding style issue
On Thu, 2016-09-22 at 23:56 +0200, Jannik Becher wrote: > removed a space after a cast to obtain the coding style. Better would be to change the subject to something like: [PATCH] staging: wlan-ng: Remove unnecessary spaces before casts ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: wlan-ng: fixed a coding style issue
On Thu, Sep 22, 2016 at 03:05:02PM -0700, Joe Perches wrote: > On Thu, 2016-09-22 at 23:56 +0200, Jannik Becher wrote: > > removed a space after a cast to obtain the coding style. > > Better would be to change the subject to something like: > > [PATCH] staging: wlan-ng: Remove unnecessary spaces before casts Should I resend the patch with this subject? Sorry for writing so many emails and asking questions. My problem is that I have no idea who to put in the cc if I'm responding to an email. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers: wlan-ng: fixed a coding style issue
On Fri, 2016-09-23 at 00:39 +0200, becher.jan...@gmail.com wrote:
> On Thu, Sep 22, 2016 at 03:05:02PM -0700, Joe Perches wrote:
> > On Thu, 2016-09-22 at 23:56 +0200, Jannik Becher wrote:
> > >r emoved a space after a cast to obtain the coding style.
> > Better would be to change the subject to something like:
> > [PATCH] staging: wlan-ng: Remove unnecessary spaces before casts
> Should I resend the patch with this subject?
> Sorry for writing so many emails and asking questions. My problem is
> that I have no idea who to put in the cc if I'm responding to an email.
Yes, with an appropriate {PATCH V2] subject prefix.
Also do not leave the commit message blank.
Describe why you are making this change.
Maybe show the tool used to find and fix this issue too.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH V2] staging: wlan-ng: remove unnecessary spaces before casts
Fixed a coding style issue by removing unnecessary spaces before casts.
Signed-off-by: Jannik Becher
---
drivers/staging/wlan-ng/hfa384x.h | 4 ++--
drivers/staging/wlan-ng/p80211netdev.c | 12 ++--
drivers/staging/wlan-ng/p80211req.c| 16
drivers/staging/wlan-ng/prism2fw.c | 18 +-
drivers/staging/wlan-ng/prism2mgmt.c | 8
drivers/staging/wlan-ng/prism2mib.c| 16
drivers/staging/wlan-ng/prism2sta.c| 32
7 files changed, 53 insertions(+), 53 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index f8ee175..4cf4796 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -256,7 +256,7 @@ Information RID Lengths: MAC Information
include the len or code fields)
*/
#defineHFA384x_RID_DBMCOMMSQUALITY_LEN \
- ((u16) sizeof(hfa384x_dbmcommsquality_t))
+ ((u16)sizeof(hfa384x_dbmcommsquality_t))
#defineHFA384x_RID_JOINREQUEST_LEN \
((u16)sizeof(hfa384x_JoinRequest_data_t))
@@ -1380,7 +1380,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw,
u16 rid, void *val)
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
- *((u16 *) val) = le16_to_cpu(*((u16 *) val));
+ *((u16 *)val) = le16_to_cpu(*((u16 *)val));
return result;
}
diff --git a/drivers/staging/wlan-ng/p80211netdev.c
b/drivers/staging/wlan-ng/p80211netdev.c
index fb97779..38c936a 100644
--- a/drivers/staging/wlan-ng/p80211netdev.c
+++ b/drivers/staging/wlan-ng/p80211netdev.c
@@ -231,7 +231,7 @@ static int p80211_convert_to_ether(struct wlandevice
*wlandev, struct sk_buff *s
{
struct p80211_hdr_a3 *hdr;
- hdr = (struct p80211_hdr_a3 *) skb->data;
+ hdr = (struct p80211_hdr_a3 *)skb->data;
if (p80211_rx_typedrop(wlandev, hdr->fc))
return CONV_TO_ETHER_SKIPPED;
@@ -265,7 +265,7 @@ static int p80211_convert_to_ether(struct wlandevice
*wlandev, struct sk_buff *s
*/
static void p80211netdev_rx_bh(unsigned long arg)
{
- struct wlandevice *wlandev = (struct wlandevice *) arg;
+ struct wlandevice *wlandev = (struct wlandevice *)arg;
struct sk_buff *skb = NULL;
netdevice_t *dev = wlandev->netdev;
@@ -534,7 +534,7 @@ static int p80211netdev_ethtool(struct wlandevice *wlandev,
void __user *useradd
static int p80211knetdev_do_ioctl(netdevice_t *dev, struct ifreq *ifr, int cmd)
{
int result = 0;
- struct p80211ioctl_req *req = (struct p80211ioctl_req *) ifr;
+ struct p80211ioctl_req *req = (struct p80211ioctl_req *)ifr;
struct wlandevice *wlandev = dev->ml_priv;
u8 *msgbuf;
@@ -625,7 +625,7 @@ static int p80211knetdev_set_mac_address(netdevice_t *dev,
void *addr)
/* Set up some convenience pointers. */
mibattr = &dot11req.mibattribute;
- macaddr = (p80211item_pstr6_t *) &mibattr->data;
+ macaddr = (p80211item_pstr6_t *)&mibattr->data;
resultcode = &dot11req.resultcode;
/* Set up a dot11req_mibset */
@@ -633,7 +633,7 @@ static int p80211knetdev_set_mac_address(netdevice_t *dev,
void *addr)
dot11req.msgcode = DIDmsg_dot11req_mibset;
dot11req.msglen = sizeof(struct p80211msg_dot11req_mibset);
memcpy(dot11req.devname,
- ((struct wlandevice *) dev->ml_priv)->name, WLAN_DEVNAMELEN_MAX
- 1);
+ ((struct wlandevice *)dev->ml_priv)->name, WLAN_DEVNAMELEN_MAX -
1);
/* Set up the mibattribute argument */
mibattr->did = DIDmsg_dot11req_mibset_mibattribute;
@@ -653,7 +653,7 @@ static int p80211knetdev_set_mac_address(netdevice_t *dev,
void *addr)
resultcode->data = 0;
/* now fire the request */
- result = p80211req_dorequest(dev->ml_priv, (u8 *) &dot11req);
+ result = p80211req_dorequest(dev->ml_priv, (u8 *)&dot11req);
/* If the request wasn't successful, report an error and don't
* change the netdev address
diff --git a/drivers/staging/wlan-ng/p80211req.c
b/drivers/staging/wlan-ng/p80211req.c
index 40627d5..010e5dc 100644
--- a/drivers/staging/wlan-ng/p80211req.c
+++ b/drivers/staging/wlan-ng/p80211req.c
@@ -110,7 +110,7 @@ static void p80211req_handle_action(struct wlandevice
*wlandev, u32 *data,
*/
int p80211req_dorequest(struct wlandevice *wlandev, u8 *msgbuf)
{
- struct p80211msg *msg = (struct p80211msg *) msgbuf;
+ struct p80211msg *msg = (struct p80211msg *)msgbuf;
/* Check to make sure the MSD is running */
if (!((wlandev->msdstate == WLAN_MSD_HWPRESENT &&
@@ -170,7 +170,7 @@ static void p80211req_handlemsg(struct wlandevice *wlandev,
struct p80211msg *ms
c
Re: [PATCH 04/11] staging: dgnc: kfree for board structure in
2016-09-22 16:21 GMT+09:00 Greg KH : > On Thu, Sep 22, 2016 at 02:22:03PM +0900, Daeseok Youn wrote: >> The board structure should be freed when any function was failed >> in dgnc_found_board(). And the board strucure will be stored >> into dgnc_board array when the dgnc_found_board() function has no error. >> >> Signed-off-by: Daeseok Youn >> --- >> drivers/staging/dgnc/dgnc_driver.c | 17 + >> 1 file changed, 9 insertions(+), 8 deletions(-) > > Another shortened subject line. I am not sure why the subject line was cut off. I will fix them up and resend. Thanks. Regards, Daeseok. > > Please look at all of the subjects in this series, fix them up, and > resend. > > thanks, > > greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 01/11 V2] staging: dgnc: remove redundant initialization for channel array
The channel array in board_t was initialized in dgnc_found_board() with NULL. But the channel is going to initialize in dgnc_tty_init() again. So the channel array doesn't need to set NULL for initailization in dgnc_found_board(). Signed-off-by: Daeseok Youn --- V2: The subject line was cut off, I put it completely and update change log. drivers/staging/dgnc/dgnc_driver.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/staging/dgnc/dgnc_driver.c b/drivers/staging/dgnc/dgnc_driver.c index 01e948c..b598034 100644 --- a/drivers/staging/dgnc/dgnc_driver.c +++ b/drivers/staging/dgnc/dgnc_driver.c @@ -400,9 +400,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id) brd->state = BOARD_FOUND; - for (i = 0; i < MAXPORTS; i++) - brd->channels[i] = NULL; - /* store which card & revision we have */ pci_read_config_word(pdev, PCI_SUBSYSTEM_VENDOR_ID, &brd->subvendor); pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &brd->subdevice); -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 03/11 V2] staging: dgnc: missing NULL check for ioremap in dgnc_do_remap()
The ioremap() function can be failed, so it need to have error
handling in dgnc_do_remap(). And also the return type of
dgnc_do_remap() should be changed from "void" to "int"
Signed-off-by: Daeseok Youn
---
V2: the subject line was cut off, I put it completely.
drivers/staging/dgnc/dgnc_driver.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index c87b3de..58cebf4 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -43,7 +43,7 @@ static void dgnc_cleanup_board(struct dgnc_board
*brd);
static voiddgnc_poll_handler(ulong dummy);
static int dgnc_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent);
-static voiddgnc_do_remap(struct dgnc_board *brd);
+static int dgnc_do_remap(struct dgnc_board *brd);
/*
* File operations permitted on Control/Management major.
@@ -431,7 +431,10 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
brd->bd_uart_offset = 0x8;
brd->bd_dividend = 921600;
- dgnc_do_remap(brd);
+ rc = dgnc_do_remap(brd);
+
+ if (rc < 0)
+ goto failed;
/* Get and store the board VPD, if it exists */
brd->bd_ops->vpd(brd);
@@ -483,15 +486,17 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
brd->bd_uart_offset = 0x200;
brd->bd_dividend = 921600;
- dgnc_do_remap(brd);
+ rc = dgnc_do_remap(brd);
- if (brd->re_map_membase) {
- /* Read and store the dvid after remapping */
- brd->dvid = readb(brd->re_map_membase + 0x8D);
+ if (rc < 0)
+ goto failed;
+
+ /* Read and store the dvid after remapping */
+ brd->dvid = readb(brd->re_map_membase + 0x8D);
+
+ /* Get and store the board VPD, if it exists */
+ brd->bd_ops->vpd(brd);
- /* Get and store the board VPD, if it exists */
- brd->bd_ops->vpd(brd);
- }
break;
default:
@@ -566,9 +571,15 @@ static int dgnc_finalize_board_init(struct dgnc_board *brd)
/*
* Remap PCI memory.
*/
-static void dgnc_do_remap(struct dgnc_board *brd)
+static int dgnc_do_remap(struct dgnc_board *brd)
{
+ int rc = 0;
+
brd->re_map_membase = ioremap(brd->membase, 0x1000);
+ if (!brd->re_map_membase)
+ rc = -ENOMEM;
+
+ return rc;
}
/*
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 04/11 V2] staging: dgnc: kfree for board structure in dgnc_found_board()
The board structure should be freed when any function was failed
in dgnc_found_board(). And the board strucure will be stored
into dgnc_board array when the dgnc_found_board() function has no error.
Signed-off-by: Daeseok Youn
---
V2: the subject line was cut off, I put it completely.
drivers/staging/dgnc/dgnc_driver.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 58cebf4..0114e78 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -353,9 +353,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
int rc = 0;
/* get the board structure and prep it */
- dgnc_board[dgnc_num_boards] = kzalloc(sizeof(*brd), GFP_KERNEL);
- brd = dgnc_board[dgnc_num_boards];
-
+ brd = kzalloc(sizeof(*brd), GFP_KERNEL);
if (!brd)
return -ENOMEM;
@@ -411,7 +409,8 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
if (!brd->membase) {
dev_err(&brd->pdev->dev,
"Card has no PCI IO resources, failing.\n");
- return -ENODEV;
+ rc = -ENODEV;
+ goto failed;
}
brd->membase_end = pci_resource_end(pdev, 4);
@@ -502,7 +501,8 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
default:
dev_err(&brd->pdev->dev,
"Didn't find any compatible Neo/Classic PCI boards.\n");
- return -ENXIO;
+ rc = -ENXIO;
+ goto failed;
}
/*
@@ -539,14 +539,15 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
wake_up_interruptible(&brd->state_wait);
+ dgnc_board[dgnc_num_boards] = brd;
+
return 0;
failed:
dgnc_tty_uninit(brd);
- brd->state = BOARD_FAILED;
- brd->dpastatus = BD_NOFEP;
+ kfree(brd);
- return -ENXIO;
+ return rc;
}
static int dgnc_finalize_board_init(struct dgnc_board *brd)
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 05/11 V2] staging: dgnc: move functions unrelated with dgnc_found_board()
The functions related with tty device initialization are needed
to be moved from dgnc_found_board() to dgnc_init_one().
Signed-off-by: Daeseok Youn
---
V2: the subject line was cut off, I put it completely.
drivers/staging/dgnc/dgnc_driver.c | 81 --
1 file changed, 43 insertions(+), 38 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 0114e78..a95d13c 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -38,7 +38,7 @@ MODULE_SUPPORTED_DEVICE("dgnc");
*/
static int dgnc_start(void);
static int dgnc_finalize_board_init(struct dgnc_board *brd);
-static int dgnc_found_board(struct pci_dev *pdev, int id);
+static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id);
static voiddgnc_cleanup_board(struct dgnc_board *brd);
static voiddgnc_poll_handler(ulong dummy);
static int dgnc_init_one(struct pci_dev *pdev,
@@ -274,6 +274,7 @@ failed_class:
static int dgnc_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
{
int rc;
+ struct dgnc_board *brd;
/* wake up and enable device */
rc = pci_enable_device(pdev);
@@ -281,9 +282,43 @@ static int dgnc_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (rc)
return -EIO;
- rc = dgnc_found_board(pdev, ent->driver_data);
- if (rc == 0)
- dgnc_num_boards++;
+ brd = dgnc_found_board(pdev, ent->driver_data);
+ if (IS_ERR(brd))
+ return PTR_ERR(brd);
+
+ /*
+* Do tty device initialization.
+*/
+
+ rc = dgnc_tty_register(brd);
+ if (rc < 0) {
+ pr_err(DRVSTR ": Can't register tty devices (%d)\n", rc);
+ goto failed;
+ }
+
+ rc = dgnc_finalize_board_init(brd);
+ if (rc < 0) {
+ pr_err(DRVSTR ": Can't finalize board init (%d)\n", rc);
+ goto failed;
+ }
+
+ rc = dgnc_tty_init(brd);
+ if (rc < 0) {
+ pr_err(DRVSTR ": Can't init tty devices (%d)\n", rc);
+ goto failed;
+ }
+
+ brd->state = BOARD_READY;
+ brd->dpastatus = BD_RUNNING;
+
+ dgnc_create_ports_sysfiles(brd);
+
+ dgnc_board[dgnc_num_boards++] = brd;
+
+ return 0;
+
+failed:
+ kfree(brd);
return rc;
}
@@ -345,7 +380,7 @@ static void dgnc_cleanup_board(struct dgnc_board *brd)
*
* A board has been found, init it.
*/
-static int dgnc_found_board(struct pci_dev *pdev, int id)
+static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id)
{
struct dgnc_board *brd;
unsigned int pci_irq;
@@ -355,7 +390,7 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
/* get the board structure and prep it */
brd = kzalloc(sizeof(*brd), GFP_KERNEL);
if (!brd)
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
/* store the info for the board we've found */
brd->magic = DGNC_BOARD_MAGIC;
@@ -505,33 +540,6 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
goto failed;
}
- /*
-* Do tty device initialization.
-*/
-
- rc = dgnc_tty_register(brd);
- if (rc < 0) {
- pr_err(DRVSTR ": Can't register tty devices (%d)\n", rc);
- goto failed;
- }
-
- rc = dgnc_finalize_board_init(brd);
- if (rc < 0) {
- pr_err(DRVSTR ": Can't finalize board init (%d)\n", rc);
- goto failed;
- }
-
- rc = dgnc_tty_init(brd);
- if (rc < 0) {
- pr_err(DRVSTR ": Can't init tty devices (%d)\n", rc);
- goto failed;
- }
-
- brd->state = BOARD_READY;
- brd->dpastatus = BD_RUNNING;
-
- dgnc_create_ports_sysfiles(brd);
-
/* init our poll helper tasklet */
tasklet_init(&brd->helper_tasklet,
brd->bd_ops->tasklet,
@@ -539,15 +547,12 @@ static int dgnc_found_board(struct pci_dev *pdev, int id)
wake_up_interruptible(&brd->state_wait);
- dgnc_board[dgnc_num_boards] = brd;
-
- return 0;
+ return brd;
failed:
- dgnc_tty_uninit(brd);
kfree(brd);
- return rc;
+ return ERR_PTR(rc);
}
static int dgnc_finalize_board_init(struct dgnc_board *brd)
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 07/11 V2] staging: dgnc: rename dgnc_finalize_board_init() to dgnc_request_irq()
The dgnc_finalize_board_init() function has only job for
requesting the IRQ. It should be renamed to dgnc_request_irq()
Signed-off-by: Daeseok Youn
---
V2: the subject line was cut off, I put it completely.
drivers/staging/dgnc/dgnc_driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index ffe55a2..70e68b5 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -37,7 +37,7 @@ MODULE_SUPPORTED_DEVICE("dgnc");
*
*/
static int dgnc_start(void);
-static int dgnc_finalize_board_init(struct dgnc_board *brd);
+static int dgnc_request_irq(struct dgnc_board *brd);
static struct dgnc_board *dgnc_found_board(struct pci_dev *pdev, int id);
static voiddgnc_cleanup_board(struct dgnc_board *brd);
static voiddgnc_poll_handler(ulong dummy);
@@ -296,7 +296,7 @@ static int dgnc_init_one(struct pci_dev *pdev, const struct
pci_device_id *ent)
goto failed;
}
- rc = dgnc_finalize_board_init(brd);
+ rc = dgnc_request_irq(brd);
if (rc < 0) {
pr_err(DRVSTR ": Can't finalize board init (%d)\n", rc);
goto unregister_tty;
@@ -558,7 +558,7 @@ failed:
return ERR_PTR(rc);
}
-static int dgnc_finalize_board_init(struct dgnc_board *brd)
+static int dgnc_request_irq(struct dgnc_board *brd)
{
int rc = 0;
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 09/11 V2] staging: dgnc: rename dgnc_tty_uninit() to dgnc_cleanup_tty()
The dgnc_tty_uninit() doesn't match with dgnc_tty_init() at all.
And also the dgnc_cleanup_tty() is only called for exiting the module.
Signed-off-by: Daeseok Youn
---
V2: the subject line was cut off, I put it completely.
drivers/staging/dgnc/dgnc_driver.c | 2 +-
drivers/staging/dgnc/dgnc_tty.c| 4 ++--
drivers/staging/dgnc/dgnc_tty.h| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/dgnc/dgnc_driver.c
b/drivers/staging/dgnc/dgnc_driver.c
index 81ce5c4..fd372d3 100644
--- a/drivers/staging/dgnc/dgnc_driver.c
+++ b/drivers/staging/dgnc/dgnc_driver.c
@@ -147,7 +147,7 @@ static void cleanup(bool sysfiles)
for (i = 0; i < dgnc_num_boards; ++i) {
dgnc_remove_ports_sysfiles(dgnc_board[i]);
- dgnc_tty_uninit(dgnc_board[i]);
+ dgnc_cleanup_tty(dgnc_board[i]);
dgnc_cleanup_board(dgnc_board[i]);
}
diff --git a/drivers/staging/dgnc/dgnc_tty.c b/drivers/staging/dgnc/dgnc_tty.c
index 893f473..5befd28 100644
--- a/drivers/staging/dgnc/dgnc_tty.c
+++ b/drivers/staging/dgnc/dgnc_tty.c
@@ -387,12 +387,12 @@ void dgnc_tty_post_uninit(void)
}
/*
- * dgnc_tty_uninit()
+ * dgnc_cleanup_tty()
*
* Uninitialize the TTY portion of this driver. Free all memory and
* resources.
*/
-void dgnc_tty_uninit(struct dgnc_board *brd)
+void dgnc_cleanup_tty(struct dgnc_board *brd)
{
int i = 0;
diff --git a/drivers/staging/dgnc/dgnc_tty.h b/drivers/staging/dgnc/dgnc_tty.h
index f065c8f..24c9a41 100644
--- a/drivers/staging/dgnc/dgnc_tty.h
+++ b/drivers/staging/dgnc/dgnc_tty.h
@@ -25,7 +25,7 @@ int dgnc_tty_preinit(void);
int dgnc_tty_init(struct dgnc_board *);
void dgnc_tty_post_uninit(void);
-void dgnc_tty_uninit(struct dgnc_board *);
+void dgnc_cleanup_tty(struct dgnc_board *);
void dgnc_input(struct channel_t *ch);
void dgnc_carrier(struct channel_t *ch);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: avoid to introduce new typedefs
This patch fixes the following checkpatch.pl warning in p80211types.h:
WARNING: do not add new typedefs
Signed-off-by: Sergio Paracuellos
---
drivers/staging/wlan-ng/cfg80211.c | 12 +-
drivers/staging/wlan-ng/p80211metastruct.h | 248 ++---
drivers/staging/wlan-ng/p80211netdev.c | 8 +-
drivers/staging/wlan-ng/p80211netdev.h | 2 +-
drivers/staging/wlan-ng/p80211req.c| 7 +-
drivers/staging/wlan-ng/p80211types.h | 126 +++
drivers/staging/wlan-ng/prism2fw.c | 4 +-
drivers/staging/wlan-ng/prism2mgmt.c | 8 +-
drivers/staging/wlan-ng/prism2mgmt.h | 10 +-
drivers/staging/wlan-ng/prism2mib.c| 16 +-
drivers/staging/wlan-ng/prism2sta.c| 8 +-
11 files changed, 225 insertions(+), 224 deletions(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index 8c592be..aa04395 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -72,8 +72,8 @@ static int prism2_result2err(int prism2_result)
static int prism2_domibset_uint32(struct wlandevice *wlandev, u32 did, u32
data)
{
struct p80211msg_dot11req_mibset msg;
- p80211item_uint32_t *mibitem =
- (p80211item_uint32_t *)&msg.mibattribute.data;
+ struct p80211item_uint32 *mibitem =
+ (struct p80211item_uint32 *)&msg.mibattribute.data;
msg.msgcode = DIDmsg_dot11req_mibset;
mibitem->did = did;
@@ -86,8 +86,8 @@ static int prism2_domibset_pstr32(struct wlandevice *wlandev,
u32 did, u8 len, const u8 *data)
{
struct p80211msg_dot11req_mibset msg;
- p80211item_pstr32_t *mibitem =
- (p80211item_pstr32_t *)&msg.mibattribute.data;
+ struct p80211item_pstr32 *mibitem =
+ (struct p80211item_pstr32 *)&msg.mibattribute.data;
msg.msgcode = DIDmsg_dot11req_mibset;
mibitem->did = did;
@@ -626,11 +626,11 @@ static int prism2_get_tx_power(struct wiphy *wiphy,
struct wireless_dev *wdev,
struct prism2_wiphy_private *priv = wiphy_priv(wiphy);
struct wlandevice *wlandev = priv->wlandev;
struct p80211msg_dot11req_mibget msg;
- p80211item_uint32_t *mibitem;
+ struct p80211item_uint32 *mibitem;
int result;
int err = 0;
- mibitem = (p80211item_uint32_t *)&msg.mibattribute.data;
+ mibitem = (struct p80211item_uint32 *)&msg.mibattribute.data;
msg.msgcode = DIDmsg_dot11req_mibget;
mibitem->did =
DIDmib_dot11phy_dot11PhyTxPowerTable_dot11CurrentTxPowerLevel;
diff --git a/drivers/staging/wlan-ng/p80211metastruct.h
b/drivers/staging/wlan-ng/p80211metastruct.h
index c501162..c454471 100644
--- a/drivers/staging/wlan-ng/p80211metastruct.h
+++ b/drivers/staging/wlan-ng/p80211metastruct.h
@@ -51,221 +51,221 @@ struct p80211msg_dot11req_mibget {
u32 msgcode;
u32 msglen;
u8 devname[WLAN_DEVNAMELEN_MAX];
- p80211item_unk392_t mibattribute;
- p80211item_uint32_t resultcode;
+ struct p80211item_unk392 mibattribute;
+ struct p80211item_uint32 resultcode;
} __packed;
struct p80211msg_dot11req_mibset {
u32 msgcode;
u32 msglen;
u8 devname[WLAN_DEVNAMELEN_MAX];
- p80211item_unk392_t mibattribute;
- p80211item_uint32_t resultcode;
+ struct p80211item_unk392 mibattribute;
+ struct p80211item_uint32 resultcode;
} __packed;
struct p80211msg_dot11req_scan {
u32 msgcode;
u32 msglen;
u8 devname[WLAN_DEVNAMELEN_MAX];
- p80211item_uint32_t bsstype;
- p80211item_pstr6_t bssid;
+ struct p80211item_uint32 bsstype;
+ struct p80211item_pstr6 bssid;
u8 pad_0C[1];
- p80211item_pstr32_t ssid;
+ struct p80211item_pstr32 ssid;
u8 pad_1D[3];
- p80211item_uint32_t scantype;
- p80211item_uint32_t probedelay;
- p80211item_pstr14_t channellist;
+ struct p80211item_uint32 scantype;
+ struct p80211item_uint32 probedelay;
+ struct p80211item_pstr14 channellist;
u8 pad_2C[1];
- p80211item_uint32_t minchanneltime;
- p80211item_uint32_t maxchanneltime;
- p80211item_uint32_t resultcode;
- p80211item_uint32_t numbss;
- p80211item_uint32_t append;
+ struct p80211item_uint32 minchanneltime;
+ struct p80211item_uint32 maxchanneltime;
+ struct p80211item_uint32 resultcode;
+ struct p80211item_uint32 numbss;
+ struct p80211item_uint32 append;
} __packed;
struct p80211msg_dot11req_scan_results {
u32 msgcode;
u32 msglen;
u8 devname[WLAN_DEVNAMELEN_MAX];
- p80211item_uint32_t bssindex;
- p80211item_uint32_t resultcode;
- p80211item_uint32_t signal;
- p80211item_uint32_t noise;
- p80211item_pstr6_t bssid;
+ struct p80211item_uint32 b
