Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 06 4月, 2013 2 次提交
    • S
      kbuild: fixdep: support concatenated dep files · 2ab8a996
      由 Stephen Warren 提交于 
      The current use-case for fixdep is: a source file is run through a single
processing step, which creates a single dependency file as a side-effect,
which fixdep transforms into the file used by the kernel build process.

In order to transparently run the C pre-processor on device-tree files,
we wish to run both gcc -E and dtc on a source file in a single rule.
This generates two dependency files, which must be transformed together
into the file used by the kernel build process. This change modifies
fixdep so it can process the concatenation of multiple separate input
dependency files, and produce a correct unified output.

The code changes have the slight benefit of transforming the loop in
parse_dep_file() into more of a lexer/tokenizer, with the loop body being
more of a parser. Previously, some of this logic was mixed together
before the loop. I also added some comments, which I hope are useful.

Benchmarking shows that on a cross-compiled ARM tegra_defconfig build,
there is less than 0.5 seconds speed decrease with this change, on top
of a build time of ~2m24s. This is probably within the noise.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NRob Herring <rob.herring@calxeda.com>
      2ab8a996
    • S
      kbuild: create an "include chroot" for DT bindings · c58299aa
      由 Stephen Warren 提交于 
      The recent dtc+cpp support allows header files and C pre-processor
defines/macros to be used when compiling device tree files. These
headers will typically define various constants that are part of the
device tree bindings.

The original patch which set up the dtc+cpp include path only considered
using those headers from device tree files. However, most are also
useful for kernel code which needs to interpret the device tree.

In both the DT files and the kernel, I'd like to include the DT-related
headers in the same way, for example, <dt-bindings/gpio/tegra-gpio.h>.
That will simplify any text which discusses the DT header locations.

Creating a <dt-bindings/> for kernel source to use is as simple as
placing files into include/dt-bindings/.

However, when compiling DT files, the include path should be restricted
so that only the dt-bindings path is available; arbitrary kernel headers
shouldn't be exposed. For this reason, create a specific include
directory for use by dtc+cpp, and symlink dt-bindings from there to the
actual location of include/dt-bindings/. For want of a better location,
place this "include chroot" into the existing dts/ directory.

arch/*/boot/dts/include/dt-bindings -> ../../../../../include/dt-bindings

Some headers used by device tree files may not be useful to the kernel;
they may be used simply to aid in constructing the DT file (e.g. macros
to create a node), but not define any information that the kernel needs
to share. These may be placed directly into arch/*/boot/dts/ along with
the DT files themselves.
Acked-by: NMichal Marek <mmarek@suse.cz>
Acked-by: NShawn Guo <shawn.guo@linaro.org>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
      c58299aa
  3. 03 3月, 2013 3 次提交
  5. 28 2月, 2013 3 次提交
  7. 25 2月, 2013 1 次提交
  9. 22 2月, 2013 16 次提交
  11. 19 2月, 2013 1 次提交
  13. 14 2月, 2013 1 次提交
  15. 13 2月, 2013 1 次提交
    • S
      kbuild: limit dtc+cpp include path · e570d7c1
      由 Stephen Warren 提交于 
      Device tree source files may now include header files. The intent is
that those header files define/name constants used as part of the DT
bindings. Currently this feature is open to abuse, since any kernel
header file at all can be included, This could allow device tree files
to become dependant on kernel headers files, and thus make them no
longer OS-independent. This would also prevent separating the device
tree source files from the kernel repository.

Solve this by limiting the cpp include path for device tree files to
separate directories.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      e570d7c1
  17. 09 2月, 2013 2 次提交
  19. 08 2月, 2013 1 次提交
  21. 05 2月, 2013 1 次提交
  23. 30 1月, 2013 1 次提交
  25. 25 1月, 2013 3 次提交
  27. 24 1月, 2013 2 次提交
  29. 23 1月, 2013 1 次提交
    • T
      lib: devres: Introduce devm_ioremap_resource() · 75096579
      由 Thierry Reding 提交于 
      The devm_request_and_ioremap() function is very useful and helps avoid a
whole lot of boilerplate. However, one issue that keeps popping up is
its lack of a specific error code to determine which of the steps that
it performs failed. Furthermore, while the function gives an example and
suggests what error code to return on failure, a wide variety of error
codes are used throughout the tree.

In an attempt to fix these problems, this patch adds a new function that
drivers can transition to. The devm_ioremap_resource() returns a pointer
to the remapped I/O memory on success or an ERR_PTR() encoded error code
on failure. Callers can check for failure using IS_ERR() and determine
its cause by extracting the error code using PTR_ERR().

devm_request_and_ioremap() is implemented as a wrapper around the new
API and return NULL on failure as before. This ensures that backwards
compatibility is maintained until all users have been converted to the
new API, at which point the old devm_request_and_ioremap() function
should be removed.

A semantic patch is included which can be used to convert from the old
devm_request_and_ioremap() API to the new devm_ioremap_resource() API.
Some non-trivial cases may require manual intervention, though.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75096579
  31. 21 1月, 2013 1 次提交
    • V
      modpost: Ignore ARC specific non-alloc sections · f2e207f3
      由 Vineet Gupta 提交于 
      ARC relocatable object files contain one/more .gnu.linkonce.arcextmap.*
sections (collated by kernel/vmlinux.lds into .arcextmap in final link).
This section is used by debuggers to display the extension instructions
and need-not be loaded by target (hence !SHF_ALLOC)

The final kernel binary only needs .arcextmap entry in modpost's ignore
list (section_white_list[]). However when building modules, modpost scans
each object file individually, hence tripping on non-aggregated
.gnu.linkonce.arcextmap.* entries as well.

Thus need for the 2 entires !
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      f2e207f3