Re: [PATCH] staging: sm750fb: Fix printk() style warning

[Edward Lipinsky]

On Thu, Oct 13, 2016 at 05:39:22PM +0300, Mike Rapoport wrote:
> On Mon, Oct 10, 2016 at 07:31:46AM -0700, Edward Lipinsky wrote:
> > 
> > Thanks, that makes sense.  I tried deleting the if statement and printk()
> > from ddk750_help.c, and adding the following in lynxfb_pci_probe() after
> > calling hw_sm750_map() and checking for errors:
> > 
> > if (sm750_dev->revid == 0xfe)
> > dev_info(>dev, "found sm750le\n");
> > 
> > The driver compiles, loads and unloads ok with this code.
> > 
> > Does this look correct?
> 
> Yep, seems just right.
>  
> > Regards,
> > Ed L.

Good, thanks.  I will submit an updated patch.

Regards,
Ed L.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [staging:staging-next 761/1248] drivers/staging/lustre/lustre/osc/osc_request.c:1045:5-24: WARNING: Unsigned expression compared with zero: cli -> cl_avail_grant < 0

[James Simmons]

> cli->cl_avail_grant has type unsigned long, so the code in line 1039-1045
> will have to be handled in some other way.
> 
> julia

Thank you Julia for reporting this. I have created a patch that is being
tested right now. I will post it shortly.

  
> -- Forwarded message --
> Date: Mon, 3 Oct 2016 13:20:40 +0800
> From: kbuild test robot 
> To: kbu...@01.org
> Cc: Julia Lawall 
> Subject: [staging:staging-next 761/1248]
> drivers/staging/lustre/lustre/osc/osc_request.c:1045:5-24: WARNING: 
> Unsigned
>  expression compared with zero: cli -> cl_avail_grant < 0
> 
> CC: kbuild-...@01.org
> CC: de...@driverdev.osuosl.org
> TO: Dmitry Eremin 
> CC: "Greg Kroah-Hartman" 
> CC: "John L. Hammond" 
> CC: Fan Yong 
> CC: Oleg Drokin 
> CC: James Simmons 
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
> staging-next
> head:   fc1e2c8ea85e109acf09e74789e9b852f6eed251
> commit: 97cba1302d8994b9a573b6274133475e85ef7630 [761/1248] staging: lustre: 
> fix comparison between signed and unsigned
> :: branch date: 12 hours ago
> :: commit date: 2 weeks ago
> 
> >> drivers/staging/lustre/lustre/osc/osc_request.c:1045:5-24: WARNING: 
> >> Unsigned expression compared with zero: cli -> cl_avail_grant < 0
> 
> git remote add staging 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> git remote update staging
> git checkout 97cba1302d8994b9a573b6274133475e85ef7630
> vim +1045 drivers/staging/lustre/lustre/osc/osc_request.c
> 
> d7e09d039 Peng Tao2013-05-02  1029/*
> d7e09d039 Peng Tao2013-05-02  1030 * ocd_grant is the total grant 
> amount we're expect to hold: if we've
> 3147b2684 Hongchao Zhang  2016-08-16  1031 * been evicted, it's the new 
> avail_grant amount, cl_dirty_pages will
> 3147b2684 Hongchao Zhang  2016-08-16  1032 * drop to 0 as inflight RPCs 
> fail out; otherwise, it's avail_grant +
> 3147b2684 Hongchao Zhang  2016-08-16  1033 * dirty.
> d7e09d039 Peng Tao2013-05-02  1034 *
> d7e09d039 Peng Tao2013-05-02  1035 * race is tolerable here: if 
> we're evicted, but imp_state already
> 3147b2684 Hongchao Zhang  2016-08-16  1036 * left EVICTED state, then 
> cl_dirty_pages must be 0 already.
> d7e09d039 Peng Tao2013-05-02  1037 */
> 7d53d8f42 John L. Hammond 2016-03-30  1038
> spin_lock(>cl_loi_list_lock);
> d7e09d039 Peng Tao2013-05-02  1039if (cli->cl_import->imp_state 
> == LUSTRE_IMP_EVICTED)
> d7e09d039 Peng Tao2013-05-02  1040cli->cl_avail_grant = 
> ocd->ocd_grant;
> d7e09d039 Peng Tao2013-05-02  1041else
> 3147b2684 Hongchao Zhang  2016-08-16  1042cli->cl_avail_grant = 
> ocd->ocd_grant -
> 3147b2684 Hongchao Zhang  2016-08-16  1043  
> (cli->cl_dirty_pages << PAGE_SHIFT);
> d7e09d039 Peng Tao2013-05-02  1044
> d7e09d039 Peng Tao2013-05-02 @1045if (cli->cl_avail_grant < 0) {
> d7e09d039 Peng Tao2013-05-02  1046CWARN("%s: available 
> grant < 0: avail/ocd/dirty %ld/%u/%ld\n",
> d7e09d039 Peng Tao2013-05-02  1047  
> cli->cl_import->imp_obd->obd_name, cli->cl_avail_grant,
> 3147b2684 Hongchao Zhang  2016-08-16  1048  ocd->ocd_grant, 
> cli->cl_dirty_pages << PAGE_SHIFT);
> d7e09d039 Peng Tao2013-05-02  1049/* workaround for 
> servers which do not have the patch from
> 30aa9c526 Oleg Drokin 2016-02-24  1050 * LU-2679
> 30aa9c526 Oleg Drokin 2016-02-24  1051 */
> d7e09d039 Peng Tao2013-05-02  1052cli->cl_avail_grant = 
> ocd->ocd_grant;
> d7e09d039 Peng Tao2013-05-02  1053}
> 
> :: The code at line 1045 was first introduced by commit
> :: d7e09d0397e84eefbabfd9cb353221f3c6448d83 staging: add Lustre file 
> system client support
> 
> :: TO: Peng Tao 
> :: CC: Greg Kroah-Hartman 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 32/41] staging: lustre: llite: restart short read/write for normal IO

[James Simmons]

