| /openbmc/openbmc/meta-openembedded/meta-networking/recipes-connectivity/restinio/ |
| H A D | restinio_0.6.13.bb | 1 SUMMARY = "Header-only C++14 library that gives you an embedded HTTP server"
2 DESCRIPTION = "Cross-platform, efficient, customizable, and robust \
4 right balance between performance and ease of use"
7 LICENSE = "BSD-3-Clause"
9 DEPENDS = "asio fmt http-parser"
20 -DRESTINIO_TEST=OFF \
21 -DRESTINIO_SAMPLE=OFF \
22 -DRESTINIO_BENCH=OFF \
23 -DRESTINIO_FIND_DEPS=ON \
24 -DRESTINIO_ALLOW_SOBJECTIZER=OFF \
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/regulator/ |
| H A D | renesas,raa215300.yaml | 1 # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Biju Das <biju.das.jz@bp.renesas.com>
13 The RAA215300 is a high-performance, low-cost 9-channel PMIC designed for
14 32-bit and 64-bit MCU and MPU applications. It supports DDR3, DDR3L, DDR4,
16 built-in Real-Time Clock (RTC), 32kHz crystal oscillator, and coin cell
18 ideal for System-On-Module (SOM) applications. A spread spectrum feature
19 provides an ease-of-use solution for noise-sensitive audio or RF applications.
25 …-power-management/multi-channel-power-management-ics-pmics/ssdsoc-power-management-ics-pmic-and-pm…
[all …]
|
| /openbmc/openbmc/poky/meta/recipes-devtools/vala/ |
| H A D | vala_0.56.17.bb | 1 SUMMARY = "C#-like programming language for easing GObject programming"
2 HOMEPAGE = "http://vala-project.org"
3 DESCRIPTION = "Vala is a C#-like language dedicated to ease GObject programming. \
6 DEPENDS = "bison-native flex-native glib-2.0 gobject-introspection"
8 # Appending libxslt-native to dependencies has an effect
9 # of rebuilding the manual, which is very slow. Let's do this
10 # only when api-documentation distro feature is enabled.
11 DEPENDS:append:class-target = " ${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation', 'libxs…
13 # vala-native contains a native version of vapigen, which we use instead of the target one
14 DEPENDS:append:class-target = " vala-native"
[all …]
|
| /openbmc/linux/drivers/scsi/isci/ |
| H A D | remote_node_table.h | 7 * Copyright(c) 2008 - 2011 Intel Corporation. All rights reserved.
10 * it under the terms of version 2 of the GNU General Public License as
14 * WITHOUT ANY WARRANTY; without even the implied warranty of
18 * You should have received a copy of the GNU General Public License
20 * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
26 * Copyright(c) 2008 - 2011 Intel Corporation. All rights reserved.
29 * Redistribution and use in source and binary forms, with or without
33 * * Redistributions of source code must retain the above copyright
34 * notice, this list of conditions and the following disclaimer.
36 * notice, this list of conditions and the following disclaimer in
[all …]
|
| /openbmc/linux/Documentation/devicetree/bindings/pinctrl/ |
| H A D | renesas,rza1-ports.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/pinctrl/renesas,rza1-ports.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Jacopo Mondi <jacopo+renesas@jmondi.org>
11 - Geert Uytterhoeven <geert+renesas@glider.be>
14 The Renesas SoCs of the RZ/A1 family feature a combined Pin and GPIO
16 Pin multiplexing and GPIO configuration is performed on a per-pin basis
17 writing configuration values to per-port register sets.
18 Each "port" features up to 16 pins, each of them configurable for GPIO
[all …]
|
| /openbmc/linux/Documentation/driver-api/fpga/ |
| H A D | fpga-mgr.rst | 5 --------
7 The FPGA manager core exports a set of functions for programming an FPGA with
9 hidden away in a low level driver which registers a set of ops with the core.
15 memory for the buffer should be avoided, users are encouraged to use a scatter
20 FPGA image as well as image-specific particulars such as whether the image was
24 --------------------------------
26 To add another FPGA manager, write a driver that implements a set of ops. The
39 struct device *dev = &pdev->dev;
46 return -ENOMEM;
72 Alternatively, the probe function could call one of the resource managed
[all …]
|
| /openbmc/openbmc/poky/documentation/test-manual/ |
| H A D | test-process.rst | 1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
11 on the Autobuilder or with the assistance of QA teams, through to making
16 up in batches either in the ``master-next`` branch in the main trees, or
17 in user trees such as ``ross/mut`` in ``poky-contrib`` (Ross Burton
20 We have two broad categories of test builds, including "full" and
21 "quick". On the Autobuilder, these can be seen as "a-quick" and
22 "a-full", simply for ease of sorting in the UI. Use our Autobuilder
24 test-related items.
32 of quick or full would depend on the type of changes and the speed with
37 build, but also to keep (:yocto_git:`yocto-testresults </yocto-testresults/>`),
[all …]
|
| /openbmc/u-boot/include/configs/ |
| H A D | ti_armv7_common.h | 1 /* SPDX-License-Identifier: GPL-2.0+ */
5 * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
7 * The various ARMv7 SoCs from TI all share a number of IP blocks when
9 * board or even SoC common file, we define a common file to be re-used
10 * in all cases. While technically true that some of these details are
25 * Our DDR memory always starts at 0x80000000 and U-Boot shall have
35 * the kernel), FDT above 128MB (the maximum location for the end of the
37 * seen large trees). We say all of this must be within the first 256MB
39 * bootm_size and we only run on platforms with 256MB or more of memory.
70 #define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \
[all …]
|
| H A D | brppt1.h | 1 /* SPDX-License-Identifier: GPL-2.0+ */
5 * specific parts for B&R T-Series Motherboard
7 * Copyright (C) 2013 Hannes Schmelzer <oe5hpm@oevsv.at> -
8 * Bernecker & Rainer Industrieelektronik GmbH - http://www.br-automation.com
16 /* ------------------------------------------------------------------------- */
40 * When we have NAND flash we expect to be making use of mtdparts,
41 * both for ease of use in U-Boot and for passing information on to
78 "run nandargs; run cfgscr; bootz ${loadaddr} - ${dtbaddr}\0" \
92 "load ${loaddev}:2 ${dtbaddr} /boot/am335x-ppt30.dtb || " \
93 "load ${loaddev}:1 ${dtbaddr} am335x-ppt30-legacy.dtb; "\
[all …]
|
| /openbmc/linux/Documentation/bpf/ |
| H A D | map_array.rst | 1 .. SPDX-License-Identifier: GPL-2.0-only
9 - ``BPF_MAP_TYPE_ARRAY`` was introduced in kernel version 3.19
10 - ``BPF_MAP_TYPE_PERCPU_ARRAY`` was introduced in version 4.6
13 storage. The key type is an unsigned 32-bit integer (4 bytes) and the map is
14 of constant size. The size of the array is defined in ``max_entries`` at
15 creation time. All array elements are pre-allocated and zero initialized when
18 stored can be of any size, however, all array elements are aligned to 8
22 setting the flag ``BPF_F_MMAPABLE``. The map definition is page-aligned and
23 starts on the first page. Sufficient page-sized and page-aligned blocks of
25 which in some cases will result in over-allocation of memory. The benefit of
[all …]
|
| H A D | ringbuf.rst | 12 ----------
15 existing perf buffer, which prompted creation of a new ring buffer
18 - more efficient memory utilization by sharing ring buffer across CPUs;
19 - preserving ordering of events that happen sequentially in time, even across
23 Both are a result of a choice to have per-CPU perf ring buffer. Both can be
24 also solved by having an MPSC implementation of ring buffer. The ordering
25 problem could technically be solved for perf buffer with some in-kernel
30 ------------------
32 Single ring buffer is presented to BPF programs as an instance of BPF map of
37 ``BPF_MAP_TYPE_RINGBUF`` could represent an array of ring buffers, but not
[all …]
|
| /openbmc/linux/Documentation/networking/devlink/ |
| H A D | devlink-info.rst | 1 .. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
7 The ``devlink-info`` mechanism enables device drivers to report device
10 The original motivation for the ``devlink-info`` API was twofold:
12 - making it possible to automate device and firmware management in a fleet
13 of machines in a vendor-independent fashion (see also
14 :ref:`Documentation/networking/devlink/devlink-flash.rst <devlink_flash>`);
15 - name the per component FW versions (as opposed to the crowded ethtool
18 ``devlink-info`` supports reporting multiple types of objects. Reporting driver
19 versions is generally discouraged - here, and via any other Linux API.
21 .. list-table:: List of top level info objects
[all …]
|
| /openbmc/qemu/docs/devel/ |
| H A D | clocks.rst | 5 ----------------
7 Clocks are QOM objects developed for the purpose of modelling the
8 distribution of clocks in QEMU.
10 They allow us to model the clock distribution of a platform and detect
19 of different devices can be connected together.
21 In these cases a Clock object is a child of a Device object, but this
22 is not a requirement. Clocks can be independent of devices. For
23 example it is possible to create a clock outside of any device to
24 model the main clock source of a machine.
26 Here is an example of clocks::
[all …]
|
| /openbmc/linux/samples/bpf/ |
| H A D | xdp2skb_meta.sh | 3 # SPDX-License-Identifier: GPL-2.0
6 # Bash-shell example on using iproute2 tools 'tc' and 'ip' to load
8 # wrappers and even long options parsing is illustrated, for ease of
9 # use.
11 # Related to sample/bpf/xdp2skb_meta_kern.c, which contains BPF-progs
19 [ -z "$TC" ] && TC=tc
20 [ -z "$IP" ] && IP=ip
24 echo "Usage: $0 [-vfh] --dev ethX"
25 echo " -d | --dev : Network device (required)"
26 echo " --flush : Cleanup flush TC and XDP progs"
[all …]
|
| /openbmc/qemu/include/exec/ |
| H A D | memop.h | 7 * This work is licensed under the terms of the GNU GPL, version 2 or later.
8 * See the COPYING file in the top-level directory.
15 #include "qemu/host-utils.h"
28 MO_SIGN = 0x08, /* Sign-extended, otherwise zero-extended. */
52 * to a size more than the size of the memory access.
56 * MO_ALIGN supposes the alignment size is the size of a memory access.
59 * - unaligned access permitted (MO_UNALN).
60 * - an alignment to the size of an access (MO_ALIGN);
61 * - an alignment to a specified size, which may be more or less than
76 * MO_ATOM_* describes the atomicity requirements of the operation:
[all …]
|
| /openbmc/linux/Documentation/gpu/ |
| H A D | introduction.rst | 5 The Linux DRM layer contains code intended to support the needs of
8 make use of DRM functions to make tasks like memory management,
17 [Insert diagram of typical DRM stack here]
23 are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so
24 on. To aid in reading, documentations make full use of the markup
29 entries in function vtables (and structure members in general) please use
37 documentation than runtime noise this provides more value. And on top of
44 Functions which have a non-\ ``void`` return value should have a section
47 section name should be all upper-case or not, and whether it should end
48 in a colon or not. Go with the file-local style. Other common section
[all …]
|
| /openbmc/openbmc/meta-security/classes/ |
| H A D | dm-verity-img.bbclass | 1 # SPDX-License-Identifier: MIT
6 # This bbclass allows creating of dm-verity protected partition images. It
7 # generates a device image file with dm-verity hash data appended at the end
9 # to mount the image such as the root hash in the form of ell variables. To
14 # for improved compartmentalization and ease of use/deployment.
17 # DM_VERITY_IMAGE = "core-image-full-cmdline" # or other image
20 # IMAGE_CLASSES += "dm-verity-img"
25 # DM_VERITY_ROOT_GUID = <UUID for your architecture and root-fs>
26 # DM_VERITY_RHASH_GUID = <UUID for your architecture and verity-hash>
27 # https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
[all …]
|
| /openbmc/linux/drivers/gpu/drm/amd/amdgpu/ |
| H A D | amdgpu_fru_eeprom.c | 4 * Permission is hereby granted, free of charge, to any person obtaining a
5 * copy of this software and associated documentation files (the "Software"),
7 * the rights to use, copy, modify, merge, publish, distribute, sublicense,
8 * and/or sell copies of the Software, and to permit persons to whom the
12 * all copies or substantial portions of the Software.
14 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
15 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
18 * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
19 * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
38 * TODO: See if we can figure this out dynamically instead of in is_fru_eeprom_supported()
[all …]
|
| /openbmc/openbmc/meta-arm/meta-arm-systemready/classes/ |
| H A D | arm-systemready-acs.bbclass | 1 # This class contains the common logic to deploy the SystemReady ACS pre-built
8 # * Create a symlink to the acs_results in ${TMPDIR}/log/oeqa for ease of
13 COMPATIBLE_HOST = "aarch64-*"
15 inherit nopackages deploy rootfs-postcommands ${IMAGE_CLASSES} python3native testimage
24 # Post-process commands may write to IMGDEPLOYDIR
43 # Run the image post-process commands
49 # The machine-specific implementation can optionally put the report file in
50 # ${UNPACKDIR}/report.txt. If there is no such file present, use the template.
57 report_file_to_copy = os.path.join(unpackdir, "systemready-ir-template",
71 do_image_complete[depends] += "arm-systemready-firmware:do_image_complete"
[all …]
|
| /openbmc/linux/Documentation/core-api/irq/ |
| H A D | irq-domain.rst | 5 The current design of the Linux kernel uses a single large number
9 that each one gets assigned non-overlapping allocations of Linux
12 The number of interrupt controllers registered as unique irqchips
13 show a rising tendency: for example subdrivers of different kinds
18 Here the interrupt number loose all kind of correspondence to
24 For this reason we need a mechanism to separate controller-local
27 The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
28 irq numbers, but they don't provide any support for reverse mapping of
29 the controller-local IRQ (hwirq) number into the Linux IRQ number
33 top of the irq_alloc_desc*() API. An irq_domain to manage mapping is
[all …]
|
| /openbmc/qemu/docs/specs/ |
| H A D | vmgenid.rst | 8 This work is licensed under the terms of the GNU GPL, version 2 or later.
9 See the COPYING file in the top-level directory.
12 exposes a 128-bit, cryptographically random, integer value identifier,
19 appropriate by marking its copies of distributed databases as dirty,
20 re-initializing its random number generator etc.
24 ------------
27 generation ID support in a virtualization platform" section of
31 - **R1a** The generation ID shall live in an 8-byte aligned buffer.
33 - **R1b** The buffer holding the generation ID shall be in guest RAM,
36 - **R1c** The buffer holding the generation ID shall be kept separate from
[all …]
|
| /openbmc/linux/Documentation/filesystems/ |
| H A D | xfs-maintainer-entry-profile.rst | 5 --------
6 XFS is a well known high-performance filesystem in the Linux kernel.
7 The aim of this project is to provide and maintain a robust and
10 Patches are generally merged to the for-next branch of the appropriate
12 After a testing period, the for-next branch is merged to the master
15 Kernel code are merged to the xfs-linux tree[0].
18 Ondisk format documentation are merged to the xfs-documentation tree[3].
21 list linux-xfs@vger.kernel.org.
24 -----
31 - **Outside Contributor**: Anyone who sends a patch but is not involved
[all …]
|
| /openbmc/linux/drivers/cpufreq/ |
| H A D | maple-cpufreq.c | 1 // SPDX-License-Identifier: GPL-2.0-only
3 * Copyright (C) 2011 Dmitry Eremin-Solenikov
4 * Copyright (C) 2002 - 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org>
5 * and Markus Demleitner <msdemlei@cl.uni-heidelberg.de>
26 #include <linux/of.h>
66 /* Power mode data is an array of the 32 bits PCR values to use for
67 * the various frequencies, retrieved from the device-tree
164 int rc = -ENODEV; in maple_cpufreq_init()
168 * to ease merging of two drivers in future. in maple_cpufreq_init()
189 /* Look for the powertune data in the device-tree */ in maple_cpufreq_init()
[all …]
|
| /openbmc/linux/Documentation/process/ |
| H A D | 3.Early-stage.rst | 3 Early-stage planning
8 though, much of the groundwork for success is best laid before the first
9 line of code is written. Some time spent in early planning and
14 ----------------------
17 clear description of the problem to be solved. In some cases, this step is
18 easy: when a driver is needed for a specific piece of hardware, for
28 the linux-kernel mailing list, where it immediately ran into problems.
32 misuse of the LSM framework (which is not intended to confer privileges
41 entire kernel development process; one of them went back to an audio list
44 There are a number of very good Linux kernel developers, but they
[all …]
|
| /openbmc/u-boot/drivers/pci/ |
| H A D | pci_sh7751.c | 1 // SPDX-License-Identifier: GPL-2.0+
3 * SH7751 PCI Controller (PCIC) for U-Boot.
99 /* Double-check that we're a 7751 or 7751R chip */ in pci_sh7751_init()
107 /* Double-check some BSC config settings */ in pci_sh7751_init()
108 /* (Area 3 non-MPX 32-bit, PCI bus pins) */ in pci_sh7751_init()
151 /* Map both P0 and P2 range to Area 3 RAM for ease of use */ in pci_sh7751_init()
152 p4_out(CONFIG_SYS_SDRAM_SIZE - 0x100000, SH7751_PCILSR0); in pci_sh7751_init()
|