* [PATCH v2 0/4] printk: Fixes and hardening related to KERN_CONT
From: Petr Mladek @ 2016-11-09 12:41 UTC (permalink / raw)
To: Linus Torvalds
Cc: Joe Perches, Andrew Morton, Sergey Senozhatsky, Steven Rostedt,
Jason Wessel, Jaroslav Kysela, Takashi Iwai, Chris Mason,
Josef Bacik, David Sterba, linux-kernel, Petr Mladek
The first patch fixes a messed output of continuous lines
when printing backtraces for all CPUs via NMI.
The other patches fix problems that I noticed when working
on the first patch.
I have incorporated the feedback and did much more testing.
Åll patches have changed so I did not add the taken Reviews
and Acks.
Changes against v1:
+ used const char in printk_nmi_flush_buffer()
+ print the final newline with KERN_CONT in
printk_nmi_flush_buffer()
+ used printk_skip_level() instead of the hardcoded '2'
in all patches.
+ define PRINTK_MAX_SINGLE_HEADER_LEN to avoid hardcoding
the buffer size; it simplified the code in btrfs_printk()
+ ignore KERN_CONT in __snd_printk(); the lines were hard
to read because of the added stuff like <filename:line>
for each piece.
Petr Mladek (4):
printk/NMI: Handle continuous lines and missing newline
printk/kdb: Handle more message headers
printk/btrfs: Handle more message headers
printk/sound: Handle more message headers
fs/btrfs/super.c | 26 +++++++++-------
include/linux/printk.h | 10 ++++++
kernel/debug/kdb/kdb_io.c | 2 +-
kernel/printk/nmi.c | 78 ++++++++++++++++++++++++++++++-----------------
sound/core/misc.c | 20 ++++++++----
5 files changed, 90 insertions(+), 46 deletions(-)
--
1.8.5.6
^ permalink raw reply
* Re: btrfs scrub with unexpected results
From: Tom Arild Naess @ 2016-11-09 12:40 UTC (permalink / raw)
To: Austin S. Hemmelgarn, linux-btrfs
In-Reply-To: <f8ba65d7-5854-e853-221c-4b7f4991b21a@gmail.com>
Thanks for your lengthy answer. Just after posting my question I
realized that the last reboot I did resulted in the filesystem being
mounted RO. I started a "btrfs check --repair" but terminated it after
six days, since I really need to get the backup up and running again. I
have decided to start with a fresh btrfs to rule out any errors created
by old kernels.
I find it unlikely that my problems are caused by any hardware faults,
as the server has been running 24/7 for six months with nightly backups
every day without any problems. Also the system has been scrubbed once a
month without issues in the same timespan. Every time there have been
scrubbing errors, these have all occurred in the the same old snapshots
that I created from my hard link backups. These were the first snapshots
I ever took, and back then I ran a quite old kernel.
If a fresh btrfs does not solve my problems, I will go through the list
you provided. Some have already been handled earlier, like memtest (did
a long run before the system was put into service). I am also running
smartctl as a service, and nothing is reported there either.
One last thing: The CPU on the server is a really low end AMD C-70, and
I wonder if it's a little too weak for a storage server? Not in the day
to day, but when a repair is needed. Seems like more than six days for a
repair on 4x 3TB system is way too long?
--
Tom Arild Naess
On 03. nov. 2016 12:51, Austin S. Hemmelgarn wrote:
> On 2016-11-02 17:55, Tom Arild Naess wrote:
>> Hello,
>>
>> I have been running btrfs on a file server and backup server for a
>> couple of years now, both set up as RAID 10. The file server has been
>> running along without any problems since day one. My problems has been
>> with the backup server.
>>
>> A little background about the backup server before I dive into the
>> problems. The server was a new build that was set to replace an aging
>> machine, and my intention was to start using btrfs send/receive instead
>> of hard links for the backups. Since I had 8x the space on the new
>> server, I just rsynced the whole lot of old backups to the new server. I
>> then made some scripts that created snapshots from the old file
>> hierarchy. As I started rewriting my backup scripts (on file server and
>> backup server) to use send/receive, I also tested scrubbing to see that
>> everything was OK. After doing this a few times, scrub found
>> unrecoverable files. This, I thought, should not be possible on new
>> disks. I tried to get some help on this list, but no answers were found,
>> and since I was unable to find what triggered this, I just stopped using
>> send/receive, and let my old backup regime live on on this new backup
>> server as well. I don't remember how I fixed the errors, but I guess I
>> just replaced the offending files with fresh ones, and scrub ran without
>> any more problems. I decided to let things just run like this, and set
>> up scrubbing on a monthly schedule.
>>
>> Last night I got the unpleasant mail from cron telling me that scrub had
>> failed (for the first time in over a year). Since I was running on an
>> older kernel (4.2.x), I decided to upgrade, and went for the latest of
>> the longterm branches, namely 4.4.30. After rebooting I did (for
>> whatever reason) check one of the offending files, and I could read the
>> file just fine! I checked the rest of the bunch, and all files read
>> fine, and had the same md5 sum as the originals! All these files were
>> located in those old snapshots. I thought that maybe this was because of
>> a bug resolved since my last kernel. Then I ran a new scrub, and this
>> one also reported unrecoverable errors. This time on two other files but
>> also in some of the old snapshots. I tried reading the files, and got
>> the expected I/O errors. One reboot later, these files reads just fine
>> again!
> So, based on what your saying, this sounds like you have hardware
> problems. The fact that a reboot is fixing I/O errors caused by
> checksum mismatches tells me that either (in relative order of
> likelihood):
> 1. You have some bad RAM (probably not much given the small number of
> errors).
> 2. You have some bad hardware in the storage path other than the
> physical media in your storage devices. Any of the storage
> controller, the cabling/back-plane, or the on-disk cache having issues
> can cause things like this to happen.
> 3. Some other component is having issues. A PSU that's not providing
> clean power could cause this also, but is not likely unless you've got
> a really cheap PSU.
> 4. You've found an odd corner case in BTRFS that nobody's reported
> before (this is pretty much certain if you rule out the hardware).
>
> Based on this, what I would suggest doing (in order):
> 1. Run self-tests on the storage devices using smartctl (and see if
> they think they're healthy or not). I doubt that this will show
> anything, but it's quick and easy to test and doesn't require taking
> the system off-line, so it's one of the first things to check.
> 2. Check your cabling. This is really easy to verify, just disconnect
> and reconnect everything and see if you still have problems. If you
> do still have problems, try switching out one data (SATA/SAS/whatever
> you use) cable at a time and see if you still have problems (it takes
> longer than using a cable tester, but finding a working cable tester
> for internal computer cables is hard).
> 3. Check your RAM. Memtest86 and Memtest86+ are the best options for
> general testing, but I doubt that those will turn up anything. If you
> have spare RAM, I'd actually suggest just swapping out one DIMM at a
> time and seeing if you still get the behavior your seeing.
> 4. Check your PSU. I list this before the storage controller and
> disks because it's pretty easy to test (you just need a PSU tester,
> which are about 15 USD on Amazon, or a good multi-meter, some wire,
> and some basic knowledge of the wiring), but after the RAM because
> it's significantly less likely to be the problem than your RAM unless
> you've got a really cheap PSU.
> 5. Check your storage controller. This is _hard_ to do unless you
> have a spare known working storage controller.
> 6. If you have any extra expansion cards your not using (NIC's, HBA's,
> etc), try pulling them out. This sounds odd, but I've seen cases
> where the driver for something I wasn't using at all was causing
> problems elsewhere.
>
> Now, assuming none of that turns anything up, then you probably have
> found a bug in BTRFS, but I have no idea in this case how we would go
> about debugging it as it seems to be some kind of in-memory data
> corruption (maybe a buffer overflow?).
>
>>
>> Some system info:
>>
>> $ uname -a
>> Linux backup 4.4.30-1-lts #1 SMP Tue Nov 1 22:09:20 CET 2016 x86_64
>> GNU/Linux
>>
>> $ btrfs --version
>> btrfs-progs v4.8.2
>>
>> $ btrfs fi show /backup
>> Label: none uuid: 8825ce78-d620-48f5-9f03-8c4568d3719d
>> Total devices 4 FS bytes used 2.81TiB
>> devid 1 size 2.73TiB used 1.41TiB path /dev/sdb
>> devid 2 size 2.73TiB used 1.41TiB path /dev/sda
>> devid 3 size 2.73TiB used 1.41TiB path /dev/sdd
>> devid 4 size 2.73TiB used 1.41TiB path /dev/sdc
>
^ permalink raw reply
* [SECILC] does not seem to filter redundant attributes and rules
From: Dominick Grift @ 2016-11-09 12:40 UTC (permalink / raw)
To: selinux
[-- Attachment #1.1: Type: text/plain, Size: 1078 bytes --]
I am in the process of a DSSP rewrite, taking a different approach this
time.
However I encountered something that seems suboptimal:
SECILC seems to not filter redundant attributes and rules
Example i have a type attribute and it has rules associated with it.
However, the type attribute is not associated with any types.
I was hoping that SECILC would be smart enough to determine that it
might as well filter both the type attribute as well as the rules
associated with it.
To reproduce:
git clone https://github.com/DefenSec/dssp1-base.git
cd dssp1-base
secilc `ls *.cil`
sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30
seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30
Am i expecting the impossible by expecting SECILC to be smart enough to
determine that something is redundant, and that it can be filtered out
until it becomes applicable?
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] spapr: Fix migration of PCI host bridges from qemu-2.7
From: Alexey Kardashevskiy @ 2016-11-09 12:39 UTC (permalink / raw)
To: David Gibson; +Cc: mdroth, agraf, thuth, lvivier, qemu-ppc, qemu-devel
In-Reply-To: <20161109121911.GH427@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 3726 bytes --]
On 09/11/16 23:19, David Gibson wrote:
> On Wed, Nov 09, 2016 at 04:14:25PM +1100, Alexey Kardashevskiy wrote:
>> On 09/11/16 14:45, David Gibson wrote:
>>> daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration from
>>> qemu-2.7 to the current version. It split the device's MMIO window into
>>> two pieces for 32-bit and 64-bit MMIO.
>>>
>>> The patch included backwards compatibility code to convert the old property
>>> into the new format. However, the property value was also transferred in
>>> the migration stream and compared with a (probably unwise) VMSTATE_EQUAL.
>>> So, the "raw" value from 2.7 is compared to the new style converted value
>>> from (pre-)2.8 giving a mismatch and migration failure.
>>>
>>> Although it would be technically possible to fix this in a way allowing
>>> backwards migration, that would leave an ugly legacy around indefinitely.
>>> This patch takes the simpler approach of bumping the migration version,
>>> dropping the unwise VMSTATE_EQUAL (and some equally unwise ones around it)
>>> and ignoring them on an incoming migration.
>>>
>>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>>> ---
>>> hw/ppc/spapr_pci.c | 17 +++++++++++------
>>> 1 file changed, 11 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
>>> index 7cde30e..7f1cc29 100644
>>> --- a/hw/ppc/spapr_pci.c
>>> +++ b/hw/ppc/spapr_pci.c
>>> @@ -1658,19 +1658,24 @@ static int spapr_pci_post_load(void *opaque, int version_id)
>>> return 0;
>>> }
>>>
>>> +static bool version_before_3(void *opaque, int version_id)
>>> +{
>>> + return version_id < 3;
>>> +}
>>> +
>>> static const VMStateDescription vmstate_spapr_pci = {
>>> .name = "spapr_pci",
>>> - .version_id = 2,
>>> + .version_id = 3,
>>> .minimum_version_id = 2,
>>> .pre_save = spapr_pci_pre_save,
>>> .post_load = spapr_pci_post_load,
>>> .fields = (VMStateField[]) {
>>> VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
>>
>>
>> You could probably go one step further and get rid of @buid as well.
>
> I thought about it. buid at least is specified state that's
> vanishingly unlikely to change or disappear from the device. It also
> does serve to make sure that QOM instance matching - which is always a
> bit black magicy to me - is lining things up correctly.
afaict to fix matching properly, TYPE_SYS_BUS_DEVICE needs get_dev_path()
hook, just like spapr_vio_get_dev_name; otherwise SPAPR PHB in migration
always named as "spapr_pci" but yes, this would be much outside of the
scope of this patch :-/
>
>>
>> Nevertheless, this works,
>>
>> Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>
>>
>>
>>
>>> - VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
>>> - VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
>>> - VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
>>> - VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
>>> - VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
>>> + VMSTATE_UNUSED_TEST(version_before_3, sizeof(uint32_t) /* dma_liobn[0] */
>>> + + sizeof(uint64_t) /* mem_win_addr */
>>> + + sizeof(uint64_t) /* mem_win_size */
>>> + + sizeof(uint64_t) /* io_win_addr */
>>> + + sizeof(uint64_t) /* io_win_size */),
>>> VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
>>> vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
>>> VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
>>>
>>
>>
>
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 839 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] gitk: memory consumption improvements
From: Markus Hitter @ 2016-11-09 12:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Paul Mackerras
In-Reply-To: <xmqqtwbhbql9.fsf@gitster.mtv.corp.google.com>
Am 08.11.2016 um 22:37 schrieb Junio C Hamano:
> Are all semi-modern Tcl/Tk in service have this -undo thing so that
> we can pass unconditionally to the text widget like the patch does?
Good point. As far as my research goes, this flag was introduced in Nov. 2001:
http://core.tcl.tk/tk/info/5265df93d207cec0
To defend Gitk developers, the Tk guys apparently change their mind on the default value from time to time. Official documentation says nothing about a default, the proposal from 2001 talks about -undo 0 as default and there are recent commits changing this default:
http://core.tcl.tk/tk/info/549d2f56757408f3
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
^ permalink raw reply
* [Buildroot] [PATCH] qt5webkit: Get sources from Qt-5-unofficial-builds
From: Alexey Brodkin @ 2016-11-09 12:38 UTC (permalink / raw)
To: buildroot
Instead of messing with git we may get tarballs of obsolete but still
existing submodules as we used to but from a bit different location.
It turned out Qt people still create packages for obsolete submodules
for so-called "unofficial builds", see [1].
[1] https://wiki.qt.io/Qt-5-unofficial-builds
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Peter Seiderer <ps.report@gmx.net>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Julien Corjon <corjon.j@ecagroup.com>
Cc: Gary Bisson <gary.bisson@boundarydevices.com>
---
package/qt5/qt5.mk | 1 +
package/qt5/qt5webkit/qt5webkit.hash | 4 ++--
package/qt5/qt5webkit/qt5webkit.mk | 14 +++-----------
3 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/package/qt5/qt5.mk b/package/qt5/qt5.mk
index d25f663662ee..e937e234b596 100644
--- a/package/qt5/qt5.mk
+++ b/package/qt5/qt5.mk
@@ -1,6 +1,7 @@
QT5_VERSION_MAJOR = 5.6
QT5_VERSION = $(QT5_VERSION_MAJOR).2
QT5_SITE = http://download.qt.io/official_releases/qt/$(QT5_VERSION_MAJOR)/$(QT5_VERSION)/submodules
+QT5_SNAPSHOTS_SITE = http://download.qt.io/snapshots/qt/$(QT5_VERSION_MAJOR)/$(QT5_VERSION)/latest_src/submodules
include $(sort $(wildcard package/qt5/*/*.mk))
define QT5_LA_PRL_FILES_FIXUP
diff --git a/package/qt5/qt5webkit/qt5webkit.hash b/package/qt5/qt5webkit/qt5webkit.hash
index 96b8bdd6909a..309f776b3ff3 100644
--- a/package/qt5/qt5webkit/qt5webkit.hash
+++ b/package/qt5/qt5webkit/qt5webkit.hash
@@ -1,2 +1,2 @@
-# locally computed
-sha256 bdd659573e7e75cd4ad57b7160a7353d98d21a6fef06e4fb9e114a5b1f1e9dab qt5webkit-b35917bcb44d7f200af0f4ac68a126fa0aa8d93d.tar.gz
+# Hash from: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/submodules/qtwebkit-opensource-src-5.6.2.tar.xz.mirrorlist
+sha256 528a6b8b1c5095367b26e8ce4f3a46bb739e2e9913ff4dfc6ef58a04fcd73966 qtwebkit-opensource-src-5.6.2.tar.xz
diff --git a/package/qt5/qt5webkit/qt5webkit.mk b/package/qt5/qt5webkit/qt5webkit.mk
index 378cdf78573e..f93ef6c48ce3 100644
--- a/package/qt5/qt5webkit/qt5webkit.mk
+++ b/package/qt5/qt5webkit/qt5webkit.mk
@@ -4,10 +4,9 @@
#
################################################################################
-QT5WEBKIT_VERSION = b35917bcb44d7f200af0f4ac68a126fa0aa8d93d
-# Using GitHub since it supports downloading tarballs from random commits.
-# The http://code.qt.io/cgit/qt/qtwebkit.git/ repo doesn't allow to do so.
-QT5WEBKIT_SITE = $(call github,qtproject,qtwebkit,$(QT5WEBKIT_VERSION))
+QT5WEBKIT_VERSION = $(QT5_VERSION)
+QT5WEBKIT_SITE = $(QT5_SNAPSHOTS_SITE)
+QT5WEBKIT_SOURCE = qtwebkit-opensource-src-$(QT5WEBKIT_EXAMPLES_VERSION).tar.xz
QT5WEBKIT_DEPENDENCIES = \
host-bison host-flex host-gperf host-python host-ruby \
qt5base sqlite
@@ -43,14 +42,7 @@ define QT5WEBKIT_PYTHON2_SYMLINK
endef
QT5WEBKIT_PRE_CONFIGURE_HOOKS += QT5WEBKIT_PYTHON2_SYMLINK
-# Since we get the source from git, generated header files are not included.
-# qmake detects that header file generation (using the syncqt tool) must be
-# done based on the existence of a .git directory (cfr. the git_build config
-# option which is set in qt_build_paths.prf).
-# So, to make sure that qmake detects that header files must be generated,
-# create an empty .git directory.
define QT5WEBKIT_CONFIGURE_CMDS
- mkdir -p $(@D)/.git
(cd $(@D); $(TARGET_MAKE_ENV) $(QT5WEBKIT_ENV) $(HOST_DIR)/usr/bin/qmake)
endef
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] leds: Add mutex protection in brightness_show()
From: Pavel Machek @ 2016-11-09 12:38 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: linux-leds, linux-kernel, Hans de Goede, Sakari Ailus,
Andrew Lunn
In-Reply-To: <1478245962-15706-1-git-send-email-j.anaszewski@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]
Hi!
> Initially the claim about no need for lock in brightness_show()
> was valid as the function was just returning unchanged
> LED brightness. After the addition of led_update_brightness() this
The claim was probably wrong from the day one, unless brightness is of
type "atomic_t".
/* Ensures consistent access to the LED Flash Class device */
struct mutex led_access;
};
This should really list fields that are protected by led_access.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] leds: Add mutex protection in brightness_show()
From: Pavel Machek @ 2016-11-09 12:37 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Hans de Goede, linux-leds, linux-kernel, Sakari Ailus,
Andrew Lunn
In-Reply-To: <32b106fa-1315-3e27-07b6-1f91ac9773c4@samsung.com>
[-- Attachment #1: Type: text/plain, Size: 4800 bytes --]
Hi!
> >>>>On 04-11-16 08:52, Jacek Anaszewski wrote:
> >>>>>Initially the claim about no need for lock in brightness_show()
> >>>>>was valid as the function was just returning unchanged
> >>>>>LED brightness. After the addition of led_update_brightness() this
> >>>>>is no longer true, as the function can change the brightness if
> >>>>>a LED class driver implements brightness_get op. It can lead to
> >>>>>races between led_update_brightness() and led_set_brightness(),
> >>>>>resulting in overwriting new brightness with the old one before
> >>>>>the former is written to the device.
> >>>>>
> >>>>>Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
> >>>>>Cc: Hans de Goede <hdegoede@redhat.com>
> >>>>>Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> >>>>>Cc: Pavel Machek <pavel@ucw.cz>
> >>>>>Cc: Andrew Lunn <andrew@lunn.ch>
> >>>>>---
> >>>>> drivers/leds/led-class.c | 3 ++-
> >>>>> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>>>>
> >>>>>diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> >>>>>index 731e4eb..0c2307b 100644
> >>>>>--- a/drivers/leds/led-class.c
> >>>>>+++ b/drivers/leds/led-class.c
> >>>>>@@ -30,8 +30,9 @@ static ssize_t brightness_show(struct device *dev,
> >>>>> {
> >>>>> struct led_classdev *led_cdev = dev_get_drvdata(dev);
> >>>>>
> >>>>>- /* no lock needed for this */
> >>>>>+ mutex_lock(&led_cdev->led_access);
> >>>>> led_update_brightness(led_cdev);
> >>>>>+ mutex_unlock(&led_cdev->led_access);
> >>>>>
> >>>>> return sprintf(buf, "%u\n", led_cdev->brightness);
> >>>>> }
> >>>>>
> >>>>
> >>>>I'm afraid that this fix is not enough, the led_access lock is only
> >>>>held when the brightness is being updated through sysfs, not for
> >>>>trigger / sw-blinking updates (which cannot take a mutex as they
> >>>>may be called from non blocking contexts).
> >>>>
> >>>>We may need to consider to add a spinlock to the led_classdev and
> >>>>always lock that when calling into the driver, except for when
> >>>>the driver has a brightness_set_blocking callback. Which will need
> >>>>special handling.
> >>>
> >>>led_update_brightness() currently has two users besides LED subsystem
> >>>(at least grep reports those places):
> >>>
> >>>1. v4l2-flash-led-class wrapper, for which led_access mutex was
> >>> introduced. Its purpose was to disable LED sysfs interface while
> >>> v4l2-flash wrapper takes over control of LED class device
> >>> (not saying that the mutex wasn't missing even without this
> >>> use case). Now I've realized that the call to
> >>> led_sysfs_is_disabled() is missing in this patch.
> >>>2. /drivers/platform/x86/thinkpad_acpi.c - it calls
> >>> led_update_brightness() on suspend
> >>>
> >>>I think that the best we can now do is to add
> >>>lockdep_assert_held(&led_cdev->led_access) in led_update_brightness()
> >>>and a description saying that the caller has to acquire led_access
> >>>lock before calling it. Similarly as in case of
> >>>led_sysfs_disable()/led_sysfs_disable().
> >>
> >>The problem is not only callers of led_update_brightness() not holding
> >>led_cdev->led_access, the problem is also callers of led_set_brightness
> >>not holding led_cdev->led_access and they cannot take this lock because
> >>they may be called from a non-blocking context.
> >
> >Thinking more about this, using a spinlock is also not going to work
> >because led_cdev->brightness_set_blocking and led_cdev->brightness_get
> >can both block and thus cannot be called with a spinlock held.
> >
> >I think that we need to just make this a problem of the led drivers
> >and in include/linux/leds.h document that the led-core does not do
> >locking and that the drivers themselves need to protect against
> >their brightness_set / brightness_get callbacks when necessary.
>
> Thanks for the analysis. Either way, this patch, with the modification
> I mentioned in my previous message is required to assure proper
> LED sysfs locking.
>
> Regarding the races between user and atomic context, I think that
> it should be system root's responsibility to define LED access
> policy. If a LED is registered for any trigger events then setting
> brightness from user space should be made impossible. Such a hint
> could be even added to the Documentation/leds/leds-class.txt.
No, kernel locking may not depend on "root did not do anything
stupid". Sorry.
Is there problem with led_access becoming a spinlock, and
brightness_set_blocking taking it internally while it reads the
brightness (but not while sleeping)?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* [PATCH] drm_fourcc: Document linear modifier
From: Daniel Vetter @ 2016-11-09 12:36 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, hoegsberg
Not setting the fb modifiers flag is something different from setting
the fb modifiers to 0 (which means explicitly linear). We kinda failed
to document that properly. Spotted by Kristian.
Cc: hoegsberg@google.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
include/uapi/drm/drm_fourcc.h | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index da49f69e4d7e..2fca7e1f6aab 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -172,6 +172,16 @@ extern "C" {
* authoritative source for all of these.
*/
+/*
+ * Linear Layout
+ *
+ * Just plain linear layout. Note that this is different from no specifying any
+ * modifier (e.g. not setting DRM_MODE_FB_MODIFIERS in the DRM_ADDFB2 ioctl),
+ * which tells the driver to also take driver-internal information into account
+ * and so might actually result in a tiled framebuffer.
+ */
+#define DRM_FORMAT_MOD_LINEAR fourcc_mod_code(NONE, 0)
+
/* Intel framebuffer modifiers */
/*
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [Qemu-devel] [Bug 1546445] Re: support vhost user without specifying vhostforce
From: Louis Bouchard @ 2016-11-09 12:18 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20160217094237.24220.45325.malonedeb@chaenomeles.canonical.com>
** Tags removed: sts-sru
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1546445
Title:
support vhost user without specifying vhostforce
Status in Ubuntu Cloud Archive:
Fix Released
Status in Ubuntu Cloud Archive kilo series:
Fix Released
Status in QEMU:
Fix Released
Status in qemu package in Ubuntu:
Fix Released
Status in qemu source package in Wily:
Fix Released
Bug description:
[Impact]
* vhost-user falls back to virtio-net which causes performance lose
without specifying the vhostforce option. But it should be the default
behavior for vhost-user, since guests using PMD doesn't support msi-x.
[Test Case]
create a vhost-user virtio backend without specifying the vhostforce option, i.e. -netdev type=vhost-user,id=mynet1,chardev=<char_dev_for_the_controll_channel>
start the VM
vhost-user is not enabled
[Regression Potential]
* none
vhost user nic doesn't support non msi guests(like pxe stage) by default.
Vhost user nic can't fall back to qemu like normal vhost net nic does. So we should
enable it for non msi guests.
The problem has been fix in qemu upstream -
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=24f938a682d934b133863eb421aac33592f7a09e.
And the patch needs to be backported to 1:2.2+dfsg-5expubuntu9.8 .
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions
^ permalink raw reply
* [PATCH] nand gpmi fix erased block bitflip counting
From: w.cappelle @ 2016-11-09 12:35 UTC (permalink / raw)
To: linux-mtd; +Cc: w.cappelle
In-Reply-To: <1478694920-6453-1-git-send-email-w.cappelle@televic.com>
From: Wouter Cappelle <w.cappelle@televic.com>
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 8339d4f..6ae118c 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1217,6 +1217,7 @@ static bool gpmi_erased_check(struct gpmi_nand_data *this,
int base = geo->ecc_chunkn_size * chunk;
unsigned int flip_bits = 0, flip_bits_noecc = 0;
uint64_t *buf = (uint64_t *)this->data_buffer_dma;
+ unsigned char *chunkbuf =(unsigned char*) this->data_buffer_dma;
unsigned int threshold;
int i;
@@ -1224,13 +1225,6 @@ static bool gpmi_erased_check(struct gpmi_nand_data *this,
if (threshold > geo->ecc_strength)
threshold = geo->ecc_strength;
- /* Count bitflips */
- for (i = 0; i < geo->ecc_chunkn_size; i++) {
- flip_bits += hweight8(~data[base + i]);
- if (flip_bits > threshold)
- return false;
- }
-
/*
* Read out the whole page with ECC disabled, and check it again,
* This is more strict then just read out a chunk, and it makes
@@ -1246,6 +1240,12 @@ static bool gpmi_erased_check(struct gpmi_nand_data *this,
return false;
}
+ /* Count bitflips in the current chunk for correct stats reporting */
+ for (i = 0; i < geo->ecc_chunkn_size; i++) {
+ flip_bits += hweight8(~chunkbuf[base + i]);
+ }
+
+
/* Tell the upper layer the bitflips we corrected. */
mtd->ecc_stats.corrected += flip_bits;
*max_bitflips = max_t(unsigned int, *max_bitflips, flip_bits);
--
2.7.4
^ permalink raw reply related
* gpmi detection of erased pages
From: w.cappelle @ 2016-11-09 12:35 UTC (permalink / raw)
To: linux-mtd; +Cc: w.cappelle
I'm using BCH8 on a 2k nand page and created a testpage with 6 bitflips
at following locations:
0x02D:FB
0x057:FE
0xA5:FB
0x16A:FB
0x18A:DF
0x4EE:FE
When reading the page through the driver, the page is uncorrectable (as
expected), then it will verify if the page is erased (gpmi_erased_check).
There i can see that the first count of the first subpage, is returning me
it detected 7 bitflips (should be 5 in that subpage). The second count of
bitflips on the full raw page returns me the correct amount of bitflips
(being 6 for the complete page).
I Don't really see the need of the first subpage check, except of speed
improvement. But as it is failing due to the gpmi block trying to repair the
page and alternating the wrong bits, I would propose to either increase the
threshold of the first check with the max number of repairable bitflips the
gpmi block is set to, or just skip the first check since on empty pages it will
however not make a difference in speed. For real uncorrectable pages, this will
not have a huge speed penalty due to the unlikely event that this will happen.
I propose following patch to be be applied to detect the correct number of
bitflips based on the raw nand read data.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2] docs: add document to explain the usage of vNVDIMM
From: Stefan Hajnoczi @ 2016-11-09 12:35 UTC (permalink / raw)
To: Haozhong Zhang; +Cc: qemu-devel, Xiao Guangrong, Dr. David Alan Gilbert
In-Reply-To: <20161109010448.21344-1-haozhong.zhang@intel.com>
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
On Wed, Nov 09, 2016 at 09:04:48AM +0800, Haozhong Zhang wrote:
> Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
> Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> Changes since v1:
> * explicitly state the block window mode is not supported (Stefan Hajnoczi)
> * typo fix: label_size ==> label-size (David Alan Gilbert)
> ---
> docs/nvdimm.txt | 124 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 124 insertions(+)
> create mode 100644 docs/nvdimm.txt
Great. This patch can go through Michael Tsirkin's tree alongside the
other current nvdimm patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v4 09/11] arm/arm64: add initial gicv3 support
From: Andre Przywara @ 2016-11-09 12:35 UTC (permalink / raw)
To: Andrew Jones, kvm, kvmarm, qemu-devel, qemu-arm
Cc: pbonzini, peter.maydell, alex.bennee, marc.zyngier, eric.auger,
christoffer.dall
In-Reply-To: <1478636499-14339-10-git-send-email-drjones@redhat.com>
Hi,
On 08/11/16 20:21, Andrew Jones wrote:
> Signed-off-by: Andrew Jones <drjones@redhat.com>
>
> ---
> v4:
> - only take defines from kernel we need now [Andre]
> - simplify enable by not caring if we reinit the distributor [drew]
> v2:
> - configure irqs as NS GRP1
> ---
> lib/arm/asm/arch_gicv3.h | 42 +++++++++++++++++++++
> lib/arm/asm/gic-v3.h | 92 ++++++++++++++++++++++++++++++++++++++++++++++
> lib/arm/asm/gic.h | 1 +
> lib/arm/gic.c | 56 ++++++++++++++++++++++++++++
> lib/arm64/asm/arch_gicv3.h | 44 ++++++++++++++++++++++
> lib/arm64/asm/gic-v3.h | 1 +
> lib/arm64/asm/sysreg.h | 44 ++++++++++++++++++++++
> 7 files changed, 280 insertions(+)
> create mode 100644 lib/arm/asm/arch_gicv3.h
> create mode 100644 lib/arm/asm/gic-v3.h
> create mode 100644 lib/arm64/asm/arch_gicv3.h
> create mode 100644 lib/arm64/asm/gic-v3.h
> create mode 100644 lib/arm64/asm/sysreg.h
>
> diff --git a/lib/arm/asm/arch_gicv3.h b/lib/arm/asm/arch_gicv3.h
> new file mode 100644
> index 000000000000..81a1e5f6c29c
> --- /dev/null
> +++ b/lib/arm/asm/arch_gicv3.h
> @@ -0,0 +1,42 @@
> +/*
> + * All ripped off from arch/arm/include/asm/arch_gicv3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_ARCH_GICV3_H_
> +#define _ASMARM_ARCH_GICV3_H_
> +
> +#ifndef __ASSEMBLY__
> +#include <libcflat.h>
> +#include <asm/barrier.h>
> +#include <asm/io.h>
> +
> +#define __stringify xstr
> +
> +#define __ACCESS_CP15(CRn, Op1, CRm, Op2) p15, Op1, %0, CRn, CRm, Op2
> +
> +#define ICC_PMR __ACCESS_CP15(c4, 0, c6, 0)
> +#define ICC_IGRPEN1 __ACCESS_CP15(c12, 0, c12, 7)
> +
> +static inline void gicv3_write_pmr(u32 val)
> +{
> + asm volatile("mcr " __stringify(ICC_PMR) : : "r" (val));
> +}
> +
> +static inline void gicv3_write_grpen1(u32 val)
> +{
> + asm volatile("mcr " __stringify(ICC_IGRPEN1) : : "r" (val));
> + isb();
> +}
> +
> +static inline u64 gicv3_read_typer(const volatile void __iomem *addr)
> +{
> + u64 val = readl(addr);
> + val |= (u64)readl(addr + 4) << 32;
> + return val;
> +}
> +
> +#endif /* !__ASSEMBLY__ */
> +#endif /* _ASMARM_ARCH_GICV3_H_ */
> diff --git a/lib/arm/asm/gic-v3.h b/lib/arm/asm/gic-v3.h
> new file mode 100644
> index 000000000000..03321f8c860f
> --- /dev/null
> +++ b/lib/arm/asm/gic-v3.h
> @@ -0,0 +1,92 @@
> +/*
> + * All GIC* defines are lifted from include/linux/irqchip/arm-gic-v3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_GIC_V3_H_
> +#define _ASMARM_GIC_V3_H_
> +
> +#ifndef _ASMARM_GIC_H_
> +#error Do not directly include <asm/gic-v3.h>. Include <asm/gic.h>
> +#endif
> +
> +#define GICD_CTLR 0x0000
> +#define GICD_TYPER 0x0004
So if we share the distributor register definition with GICv2, these
shouldn't be here, but in gic.h.
But this is the right naming scheme we should use (instead of GIC_DIST_xxx).
Now this gets interesting with your wish to both share the definitions
for the GICv2 and GICv3 distributors, but also stick to the names the
kernel uses (because they differ between the two) ;-)
So now you loose the greppability for either GIC_DIST_CTR or GICD_TYPER,
for instance.
> +#define GICD_IGROUPR 0x0080
> +
> +#define GICD_CTLR_RWP (1U << 31)
> +#define GICD_CTLR_ARE_NS (1U << 4)
> +#define GICD_CTLR_ENABLE_G1A (1U << 1)
> +#define GICD_CTLR_ENABLE_G1 (1U << 0)
> +
> +#define GICR_TYPER 0x0008
> +#define GICR_IGROUPR0 GICD_IGROUPR
> +#define GICR_TYPER_LAST (1U << 4)
> +
> +
> +#include <asm/arch_gicv3.h>
> +
> +#ifndef __ASSEMBLY__
> +#include <asm/setup.h>
> +#include <asm/smp.h>
> +#include <asm/processor.h>
> +#include <asm/io.h>
> +
> +struct gicv3_data {
> + void *dist_base;
> + void *redist_base[NR_CPUS];
> + unsigned int irq_nr;
> +};
> +extern struct gicv3_data gicv3_data;
> +
> +#define gicv3_dist_base() (gicv3_data.dist_base)
> +#define gicv3_redist_base() (gicv3_data.redist_base[smp_processor_id()])
> +#define gicv3_sgi_base() (gicv3_data.redist_base[smp_processor_id()] + SZ_64K)
> +
> +extern int gicv3_init(void);
> +extern void gicv3_enable_defaults(void);
> +
> +static inline void gicv3_do_wait_for_rwp(void *base)
> +{
> + int count = 100000; /* 1s */
> +
> + while (readl(base + GICD_CTLR) & GICD_CTLR_RWP) {
> + if (!--count) {
> + printf("GICv3: RWP timeout!\n");
> + abort();
> + }
> + cpu_relax();
> + udelay(10);
> + };
> +}
> +
> +static inline void gicv3_dist_wait_for_rwp(void)
> +{
> + gicv3_do_wait_for_rwp(gicv3_dist_base());
> +}
> +
> +static inline void gicv3_redist_wait_for_rwp(void)
> +{
> + gicv3_do_wait_for_rwp(gicv3_redist_base());
> +}
> +
> +static inline u32 mpidr_compress(u64 mpidr)
> +{
> + u64 compressed = mpidr & MPIDR_HWID_BITMASK;
> +
> + compressed = (((compressed >> 32) & 0xff) << 24) | compressed;
> + return compressed;
> +}
> +
> +static inline u64 mpidr_uncompress(u32 compressed)
> +{
> + u64 mpidr = ((u64)compressed >> 24) << 32;
> +
> + mpidr |= compressed & MPIDR_HWID_BITMASK;
> + return mpidr;
> +}
> +
> +#endif /* !__ASSEMBLY__ */
> +#endif /* _ASMARM_GIC_V3_H_ */
> diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
> index 328e078a9ae1..4897bc592cdd 100644
> --- a/lib/arm/asm/gic.h
> +++ b/lib/arm/asm/gic.h
> @@ -7,6 +7,7 @@
> #define _ASMARM_GIC_H_
>
> #include <asm/gic-v2.h>
> +#include <asm/gic-v3.h>
>
> #define GIC_CPU_CTRL 0x00
> #define GIC_CPU_PRIMASK 0x04
> diff --git a/lib/arm/gic.c b/lib/arm/gic.c
> index 91d78c9a0cc2..af58a11ea13e 100644
> --- a/lib/arm/gic.c
> +++ b/lib/arm/gic.c
> @@ -8,9 +8,11 @@
> #include <asm/io.h>
>
> struct gicv2_data gicv2_data;
> +struct gicv3_data gicv3_data;
>
> /*
> * Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> + * Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
> */
> static bool
> gic_get_dt_bases(const char *compatible, void **base1, void **base2)
> @@ -48,10 +50,18 @@ int gicv2_init(void)
> &gicv2_data.dist_base, &gicv2_data.cpu_base);
> }
>
> +int gicv3_init(void)
> +{
> + return gic_get_dt_bases("arm,gic-v3", &gicv3_data.dist_base,
> + &gicv3_data.redist_base[0]);
> +}
> +
> int gic_init(void)
> {
> if (gicv2_init())
> return 2;
> + else if (gicv3_init())
> + return 3;
> return 0;
> }
>
> @@ -73,3 +83,49 @@ void gicv2_enable_defaults(void)
> writel(GICC_INT_PRI_THRESHOLD, cpu_base + GIC_CPU_PRIMASK);
> writel(GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
> }
> +
> +void gicv3_set_redist_base(void)
> +{
> + u32 aff = mpidr_compress(get_mpidr());
> + void *ptr = gicv3_data.redist_base[0];
> + u64 typer;
> +
> + do {
> + typer = gicv3_read_typer(ptr + GICR_TYPER);
> + if ((typer >> 32) == aff) {
> + gicv3_redist_base() = ptr;
> + return;
> + }
> + ptr += SZ_64K * 2; /* skip RD_base and SGI_base */
> + } while (!(typer & GICR_TYPER_LAST));
> + assert(0);
> +}
> +
> +void gicv3_enable_defaults(void)
> +{
> + void *dist = gicv3_dist_base();
> + void *sgi_base;
> + unsigned int i;
> +
> + gicv3_data.irq_nr = GICD_TYPER_IRQS(readl(dist + GICD_TYPER));
> + if (gicv3_data.irq_nr > 1020)
> + gicv3_data.irq_nr = 1020;
> +
> + writel(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1,
> + dist + GICD_CTLR);
> + gicv3_dist_wait_for_rwp();
> +
> + if (!gicv3_redist_base())
> + gicv3_set_redist_base();
> + sgi_base = gicv3_sgi_base();
> +
> + writel(~0, sgi_base + GICR_IGROUPR0);
This is mixing redist setup with distributor setup. Is it that what you
meant with:
" - simplify enable by not caring if we reinit the distributor [drew]"?
Also if you set the group for the SGIs, you should set it for SPIs as
well (like the kernel does). This was done in v3 of the series.
What about you finish the per-CPU setup first, then bail out with:
if (smp_processor_id() != 0)
return;
and then do the distributor setup (only on the first core).
Cheers,
Andre.
> + writel(GICD_INT_EN_SET_SGI, sgi_base + GIC_DIST_ENABLE_SET);
> +
> + for (i = 0; i < 32; i += 4)
> + writel(GICD_INT_DEF_PRI_X4, sgi_base + GIC_DIST_PRI + i);
> + gicv3_redist_wait_for_rwp();
> +
> + gicv3_write_pmr(0xf0);
> + gicv3_write_grpen1(1);
> +}
> diff --git a/lib/arm64/asm/arch_gicv3.h b/lib/arm64/asm/arch_gicv3.h
> new file mode 100644
> index 000000000000..6d353567f56a
> --- /dev/null
> +++ b/lib/arm64/asm/arch_gicv3.h
> @@ -0,0 +1,44 @@
> +/*
> + * All ripped off from arch/arm64/include/asm/arch_gicv3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM64_ARCH_GICV3_H_
> +#define _ASMARM64_ARCH_GICV3_H_
> +
> +#include <asm/sysreg.h>
> +
> +#define ICC_PMR_EL1 sys_reg(3, 0, 4, 6, 0)
> +#define ICC_GRPEN1_EL1 sys_reg(3, 0, 12, 12, 7)
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <libcflat.h>
> +#include <asm/barrier.h>
> +
> +#define __stringify xstr
> +
> +/*
> + * Low-level accessors
> + *
> + * These system registers are 32 bits, but we make sure that the compiler
> + * sets the GP register's most significant bits to 0 with an explicit cast.
> + */
> +
> +static inline void gicv3_write_pmr(u32 val)
> +{
> + asm volatile("msr_s " __stringify(ICC_PMR_EL1) ", %0" : : "r" ((u64)val));
> +}
> +
> +static inline void gicv3_write_grpen1(u32 val)
> +{
> + asm volatile("msr_s " __stringify(ICC_GRPEN1_EL1) ", %0" : : "r" ((u64)val));
> + isb();
> +}
> +
> +#define gicv3_read_typer(c) readq(c)
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* _ASMARM64_ARCH_GICV3_H_ */
> diff --git a/lib/arm64/asm/gic-v3.h b/lib/arm64/asm/gic-v3.h
> new file mode 100644
> index 000000000000..8ee5d4d9c181
> --- /dev/null
> +++ b/lib/arm64/asm/gic-v3.h
> @@ -0,0 +1 @@
> +#include "../../arm/asm/gic-v3.h"
> diff --git a/lib/arm64/asm/sysreg.h b/lib/arm64/asm/sysreg.h
> new file mode 100644
> index 000000000000..544a46cb8cc5
> --- /dev/null
> +++ b/lib/arm64/asm/sysreg.h
> @@ -0,0 +1,44 @@
> +/*
> + * Ripped off from arch/arm64/include/asm/sysreg.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM64_SYSREG_H_
> +#define _ASMARM64_SYSREG_H_
> +
> +#define sys_reg(op0, op1, crn, crm, op2) \
> + ((((op0)&3)<<19)|((op1)<<16)|((crn)<<12)|((crm)<<8)|((op2)<<5))
> +
> +#ifdef __ASSEMBLY__
> + .irp num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
> + .equ .L__reg_num_x\num, \num
> + .endr
> + .equ .L__reg_num_xzr, 31
> +
> + .macro mrs_s, rt, sreg
> + .inst 0xd5200000|(\sreg)|(.L__reg_num_\rt)
> + .endm
> +
> + .macro msr_s, sreg, rt
> + .inst 0xd5000000|(\sreg)|(.L__reg_num_\rt)
> + .endm
> +#else
> +asm(
> +" .irp num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
> +" .equ .L__reg_num_x\\num, \\num\n"
> +" .endr\n"
> +" .equ .L__reg_num_xzr, 31\n"
> +"\n"
> +" .macro mrs_s, rt, sreg\n"
> +" .inst 0xd5200000|(\\sreg)|(.L__reg_num_\\rt)\n"
> +" .endm\n"
> +"\n"
> +" .macro msr_s, sreg, rt\n"
> +" .inst 0xd5000000|(\\sreg)|(.L__reg_num_\\rt)\n"
> +" .endm\n"
> +);
> +#endif
> +
> +#endif /* _ASMARM64_SYSREG_H_ */
>
^ permalink raw reply
* RE: [PATCH 5/5] mwifiex: wait for firmware dump completion in remove_card
From: Amitkumar Karwar @ 2016-11-09 12:35 UTC (permalink / raw)
To: Brian Norris, Kalle Valo
Cc: Dmitry Torokhov, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam, Xinming Hu
In-Reply-To: <20161102204537.GA27786@google.com>
Hi Brian,
> From: Brian Norris [mailto:briannorris@chromium.org]
> Sent: Thursday, November 03, 2016 2:16 AM
> To: Kalle Valo
> Cc: Dmitry Torokhov; Amitkumar Karwar; linux-wireless@vger.kernel.org;
> Cathy Luo; Nishant Sarmukadam; Xinming Hu
> Subject: Re: [PATCH 5/5] mwifiex: wait for firmware dump completion in
> remove_card
>
> On Thu, Oct 27, 2016 at 04:20:25PM +0300, Kalle Valo wrote:
> > Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:
> >
> > >> +/* reset_trigger variable is used to identify if
> > >> +mwifiex_sdio_remove()
> > >> + * is called by sdio_work during reset or the call is from sdio
> subsystem.
> > >> + * We will cancel sdio_work only if the call is from sdio
> subsystem.
> > >> + */
> > >> +static u8 reset_triggered;
> > >
> > > It would be really great if the driver supported multiple devices.
> > > IOW please avoid module-globals.
> >
> > Good catch, it's a hard requirement to support multiple devices at the
> > same time.
>
> BTW, this problem is repeated in several places throughout this driver.
> For instance, look for 'user_rmmod' (why? you shouldn't need to treat
> module unload differently...)
We have 2 kinds of teardown cases.
1) Chip is going to be powered off.
a) System reboot
b) Someone manually removed wifi card from system
2) User unloaded the driver.
In case 1. b), we can't have logic to terminate WIFI connection and download SHUTDOWN command to firmware, as hardware itself is not present.
This logic is useful when user just unloads and loads the driver. Firmware download will be skipped in this case, as it's already running. SHUTDOWN command sent during unload has cleared firmware's state.
'user_rmmod' flag doesn't create problem for supporting multiple devices. The flag is true during module unload OR reboot. It's applicable for all devices.
> and the work structs (and corresponding
> 'saved_adapter' and 'iface_flags') used for PCIe function-level reset
> and SDIO reset.
We are working on the v3 of this patch series. We will try to get rid of these variables along with global "work_struct" as you suggested.
Regards,
Amitkumar
^ permalink raw reply
* Re: [kvm-unit-tests PATCH v4 09/11] arm/arm64: add initial gicv3 support
From: Andre Przywara @ 2016-11-09 12:35 UTC (permalink / raw)
To: Andrew Jones, kvm, kvmarm, qemu-devel, qemu-arm
Cc: pbonzini, peter.maydell, alex.bennee, marc.zyngier, eric.auger,
christoffer.dall
In-Reply-To: <1478636499-14339-10-git-send-email-drjones@redhat.com>
Hi,
On 08/11/16 20:21, Andrew Jones wrote:
> Signed-off-by: Andrew Jones <drjones@redhat.com>
>
> ---
> v4:
> - only take defines from kernel we need now [Andre]
> - simplify enable by not caring if we reinit the distributor [drew]
> v2:
> - configure irqs as NS GRP1
> ---
> lib/arm/asm/arch_gicv3.h | 42 +++++++++++++++++++++
> lib/arm/asm/gic-v3.h | 92 ++++++++++++++++++++++++++++++++++++++++++++++
> lib/arm/asm/gic.h | 1 +
> lib/arm/gic.c | 56 ++++++++++++++++++++++++++++
> lib/arm64/asm/arch_gicv3.h | 44 ++++++++++++++++++++++
> lib/arm64/asm/gic-v3.h | 1 +
> lib/arm64/asm/sysreg.h | 44 ++++++++++++++++++++++
> 7 files changed, 280 insertions(+)
> create mode 100644 lib/arm/asm/arch_gicv3.h
> create mode 100644 lib/arm/asm/gic-v3.h
> create mode 100644 lib/arm64/asm/arch_gicv3.h
> create mode 100644 lib/arm64/asm/gic-v3.h
> create mode 100644 lib/arm64/asm/sysreg.h
>
> diff --git a/lib/arm/asm/arch_gicv3.h b/lib/arm/asm/arch_gicv3.h
> new file mode 100644
> index 000000000000..81a1e5f6c29c
> --- /dev/null
> +++ b/lib/arm/asm/arch_gicv3.h
> @@ -0,0 +1,42 @@
> +/*
> + * All ripped off from arch/arm/include/asm/arch_gicv3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_ARCH_GICV3_H_
> +#define _ASMARM_ARCH_GICV3_H_
> +
> +#ifndef __ASSEMBLY__
> +#include <libcflat.h>
> +#include <asm/barrier.h>
> +#include <asm/io.h>
> +
> +#define __stringify xstr
> +
> +#define __ACCESS_CP15(CRn, Op1, CRm, Op2) p15, Op1, %0, CRn, CRm, Op2
> +
> +#define ICC_PMR __ACCESS_CP15(c4, 0, c6, 0)
> +#define ICC_IGRPEN1 __ACCESS_CP15(c12, 0, c12, 7)
> +
> +static inline void gicv3_write_pmr(u32 val)
> +{
> + asm volatile("mcr " __stringify(ICC_PMR) : : "r" (val));
> +}
> +
> +static inline void gicv3_write_grpen1(u32 val)
> +{
> + asm volatile("mcr " __stringify(ICC_IGRPEN1) : : "r" (val));
> + isb();
> +}
> +
> +static inline u64 gicv3_read_typer(const volatile void __iomem *addr)
> +{
> + u64 val = readl(addr);
> + val |= (u64)readl(addr + 4) << 32;
> + return val;
> +}
> +
> +#endif /* !__ASSEMBLY__ */
> +#endif /* _ASMARM_ARCH_GICV3_H_ */
> diff --git a/lib/arm/asm/gic-v3.h b/lib/arm/asm/gic-v3.h
> new file mode 100644
> index 000000000000..03321f8c860f
> --- /dev/null
> +++ b/lib/arm/asm/gic-v3.h
> @@ -0,0 +1,92 @@
> +/*
> + * All GIC* defines are lifted from include/linux/irqchip/arm-gic-v3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_GIC_V3_H_
> +#define _ASMARM_GIC_V3_H_
> +
> +#ifndef _ASMARM_GIC_H_
> +#error Do not directly include <asm/gic-v3.h>. Include <asm/gic.h>
> +#endif
> +
> +#define GICD_CTLR 0x0000
> +#define GICD_TYPER 0x0004
So if we share the distributor register definition with GICv2, these
shouldn't be here, but in gic.h.
But this is the right naming scheme we should use (instead of GIC_DIST_xxx).
Now this gets interesting with your wish to both share the definitions
for the GICv2 and GICv3 distributors, but also stick to the names the
kernel uses (because they differ between the two) ;-)
So now you loose the greppability for either GIC_DIST_CTR or GICD_TYPER,
for instance.
> +#define GICD_IGROUPR 0x0080
> +
> +#define GICD_CTLR_RWP (1U << 31)
> +#define GICD_CTLR_ARE_NS (1U << 4)
> +#define GICD_CTLR_ENABLE_G1A (1U << 1)
> +#define GICD_CTLR_ENABLE_G1 (1U << 0)
> +
> +#define GICR_TYPER 0x0008
> +#define GICR_IGROUPR0 GICD_IGROUPR
> +#define GICR_TYPER_LAST (1U << 4)
> +
> +
> +#include <asm/arch_gicv3.h>
> +
> +#ifndef __ASSEMBLY__
> +#include <asm/setup.h>
> +#include <asm/smp.h>
> +#include <asm/processor.h>
> +#include <asm/io.h>
> +
> +struct gicv3_data {
> + void *dist_base;
> + void *redist_base[NR_CPUS];
> + unsigned int irq_nr;
> +};
> +extern struct gicv3_data gicv3_data;
> +
> +#define gicv3_dist_base() (gicv3_data.dist_base)
> +#define gicv3_redist_base() (gicv3_data.redist_base[smp_processor_id()])
> +#define gicv3_sgi_base() (gicv3_data.redist_base[smp_processor_id()] + SZ_64K)
> +
> +extern int gicv3_init(void);
> +extern void gicv3_enable_defaults(void);
> +
> +static inline void gicv3_do_wait_for_rwp(void *base)
> +{
> + int count = 100000; /* 1s */
> +
> + while (readl(base + GICD_CTLR) & GICD_CTLR_RWP) {
> + if (!--count) {
> + printf("GICv3: RWP timeout!\n");
> + abort();
> + }
> + cpu_relax();
> + udelay(10);
> + };
> +}
> +
> +static inline void gicv3_dist_wait_for_rwp(void)
> +{
> + gicv3_do_wait_for_rwp(gicv3_dist_base());
> +}
> +
> +static inline void gicv3_redist_wait_for_rwp(void)
> +{
> + gicv3_do_wait_for_rwp(gicv3_redist_base());
> +}
> +
> +static inline u32 mpidr_compress(u64 mpidr)
> +{
> + u64 compressed = mpidr & MPIDR_HWID_BITMASK;
> +
> + compressed = (((compressed >> 32) & 0xff) << 24) | compressed;
> + return compressed;
> +}
> +
> +static inline u64 mpidr_uncompress(u32 compressed)
> +{
> + u64 mpidr = ((u64)compressed >> 24) << 32;
> +
> + mpidr |= compressed & MPIDR_HWID_BITMASK;
> + return mpidr;
> +}
> +
> +#endif /* !__ASSEMBLY__ */
> +#endif /* _ASMARM_GIC_V3_H_ */
> diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
> index 328e078a9ae1..4897bc592cdd 100644
> --- a/lib/arm/asm/gic.h
> +++ b/lib/arm/asm/gic.h
> @@ -7,6 +7,7 @@
> #define _ASMARM_GIC_H_
>
> #include <asm/gic-v2.h>
> +#include <asm/gic-v3.h>
>
> #define GIC_CPU_CTRL 0x00
> #define GIC_CPU_PRIMASK 0x04
> diff --git a/lib/arm/gic.c b/lib/arm/gic.c
> index 91d78c9a0cc2..af58a11ea13e 100644
> --- a/lib/arm/gic.c
> +++ b/lib/arm/gic.c
> @@ -8,9 +8,11 @@
> #include <asm/io.h>
>
> struct gicv2_data gicv2_data;
> +struct gicv3_data gicv3_data;
>
> /*
> * Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> + * Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
> */
> static bool
> gic_get_dt_bases(const char *compatible, void **base1, void **base2)
> @@ -48,10 +50,18 @@ int gicv2_init(void)
> &gicv2_data.dist_base, &gicv2_data.cpu_base);
> }
>
> +int gicv3_init(void)
> +{
> + return gic_get_dt_bases("arm,gic-v3", &gicv3_data.dist_base,
> + &gicv3_data.redist_base[0]);
> +}
> +
> int gic_init(void)
> {
> if (gicv2_init())
> return 2;
> + else if (gicv3_init())
> + return 3;
> return 0;
> }
>
> @@ -73,3 +83,49 @@ void gicv2_enable_defaults(void)
> writel(GICC_INT_PRI_THRESHOLD, cpu_base + GIC_CPU_PRIMASK);
> writel(GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
> }
> +
> +void gicv3_set_redist_base(void)
> +{
> + u32 aff = mpidr_compress(get_mpidr());
> + void *ptr = gicv3_data.redist_base[0];
> + u64 typer;
> +
> + do {
> + typer = gicv3_read_typer(ptr + GICR_TYPER);
> + if ((typer >> 32) == aff) {
> + gicv3_redist_base() = ptr;
> + return;
> + }
> + ptr += SZ_64K * 2; /* skip RD_base and SGI_base */
> + } while (!(typer & GICR_TYPER_LAST));
> + assert(0);
> +}
> +
> +void gicv3_enable_defaults(void)
> +{
> + void *dist = gicv3_dist_base();
> + void *sgi_base;
> + unsigned int i;
> +
> + gicv3_data.irq_nr = GICD_TYPER_IRQS(readl(dist + GICD_TYPER));
> + if (gicv3_data.irq_nr > 1020)
> + gicv3_data.irq_nr = 1020;
> +
> + writel(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1,
> + dist + GICD_CTLR);
> + gicv3_dist_wait_for_rwp();
> +
> + if (!gicv3_redist_base())
> + gicv3_set_redist_base();
> + sgi_base = gicv3_sgi_base();
> +
> + writel(~0, sgi_base + GICR_IGROUPR0);
This is mixing redist setup with distributor setup. Is it that what you
meant with:
" - simplify enable by not caring if we reinit the distributor [drew]"?
Also if you set the group for the SGIs, you should set it for SPIs as
well (like the kernel does). This was done in v3 of the series.
What about you finish the per-CPU setup first, then bail out with:
if (smp_processor_id() != 0)
return;
and then do the distributor setup (only on the first core).
Cheers,
Andre.
> + writel(GICD_INT_EN_SET_SGI, sgi_base + GIC_DIST_ENABLE_SET);
> +
> + for (i = 0; i < 32; i += 4)
> + writel(GICD_INT_DEF_PRI_X4, sgi_base + GIC_DIST_PRI + i);
> + gicv3_redist_wait_for_rwp();
> +
> + gicv3_write_pmr(0xf0);
> + gicv3_write_grpen1(1);
> +}
> diff --git a/lib/arm64/asm/arch_gicv3.h b/lib/arm64/asm/arch_gicv3.h
> new file mode 100644
> index 000000000000..6d353567f56a
> --- /dev/null
> +++ b/lib/arm64/asm/arch_gicv3.h
> @@ -0,0 +1,44 @@
> +/*
> + * All ripped off from arch/arm64/include/asm/arch_gicv3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM64_ARCH_GICV3_H_
> +#define _ASMARM64_ARCH_GICV3_H_
> +
> +#include <asm/sysreg.h>
> +
> +#define ICC_PMR_EL1 sys_reg(3, 0, 4, 6, 0)
> +#define ICC_GRPEN1_EL1 sys_reg(3, 0, 12, 12, 7)
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <libcflat.h>
> +#include <asm/barrier.h>
> +
> +#define __stringify xstr
> +
> +/*
> + * Low-level accessors
> + *
> + * These system registers are 32 bits, but we make sure that the compiler
> + * sets the GP register's most significant bits to 0 with an explicit cast.
> + */
> +
> +static inline void gicv3_write_pmr(u32 val)
> +{
> + asm volatile("msr_s " __stringify(ICC_PMR_EL1) ", %0" : : "r" ((u64)val));
> +}
> +
> +static inline void gicv3_write_grpen1(u32 val)
> +{
> + asm volatile("msr_s " __stringify(ICC_GRPEN1_EL1) ", %0" : : "r" ((u64)val));
> + isb();
> +}
> +
> +#define gicv3_read_typer(c) readq(c)
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* _ASMARM64_ARCH_GICV3_H_ */
> diff --git a/lib/arm64/asm/gic-v3.h b/lib/arm64/asm/gic-v3.h
> new file mode 100644
> index 000000000000..8ee5d4d9c181
> --- /dev/null
> +++ b/lib/arm64/asm/gic-v3.h
> @@ -0,0 +1 @@
> +#include "../../arm/asm/gic-v3.h"
> diff --git a/lib/arm64/asm/sysreg.h b/lib/arm64/asm/sysreg.h
> new file mode 100644
> index 000000000000..544a46cb8cc5
> --- /dev/null
> +++ b/lib/arm64/asm/sysreg.h
> @@ -0,0 +1,44 @@
> +/*
> + * Ripped off from arch/arm64/include/asm/sysreg.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM64_SYSREG_H_
> +#define _ASMARM64_SYSREG_H_
> +
> +#define sys_reg(op0, op1, crn, crm, op2) \
> + ((((op0)&3)<<19)|((op1)<<16)|((crn)<<12)|((crm)<<8)|((op2)<<5))
> +
> +#ifdef __ASSEMBLY__
> + .irp num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
> + .equ .L__reg_num_x\num, \num
> + .endr
> + .equ .L__reg_num_xzr, 31
> +
> + .macro mrs_s, rt, sreg
> + .inst 0xd5200000|(\sreg)|(.L__reg_num_\rt)
> + .endm
> +
> + .macro msr_s, sreg, rt
> + .inst 0xd5000000|(\sreg)|(.L__reg_num_\rt)
> + .endm
> +#else
> +asm(
> +" .irp num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
> +" .equ .L__reg_num_x\\num, \\num\n"
> +" .endr\n"
> +" .equ .L__reg_num_xzr, 31\n"
> +"\n"
> +" .macro mrs_s, rt, sreg\n"
> +" .inst 0xd5200000|(\\sreg)|(.L__reg_num_\\rt)\n"
> +" .endm\n"
> +"\n"
> +" .macro msr_s, sreg, rt\n"
> +" .inst 0xd5000000|(\\sreg)|(.L__reg_num_\\rt)\n"
> +" .endm\n"
> +);
> +#endif
> +
> +#endif /* _ASMARM64_SYSREG_H_ */
>
^ permalink raw reply
* Re: [kvm-unit-tests PATCH v4 09/11] arm/arm64: add initial gicv3 support
From: Andre Przywara @ 2016-11-09 12:35 UTC (permalink / raw)
To: Andrew Jones, kvm, kvmarm, qemu-devel, qemu-arm; +Cc: marc.zyngier, pbonzini
In-Reply-To: <1478636499-14339-10-git-send-email-drjones@redhat.com>
Hi,
On 08/11/16 20:21, Andrew Jones wrote:
> Signed-off-by: Andrew Jones <drjones@redhat.com>
>
> ---
> v4:
> - only take defines from kernel we need now [Andre]
> - simplify enable by not caring if we reinit the distributor [drew]
> v2:
> - configure irqs as NS GRP1
> ---
> lib/arm/asm/arch_gicv3.h | 42 +++++++++++++++++++++
> lib/arm/asm/gic-v3.h | 92 ++++++++++++++++++++++++++++++++++++++++++++++
> lib/arm/asm/gic.h | 1 +
> lib/arm/gic.c | 56 ++++++++++++++++++++++++++++
> lib/arm64/asm/arch_gicv3.h | 44 ++++++++++++++++++++++
> lib/arm64/asm/gic-v3.h | 1 +
> lib/arm64/asm/sysreg.h | 44 ++++++++++++++++++++++
> 7 files changed, 280 insertions(+)
> create mode 100644 lib/arm/asm/arch_gicv3.h
> create mode 100644 lib/arm/asm/gic-v3.h
> create mode 100644 lib/arm64/asm/arch_gicv3.h
> create mode 100644 lib/arm64/asm/gic-v3.h
> create mode 100644 lib/arm64/asm/sysreg.h
>
> diff --git a/lib/arm/asm/arch_gicv3.h b/lib/arm/asm/arch_gicv3.h
> new file mode 100644
> index 000000000000..81a1e5f6c29c
> --- /dev/null
> +++ b/lib/arm/asm/arch_gicv3.h
> @@ -0,0 +1,42 @@
> +/*
> + * All ripped off from arch/arm/include/asm/arch_gicv3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_ARCH_GICV3_H_
> +#define _ASMARM_ARCH_GICV3_H_
> +
> +#ifndef __ASSEMBLY__
> +#include <libcflat.h>
> +#include <asm/barrier.h>
> +#include <asm/io.h>
> +
> +#define __stringify xstr
> +
> +#define __ACCESS_CP15(CRn, Op1, CRm, Op2) p15, Op1, %0, CRn, CRm, Op2
> +
> +#define ICC_PMR __ACCESS_CP15(c4, 0, c6, 0)
> +#define ICC_IGRPEN1 __ACCESS_CP15(c12, 0, c12, 7)
> +
> +static inline void gicv3_write_pmr(u32 val)
> +{
> + asm volatile("mcr " __stringify(ICC_PMR) : : "r" (val));
> +}
> +
> +static inline void gicv3_write_grpen1(u32 val)
> +{
> + asm volatile("mcr " __stringify(ICC_IGRPEN1) : : "r" (val));
> + isb();
> +}
> +
> +static inline u64 gicv3_read_typer(const volatile void __iomem *addr)
> +{
> + u64 val = readl(addr);
> + val |= (u64)readl(addr + 4) << 32;
> + return val;
> +}
> +
> +#endif /* !__ASSEMBLY__ */
> +#endif /* _ASMARM_ARCH_GICV3_H_ */
> diff --git a/lib/arm/asm/gic-v3.h b/lib/arm/asm/gic-v3.h
> new file mode 100644
> index 000000000000..03321f8c860f
> --- /dev/null
> +++ b/lib/arm/asm/gic-v3.h
> @@ -0,0 +1,92 @@
> +/*
> + * All GIC* defines are lifted from include/linux/irqchip/arm-gic-v3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM_GIC_V3_H_
> +#define _ASMARM_GIC_V3_H_
> +
> +#ifndef _ASMARM_GIC_H_
> +#error Do not directly include <asm/gic-v3.h>. Include <asm/gic.h>
> +#endif
> +
> +#define GICD_CTLR 0x0000
> +#define GICD_TYPER 0x0004
So if we share the distributor register definition with GICv2, these
shouldn't be here, but in gic.h.
But this is the right naming scheme we should use (instead of GIC_DIST_xxx).
Now this gets interesting with your wish to both share the definitions
for the GICv2 and GICv3 distributors, but also stick to the names the
kernel uses (because they differ between the two) ;-)
So now you loose the greppability for either GIC_DIST_CTR or GICD_TYPER,
for instance.
> +#define GICD_IGROUPR 0x0080
> +
> +#define GICD_CTLR_RWP (1U << 31)
> +#define GICD_CTLR_ARE_NS (1U << 4)
> +#define GICD_CTLR_ENABLE_G1A (1U << 1)
> +#define GICD_CTLR_ENABLE_G1 (1U << 0)
> +
> +#define GICR_TYPER 0x0008
> +#define GICR_IGROUPR0 GICD_IGROUPR
> +#define GICR_TYPER_LAST (1U << 4)
> +
> +
> +#include <asm/arch_gicv3.h>
> +
> +#ifndef __ASSEMBLY__
> +#include <asm/setup.h>
> +#include <asm/smp.h>
> +#include <asm/processor.h>
> +#include <asm/io.h>
> +
> +struct gicv3_data {
> + void *dist_base;
> + void *redist_base[NR_CPUS];
> + unsigned int irq_nr;
> +};
> +extern struct gicv3_data gicv3_data;
> +
> +#define gicv3_dist_base() (gicv3_data.dist_base)
> +#define gicv3_redist_base() (gicv3_data.redist_base[smp_processor_id()])
> +#define gicv3_sgi_base() (gicv3_data.redist_base[smp_processor_id()] + SZ_64K)
> +
> +extern int gicv3_init(void);
> +extern void gicv3_enable_defaults(void);
> +
> +static inline void gicv3_do_wait_for_rwp(void *base)
> +{
> + int count = 100000; /* 1s */
> +
> + while (readl(base + GICD_CTLR) & GICD_CTLR_RWP) {
> + if (!--count) {
> + printf("GICv3: RWP timeout!\n");
> + abort();
> + }
> + cpu_relax();
> + udelay(10);
> + };
> +}
> +
> +static inline void gicv3_dist_wait_for_rwp(void)
> +{
> + gicv3_do_wait_for_rwp(gicv3_dist_base());
> +}
> +
> +static inline void gicv3_redist_wait_for_rwp(void)
> +{
> + gicv3_do_wait_for_rwp(gicv3_redist_base());
> +}
> +
> +static inline u32 mpidr_compress(u64 mpidr)
> +{
> + u64 compressed = mpidr & MPIDR_HWID_BITMASK;
> +
> + compressed = (((compressed >> 32) & 0xff) << 24) | compressed;
> + return compressed;
> +}
> +
> +static inline u64 mpidr_uncompress(u32 compressed)
> +{
> + u64 mpidr = ((u64)compressed >> 24) << 32;
> +
> + mpidr |= compressed & MPIDR_HWID_BITMASK;
> + return mpidr;
> +}
> +
> +#endif /* !__ASSEMBLY__ */
> +#endif /* _ASMARM_GIC_V3_H_ */
> diff --git a/lib/arm/asm/gic.h b/lib/arm/asm/gic.h
> index 328e078a9ae1..4897bc592cdd 100644
> --- a/lib/arm/asm/gic.h
> +++ b/lib/arm/asm/gic.h
> @@ -7,6 +7,7 @@
> #define _ASMARM_GIC_H_
>
> #include <asm/gic-v2.h>
> +#include <asm/gic-v3.h>
>
> #define GIC_CPU_CTRL 0x00
> #define GIC_CPU_PRIMASK 0x04
> diff --git a/lib/arm/gic.c b/lib/arm/gic.c
> index 91d78c9a0cc2..af58a11ea13e 100644
> --- a/lib/arm/gic.c
> +++ b/lib/arm/gic.c
> @@ -8,9 +8,11 @@
> #include <asm/io.h>
>
> struct gicv2_data gicv2_data;
> +struct gicv3_data gicv3_data;
>
> /*
> * Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt
> + * Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt
> */
> static bool
> gic_get_dt_bases(const char *compatible, void **base1, void **base2)
> @@ -48,10 +50,18 @@ int gicv2_init(void)
> &gicv2_data.dist_base, &gicv2_data.cpu_base);
> }
>
> +int gicv3_init(void)
> +{
> + return gic_get_dt_bases("arm,gic-v3", &gicv3_data.dist_base,
> + &gicv3_data.redist_base[0]);
> +}
> +
> int gic_init(void)
> {
> if (gicv2_init())
> return 2;
> + else if (gicv3_init())
> + return 3;
> return 0;
> }
>
> @@ -73,3 +83,49 @@ void gicv2_enable_defaults(void)
> writel(GICC_INT_PRI_THRESHOLD, cpu_base + GIC_CPU_PRIMASK);
> writel(GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
> }
> +
> +void gicv3_set_redist_base(void)
> +{
> + u32 aff = mpidr_compress(get_mpidr());
> + void *ptr = gicv3_data.redist_base[0];
> + u64 typer;
> +
> + do {
> + typer = gicv3_read_typer(ptr + GICR_TYPER);
> + if ((typer >> 32) == aff) {
> + gicv3_redist_base() = ptr;
> + return;
> + }
> + ptr += SZ_64K * 2; /* skip RD_base and SGI_base */
> + } while (!(typer & GICR_TYPER_LAST));
> + assert(0);
> +}
> +
> +void gicv3_enable_defaults(void)
> +{
> + void *dist = gicv3_dist_base();
> + void *sgi_base;
> + unsigned int i;
> +
> + gicv3_data.irq_nr = GICD_TYPER_IRQS(readl(dist + GICD_TYPER));
> + if (gicv3_data.irq_nr > 1020)
> + gicv3_data.irq_nr = 1020;
> +
> + writel(GICD_CTLR_ARE_NS | GICD_CTLR_ENABLE_G1A | GICD_CTLR_ENABLE_G1,
> + dist + GICD_CTLR);
> + gicv3_dist_wait_for_rwp();
> +
> + if (!gicv3_redist_base())
> + gicv3_set_redist_base();
> + sgi_base = gicv3_sgi_base();
> +
> + writel(~0, sgi_base + GICR_IGROUPR0);
This is mixing redist setup with distributor setup. Is it that what you
meant with:
" - simplify enable by not caring if we reinit the distributor [drew]"?
Also if you set the group for the SGIs, you should set it for SPIs as
well (like the kernel does). This was done in v3 of the series.
What about you finish the per-CPU setup first, then bail out with:
if (smp_processor_id() != 0)
return;
and then do the distributor setup (only on the first core).
Cheers,
Andre.
> + writel(GICD_INT_EN_SET_SGI, sgi_base + GIC_DIST_ENABLE_SET);
> +
> + for (i = 0; i < 32; i += 4)
> + writel(GICD_INT_DEF_PRI_X4, sgi_base + GIC_DIST_PRI + i);
> + gicv3_redist_wait_for_rwp();
> +
> + gicv3_write_pmr(0xf0);
> + gicv3_write_grpen1(1);
> +}
> diff --git a/lib/arm64/asm/arch_gicv3.h b/lib/arm64/asm/arch_gicv3.h
> new file mode 100644
> index 000000000000..6d353567f56a
> --- /dev/null
> +++ b/lib/arm64/asm/arch_gicv3.h
> @@ -0,0 +1,44 @@
> +/*
> + * All ripped off from arch/arm64/include/asm/arch_gicv3.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM64_ARCH_GICV3_H_
> +#define _ASMARM64_ARCH_GICV3_H_
> +
> +#include <asm/sysreg.h>
> +
> +#define ICC_PMR_EL1 sys_reg(3, 0, 4, 6, 0)
> +#define ICC_GRPEN1_EL1 sys_reg(3, 0, 12, 12, 7)
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <libcflat.h>
> +#include <asm/barrier.h>
> +
> +#define __stringify xstr
> +
> +/*
> + * Low-level accessors
> + *
> + * These system registers are 32 bits, but we make sure that the compiler
> + * sets the GP register's most significant bits to 0 with an explicit cast.
> + */
> +
> +static inline void gicv3_write_pmr(u32 val)
> +{
> + asm volatile("msr_s " __stringify(ICC_PMR_EL1) ", %0" : : "r" ((u64)val));
> +}
> +
> +static inline void gicv3_write_grpen1(u32 val)
> +{
> + asm volatile("msr_s " __stringify(ICC_GRPEN1_EL1) ", %0" : : "r" ((u64)val));
> + isb();
> +}
> +
> +#define gicv3_read_typer(c) readq(c)
> +
> +#endif /* __ASSEMBLY__ */
> +#endif /* _ASMARM64_ARCH_GICV3_H_ */
> diff --git a/lib/arm64/asm/gic-v3.h b/lib/arm64/asm/gic-v3.h
> new file mode 100644
> index 000000000000..8ee5d4d9c181
> --- /dev/null
> +++ b/lib/arm64/asm/gic-v3.h
> @@ -0,0 +1 @@
> +#include "../../arm/asm/gic-v3.h"
> diff --git a/lib/arm64/asm/sysreg.h b/lib/arm64/asm/sysreg.h
> new file mode 100644
> index 000000000000..544a46cb8cc5
> --- /dev/null
> +++ b/lib/arm64/asm/sysreg.h
> @@ -0,0 +1,44 @@
> +/*
> + * Ripped off from arch/arm64/include/asm/sysreg.h
> + *
> + * Copyright (C) 2016, Red Hat Inc, Andrew Jones <drjones@redhat.com>
> + *
> + * This work is licensed under the terms of the GNU LGPL, version 2.
> + */
> +#ifndef _ASMARM64_SYSREG_H_
> +#define _ASMARM64_SYSREG_H_
> +
> +#define sys_reg(op0, op1, crn, crm, op2) \
> + ((((op0)&3)<<19)|((op1)<<16)|((crn)<<12)|((crm)<<8)|((op2)<<5))
> +
> +#ifdef __ASSEMBLY__
> + .irp num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30
> + .equ .L__reg_num_x\num, \num
> + .endr
> + .equ .L__reg_num_xzr, 31
> +
> + .macro mrs_s, rt, sreg
> + .inst 0xd5200000|(\sreg)|(.L__reg_num_\rt)
> + .endm
> +
> + .macro msr_s, sreg, rt
> + .inst 0xd5000000|(\sreg)|(.L__reg_num_\rt)
> + .endm
> +#else
> +asm(
> +" .irp num,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30\n"
> +" .equ .L__reg_num_x\\num, \\num\n"
> +" .endr\n"
> +" .equ .L__reg_num_xzr, 31\n"
> +"\n"
> +" .macro mrs_s, rt, sreg\n"
> +" .inst 0xd5200000|(\\sreg)|(.L__reg_num_\\rt)\n"
> +" .endm\n"
> +"\n"
> +" .macro msr_s, sreg, rt\n"
> +" .inst 0xd5000000|(\\sreg)|(.L__reg_num_\\rt)\n"
> +" .endm\n"
> +);
> +#endif
> +
> +#endif /* _ASMARM64_SYSREG_H_ */
>
^ permalink raw reply
* [PATCH] qf: Document how to bisect the patch pile history
From: Daniel Vetter @ 2016-11-09 12:34 UTC (permalink / raw)
To: Intel Graphics Development; +Cc: Daniel Vetter, Daniel Vetter, Rodrigo Vivi
Rodrigo recently asked me about this, and I totally failed to properly
document it!
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
qf | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/qf b/qf
index 31b9f3bae0a2..883dda0a1668 100755
--- a/qf
+++ b/qf
@@ -540,6 +540,25 @@ $ qf git pull && qf checkout test
Doing only a git pull on the quilt branch leads to an
inconsitent state if the baseline changed.
+Bisecting patch history
+-----------------------
+
+Git history in the patches directory records every rebase or any other changes
+to the patch pile, including the baseline. Which means it can be used for
+bisecting not just the individual patches, but the history of the entire patch
+pile:
+
+$ qf git bisect *old-sha1* *new-sha1*
+
+to start the bisect process, and then for each bisect step:
+
+$ qf checkout HEAD
+
+Run tests to figure out whether it's part of the new (bad) or old (good)
+history, then tell git using
+
+$ qf git bisect new|old
+
COMMANDS
========
--
2.7.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [RFC 0/4] ALSA controls management using index/device/sub-devices fields
From: Takashi Sakamoto @ 2016-11-09 12:33 UTC (permalink / raw)
To: Arnaud Pouliquen, alsa-devel, Charles Keepax, Vinod Koul
Cc: Takashi Iwai, broonie, lgirdwood
In-Reply-To: <1478592675-23092-1-git-send-email-arnaud.pouliquen@st.com>
Hi,
On Nov 8 2016 17:11, Arnaud Pouliquen wrote:
> 3) Patches proposed:
> Based on these observations, here are some patches that i tested in my
> environment. There are complementary, and could answer to some
> limitations mentioned above.
>
> 3-1) Alsa-utils patch
>
> - iecset: allow to select control with device and sub-device numbers
> This patch allows to access to 2 iec controls differentiated by
> device/sub-devices numbers
> => For me, this patch is mandatory to be able to address the ASoC IEC
> controls, in case of no fix is implemented to allows index field
> update in ASoC.
>
> 3-2) Alsa driver patches
> - ASoC: core: allow PCM control binding to PCM device
> Add relationship between DAIs PCM controls and PCM device.
>
> - ALSA: control: increment index field for duplicated control.
> Generic implementation of the patch proposed in HDA driver
> (http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=ea9b43add)
>
> - ASoC: sti: use bind_pcm_ctl
> implementation of bind_pcm_ctl for sti driver.
In my view, this patchset includes two attempts:
1.to add a framework into ALSA SoC part to relate some control element
sets to PCM devices
2.to allow drivers in ALSA SoC part to add some control element sets
from the same codes according to entries of dtb
To achieve above 2nd attempt, it changes ALSA control core to accept
several control element sets with the same name by assigning proper
indexes to the sets.
Well, since your former messages, you continue using the word, 'general'
or 'generic'. If it were somewhat general, it should satisfy
requirements in whole this subsystem. Actually, there's none of such
requirements outside of ALSA SoC part. For the drivers outside of ALSA
SoC part, design of target sound card is fixed in advance, therefore
programmers can assign control element sets to PCM devices in usual
ways. At least, current infrastructure in ALSA control core can satisfy
the programmers.
Therefore, I think that your attempts includes over-generalization. In
theory, it can bring over-specification easily and it causes code
complication or unmaintained codes.
Focusing on ALSA SoC part, there's a requirement to register control
element sets from the same code, in fact. So I wonder why you don't
start your explanation in an aspect of it. In short, I can't understand
the reason that you adhere to such an inappropriate generalization for
this subsystem.
In this patchset, you adhere to usage of 'index' field. But there's
another way; assigning different identification information to the
control element sets. Let us to start discussion from this point? At
least, Iwai-san said, former driver for Intel High Definition Audio is
necessarily not a good example for a model to c
onsider about this issue and the usage of 'index' is not
well-generalized[1].
Finally, it's better to clear main points of your issue, for practical
and meaningful discussion for better approaches, before starting this
discussion, I think. At least, there's over-generalization,
misunderstandings of design and interfaces, driver-specific historical
reasons and so on.
[1] [alsa-devel] [RFC 0/4] ALSA controls management using
index/device/sub-devices fields
http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/114430.html
Regards
Takashi Sakamoto
^ permalink raw reply
* Re: [PATCH] usbnet: prevent device rpm suspend in usbnet_probe function
From: Bjørn Mork @ 2016-11-09 12:32 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Alan Stern, Kai-Heng Feng, linux-kernel, linux-usb, netdev
In-Reply-To: <1478692735.2428.10.camel@suse.com>
Oliver Neukum <oneukum@suse.com> writes:
> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>
>> These problems could very well be caused by running at SuperSpeed
>> (USB-3) instead of high speed (USB-2).
>>
>> Is there any way to test what happens when the device is attached to
>> the computer by a USB-2 cable? That would prevent it from operating at
>> SuperSpeed.
>>
>> The main point, however, is that the proposed patch doesn't seem to
>> address the true problem, which is that the device gets suspended
>> between probes. The patch only tries to prevent it from being
>> suspended during a probe -- which is already prevented by the USB core.
>
> But why doesn't it fail during normal operation?
>
> I suspect that its firmware requires the altsetting
>
> /* should we change control altsetting on a NCM/MBIM function? */
> if (cdc_ncm_select_altsetting(intf) == CDC_NCM_COMM_ALTSETTING_MBIM) {
> data_altsetting = CDC_NCM_DATA_ALTSETTING_MBIM;
> ret = cdc_mbim_set_ctrlalt(dev, intf, CDC_NCM_COMM_ALTSETTING_MBIM);
>
> to be set before it accepts a suspension.
Could be, but I don't think so. The above code is effectively a noop
unless the function is a combined NCM/MBIM function. Something I've
never seen on a Sierra Wireless device (ignoring the infamous EM7345,
which really is an Intel device).
This is a typical example of a Sierra Wireless modem configured for
MBIM:
P: Vendor=1199 ProdID=9079 Rev= 0.06
S: Manufacturer=Sierra Wireless, Incorporated
S: Product=Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A
S: SerialNumber=LF615126xxxxxxx
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
A: FirstIf#=12 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#=12 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=(none)
E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=32ms
I:* If#=13 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
I: If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
The control interface of plain MBIM functions will always have a single
altsetting, like the example above. So cdc_ncm_select_altsetting(intf)
returns "0", while CDC_NCM_COMM_ALTSETTING_MBIM is "1".
Just for reference, using the Intel^H^H^H^H^HEM7345 as example, this is
what a combined NCM/MBIM function looks like:
P: Vendor=1199 ProdID=a001 Rev=17.29
S: Manufacturer=Sierra Wireless Inc.
S: Product=Sierra Wireless EM7345 4G LTE
S: SerialNumber=013937000xxxxxx
C:* #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=100mA
A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0d Prot=00
A: FirstIf#= 2 IfCount= 2 Cls=02(comm.) Sub=02 Prot=01
I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver=cdc_mbim
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
I:* If#= 0 Alt= 1 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver=cdc_mbim
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 2 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=01 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=1ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=(none)
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
And this is what the code you quote is trying to deal with. Note the
different subclass of altsetting 0 and 1.... This is incredibly ugly.
FWIW, the modem in question cannot be an EM7345. That modem does not
have the static interface numbering oddity. Another sign that it isn't
a true Sierra device.
Bjørn
^ permalink raw reply
* [linux-3.4 test] 102041: regressions - FAIL
From: osstest service owner @ 2016-11-09 12:31 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 15852 bytes --]
flight 102041 linux-3.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102041/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 92983
test-amd64-amd64-libvirt-vhd 6 xen-boot fail REGR. vs. 92983
test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 92983
test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 92983
test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 92983
test-amd64-amd64-xl-qcow2 6 xen-boot fail REGR. vs. 92983
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 92983
test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 92983
test-amd64-amd64-qemuu-nested-intel 6 xen-boot fail REGR. vs. 92983
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 92983
test-amd64-i386-xl 6 xen-boot fail REGR. vs. 92983
test-amd64-amd64-xl-xsm 6 xen-boot fail REGR. vs. 92983
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 92983
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101695 pass in 102041
test-amd64-amd64-i386-pvgrub 6 xen-boot fail pass in 101695
test-amd64-amd64-xl-rtds 6 xen-boot fail pass in 101695
test-amd64-i386-freebsd10-amd64 6 xen-boot fail pass in 101695
test-amd64-i386-pair 9 xen-boot/src_host fail pass in 101720
test-amd64-i386-pair 10 xen-boot/dst_host fail pass in 101720
test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail pass in 101822
test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail pass in 101840
test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail pass in 101840
test-amd64-amd64-amd64-pvgrub 6 xen-boot fail pass in 101867
test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail pass in 101867
test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail pass in 101867
test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail pass in 101951
test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101951
test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 101951
test-amd64-amd64-pair 10 xen-boot/dst_host fail pass in 101951
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92983
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 92983
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 92983
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a
test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a
build-amd64-rumprun 7 xen-build fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
build-i386-rumprun 7 xen-build fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
linux 8d1988f838a95e836342b505398d38b223181f17
baseline version:
linux 343a5fbeef08baf2097b8cf4e26137cebe3cfef4
Last test of basis 92983 2016-04-27 16:21:44 Z 195 days
Testing same since 101695 2016-10-26 18:26:23 Z 13 days 20 attempts
------------------------------------------------------------
People who touched revisions under test:
"Suzuki K. Poulose" <Suzuki.Poulose@arm.com>
Aaro Koskinen <aaro.koskinen@iki.fi>
Al Viro <viro@zeniv.linux.org.uk>
Alan Stern <stern@rowland.harvard.edu>
Aleksander Morgado <aleksander@aleksander.es>
Alex Thorlton <athorlton@sgi.com>
Alexandru Cornea <alexandru.cornea@intel.com>
Alexey Khoroshilov <khoroshilov@ispras.ru>
Amitkumar Karwar <akarwar@marvell.com>
Andrew Banman <abanman@sgi.com>
Andrew Morton <akpm@linux-foundation.org>
Andrey Ryabinin <aryabinin@virtuozzo.com>
Anson Huang <Anson.Huang@freescale.com>
Arnaldo Carvalho de Melo <acme@kernel.org>
Arnaldo Carvalho de Melo <acme@redhat.com>
Arnd Bergmann <arnd@arndb.de>
Ben Hutchings <ben@decadent.org.uk>
Bjørn Mork <bjorn@mork.no>
Boris Brezillon <boris.brezillon@free-electrons.com>
Borislav Petkov <bp@suse.de>
Brian Norris <computersforpeace@gmail.com>
Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Chen Yu <yu.c.chen@intel.com>
Christoph Hellwig <hch@lst.de>
Chunfeng Yun <chunfeng.yun@mediatek.com>
Clemens Ladisch <clemens@ladisch.de>
Colin Ian King <colin.king@canonical.com>
Cong Wang <xiyou.wangcong@gmail.com>
Daeho Jeong <daeho.jeong@samsung.com>
Dan Carpenter <dan.carpenter@oracle.com>
Darren Hart <dvhart@linux.intel.com>
Dave Airlie <airlied@redhat.com>
David Howells <dhowells@redhat.com>
David Rientjes <rientjes@google.com>
David S. Miller <davem@davemloft.net>
David Turner <novalis@novalis.org>
David Vrabel <david.vrabel@citrix.com>
David Woodhouse <David.Woodhouse@intel.com>
Dmitry Tunin <hanipouspilot@gmail.com>
Dmitry V. Levin <ldv@altlinux.org>
Dmitry Vyukov <dvyukov@google.com>
Eric Dumazet <edumazet@google.com>
Eric Dumazet <eric.dumazet@gmail.com>
Felipe Balbi <balbi@ti.com>
Filipe Manana <fdmanana@suse.com>
Francesco Ruggeri <fruggeri@arista.com>
Francesco Ruggeri <fruggeri@aristanetworks.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Helge Deller <deller@gmx.de>
Herbert Xu <herbert@gondor.apana.org.au>
Hillf Danton <hillf.zj@alibaba-inc.com>
Hobin Woo <hobin.woo@samsung.com>
Hu <yadi.hu@windriver.com>
Ingo Molnar <mingo@kernel.org>
James Bottomley <James.Bottomley@HansenPartnership.com>
James Bottomley <JBottomley@Odin.com>
James Morris <james.l.morris@oracle.com>
Jan Beulich <JBeulich@suse.com>
Jan Kara <jack@suse.cz>
Jason A. Donenfeld <Jason@zx2c4.com>
Jeff Layton <jeff.layton@primarydata.com>
Jeff Layton <jlayton@poochiereds.net>
Jens Axboe <axboe@fb.com>
Jiri Kosina <jkosina@suse.cz>
Jiri Slaby <jslaby@suse.cz>
Joe Thornber <ejt@redhat.com>
Johan Hovold <johan@kernel.org>
Johannes Berg <johannes.berg@intel.com>
Johannes Thumshirn <jthumshirn@suse.de>
John Stultz <john.stultz@linaro.org>
Jonathan Cameron <jic23@kernel.org>
Joseph Qi <joseph.qi@huawei.com>
Kalle Valo <kvalo@codeaurora.org>
Karl Heiss <kheiss@gmail.com>
Kashyap Desai <kashyap.desai@avagotech.com>
Kees Cook <keescook@chromium.org>
Kinglong Mee <kinglongmee@gmail.com>
Kirill A. Shutemov <kirill@shutemov.name>
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Konstantin Khlebnikov <koct9i@gmail.com>
Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
Larry Finger <Larry.Finger@lwfinger.net>
Li Bin <huawei.libin@huawei.com>
libin <huawei.libin@huawei.com>
Linus Torvalds <torvalds@linux-foundation.org>
lucien <lucien.xin@gmail.com>
Lv Zheng <lv.zheng@intel.com>
Maciej W. Rozycki <macro@imgtec.com>
Marc Kleine-Budde <mkl@pengutronix.de>
Marcel Holtmann <marcel@holtmann.org>
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Mark Brown <broonie@kernel.org>
Martin K. Petersen <martin.petersen@oracle.com>
Mathias Nyman <mathias.nyman@linux.intel.com>
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Michal Hocko <mhocko@suse.com>
Michal Kubecek <mkubecek@suse.cz>
Michal KubeÄek <mkubecek@suse.cz>
Mike Snitzer <snitzer@redhat.com>
Miklos Szeredi <miklos@szeredi.hu>
Mikulas Patocka <mpatocka@redhat.com>
Mirza Krak <mirza.krak@hostmobility.com>
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Neal Cardwell <ncardwell@google.com>
Neil Horman <nhorman@tuxdriver.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com>
Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Paul Bolle <pebolle@tiscali.nl>
Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Pete Zaitcev <zaitcev@yahoo.com>
Peter Hurley <peter@hurleysoftware.com>
Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Peter Zijlstra (Intel) <peterz@infradead.org>
Peter Zijlstra <peterz@infradead.org>
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ralf Baechle <ralf@linux-mips.org>
Richard Purdie <richard.purdie@linuxfoundation.org>
Robert Jarzmik <robert.jarzmik@free.fr>
Roger Pau Monné <roger.pau@citrix.com>
Roman Gushchin <klamm@yandex-team.ru>
Russell King <rmk+kernel@arm.linux.org.uk>
Sabrina Dubroca <sd@queasysnail.net>
Sachin Pandhare <sachinpandhare@gmail.com>
Sebastian Reichel <sre@kernel.org>
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Stefan Richter <stefanr@s5r6.in-berlin.de>
Stephan Mueller <smueller@chronox.de>
Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Steven Rostedt <rostedt@goodmis.org>
Sumit Saxena <sumit.saxena@avagotech.com>
sumit.saxena@avagotech.com <sumit.saxena@avagotech.com>
Takashi Iwai <tiwai@suse.de>
Tejun Heo <tj@kernel.org>
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Theodore Ts'o <tytso@mit.edu>
Thomas Gleixner <tglx@linutronix.de>
Tilman Schmidt <tilman@imap.cc>
Trond Myklebust <trond.myklebust@primarydata.com>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Valentin Rothberg <valentinrothberg@gmail.com>
Vlad Yasevich <vyasevich@gmail.com>
Vladimir Zapolskiy <vz@mleia.com>
WANG Cong <xiyou.wangcong@gmail.com>
Xiangliang Yu <Xiangliang.Yu@amd.com>
Xin Long <lucien.xin@gmail.com>
Xunlei Pang <xlpang@redhat.com>
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Yuchung Cheng <ycheng@google.com>
Zefan Li <lizefan@huawei.com>
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-i386-pvops pass
build-amd64-rumprun fail
build-i386-rumprun fail
test-amd64-amd64-xl fail
test-amd64-i386-xl fail
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm fail
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm fail
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
test-amd64-i386-freebsd10-amd64 fail
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 blocked
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 blocked
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel fail
test-amd64-amd64-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-amd64-amd64-pair fail
test-amd64-i386-pair fail
test-amd64-amd64-libvirt-pair fail
test-amd64-i386-libvirt-pair fail
test-amd64-amd64-amd64-pvgrub fail
test-amd64-amd64-i386-pvgrub fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-libvirt-vhd fail
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xl-qemuu-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 3972 lines long.)
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 2/3] target-i386: Add Intel HAX files
From: Stefan Hajnoczi @ 2016-11-09 12:30 UTC (permalink / raw)
To: Vincent Palatin; +Cc: qemu-devel
In-Reply-To: <dc1f10ce25eab9d517675e0bdecfc6f4f65d77af.1478619442.git.vpalatin@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
On Tue, Nov 08, 2016 at 04:39:28PM +0100, Vincent Palatin wrote:
Please run scripts/checkpatch.pl to verify that the code follows the
QEMU coding style.
> +hax_fd hax_host_open_vcpu(int vmid, int vcpuid)
> +{
> + char *devfs_path = NULL;
> + hax_fd fd;
> +
> + devfs_path = hax_vcpu_devfs_string(vmid, vcpuid);
> + if (!devfs_path) {
> + fprintf(stderr, "Failed to get the devfs\n");
> + return -EINVAL;
> + }
> +
> + fd = open(devfs_path, O_RDWR);
> + qemu_vfree(devfs_path);
g_malloc(), g_new(), g_strdup(), etc must be matched with g_free(), not
qemu_vfree(). There are probably other instances of this issue in the
patches.
> +//#define DEBUG_HAX_SLOT
> +
> +#ifdef DEBUG_HAX_SLOT
> +#define DPRINTF(fmt, ...) \
> + do { fprintf(stdout, fmt, ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) \
> + do { } while (0)
> +#endif
Please consider using tracing instead of debug printfs. See docs/tracing.txt.
If you really want to keep macros, please use:
#define DEBUG_HAX_SLOT 0
#define DPRINTF(fmt, ...) \
do { \
if (DEBUG_HAX_SLOT) { \
fprintf(stdout, fmt, ## __VA_ARGS__); \
} \
} while (0)
This approach prevents bitrot because it allows the compiler to syntax
check the format string and arguments even when the printf is compiled
out.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: sh-pfc: r8a7795: Use lookup function for bias data
From: Geert Uytterhoeven @ 2016-11-09 12:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Niklas Söderlund, Geert Uytterhoeven, Linus Walleij,
Linux-Renesas, linux-gpio@vger.kernel.org
In-Reply-To: <1534860.cl1iMAJKMz@avalon>
Hi Laurent,
On Wed, Nov 9, 2016 at 11:43 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Monday 07 Nov 2016 11:57:36 Geert Uytterhoeven wrote:
>> On Thu, Nov 3, 2016 at 6:10 PM, Laurent Pinchart wrote:
>> > On Thursday 03 Nov 2016 16:34:21 Niklas Söderlund wrote:
>> >> There is a bug in the r8a7795 bias code where a WARN() is trigged
>> >> anytime a pin from PUEN0/PUD0is accessed.
>> >> # cat /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins
>> >>
>> >> WARNING: CPU: 2 PID: 2391 at drivers/pinctrl/sh-pfc/pfc-r8a7795.c:5364
>> >>
>> >> r8a7795_pinmux_get_bias+0xbc/0xc8 [..]
>> >>
>> >> Call trace:
>> >> [<ffff0000083c442c>] r8a7795_pinmux_get_bias+0xbc/0xc8
>> >> [<ffff0000083c37f4>] sh_pfc_pinconf_get+0x194/0x270
>> >> [<ffff0000083b0768>] pin_config_get_for_pin+0x20/0x30
>> >> [<ffff0000083b11e8>] pinconf_generic_dump_one+0x168/0x188
>> >> [<ffff0000083b144c>] pinconf_generic_dump_pins+0x5c/0x98
>> >> [<ffff0000083b0628>] pinconf_pins_show+0xc8/0x128
>> >> [<ffff0000081fe3bc>] seq_read+0x16c/0x420
>> >> [<ffff00000831a110>] full_proxy_read+0x58/0x88
>> >> [<ffff0000081d7ad4>] __vfs_read+0x1c/0xf8
>> >> [<ffff0000081d8874>] vfs_read+0x84/0x148
>> >> [<ffff0000081d9d64>] SyS_read+0x44/0xa0
>> >> [<ffff000008082f4c>] __sys_trace_return+0x0/0x4
>> >>
>> >> This is due to the WARN() check if the reg field of the pullups struct
>> >> is zero, and this should be 0 for pins controlled by the PUEN0/PUD0
>> >> registers. Change the layout of the pullups struct to embed the pin
>> >> number inside the struct and loop over it to fetch the correct
>> >> information or WARN() if no pin is found.
>> >
>> > This lowers the memory consumption at the cost of increased CPU usage.
>> > Given that the get/set bias functions are not part of a critical path I'm
>> > fine with that. We could possibly optimize the implementation by using a
>> > dichotomic search, but I don't think that's needed at the moment.
>>
>> Alternatively, we could steal one bit from the "reg" bitifield to
>> add a "present" bit, without increasing the table size:
>
> That's an option too, but given how sparsely populated the table is at the
> moment, I'd prefer lowering the memory consumption by moving the pin number in
> the table and removing unused entries. The increase in CPU time could be
> further limited by using a dichotomic search if needed.
After discussing with Niklas, I agree.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* krogoth 2.1.2 status
From: Richard Purdie @ 2016-11-09 12:30 UTC (permalink / raw)
To: openembedded-core, Armin Kuster
I ran a krogoth 2.1.2 build. It did have some issues:
* one runtime sanity test had a timeout issue
* some urls are stale (perpetual problem)
* musl runtime testing fails (never tested on krogoth previously)
* no-x11 runtime testing had a failure (never tested on krogoth
previously)
I suspect we can call this good enough to put into QA but there were
enough 'failures' I wanted to send this out in case someone objects.
Part of the problem here is we apply our current autobuilder test setup
to the older releases as well. I'm aware there may be better ways to do
this but I don't know anyone with time to work on that, we have other
more pressing problems.
Cheers,
Richard
^ permalink raw reply
* Re: [RFC PATCH] scsi: libsas: fix WARN on device removal
From: John Garry @ 2016-11-09 12:28 UTC (permalink / raw)
To: martin.petersen, jejb
Cc: linux-scsi, linuxarm, linux-kernel, dan.j.williams, john.garry2,
jinpu.wang, lindar_liu, tk
In-Reply-To: <1478185120-5509-1-git-send-email-john.garry@huawei.com>
On 03/11/2016 14:58, John Garry wrote:
> The following patch introduces an annoying WARN
> when a device is removed from the SAS topology:
> [SCSI] libsas: prevent domain rediscovery competing with ata error handling
>
Are there any views on this patch? I would have thought that the parties
who use the drivers based on libsas would be interested in fixing this bug.
BTW, We are internally testing, hence the RFC.
Thanks in advance,
John
> A sample WARN is as follows:
> [ 236.842227] WARNING: CPU: 7 PID: 1520 at fs/sysfs/group.c:237 sysfs_remove_group+0x90/0x98
> [ 236.850465] Modules linked in:
> [ 236.853544]
> [ 236.855045] CPU: 7 PID: 1520 Comm: kworker/u64:4 Tainted: G W 4.9.0-rc1-15310-g3fbc29e-dirty #676
> [ 236.865010] Hardware name: Huawei Taishan 2180 /D03, BIOS Estuary v2.3 D03 UEFI 08/17/2016
> [ 236.873249] Workqueue: scsi_wq_0 sas_destruct_devices
> [ 236.878317] task: ffff8027ba31b200 task.stack: ffff8027b9d44000
> [ 236.884225] PC is at sysfs_remove_group+0x90/0x98
> [ 236.888920] LR is at sysfs_remove_group+0x90/0x98
> [ 236.893616] pc : [<ffff000008256df8>] lr : [<ffff000008256df8>] pstate: 60000145
> [ 236.900989] sp : ffff8027b9d47bf0
>
> < snip >
>
> [ 237.116463] [<ffff000008256df8>] sysfs_remove_group+0x90/0x98
> [ 237.122197] [<ffff00000851fe68>] dpm_sysfs_remove+0x58/0x68
> [ 237.127758] [<ffff000008513678>] device_del+0x40/0x218
> [ 237.132886] [<ffff000008513864>] device_unregister+0x14/0x2c
> [ 237.138536] [<ffff0000083670c4>] bsg_unregister_queue+0x5c/0xa0
> [ 237.144442] [<ffff00000855b984>] sas_rphy_remove+0x44/0x80
> [ 237.149915] [<ffff00000855b9d4>] sas_rphy_delete+0x14/0x28
> [ 237.155388] [<ffff00000855f9d8>] sas_destruct_devices+0x64/0x98
> [ 237.161293] [<ffff0000080d2c1c>] process_one_work+0x128/0x2e4
> [ 237.167027] [<ffff0000080d2e30>] worker_thread+0x58/0x434
> [ 237.172415] [<ffff0000080d8c24>] kthread+0xd4/0xe8
> [ 237.177198] [<ffff000008082e80>] ret_from_fork+0x10/0x50
> [ 237.182557] sysfs group 'power' not found for kobject 'end_device-0:0:5'
>
> (this can be really huge when an expander is unplugged)
>
> The problem is with the process of sas_port and domain_device
> destruction in domain revalidation. There is a 2-stage process:
> In domain revalidation (which runs in work queue context), if a
> domain_device is discovered to be gone, then the following happens:
> - the domain_device is queued for destruction in a separate work item
> - the associated sas_port is destroyed immediately
>
> This causes a problem in that the sas_port associated with
> a domain_device is destroyed prior the domain_device: this causes
> the sysfs WARN. Essentially the "rug has been pulled from underneath".
>
> Also, likewise, when a root port is deformed due to loss of signal,
> we have the same issue.
>
> To solve, destroy the sas_port in a separate work item to which
> we do the domain revalidation with a new discovery event, as follows:
> - When a domain_device is detected to be gone, the domain_device is
> queued for destruction in a separate work item. The associated
> sas_port is also queued for destruction in another separate work item
> (needs to be queued 2nd)
> - the domain_device is destroyed
> - the sas_port is destroyed
> [similar is done for loss of signal event, in sas_port_deformed()].
>
> Fixes: 87c8331fcf72e501c3a3c0cdc5c [SCSI] libsas: prevent domain
> rediscovery competing with ata error handling
>
> Signed-off-by: John Garry <john.garry@huawei.com>
>
> diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c
> index 60de662..01d0fe2 100644
> --- a/drivers/scsi/libsas/sas_discover.c
> +++ b/drivers/scsi/libsas/sas_discover.c
> @@ -361,7 +361,7 @@ static void sas_destruct_devices(struct work_struct *work)
>
> clear_bit(DISCE_DESTRUCT, &port->disc.pending);
>
> - list_for_each_entry_safe(dev, n, &port->destroy_list, disco_list_node) {
> + list_for_each_entry_safe(dev, n, &port->dev_destroy_list, disco_list_node) {
> list_del_init(&dev->disco_list_node);
>
> sas_remove_children(&dev->rphy->dev);
> @@ -383,7 +383,7 @@ void sas_unregister_dev(struct asd_sas_port *port, struct domain_device *dev)
>
> if (!test_and_set_bit(SAS_DEV_DESTROY, &dev->state)) {
> sas_rphy_unlink(dev->rphy);
> - list_move_tail(&dev->disco_list_node, &port->destroy_list);
> + list_move_tail(&dev->disco_list_node, &port->dev_destroy_list);
> sas_discover_event(dev->port, DISCE_DESTRUCT);
> }
> }
> @@ -525,6 +525,28 @@ static void sas_revalidate_domain(struct work_struct *work)
> mutex_unlock(&ha->disco_mutex);
> }
>
> +/* ---------- Async Port destruct ---------- */
> +static void sas_async_port_destruct(struct work_struct *work)
> +{
> + struct sas_discovery_event *ev = to_sas_discovery_event(work);
> + struct asd_sas_port *port = ev->port;
> + struct sas_port *sas_port, *n;
> +
> + clear_bit(DISCE_PORT_DESTRUCT, &port->disc.pending);
> +
> + list_for_each_entry_safe(sas_port, n, &port->port_destroy_list, destroy_list) {
> + list_del_init(&port->port_destroy_list);
> +
> + sas_port_delete(sas_port);
> + }
> +}
> +
> +void sas_port_destruct(struct asd_sas_port *port, struct sas_port *sas_port)
> +{
> + list_move_tail(&sas_port->destroy_list, &port->port_destroy_list);
> + sas_discover_event(port, DISCE_PORT_DESTRUCT);
> +}
> +
> /* ---------- Events ---------- */
>
> static void sas_chain_work(struct sas_ha_struct *ha, struct sas_work *sw)
> @@ -582,6 +604,7 @@ void sas_init_disc(struct sas_discovery *disc, struct asd_sas_port *port)
> [DISCE_SUSPEND] = sas_suspend_devices,
> [DISCE_RESUME] = sas_resume_devices,
> [DISCE_DESTRUCT] = sas_destruct_devices,
> + [DISCE_PORT_DESTRUCT] = sas_async_port_destruct,
> };
>
> disc->pending = 0;
> diff --git a/drivers/scsi/libsas/sas_expander.c b/drivers/scsi/libsas/sas_expander.c
> index 022bb6e..f9522a0 100644
> --- a/drivers/scsi/libsas/sas_expander.c
> +++ b/drivers/scsi/libsas/sas_expander.c
> @@ -1900,10 +1900,11 @@ static void sas_unregister_devs_sas_addr(struct domain_device *parent,
> }
> memset(phy->attached_sas_addr, 0, SAS_ADDR_SIZE);
> if (phy->port) {
> + struct asd_sas_port *port = found->port;
> sas_port_delete_phy(phy->port, phy->phy);
> sas_device_set_phy(found, phy->port);
> if (phy->port->num_phys == 0)
> - sas_port_delete(phy->port);
> + sas_port_destruct(port, phy->port);
> phy->port = NULL;
> }
> }
> diff --git a/drivers/scsi/libsas/sas_port.c b/drivers/scsi/libsas/sas_port.c
> index d3c5297..1a32f86 100644
> --- a/drivers/scsi/libsas/sas_port.c
> +++ b/drivers/scsi/libsas/sas_port.c
> @@ -219,7 +219,7 @@ void sas_deform_port(struct asd_sas_phy *phy, int gone)
>
> if (port->num_phys == 1) {
> sas_unregister_domain_devices(port, gone);
> - sas_port_delete(port->port);
> + sas_port_destruct(port, port->port);
> port->port = NULL;
> } else {
> sas_port_delete_phy(port->port, phy->phy);
> @@ -322,7 +322,8 @@ static void sas_init_port(struct asd_sas_port *port,
> port->id = i;
> INIT_LIST_HEAD(&port->dev_list);
> INIT_LIST_HEAD(&port->disco_list);
> - INIT_LIST_HEAD(&port->destroy_list);
> + INIT_LIST_HEAD(&port->dev_destroy_list);
> + INIT_LIST_HEAD(&port->port_destroy_list);
> spin_lock_init(&port->phy_list_lock);
> INIT_LIST_HEAD(&port->phy_list);
> port->ha = sas_ha;
> diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c
> index 60b651b..062c03c 100644
> --- a/drivers/scsi/scsi_transport_sas.c
> +++ b/drivers/scsi/scsi_transport_sas.c
> @@ -934,6 +934,7 @@ struct sas_port *sas_port_alloc(struct device *parent, int port_id)
>
> mutex_init(&port->phy_list_mutex);
> INIT_LIST_HEAD(&port->phy_list);
> + INIT_LIST_HEAD(&port->destroy_list);
>
> if (scsi_is_sas_expander_device(parent)) {
> struct sas_rphy *rphy = dev_to_rphy(parent);
> diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
> index dae99d7..a7953c8 100644
> --- a/include/scsi/libsas.h
> +++ b/include/scsi/libsas.h
> @@ -91,7 +91,8 @@ enum discover_event {
> DISCE_SUSPEND = 4,
> DISCE_RESUME = 5,
> DISCE_DESTRUCT = 6,
> - DISC_NUM_EVENTS = 7,
> + DISCE_PORT_DESTRUCT = 7,
> + DISC_NUM_EVENTS,
> };
>
> /* ---------- Expander Devices ---------- */
> @@ -268,7 +269,8 @@ struct asd_sas_port {
> spinlock_t dev_list_lock;
> struct list_head dev_list;
> struct list_head disco_list;
> - struct list_head destroy_list;
> + struct list_head dev_destroy_list;
> + struct list_head port_destroy_list;
> enum sas_linkrate linkrate;
>
> struct sas_work work;
> @@ -702,6 +704,7 @@ extern int sas_bios_param(struct scsi_device *,
> int sas_ex_revalidate_domain(struct domain_device *);
>
> void sas_unregister_domain_devices(struct asd_sas_port *port, int gone);
> +void sas_port_destruct(struct asd_sas_port *port, struct sas_port *sas_port);
> void sas_init_disc(struct sas_discovery *disc, struct asd_sas_port *);
> int sas_discover_event(struct asd_sas_port *, enum discover_event ev);
>
> diff --git a/include/scsi/scsi_transport_sas.h b/include/scsi/scsi_transport_sas.h
> index 73d8709..b495aac 100644
> --- a/include/scsi/scsi_transport_sas.h
> +++ b/include/scsi/scsi_transport_sas.h
> @@ -154,6 +154,7 @@ struct sas_port {
>
> struct mutex phy_list_mutex;
> struct list_head phy_list;
> + struct list_head destroy_list; /* only used by libsas */
> };
>
> #define dev_to_sas_port(d) \
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.