mirror of
https://github.com/suyu-emu/horinux.git
synced 2026-09-21 14:15:21 -07:00
Merge branches 'sh/urgent' and 'sh/platform-updates' into sh-latest
This commit is contained in:
Paul Mundt
@@ -50,7 +50,9 @@
|
||||
|
||||
<sect1><title>Delaying, scheduling, and timer routines</title>
|
||||
!Iinclude/linux/sched.h
|
||||
!Ekernel/sched.c
|
||||
!Ekernel/sched/core.c
|
||||
!Ikernel/sched/cpupri.c
|
||||
!Ikernel/sched/fair.c
|
||||
!Iinclude/linux/completion.h
|
||||
!Ekernel/timer.c
|
||||
</sect1>
|
||||
@@ -216,7 +218,6 @@ X!Isound/sound_firmware.c
|
||||
|
||||
<chapter id="uart16x50">
|
||||
<title>16x50 UART Driver</title>
|
||||
!Iinclude/linux/serial_core.h
|
||||
!Edrivers/tty/serial/serial_core.c
|
||||
!Edrivers/tty/serial/8250.c
|
||||
</chapter>
|
||||
|
||||
@@ -317,7 +317,7 @@ CPU B: spin_unlock_irqrestore(&dev_lock, flags)
|
||||
<chapter id="pubfunctions">
|
||||
<title>Public Functions Provided</title>
|
||||
!Iarch/x86/include/asm/io.h
|
||||
!Elib/iomap.c
|
||||
!Elib/pci_iomap.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
||||
@@ -163,14 +163,16 @@ get/set up to 64 properties. The actual meaning of each property is described on
|
||||
<section id="DTV-FREQUENCY">
|
||||
<title><constant>DTV_FREQUENCY</constant></title>
|
||||
|
||||
<para>Central frequency of the channel, in HZ.</para>
|
||||
<para>Central frequency of the channel.</para>
|
||||
|
||||
<para>Notes:</para>
|
||||
<para>1)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
|
||||
<para>1)For satellital delivery systems, it is measured in kHz.
|
||||
For the other ones, it is measured in Hz.</para>
|
||||
<para>2)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
|
||||
E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
|
||||
the channel which is 6MHz.</para>
|
||||
|
||||
<para>2)As in ISDB-Tsb the channel consists of only one or three segments the
|
||||
<para>3)As in ISDB-Tsb the channel consists of only one or three segments the
|
||||
frequency step is 429kHz, 3*429 respectively. As for ISDB-T the
|
||||
central frequency of the channel is expected.</para>
|
||||
</section>
|
||||
@@ -735,14 +737,10 @@ typedef enum fe_hierarchy {
|
||||
<listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-CODE-RATE-HP"><constant>DTV_CODE_RATE_HP</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-CODE-RATE-LP"><constant>DTV_CODE_RATE_LP</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBT-LAYER-ENABLED"><constant>DTV_ISDBT_LAYER_ENABLED</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBT-PARTIAL-RECEPTION"><constant>DTV_ISDBT_PARTIAL_RECEPTION</constant></link></para></listitem>
|
||||
<listitem><para><link linkend="DTV-ISDBT-SOUND-BROADCASTING"><constant>DTV_ISDBT_SOUND_BROADCASTING</constant></link></para></listitem>
|
||||
|
||||
@@ -183,7 +183,12 @@ applications must set the array to zero.</entry>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>ctrl_class</structfield></entry>
|
||||
<entry>The control class to which all controls belong, see
|
||||
<xref linkend="ctrl-class" />.</entry>
|
||||
<xref linkend="ctrl-class" />. Drivers that use a kernel framework for handling
|
||||
controls will also accept a value of 0 here, meaning that the controls can
|
||||
belong to any control class. Whether drivers support this can be tested by setting
|
||||
<structfield>ctrl_class</structfield> to 0 and calling <constant>VIDIOC_TRY_EXT_CTRLS</constant>
|
||||
with a <structfield>count</structfield> of 0. If that succeeds, then the driver
|
||||
supports this feature.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
@@ -194,10 +199,13 @@ also be zero.</entry>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>error_idx</structfield></entry>
|
||||
<entry>Set by the driver in case of an error. It is the
|
||||
index of the control causing the error or equal to 'count' when the
|
||||
error is not associated with a particular control. Undefined when the
|
||||
ioctl returns 0 (success).</entry>
|
||||
<entry>Set by the driver in case of an error. If it is equal
|
||||
to <structfield>count</structfield>, then no actual changes were made to
|
||||
controls. In other words, the error was not associated with setting a particular
|
||||
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
|
||||
were modified and control <structfield>error_idx</structfield> is the one that
|
||||
caused the error. The <structfield>error_idx</structfield> value is undefined
|
||||
if the ioctl returned 0 (success).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
||||
@@ -364,15 +364,20 @@ capability and it is cleared otherwise.</entry>
|
||||
<row>
|
||||
<entry><constant>V4L2_FBUF_FLAG_OVERLAY</constant></entry>
|
||||
<entry>0x0002</entry>
|
||||
<entry>The frame buffer is an overlay surface the same
|
||||
size as the capture. [?]</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry spanname="hspan">The purpose of
|
||||
<constant>V4L2_FBUF_FLAG_OVERLAY</constant> was never quite clear.
|
||||
Most drivers seem to ignore this flag. For compatibility with the
|
||||
<wordasword>bttv</wordasword> driver applications should set the
|
||||
<constant>V4L2_FBUF_FLAG_OVERLAY</constant> flag.</entry>
|
||||
<entry>If this flag is set for a video capture device, then the
|
||||
driver will set the initial overlay size to cover the full framebuffer size,
|
||||
otherwise the existing overlay size (as set by &VIDIOC-S-FMT;) will be used.
|
||||
|
||||
Only one video capture driver (bttv) supports this flag. The use of this flag
|
||||
for capture devices is deprecated. There is no way to detect which drivers
|
||||
support this flag, so the only reliable method of setting the overlay size is
|
||||
through &VIDIOC-S-FMT;.
|
||||
|
||||
If this flag is set for a video output device, then the video output overlay
|
||||
window is relative to the top-left corner of the framebuffer and restricted
|
||||
to the size of the framebuffer. If it is cleared, then the video output
|
||||
overlay window is relative to the video output display.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_FBUF_FLAG_CHROMAKEY</constant></entry>
|
||||
|
||||
@@ -98,8 +98,11 @@ the &v4l2-output; <structfield>modulator</structfield> field and the
|
||||
<entry>&v4l2-tuner-type;</entry>
|
||||
<entry><structfield>type</structfield></entry>
|
||||
<entry>The tuner type. This is the same value as in the
|
||||
&v4l2-tuner; <structfield>type</structfield> field. The field is not
|
||||
applicable to modulators, &ie; ignored by drivers.</entry>
|
||||
&v4l2-tuner; <structfield>type</structfield> field. The type must be set
|
||||
to <constant>V4L2_TUNER_RADIO</constant> for <filename>/dev/radioX</filename>
|
||||
device nodes, and to <constant>V4L2_TUNER_ANALOG_TV</constant>
|
||||
for all others. The field is not applicable to modulators, &ie; ignored
|
||||
by drivers.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
|
||||
@@ -61,8 +61,8 @@ desired input in an integer and call the
|
||||
<constant>VIDIOC_S_INPUT</constant> ioctl with a pointer to this
|
||||
integer. Side effects are possible. For example inputs may support
|
||||
different video standards, so the driver may implicitly switch the
|
||||
current standard. It is good practice to select an input before
|
||||
querying or negotiating any other parameters.</para>
|
||||
current standard. Because of these possible side effects applications
|
||||
must select an input before querying or negotiating any other parameters.</para>
|
||||
|
||||
<para>Information about video inputs is available using the
|
||||
&VIDIOC-ENUMINPUT; ioctl.</para>
|
||||
|
||||
@@ -61,8 +61,9 @@ desired output in an integer and call the
|
||||
<constant>VIDIOC_S_OUTPUT</constant> ioctl with a pointer to this integer.
|
||||
Side effects are possible. For example outputs may support different
|
||||
video standards, so the driver may implicitly switch the current
|
||||
standard. It is good practice to select an output before querying or
|
||||
negotiating any other parameters.</para>
|
||||
standard.
|
||||
standard. Because of these possible side effects applications
|
||||
must select an output before querying or negotiating any other parameters.</para>
|
||||
|
||||
<para>Information about video outputs is available using the
|
||||
&VIDIOC-ENUMOUTPUT; ioctl.</para>
|
||||
|
||||
@@ -47,20 +47,53 @@ directory apei/einj. The following files are provided.
|
||||
|
||||
- param1
|
||||
This file is used to set the first error parameter value. Effect of
|
||||
parameter depends on error_type specified. For memory error, this is
|
||||
physical memory address. Only available if param_extension module
|
||||
parameter is specified.
|
||||
parameter depends on error_type specified.
|
||||
|
||||
- param2
|
||||
This file is used to set the second error parameter value. Effect of
|
||||
parameter depends on error_type specified. For memory error, this is
|
||||
physical memory address mask. Only available if param_extension
|
||||
module parameter is specified.
|
||||
parameter depends on error_type specified.
|
||||
|
||||
BIOS versions based in the ACPI 4.0 specification have limited options
|
||||
to control where the errors are injected. Your BIOS may support an
|
||||
extension (enabled with the param_extension=1 module parameter, or
|
||||
boot command line einj.param_extension=1). This allows the address
|
||||
and mask for memory injections to be specified by the param1 and
|
||||
param2 files in apei/einj.
|
||||
|
||||
BIOS versions using the ACPI 5.0 specification have more control over
|
||||
the target of the injection. For processor related errors (type 0x1,
|
||||
0x2 and 0x4) the APICID of the target should be provided using the
|
||||
param1 file in apei/einj. For memory errors (type 0x8, 0x10 and 0x20)
|
||||
the address is set using param1 with a mask in param2 (0x0 is equivalent
|
||||
to all ones). For PCI express errors (type 0x40, 0x80 and 0x100) the
|
||||
segment, bus, device and function are specified using param1:
|
||||
|
||||
31 24 23 16 15 11 10 8 7 0
|
||||
+-------------------------------------------------+
|
||||
| segment | bus | device | function | reserved |
|
||||
+-------------------------------------------------+
|
||||
|
||||
An ACPI 5.0 BIOS may also allow vendor specific errors to be injected.
|
||||
In this case a file named vendor will contain identifying information
|
||||
from the BIOS that hopefully will allow an application wishing to use
|
||||
the vendor specific extension to tell that they are running on a BIOS
|
||||
that supports it. All vendor extensions have the 0x80000000 bit set in
|
||||
error_type. A file vendor_flags controls the interpretation of param1
|
||||
and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor
|
||||
documentation for details (and expect changes to this API if vendors
|
||||
creativity in using this feature expands beyond our expectations).
|
||||
|
||||
Example:
|
||||
# cd /sys/kernel/debug/apei/einj
|
||||
# cat available_error_type # See which errors can be injected
|
||||
0x00000002 Processor Uncorrectable non-fatal
|
||||
0x00000008 Memory Correctable
|
||||
0x00000010 Memory Uncorrectable non-fatal
|
||||
# echo 0x12345000 > param1 # Set memory address for injection
|
||||
# echo 0xfffffffffffff000 > param2 # Mask - anywhere in this page
|
||||
# echo 0x8 > error_type # Choose correctable memory error
|
||||
# echo 1 > error_inject # Inject now
|
||||
|
||||
Injecting parameter support is a BIOS version specific extension, that
|
||||
is, it only works on some BIOS version. If you want to use it, please
|
||||
make sure your BIOS version has the proper support and specify
|
||||
"param_extension=y" in module parameter.
|
||||
|
||||
For more information about EINJ, please refer to ACPI specification
|
||||
version 4.0, section 17.5.
|
||||
version 4.0, section 17.5 and ACPI 5.0, section 18.6.
|
||||
|
||||
@@ -447,6 +447,9 @@ Your cooperation is appreciated.
|
||||
234 = /dev/btrfs-control Btrfs control device
|
||||
235 = /dev/autofs Autofs control device
|
||||
236 = /dev/mapper/control Device-Mapper control device
|
||||
237 = /dev/loop-control Loopback control device
|
||||
238 = /dev/vhost-net Host kernel accelerator for virtio net
|
||||
|
||||
240-254 Reserved for local use
|
||||
255 Reserved for MISC_DYNAMIC_MINOR
|
||||
|
||||
|
||||
@@ -0,0 +1,14 @@
|
||||
* Atmel Direct Memory Access Controller (DMA)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,<chip>-dma"
|
||||
- reg: Should contain DMA registers location and length
|
||||
- interrupts: Should contain DMA interrupt
|
||||
|
||||
Examples:
|
||||
|
||||
dma@ffffec00 {
|
||||
compatible = "atmel,at91sam9g45-dma";
|
||||
reg = <0xffffec00 0x200>;
|
||||
interrupts = <21>;
|
||||
};
|
||||
@@ -0,0 +1,30 @@
|
||||
I2C for OMAP platforms
|
||||
|
||||
Required properties :
|
||||
- compatible : Must be "ti,omap3-i2c" or "ti,omap4-i2c"
|
||||
- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based)
|
||||
- #address-cells = <1>;
|
||||
- #size-cells = <0>;
|
||||
|
||||
Recommended properties :
|
||||
- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise
|
||||
the default 100 kHz frequency will be used.
|
||||
|
||||
Optional properties:
|
||||
- Child nodes conforming to i2c bus binding
|
||||
|
||||
Note: Current implementation will fetch base address, irq and dma
|
||||
from omap hwmod data base during device registration.
|
||||
Future plan is to migrate hwmod data base contents into device tree
|
||||
blob so that, all the required data will be used from device tree dts
|
||||
file.
|
||||
|
||||
Examples :
|
||||
|
||||
i2c1: i2c@0 {
|
||||
compatible = "ti,omap3-i2c";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
ti,hwmods = "i2c1";
|
||||
clock-frequency = <400000>;
|
||||
};
|
||||
@@ -75,6 +75,10 @@ The slave DMA usage consists of following steps:
|
||||
slave_sg - DMA a list of scatter gather buffers from/to a peripheral
|
||||
dma_cyclic - Perform a cyclic DMA operation from/to a peripheral till the
|
||||
operation is explicitly stopped.
|
||||
interleaved_dma - This is common to Slave as well as M2M clients. For slave
|
||||
address of devices' fifo could be already known to the driver.
|
||||
Various types of operations could be expressed by setting
|
||||
appropriate values to the 'dma_interleaved_template' members.
|
||||
|
||||
A non-NULL return of this transfer API represents a "descriptor" for
|
||||
the given transaction.
|
||||
@@ -89,6 +93,10 @@ The slave DMA usage consists of following steps:
|
||||
struct dma_chan *chan, dma_addr_t buf_addr, size_t buf_len,
|
||||
size_t period_len, enum dma_data_direction direction);
|
||||
|
||||
struct dma_async_tx_descriptor *(*device_prep_interleaved_dma)(
|
||||
struct dma_chan *chan, struct dma_interleaved_template *xt,
|
||||
unsigned long flags);
|
||||
|
||||
The peripheral driver is expected to have mapped the scatterlist for
|
||||
the DMA operation prior to calling device_prep_slave_sg, and must
|
||||
keep the scatterlist mapped until the DMA operation has completed.
|
||||
|
||||
@@ -439,17 +439,6 @@ Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: For VIDIOC_S_FREQUENCY the type field must match the device node's type.
|
||||
If not, return -EINVAL.
|
||||
When: 3.2
|
||||
Why: It makes no sense to switch the tuner to radio mode by calling
|
||||
VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by
|
||||
calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a
|
||||
move to more consistent handling of tv and radio tuners.
|
||||
Who: Hans Verkuil <hans.verkuil@cisco.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Opening a radio device node will no longer automatically switch the
|
||||
tuner mode from tv to radio.
|
||||
When: 3.3
|
||||
|
||||
@@ -149,6 +149,7 @@ Code Seq#(hex) Include File Comments
|
||||
'M' 01-03 drivers/scsi/megaraid/megaraid_sas.h
|
||||
'M' 00-0F drivers/video/fsl-diu-fb.h conflict!
|
||||
'N' 00-1F drivers/usb/scanner.h
|
||||
'N' 40-7F drivers/block/nvme.c
|
||||
'O' 00-06 mtd/ubi-user.h UBI
|
||||
'P' all linux/soundcard.h conflict!
|
||||
'P' 60-6F sound/sscape_ioctl.h conflict!
|
||||
|
||||
@@ -1059,6 +1059,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
By default, super page will be supported if Intel IOMMU
|
||||
has the capability. With this option, super page will
|
||||
not be supported.
|
||||
|
||||
intel_idle.max_cstate= [KNL,HW,ACPI,X86]
|
||||
0 disables intel_idle and fall back on acpi_idle.
|
||||
1 to 6 specify maximum depth of C-state.
|
||||
|
||||
intremap= [X86-64, Intel-IOMMU]
|
||||
on enable Interrupt Remapping (default)
|
||||
off disable Interrupt Remapping
|
||||
|
||||
@@ -15,7 +15,7 @@ test at least a couple of times in a row for confidence. [This is necessary,
|
||||
because some problems only show up on a second attempt at suspending and
|
||||
resuming the system.] Moreover, hibernating in the "reboot" and "shutdown"
|
||||
modes causes the PM core to skip some platform-related callbacks which on ACPI
|
||||
systems might be necessary to make hibernation work. Thus, if you machine fails
|
||||
systems might be necessary to make hibernation work. Thus, if your machine fails
|
||||
to hibernate or resume in the "reboot" mode, you should try the "platform" mode:
|
||||
|
||||
# echo platform > /sys/power/disk
|
||||
|
||||
@@ -120,10 +120,10 @@ So in practice, the 'at all' may become a 'why freeze kernel threads?' and
|
||||
freezing user threads I don't find really objectionable."
|
||||
|
||||
Still, there are kernel threads that may want to be freezable. For example, if
|
||||
a kernel that belongs to a device driver accesses the device directly, it in
|
||||
principle needs to know when the device is suspended, so that it doesn't try to
|
||||
access it at that time. However, if the kernel thread is freezable, it will be
|
||||
frozen before the driver's .suspend() callback is executed and it will be
|
||||
a kernel thread that belongs to a device driver accesses the device directly, it
|
||||
in principle needs to know when the device is suspended, so that it doesn't try
|
||||
to access it at that time. However, if the kernel thread is freezable, it will
|
||||
be frozen before the driver's .suspend() callback is executed and it will be
|
||||
thawed after the driver's .resume() callback has run, so it won't be accessing
|
||||
the device while it's suspended.
|
||||
|
||||
|
||||
@@ -1,3 +1,13 @@
|
||||
Release Date : Fri. Jan 6, 2012 17:00:00 PST 2010 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Adam Radford
|
||||
Current Version : 00.00.06.14-rc1
|
||||
Old Version : 00.00.06.12-rc1
|
||||
1. Fix reglockFlags for degraded raid5/6 for MR 9360/9380.
|
||||
2. Mask off flags in ioctl path to prevent memory scribble with older
|
||||
MegaCLI versions.
|
||||
3. Remove poll_mode_io module paramater, sysfs node, and associated code.
|
||||
-------------------------------------------------------------------------------
|
||||
Release Date : Wed. Oct 5, 2011 17:00:00 PST 2010 -
|
||||
(emaild-id:megaraidlinux@lsi.com)
|
||||
Adam Radford
|
||||
|
||||
@@ -1,32 +1,11 @@
|
||||
Copyright (c) 2003-2011 QLogic Corporation
|
||||
QLogic Linux iSCSI HBA Driver
|
||||
QLogic Linux iSCSI Driver
|
||||
|
||||
This program includes a device driver for Linux 3.x.
|
||||
You may modify and redistribute the device driver code under the
|
||||
GNU General Public License (a copy of which is attached hereto as
|
||||
Exhibit A) published by the Free Software Foundation (version 2).
|
||||
|
||||
REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
|
||||
THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
|
||||
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
|
||||
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
|
||||
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
||||
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
|
||||
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
|
||||
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
||||
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
|
||||
CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
|
||||
OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
|
||||
TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
|
||||
ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
|
||||
COMBINATION WITH THIS PROGRAM.
|
||||
|
||||
|
||||
EXHIBIT A
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user