Re: [PATCH] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

[Dan Carpenter]

On Sun, Feb 18, 2018 at 04:44:46PM -0800, Quytelda Kahja wrote:
> Fix a coding style problem.
> 
> Signed-off-by: Quytelda Kahja 
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
> b/drivers/staging/media/bcm2048/radio-bcm2048.c
> index 06d1920150da..94141a11e51b 100644
> --- a/drivers/staging/media/bcm2048/radio-bcm2048.c
> +++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
> @@ -1846,6 +1846,7 @@ static int bcm2048_deinit(struct bcm2048_device *bdev)
>  static int bcm2048_probe(struct bcm2048_device *bdev)
>  {
>   int err;
> + u8 default_threshold = BCM2048_DEFAULT_RSSI_THRESHOLD;
>  
>   err = bcm2048_set_power_state(bdev, BCM2048_POWER_ON);
>   if (err < 0)
> @@ -1863,8 +1864,7 @@ static int bcm2048_probe(struct bcm2048_device *bdev)
>   if (err < 0)
>   goto unlock;
>  
> - err = bcm2048_set_fm_search_rssi_threshold(bdev,
> - BCM2048_DEFAULT_RSSI_THRESHOLD);
> + err = bcm2048_set_fm_search_rssi_threshold(bdev, default_threshold);

Nah.  Don't do this.

There were some of your earlier patches where I thought:

gdm->tty_dev->send_func(...

Could be shortened to:

tty->send_func(...

So sometimes introducing shorter aliases is the right thing.  But here
it just makes it look like a variable when it's a constant.  It's makes
the code slightly less readable.

Just ignore the warning.

regards,
dan carpenter

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Mon Feb 19 05:00:17 CET 2018
media-tree git hash:29422737017b866d4a51014cc7522fa3a99e8852
media_build git hash:   d144cfe4b3c37ece55ae27778c99765d4943c4fa
v4l-utils git hash: 4665ab1fbab1ddaa5696bc3f5865ec6fc83eaf84
gcc version:i686-linux-gcc (GCC) 7.3.0
sparse version: v0.5.0-3994-g45eb2282
smatch version: v0.5.0-3994-g45eb2282
host hardware:  x86_64
host os:4.14.0-3-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-arm-stm32: OK
linux-git-arm64: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.98-i686: WARNINGS
linux-3.2.98-x86_64: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.53-i686: WARNINGS
linux-3.16.53-x86_64: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.93-i686: WARNINGS
linux-3.18.93-x86_64: WARNINGS
linux-3.19-i686: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.49-i686: WARNINGS
linux-4.1.49-x86_64: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.115-i686: OK
linux-4.4.115-x86_64: OK
linux-4.5.7-i686: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-i686: OK
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-i686: OK
linux-4.7.5-x86_64: WARNINGS
linux-4.8-i686: OK
linux-4.8-x86_64: WARNINGS
linux-4.9.80-i686: OK
linux-4.9.80-x86_64: OK
linux-4.10.14-i686: OK
linux-4.10.14-x86_64: WARNINGS
linux-4.11-i686: OK
linux-4.11-x86_64: WARNINGS
linux-4.12.1-i686: OK
linux-4.12.1-x86_64: WARNINGS
linux-4.13-i686: OK
linux-4.13-x86_64: OK
linux-4.14.17-i686: OK
linux-4.14.17-x86_64: OK
linux-4.15.2-i686: OK
linux-4.15.2-x86_64: OK
linux-4.16-rc1-i686: OK
linux-4.16-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

[PATCH] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

[Quytelda Kahja]

Fix a coding style problem.

Signed-off-by: Quytelda Kahja 
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 06d1920150da..94141a11e51b 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -1846,6 +1846,7 @@ static int bcm2048_deinit(struct bcm2048_device *bdev)
 static int bcm2048_probe(struct bcm2048_device *bdev)
 {
int err;
+   u8 default_threshold = BCM2048_DEFAULT_RSSI_THRESHOLD;
 
err = bcm2048_set_power_state(bdev, BCM2048_POWER_ON);
if (err < 0)
@@ -1863,8 +1864,7 @@ static int bcm2048_probe(struct bcm2048_device *bdev)
if (err < 0)
goto unlock;
 
-   err = bcm2048_set_fm_search_rssi_threshold(bdev,
-   BCM2048_DEFAULT_RSSI_THRESHOLD);
+   err = bcm2048_set_fm_search_rssi_threshold(bdev, default_threshold);
if (err < 0)
goto unlock;
 
@@ -1942,9 +1942,9 @@ static irqreturn_t bcm2048_handler(int irq, void *dev)
  */
 #define property_write(prop, type, mask, check)
\
 static ssize_t bcm2048_##prop##_write(struct device *dev,  \
-   struct device_attribute *attr,  \
-   const char *buf,\
-   size_t count)   \
+ struct device_attribute *attr,\
+ const char *buf,  \
+ size_t count) \
 {  \
struct bcm2048_device *bdev = dev_get_drvdata(dev); \
type value; \
@@ -1966,8 +1966,8 @@ static ssize_t bcm2048_##prop##_write(struct device *dev, 
\
 
 #define property_read(prop, mask)  \
 static ssize_t bcm2048_##prop##_read(struct device *dev,   \
-   struct device_attribute *attr,  \
-   char *buf)  \
+struct device_attribute *attr, \
+char *buf) \
 {  \
struct bcm2048_device *bdev = dev_get_drvdata(dev); \
int value;  \
@@ -1985,8 +1985,8 @@ static ssize_t bcm2048_##prop##_read(struct device *dev,  
\
 
 #define property_signed_read(prop, size, mask) \
 static ssize_t bcm2048_##prop##_read(struct device *dev,   \
-   struct device_attribute *attr,  \
-   char *buf)  \
+struct device_attribute *attr, \
+char *buf) \
 {  \
struct bcm2048_device *bdev = dev_get_drvdata(dev); \
size value; \
@@ -2005,8 +2005,8 @@ property_read(prop, mask) 
\
 
 #define property_str_read(prop, size)  \
 static ssize_t bcm2048_##prop##_read(struct device *dev,   \
-   struct device_attribute *attr,  \
-   char *buf)  \
+struct device_attribute *attr, \
+char *buf) \
 {  \
struct bcm2048_device *bdev = dev_get_drvdata(dev); \
int count;  \
@@ -2175,7 +2175,7 @@ static int bcm2048_fops_release(struct file *file)
 }
 
 static __poll_t bcm2048_fops_poll(struct file *file,
- struct poll_table_struct *pts)
+ struct poll_table_struct *pts)
 {
struct bcm2048_device *bdev = video_drvdata(file);
__poll_t retval = 0;
-- 
2.16.2

Re: [PATCH V2 0/3] Add timers to en50221 protocol driver

[Ralph Metzler]

Hi Jasmin,

Jasmin J. writes:
 > Hallo Ralph!
 > 
 > > 1. The SW bit is cleared too early during the whole buffer size 
 > > negotiation.
 > > This should be fixed.
 > I will look into this when I have time again. Probably end of next week.
 > 
 > > 2. IRQEN = CMDREG_DAIE = 0x80 is always set in the command register.
 > > So, they should probably only be used if both the host and module say they
 > > support it.
 > How can we know that in the driver?
 > I haven't seen an API for this.

The flags parameter of dvb_ca_en50221_init() allow these values:

#define DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE   1
#define DVB_CA_EN50221_FLAG_IRQ_FR  2
#define DVB_CA_EN50221_FLAG_IRQ_DA  4

but only DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE seems to be used in dvb_ca_en50221.c.
Support for this was seemingly planned but never implemented.

Annex G.2 of
http://www.ci-plus.com/data/ci-plus_specification_v1.3.pdf
contains details about how support is announced in the CIS.


 > There is the flag "da_irq_supported", which might be used to set the IRQEN
 > bit it the bit is set.

Sure, e.g. to store the result from the CIS parsing.
The current use is not much help. It is set if an interrupt occured with DA bit 
set, which is
a little too late.


 > Any suggestions how to proceed with item 2?

Check the CIS for support by the CAM and ca->flags for support by the host.
If both support it, set CMDREG_FRIE and/or CMDREG_DAIE in command reg.


Regards,
Ralph

[no subject]

[Alfred Cheuk Yu Chow]

Good Day,

I am Mr. Alfred Cheuk Yu Chow, the Director for Credit & Marketing Chong
Hing Bank, Hong Kong, Chong Hing Bank Center, 24 Des Voeux Road Central,
Hong Kong. I have a business proposal of $ 38,980,369.00.

All confirmable documents to back up the claims will be made available
to you prior to your acceptance and as soon as I receive your return
mail.

Best Regards,
Alfred Chow.

Re: [PATCH V2 0/3] Add timers to en50221 protocol driver

[Jasmin J.]

Hallo Ralph!

> 1. The SW bit is cleared too early during the whole buffer size negotiation.
> This should be fixed.
I will look into this when I have time again. Probably end of next week.

> 2. IRQEN = CMDREG_DAIE = 0x80 is always set in the command register.
> So, they should probably only be used if both the host and module say they
> support it.
How can we know that in the driver?
I haven't seen an API for this.
There is the flag "da_irq_supported", which might be used to set the IRQEN
bit it the bit is set.

Any suggestions how to proceed with item 2?

BR,
   Jasmin

Re: [PATCH V2 0/3] Add timers to en50221 protocol driver

[Ralph Metzler]

Hi Jasmin,

Jasmin J. writes:
 > Hi!
 > 
 > Please hold on in merging this series, because I have to investigate a hint
 > I got related to the buffer size handshake of the protocol driver:
 >   https://www.linuxtv.org/pipermail/linux-dvb/2007-July/019116.html
 > 
 > BR,
 >Jasmin


So, there seem to be two bugs:

1. The SW bit is cleared too early during the whole buffer size negotiation.

This should be fixed.


2. IRQEN = CMDREG_DAIE = 0x80 is always set in the command register.

DAIE and FRIE were introduced as recommendation in Cenelec R06-001:1998 and are 
a requirement for
CI+.

They could cause problems if the IRQ line goes high and the interrupt is 
enabled but not handled.
They should not cause a problem if the host ignores the interrupt or if the CAM 
does not support it,
but one never knows with some CAMs ...

So, they should probably only be used if both the host and module say they 
support it.
R06 does not mention it but CI+ also requires a CIS entry to be present in 
modules 
supporting this feature.



Regards,
Ralph

Re: [BUG] musb: broken isochronous transfer at TI AM335x platform

[Matwey V. Kornilov]

2018-02-16 19:27 GMT+03:00 Tony Lindgren :
> * Matwey V. Kornilov  [180215 17:55]:
>> []   7.219456 d=  0.000997 [181.0 +  3.667] [  3] IN   : 4.5
>> [T   ]   7.219459 d=  0.03 [181.0 +  7.083] [800] DATA0: 53 da 
>> ...
>> []   7.220456 d=  0.000997 [182   +  3.667] [  3] IN   : 4.5
>> [T   ]   7.220459 d=  0.03 [182   +  7.000] [800] DATA0: 13 36 
>> ...
>> []   7.222456 d=  0.001997 [184   +  3.667] [  3] IN   : 4.5
>> []   7.222459 d=  0.03 [184   +  7.000] [  3] DATA0: 00 00
>> []   7.223456 d=  0.000997 [185.0 +  3.667] [  3] IN   : 4.5
>> []   7.223459 d=  0.03 [185.0 +  7.000] [  3] DATA0: 00 00
>>
>> Please note, that the time moment "7.221456" has missed IN request
>> packet which must be sent out every 1ms in this low-speed USB case.
>> Then, all incoming packets became empty ones. Such moments coincide
>> with frame discarding in pwc driver.
>
> Well sounds like you may be able to fix it since you have a test
> case for it :)

Well, I am not an USB expert and I need some guidance and advice to
find acceptable solution. No doubts I could implement and test it, but
I would like to spend time for something known to be useful.

>
>> Even though IN sending is usually handled by USB host hardware, it is
>> not fully true for MUSB. Every IN is triggered by musb kernel driver
>> (see MUSB_RXCSR_H_REQPKT usage in musb_host_packet_rx() and
>> musb_ep_program()) since auto IN is not used. Rather complicated logic
>> is incorporated to decide whether IN packet has to be sent. First,
>> musb_host_packet_rx() handles IN sending when current URB is not
>> completed (i.e. current URB has another packet which has to be
>> received next). Second, musb_advance_schedule() (via musb_start_urb())
>> handles the case when current URB is completed but there is another
>> URB pending. It seems that there is a hardware logic to fire IN packet
>> in a way to have exactly 1ms between two consequent INs. So,
>> MUSB_RXCSR_H_REQPKT is considered as IN requesting flag.
>
> Yeah this is a known issue with musb, there is not much ISO support
> currently really. The regression should be fixed though.
>
> Sorry I don't have much ideas on how to improve things here. One
> way might be to attempt to split the large musb functions into
> smaller functions and see if that then allows finer grained control.
>
> Just to try to come up with some new ideas.. Maybe there's some way
> to swap the hardware EP config dynamically and have some packets
> mostly preconfigured and waiting to be triggered?
>
> Regards,
>
> Tony
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

