From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933784AbcIUN0S (ORCPT ); Wed, 21 Sep 2016 09:26:18 -0400 Received: from ni.piap.pl ([195.187.100.4]:59596 "EHLO ni.piap.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932964AbcIUN0O (ORCPT ); Wed, 21 Sep 2016 09:26:14 -0400 X-Greylist: delayed 552 seconds by postgrey-1.27 at vger.kernel.org; Wed, 21 Sep 2016 09:26:14 EDT From: khalasa@piap.pl (Krzysztof =?utf-8?Q?Ha=C5=82asa?=) To: Hans Verkuil Cc: Andrey Utkin , linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, Mauro Carvalho Chehab , Hans Verkuil , Ismael Luceno , Bluecherry Maintainers , andrey_utkin@fastmail.com Subject: Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression) References: <20160915130441.ji3f3jiiebsnsbct@acer> <9cbb2079-f705-5312-d295-34bc3c8dadb9@xs4all.nl> Date: Wed, 21 Sep 2016 15:16:57 +0200 In-Reply-To: <9cbb2079-f705-5312-d295-34bc3c8dadb9@xs4all.nl> (Hans Verkuil's message of "Thu, 15 Sep 2016 15:15:53 +0200") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-KLMS-Rule-ID: 1 X-KLMS-Message-Action: clean X-KLMS-AntiSpam-Lua-Profiles: 103097 [Sep 21 2016] X-KLMS-AntiSpam-Version: 5.6.0.28 X-KLMS-AntiSpam-Envelope-From: khalasa@piap.pl X-KLMS-AntiSpam-Rate: 0 X-KLMS-AntiSpam-Status: not_detected X-KLMS-AntiSpam-Method: none X-KLMS-AntiSpam-Info: LuaCore: 112 112 a2b0103ce64cfdf8d45a470d2c6a59d52eef415f, Auth:dkim=none X-KLMS-AntiSpam-Interceptor-Info: scan successful X-KLMS-AntiPhishing: Clean, 2016/09/20 16:40:56 X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/09/21 06:05:00 #8056877 X-KLMS-AntiVirus-Status: Clean, skipped Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hans Verkuil writes: > That was probably the reason for the pci_read_config_word in the reg_write > code. Try putting that back (and just that). Yes. I guess a single pci_read_config_word() would suffice. Though it would obviously be much better to identify the place in the driver which needs to have the write buffers flushed, and add a read() just there. The interrupt handler maybe (e.g. just before the return IRQ_HANDLED)? OTOH this may be some sort of timing problem, I mean the faster code may put too much stress on the SOLO chip. Doesn't happen here so I can't test the cure. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland