Re: [PATCH] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.
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
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.
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
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]
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
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
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
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
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
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(&dev->raw->edge_spinlock); rc = ir_raw_event_store(dev, &ev); dev->raw->last_event = now; @@ -112,6 +113,7 @@ int ir_raw_event_store_edge(struct rc_dev *dev, bool pulse) mod_timer(&dev->raw->edge_handle, jiffies + msecs_to_jiffies(15)); } + spin_unlock(&dev->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(&dev->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(&dev->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(&dev->raw->edge_handle, edge_handle, 0); + spin_lock_init(&dev->raw->edge_spinlock); + timer_setup(&dev->raw->edge_handle, ir_raw_edge_handle, 0); INIT_KFIFO(dev->raw->kfifo); return 0; -- 2.14.3
Hello Beautiful
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.