> On Wed, Oct 12, 2016 at 12:22:35AM +0100, James Simmons wrote:
> > 
> > > On Sun, Oct 02, 2016 at 10:28:28PM -0400, James Simmons wrote:
> > > > From: Bobi Jam 
> > > > 
> > > > If normal IO got short read/write, we'd restart the IO from where
> > > > we've accomplished until we meet EOF or error happens.
> > > > 
> > > > Signed-off-by: Bobi Jam 
> > > > Signed-off-by: Jinshan Xiong 
> > > > Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6389
> > > > Reviewed-on: http://review.whamcloud.com/14123
> > > > Reviewed-by: Andreas Dilger 
> > > > Reviewed-by: Oleg Drokin 
> > > > Signed-off-by: James Simmons 
> > > > ---
> > > >  drivers/staging/lustre/lnet/libcfs/fail.c  |1 +
> > > >  .../staging/lustre/lustre/include/obd_support.h|2 +
> > > >  drivers/staging/lustre/lustre/llite/file.c |   41 
> > > > 
> > > >  drivers/staging/lustre/lustre/llite/vvp_io.c   |   19 -
> > > >  4 files changed, 45 insertions(+), 18 deletions(-)
> > > 
> > > Due to other changes in the filesystem tree, this patch no longer
> > > applies :(
> > > 
> > > Can you rebase it and resend?
> > 
> > How long will you be accepting patches to merge for? If its going
> > to be a few weeks like to just include the missing two patches with
> > the next batch.
> 
> I don't understand the question.  I always accept patches, no need to
> not send them, I'll queue them up to the proper branches as needed.  So
> what do you mean here?

I had the impression that more complex patches like the ones I have been
sending tend to accepted only at the start of the release cycle and only
simpler patches go into *-rc[3-7] versions. That is why I asked the
above question.
 
> > Another issue I need to look at is the IB changes. That's going to
> > require some heavy surgery to the ko2iblnd driver so its going to
> > take time for me to port this to the new RDMA RW api. That will
> > need to be push to linus so ko2iblnd can work with the 4.9 tree
> > if that is okay with you.
> 
> Sure, send the patches, but maybe it is a 4.10 thing if it's too much
> work?

We can work it out once I have something useful. Thanks.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [patch] Staging: lustre: indent an if statement

[James Simmons]

> This if statement wasn't intended.

Acked-by: James Simmons 
 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c 
> b/drivers/staging/lustre/lustre/obdclass/cl_object.c
> index 3199dd4..a102c36 100644
> --- a/drivers/staging/lustre/lustre/obdclass/cl_object.c
> +++ b/drivers/staging/lustre/lustre/obdclass/cl_object.c
> @@ -335,7 +335,7 @@ int cl_object_getstripe(const struct lu_env *env, struct 
> cl_object *obj,
>   if (obj->co_ops->coo_getstripe) {
>   result = obj->co_ops->coo_getstripe(env, obj, uarg);
>   if (result)
> - break;
> + break;
>   }
>   }
>   return result;
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [bug report] staging: lustre: create striped directory

[James Simmons]

> On Tue, Oct 11, 2016 at 04:14:11PM +, Wang, Di wrote:
> > Hello,
> > 
> > On 10/11/16, 4:37 AM, "Dan Carpenter"  wrote:
> > 
> > >Hello wang di,
> > >
> > >The patch 2de353860782: "staging: lustre: create striped directory"
> > >from Aug 16, 2016, leads to the following static checker warning:
> > >
> > >   drivers/staging/lustre/lustre/llite/namei.c:294 ll_md_blocking_ast()
> > >   warn: 'master_inode' isn't an ERR_PTR
> > >
> > >drivers/staging/lustre/lustre/llite/namei.c
> > >   287  
> > >   288  hash =
> > >cl_fid_build_ino(>lli_pfid,
> > >   289
> > >ll_need_32bit_api(ll_i2sbi(inode)));
> > >   290  
> > >   291  master_inode =
> > >ilookup5(inode->i_sb, hash,
> > >   292
> > >ll_test_inode_by_fid,
> > >   293  (void
> > >*)>lli_pfid);
> > >   294  if (master_inode &&
> > >!IS_ERR(master_inode)) {
> > >  
> > >
> > >ilookup5() never returns ERR_PTRs.
> > 
> > Yes, only master_inode != NULL should be enough here.
> 
> Please send a patch to remove the other check?

A patch is being reviewed and validated with our test harness.
Its coming :-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Tools: hv: recover after hv_vss_daemon freeze times out

[Michael Gissing]

If a FIFREEZE operation run by the hv_vss_daemon takes longer than the
VSS_USERSPACE_TIMEOUT set in the hv_snapshot module, instead of exiting
after a write failure, try to recover by reopening the hv_vss device and
performing the initial handshake again. Exiting causes all subsequent VSS
operations sent by the Hyper-V host to fail until the daemon is restarted.

Signed-off-by: Michael Gissing 

---
 tools/hv/hv_vss_daemon.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 5d51d6f..0ecbdab 100644
--- a/tools/hv/hv_vss_daemon.c
+++ b/tools/hv/hv_vss_daemon.c
@@ -176,6 +176,7 @@ int main(int argc, char *argv[])
 openlog("Hyper-V VSS", 0, LOG_USER);
 syslog(LOG_INFO, "VSS starting; pid is:%d", getpid());

+recover:
 vss_fd = open("/dev/vmbus/hv_vss", O_RDWR);
 if (vss_fd < 0) {
 syslog(LOG_ERR, "open /dev/vmbus/hv_vss failed; error: %d %s",
@@ -196,6 +197,7 @@ int main(int argc, char *argv[])
 }

 pfd.fd = vss_fd;
+in_handshake = 1;

 while (1) {
 pfd.events = POLLIN;
@@ -258,7 +260,14 @@ int main(int argc, char *argv[])
 if (len != sizeof(struct hv_vss_msg)) {
 syslog(LOG_ERR, "write failed; error: %d %s", errno,
strerror(errno));
-exit(EXIT_FAILURE);
+/*
+ * try to recover from possible timeout by THAWing
+ * and restarting the message loop
+*/
+vss_operate(VSS_OP_THAW);
+close(vss_fd);
+syslog(LOG_INFO, "trying to recover VSS connection");
+goto recover;
 }
 }

--
2.7.4


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

my subject

[WESTERN UNION MONEY TRANSFER]

Good Day Beneficiary

I write to inform you that we have been given the mandate to transfer your
full compensation payment of $1,800,000.00 USD via western union by this
government.

We tried to give you the Western Union Instructions through phone, but we
could not locate your numbers in our database to reach you last week even
this morning.

So, I decided to email you the MTCN and Sender Names so that you can pick up
the USD5,000.00 to enable us send another USD5,000.00 by tomorrow as you
knows we will be sending you only USD5,000.00 per day.

Please pick up this information and run to any western union in your country
to pick up the USD5,000.00 and send us email back to send you another
payment tomorrow.

Manager Mrs.Anita Daniel
Email: wtransfermone...@qdwxs.com
email us once you picked up this USD5,000.00 today.
Here is the western union information to pick up the USD5,000.00,
Visit  https://wumt.westernunion.com/asp/orderstatus.asp?
country=globalto verify your pick up.

MTCN : 633-670-6150
Sender's Name: LOPEZ CARLOS
Question: Honest
Answer:Trust
Amount: 5,000.00USD
City:Abuja
Country:Nigeria
Tel:+234-802-138-1209

I am waiting for your email once you pick up USD5,000.00,

Thanks!
Mrs.Anita Daniel
Western Union Online Coordinator

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2] Staging:ks7010:eap_packet: fixed 80 character line limit coding style issue

[Nadim Almas]

Fixed coding style issue

Signed-off-by: Nadim Almas 
---
Changes in v2:
  -Comment is taken from below line.

 drivers/staging/ks7010/eap_packet.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/eap_packet.h 
b/drivers/staging/ks7010/eap_packet.h
index df7f760..90432ff 100644
--- a/drivers/staging/ks7010/eap_packet.h
+++ b/drivers/staging/ks7010/eap_packet.h
@@ -58,11 +58,13 @@ struct ieee802_1x_eapol_key {
 * encrypt the Key field; 64-bit NTP timestamp MAY be used here
 */
unsigned char replay_counter[IEEE8021X_REPLAY_COUNTER_LEN];
-   unsigned char key_iv[IEEE8021X_KEY_IV_LEN]; /* cryptographically 
random number */
+   unsigned char key_iv[IEEE8021X_KEY_IV_LEN];
+   /* cryptographically random number */
unsigned char key_index;/*
 * key flag in the most significant bit:
 * 0 = broadcast (default key),
-* 1 = unicast (key mapping key); key 
index is in the
+* 1 = unicast (key mapping key); key
+* index is in the
 * 7 least significant bits
 */
/*
--
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging:ks7010:eap_packet: fixed 80 character line limit coding style issue

[Greg KH]

Note, the mailing lists reject html email, please fix up your client.

On Fri, Oct 14, 2016 at 12:34:30AM +0530, Nadim Almas wrote:
> But i have seen in some place where comments are below the line
> like in
> here from "drivers/staging/ks7010/eap_packet.h"
>  line number 100
> 
> 
>  struct wpa_eapol_key {
> unsigned char type;
> unsigned short key_info;
> unsigned short key_length;
> unsigned char replay_counter[WPA_REPLAY_COUNTER_LEN];
> unsigned char key_nonce[WPA_NONCE_LEN];
> unsigned char key_iv[16];
> unsigned char key_rsc[8];
> unsigned char key_id[8]; /* Reserved in IEEE 802.11i/RSN */
> unsigned char key_mic[16];
> unsigned short key_data_length;
> /* followed by key_data_length bytes of key_data */
> } __packed;

Read that comment, it makes sense to be there, right?  Because it
describes the field after the one above it.

Thanks for proving my point :)

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging:ks7010:eap_packet: fixed 80 character line limit coding style issue

[Joe Perches]

On Thu, 2016-10-13 at 09:05 -0700, Nadim Almas wrote:
> Fixed coding style issue
> 
> Signed-off-by: Nadim Almas 
> ---
>  drivers/staging/ks7010/eap_packet.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/eap_packet.h 
> b/drivers/staging/ks7010/eap_packet.h
> index df7f760..90432ff 100644
> --- a/drivers/staging/ks7010/eap_packet.h
> +++ b/drivers/staging/ks7010/eap_packet.h
> @@ -58,11 +58,13 @@ struct ieee802_1x_eapol_key {
>* encrypt the Key field; 64-bit NTP timestamp MAY be used here
>*/
>   unsigned char replay_counter[IEEE8021X_REPLAY_COUNTER_LEN];
> - unsigned char key_iv[IEEE8021X_KEY_IV_LEN]; /* cryptographically 
> random number */
> + unsigned char key_iv[IEEE8021X_KEY_IV_LEN];
> + /* cryptographically random number */
>   unsigned char key_index;/*
>* key flag in the most significant bit:
>* 0 = broadcast (default key),
> -  * 1 = unicast (key mapping key); key 
> index is in the
> +  * 1 = unicast (key mapping key); key
> +  * index is in the
>* 7 least significant bits
> 

Might be better as
unsigned char key_index;/* Key flag:
 * Most significant bit:
 * 0: broadcast (default key)
 * 1: unicast (key mapping key)
 *key index is the value of
 *the 7 least significant bits
 */
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change

[Zach Brown]

On Thu, Oct 13, 2016 at 10:46:34AM -0400, David Miller wrote:
> From: Zach Brown 
> Date: Tue, 11 Oct 2016 15:26:20 -0500
> 
> > From: Josh Cartwright 
> > 
> > Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
> > create a set of led triggers for each instantiated PHY device.  There is
> > one LED trigger per link-speed, per-phy.
> > 
> > This allows for a user to configure their system to allow a set of LEDs
> > to represent link state changes on the phy.
> > 
> > Signed-off-by: Josh Cartwright 
> > Signed-off-by: Nathan Sullivan 
> > Signed-off-by: Zach Brown 
>  ...
> > +   static const char * const name_suffix[] = {
> > +   "10Mbps",
> > +   "100Mbps",
> > +   "1Gbps",
> > +   "2.5Gbps",
> > +   "10Gbps",
> 
> This choice of both the array size and the speeds to support seems
> entirely arbitrary and is inappropriate for a generic driver of this
> kind.
> 
> This seems to be hard coding this to support the list of speeds
> supported by whatever driver you want to use with this new LED
> facility, and sorry that's not how we build nice generic pieces of
> infrastructure.
> 
> Thanks.

The speeds listed are the speeds found in the phy_speed_to_str function in 
phy.c.
They are also the speeds found in the struct phy_setting settings array,
which is commented with
"/* A mapping of all SUPPORTED settings to speed/duplex */"
We believed they represented the commonly supported speeds of phys.

Do you have suggestions on how to better handle the choice of the array size
and the speeds?

Thanks.

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: ks7010: Fixes warning :do not add new typedefs

[Sabitha George]

Fixes checkpatch.pl warning: do not add new typedefs in
ks_wlan_net.c

Signed-off-by: Sabitha George 
---
 drivers/staging/ks7010/ks_wlan_net.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c 
b/drivers/staging/ks7010/ks_wlan_net.c
index 84edd3b..7b864c0 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -50,10 +50,10 @@
 /* A few details needed for WEP (Wireless Equivalent Privacy) */
 #define MAX_KEY_SIZE 13/* 128 (?) bits */
 #define MIN_KEY_SIZE  5/* 40 bits RC4 - WEP */
-typedef struct wep_key_t {
+struct wep_key {
u16 len;
u8 key[16]; /* 40-bit and 104-bit keys */
-} wep_key_t;
+};
 
 /* Backward compatibility */
 #ifndef IW_ENCODE_NOKEY
@@ -899,7 +899,7 @@ static int ks_wlan_set_encode(struct net_device *dev,
struct ks_wlan_private *priv =
(struct ks_wlan_private *)netdev_priv(dev);
 
-   wep_key_t key;
+   struct wep_key key;
int index = (dwrq->flags & IW_ENCODE_INDEX);
int current_index = priv->reg.wep_index;
int i;
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: ks7010: Replace __attribute__(aligned(x)) with __aligned(x)

[Sabitha George]

Fixes checkpatch.pl warning: __aligned(size) is preferred over
__attribute__((aligned(size)) in ks7010_sdio.h

Signed-off-by: Sabitha George 
---
 drivers/staging/ks7010/ks7010_sdio.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks7010_sdio.h 
b/drivers/staging/ks7010/ks7010_sdio.h
index c72064b..c89e570 100644
--- a/drivers/staging/ks7010/ks7010_sdio.h
+++ b/drivers/staging/ks7010/ks7010_sdio.h
@@ -100,7 +100,7 @@ struct hw_info_t {
 struct ks_sdio_packet {
struct ks_sdio_packet *next;
u16 nb;
-   u8 buffer[0] __attribute__ ((aligned(4)));
+   u8 buffer[0] __aligned(4);
 };
 
 struct ks_sdio_card {
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Re: [PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

[Joe Perches]

On Thu, 2016-10-13 at 18:49 +0200, Greg KH wrote:
> On Thu, Oct 13, 2016 at 09:37:23AM -0700, Joe Perches wrote:
> > On Thu, 2016-10-13 at 16:57 +0200, Greg KH wrote:
> > > On Thu, Oct 13, 2016 at 05:23:45PM +0300, Mikhail Golubev wrote:
> > > > On Thu, Oct 13, 2016 at 02:06:02PM +0200, Greg KH wrote:
> > > > > On Thu, Oct 13, 2016 at 02:50:18PM +0300, Mikhail Golubev wrote:
> > > > > > Function definitions arguments should also have an identifier name 
> > > > > > as reported by checkpatch.pl.
> > 
> > []
> > > > > > diff --git a/drivers/staging/vt6656/baseband.h 
> > > > > > b/drivers/staging/vt6656/baseband.h
> > 
> > []
> > > > > > @@ -86,15 +86,15 @@ struct vnt_phy_field {
> > > > > >  unsigned int vnt_get_frame_time(u8 preamble_type, u8 pkt_type,
> > > > > > unsigned int frame_length, u16 
> > > > > > tx_rate);p
> > > > > >  
> > > > > > -void vnt_get_phy_field(struct vnt_private *, u32 frame_length,
> > > > > > -  u16 tx_rate, u8 pkt_type, struct vnt_phy_field 
> > > > > > *);
> > > > > > -
> > > > > > -void vnt_set_short_slot_time(struct vnt_private *);
> > > > > > -void vnt_set_vga_gain_offset(struct vnt_private *, u8);
> > > > > > -void vnt_set_antenna_mode(struct vnt_private *, u8);
> > > > > > -int vnt_vt3184_init(struct vnt_private *);
> > > > > > -void vnt_set_deep_sleep(struct vnt_private *);
> > > > > > -void vnt_exit_deep_sleep(struct vnt_private *);
> > > > > > -void vnt_update_pre_ed_threshold(struct vnt_private *, int 
> > > > > > scanning);
> > > > > > +void vnt_get_phy_field(struct vnt_private *priv, u32 frame_length,
> > > > > > +  u16 tx_rate, u8 pkt_type, struct vnt_phy_field 
> > > > > > *phy);
> > > > > > +
> > > > > 
> > > > > Really?  Since when is this a coding style requirement?
> > > > 
> > > > This requirement is really new. It was proposed by Joe Perches at 26 
> > > > Sep 2016:
> > > > [PATCH] checkpatch: Add warning for unnamed function definition.
> > > > 
> > > > Should this type of warnings be fixed here?
> > > 
> > > Ugh, Joe, why did you add this option?
> > 
> > 
> > 1. Most all kernel prototypes use named arguments.
> > 2. It helps make header files easier to read/lookup with grep.
> > 
> > int func(int, int, int)
> > vs
> > int func(int weight, int density, int mass)
> > 
> > which is easier for humans to use?
> 
> 
> Yes, which is why I use that format, but is it something we are now
> going to suddenly require?
> 
> Also, this is going to take a lot more work to review patches like this,
> to match up the variable names to ensure that the developer got it
> right...

Coccinelle to the rescue...

http://www.spinics.net/lists/linux-kernel-janitors/msg28450.html

Julia Lawall wrote a script for that.
Unfortunately, it doesn't currently span .h and .c files

---

@r@
identifier f;
position p;
type T, t;
parameter list[n] ps;
@@

T f@p(ps,t,...);

@s@
identifier r.f,x;
type r.T, r.t;
parameter list[r.n] ps;
@@

T f(ps,t x,...) { ... }

@@
identifier r.f, s.x;
position r.p;
type r.T, r.t;
parameter list[r.n] ps;
@@

T f@p(ps,t
+ x
  ,...);


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Re: [PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

[Greg KH]

On Thu, Oct 13, 2016 at 09:37:23AM -0700, Joe Perches wrote:
> On Thu, 2016-10-13 at 16:57 +0200, Greg KH wrote:
> > On Thu, Oct 13, 2016 at 05:23:45PM +0300, Mikhail Golubev wrote:
> > > On Thu, Oct 13, 2016 at 02:06:02PM +0200, Greg KH wrote:
> > > > On Thu, Oct 13, 2016 at 02:50:18PM +0300, Mikhail Golubev wrote:
> > > > > Function definitions arguments should also have an identifier name as 
> > > > > reported by checkpatch.pl.
> []
> > > > > diff --git a/drivers/staging/vt6656/baseband.h 
> > > > > b/drivers/staging/vt6656/baseband.h
> []
> > > > > @@ -86,15 +86,15 @@ struct vnt_phy_field {
> > > > >  unsigned int vnt_get_frame_time(u8 preamble_type, u8 pkt_type,
> > > > >   unsigned int frame_length, u16 
> > > > > tx_rate);p
> > > > >  
> > > > > -void vnt_get_phy_field(struct vnt_private *, u32 frame_length,
> > > > > -u16 tx_rate, u8 pkt_type, struct vnt_phy_field 
> > > > > *);
> > > > > -
> > > > > -void vnt_set_short_slot_time(struct vnt_private *);
> > > > > -void vnt_set_vga_gain_offset(struct vnt_private *, u8);
> > > > > -void vnt_set_antenna_mode(struct vnt_private *, u8);
> > > > > -int vnt_vt3184_init(struct vnt_private *);
> > > > > -void vnt_set_deep_sleep(struct vnt_private *);
> > > > > -void vnt_exit_deep_sleep(struct vnt_private *);
> > > > > -void vnt_update_pre_ed_threshold(struct vnt_private *, int scanning);
> > > > > +void vnt_get_phy_field(struct vnt_private *priv, u32 frame_length,
> > > > > +u16 tx_rate, u8 pkt_type, struct vnt_phy_field 
> > > > > *phy);
> > > > > +
> > > > Really?  Since when is this a coding style requirement?
> > > This requirement is really new. It was proposed by Joe Perches at 26 Sep 
> > > 2016:
> > > [PATCH] checkpatch: Add warning for unnamed function definition.
> > > 
> > > Should this type of warnings be fixed here?
> > Ugh, Joe, why did you add this option?
> 
> 1. Most all kernel prototypes use named arguments.
> 2. It helps make header files easier to read/lookup with grep.
> 
> int func(int, int, int)
> vs
> int func(int weight, int density, int mass)
> 
> which is easier for humans to use?

Yes, which is why I use that format, but is it something we are now
going to suddenly require?

Also, this is going to take a lot more work to review patches like this,
to match up the variable names to ensure that the developer got it
right...

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change

[Andrew Lunn]

> Do you have suggestions on how to better handle the choice of the array size
> and the speeds?

phydev->supported lists the speeds this phy supports.

Andrew
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Re: [PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

[Joe Perches]

On Thu, 2016-10-13 at 16:57 +0200, Greg KH wrote:
> On Thu, Oct 13, 2016 at 05:23:45PM +0300, Mikhail Golubev wrote:
> > On Thu, Oct 13, 2016 at 02:06:02PM +0200, Greg KH wrote:
> > > On Thu, Oct 13, 2016 at 02:50:18PM +0300, Mikhail Golubev wrote:
> > > > Function definitions arguments should also have an identifier name as 
> > > > reported by checkpatch.pl.
[]
> > > > diff --git a/drivers/staging/vt6656/baseband.h 
> > > > b/drivers/staging/vt6656/baseband.h
[]
> > > > @@ -86,15 +86,15 @@ struct vnt_phy_field {
> > > >  unsigned int vnt_get_frame_time(u8 preamble_type, u8 pkt_type,
> > > > unsigned int frame_length, u16 
> > > > tx_rate);p
> > > >  
> > > > -void vnt_get_phy_field(struct vnt_private *, u32 frame_length,
> > > > -  u16 tx_rate, u8 pkt_type, struct vnt_phy_field 
> > > > *);
> > > > -
> > > > -void vnt_set_short_slot_time(struct vnt_private *);
> > > > -void vnt_set_vga_gain_offset(struct vnt_private *, u8);
> > > > -void vnt_set_antenna_mode(struct vnt_private *, u8);
> > > > -int vnt_vt3184_init(struct vnt_private *);
> > > > -void vnt_set_deep_sleep(struct vnt_private *);
> > > > -void vnt_exit_deep_sleep(struct vnt_private *);
> > > > -void vnt_update_pre_ed_threshold(struct vnt_private *, int scanning);
> > > > +void vnt_get_phy_field(struct vnt_private *priv, u32 frame_length,
> > > > +  u16 tx_rate, u8 pkt_type, struct vnt_phy_field 
> > > > *phy);
> > > > +
> > > Really?  Since when is this a coding style requirement?
> > This requirement is really new. It was proposed by Joe Perches at 26 Sep 
> > 2016:
> > [PATCH] checkpatch: Add warning for unnamed function definition.
> > 
> > Should this type of warnings be fixed here?
> Ugh, Joe, why did you add this option?

1. Most all kernel prototypes use named arguments.
2. It helps make header files easier to read/lookup with grep.

int func(int, int, int)
vs
int func(int weight, int density, int mass)

which is easier for humans to use?

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging:ks7010:eap_packet: fixed 80 character line limit coding style issue

[Greg KH]

On Thu, Oct 13, 2016 at 09:05:57AM -0700, Nadim Almas wrote:
> Fixed coding style issue
> 
> Signed-off-by: Nadim Almas 
> ---
>  drivers/staging/ks7010/eap_packet.h | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/ks7010/eap_packet.h 
> b/drivers/staging/ks7010/eap_packet.h
> index df7f760..90432ff 100644
> --- a/drivers/staging/ks7010/eap_packet.h
> +++ b/drivers/staging/ks7010/eap_packet.h
> @@ -58,11 +58,13 @@ struct ieee802_1x_eapol_key {
>* encrypt the Key field; 64-bit NTP timestamp MAY be used here
>*/
>   unsigned char replay_counter[IEEE8021X_REPLAY_COUNTER_LEN];
> - unsigned char key_iv[IEEE8021X_KEY_IV_LEN]; /* cryptographically 
> random number */
> + unsigned char key_iv[IEEE8021X_KEY_IV_LEN];
> + /* cryptographically random number */

Comment below the line?  That's not how you read code :(
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Staging:ks7010:eap_packet: fixed 80 character line limit coding style issue

[Nadim Almas]

Fixed coding style issue

Signed-off-by: Nadim Almas 
---
 drivers/staging/ks7010/eap_packet.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/eap_packet.h 
b/drivers/staging/ks7010/eap_packet.h
index df7f760..90432ff 100644
--- a/drivers/staging/ks7010/eap_packet.h
+++ b/drivers/staging/ks7010/eap_packet.h
@@ -58,11 +58,13 @@ struct ieee802_1x_eapol_key {
 * encrypt the Key field; 64-bit NTP timestamp MAY be used here
 */
unsigned char replay_counter[IEEE8021X_REPLAY_COUNTER_LEN];
-   unsigned char key_iv[IEEE8021X_KEY_IV_LEN]; /* cryptographically 
random number */
+   unsigned char key_iv[IEEE8021X_KEY_IV_LEN];
+   /* cryptographically random number */
unsigned char key_index;/*
 * key flag in the most significant bit:
 * 0 = broadcast (default key),
-* 1 = unicast (key mapping key); key 
index is in the
+* 1 = unicast (key mapping key); key
+* index is in the
 * 7 least significant bits
 */
/*
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change

[David Miller]

From: Zach Brown 
Date: Thu, 13 Oct 2016 10:42:46 -0500

> Do you have suggestions on how to better handle the choice of the array size
> and the speeds?

All of the speed values are simply the rate in bits per second.

There is therefore no reason you can't just print the raw value and
scale it to whatever is appropriate ("MB/s", "GB/s", etc.)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Re: [PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

[Greg KH]

On Thu, Oct 13, 2016 at 05:23:45PM +0300, Mikhail Golubev wrote:
> On Thu, Oct 13, 2016 at 02:06:02PM +0200, Greg KH wrote:
> > On Thu, Oct 13, 2016 at 02:50:18PM +0300, Mikhail Golubev wrote:
> > > Function definitions arguments should also have an identifier name as 
> > > reported by checkpatch.pl.
> > 
> > Please wrap your changelog comments at 72 columns.
> > 
> > > 
> > > Signed-off-by: Mikhail Golubev 
> > > ---
> > >  drivers/staging/vt6656/baseband.h | 20 ++--
> > >  1 file changed, 10 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/staging/vt6656/baseband.h 
> > > b/drivers/staging/vt6656/baseband.h
> > > index 7cc1387..fe1c25c 100644
> > > --- a/drivers/staging/vt6656/baseband.h
> > > +++ b/drivers/staging/vt6656/baseband.h
> > > @@ -86,15 +86,15 @@ struct vnt_phy_field {
> > >  unsigned int vnt_get_frame_time(u8 preamble_type, u8 pkt_type,
> > >   unsigned int frame_length, u16 tx_rate);
> > >  
> > > -void vnt_get_phy_field(struct vnt_private *, u32 frame_length,
> > > -u16 tx_rate, u8 pkt_type, struct vnt_phy_field *);
> > > -
> > > -void vnt_set_short_slot_time(struct vnt_private *);
> > > -void vnt_set_vga_gain_offset(struct vnt_private *, u8);
> > > -void vnt_set_antenna_mode(struct vnt_private *, u8);
> > > -int vnt_vt3184_init(struct vnt_private *);
> > > -void vnt_set_deep_sleep(struct vnt_private *);
> > > -void vnt_exit_deep_sleep(struct vnt_private *);
> > > -void vnt_update_pre_ed_threshold(struct vnt_private *, int scanning);
> > > +void vnt_get_phy_field(struct vnt_private *priv, u32 frame_length,
> > > +u16 tx_rate, u8 pkt_type, struct vnt_phy_field *phy);
> > > +
> > 
> > Really?  Since when is this a coding style requirement?
> > 
> 
> This requirement is really new. It was proposed by Joe Perches at 26 Sep 2016:
> [PATCH] checkpatch: Add warning for unnamed function definition.
> 
> Should this type of warnings be fixed here?

Ugh, Joe, why did you add this option?

What is it going to help out with?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 3/3] net: phy: leds: add support for led triggers on phy link state change

[David Miller]

From: Zach Brown 
Date: Tue, 11 Oct 2016 15:26:20 -0500

> From: Josh Cartwright 
> 
> Create an option CONFIG_LED_TRIGGER_PHY (default n), which will
> create a set of led triggers for each instantiated PHY device.  There is
> one LED trigger per link-speed, per-phy.
> 
> This allows for a user to configure their system to allow a set of LEDs
> to represent link state changes on the phy.
> 
> Signed-off-by: Josh Cartwright 
> Signed-off-by: Nathan Sullivan 
> Signed-off-by: Zach Brown 
 ...
> + static const char * const name_suffix[] = {
> + "10Mbps",
> + "100Mbps",
> + "1Gbps",
> + "2.5Gbps",
> + "10Gbps",

This choice of both the array size and the speeds to support seems
entirely arbitrary and is inappropriate for a generic driver of this
kind.

This seems to be hard coding this to support the list of speeds
supported by whatever driver you want to use with this new LED
facility, and sorry that's not how we build nice generic pieces of
infrastructure.

Thanks.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: sm750fb: Fix printk() style warning

[Mike Rapoport]

On Mon, Oct 10, 2016 at 07:31:46AM -0700, Edward Lipinsky wrote:
> 
> Thanks, that makes sense.  I tried deleting the if statement and printk()
> from ddk750_help.c, and adding the following in lynxfb_pci_probe() after
> calling hw_sm750_map() and checking for errors:
> 
> if (sm750_dev->revid == 0xfe)
>   dev_info(>dev, "found sm750le\n");
> 
> The driver compiles, loads and unloads ok with this code.
> 
> Does this look correct?

Yep, seems just right.
 
> Regards,
> Ed L.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Re: [PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

[Mikhail Golubev]

On Thu, Oct 13, 2016 at 02:06:02PM +0200, Greg KH wrote:
> On Thu, Oct 13, 2016 at 02:50:18PM +0300, Mikhail Golubev wrote:
> > Function definitions arguments should also have an identifier name as 
> > reported by checkpatch.pl.
> 
> Please wrap your changelog comments at 72 columns.
> 
> > 
> > Signed-off-by: Mikhail Golubev 
> > ---
> >  drivers/staging/vt6656/baseband.h | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/staging/vt6656/baseband.h 
> > b/drivers/staging/vt6656/baseband.h
> > index 7cc1387..fe1c25c 100644
> > --- a/drivers/staging/vt6656/baseband.h
> > +++ b/drivers/staging/vt6656/baseband.h
> > @@ -86,15 +86,15 @@ struct vnt_phy_field {
> >  unsigned int vnt_get_frame_time(u8 preamble_type, u8 pkt_type,
> > unsigned int frame_length, u16 tx_rate);
> >  
> > -void vnt_get_phy_field(struct vnt_private *, u32 frame_length,
> > -  u16 tx_rate, u8 pkt_type, struct vnt_phy_field *);
> > -
> > -void vnt_set_short_slot_time(struct vnt_private *);
> > -void vnt_set_vga_gain_offset(struct vnt_private *, u8);
> > -void vnt_set_antenna_mode(struct vnt_private *, u8);
> > -int vnt_vt3184_init(struct vnt_private *);
> > -void vnt_set_deep_sleep(struct vnt_private *);
> > -void vnt_exit_deep_sleep(struct vnt_private *);
> > -void vnt_update_pre_ed_threshold(struct vnt_private *, int scanning);
> > +void vnt_get_phy_field(struct vnt_private *priv, u32 frame_length,
> > +  u16 tx_rate, u8 pkt_type, struct vnt_phy_field *phy);
> > +
> 
> Really?  Since when is this a coding style requirement?
> 

This requirement is really new. It was proposed by Joe Perches at 26 Sep 2016:
[PATCH] checkpatch: Add warning for unnamed function definition.

Should this type of warnings be fixed here?

> Don't use --strict, it's not worth it for stuff like this, there are far
> worse-off files in drivers/staging/ than this one.
> 
> thanks,
> 
> greg k-h

Best wishes,
Mike.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] [media] s5p_cec: Mark runtime suspend/resume as __maybe_unused

[Geert Uytterhoeven]

If CONFIG_PM_SLEEP=n:

drivers/staging/media/s5p-cec/s5p_cec.c:235: warning: 
‘s5p_cec_runtime_suspend’ defined but not used
drivers/staging/media/s5p-cec/s5p_cec.c:243: warning: 
‘s5p_cec_runtime_resume’ defined but not used

Mark these functions as__maybe_unused to fix this without introducing
an #ifdef.

Fixes: 57b978ada073106d ("[media] s5p-cec: fix system and runtime PM 
integration")
Signed-off-by: Geert Uytterhoeven 
---
The above commit didn't take into account Arnd's previous fix...

 drivers/staging/media/s5p-cec/s5p_cec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c 
b/drivers/staging/media/s5p-cec/s5p_cec.c
index 1780a08b73c96193..58d7562311360b7f 100644
--- a/drivers/staging/media/s5p-cec/s5p_cec.c
+++ b/drivers/staging/media/s5p-cec/s5p_cec.c
@@ -231,7 +231,7 @@ static int s5p_cec_remove(struct platform_device *pdev)
return 0;
 }
 
-static int s5p_cec_runtime_suspend(struct device *dev)
+static int __maybe_unused s5p_cec_runtime_suspend(struct device *dev)
 {
struct s5p_cec_dev *cec = dev_get_drvdata(dev);
 
@@ -239,7 +239,7 @@ static int s5p_cec_runtime_suspend(struct device *dev)
return 0;
 }
 
-static int s5p_cec_runtime_resume(struct device *dev)
+static int __maybe_unused s5p_cec_runtime_resume(struct device *dev)
 {
struct s5p_cec_dev *cec = dev_get_drvdata(dev);
int ret;
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] Staging: greybus: gpio: Use gbphy_dev->dev instead of bundle->dev

[Rui Miguel Silva]

Hi Viresh,
On Wed, Oct 12, 2016 at 08:02:21AM +0530, Viresh Kumar wrote:

Some of the print messages are using the incorrect device pointer, fix
them.

Signed-off-by: Viresh Kumar 


Reviewed-by: Rui Miguel Silva 

Thanks,
  Rui

---
drivers/staging/greybus/gpio.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/greybus/gpio.c b/drivers/staging/greybus/gpio.c
index 5e06e4229e42..250caa00de5e 100644
--- a/drivers/staging/greybus/gpio.c
+++ b/drivers/staging/greybus/gpio.c
@@ -702,15 +702,13 @@ static int gb_gpio_probe(struct gbphy_device *gbphy_dev,
ret = gb_gpio_irqchip_add(gpio, irqc, 0,
   handle_level_irq, IRQ_TYPE_NONE);
if (ret) {
-   dev_err(>bundle->dev,
-   "failed to add irq chip: %d\n", ret);
+   dev_err(_dev->dev, "failed to add irq chip: %d\n", ret);
goto exit_line_free;
}

ret = gpiochip_add(gpio);
if (ret) {
-   dev_err(>bundle->dev,
-   "failed to add gpio chip: %d\n", ret);
+   dev_err(_dev->dev, "failed to add gpio chip: %d\n", ret);
goto exit_gpio_irqchip_remove;
}

--
2.7.1.410.g6faf27b


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[patch v2] staging: android: ion: Fix error handling in ion_query_heaps()

[Dan Carpenter]

If the copy_to_user() fails we should unlock and return directly without
updating "cnt".  Also the return value should be -EFAULT instead of the
number of bytes remaining.

Fixes: 02b23803c6af ("staging: android: ion: Add ioctl to query available 
heaps")
Signed-off-by: Dan Carpenter 
---
v2: a more complete fix

diff --git a/drivers/staging/android/ion/ion.c 
b/drivers/staging/android/ion/ion.c
index 396ded5..209a8f7 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -1187,8 +1187,10 @@ int ion_query_heaps(struct ion_client *client, struct 
ion_heap_query *query)
hdata.type = heap->type;
hdata.heap_id = heap->id;
 
-   ret = copy_to_user([cnt],
-  , sizeof(hdata));
+   if (copy_to_user([cnt], , sizeof(hdata))) {
+   ret = -EFAULT;
+   goto out;
+   }
 
cnt++;
if (cnt >= max_cnt)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

[Greg KH]

On Thu, Oct 13, 2016 at 02:50:18PM +0300, Mikhail Golubev wrote:
> Function definitions arguments should also have an identifier name as 
> reported by checkpatch.pl.

Please wrap your changelog comments at 72 columns.

> 
> Signed-off-by: Mikhail Golubev 
> ---
>  drivers/staging/vt6656/baseband.h | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/staging/vt6656/baseband.h 
> b/drivers/staging/vt6656/baseband.h
> index 7cc1387..fe1c25c 100644
> --- a/drivers/staging/vt6656/baseband.h
> +++ b/drivers/staging/vt6656/baseband.h
> @@ -86,15 +86,15 @@ struct vnt_phy_field {
>  unsigned int vnt_get_frame_time(u8 preamble_type, u8 pkt_type,
>   unsigned int frame_length, u16 tx_rate);
>  
> -void vnt_get_phy_field(struct vnt_private *, u32 frame_length,
> -u16 tx_rate, u8 pkt_type, struct vnt_phy_field *);
> -
> -void vnt_set_short_slot_time(struct vnt_private *);
> -void vnt_set_vga_gain_offset(struct vnt_private *, u8);
> -void vnt_set_antenna_mode(struct vnt_private *, u8);
> -int vnt_vt3184_init(struct vnt_private *);
> -void vnt_set_deep_sleep(struct vnt_private *);
> -void vnt_exit_deep_sleep(struct vnt_private *);
> -void vnt_update_pre_ed_threshold(struct vnt_private *, int scanning);
> +void vnt_get_phy_field(struct vnt_private *priv, u32 frame_length,
> +u16 tx_rate, u8 pkt_type, struct vnt_phy_field *phy);
> +

Really?  Since when is this a coding style requirement?

Don't use --strict, it's not worth it for stuff like this, there are far
worse-off files in drivers/staging/ than this one.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging:vt6656:baseband.h: fix function definition argument without identifier name issue

[Mikhail Golubev]

Function definitions arguments should also have an identifier name as reported 
by checkpatch.pl.

Signed-off-by: Mikhail Golubev 
---
 drivers/staging/vt6656/baseband.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/vt6656/baseband.h 
b/drivers/staging/vt6656/baseband.h
index 7cc1387..fe1c25c 100644
--- a/drivers/staging/vt6656/baseband.h
+++ b/drivers/staging/vt6656/baseband.h
@@ -86,15 +86,15 @@ struct vnt_phy_field {
 unsigned int vnt_get_frame_time(u8 preamble_type, u8 pkt_type,
unsigned int frame_length, u16 tx_rate);
 
-void vnt_get_phy_field(struct vnt_private *, u32 frame_length,
-  u16 tx_rate, u8 pkt_type, struct vnt_phy_field *);
-
-void vnt_set_short_slot_time(struct vnt_private *);
-void vnt_set_vga_gain_offset(struct vnt_private *, u8);
-void vnt_set_antenna_mode(struct vnt_private *, u8);
-int vnt_vt3184_init(struct vnt_private *);
-void vnt_set_deep_sleep(struct vnt_private *);
-void vnt_exit_deep_sleep(struct vnt_private *);
-void vnt_update_pre_ed_threshold(struct vnt_private *, int scanning);
+void vnt_get_phy_field(struct vnt_private *priv, u32 frame_length,
+  u16 tx_rate, u8 pkt_type, struct vnt_phy_field *phy);
+
+void vnt_set_short_slot_time(struct vnt_private *priv);
+void vnt_set_vga_gain_offset(struct vnt_private *priv, u8 data);
+void vnt_set_antenna_mode(struct vnt_private *priv, u8 antenna_mode);
+int vnt_vt3184_init(struct vnt_private *priv);
+void vnt_set_deep_sleep(struct vnt_private *priv);
+void vnt_exit_deep_sleep(struct vnt_private *priv);
+void vnt_update_pre_ed_threshold(struct vnt_private *priv, int scanning);
 
 #endif /* __BASEBAND_H__ */
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v1 00/28] x86: Secure Encrypted Virtualization (AMD)

[Paolo Bonzini]

On 23/08/2016 01:23, Brijesh Singh wrote:
> TODO:
> - send qemu/seabios RFC's on respective mailing list
> - integrate the psp driver with CCP driver (they share the PCI id's)
> - add SEV guest migration command support
> - add SEV snapshotting command support
> - determine how to do ioremap of physical memory with mem encryption enabled
>   (e.g acpi tables)

The would be encrypted, right?  Similar to the EFI data in patch 9.

> - determine how to share the guest memory with hypervisor for to support
>   pvclock driver

Is it enough if the guest makes that page unencrypted?

I reviewed the KVM host-side patches and they are pretty
straightforward, so the comments on each patch suffice.

Thanks,

Paolo

> Brijesh Singh (11):
>   crypto: add AMD Platform Security Processor driver
>   KVM: SVM: prepare to reserve asid for SEV guest
>   KVM: SVM: prepare for SEV guest management API support
>   KVM: introduce KVM_SEV_ISSUE_CMD ioctl
>   KVM: SVM: add SEV launch start command
>   KVM: SVM: add SEV launch update command
>   KVM: SVM: add SEV_LAUNCH_FINISH command
>   KVM: SVM: add KVM_SEV_GUEST_STATUS command
>   KVM: SVM: add KVM_SEV_DEBUG_DECRYPT command
>   KVM: SVM: add KVM_SEV_DEBUG_ENCRYPT command
>   KVM: SVM: add command to query SEV API version
> 
> Tom Lendacky (17):
>   kvm: svm: Add support for additional SVM NPF error codes
>   kvm: svm: Add kvm_fast_pio_in support
>   kvm: svm: Use the hardware provided GPA instead of page walk
>   x86: Secure Encrypted Virtualization (SEV) support
>   KVM: SVM: prepare for new bit definition in nested_ctl
>   KVM: SVM: Add SEV feature definitions to KVM
>   x86: Do not encrypt memory areas if SEV is enabled
>   Access BOOT related data encrypted with SEV active
>   x86/efi: Access EFI data as encrypted when SEV is active
>   x86: Change early_ioremap to early_memremap for BOOT data
>   x86: Don't decrypt trampoline area if SEV is active
>   x86: DMA support for SEV memory encryption
>   iommu/amd: AMD IOMMU support for SEV
>   x86: Don't set the SME MSR bit when SEV is active
>   x86: Unroll string I/O when SEV is active
>   x86: Add support to determine if running with SEV enabled
>   KVM: SVM: Enable SEV by setting the SEV_ENABLE cpu feature
> 
> 
>  arch/x86/boot/compressed/Makefile  |2 
>  arch/x86/boot/compressed/head_64.S |   19 +
>  arch/x86/boot/compressed/mem_encrypt.S |  123 
>  arch/x86/include/asm/io.h  |   26 +
>  arch/x86/include/asm/kvm_emulate.h |3 
>  arch/x86/include/asm/kvm_host.h|   27 +
>  arch/x86/include/asm/mem_encrypt.h |3 
>  arch/x86/include/asm/svm.h |3 
>  arch/x86/include/uapi/asm/hyperv.h |4 
>  arch/x86/include/uapi/asm/kvm_para.h   |4 
>  arch/x86/kernel/acpi/boot.c|4 
>  arch/x86/kernel/head64.c   |4 
>  arch/x86/kernel/mem_encrypt.S  |   44 ++
>  arch/x86/kernel/mpparse.c  |   10 
>  arch/x86/kernel/setup.c|7 
>  arch/x86/kernel/x8664_ksyms_64.c   |1 
>  arch/x86/kvm/cpuid.c   |4 
>  arch/x86/kvm/mmu.c |   20 +
>  arch/x86/kvm/svm.c |  906 
> 
>  arch/x86/kvm/x86.c |   73 +++
>  arch/x86/mm/ioremap.c  |7 
>  arch/x86/mm/mem_encrypt.c  |   50 ++
>  arch/x86/platform/efi/efi_64.c |   14 
>  arch/x86/realmode/init.c   |   11 
>  drivers/crypto/Kconfig |   11 
>  drivers/crypto/Makefile|1 
>  drivers/crypto/psp/Kconfig |8 
>  drivers/crypto/psp/Makefile|3 
>  drivers/crypto/psp/psp-dev.c   |  220 
>  drivers/crypto/psp/psp-dev.h   |   95 +++
>  drivers/crypto/psp/psp-ops.c   |  454 
>  drivers/crypto/psp/psp-pci.c   |  376 +
>  drivers/sfi/sfi_core.c |6 
>  include/linux/ccp-psp.h|  833 +
>  include/uapi/linux/Kbuild  |1 
>  include/uapi/linux/ccp-psp.h   |  182 ++
>  include/uapi/linux/kvm.h   |  125 
>  37 files changed, 3643 insertions(+), 41 deletions(-)
>  create mode 100644 arch/x86/boot/compressed/mem_encrypt.S
>  create mode 100644 drivers/crypto/psp/Kconfig
>  create mode 100644 drivers/crypto/psp/Makefile
>  create mode 100644 drivers/crypto/psp/psp-dev.c
>  create mode 100644 drivers/crypto/psp/psp-dev.h
>  create mode 100644 drivers/crypto/psp/psp-ops.c
>  create mode 100644 drivers/crypto/psp/psp-pci.c
>  create mode 100644 include/linux/ccp-psp.h
>  create mode 100644 include/uapi/linux/ccp-psp.h
> 
___
devel mailing list
de...@linuxdriverproject.org

Re: [RFC PATCH v1 24/28] KVM: SVM: add SEV_LAUNCH_FINISH command

[Paolo Bonzini]

On 23/08/2016 01:28, Brijesh Singh wrote:
> +
> + /* Iterate through each vcpus and set SEV KVM_SEV_FEATURE bit in
> +  * KVM_CPUID_FEATURE to indicate that SEV is enabled on this vcpu
> +  */
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + svm_cpuid_update(vcpu);
> +

Do you need another call to sev_init_vmcb here?

Paolo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v1 22/28] KVM: SVM: add SEV launch start command

[Paolo Bonzini]

On 23/08/2016 01:28, Brijesh Singh wrote:
> +static int sev_launch_start(struct kvm *kvm,
> + struct kvm_sev_launch_start __user *arg,
> + int *psp_ret)
> +{
> + int ret, asid;
> + struct kvm_sev_launch_start params;
> + struct psp_data_launch_start *start;
> +
> + /* Get parameter from the user */
> + if (copy_from_user(, arg, sizeof(*arg)))
> + return -EFAULT;
> +
> + start = kzalloc(sizeof(*start), GFP_KERNEL);
> + if (!start)
> + return -ENOMEM;
> +
> + ret = sev_pre_start(kvm, );

You need some locking in sev_asid_{new,free}.  Probably _lock.  The
SEV_ISSUE_CMD ioctl instead should take >lock.

Paolo

> + if (ret)
> + goto err_1;
> +
> + start->hdr.buffer_len = sizeof(*start);
> + start->flags  = params.flags;
> + start->policy = params.policy;
> + start->handle = params.handle;
> + memcpy(start->nonce, , sizeof(start->nonce));
> + memcpy(start->dh_pub_qx, _pub_qx, sizeof(start->dh_pub_qx));
> + memcpy(start->dh_pub_qy, _pub_qy, sizeof(start->dh_pub_qy));
> +
> + /* launch start */
> + ret = psp_guest_launch_start(start, psp_ret);
> + if (ret) {
> + printk(KERN_ERR "SEV: LAUNCH_START ret=%d (%#010x)\n",
> + ret, *psp_ret);
> + goto err_2;
> + }
> +
> + ret = sev_post_start(kvm, asid, start->handle, psp_ret);
> + if (ret)
> + goto err_2;

Paolo

> + kfree(start);
> + return 0;
> +
> +err_2:
> + sev_asid_free(asid);
> +err_1:
> + kfree(start);
> + return ret;
> +}
> +
> +static int amd_sev_issue_cmd(struct kvm *kvm,
> +  struct kvm_sev_issue_cmd __user *user_data)
> +{
> + int r = -ENOTTY;
> + struct kvm_sev_issue_cmd arg;
> +
> + if (copy_from_user(, user_data, sizeof(struct kvm_sev_issue_cmd)))
> + return -EFAULT;
> +
> + switch (arg.cmd) {
> + case KVM_SEV_LAUNCH_START: {
> + r = sev_launch_start(kvm, (void *)arg.opaque,
> + _code);
> + break;
> + }
> + default:
> + break;
> + }
> +
> + if (copy_to_user(user_data, , sizeof(struct kvm_sev_issue_cmd)))
> + r = -EFAULT;
> + return r;
> +}
> +
>  static struct kvm_x86_ops svm_x86_ops __ro_after_init = {
>   .cpu_has_kvm_support = has_svm,
>   .disabled_by_bios = is_disabled,
> @@ -5313,6 +5517,8 @@ static struct kvm_x86_ops svm_x86_ops __ro_after_init = 
> {
>  
>   .pmu_ops = _pmu_ops,
>   .deliver_posted_interrupt = svm_deliver_avic_intr,
> +
> + .sev_issue_cmd = amd_sev_issue_cmd,
>  };
>  
>  static int __init svm_init(void)
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v1 21/28] KVM: introduce KVM_SEV_ISSUE_CMD ioctl

[Paolo Bonzini]

On 23/08/2016 01:28, Brijesh Singh wrote:
> The ioctl will be used by qemu to issue the Secure Encrypted
> Virtualization (SEV) guest commands to transition a guest into
> into SEV-enabled mode.
> 
> a typical usage:
> 
> struct kvm_sev_launch_start start;
> struct kvm_sev_issue_cmd data;
> 
> data.cmd = KVM_SEV_LAUNCH_START;
> data.opaque = 
> 
> ret = ioctl(fd, KVM_SEV_ISSUE_CMD, );
> 
> On SEV command failure, data.ret_code will contain the firmware error code.

Please modify the ioctl to require the file descriptor for the PSP.  A
program without access to /dev/psp should not be able to use SEV.

> Signed-off-by: Brijesh Singh 
> ---
>  arch/x86/include/asm/kvm_host.h |3 +
>  arch/x86/kvm/x86.c  |   13 
>  include/uapi/linux/kvm.h|  125 
> +++
>  3 files changed, 141 insertions(+)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 9b885fc..a94e37d 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1040,6 +1040,9 @@ struct kvm_x86_ops {
>   void (*cancel_hv_timer)(struct kvm_vcpu *vcpu);
>  
>   void (*setup_mce)(struct kvm_vcpu *vcpu);
> +
> + int (*sev_issue_cmd)(struct kvm *kvm,
> +  struct kvm_sev_issue_cmd __user *argp);
>  };
>  
>  struct kvm_arch_async_pf {
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index d6f2f4b..0c0adad 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3820,6 +3820,15 @@ split_irqchip_unlock:
>   return r;
>  }
>  
> +static int kvm_vm_ioctl_sev_issue_cmd(struct kvm *kvm,
> +   struct kvm_sev_issue_cmd __user *argp)
> +{
> + if (kvm_x86_ops->sev_issue_cmd)
> + return kvm_x86_ops->sev_issue_cmd(kvm, argp);
> +
> + return -ENOTTY;
> +}

Please make a more generic vm_ioctl callback.

>  long kvm_arch_vm_ioctl(struct file *filp,
>  unsigned int ioctl, unsigned long arg)
>  {
> @@ -4085,6 +4094,10 @@ long kvm_arch_vm_ioctl(struct file *filp,
>   r = kvm_vm_ioctl_enable_cap(kvm, );
>   break;
>   }
> + case KVM_SEV_ISSUE_CMD: {
> + r = kvm_vm_ioctl_sev_issue_cmd(kvm, argp);
> + break;
> + }
>   default:
>   r = kvm_vm_ioctl_assigned_device(kvm, ioctl, arg);
>   }
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 300ef25..72c18c3 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1274,6 +1274,131 @@ struct kvm_s390_ucas_mapping {
>  /* Available with KVM_CAP_X86_SMM */
>  #define KVM_SMI   _IO(KVMIO,   0xb7)
>  
> +/* Secure Encrypted Virtualization mode */
> +enum sev_cmd {
> + KVM_SEV_LAUNCH_START = 0,
> + KVM_SEV_LAUNCH_UPDATE,
> + KVM_SEV_LAUNCH_FINISH,
> + KVM_SEV_GUEST_STATUS,
> + KVM_SEV_DBG_DECRYPT,
> + KVM_SEV_DBG_ENCRYPT,
> + KVM_SEV_RECEIVE_START,
> + KVM_SEV_RECEIVE_UPDATE,
> + KVM_SEV_RECEIVE_FINISH,
> + KVM_SEV_SEND_START,
> + KVM_SEV_SEND_UPDATE,
> + KVM_SEV_SEND_FINISH,
> + KVM_SEV_API_VERSION,
> + KVM_SEV_NR_MAX,
> +};
> +
> +struct kvm_sev_issue_cmd {
> + __u32 cmd;
> + __u64 opaque;
> + __u32 ret_code;
> +};
> +
> +struct kvm_sev_launch_start {
> + __u32 handle;
> + __u32 flags;
> + __u32 policy;
> + __u8 nonce[16];
> + __u8 dh_pub_qx[32];
> + __u8 dh_pub_qy[32];
> +};
> +
> +struct kvm_sev_launch_update {
> + __u64   address;
> + __u32   length;
> +};
> +
> +struct kvm_sev_launch_finish {
> + __u32 vcpu_count;
> + __u32 vcpu_length;
> + __u64 vcpu_mask_addr;
> + __u32 vcpu_mask_length;
> + __u8  measurement[32];
> +};
> +
> +struct kvm_sev_guest_status {
> + __u32 policy;
> + __u32 state;
> +};
> +
> +struct kvm_sev_dbg_decrypt {
> + __u64 src_addr;
> + __u64 dst_addr;
> + __u32 length;
> +};
> +
> +struct kvm_sev_dbg_encrypt {
> + __u64 src_addr;
> + __u64 dst_addr;
> + __u32 length;
> +};
> +
> +struct kvm_sev_receive_start {
> + __u32 handle;
> + __u32 flags;
> + __u32 policy;
> + __u8 policy_meas[32];
> + __u8 wrapped_tek[24];
> + __u8 wrapped_tik[24];
> + __u8 ten[16];
> + __u8 dh_pub_qx[32];
> + __u8 dh_pub_qy[32];
> + __u8 nonce[16];
> +};
> +
> +struct kvm_sev_receive_update {
> + __u8 iv[16];
> + __u64 address;
> + __u32 length;
> +};
> +
> +struct kvm_sev_receive_finish {
> + __u8 measurement[32];
> +};
> +
> +struct kvm_sev_send_start {
> + __u8 nonce[16];
> + __u32 policy;
> + __u8 policy_meas[32];
> + __u8 wrapped_tek[24];
> + __u8 wrapped_tik[24];
> + __u8 ten[16];
> + __u8 iv[16];
> + __u32 flags;
> + __u8 api_major;
> + __u8 api_minor;
> + __u32 serial;
> + __u8 dh_pub_qx[32];
> + __u8 dh_pub_qy[32];
> + __u8 pek_sig_r[32];
> + 

Re: [RFC PATCH v1 20/28] KVM: SVM: prepare for SEV guest management API support

[Paolo Bonzini]

On 23/08/2016 01:28, Brijesh Singh wrote:
> The patch adds initial support required for Secure Encrypted
> Virtualization (SEV) guest management API's.
> 
> ASID management:
>  - Reserve asid range for SEV guest, SEV asid range is obtained
>through CPUID Fn8000_001f[ECX]. A non-SEV guest can use any
>asid outside the SEV asid range.
>  - SEV guest must have asid value within asid range obtained
>through CPUID.
>  - SEV guest must have the same asid for all vcpu's. A TLB flush
>is required if different vcpu for the same ASID is to be run
>on the same host CPU.
> 
> - save SEV private structure in kvm_arch.
> 
> - If SEV is available then initialize PSP firmware during hardware probe
> 
> Signed-off-by: Brijesh Singh 
> ---
>  arch/x86/include/asm/kvm_host.h |9 ++
>  arch/x86/kvm/svm.c  |  213 
> +++
>  2 files changed, 221 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index b1dd673..9b885fc 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -715,6 +715,12 @@ struct kvm_hv {
>   u64 hv_crash_ctl;
>  };
>  
> +struct kvm_sev_info {
> + unsigned int asid;  /* asid for this guest */
> + unsigned int handle;/* firmware handle */
> + unsigned int ref_count; /* number of active vcpus */
> +};
> +
>  struct kvm_arch {
>   unsigned int n_used_mmu_pages;
>   unsigned int n_requested_mmu_pages;
> @@ -799,6 +805,9 @@ struct kvm_arch {
>  
>   bool x2apic_format;
>   bool x2apic_broadcast_quirk_disabled;
> +
> + /* struct for SEV guest */
> + struct kvm_sev_info sev_info;
>  };
>  
>  struct kvm_vm_stat {
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index f010b23..dcee635 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -186,6 +187,9 @@ struct vcpu_svm {
>   struct page *avic_backing_page;
>   u64 *avic_physical_id_cache;
>   bool avic_is_running;
> +
> + /* which host cpu was used for running this vcpu */
> + bool last_cpuid;
>  };
>  
>  #define AVIC_LOGICAL_ID_ENTRY_GUEST_PHYSICAL_ID_MASK (0xFF)
> @@ -243,6 +247,25 @@ static int avic;
>  module_param(avic, int, S_IRUGO);
>  #endif
>  
> +/* Secure Encrypted Virtualization */
> +static bool sev_enabled;

You can check max_sev_asid != 0 instead (wrapped in a sev_enabled()
function).

> +static unsigned long max_sev_asid;

Need not be 64-bit.

> +static unsigned long *sev_asid_bitmap;

Please note what lock protects this, and modify it with __set_bit and
__clear_bit.

> +#define kvm_sev_guest()  (kvm->arch.sev_info.handle)
> +#define kvm_sev_handle() (kvm->arch.sev_info.handle)
> +#define kvm_sev_ref()(kvm->arch.sev_info.ref_count++)
> +#define kvm_sev_unref()  (kvm->arch.sev_info.ref_count--)
> +#define svm_sev_handle() (svm->vcpu.kvm->arch.sev_info.handle)
> +#define svm_sev_asid()   (svm->vcpu.kvm->arch.sev_info.asid)
> +#define svm_sev_ref()
> (svm->vcpu.kvm->arch.sev_info.ref_count++)
> +#define svm_sev_unref()  
> (svm->vcpu.kvm->arch.sev_info.ref_count--)
> +#define svm_sev_guest()  (svm->vcpu.kvm->arch.sev_info.handle)
> +#define svm_sev_ref_count()  (svm->vcpu.kvm->arch.sev_info.ref_count)

Why is the reference count necessary?  Could you use the kvm refcount
instead and free the ASID in kvm_x86_ops->vm_destroy?  Also, what lock
protects the reference count?

Also please remove the macros in general.  If there is only a struct
vcpu_svm*, use

struct kvm_arch *vm_data = >vcpu.kvm->arch;

as done for example in avic_init_vmcb.

> +
> +static int sev_asid_new(void);
> +static void sev_asid_free(int asid);
> +
>  static void svm_set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);
>  static void svm_flush_tlb(struct kvm_vcpu *vcpu);
>  static void svm_complete_interrupts(struct vcpu_svm *svm);
> @@ -474,6 +497,8 @@ struct svm_cpu_data {
>   struct kvm_ldttss_desc *tss_desc;
>  
>   struct page *save_area;
> +
> + void **sev_vmcb;  /* index = sev_asid, value = vmcb pointer */

It's not a void**, it's a struct vmcb**.  Please rename it to sev_vmcbs,
too, so that it's clear that it's an array.

>  };
>  
>  static DEFINE_PER_CPU(struct svm_cpu_data *, svm_data);
> @@ -727,7 +752,10 @@ static int svm_hardware_enable(void)
>   sd->asid_generation = 1;
>   sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
>   sd->next_asid = sd->max_asid + 1;
> - sd->min_asid = 1;
> + sd->min_asid = max_sev_asid + 1;
> +
> + if (sev_enabled)
> + memset(sd->sev_vmcb, 0, (max_sev_asid + 1) * sizeof(void *));

This seems strange.  You should clear the field, for each possible CPU,
in sev_asid_free, not in sev_uninit_vcpu.  Then when you reuse the 

Re: [V2] rtlwifi: Fix regression caused by commit d86e64768859

[Kalle Valo]

Larry Finger  wrote:
> In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
> the configuration struct for most of the drivers was changed to be
> constant. The problem is that five of the modified drivers need to be
> able to update the firmware name based on the exact model of the card.
> As the file names were stored in one of the members of that struct,
> these drivers would fail with a kernel BUG splat when they tried to
> update the firmware name.
> 
> Rather than reverting the previous commit, I used a suggestion by
> Johannes Berg and made the firmware file name pointers be local to
> the routines that update the software variables.
> 
> The configuration struct of rtl8192cu, which was not touched in the
> previous patch, is now constantfied.
> 
> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
> Suggested-by: Johannes Berg 
> Signed-off-by: Larry Finger 
> Cc: Stable  # 4.8
> Cc: Julia Lawall 

Patch applied to wireless-drivers.git, thanks.

cf4747d7535a rtlwifi: Fix regression caused by commit d86e64768859

-- 
https://patchwork.kernel.org/patch/9373717/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v1 19/28] KVM: SVM: prepare to reserve asid for SEV guest

[Paolo Bonzini]

On 23/08/2016 01:27, Brijesh Singh wrote:
> In current implementation, asid allocation starts from 1, this patch
> adds a min_asid variable in svm_vcpu structure to allow starting asid
> from something other than 1.
> 
> Signed-off-by: Brijesh Singh 
> ---
>  arch/x86/kvm/svm.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 211be94..f010b23 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -470,6 +470,7 @@ struct svm_cpu_data {
>   u64 asid_generation;
>   u32 max_asid;
>   u32 next_asid;
> + u32 min_asid;
>   struct kvm_ldttss_desc *tss_desc;
>  
>   struct page *save_area;
> @@ -726,6 +727,7 @@ static int svm_hardware_enable(void)
>   sd->asid_generation = 1;
>   sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
>   sd->next_asid = sd->max_asid + 1;
> + sd->min_asid = 1;
>  
>   native_store_gdt(_descr);
>   gdt = (struct desc_struct *)gdt_descr.address;
> @@ -1887,7 +1889,7 @@ static void new_asid(struct vcpu_svm *svm, struct 
> svm_cpu_data *sd)
>  {
>   if (sd->next_asid > sd->max_asid) {
>   ++sd->asid_generation;
> - sd->next_asid = 1;
> + sd->next_asid = sd->min_asid;
>   svm->vmcb->control.tlb_ctl = TLB_CONTROL_FLUSH_ALL_ASID;
>   }
>  
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 

Reviewed-by: Paolo Bonzini 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[patch] Staging: lustre: indent an if statement

[Dan Carpenter]

This if statement wasn't intended.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/lustre/lustre/obdclass/cl_object.c 
b/drivers/staging/lustre/lustre/obdclass/cl_object.c
index 3199dd4..a102c36 100644
--- a/drivers/staging/lustre/lustre/obdclass/cl_object.c
+++ b/drivers/staging/lustre/lustre/obdclass/cl_object.c
@@ -335,7 +335,7 @@ int cl_object_getstripe(const struct lu_env *env, struct 
cl_object *obj,
if (obj->co_ops->coo_getstripe) {
result = obj->co_ops->coo_getstripe(env, obj, uarg);
if (result)
-   break;
+   break;
}
}
return result;
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] Staging:greybus:arche-apb-ctrl: fixed some coding style issue

[Greg KH]

On Thu, Oct 13, 2016 at 06:00:45AM +0200, Alexander Alemayhu wrote:
> On Wed, Oct 12, 2016 at 04:45:54PM +0200, Greg KH wrote:
> > 
> > You can subscribe to the driverdev mailing list to see what othes are
> > working on, and you can follow my staging-testing kernel branch in the
> > staging.git tree.  But sometimes you just get unlucky, lots of people
> > are working on cleaning up staging drivers, people do the same work at
> > the same time quite often, it's just part of the process.
> > 
> 
> Is this
> (http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel)
> the right page for subscribing?

Yes.

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel