[PATCH] staging: ccree: move comment to fit coding style
Trivial fix for Line over 80 characters Moved the comment to top of the definition Signed-off-by: Bincy K Philip --- drivers/staging/ccree/cc_hw_queue_defs.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h b/drivers/staging/ccree/cc_hw_queue_defs.h --- a/drivers/staging/ccree/cc_hw_queue_defs.h +++ b/drivers/staging/ccree/cc_hw_queue_defs.h @@ -27,7 +27,8 @@ **/ #define HW_DESC_SIZE_WORDS 6 -#define HW_QUEUE_SLOTS_MAX 15 /* Max. available slots in HW queue */ +/* Define max. available slots in HW queue */ +#define HW_QUEUE_SLOTS_MAX 15 #define CC_REG_NAME(word, name) DX_DSCRPTR_QUEUE_WORD ## word ## _ ## name -- 1.8.3.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Submit of a driver for Pi433 - a radio module for Raspberry Pi
On Tue, Jul 11, 2017 at 06:02:09PM +0200, Marcus Wolf wrote: > Hi folks, > > I developed a radio shield for the 433MHz ISM band [0] for the Raspberry Pi. > This shield is called Pi433 [1]. It can be used to communicate between two > Raspberries or to control third party equipment e. g. cheap radio sockets [2]. > The base of this radio shield is a radio module from HopeRf - a rfm69cw-433s2. > > In the beginning, I conrolled the rf69 chip by direct access via SPI, but I > figured out, that several tasks were hard to handle. Especially the following > points were annoying: > * Just one process could open the SPI interface so just one process was > able to access the module > * A simultaneous send and receive was very hard to implement > > Therefore I started to implement a driver. > The drivers features: > * simple access/nice abstraction of spi registers via open, close, > read, write and ioctl > * multiple applications can open > * tx requests are queued, so every app can send a tx request at any time > * first app asking for rx will block other apps, also asking for rx until one > rx > cycle is complete > * rx cycle means listening on the air until something appears > * if an app wants to tx during the driver is waiting in rx cycle, rx will be > shortly interrupted to do the tx task > * for each tx task a seperate configuration of the rf chip (bitrate, > modulation, ...) > can be chosen > * wrtten in modular architecture, allowing to extend for other products with > rf69 chip (e.g. rfm69hcw, ...) or even to support other HopeRf chips with > similar > interface (e. g. rfm12, rfm95, ...) > > In principle the driver was intended to be used by my project (Smarthome-Pi), > only. > But while having all this nice features, I was asked, whether I could offer > the > driver to the community. I never did that before, so I started reading about > submitting drivers and figured out, that there is a lot of work to do, to meet > all > concepts and ideas of complying to kernel code. I spend some days and modified > a lot, but still, a lot of things aren't perfect. > Already known tasks are: > > * coding style does not fully comply with the kernel style guide. > * still TODOs, annotated in the code > * currently the code introduces new IOCTLs. I'm afraid this is a bad idea. > Replace this with another interface, hints are welcome! > > I tested the patch on Raspbian with Kernel v4.12 and applied the patch on > mainline Linux v4.12 > > Is it posibble to integrate into the staging area to ease further development? Sure, I'm always glad to take new drivers, but can you submit it as just a single patch, and keep it self-contained (i.e. nothing outside of drivers/staging/YOUR_DRIVER/)? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: rtl8188eu: memory leak in rtw_free_cmd_obj()
We were fixing checkpatch.pl warnings and accidentally reversed this
condition.
Fixes: 5b291e3c ("staging: rtl8188eu: removes comparison to null")
Signed-off-by: Dan Carpenter
diff --git a/drivers/staging/rtl8188eu/core/rtw_cmd.c
b/drivers/staging/rtl8188eu/core/rtw_cmd.c
index 002d09159896..a69007ef77bf 100644
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -132,7 +132,7 @@ void rtw_free_cmd_obj(struct cmd_obj *pcmd)
kfree(pcmd->parmbuf);
}
- if (!pcmd->rsp) {
+ if (pcmd->rsp) {
if (pcmd->rspsz != 0) {
/* free rsp in cmd_obj */
kfree(pcmd->rsp);
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: ks7010: fix styling WARNINGs
On Fri, Jun 30, 2017 at 8:39 PM, Mark Rogers wrote: > Thank you for your feedback. I guess when making this patch I had the > preferred coding style in mind, but didn't ask myself if making the code > conform to it would truly improve readability. > > I agree with all of your comments. Do you think the best course of > action is to create a new patch with this change alone and forget the > rest? It's up to you. You could send a couple of patches fixing these things, or just do one patch fixing one thing. > > - DPRINTK(1, "ks7010_sdio_remove()\n"); > + DPRINTK(1, "%s()\n", __func__); > > Sorry about the newbie questions and bad patch, I will do better with > the next one. Thanks again for your time and feedback, I really > appreciate it. It's pretty much what staging is for. Don't worry about it. Frans ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] drivers/staging/wilc1000: fix sparse warning: right shift by bigger than source value
On Wed, 2017-07-12 at 08:12 +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 12, 2017 at 10:23:02AM +0800, Rui Teng wrote:
> > On 12/07/2017 1:04 AM, Greg Kroah-Hartman wrote:
> > > On Mon, Jul 10, 2017 at 04:57:31PM +0800, Rui Teng wrote:
> > > > This patch sets memory to zero directly to avoid unnecessary shift and
> > > > bitwise operations on bool type, which can fix a sparse warning and also
> > > > improve performance.
> > >
> > > It does? How did you measure the performance impact? What was now
> > > faster?
> >
> > It can avoid 3 times right shift and 3 times bitwise operations.
> > And once memory set should also faster than 4 times copy operations.
> > And add number 4 once should also faster than 4 times plus plus.
>
> And did you test this to prove that this does matter and is noticable?
> How do you know that gcc doesn't just optimize it all away? Is this on
> a code path that actually matters?
>
> Don't ever say "improve performance" without actually being able to
> prove it please.
Using __be32 would be more intelligible.
Maybe something like this: (in any number of patches)
o convert u8 *pu8CurrByte to be32 *buf
o convert strHostIfSetMulti to smulti
o remove useless initialization of result
o remove unnecessary parentheses
o return directly on kalloc failure
o remove label
Ending up with: (uncompiled/untested)
---
static void Handle_SetMulticastFilter(struct wilc_vif *vif,
struct set_multicast *smulti)
{
s32 result;
struct wid wid;
__be32 *buf;
wid.id = (u16)WID_SETUP_MULTICAST_FILTER;
wid.type = WID_BIN;
wid.size = sizeof(struct set_multicast) + smulti->cnt * ETH_ALEN;
wid.val = kmalloc(wid.size, GFP_KERNEL);
if (!wid.val)
return;
buf = (__force __be32 *)wid.val;
*buf++ = cpu_to_be32(smulti->enabled);
*buf++ = cpu_to_be32(smulti->cnt);
memcpy(buf, wilc_multicast_mac_addr_list, smulti->cnt * ETH_ALEN);
result = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
wilc_get_vif_idx(vif));
if (result)
netdev_err(vif->ndev, "Failed to send setup multicast\n");
kfree(wid.val);
}
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Stagingdriver cctree: Fix for checkpatch warning
Hi Gilad, I have added your comments and resent the patch.Thanks On 11/07/17 17:16, Gilad Ben-Yossef wrote: Hello Philip, Thank your patch. Your patch subject line is not descriptive and not formatted well. A better subject would be something like: staging: ccree: move comment to fit coding style Thanks, Gilad On Fri, Jun 30, 2017 at 7:32 AM, wrote: From: Bincy K Philip Trivial fix for Line over 80 characters Moved the comment to top of the definition Signed-off-by: Bincy K Philip --- drivers/staging/ccree/cc_hw_queue_defs.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h b/drivers/staging/ccree/cc_hw_queue_defs.h index aaa56c8..a18e6c9 100644 --- a/drivers/staging/ccree/cc_hw_queue_defs.h +++ b/drivers/staging/ccree/cc_hw_queue_defs.h @@ -27,7 +27,8 @@ **/ #define HW_DESC_SIZE_WORDS 6 -#define HW_QUEUE_SLOTS_MAX 15 /* Max. available slots in HW queue */ +/* Define max. available slots in HW queue */ +#define HW_QUEUE_SLOTS_MAX 15 #define CC_REG_NAME(word, name) DX_DSCRPTR_QUEUE_WORD ## word ## _ ## name -- 1.8.3.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 0/4] Staging: Lustre Style Fixes
This series fixes a few style issues in lustre. All where picked up by checkpatch. v2 Changes: - Fixed typo in patch subject s/luster/lustre/ Craig Inches (4): Staging: Lustre Clean up line over 80Char in lib-lnet.h Staging: Lustre Fix up multiple Block Comments in lib-types.h Staging: Lustre Fixing multiline block comments in lnetst.h Staging: Lustre Fix block statement style issue .../staging/lustre/include/linux/lnet/lib-lnet.h | 3 +- .../staging/lustre/include/linux/lnet/lib-types.h | 46 +--- drivers/staging/lustre/include/linux/lnet/lnetst.h | 129 + .../staging/lustre/include/linux/lnet/socklnd.h| 3 +- 4 files changed, 115 insertions(+), 66 deletions(-) -- 2.13.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 1/4] Staging: Lustre Clean up line over 80Char in lib-lnet.h
This patch fixes a warning generated by checkpatch for a line over 80 characters. Signed-off-by: Craig Inches --- drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h index 8ae7423b4543..f534115d402a 100644 --- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h +++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h @@ -453,7 +453,8 @@ extern int portal_rotor; int lnet_lib_init(void); void lnet_lib_exit(void); -int lnet_notify(struct lnet_ni *ni, lnet_nid_t peer, int alive, unsigned long when); +int lnet_notify(struct lnet_ni *ni, lnet_nid_t peer, int alive, + unsigned long when); void lnet_notify_locked(struct lnet_peer *lp, int notifylnd, int alive, unsigned long when); int lnet_add_route(__u32 net, __u32 hops, lnet_nid_t gateway_nid, -- 2.13.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/4] Staging: Lustre Fix up multiple Block Comments in lib-types.h
This patch fixes some multiline comment blocks which didnt conform
to the style guide, found by checkpatch.
Signed-off-by: Craig Inches
---
.../staging/lustre/include/linux/lnet/lib-types.h | 46 ++
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/lnet/lib-types.h
b/drivers/staging/lustre/include/linux/lnet/lib-types.h
index 321752dfe58b..ddb808ed5d0b 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-types.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-types.h
@@ -308,9 +308,11 @@ struct lnet_rc_data {
struct lnet_peer {
struct list_head lp_hashlist; /* chain on peer hash */
struct list_head lp_txq;/* messages blocking for
- tx credits */
+* tx credits
+*/
struct list_head lp_rtrq; /* messages blocking for
- router credits */
+* router credits
+*/
struct list_head lp_rtr_list; /* chain on router list */
int lp_txcredits; /* # tx credits available */
int lp_mintxcredits; /* low water mark */
@@ -319,23 +321,31 @@ struct lnet_peer {
unsigned int lp_alive:1; /* alive/dead? */
unsigned int lp_notify:1; /* notification outstanding? */
unsigned int lp_notifylnd:1;/* outstanding notification
- for LND? */
+* for LND?
+*/
unsigned int lp_notifying:1; /* some thread is handling
- notification */
+ * notification
+ */
unsigned int lp_ping_notsent;/* SEND event outstanding
- from ping */
+ * from ping
+ */
int lp_alive_count; /* # times router went
- dead<->alive */
- long lp_txqnob; /* bytes queued for sending */
+ * dead<->alive
+ */
+ long lp_txqnob; /* ytes queued for sending */
unsigned longlp_timestamp; /* time of last aliveness
- news */
+ * news
+ */
unsigned longlp_ping_timestamp;/* time of last ping
- attempt */
+ * attempt
+ */
unsigned longlp_ping_deadline; /* != 0 if ping reply
- expected */
+ * expected
+ */
unsigned longlp_last_alive; /* when I was last alive */
unsigned longlp_last_query; /* when lp_ni was queried
- last time */
+* last time
+*/
struct lnet_ni *lp_ni; /* interface peer is on */
lnet_nid_t lp_nid;/* peer's NID */
int lp_refcount; /* # refs */
@@ -386,7 +396,8 @@ struct lnet_route {
struct lnet_remotenet {
struct list_headlrn_list; /* chain on
- ln_remote_nets_hash */
+* ln_remote_nets_hash
+*/
struct list_headlrn_routes; /* routes to me */
__u32 lrn_net;/* my net number */
};
@@ -399,14 +410,16 @@ struct lnet_remotenet {
struct lnet_rtrbufpool {
struct list_headrbp_bufs; /* my free buffer pool */
struct list_headrbp_msgs; /* messages blocking
- for a buffer */
+* for a buffer
+*/
int rbp_npages; /
[PATCH v2 4/4] Staging: Lustre Fix block statement style issue
This fixes a block statement which didnt end with */
Signed-off-by: Craig Inches
---
drivers/staging/lustre/include/linux/lnet/socklnd.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/include/linux/lnet/socklnd.h
b/drivers/staging/lustre/include/linux/lnet/socklnd.h
index dd5bc0e46560..a1ae66ede7a8 100644
--- a/drivers/staging/lustre/include/linux/lnet/socklnd.h
+++ b/drivers/staging/lustre/include/linux/lnet/socklnd.h
@@ -76,7 +76,8 @@ struct ksock_msg {
__u64 ksm_zc_cookies[2]; /* Zero-Copy request/ACK cookie */
union {
struct ksock_lnet_msg lnetmsg; /* lnet message, it's empty if
- * it's NOOP */
+ * it's NOOP
+ */
} WIRE_ATTR ksm_u;
} WIRE_ATTR;
--
2.13.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 3/4] Staging: Lustre Fixing multiline block comments in lnetst.h
This fixes multiple block statements found not to match
style as per checkpatch
Signed-off-by: Craig Inches
---
drivers/staging/lustre/include/linux/lnet/lnetst.h | 129 +
1 file changed, 81 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/lustre/include/linux/lnet/lnetst.h
b/drivers/staging/lustre/include/linux/lnet/lnetst.h
index ea736f8d5231..a4f9ff01d458 100644
--- a/drivers/staging/lustre/include/linux/lnet/lnetst.h
+++ b/drivers/staging/lustre/include/linux/lnet/lnetst.h
@@ -54,7 +54,8 @@
#define LSTIO_GROUP_ADD0xC10 /* add group */
#define LSTIO_GROUP_LIST 0xC11 /* list all groups in session */
#define LSTIO_GROUP_INFO 0xC12 /* query default information of
-* specified group */
+* specified group
+*/
#define LSTIO_GROUP_DEL0xC13 /* delete group */
#define LSTIO_NODES_ADD0xC14 /* add nodes to specified group
*/
#define LSTIO_GROUP_UPDATE 0xC15 /* update group */
@@ -102,27 +103,32 @@ struct lstcon_test_ent {
int tse_type; /* test type */
int tse_loop; /* loop count */
int tse_concur; /* concurrency of test */
-}; /*** test summary entry, for
-*** list_batch command */
+}; /* test summary entry, for
+* list_batch command
+*/
struct lstcon_batch_ent {
int bae_state; /* batch status */
int bae_timeout;/* batch timeout */
int bae_ntest; /* # of tests in the batch */
-}; /*** batch summary entry, for
-*** list_batch command */
+}; /* batch summary entry, for
+* list_batch command
+*/
struct lstcon_test_batch_ent {
struct lstcon_ndlist_ent tbe_cli_nle; /* client (group) node_list
-* entry */
+* entry
+*/
struct lstcon_ndlist_ent tbe_srv_nle; /* server (group) node_list
-* entry */
+* entry
+*/
union {
struct lstcon_test_ent tbe_test; /* test entry */
struct lstcon_batch_ent tbe_batch;/* batch entry */
} u;
-}; /*** test/batch verbose information entry,
-*** for list_batch command */
+}; /* test/batch verbose information entry,
+* for list_batch command
+*/
struct lstcon_rpc_ent {
struct list_headrpe_link; /* link chain */
@@ -138,10 +144,10 @@ struct lstcon_rpc_ent {
};
struct lstcon_trans_stat {
- int trs_rpc_stat[4];/* RPCs stat (0: total
- 1: failed
- 2: finished
- 4: reserved */
+ int trs_rpc_stat[4];/* RPCs stat (0: total 1: failed
+* 2: finished
+* 4: reserved
+*/
int trs_rpc_errno; /* RPC errno */
int trs_fwk_stat[8];/* framework stat */
int trs_fwk_errno; /* errno of the first remote error */
@@ -275,22 +281,28 @@ struct lstio_session_end_args {
struct lstio_debug_args {
int lstio_dbg_key; /* IN: session key */
int lstio_dbg_type;/* IN: debug
- session|batch|
- group|nodes
- list */
+* session|batch|
+* group|nodes list
+*/
int lstio_dbg_flags; /* IN: reserved debug
- flags */
+* flags
+*/
int lstio_dbg_timeout; /* IN: timeout of
- debug */
+
[PATCH] Staging: speakup: speakup_keypc.c: usleep_range is preferred over udelay
Fix checkpatch issue: CHECK: usleep_range is preferred over udelay; Signed-off-by: Jaya Durga --- drivers/staging/speakup/speakup_keypc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/speakup/speakup_keypc.c b/drivers/staging/speakup/speakup_keypc.c index d3203f8..1ba4cfc 100644 --- a/drivers/staging/speakup/speakup_keypc.c +++ b/drivers/staging/speakup/speakup_keypc.c @@ -28,7 +28,7 @@ #define DRV_VERSION "2.10" #define SYNTH_IO_EXTENT0x04 -#define SWAIT udelay(70) +#define SWAIT usleep_range(70, 150) #define PROCSPEECH 0x1f #define SYNTH_CLEAR 0x03 @@ -164,7 +164,7 @@ static const char *synth_immediate(struct spk_synth *synth, const char *buf) if (--timeout <= 0) return oops(); outb_p(ch, synth_port); - udelay(70); + usleep_range(70, 150); buf++; } return NULL; -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
New Driver for electrical energy measurement
Hi, Microchip is planning to introduce a driver for a new companion chip series capable of electical energy measurement. However, we are not sure which location in the source tree is the most suitable. First thought was to put it into /drivers/powercap. But now we are in discussions whether it would make even more sense to introduce a new driver for electrical energy measuring or monitoring. Following is a rough overview of the part we want the driver for. Any input on this will be appreciated. thanks, Chris === Introduction Following the recent focus on low-power systems, Microchip has designed a companion chip series capable of measuring the electrical energy flow of an electrical system. The series in question, EM Chip is capable of measuring the energy flow (in or out) of an electrical system by monitoring one or more power rails. The 1st chip of the series, EM Chip is able to measure the net energy flow over 4 different power rails. The chip itself is a small QFN16 (4mm x 4mm x 0.5mm) or WLCSP16 (2.25mm x 2.2mm) package. === Theory of Operation In order to measure the amount of energy entering/exiting a system, a small shunt resistor is interleaved on a power rail. By measuring the small voltage drop across the shunt resistor (a known value), the electrical current is measured. I = U/R Depending on whether the system is consuming or producing energy, the measured current value can be either a positive or negative number. To get the instantaneous power figure we will have to measure the power rail’s voltage and multiply it with the measured value for the current P = V * I = V * U_shunt/R Knowing the instantaneous power and by making a high enough sample rate (for measuring the current and the power rail voltage), we can assume the measured value for power is equal to the average power figure for the amount of time between 2 sampling moments. Now that we also know the average power for a given time interval (dt_x = time between 2 sampling moments; sampling speed is known), we can measure the energy amount entering or exiting the system between 2 sampling moments E_partial_x = P * dt_x Having the energy information available, we can continue to add the subsequent energy values for as long as the system is active. The amount of energy is the sum of all the partial energy values measured for each time interval E = Sum (E_partial_x), where x can take values from 0 till infinite. === Chip Operation The EM Chip chip uses the same principles of operation as presented in the “Theory of Operation” and it does so for a number of 4 channels. 4 independent power rails can be energy monitored in the same time. The chip is controlled over I2C/SMBus by an I2C/SMBus master. In order to reduce the amount of information traffic between the EM Chip and the entity asking for its information, the chip features large accumulator energy registers for the accumulated energy values. It can accumulate up to 2^24 power values. Depending on the selected chip’s sampling speed, such a number of samples are produced in about 4.5 hours (fastest sampling speed) up to 582.5 hours or more than 24 days (lowest sampling speed). EM Chip measures the power as a 28-bits number. The 28-bits number is the multiplication result of the 16-bits number used to measure the power rail voltage and the 12-bits number used for measuring the voltage drop across the power rail shunt resistor. If bidirectional energy flow is required, the power is measured as a 27-bits number and 1 bit for the sign. When no bidirectional flow is needed, the power value is measured as an unsigned 28-bits number. Due to the relatively large size of the accumulated energy registers inside the chip (48 bits), in the worst case scenario (power values are full scale numbers), a number of 2^20 full-scale power values can be measured before energy register’s overflow. Using the fastest sampling speed, the accumulated energy registers overflows only after a bit over 17 minutes, while at the lowest sampling speed, it would overflow in over 36 hours. Thus, the chip requires infrequent reads of the accumulated energy registers. Even in the worst case scenario, the time between 2 consecutive energy accumulator reads can be over 17 minutes ! In order to keep a longer history of energy measurements, an I2C/SMBus master (e.g. SoC) would read the accumulated energy register values and then use larger “soft” accumulated energy registers to extend the maximum overflow period. The EM Chip chip can monitor rails up to 32V. It can monitor the energy amounts used by various sub-components of a system (e.g. CPU, GPU, memory, hard-drives, USB ports, backlight, wireless adapters, cameras, displays, …) EM Chip is able to start operating immediately after power-up with no CPU intervention at all. Such a feature is useful, because it can show the amount of energy consumed by a system before the latter finished booting its operating system. The
[PATCH] media: staging: atomisp: disable warnings with cc-disable-warning
Instead of directly using -Wno-foo, use cc-disable-warning, as it checks if the compiler has the warnings we want to disable. Signed-off-by: Mauro Carvalho Chehab --- drivers/staging/media/atomisp/pci/atomisp2/Makefile | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/staging/media/atomisp/pci/atomisp2/Makefile b/drivers/staging/media/atomisp/pci/atomisp2/Makefile index 726eaa293c55..2bd98f0667ec 100644 --- a/drivers/staging/media/atomisp/pci/atomisp2/Makefile +++ b/drivers/staging/media/atomisp/pci/atomisp2/Makefile @@ -354,7 +354,9 @@ ccflags-y += $(INCLUDES) $(DEFINES) -fno-common # HACK! While this driver is in bad shape, don't enable several warnings # that would be otherwise enabled with W=1 -ccflags-y += -Wno-unused-const-variable -Wno-missing-prototypes \ --Wno-unused-but-set-variable -Wno-missing-declarations \ --Wno-suggest-attribute=format -Wno-missing-prototypes \ --Wno-implicit-fallthrough +ccflags-y += $(call cc-disable-warning, implicit-fallthrough) +ccflags-y += $(call cc-disable-warning, missing-prototypes) +ccflags-y += $(call cc-disable-warning, missing-declarations) +ccflags-y += $(call cc-disable-warning, suggest-attribute=format) +ccflags-y += $(call cc-disable-warning, unused-const-variable) +ccflags-y += $(call cc-disable-warning, unused-but-set-variable) -- 2.13.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: speakup: speakup_keypc.c: usleep_range is preferred over udelay
On Wed, Jul 12, 2017 at 04:53:53PM +0530, Jaya Durga wrote: > Fix checkpatch issue: CHECK: usleep_range is preferred over udelay; > > Signed-off-by: Jaya Durga > --- > drivers/staging/speakup/speakup_keypc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/speakup/speakup_keypc.c > b/drivers/staging/speakup/speakup_keypc.c > index d3203f8..1ba4cfc 100644 > --- a/drivers/staging/speakup/speakup_keypc.c > +++ b/drivers/staging/speakup/speakup_keypc.c > @@ -28,7 +28,7 @@ > > #define DRV_VERSION "2.10" > #define SYNTH_IO_EXTENT 0x04 > -#define SWAIT udelay(70) > +#define SWAIT usleep_range(70, 150) Ick, why not just get rid of SWAIT entirely please? > #define PROCSPEECH 0x1f > #define SYNTH_CLEAR 0x03 > > @@ -164,7 +164,7 @@ static const char *synth_immediate(struct spk_synth > *synth, const char *buf) > if (--timeout <= 0) > return oops(); > outb_p(ch, synth_port); > - udelay(70); > + usleep_range(70, 150); And you are sure it is ok to wait up to 150 long here? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: speakup: speakup_keypc.c: usleep_range is preferred over udelay
Jaya Durga, on mer. 12 juil. 2017 16:53:53 +0530, wrote: > Fix checkpatch issue: CHECK: usleep_range is preferred over udelay; IIRC synth_immediate is meant to be usable in atomic contexts too, so usleep can't be used. Samuel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: New Driver for electrical energy measurement
On Wed, Jul 12, 2017 at 02:18:54PM +0200, Christian Gromm wrote: > > Hi, > > Microchip is planning to introduce a driver for a new companion chip series > capable of electical energy measurement. However, we are not sure which > location in the source tree is the most suitable. First thought was to put > it into /drivers/powercap. But now we are in discussions whether it would > make even more sense to introduce a new driver for electrical energy > measuring or monitoring. Why not just have it be an IIO device, I think they have energy sensors already (adding the iio mailing list to find out...) > > Following is a rough overview of the part we want the driver for. Any > input on this will be appreciated. > > thanks, > Chris > > === Introduction > > Following the recent focus on low-power systems, Microchip has designed a > companion chip series capable of measuring the electrical energy flow of an > electrical system. The series in question, EM Chip is capable of > measuring the energy flow (in or out) of an electrical system by monitoring > one or more power rails. The 1st chip of the series, EM Chip is able to > measure the net energy flow over 4 different power rails. The chip itself > is a small QFN16 (4mm x 4mm x 0.5mm) or WLCSP16 (2.25mm x 2.2mm) package. > > === Theory of Operation > > In order to measure the amount of energy entering/exiting a system, a small > shunt resistor is interleaved on a power rail. By measuring the small > voltage drop across the shunt resistor (a known value), the electrical > current is measured. > > I = U/R > > Depending on whether the system is consuming or producing energy, the > measured current value can be either a positive or negative number. > > To get the instantaneous power figure we will have to measure the power > rail’s voltage and multiply it with the measured value for the current > > P = V * I = V * U_shunt/R > > Knowing the instantaneous power and by making a high enough sample rate > (for measuring the current and the power rail voltage), we can assume the > measured value for power is equal to the average power figure for the > amount of time between 2 sampling moments. > > Now that we also know the average power for a given time interval (dt_x = > time between 2 sampling moments; sampling speed is known), we can measure > the energy amount entering or exiting the system between 2 sampling moments > > E_partial_x = P * dt_x > > Having the energy information available, we can continue to add the > subsequent energy values for as long as the system is active. The amount of > energy is the sum of all the partial energy values measured for each time > interval E = Sum (E_partial_x), where x can take values from 0 till > infinite. > > > === Chip Operation > > The EM Chip chip uses the same principles of operation as presented in the > “Theory of Operation” and it does so for a number of 4 channels. 4 > independent power rails can be energy monitored in the same time. The chip > is controlled over I2C/SMBus by an I2C/SMBus master. > > In order to reduce the amount of information traffic between the EM Chip > and the entity asking for its information, the chip features large > accumulator energy registers for the accumulated energy values. It can > accumulate up to 2^24 power values. Depending on the selected chip’s > sampling speed, such a number of samples are produced in about 4.5 hours > (fastest sampling speed) up to 582.5 hours or more than 24 days (lowest > sampling speed). > > EM Chip measures the power as a 28-bits number. The 28-bits number is the > multiplication result of the 16-bits number used to measure the power rail > voltage and the 12-bits number used for measuring the voltage drop across > the power rail shunt resistor. > > If bidirectional energy flow is required, the power is measured as a > 27-bits number and 1 bit for the sign. When no bidirectional flow is > needed, the power value is measured as an unsigned 28-bits number. > > Due to the relatively large size of the accumulated energy registers inside > the chip (48 bits), in the worst case scenario (power values are full scale > numbers), a number of 2^20 full-scale power values can be measured before > energy register’s overflow. Using the fastest sampling speed, the > accumulated energy registers overflows only after a bit over 17 minutes, > while at the lowest sampling speed, it would overflow in over 36 hours. > > Thus, the chip requires infrequent reads of the accumulated energy > registers. Even in the worst case scenario, the time between 2 consecutive > energy accumulator reads can be over 17 minutes ! > > In order to keep a longer history of energy measurements, an I2C/SMBus > master (e.g. SoC) would read the accumulated energy register values and > then use larger “soft” accumulated energy registers to extend the maximum > overflow period. > > The EM Chip chip can monitor rails up to 32V. It can monitor the energy > amoun
Re: New Driver for electrical energy measurement
Hi Christian, On 12 July 2017 at 17:48, Christian Gromm wrote: > > Hi, > > Microchip is planning to introduce a driver for a new companion chip series > capable of electical energy measurement. However, we are not sure which > location in the source tree is the most suitable. First thought was to put > it into /drivers/powercap. But now we are in discussions whether it would > make even more sense to introduce a new driver for electrical energy > measuring or monitoring. May be IIO subsystem will help. Look at the following links for more info: 1. http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf 2. https://archive.fosdem.org/2012/schedule/event/693/127_iio-a-new-subsystem.pdf 3. https://wiki.analog.com/software/linux/docs/iio/iio Regards, PrasannaKumar ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: New Driver for electrical energy measurement
On Wed, 12 Jul 2017 14:51:01 +0200 Greg KH wrote: > On Wed, Jul 12, 2017 at 02:18:54PM +0200, Christian Gromm wrote: > > > > Hi, > > > > Microchip is planning to introduce a driver for a new companion > > chip series capable of electical energy measurement. However, we > > are not sure which location in the source tree is the most > > suitable. First thought was to put it into /drivers/powercap. But > > now we are in discussions whether it would make even more sense to > > introduce a new driver for electrical energy measuring or > > monitoring. > > Why not just have it be an IIO device, I think they have energy > sensors already (adding the iio mailing list to find out...) We thought about hwmon, but not IIO. > > > > > Following is a rough overview of the part we want the driver for. > > Any input on this will be appreciated. > > > > thanks, > > Chris > > > > === Introduction > > > > Following the recent focus on low-power systems, Microchip has > > designed a companion chip series capable of measuring the > > electrical energy flow of an electrical system. The series in > > question, EM Chip is capable of measuring the energy flow (in or > > out) of an electrical system by monitoring one or more power > > rails. The 1st chip of the series, EM Chip is able to measure the > > net energy flow over 4 different power rails. The chip itself is a > > small QFN16 (4mm x 4mm x 0.5mm) or WLCSP16 (2.25mm x 2.2mm) package. > > > > === Theory of Operation > > > > In order to measure the amount of energy entering/exiting a system, > > a small shunt resistor is interleaved on a power rail. By measuring > > the small voltage drop across the shunt resistor (a known value), > > the electrical current is measured. > > > > I = U/R > > > > Depending on whether the system is consuming or producing energy, > > the measured current value can be either a positive or negative > > number. > > > > To get the instantaneous power figure we will have to measure the > > power rail’s voltage and multiply it with the measured value for > > the current > > > > P = V * I = V * U_shunt/R > > > > Knowing the instantaneous power and by making a high enough sample > > rate (for measuring the current and the power rail voltage), we can > > assume the measured value for power is equal to the average power > > figure for the amount of time between 2 sampling moments. > > > > Now that we also know the average power for a given time interval > > (dt_x = time between 2 sampling moments; sampling speed is known), > > we can measure the energy amount entering or exiting the system > > between 2 sampling moments > > > > E_partial_x = P * dt_x > > > > Having the energy information available, we can continue to add the > > subsequent energy values for as long as the system is active. The > > amount of energy is the sum of all the partial energy values > > measured for each time interval E = Sum (E_partial_x), where x can > > take values from 0 till infinite. > > > > > > === Chip Operation > > > > The EM Chip chip uses the same principles of operation as presented > > in the “Theory of Operation” and it does so for a number of 4 > > channels. 4 independent power rails can be energy monitored in the > > same time. The chip is controlled over I2C/SMBus by an I2C/SMBus > > master. > > > > In order to reduce the amount of information traffic between the EM > > Chip and the entity asking for its information, the chip features > > large accumulator energy registers for the accumulated energy > > values. It can accumulate up to 2^24 power values. Depending on the > > selected chip’s sampling speed, such a number of samples are > > produced in about 4.5 hours (fastest sampling speed) up to 582.5 > > hours or more than 24 days (lowest sampling speed). > > > > EM Chip measures the power as a 28-bits number. The 28-bits number > > is the multiplication result of the 16-bits number used to measure > > the power rail voltage and the 12-bits number used for measuring > > the voltage drop across the power rail shunt resistor. > > > > If bidirectional energy flow is required, the power is measured as a > > 27-bits number and 1 bit for the sign. When no bidirectional flow is > > needed, the power value is measured as an unsigned 28-bits number. > > > > Due to the relatively large size of the accumulated energy > > registers inside the chip (48 bits), in the worst case scenario > > (power values are full scale numbers), a number of 2^20 full-scale > > power values can be measured before energy register’s overflow. > > Using the fastest sampling speed, the accumulated energy registers > > overflows only after a bit over 17 minutes, while at the lowest > > sampling speed, it would overflow in over 36 hours. > > > > Thus, the chip requires infrequent reads of the accumulated energy > > registers. Even in the worst case scenario, the time between 2 > > consecutive energy accumulator reads can be over 17 minutes ! > > > > In orde
Re: New Driver for electrical energy measurement
On Wed, 12 Jul 2017 18:28:56 +0530 PrasannaKumar Muralidharan wrote: > Hi Christian, > > On 12 July 2017 at 17:48, Christian Gromm > wrote: > > > > Hi, > > > > Microchip is planning to introduce a driver for a new companion > > chip series capable of electical energy measurement. However, we > > are not sure which location in the source tree is the most > > suitable. First thought was to put it into /drivers/powercap. But > > now we are in discussions whether it would make even more sense to > > introduce a new driver for electrical energy measuring or > > monitoring. > > May be IIO subsystem will help. > > Look at the following links for more info: > 1. > http://events.linuxfoundation.org/sites/events/files/slides/lceu15_baluta.pdf > 2. > https://archive.fosdem.org/2012/schedule/event/693/127_iio-a-new-subsystem.pdf > 3. https://wiki.analog.com/software/linux/docs/iio/iio > Nice, I'll have a look at those. thanks, Chris ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] [media] staging/imx: remove confusing IS_ERR_OR_NULL usage
On Tue, 2017-07-11 at 15:18 +0200, Arnd Bergmann wrote:
> While looking at a compiler warning, I noticed the use of
> IS_ERR_OR_NULL, which is generally a sign of a bad API design
> and should be avoided.
>
> In this driver, this is fairly easy, we can simply stop storing
> error pointers in persistent structures, and change the two
> functions that might return either a NULL pointer or an error
> code to consistently return error pointers when failing.
>
> of_parse_subdev() now separates the error code and the pointer
> it looks up, to clarify the interface. There are two cases
> where this function originally returns 'NULL', and I have
> changed that to '0' for success to keep the current behavior,
> though returning an error would also make sense there.
>
> Fixes: e130291212df ("[media] media: Add i.MX media core driver")
> Signed-off-by: Arnd Bergmann
> ---
> v2: fix type mismatch
> v3: rework of_parse_subdev() as well.
Thanks!
Reviewed-by: Philipp Zabel
Tested-by: Philipp Zabel
regards
Philipp
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH RESEND] staging: sm750fb: avoid conflicting vesafb
On Wed, Jul 12, 2017 at 08:06:24AM +0200, Greg Kroah-Hartman wrote: > On Tue, Jul 11, 2017 at 10:03:01PM +0100, Sudip Mukherjee wrote: > > Hi Greg, > > > > On Fri, Jun 30, 2017 at 09:57:43PM +0100, Sudip Mukherjee wrote: > > > From: Teddy Wang > > > > > > > A gentle ping. > > It's in the middle of the merge window, I can't do anything with patches > right now, you know better than this... yes, sorry, my bad. lost count of days. -- Regards Sudip ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: Use little-endian type
On Wed, Jul 12, 2017 at 07:26:08AM +0200, Frans Klaver wrote: > On Tue, Jul 11, 2017 at 9:51 PM, Aviv Palivoda wrote: > > Fix the following sparse warning: > > drivers/staging//wlan-ng/prism2sta.c:1691:20: warning: incorrect type in > > assignment (different base types) > > > > (a) Change struct hfa384x_authenticate_station_data status member type to > > __le16. > > (b) All assignment to status are converted to little-endian prior to > > assignment. > > Why is this the right thing to do? > > Frans In line 1691 the status is converted to little endian: rec.status = cpu_to_le16(rec.status); Currently status is u16 but is being converted to __le16 by cpu_to_le16. This causes a sparse warning as specified in the commit message. Converting all P80211ENUM_status_* to little endian prior to assignment will happen by the preprocessor. While the current conversion happens at run time. Aviv ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] [media] staging/imx: remove confusing IS_ERR_OR_NULL usage
On 07/12/2017 08:50 AM, Philipp Zabel wrote:
On Tue, 2017-07-11 at 15:18 +0200, Arnd Bergmann wrote:
While looking at a compiler warning, I noticed the use of
IS_ERR_OR_NULL, which is generally a sign of a bad API design
and should be avoided.
In this driver, this is fairly easy, we can simply stop storing
error pointers in persistent structures, and change the two
functions that might return either a NULL pointer or an error
code to consistently return error pointers when failing.
of_parse_subdev() now separates the error code and the pointer
it looks up, to clarify the interface. There are two cases
where this function originally returns 'NULL', and I have
changed that to '0' for success to keep the current behavior,
though returning an error would also make sense there.
Fixes: e130291212df ("[media] media: Add i.MX media core driver")
Signed-off-by: Arnd Bergmann
---
v2: fix type mismatch
v3: rework of_parse_subdev() as well.
Thanks!
Reviewed-by: Philipp Zabel
Tested-by: Philipp Zabel
Looks fine to me. Tested on SabreAuto with affected pipelines.
Reviewed-by: Steve Longerbeam
Tested-by: Steve Longerbeam
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch 0/3] Re: tty contention resulting from tty_open_by_device export
> When opening from kernel, we don't use file pointer. The count mismatch > is between tty->count and #fd's. So opening from kernel leads to #fd's > being less than tty->count. I thought this difference is relevant to > user-space opening of tty, and not to kernel opening of tty. Can you > suggest how to address this mismatch? Your kernel reference is the same as having a file open reference so I think this actually needs addressing in the maths. In other words count the number of kernel references and also add that into the test for check_tty_count (kernel references + #fds == count). I'd really like to keep this right because that check has a long history of catching really nasty race conditions in the tty code. The open/close/hangup code is really fragile so worth the debugability. > Ah may be I didn't notice the active bit. Is it one of the #defines in > tty.h? Can usage count and active bit be used to differentiate between > whether the tty was opened by kernel or user? It only tells you whether the port is currently active for some purpose, not which. If you still want to implement exclusivity between kernel and user then it needs another flag, but I think that flag should be in port->flags as it is a property of the physical interface. (Take a look at tty_port_open for example) Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch] staging: speakup: safely close tty
> spk_ttyio_initialise_ldisc is called separately for each module (e.g. > speakup_apollo, speakup_ltlk etc) when it is loaded. spk_ttyio_release > is also called separately for each module when it is unloaded. The ldisc > stays around until the last of the modules is unloaded. What guarantees that someone hasn't decided to set the ldisc on unrelated hardware to speakup (eg on a pty/tty pair). > > > > > I'd also btw strongly recommend putting the ldisc and the speakup tty > > driver as different modules. > Sure, that makes sense. I will do that following these patches. If the ldisc is just unregistered when the module implementing it is unloaded then the ref counts on the ldisc module should do everything needed if the above isn't correctly handled, and if it is will still be cleaner. Alan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] [media] lirc_zilog: Clean up lirc zilog error codes
According the coding style guidelines, the ENOSYS error code must be returned in case of a non existent system call. This code has been replaced with the ENOTTY error code indicating a missing functionality. v2: Improved punctuation Fixed patch subject Signed-off-by: Yves Lemée --- drivers/staging/media/lirc/lirc_zilog.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/staging/media/lirc/lirc_zilog.c b/drivers/staging/media/lirc/lirc_zilog.c index 015e41bd036e..26dd32d5b5b2 100644 --- a/drivers/staging/media/lirc/lirc_zilog.c +++ b/drivers/staging/media/lirc/lirc_zilog.c @@ -1249,7 +1249,7 @@ static long ioctl(struct file *filep, unsigned int cmd, unsigned long arg) break; case LIRC_GET_REC_MODE: if (!(features & LIRC_CAN_REC_MASK)) - return -ENOSYS; + return -ENOTTY; result = put_user(LIRC_REC2MODE (features & LIRC_CAN_REC_MASK), @@ -1257,21 +1257,21 @@ static long ioctl(struct file *filep, unsigned int cmd, unsigned long arg) break; case LIRC_SET_REC_MODE: if (!(features & LIRC_CAN_REC_MASK)) - return -ENOSYS; + return -ENOTTY; result = get_user(mode, uptr); if (!result && !(LIRC_MODE2REC(mode) & features)) - result = -EINVAL; + result = -ENOTTY; break; case LIRC_GET_SEND_MODE: if (!(features & LIRC_CAN_SEND_MASK)) - return -ENOSYS; + return -ENOTTY; result = put_user(LIRC_MODE_PULSE, uptr); break; case LIRC_SET_SEND_MODE: if (!(features & LIRC_CAN_SEND_MASK)) - return -ENOSYS; + return -ENOTTY; result = get_user(mode, uptr); if (!result && mode != LIRC_MODE_PULSE) -- 2.13.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: Fix endianness warnings
From: Alfonso Lima Astor
These variables were set to u16 and u32 although they always hold a little
endian value.
This patch fixes multiple sparse warnings like:
drivers/staging/wlan-ng/prism2sta.c:375:46: warning: cast to restricted __le16
Signed-off-by: Alfonso Lima Astor
---
drivers/staging/wlan-ng/hfa384x.h | 92 ++---
drivers/staging/wlan-ng/prism2sta.c | 8 ++--
2 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 018db2299..6e4c946df 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -445,9 +445,9 @@ struct hfa384x_downloadbuffer {
/*-- Information Record: commsquality --*/
struct hfa384x_commsquality {
- u16 cq_curr_bss;
- u16 asl_curr_bss;
- u16 anl_curr_fc;
+ __le16 cq_curr_bss;
+ __le16 asl_curr_bss;
+ __le16 anl_curr_fc;
} __packed;
/*-- Information Record: dmbcommsquality --*/
@@ -598,51 +598,51 @@ struct hfa384x_rx_frame {
/*-- Inquiry Frame, Diagnose: Communication Tallies --*/
struct hfa384x_comm_tallies_16 {
- u16 txunicastframes;
- u16 txmulticastframes;
- u16 txfragments;
- u16 txunicastoctets;
- u16 txmulticastoctets;
- u16 txdeferredtrans;
- u16 txsingleretryframes;
- u16 txmultipleretryframes;
- u16 txretrylimitexceeded;
- u16 txdiscards;
- u16 rxunicastframes;
- u16 rxmulticastframes;
- u16 rxfragments;
- u16 rxunicastoctets;
- u16 rxmulticastoctets;
- u16 rxfcserrors;
- u16 rxdiscardsnobuffer;
- u16 txdiscardswrongsa;
- u16 rxdiscardswepundecr;
- u16 rxmsginmsgfrag;
- u16 rxmsginbadmsgfrag;
+ __le16 txunicastframes;
+ __le16 txmulticastframes;
+ __le16 txfragments;
+ __le16 txunicastoctets;
+ __le16 txmulticastoctets;
+ __le16 txdeferredtrans;
+ __le16 txsingleretryframes;
+ __le16 txmultipleretryframes;
+ __le16 txretrylimitexceeded;
+ __le16 txdiscards;
+ __le16 rxunicastframes;
+ __le16 rxmulticastframes;
+ __le16 rxfragments;
+ __le16 rxunicastoctets;
+ __le16 rxmulticastoctets;
+ __le16 rxfcserrors;
+ __le16 rxdiscardsnobuffer;
+ __le16 txdiscardswrongsa;
+ __le16 rxdiscardswepundecr;
+ __le16 rxmsginmsgfrag;
+ __le16 rxmsginbadmsgfrag;
} __packed;
struct hfa384x_comm_tallies_32 {
- u32 txunicastframes;
- u32 txmulticastframes;
- u32 txfragments;
- u32 txunicastoctets;
- u32 txmulticastoctets;
- u32 txdeferredtrans;
- u32 txsingleretryframes;
- u32 txmultipleretryframes;
- u32 txretrylimitexceeded;
- u32 txdiscards;
- u32 rxunicastframes;
- u32 rxmulticastframes;
- u32 rxfragments;
- u32 rxunicastoctets;
- u32 rxmulticastoctets;
- u32 rxfcserrors;
- u32 rxdiscardsnobuffer;
- u32 txdiscardswrongsa;
- u32 rxdiscardswepundecr;
- u32 rxmsginmsgfrag;
- u32 rxmsginbadmsgfrag;
+ __le32 txunicastframes;
+ __le32 txmulticastframes;
+ __le32 txfragments;
+ __le32 txunicastoctets;
+ __le32 txmulticastoctets;
+ __le32 txdeferredtrans;
+ __le32 txsingleretryframes;
+ __le32 txmultipleretryframes;
+ __le32 txretrylimitexceeded;
+ __le32 txdiscards;
+ __le32 rxunicastframes;
+ __le32 rxmulticastframes;
+ __le32 rxfragments;
+ __le32 rxunicastoctets;
+ __le32 rxmulticastoctets;
+ __le32 rxfcserrors;
+ __le32 rxdiscardsnobuffer;
+ __le32 txdiscardswrongsa;
+ __le32 rxdiscardswepundecr;
+ __le32 rxmsginmsgfrag;
+ __le32 rxmsginbadmsgfrag;
} __packed;
/*-- Inquiry Frame, Diagnose: Scan Results & Subfields--*/
@@ -711,7 +711,7 @@ struct hfa384x_hscan_result {
#define HFA384x_LINK_ASSOCFAIL ((u16)6)
struct hfa384x_link_status {
- u16 linkstatus;
+ __le16 linkstatus;
} __packed;
/*-- Unsolicited Frame, MAC Mgmt: AssociationStatus (--*/
diff --git a/drivers/staging/wlan-ng/prism2sta.c
b/drivers/staging/wlan-ng/prism2sta.c
index e16da3438..5d0495ec8 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -991,9 +991,9 @@ static void prism2sta_inf_tallies(struct wlandevice
*wlandev,
struct hfa384x_inf_frame *inf)
{
struct hfa384x *hw = wlandev->priv;
- u16 *src16;
+ __le16 *src16;
u32 *dst;
- u32 *src32;
+ __le32 *src32;
int i;
int cnt;
@@ -1005,12 +1005,12 @@ static void prism2sta_inf_tallies(struct wlandevice
*wlandev,
cnt = sizeof(struct hfa384x_comm_tallies_32) / sizeof(u32);
if (inf->framelen > 22) {
dst = (u32 *)&hw->tallies;
- src32 = (u32 *)&inf->info.commtallies32;
+
Re: [PATCH v5] staging: lustre: lnet: remove dead code and useless wrapper
On Jul 7, 2017, at 16:03, Dmitriy Cherkasov wrote:
>
> After removing commented out code, ksocknal_csum() becomes a useless
> wrapper for crc32_le(). Remove it, and instead call crc32_le() directly.
>
> Fixes the following checkpatch warning:
>
> WARNING: space prohibited before semicolon
>
> Signed-off-by: Dmitriy Cherkasov
Reviewed-by: Andreas Dilger
> ---
> v5:
> - fix incomplete patch changelog
> - improve code alignment
> - reword commit message and summary to be more concise
> v4:
> - fix spacing issues
> - fix typo in commit message
> - add patch changelog
> v3:
> - fix spacing and alignment issues
> (suggested by Joe Perches)
> v2:
> - remove ksocknal_csum() and call crc32_le() directly
> (suggested by Greg KH)
> - update commit message and summary to reflect these changes
>
> drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h | 11 ---
> .../staging/lustre/lnet/klnds/socklnd/socklnd_lib.c | 20 ++--
> 2 files changed, 10 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
> b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
> index 5540de6..9eb169d 100644
> --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
> +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
> @@ -519,17 +519,6 @@ struct ksock_proto {
> #define CPU_MASK_NONE 0UL
> #endif
>
> -static inline __u32 ksocknal_csum(__u32 crc, unsigned char const *p, size_t
> len)
> -{
> -#if 1
> - return crc32_le(crc, p, len);
> -#else
> - while (len-- > 0)
> - crc = ((crc + 0x100) & ~0xff) | ((crc + *p++) & 0xff) ;
> - return crc;
> -#endif
> -}
> -
> static inline int
> ksocknal_route_mask(void)
> {
> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
> b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
> index 8a036f4..9c328dc 100644
> --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
> +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
> @@ -201,9 +201,9 @@
> if (fragnob > sum)
> fragnob = sum;
>
> - conn->ksnc_rx_csum = ksocknal_csum(conn->ksnc_rx_csum,
> -iov[i].iov_base,
> -fragnob);
> + conn->ksnc_rx_csum = crc32_le(conn->ksnc_rx_csum,
> + iov[i].iov_base,
> + fragnob);
> }
> conn->ksnc_msg.ksm_csum = saved_csum;
> }
> @@ -243,8 +243,8 @@
> if (fragnob > sum)
> fragnob = sum;
>
> - conn->ksnc_rx_csum = ksocknal_csum(conn->ksnc_rx_csum,
> -base, fragnob);
> + conn->ksnc_rx_csum = crc32_le(conn->ksnc_rx_csum,
> + base, fragnob);
>
> kunmap(kiov[i].bv_page);
> }
> @@ -265,22 +265,22 @@
>
> tx->tx_msg.ksm_csum = 0;
>
> - csum = ksocknal_csum(~0, tx->tx_iov[0].iov_base,
> - tx->tx_iov[0].iov_len);
> + csum = crc32_le(~0, tx->tx_iov[0].iov_base,
> + tx->tx_iov[0].iov_len);
>
> if (tx->tx_kiov) {
> for (i = 0; i < tx->tx_nkiov; i++) {
> base = kmap(tx->tx_kiov[i].bv_page) +
> tx->tx_kiov[i].bv_offset;
>
> - csum = ksocknal_csum(csum, base, tx->tx_kiov[i].bv_len);
> + csum = crc32_le(csum, base, tx->tx_kiov[i].bv_len);
>
> kunmap(tx->tx_kiov[i].bv_page);
> }
> } else {
> for (i = 1; i < tx->tx_niov; i++)
> - csum = ksocknal_csum(csum, tx->tx_iov[i].iov_base,
> - tx->tx_iov[i].iov_len);
> + csum = crc32_le(csum, tx->tx_iov[i].iov_base,
> + tx->tx_iov[i].iov_len);
> }
>
> if (*ksocknal_tunables.ksnd_inject_csum_error) {
> --
> 1.9.1
>
Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5] staging: lustre: lnet: remove dead code and useless wrapper
On Jul 7, 2017, at 16:03, Dmitriy Cherkasov wrote:
>
> After removing commented out code, ksocknal_csum() becomes a useless
> wrapper for crc32_le(). Remove it, and instead call crc32_le() directly.
>
> Fixes the following checkpatch warning:
>
> WARNING: space prohibited before semicolon
>
> Signed-off-by: Dmitriy Cherkasov
Reviewed-by: Andreas Dilger
> ---
> v5:
> - fix incomplete patch changelog
> - improve code alignment
> - reword commit message and summary to be more concise
> v4:
> - fix spacing issues
> - fix typo in commit message
> - add patch changelog
> v3:
> - fix spacing and alignment issues
> (suggested by Joe Perches)
> v2:
> - remove ksocknal_csum() and call crc32_le() directly
> (suggested by Greg KH)
> - update commit message and summary to reflect these changes
>
> drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h | 11 ---
> .../staging/lustre/lnet/klnds/socklnd/socklnd_lib.c | 20 ++--
> 2 files changed, 10 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
> b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
> index 5540de6..9eb169d 100644
> --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
> +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.h
> @@ -519,17 +519,6 @@ struct ksock_proto {
> #define CPU_MASK_NONE 0UL
> #endif
>
> -static inline __u32 ksocknal_csum(__u32 crc, unsigned char const *p, size_t
> len)
> -{
> -#if 1
> - return crc32_le(crc, p, len);
> -#else
> - while (len-- > 0)
> - crc = ((crc + 0x100) & ~0xff) | ((crc + *p++) & 0xff) ;
> - return crc;
> -#endif
> -}
> -
> static inline int
> ksocknal_route_mask(void)
> {
> diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
> b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
> index 8a036f4..9c328dc 100644
> --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
> +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd_lib.c
> @@ -201,9 +201,9 @@
> if (fragnob > sum)
> fragnob = sum;
>
> - conn->ksnc_rx_csum = ksocknal_csum(conn->ksnc_rx_csum,
> -iov[i].iov_base,
> -fragnob);
> + conn->ksnc_rx_csum = crc32_le(conn->ksnc_rx_csum,
> + iov[i].iov_base,
> + fragnob);
> }
> conn->ksnc_msg.ksm_csum = saved_csum;
> }
> @@ -243,8 +243,8 @@
> if (fragnob > sum)
> fragnob = sum;
>
> - conn->ksnc_rx_csum = ksocknal_csum(conn->ksnc_rx_csum,
> -base, fragnob);
> + conn->ksnc_rx_csum = crc32_le(conn->ksnc_rx_csum,
> + base, fragnob);
>
> kunmap(kiov[i].bv_page);
> }
> @@ -265,22 +265,22 @@
>
> tx->tx_msg.ksm_csum = 0;
>
> - csum = ksocknal_csum(~0, tx->tx_iov[0].iov_base,
> - tx->tx_iov[0].iov_len);
> + csum = crc32_le(~0, tx->tx_iov[0].iov_base,
> + tx->tx_iov[0].iov_len);
>
> if (tx->tx_kiov) {
> for (i = 0; i < tx->tx_nkiov; i++) {
> base = kmap(tx->tx_kiov[i].bv_page) +
> tx->tx_kiov[i].bv_offset;
>
> - csum = ksocknal_csum(csum, base, tx->tx_kiov[i].bv_len);
> + csum = crc32_le(csum, base, tx->tx_kiov[i].bv_len);
>
> kunmap(tx->tx_kiov[i].bv_page);
> }
> } else {
> for (i = 1; i < tx->tx_niov; i++)
> - csum = ksocknal_csum(csum, tx->tx_iov[i].iov_base,
> - tx->tx_iov[i].iov_len);
> + csum = crc32_le(csum, tx->tx_iov[i].iov_base,
> + tx->tx_iov[i].iov_len);
> }
>
> if (*ksocknal_tunables.ksnd_inject_csum_error) {
> --
> 1.9.1
>
Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] stating: lustre: fix sparse error: incompatible types in comparison expression
Comparing two user space addresses to avoid sparse error: drivers/staging//lustre/lnet/selftest/conrpc.c:490:30: error: incompatible types in comparison expression (different address spaces) Signed-off-by: Rui Teng --- drivers/staging/lustre/lnet/selftest/conrpc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.c b/drivers/staging/lustre/lnet/selftest/conrpc.c index da36c55b86d3..ae7c2772825e 100644 --- a/drivers/staging/lustre/lnet/selftest/conrpc.c +++ b/drivers/staging/lustre/lnet/selftest/conrpc.c @@ -487,10 +487,9 @@ lstcon_rpc_trans_interpreter(struct lstcon_rpc_trans *trans, sizeof(struct list_head))) return -EFAULT; - if (tmp.next == head_up) - return 0; - next = tmp.next; + if (next == head_up) + return 0; ent = list_entry(next, struct lstcon_rpc_ent, rpe_link); -- 2.11.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] stating: lustre: fix sparse error: incompatible types in comparison expression
On Jul 12, 2017, at 10:10 PM, Rui Teng wrote: > Comparing two user space addresses to avoid sparse error: > > drivers/staging//lustre/lnet/selftest/conrpc.c:490:30: error: > incompatible types in comparison expression (different address spaces) > > Signed-off-by: Rui Teng > --- > drivers/staging/lustre/lnet/selftest/conrpc.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/staging/lustre/lnet/selftest/conrpc.c > b/drivers/staging/lustre/lnet/selftest/conrpc.c > index da36c55b86d3..ae7c2772825e 100644 > --- a/drivers/staging/lustre/lnet/selftest/conrpc.c > +++ b/drivers/staging/lustre/lnet/selftest/conrpc.c > @@ -487,10 +487,9 @@ lstcon_rpc_trans_interpreter(struct lstcon_rpc_trans > *trans, > sizeof(struct list_head))) > return -EFAULT; > > - if (tmp.next == head_up) > - return 0; > - > next = tmp.next; So the assignment is fine, but comparison is not? Strange. I guess this is fine by me if that makes the warning go away. Acked-by: Oleg Drokin > + if (next == head_up) > + return 0; > > ent = list_entry(next, struct lstcon_rpc_ent, rpe_link); > > -- > 2.11.0 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: wlan-ng: Use little-endian type
On Wed, Jul 12, 2017 at 6:44 PM, Aviv Palivoda wrote: > On Wed, Jul 12, 2017 at 07:26:08AM +0200, Frans Klaver wrote: >> On Tue, Jul 11, 2017 at 9:51 PM, Aviv Palivoda wrote: >> > Fix the following sparse warning: >> > drivers/staging//wlan-ng/prism2sta.c:1691:20: warning: incorrect type in >> > assignment (different base types) >> > >> > (a) Change struct hfa384x_authenticate_station_data status member type to >> > __le16. >> > (b) All assignment to status are converted to little-endian prior to >> > assignment. >> >> Why is this the right thing to do? >> >> Frans > > In line 1691 the status is converted to little endian: > rec.status = cpu_to_le16(rec.status); > Currently status is u16 but is being converted to __le16 by > cpu_to_le16. This causes a sparse warning as specified in the commit message. > Converting all P80211ENUM_status_* to little endian prior to assignment will > happen by the preprocessor. While the current conversion happens at run time. That's the rationale for the sparse warning, yes, but does not really answer my question. Does your change improve readability? Why is algorithm still u16? ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2 2/2] staging: atomisp2: hmm: Alignment code (rebased)
This patch fixed code alignment to open paranthesis.
Semantic should not be affected by this patch.
It has been rebased on top of media_tree atomisp branch
Signed-off-by: Philipp Guendisch
Signed-off-by: Chris Baller
---
.../staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 93 +++---
1 file changed, 45 insertions(+), 48 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index b345025..b8aae4b 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -55,7 +55,7 @@ struct _hmm_mem_stat hmm_mem_stat;
static const char hmm_bo_type_string[] = "psui";
static ssize_t bo_show(struct device *dev, struct device_attribute *attr,
- char *buf, struct list_head *bo_list, bool active)
+ char *buf, struct list_head *bo_list, bool active)
{
ssize_t ret = 0;
struct hmm_buffer_object *bo;
@@ -75,10 +75,10 @@ static ssize_t bo_show(struct device *dev, struct
device_attribute *attr,
spin_lock_irqsave(&bo_device.list_lock, flags);
list_for_each_entry(bo, bo_list, list) {
if ((active && (bo->status & HMM_BO_ALLOCED)) ||
- (!active && !(bo->status & HMM_BO_ALLOCED))) {
+ (!active && !(bo->status & HMM_BO_ALLOCED))) {
ret = scnprintf(buf + index1, PAGE_SIZE - index1,
- "%c %d\n",
- hmm_bo_type_string[bo->type], bo->pgnr);
+ "%c %d\n",
+ hmm_bo_type_string[bo->type], bo->pgnr);
total[bo->type] += bo->pgnr;
count[bo->type]++;
@@ -91,9 +91,10 @@ static ssize_t bo_show(struct device *dev, struct
device_attribute *attr,
for (i = 0; i < HMM_BO_LAST; i++) {
if (count[i]) {
ret = scnprintf(buf + index1 + index2,
- PAGE_SIZE - index1 - index2,
- "%ld %c buffer objects: %ld KB\n",
- count[i], hmm_bo_type_string[i], total[i] * 4);
+ PAGE_SIZE - index1 - index2,
+ "%ld %c buffer objects: %ld KB\n",
+ count[i], hmm_bo_type_string[i],
+ total[i] * 4);
if (ret > 0)
index2 += ret;
}
@@ -103,23 +104,21 @@ static ssize_t bo_show(struct device *dev, struct
device_attribute *attr,
return index1 + index2 + 1;
}
-static ssize_t active_bo_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t active_bo_show(struct device *dev, struct device_attribute
*attr,
+ char *buf)
{
return bo_show(dev, attr, buf, &bo_device.entire_bo_list, true);
}
-static ssize_t free_bo_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+static ssize_t free_bo_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
return bo_show(dev, attr, buf, &bo_device.entire_bo_list, false);
}
static ssize_t reserved_pool_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+ struct device_attribute *attr,
+ char *buf)
{
ssize_t ret = 0;
@@ -131,7 +130,7 @@ static ssize_t reserved_pool_show(struct device *dev,
spin_lock_irqsave(&pinfo->list_lock, flags);
ret = scnprintf(buf, PAGE_SIZE, "%d out of %d pages available\n",
- pinfo->index, pinfo->pgnr);
+ pinfo->index, pinfo->pgnr);
spin_unlock_irqrestore(&pinfo->list_lock, flags);
if (ret > 0)
@@ -141,8 +140,8 @@ static ssize_t reserved_pool_show(struct device *dev,
};
static ssize_t dynamic_pool_show(struct device *dev,
- struct device_attribute *attr,
- char *buf)
+struct device_attribute *attr,
+char *buf)
{
ssize_t ret = 0;
@@ -154,7 +153,7 @@ static ssize_t dynamic_pool_show(struct device *dev,
spin_lock_irqsave(&pinfo->list_lock, flags);
ret = scnprintf(buf, PAGE_SIZE, "%d (max %d) pages available\n",
- pinfo->pgnr, pinfo->pool_size);
+ pinfo->pgnr, pinfo->pool_size);
spin_unlock_irqrestore(&pinfo->list_lock, flags);
if (ret > 0)
@@ -202,7 +201,7 @@ int hmm_init(void)
if (!ret) {
ret = sysfs_create_group(&atomisp_dev->ko
[PATCH v2 1/2] staging: atomisp2: hmm: Fixed comment style
This patch fixed comment style. Semantic should not be affected.
There are also two warnings left about too long lines, which
reduce readability if changed.
Signed-off-by: Philipp Guendisch
Signed-off-by: Chris Baller
---
.../staging/media/atomisp/pci/atomisp2/hmm/hmm.c | 44 +++---
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
index de0426b..b345025 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/hmm/hmm.c
@@ -46,10 +46,12 @@ static ia_css_ptr dummy_ptr;
static bool hmm_initialized;
struct _hmm_mem_stat hmm_mem_stat;
-/* p: private
- s: shared
- u: user
- i: ion */
+/*
+ * p: private
+ * s: shared
+ * u: user
+ * i: ion
+ */
static const char hmm_bo_type_string[] = "psui";
static ssize_t bo_show(struct device *dev, struct device_attribute *attr,
@@ -213,9 +215,7 @@ void hmm_cleanup(void)
{
sysfs_remove_group(&atomisp_dev->kobj, atomisp_attribute_group);
- /*
-* free dummy memory first
-*/
+ /* free dummy memory first */
hmm_free(dummy_ptr);
dummy_ptr = 0;
@@ -230,22 +230,24 @@ ia_css_ptr hmm_alloc(size_t bytes, enum hmm_bo_type type,
struct hmm_buffer_object *bo;
int ret;
- /* Check if we are initialized. In the ideal world we wouldn't need
- this but we can tackle it once the driver is a lot cleaner */
+ /*
+* Check if we are initialized. In the ideal world we wouldn't need
+* this but we can tackle it once the driver is a lot cleaner
+*/
if (!hmm_initialized)
hmm_init();
- /*Get page number from size*/
+ /* Get page number from size */
pgnr = size_to_pgnr_ceil(bytes);
- /*Buffer object structure init*/
+ /* Buffer object structure init */
bo = hmm_bo_alloc(&bo_device, pgnr);
if (!bo) {
dev_err(atomisp_dev, "hmm_bo_create failed.\n");
goto create_bo_err;
}
- /*Allocate pages for memory*/
+ /* Allocate pages for memory */
ret = hmm_bo_alloc_pages(bo, type, from_highmem, userptr, cached);
if (ret) {
dev_err(atomisp_dev,
@@ -253,7 +255,7 @@ ia_css_ptr hmm_alloc(size_t bytes, enum hmm_bo_type type,
goto alloc_page_err;
}
- /*Combind the virtual address and pages togather*/
+ /* Combind the virtual address and pages togather */
ret = hmm_bo_bind(bo);
if (ret) {
dev_err(atomisp_dev, "hmm_bo_bind failed.\n");
@@ -319,7 +321,7 @@ static inline int hmm_check_bo(struct hmm_buffer_object
*bo, unsigned int ptr)
return 0;
}
-/*Read function in ISP memory management*/
+/* Read function in ISP memory management */
static int load_and_flush_by_kmap(ia_css_ptr virt, void *data, unsigned int
bytes)
{
struct hmm_buffer_object *bo;
@@ -362,7 +364,7 @@ static int load_and_flush_by_kmap(ia_css_ptr virt, void
*data, unsigned int byte
return 0;
}
-/*Read function in ISP memory management*/
+/* Read function in ISP memory management */
static int load_and_flush(ia_css_ptr virt, void *data, unsigned int bytes)
{
struct hmm_buffer_object *bo;
@@ -397,7 +399,7 @@ static int load_and_flush(ia_css_ptr virt, void *data,
unsigned int bytes)
return 0;
}
-/*Read function in ISP memory management*/
+/* Read function in ISP memory management */
int hmm_load(ia_css_ptr virt, void *data, unsigned int bytes)
{
if (!data) {
@@ -408,13 +410,13 @@ int hmm_load(ia_css_ptr virt, void *data, unsigned int
bytes)
return load_and_flush(virt, data, bytes);
}
-/*Flush hmm data from the data cache*/
+/* Flush hmm data from the data cache */
int hmm_flush(ia_css_ptr virt, unsigned int bytes)
{
return load_and_flush(virt, NULL, bytes);
}
-/*Write function in ISP memory management*/
+/* Write function in ISP memory management */
int hmm_store(ia_css_ptr virt, const void *data, unsigned int bytes)
{
struct hmm_buffer_object *bo;
@@ -496,7 +498,7 @@ int hmm_store(ia_css_ptr virt, const void *data, unsigned
int bytes)
return 0;
}
-/*memset function in ISP memory management*/
+/* memset function in ISP memory management */
int hmm_set(ia_css_ptr virt, int c, unsigned int bytes)
{
struct hmm_buffer_object *bo;
@@ -556,7 +558,7 @@ int hmm_set(ia_css_ptr virt, int c, unsigned int bytes)
return 0;
}
-/*Virtual address to physical address convert*/
+/* Virtual address to physical address convert */
phys_addr_t hmm_virt_to_phys(ia_css_ptr virt)
{
unsigned int idx, offset;
@@ -591,7 +593,7 @@ int hmm_mmap(struct vm_area_struct *vma, ia_css_ptr virt)
return hmm_bo_mmap(vma, bo);
}
-/*Map ISP virtual address into IA virtual address*/
+/* Map ISP
