For config options with only a single value, guarding the single value
with 'if' is the same as adding a 'depends' statement. And it's more
standard to just use 'depends'.
And if the option has both an 'if' guard and a 'depends' we can collapse
them into a single 'depends' by combining them with &&.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Now that support for 64k pages with a 4K kernel is removed, this code is
unreachable.
CONFIG_PPC_HAS_HASH_64K can only be true when CONFIG_PPC_64K_PAGES is
also true.
But when CONFIG_PPC_64K_PAGES is true we include pte-hash64.h which
includes pte-hash64-64k.h, which defines both pte_pagesize_index() and
crucially __real_pte, which means this definition can never be used.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
'0f1fb99 iommu/fsl: Fix section mismatch' was intended to address the modpost
warning and the potential crash. Crash which is actually easy to trigger with a
'unbind' followed by a 'bind' sequence. The fix is wrong as
fsl_of_pamu_driver.driver gets added by bus_add_driver() to a couple of
klist(s) which become invalid/corrupted as soon as the init sections are freed.
Depending on when/how the init sections storage is reused various/random errors
and crashes will happen
'cd70d46 iommu/fsl: Various cleanups' contains annotations that go further down
the wrong path laid by '0f1fb99 iommu/fsl: Fix section mismatch'
Now remove all the incorrect annotations from the above mentioned patches (not
exactly a revert) and those previously existing in the code, This fixes the
modpost warning(s), the unbind/bind sequence crashes and the random
errors/crashes
Fixes: 0f1fb99b62 ("iommu/fsl: Fix section mismatch")
Fixes: cd70d4659f ("iommu/fsl: Various cleanups")
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Acked-by: Varun Sethi <Varun.Sethi@freescale.com>
Cc: stable@vger.kernel.org
Tested-by: Madalin Bucur <Madalin.Bucur@freescale.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Back in the olden days we added support for using 64K pages to map the
SPU (Synergistic Processing Unit) local store on Cell, when the main
kernel was using 4K pages.
This was useful at the time because distros were using 4K pages, but
using 64K pages on the SPUs could reduce TLB pressure there.
However these days the number of Cell users is approaching zero, and
supporting this option adds unpleasant complexity to the memory
management code.
So drop the option, CONFIG_SPU_FS_64K_LS, and all related code.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Jeremy Kerr <jk@ozlabs.org>
The powerpc kernel can be built to have either a 4K PAGE_SIZE or a 64K
PAGE_SIZE.
However when built with a 4K PAGE_SIZE there is an additional config
option which can be enabled, PPC_HAS_HASH_64K, which means the kernel
also knows how to hash a 64K page even though the base PAGE_SIZE is 4K.
This is used in one obscure configuration, to support 64K pages for SPU
local store on the Cell processor when the rest of the kernel is using
4K pages.
In this configuration, pte_pagesize_index() is defined to just pass
through its arguments to get_slice_psize(). However pte_pagesize_index()
is called for both user and kernel addresses, whereas get_slice_psize()
only knows how to handle user addresses.
This has been broken forever, however until recently it happened to
work. That was because in get_slice_psize() the large kernel address
would cause the right shift of the slice mask to return zero.
However in commit 7aa0727f33 ("powerpc/mm: Increase the slice range to
64TB"), the get_slice_psize() code was changed so that instead of a
right shift we do an array lookup based on the address. When passed a
kernel address this means we index way off the end of the slice array
and return random junk.
That is only fatal if we happen to hit something non-zero, but when we
do return a non-zero value we confuse the MMU code and eventually cause
a check stop.
This fix is ugly, but simple. When we're called for a kernel address we
return 4K, which is always correct in this configuration, otherwise we
use the slice mask.
Fixes: 7aa0727f33 ("powerpc/mm: Increase the slice range to 64TB")
Reported-by: Cyril Bur <cyrilbur@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
When installing a block mapping, we unconditionally overwrite a non-leaf
PTE if we find one. However, this can cause a problem if the following
sequence of events occur:
(1) iommu_map called for a 4k (i.e. PAGE_SIZE) mapping at some address
- We initialise the page table all the way down to a leaf entry
- No TLB maintenance is required, because we're going from invalid
to valid.
(2) iommu_unmap is called on the mapping installed in (1)
- We walk the page table to the final (leaf) entry and zero it
- We only changed a valid leaf entry, so we invalidate leaf-only
(3) iommu_map is called on the same address as (1), but this time for
a 2MB (i.e. BLOCK_SIZE) mapping)
- We walk the page table down to the penultimate level, where we
find a table entry
- We overwrite the table entry with a block mapping and return
without any TLB maintenance and without freeing the memory used
by the now-orphaned table.
This last step can lead to a walk-cache caching the overwritten table
entry, causing unexpected faults when the new mapping is accessed by a
device. One way to fix this would be to collapse the page table when
freeing the last page at a given level, but this would require expensive
iteration on every map call. Instead, this patch detects the case when
we are overwriting a table entry and explicitly unmaps the table first,
which takes care of both freeing and TLB invalidation.
Cc: <stable@vger.kernel.org>
Reported-by: Brian Starkey <brian.starkey@arm.com>
Tested-by: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Describe capabilities of the HLCDC IP found on sama5d4 SoCs and add a
new entry to the atmel_hlcdc_of_match table.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Describe capabilities of the HLCDC IP found on at91sam9n12 SoC and add a
new entry to the atmel_hlcdc_of_match table.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Describe capabilities of the HLCDC IP found on at91sam9x5 SoCs and add a
new entry to the atmel_hlcdc_of_match table.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
The atmel-hlcdc driver already supports atomic operations, add the
missing DRM_ATOMIC flag to expose the atomic features to userspace.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
When we enter D0i3, we must stop TXing otherwise the
sequence number we use might conflict with the firmware's
internal TX. In order to do so, we have
IWL_MVM_STATUS_IN_D0I3 which should prevent any Tx while we
enter D0i3. There is a bug in this code since we may Tx even
if IWL_MVM_STATUS_IN_D0I3 is set. This can happen as long as
mvm->d0i3_ap_sta_id is not set.
To make sure that we don't have any packet in the Tx path
while we set mvm->d0i3_ap_sta_id, call synchronize_net only
after we already set mvm->d0i3_ap_sta_id.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Currently if we wake up during D0I3 due to beacon loss we disconnect
immediately. This behaviour causes redundant disconnection, which could
be prevented by polling as it is usually done in mac80211.
Instead, we prefer reporting beacon loss and let mac80211 try polling
before disconnection.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
KASan error report:
==================================================================
BUG: KASan: out of bounds access in iwl_init_sband_channels+0x207/0x260 [iwlwifi] at addr ffff8800c2d0aac8
Read of size 4 by task modprobe/329
==================================================================
Both loops of this function compare data from the 'chan' array and then
check if the index is valid.
The 2 conditions should be inverted to avoid an out-of-bounds access.
Signed-off-by: Adrien Schildknecht <adrien+dev@schischi.me>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Fix bug where MIMO is disabled for low latency TX on P2P VIF
regardless of configuration. Make it dependent on
IWL_MVM_RS_DISABLE_P2P_MIMO compilation option. Change configuration
so that MIMO will be disabled only in SDIO platforms.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
This switches the BCMA GPIO driver to use GPIOLIB_IRQCHIP to
handle its interrupts instead of rolling its own copy of the
irqdomain handling etc.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Add diversity statistics and sync the driver
statistics acx and debugfs representation
with the current fw api.
Signed-off-by: Guy Mishol <guym@ti.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Sync the driver statistics acx and debugfs representation
with the current fw api.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
rt2500usb_validate_eeprom() read data up to 0x6e (EEPROM_CALIBRATE_OFFSET)
but only 0x6a bytes has been allocated and read from the eeprom.
This lead to out-of-bound accesses and invalid values for
EEPROM_BBPTUNE_R17 and EEPROM_CALIBRATE_OFFSET.
Change the EEPROM_SIZE to 0x6e in order to retrieve all the fields.
Tested with a rt2570 device.
Signed-off-by: Adrien Schildknecht <adrien+dev@schischi.me>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
CC [M] drivers/net/wireless/mwl8k.o
drivers/net/wireless/mwl8k.c: In function ‘mwl8k_bss_info_changed’:
drivers/net/wireless/mwl8k.c:3290:2: warning: ‘ap_mcs_rates’ may be used uninitialized in this function [-Wmaybe-uninitialized]
memcpy(cmd->mcs_set, mcs_rates, 16);
^
drivers/net/wireless/mwl8k.c:4987:5: note: ‘ap_mcs_rates’ was declared here
u8 ap_mcs_rates[16];
^
The warning was bogus. But the conditionals were rather complicated,
with multiple redundant checks. This consolidates the checking and
makes it more readable IMHO.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
I remove duplicated routines which related rtl92cu_set_hw_reg().
1. rtl92c_set_qos() and HW_VAR_AC_PARAM routine are similar code.
so i replace code with rtlpriv->cfg->ops->set_hw_reg().
2. rtl92c_set_mac_addr() and 'HW_VAR_ETHER_ADDR' case at
rtl92cu_set_hw_reg() routine are similar code.
so i removed rtl92c_set_mac_addr() function.
also it was not used anywhere.
3. remove HW_VAR_ACM_CTRL routine in rtl92cu_set_hw_reg().
if rtl_usb->acm_method is not EACMWAY2_SW, HW_VAR_ACM_CTRL is called
from HW_VAR_AC_PARAM. but it never called. because acm_method is always
EACMWAY2_SW. so i remove acm_method check routine
and HW_VAR_ACM_CTRL routine.
both usb and pci interface is not used HW_VAR_ACM_CTRL.
but i can't test pci interface module, so i didn't modify pci code.
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
rtl92c_set_xxx_filter is same routine with rtl92cu_set_hw_reg.
so i remove those functions that are rtl92c_set_xxx_filter.
(rtl92c_get_xxx_filter is also same reason.)
also i add code updating struct rtl_mac member variable in the
rtl92cu_set_hw_reg.
after that, no more _update_mac_setting is not useful. thus i remove that.
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Allow the topology code to be compiled out so that users who don't need
topology don't need to havve the code compiled in, saving them some
memory.
Some more configuration could be added to remove some of the hooks into
the core data structures but that is probably best done with some
refactoring to use functions to do the updates of the data structures
rather than ifdefing in the code as we'd need to do at the minute.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Tom Herbert says:
====================
net: Identifier Locator Addressing - Part I
This patch set provides rudimentary support for Identifier Locator
Addressing or ILA. The basic concept of ILA is that we split an IPv6
address into a 64 bit locator and 64 bit identifier. The identifier is
the identity of an entity in communication ("who"), and the locator
expresses the location of the entity ("where"). Applications
use externally visible address that contains the identifier.
When a packet is actually sent, a translation is done that
overwrites the first 64 bits of the address with a locator.
The packet can then be forwarded over the network to the host where
the addressed entity is located. At the receiver, the reverse
translation is done so the that the application sees the original,
untranslated address. Presumably an external control plane will
provide identifier->locator mappings.
v2:
- Fix compilation erros when LWT not configured
- Consolidate ILA into a single ila.c
v3:
- Change pseudohdr argument od inet_proto_csum_replace functions to
be a bool
v4:
- In ila_build_state check locator being in netlink params before
allocating tunnel state
The data path for ILA is a simple NAT translation that only operates
on the upper 64 bits of a destination address in IPv6 packets. The
basic process is:
1) Lookup 64 bit identifier (lower 64 bits of destination)
2) If a match is found
a) Overwrite locator (upper 64 bits of destination) with
the new locator
b) Adjust any checksum that has destination address included in
pseudo header
3) Send or receive packet
ILA is a means to implement tunnels or network virtualization without
encapsulation. Since there is no encapsulation involved, we assume that
stateless support in the network for IPv6 (e.g. RSS, ECMP, TSO, etc.)
just works. Also, since we're minimally changing the packet many of
the worries about encapsulation (MTU, checksum, fragmentation) are
not relevant. The downside is that, ILA is not extensible like other
encapsulations (GUE for instance) so it might not be appropriate for
all use cases. Also, this only makes sense to do in IPv6!
A key aspect of ILA is performance. The intent is that ILA would be
used in data centers in virtualizing tasks or jobs. In the fullest
incarnation all intra data center communications might be targeted to
virtual ILA addresses. This is basically adding a new virtualization
capability to the existing services in a datacenter, so there is a
strong expectation is that this does not degrade performance for
existing applications.
Performance seems to be dependent on how ILA is hooked into kernel.
ILA can be implemented under some different models:
- Mechanically it is a form a stateless DNAT
- It can be thought of as a type of (source) routing
- As a functional replacement of encapsulation
In this patch set we hook into the data path using Light Weight
Tunnels (LWT) infrastructure. As part of that, we add support in LWT
to redirect dst input. iproute will be modified to take a new ila encap
type. ILA can be configured like:
ip route add 3333:0:0:1:5555:0:2:0/128 \
encap ila 2001:0:0:2 via 2401:db00:20:911a:face:0:27:0
ip -6 addr add 3333:0:0:1:5555:0:1:0/128 dev eth0
ip route add table local local 2001:0:0:1:5555:0:1:0/128
encap ila 3333:0:0:1 dev lo
So sending to destination 3333:0:0:1:5555:0:2:0 will have destination
of 2001:0:0:2:5555:0:2:0 on the wire.
Performance results are below. With ILA we see about a 10% drop in
pps compared to non-ILA. Much of this drop can be attributed to the
loss of early demux on input (translation occurs after it is attempted).
We will address this in the next patch set. Also, IPvlan input path
does not work with ILA since the routing is bypassed-- this will
be addressed in a future patch.
Performance testing:
Performing netperf TCP_RR with 200 clients:
Non-ILA baseline
84.92% CPU utilization
1861922.9 tps
93/163/330 50/90/99% latencies
ILA single destination
83.16% CPU utilization
1679683.4 tps
105/180/332 50/90/99% latencies
References:
Slides from netconf:
http://vger.kernel.org/netconf2015Herbert-ILA.pdf
Slides from presentation at IETF:
https://www.ietf.org/proceedings/92/slides/slides-92-nvo3-1.pdf
I-D:
https://tools.ietf.org/html/draft-herbert-nvo3-ila-00
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Adding new module name ila. This implements ILA translation. Light
weight tunnel redirection is used to perform the translation in
the data path. This is configured by the "ip -6 route" command
using the "encap ila <locator>" option, where <locator> is the
value to set in destination locator of the packet. e.g.
ip -6 route add 3333:0:0:1:5555:0:1:0/128 \
encap ila 2001:0:0:1 via 2401:db00:20:911a:face:0:25:0
Sets a route where 3333:0:0:1 will be overwritten by
2001:0:0:1 on output.
Signed-off-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This function updates a checksum field value and skb->csum based on
a value which is the difference between the old and new checksum.
Signed-off-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
inet_proto_csum_replace4,2,16 take a pseudohdr argument which indicates
the checksum field carries a pseudo header. This argument should be a
boolean instead of an int.
Signed-off-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds the capability to redirect dst input in the same way
that dst output is redirected by LWT.
Also, save the original dst.input and and dst.out when setting up
lwtunnel redirection. These can be called by the client as a pass-
through.
Signed-off-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
>> drivers/net/ethernet/cisco/enic/vnic_dev.c:1095:13: sparse: incorrect type in assignment (different address spaces)
drivers/net/ethernet/cisco/enic/vnic_dev.c:1095:13: expected void *res
drivers/net/ethernet/cisco/enic/vnic_dev.c:1095:13: got void [noderef] <asn:2>*
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
>> drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:173:44: sparse: incorrect type in argument 1 (different base types)
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:173:44: expected restricted __sum16 [usertype] n
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:173:44: got restricted __be16 [usertype] check_sum
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There's a small consistency problem between the inode and writeback
naming. Writeback calls the "for IO" inode queues b_io and
b_more_io, but the inode calls these the "writeback list" or
i_wb_list. This makes it hard to an new "under writeback" list to
the inode, or call it an "under IO" list on the bdi because either
way we'll have writeback on IO and IO on writeback and it'll just be
confusing. I'm getting confused just writing this!
So, rename the inode "for IO" list variable to i_io_list so we can
add a new "writeback list" in a subsequent patch.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Tested-by: Dave Chinner <dchinner@redhat.com>
LS1021A is a QorIQ SoC having little endian CAAM.
There are a few differences b/w QorIQ and i.MX from CAAM perspective:
1. i.MX platforms are somewhat special wrt. 64-bit registers:
-big endian format at 64-bit level: MSW at address+0 and LSW at address+4
-little endian format at 32-bit level (within MSW and LSW)
and thus need special handling.
2. No CCM (clock controller module) for QorIQ.
No CAAM clocks to enable / disable.
A new Kconfig option - CRYPTO_DEV_FSL_CAAM_LE - is added to indicate
CAAM is little endian (*). It is hidden from the user (to avoid
misconfiguration); when adding support for a new platform with LE CAAM,
either the Kconfig needs to be updated or the corresponding defconfig
needs to indicate that CAAM is LE.
(*) Using a DT property to provide CAAM endianness would not allow
for the ifdeffery.
In order to keep changes to a minimum, the following changes
are postponed:
-endianness fix of the last word in the S/G (rsvd2, bpid, offset),
fields are always 0 anyway;
-S/G format fix for i.MX7 (yes, i.MX7 support was not added yet,
but still...)
Signed-off-by: Horia Geant? <horia.geanta@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
GHASH table algorithm is using a big endian key.
In little endian machines key will be LE ordered.
After a lxvd2x instruction key is loaded as it is,
LE/BE order, in first case it'll generate a wrong
table resulting in wrong hashes from the algorithm.
Bug affects only LE machines.
In order to fix it we do a swap for loaded key.
Cc: stable@vger.kernel.org
Signed-off-by: Leonidas S Barbosa <leosilva@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
AES-CTR is using a counter 8bytes-8bytes what miss match with
kernel specs.
In the previous code a vadduwm was done to increment counter.
Replacing this for a vadduqm now considering both cases counter
8-8 bytes and full 16bytes.
Cc: stable@vger.kernel.org
Signed-off-by: Leonidas S Barbosa <leosilva@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
IFC NAND chip select is wrongly mapped to 2 in reg property of
NAND node. Due to this kernel is not able probe NAND flash. Set
chip select to 1 in reg property.
Signed-off-by: Jaiprakash Singh <b44839@freescale.com>
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
SCFG provides SoC specific configuration and status registers for
the chip. Add this for powerpc platform.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
T1040D4RDB/T1042D4RDB are Freescale Reference Design Board
which can support T1040/T1042 QorIQ Power
Architecture™ processor respectively
T1040D4RDB/T1042D4RDB board Overview
-------------------------------------
- SERDES Connections, 8 lanes supporting:
- PCI
- SGMII
- SATA 2.0
- QSGMII(only for T1040D4RDB)
- DDR Controller
- Supports rates of up to 1600 MHz data-rate
- Supports one DDR4 UDIMM
-IFC/Local Bus
- NAND flash: 1GB 8-bit NAND flash
- NOR: 128MB 16-bit NOR Flash
- Ethernet
- Two on-board RGMII 10/100/1G ethernet ports.
- PHY #0 remains powered up during deep-sleep
- CPLD
- Clocks
- System and DDR clock (SYSCLK, “DDRCLK”)
- SERDES clocks
- Power Supplies
- USB
- Supports two USB 2.0 ports with integrated PHYs
- Two type A ports with 5V@1.5A per port.
- SDHC
- SDHC/SDXC connector
- SPI
- On-board 64MB SPI flash
- I2C
- Devices connected: EEPROM, thermal monitor, VID controller
- Other IO
- Two Serial ports
- ProfiBus port
Add support for T1040/T1042D4RDB board:
-add device tree
-Add entry in corenet_generic.c
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
The c293pcie board is an endpoint device and it doesn't need PM,
so remove hooks pcibios_fixup_phb and pcibios_fixup_bus.
Signed-off-by: Hou Zhiqiang <B48286@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
It makes no sense to put the instructions for calculating the lock
value (cpu number + 1) and the clearing of eq bit of cr1 in lbarx/stbcx
loop. And when the lock is acquired by the other thread, the current
lock value has no chance to equal with the lock value used by current
cpu. So we can skip the comparing for these two lock values in the
lbz/bne loop.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
