Instead of removing mark from object list from fsnotify_detach_mark(),
remove the mark when last reference to the mark is dropped. This will
allow fanotify to wait for userspace response to event without having to
hold onto fsnotify_mark_srcu.
To avoid pinning inodes by elevated refcount (and thus e.g. delaying
file deletion) while someone holds mark reference, we detach connector
from the object also from fsnotify_destroy_marks() and not only after
removing last mark from the list as it was now.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Currently we queue mark into a list of marks for destruction in
__fsnotify_free_mark() and keep the last mark reference dangling. After the
worker waits for SRCU period, it drops the last reference to the mark
which frees it. This scheme has the disadvantage that if we hold
reference to a mark and drop and reacquire SRCU lock, the mark can get
freed immediately which is slightly inconvenient and we will need to
avoid this in the future.
Move to a scheme where queueing of mark into a list of marks for
destruction happens when the last reference to the mark is dropped. Also
drop reference to the mark held by group list already when mark is
removed from that list instead of dropping it only from the destruction
worker.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Dropping mark reference can result in mark being freed. Although it
should not happen in inotify_remove_from_idr() since caller should hold
another reference, just don't risk lock up just after WARN_ON
unnecessarily. Also fold do_inotify_remove_from_idr() into the single
callsite as that function really is just two lines of real code.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Currently we free fsnotify_mark_connector structure only when inode /
vfsmount is getting freed. This can however impose noticeable memory
overhead when marks get attached to inodes only temporarily. So free the
connector structure once the last mark is detached from the object.
Since notification infrastructure can be working with the connector
under the protection of fsnotify_mark_srcu, we have to be careful and
free the fsnotify_mark_connector only after SRCU period passes.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
So far list of marks attached to an object (inode / vfsmount) was
protected by i_lock or mnt_root->d_lock. This dictates that the list
must be empty before the object can be destroyed although the list is
now anchored in the fsnotify_mark_connector structure. Protect the list
by a spinlock in the fsnotify_mark_connector structure to decouple
lifetime of a list of marks from a lifetime of the object. This also
simplifies the code quite a bit since we don't have to differentiate
between inode and vfsmount lists in quite a few places anymore.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
After removing all the indirection it is clear that
hlist_del_init_rcu(&mark->obj_list);
in fsnotify_destroy_marks() is not needed as the mark gets removed from
the list shortly afterwards in fsnotify_destroy_mark() ->
fsnotify_detach_mark() -> fsnotify_detach_from_object(). Also there is
no problem with mark being visible on object list while we call
fsnotify_destroy_mark() as parallel destruction of marks from several
places is properly handled (as mentioned in the comment in
fsnotify_destroy_marks(). So just remove the list removal and also the
stale comment.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
We lock object list lock in fsnotify_detach_from_object() twice - once
to detach mark and second time to recalculate mask. That is unnecessary
and later it will become problematic as we will free the connector as
soon as there is no mark in it. So move recalculation of fsnotify mask
into the same critical section that is detaching mark.
This also removes recalculation of child dentry flags from
fsnotify_detach_from_object(). That is however fine. Those marks will
get recalculated once some event happens on a child.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
fsnotify_detach_mark() calls fsnotify_destroy_inode_mark() or
fsnotify_destroy_vfsmount_mark() to remove mark from object list. These
two functions are however very similar and differ only in the lock they
use to protect the object list of marks. Simplify the code by removing
the indirection and removing mark from the object list in a common
function.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Instead of passing spinlock into fsnotify_destroy_marks() determine it
directly in that function from the connector type. This will reduce code
churn when changing lock protecting list of marks.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Move locking of a mark list into fsnotify_find_mark(). This reduces code
churn in the following patch changing lock protecting the list.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Move locking of locks protecting a list of marks into
fsnotify_recalc_mask(). This reduces code churn in the following patch
which changes the lock protecting the list of marks.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Move fsnotify_destroy_marks() to be later in the fs/notify/mark.c. It
will need some functions that are declared after its current
declaration. No functional change.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Adding notification mark to object list has been currently done through
fsnotify_add_{inode|vfsmount}_mark() helpers from
fsnotify_add_mark_locked() which call fsnotify_add_mark_list(). Remove
this unnecessary indirection to simplify the code.
Pushing all the locking to fsnotify_add_mark_list() also allows us to
allocate the connector structure with GFP_KERNEL mode.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Currently inode reference is held by fsnotify marks. Change the rules so
that inode reference is held by fsnotify_mark_connector structure
whenever the list is non-empty. This simplifies the code and is more
logical.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Move pointer to inode / vfsmount from mark itself to the
fsnotify_mark_connector structure. This is another step on the path
towards decoupling inode / vfsmount lifetime from notification mark
lifetime.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Currently notification marks are attached to object (inode or vfsmnt) by
a hlist_head in the object. The list is also protected by a spinlock in
the object. So while there is any mark attached to the list of marks,
the object must be pinned in memory (and thus e.g. last iput() deleting
inode cannot happen). Also for list iteration in fsnotify() to work, we
must hold fsnotify_mark_srcu lock so that mark itself and
mark->obj_list.next cannot get freed. Thus we are required to wait for
response to fanotify events from userspace process with
fsnotify_mark_srcu lock held. That causes issues when userspace process
is buggy and does not reply to some event - basically the whole
notification subsystem gets eventually stuck.
So to be able to drop fsnotify_mark_srcu lock while waiting for
response, we have to pin the mark in memory and make sure it stays in
the object list (as removing the mark waiting for response could lead to
lost notification events for groups later in the list). However we don't
want inode reclaim to block on such mark as that would lead to system
just locking up elsewhere.
This commit is the first in the series that paves way towards solving
these conflicting lifetime needs. Instead of anchoring the list of marks
directly in the object, we anchor it in a dedicated structure
(fsnotify_mark_connector) and just point to that structure from the
object. The following commits will also add spinlock protecting the list
and object pointer to the structure.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Add a comment that lifetime of a notification mark is protected by SRCU
and remove a comment about clearing of marks attached to the inode. It
is stale and more uptodate version is at fsnotify_destroy_marks() which
is the function handling this case.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Currently audit code uses checking of mark->inode to verify whether mark
is still alive. Switch that to checking mark flags as that is more
logical and current way will become unreliable in future.
Reviewed-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Add pinctrl dtsi file for HiKey960 development board, enable
5 pinmux devices and 1 pinconf device, also include some nodes
of configurations for pins.
Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin@hisilicon.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Extend drive strength levels of the pins for Hi3660 Soc.
Signed-off-by: Wang Xiaoyin <hw.wangxiaoyin@hisilicon.com>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Add a new serio ID for the RainShadow Tech USB HDMI CEC adapter.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
The retry queue is intended to provide a temporary buffer in the case
of transient errors when communicating with auditd, it is not meant
as a long life queue, that functionality is provided by the hold
queue.
This patch fixes a problem identified by Seth where the retry queue
could grow uncontrollably if an auditd instance did not connect to
the kernel to drain the queues. This commit fixes this by doing the
following:
* Make sure we always call auditd_reset() if we decide the connection
with audit is really dead. There were some cases in
kauditd_hold_skb() where we did not reset the connection, this patch
relocates the reset calls to kauditd_thread() so all the error
conditions are caught and the connection reset. As a side effect,
this means we could move auditd_reset() and get rid of the forward
definition at the top of kernel/audit.c.
* We never checked the status of the auditd connection when
processing the main audit queue which meant that the retry queue
could grow unchecked. This patch adds a call to auditd_reset()
after the main queue has been processed if auditd is not connected,
the auditd_reset() call will make sure the retry and hold queues are
correctly managed/flushed so that the retry queue remains reasonable.
Cc: <stable@vger.kernel.org> # 4.10.x-: 5b52330bbf
Reported-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Move all the EDAC core functionality behind CONFIG_EDAC and get rid of
that indirection. Update defconfigs which had it.
While at it, fix dependencies such that EDAC depends on RAS for the
tracepoints.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: linux-edac@vger.kernel.org
Use mc_devices list instead to check whether we have EDAC driver
instances successfully registered with EDAC core.
Signed-off-by: Borislav Petkov <bp@suse.de>
Apparently, some machines used to report DRAM errors through a PCI SERR
NMI. This is why we have a call into EDAC in the NMI handler. See
c0d1217202 ("drivers/edac: add new nmi rescan").
From looking at the patch above, that's two drivers: e752x_edac.c and
e7xxx_edac.c. Now, I wanna say those are old machines which are probably
decommissioned already.
Tony says that "[t]the newest CPU supported by either of those drivers
is the Xeon E7520 (a.k.a. "Nehalem") released in Q1'2010. Possibly some
folks are still using these ... but people that hold onto h/w for 7
years generally cling to old s/w too ... so I'd guess it unlikely that
we will get complaints for breaking these in upstream."
So even if there is a small number still in use, we did load EDAC with
edac_op_state == EDAC_OPSTATE_POLL by default (we still do, in fact)
which means a default EDAC setup without any parameters supplied on the
command line or otherwise would never even log the error in the NMI
handler because we're polling by default:
inline int edac_handler_set(void)
{
if (edac_op_state == EDAC_OPSTATE_POLL)
return 0;
return atomic_read(&edac_handlers);
}
So, long story short, I'd like to get rid of that nastiness called
edac_stub.c and confine all the EDAC drivers solely to drivers/edac/. If
we ever have to do stuff like that again, it should be notifiers we're
using and not some insanity like this one.
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
This function should not be called with long timeouts in atomic context.
Annotate it as might_sleep if timeout is longer than 10us.
v2: fix comment (Michal)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170410121747.209200-1-michal.wajdeczko@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
*) Add new PHY driver for Qualcomm's QMP PHY (used by PCIe, UFS and USB)
*) Add new PHY driver for Qualcomm's QUSB2 PHY
*) Add support for vbus regulator in rockchip-usb driver
*) Add support for usb2-phy in rk3328 to rockchip-inno-usb2 driver
*) Add support for a new version of PHY in phy-mt65xx-usb3 driver
*) Add support for Allwinner A64 PHY to switch between MUSB and EHCI/OHCI
*) Cleanups in Exynos driver and phy-mt65xx-usb3 driver
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJY62nSAAoJEA5ceFyATYLZWkoP/2lImyWp5P61S8cOdvli1SHj
J/TIfcyGyvwTQPtUdYGQmgS0JfBtXkSqu5y5E+diIyZMSSLsob7udJ+qeO4WWtOQ
wNOm2MTNAyOvbYqdhEiUWRXGLhCkVmhfFoUG5tB2FXnOHMDVc14PFh3U1PmqETWN
QIL3oc44L9JGgeGcYvGWJHm1pcLxD7eHPzkeqS4+KJfX4ehFo5kuZId1K7YM5cdZ
EgQ8UQy93jDB2t/0x6wrd7MQ+saSiB8gg7U6UOBR7cm57pXBvs1LTvk6qqIGSG3r
xmlYyI/N3QaU7Z3yGpCRyMGj7JZslBAzYBX/U0s6sio4IcQT5Vyp3moSnTjCexR0
LIpZJoiTf45hZ6JUIxRrPFM9UG6vKVhobtXHzLwbRiSQxN1IPmT+j9HsDEBHdmvu
qNGwkciuaBsS5hRJeIs7gR52wCt8PRKH1riXbeTi5O1t/h98pnf5Dlasvtvl9E20
cMa3o/8YSrwspOXqJ8er4rHc3SEKb+FLBHko/unqK1Sf3xOEaU4lle4F459P7MVN
2btEvSlOKbgYwnlOuKw7xwZX3rmNnPh/IZpqRLlI0vf4OvlabaW1u+toirCaaD2K
Jkfw2yvy41qXfD/4ERH9NcWmryhgRHTV1KCpmQGNzJdk8RTZAoRd8EOSuQ4kZBKr
NCx4jg4+N8llxItXXXFF
=7TO8
-----END PGP SIGNATURE-----
Merge tag 'phy-for-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next
Kishon writes:
phy: for 4.12
*) Add new PHY driver for Qualcomm's QMP PHY (used by PCIe, UFS and USB)
*) Add new PHY driver for Qualcomm's QUSB2 PHY
*) Add support for vbus regulator in rockchip-usb driver
*) Add support for usb2-phy in rk3328 to rockchip-inno-usb2 driver
*) Add support for a new version of PHY in phy-mt65xx-usb3 driver
*) Add support for Allwinner A64 PHY to switch between MUSB and EHCI/OHCI
*) Cleanups in Exynos driver and phy-mt65xx-usb3 driver
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Detailed description for this pull request:
1. Add new 'extcon-intel-cht-wc.c' driver
- Intel Cherrytrail Whiskey Cove PMIC extcon driver supports
the detection of the charger connectors and the control.
2. Add new extcon API to monitor the all external connectors.
- The extcon consumer might need to monitor the all supported external
connectors from the extcon device. Before, the extcon consumer
should have each notifier_block structure for each external connector.
In order to support the requirement, the extcon adds new
extcon_register_notifier_all() API. The extcon consumer is able
to monitor the state change of all supported external connectors
from the extcon device by using only one notifier_block.
- extcon_(register|unregister)_notifier_all(struct extcon_dev *edev
struct notifier_block *nb)
- devm_extcon_(register|unregister)_notifier_all(struct device *dev,
struct extcon_dev *edev
struct notifier_block *nb)
3. Remove porting compatibility of old switch class
- The extcon removes the porting compatibility of old switch class
because there are no any use-case and requirement of switch class.
4. Update the extcon drivers and Fix the minor issues
- Revert the ACPI gpio interface on the extcon-usb-gpioc.c.
- Fix the issues related to the suspend-to-ram for both extcon-usb-gpio.c
and extcon-palmas.c.
- Add warning message for extcon-arizona.c when headphone detection is not
finished.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJY6xdjAAoJEJzN3yze689TKp4QAIRtX/6/8SsF29wI6ViQvJCi
OcBhiaKPqUJqJB5lK5wHvXR898Zx3PibAY4RNhcFCbXfiTgGeIGtG3OiN5+PpZ+i
+gUbVR2ec6G6YMTOmpiatKX8kdaknDMet6Czj9Ap4i8qW7XVZrx8k5rX3eQygb+9
kPG8VGYkdTWpJwqZ/GR5DiOe0tSlzH9jDBFxBYEUEQSfXLvwmieDWrKVZHXcI4lB
BaCy/v0yh/jWXe+/ZgM9Fff0a+NJLbIfVmVGmrUhy7iAyDfeP91Df5uv6PPzPX9b
GKIqAbJB1B//MK8pON2ZL0RuTssD/7akENrmd+eHDuqA7eFf1+aL2Em8eBJ3S+Xh
uBFt4dWR6Gctwsmkyu5GOOFgAzPB+9aCFEEOTjnzBszj3U7lIzqDq6G2Mrg4gb7b
3Y4pS2JjA2V6lpflGomfhfIEq7hDmr7LB4/kl8Odf1C3pJI3lwmIux883qm+zmIO
zl0vKVpWoskxl7yMxLGALhiRN/gUQF4grcSGDWHQ6lmcREgo5Ixw8IUUcnpabmqy
UAZgixdNutquaAF+QvZ8VshktcleMYxWZhvJ/ttPee8RNvh6yTqgcRM/8ujrQPPT
xVamXHOgs92K1Ljw1Er+YnmCH3C6nL6Amsr7Ya2VmIPtXDuWxIRmk5NAFTc+XVb1
IK8Me7KVb0FF910in2/m
=UAR0
-----END PGP SIGNATURE-----
Merge tag 'extcon-next-for-4.12' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next
Update extcon for 4.12
Detailed description for this pull request:
1. Add new 'extcon-intel-cht-wc.c' driver
- Intel Cherrytrail Whiskey Cove PMIC extcon driver supports
the detection of the charger connectors and the control.
2. Add new extcon API to monitor the all external connectors.
- The extcon consumer might need to monitor the all supported external
connectors from the extcon device. Before, the extcon consumer
should have each notifier_block structure for each external connector.
In order to support the requirement, the extcon adds new
extcon_register_notifier_all() API. The extcon consumer is able
to monitor the state change of all supported external connectors
from the extcon device by using only one notifier_block.
- extcon_(register|unregister)_notifier_all(struct extcon_dev *edev
struct notifier_block *nb)
- devm_extcon_(register|unregister)_notifier_all(struct device *dev,
struct extcon_dev *edev
struct notifier_block *nb)
3. Remove porting compatibility of old switch class
- The extcon removes the porting compatibility of old switch class
because there are no any use-case and requirement of switch class.
4. Update the extcon drivers and Fix the minor issues
- Revert the ACPI gpio interface on the extcon-usb-gpioc.c.
- Fix the issues related to the suspend-to-ram for both extcon-usb-gpio.c
and extcon-palmas.c.
- Add warning message for extcon-arizona.c when headphone detection is not
finished.
Currently, the arch timer driver uses ARCH_TIMER_PHYS_SECURE_PPI to mean
the driver will use the secure PPI *and* potentially also use the
non-secure PPI. This is somewhat confusing.
For arm64 it never makes sense to use the secure PPI, but we do anyway,
inheriting this behaviour from 32-bit arm. For ACPI, we may not even
have a valid secure PPI, so we need to be able to only request the
non-secure PPI.
To that end, this patch reworks the timer driver so that we can request
the non-secure PPI alone. The PPI selection is split out into a new
function, arch_timer_select_ppi(), and verification of the selected PPI
is shifted out to callers (as DT may select the PPI by other means and
must handle this anyway).
We now consistently use arch_timer_has_nonsecure_ppi() to determine
whether we must manage a non-secure PPI *in addition* to a secure PPI.
When we only have a non-secure PPI, this returns false.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
[Mark: reword commit message]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
This patch add a new enum "arch_timer_spi_nr" and use it in the driver.
Just for code's readability, no functional change.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
To support the arm_arch_timer via ACPI we need to share defines and enums
between the driver and the ACPI parser code.
So we split out the relevant defines and enums into arm_arch_timer.h.
No functional change.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
In preparation for moving the PPI enum out into a header, rename the
enum and its constituent values these so they are namespaced w.r.t. the
arch timer. This will aid consistency and avoid potential name clashes
when this move occurs.
No functional change.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
[Mark: reword commit message]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
The Duckbill devices are small, pen-drive sized boards based on
NXP's i.MX28 SoC. While the initial variants (Duckbill series)
were equipped with a micro SD card slot only, the latest generation
(Duckbill 2 series) have an additional internal eMMC onboard.
To distinguish between both generations, a new device tree
compatible string was introduced. To get the MAC address fixup
applied, we need to check for this new string here, too.
Signed-off-by: Michael Heimpold <michael.heimpold@i2se.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
In preparation for moving the type macros out into a header, rename
these so they are namespaced w.r.t. the arch timer. We'll apply the same
prefix to other definitions in subsequent patches. This will aid
consistency and avoid potential name clahses when this move occurs.
No functional change.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
[Mark: reword commit message]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Almost all string in the arm_arch_timer driver duplicate an common
prefix (though a few do not). For consistency, it would be better to use
pr_fmt(), and always use this prefix. At the same time, we may as well
clean up some whitespace issues in arch_timer_banner and
arch_timer_init.
No functional change.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
[Mark: reword commit message]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
These params are passed by value, const qualifiers are ignored any way.
While around, unify timeout_ms type from long to int.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170410093817.151280-1-michal.wajdeczko@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We need to set LPES in order for normal external interrupts (0x500)
to be directed to the guest while running in guest state.
We also need HEIC set to prevent them to be sent to the host while
in host state.
With XIVE the host never gets one of these and wouldn't know how to
handle it. All host external interrupts come in via the new
hypervisor virtualization interrupts vector.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