[PATCH 1/2] media: rc: no need to announce major number

[Sean Young]

Since commit a60d64b15c20 ("media: lirc: lirc interface should not be
a raw decoder"), the message in the documentation is incorrect as the
module name is rc_core, not lirc_dev. Since the message is not useful,
just make the message debug and remove it from the documentation.

Signed-off-by: Sean Young 
---
 Documentation/media/uapi/rc/lirc-dev-intro.rst | 1 -
 drivers/media/rc/lirc_dev.c| 4 ++--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/media/uapi/rc/lirc-dev-intro.rst 
b/Documentation/media/uapi/rc/lirc-dev-intro.rst
index 3a74fec66d69..698e4f80270e 100644
--- a/Documentation/media/uapi/rc/lirc-dev-intro.rst
+++ b/Documentation/media/uapi/rc/lirc-dev-intro.rst
@@ -18,7 +18,6 @@ Example dmesg output upon a driver registering w/LIRC:
 .. code-block:: none
 
 $ dmesg |grep lirc_dev
-lirc_dev: IR Remote Control driver registered, major 248
 rc rc0: lirc_dev: driver mceusb registered at minor = 0
 
 What you should see for a chardev:
diff --git a/drivers/media/rc/lirc_dev.c b/drivers/media/rc/lirc_dev.c
index da3b5c095a59..24e9fbb80e81 100644
--- a/drivers/media/rc/lirc_dev.c
+++ b/drivers/media/rc/lirc_dev.c
@@ -804,8 +804,8 @@ int __init lirc_dev_init(void)
return retval;
}
 
-   pr_info("IR Remote Control driver registered, major %d\n",
-   MAJOR(lirc_base_dev));
+   pr_debug("IR Remote Control driver registered, major %d\n",
+MAJOR(lirc_base_dev));
 
return 0;
 }
-- 
2.14.3

[PATCH 2/2] media: rc: fix race condition in ir_raw_event_store_edge() handling

[Sean Young]

There is a possible race condition between the IR timeout being generated
from the timer, and new IR arriving. This could result in the timeout
being added to the kfifo after new IR arrives. On top of that, there is
concurrent write access to the kfifo from ir_raw_event_store_edge() and
the timer.

Signed-off-by: Sean Young 
---
 drivers/media/rc/rc-core-priv.h |  5 +++--
 drivers/media/rc/rc-ir-raw.c| 24 +---
 2 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index d09a06e1c17f..5e80b4273e2d 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -50,8 +50,9 @@ struct ir_raw_event_ctrl {
DECLARE_KFIFO(kfifo, struct ir_raw_event, MAX_IR_EVENT_SIZE);
ktime_t last_event; /* when last event 
occurred */
struct rc_dev   *dev;   /* pointer to the 
parent rc_dev */
-   /* edge driver */
-   struct timer_list edge_handle;
+   /* handle delayed ir_raw_event_store_edge processing */
+   spinlock_t  edge_spinlock;
+   struct timer_list   edge_handle;
 
/* raw decoder state follows */
struct ir_raw_event prev_ev;
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 2790a0d268fd..984bb82851f9 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -101,6 +101,7 @@ int ir_raw_event_store_edge(struct rc_dev *dev, bool pulse)
ev.duration = ktime_to_ns(ktime_sub(now, dev->raw->last_event));
ev.pulse = !pulse;
 
+   spin_lock(>raw->edge_spinlock);
rc = ir_raw_event_store(dev, );
 
dev->raw->last_event = now;
@@ -112,6 +113,7 @@ int ir_raw_event_store_edge(struct rc_dev *dev, bool pulse)
mod_timer(>raw->edge_handle,
  jiffies + msecs_to_jiffies(15));
}
+   spin_unlock(>raw->edge_spinlock);
 
return rc;
 }
@@ -462,12 +464,26 @@ int ir_raw_encode_scancode(enum rc_proto protocol, u32 
scancode,
 }
 EXPORT_SYMBOL(ir_raw_encode_scancode);
 
-static void edge_handle(struct timer_list *t)
+/**
+ * ir_raw_edge_handle() - Handle ir_raw_event_store_edge() processing
+ *
+ * @t: timer_list
+ *
+ * This callback is armed by ir_raw_event_store_edge(). It does two things:
+ * first of all, rather than calling ir_raw_event_handle() for each
+ * edge and waking up the rc thread, 15 ms after the first edge
+ * ir_raw_event_handle() is called. Secondly, generate a timeout event
+ * no more IR is received after the rc_dev timeout.
+ */
+static void ir_raw_edge_handle(struct timer_list *t)
 {
struct ir_raw_event_ctrl *raw = from_timer(raw, t, edge_handle);
struct rc_dev *dev = raw->dev;
-   ktime_t interval = ktime_sub(ktime_get(), dev->raw->last_event);
+   unsigned long flags;
+   ktime_t interval;
 
+   spin_lock_irqsave(>raw->edge_spinlock, flags);
+   interval = ktime_sub(ktime_get(), dev->raw->last_event);
if (ktime_to_ns(interval) >= dev->timeout) {
DEFINE_IR_RAW_EVENT(ev);
 
@@ -480,6 +496,7 @@ static void edge_handle(struct timer_list *t)
  jiffies + nsecs_to_jiffies(dev->timeout -
 ktime_to_ns(interval)));
}
+   spin_unlock_irqrestore(>raw->edge_spinlock, flags);
 
ir_raw_event_handle(dev);
 }
@@ -528,7 +545,8 @@ int ir_raw_event_prepare(struct rc_dev *dev)
 
dev->raw->dev = dev;
dev->change_protocol = change_protocol;
-   timer_setup(>raw->edge_handle, edge_handle, 0);
+   spin_lock_init(>raw->edge_spinlock);
+   timer_setup(>raw->edge_handle, ir_raw_edge_handle, 0);
INIT_KFIFO(dev->raw->kfifo);
 
return 0;
-- 
2.14.3

Hello Beautiful

[Jack]

Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.