| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This warning is misleading. In many cases, for example P2P ROC time
events, this will happen if the time event is aborted, for example
due to a higher priority time event. This is entirely normal and not
worth warning about.
In other cases, where we actually do act upon this, for example when
trying to connect and this fails, we should instead warn as part of
the disconnect operation.
Change the code to do that, i.e. make the warning a debug message,
and make it more prominent (an error) when we actually disconnect
because of it.
This also fixes confusion in the logs - the warning was mistaken for
something that needed investigation, while in most cases it's just
expected behaviour that occasionally some lower-priority time events
would not complete fully.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
In 8000 HW family B-step only, the ICCM is separate
from the SRAM. This adds the ICCM to the dump data
collected for FW debug.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are transport that must buffer frames in the driver.
This means that we have frames that are not in the op_mode
and not visible to the firwmare. This causes issues when we
flush the queues: the op_mode flushes a queue, and the
firmware flushes all the frames that are *currently* on the
rings, but if the transport buffers frames, it can submit
these while we are flushing. This leads to a situation
where we still have frames on the queues after we flushed
them.
Preventing those buffered frame from getting into the
firmware is possible, but then, we have to run the Tx
response path on frames that didn't reach the firmware
which is not desirable.
The way I solve this here is to let these frames go to the
firmware, but make sure the firmware will not transmit them
(by setting the station as draining). The op_mode then needs
to wait until the transport itself is empty to be sure that
the queue is really empty.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
For each RX packet until this patch there only was a debug
print of the HCMD and the offset. This adds also the
sequence number of the packet for easier matching between
what was sent, what came back / was received, and what
got stuck somewhere and was never responded by the FW.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to FW methodology, the capability bits should be the only ones
that change per-HW. The API bits should remain constant across different
HWs.
Currently this is not the case with multi-source LAR (API bit 9). Assign
a new capability bit to eventually replace the API bit. Until the API bit
can be deprecated, the driver will check either to enable multi-source
LAR.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|
|
|
|
|
|
|
|
|
|
| |
If, on a GO, the CSA time event fails to be scheduled, continue the
flow towards mac80211's state machine so it doesn't get stuck, but
report an error later on the post switch which will cause mac80211
to tear down the operation. This ensures nothing gets stuck due to
the scheduling failure.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If this situation ever happens, the mac80211 state machine gets
confused because it never clears csa_active. There was a separate
bug that lead to this happening with a working connection, but it
isn't very robust to try to keep the connection up in this case.
When removing the time event the CSA essentially procedure stops,
so the safest thing to do is to disconnect in this case.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
mac80211 now informs the driver when to drop the packets
upon flush(). This will happen before disconnecting, or
before we shut down the interface. We can now rely on this
to drop all the packets including the VO queues.
When mac80211 sets drop to false, wait for all the queues
to be empty.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The commit below introduced an unsafe dereference of
mvmvif->phy_ctxt. It can be NULL even if we hold the mutex.
We can be handling a BT Coex notification while the vif has
already been unassigned. This can happen since the BT Coex
notification is hanled asynchronuously: we can have started
to handle the BT Coex notification trying to acquire the
mutex while the unassign flow already got it. The BT Coex
notification handling will wait for the mutext. I'll get it
later, but then mvmvif->phy_ctxt will be NULL.
Panic log:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<f985180d>] iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm]
*pdpt = 0000000000000000 *pde = f000eef300000007
Oops: 0000 [#1] SMP
Workqueue: events iwl_mvm_async_handlers_wk [iwlmvm]
task: ed719b20 ti: ec03e000 task.ti: ec03e000
EIP: 0060:[<f985180d>] EFLAGS: 00010202 CPU: 2
EIP is at iwl_mvm_bt_notif_iterator+0x9d/0x340 [iwlmvm]
EAX: 00000000 EBX: f6d3cb70 ECX: f6d3cb70 EDX: 00000000
ESI: ec03fe40 EDI: efeb8810 EBP: ec03fdf0 ESP: ec03fdac
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
CR0: 80050033 CR2: 00000000 CR3: 01a1a000 CR4: 001407f0
Stack:
f743ca80 f744a404 ec03fdcc c10e3952 00003aba f743ca80 00000246 f743ca80
00000246 00000000 00000001 00000000 ebd45ff6 ebd458a4 f6d3c500 ebd45578
ebd44b01 ec03fe18 f99e1bc2 00000002 ebd44bc0 f9851770 00000000 f6d3c500
Call Trace:
[<c10e3952>] ? ring_buffer_unlock_commit+0xa2/0xd0
[<f99e1bc2>] __iterate_interfaces+0x82/0x110 [mac80211]
[<f9851770>] ? iwl_mvm_bt_coex_reduced_txp+0x140/0x140 [iwlmvm]
[<f99e1c6a>] ieee80211_iterate_active_interfaces_atomic+0x1a/0x20 [mac80211]
[<f9851427>] iwl_mvm_bt_coex_notif_handle+0x77/0x280 [iwlmvm]
[<f9852161>] iwl_mvm_rx_bt_coex_notif_old+0x211/0x220 [iwlmvm]
[<f9850b8b>] iwl_mvm_rx_bt_coex_notif+0x19b/0x1b0 [iwlmvm]
[<f983944f>] iwl_mvm_async_handlers_wk+0x7f/0xe0 [iwlmvm]
CC: <stable@vger.kernel.org> [3.19+]
Fixes: 123f515635b1 ("iwlwifi: mvm: BT Coex - add support for TTC / RRC")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The commit below didn't update the max_ht_ampdu_exponent
for the devices listed in iwl-[1-6]000.c which, in result,
became 0 instead of 8K. This reduced the size of the Rx
AMPDU from 64K to 8K which had an impact in the Rx
throughput. One user reported that because of this, his
downstream throughput droppped by a half.
CC: <stable@vger.kernel.org> [3.19]
Fixes: c064ddf318aa ("iwlwifi: change max HT and VHT A-MPDU exponent")
Reported-and-tested-by: Valentin Manea <linux-wireless@mrs.ro>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Current FW is declaring support for BFER in ucode_capa.capa
but it doesn't really support it unless the new LQ_SS_PARAMS API
is supported as well. Avoid publishing BFER in our VHT caps
if FW doesn't support.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
iwl_mvm_stop_roc removes TE only if running flag is set. This is not correct
since this flag is only set when the TE is started.
This resulted in a TE not being removed, when mac80211 believes that there are
no active ROCs.
Fixes: bf5da87f60a9 ("iwlwifi: mvm: add remove flow for AUX ROC time events")
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Reviewed-by: Matti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In certain conditions, mac80211 may ask us to stop a scan (scheduled
or normal) that is not running anymore. This can also happen when we
are doing a different type of scan, for instance, mac80211 can ask us
to stop a scheduled scan when we are running a normal scan, due to
some race conditions. In this case, we would stop the wrong type of
scan and leave everything everything in a wrong state.
To fix this, simply ignore scan stop requests for scans types that are
not running.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The check to avoid the shared antenna was passed the wrong
antenna parameter. It should have checked whether the antenna of
the next column we're considering is allowed and instead it was
passed the current antenna.
This could lead to a wrong choice of the next column in the rs
algorithm and non optimal performance.
Fixes: commit 219fb66b49fac64bb ("iwlwifi: mvm: rs - don't use the shared antenna when BT load is high")
CC: <stable@vger.kernel.org> [3.19]
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A scan abort command failure is not that unusual, since we may try to
send it after the scan has actually completed but before we received
the completed notification from the firmware. The scan abort can also
fail for other reasons, such as a timeout. In such cases, we should
clear things up so the next scans will work again. To do so, don't
return immediately in case of failures, but call
ieee80211_scan_completed() and clear the scan_status flags.
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The return value in iwl_mvm_get_wakeup_status() is a bit unclear in
that it's not obvious that we don't leak fw_status in some cases.
Use fw_status directly with ERR_PTR() and return only it, that way
the compiler has a chance of proving that it's uninitialized (if it
ever is due to new changes.)
Additionally, this removes a smatch warning since smatch couldn't
figure out that fw_status can't, in fact, leak here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When IWLWIFI_DEBUGFS is not set, we should not unlock the mutex after
calling iwl_mvm_query_wakeup_reasons(), because this function unlocks
it already. Move the goto out_iterate outside the #ifdef.
Change-Id: I13d86402aecf0eeec44b1abbe2b244fbc706a5eb
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The code here is a little confusing, the iwl_mvm_te_check_disconnect()
will check that the interface is a station, but going into it after
already having processed the time even end for P2P seems strange at
first look.
Put a switch statement there to distinguish the interface types and
make this more readable.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We previously enabled the smart FIFO (SF) in BSS only after
association.
This cause interrupt latency on P2P on certain devices.
Change the working model to enable the SF all the time and
play with the timeout values based on the association state.
This change was not tested on older firwmares, so make it
happen only on -13.ucode and up.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| | |
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
More sub system IDs were introduced for the 8260 series.
Add the new sub system IDs so the cards can be recognized.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The firmware was not using the new API, so we don't need to
differentiate between the different stages of this new API.
The main difference here is that most of the hard coded
values are not sent through the command anymore.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The newer devices will enable a new register for this
(DEVICE_SET_NMI_8000B_REG), but the interrupt handler
isn't wired yet.
Keep the old register for now.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a station goes to sleep, we can't transmit any frame
to it. This means that until that station will wake up, a
queue that is dedicated to this station won't progress at
all. Take this into account when monitoring stuck queues
and don't account for the time the station was asleep.
This allows to mask false positives where the queues are
stuck not because of a bug, but because of the station
being asleep.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows the op_mode to let the transport know that a
queue is currently frozen and that its timer should be
stopped.
When the queue is unfrozen, its timer should be set to
expire after the remainder of the timeout has elapsed.
This can be used when stations go to sleep. When a station
goes to sleep, the op_mode can freeze the timer so that the
queue will never be considered as stuck. When the station
wakes up, the queue will be unfrozen.
This is meant to avoid false positives that would happen if
a buggy station goes to sleep for a very long time. In case
we have a dedicated queue for this station (BA agreement)
and it goes to sleep for a very long time, the queue would
rightfully be stopped during all that time. In this case,
the stuck queue timer could fire and that would be a false
positive.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The Tx statistics weren't updated when using fixed rate for
debugging. Fix this as Tx statistics are useful in this use case.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
RTNL is not taken during CT-kill so regulatory APIs cannot be invoked.
That's fine, since the HW is only brought up to check the temperature
during CT-kill. We don't expect Tx or scanning.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
When using IBSS, it's easily possible to exhaust the number
of available stations in the driver, so don't warn on it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we load the firmware for the 8000 B step device, it'll
verify its signature. In the current version of the
hardware, there can be a race between the WiFi firmware
being loaded and the Bluetooth firmware being loaded.
Check that WiFi is authenticated, if not, take ownership
on the authentication machine to make sure that the WiFi
firmware will be authenticated.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
New sub system IDs were introduced for the 8260 series.
This patch adds them so new 8260 cards can be recognized.
Signed-off-by: Oren Givon <oren.givon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Make the print a bit more readable.
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the FW returns an invalid channels count in response to an MCC request,
make sure we don't reference invalid indices in the channels array.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When entering D0i3, the MVM mutex cannot be grabbed. This interferes
with the calculation of the number of connected TDLS stations during
the setup of the power cmd.
The goal is to disable power saving for all vifs while any TDLS station
is connected. For this purpose it is enough to keep the pm_enabled
member of all mvmvifs as false. An update of the power state already
occurs when a TDLS station is added/removed, so the values are correctly
updated.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
mvm->fw->dbg_dest_tlv really needs to be under the right
parenthesis.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
The functions related to firmware error dump moved. No need
for this unclude anymore.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
New NVM versions in LnP platforms have the lar_enable bits in a different
offset.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| | |
While at it, fix a few checkpatch issues.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| | |
This adds BT Coex data to the prph register list.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We don't need to acquire MAC access for each access, it
makes much more sense to keep the MAC access. This speeds
up the Tx DMA stop flow significantly.
Moreover, if one channel can't be stopped, stop the others
but don't poll for them to avoid being stuck there for a
long time.
This solves a situation in which we were stuck in that flow
for way too long with a spinlock held which led to a kernel
panic.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In-order to recognize newer step of the device, the driver
must read the chip_version_id from the AUX bus MISC address
space. This will determine what firmware file will be
loaded.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we associate we always need to update the quotas. This
fixes a bug for cases in which quotas weren't udapted after
association.
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
Enable this feature only if the firmware advertises support
for it.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| | |
All the supported firmwares support this API.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| | |
All the supported firwmares have this new API.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| | |
This new firmware will come out soon.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When moving to the D3 FW give it the valid MCC from the D0 FW. When
returning from D3 to D0, query the D3 FW for the latest MCC, as
it might have changed internally. This MCC will be replayed to the D0 FW
when it boots.
Signed-off-by: Jonathan Doron <jonathanx.doron@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When booting the card, check for a dedicated regulatory ACPI entry. If
such exists, read it and give the information to FW with the appropriate
source.
Signed-off-by: Jonathan Doron <jonathanx.doron@intel.com>
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For some configurations, the driver should get the MAC
address from the hardware registers and not from the
regular locations. Since the parsing of the MAC address
is the same regardless of its source, continue the regular
code path (parsing) after we read the registers.
Signed-off-by: Eran Harary <eran.harary@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|
| |
| |
| |
| |
| |
| |
| | |
This module parameter is useful for debugging NVM and LAR related issues.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
|