soc: qcom: smp2p: Introduce tracepoint support

Introduce tracepoint support for smp2p to enable
communication logging between local and remote processors.
Include tracepoints with information about

soc: qcom: smp2p: Introduce tracepoint support

Introduce tracepoint support for smp2p to enable
communication logging between local and remote processors.
Include tracepoints with information about the remote subsystem
name, negotiation details, supported features, bit change
notifications, and ssr activity. These logs are useful for
debugging issues between subsystems.

Signed-off-by: Sudeepgoud Patil <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: add pd-mapper implementation

Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if

soc: qcom: add pd-mapper implementation

Existing userspace protection domain mapper implementation has several
issue. It doesn't play well with CONFIG_EXTRA_FIRMWARE, it doesn't
reread JSON files if firmware location is changed (or if firmware was
not available at the time pd-mapper was started but the corresponding
directory is mounted later), etc.

Provide in-kernel service implementing protection domain mapping
required to work with several services, which are provided by the DSP
firmware.

This module is loaded automatically by the remoteproc drivers when
necessary via the symbol dependency. It uses a root node to match a
protection domains map for a particular board. It is not possible to
implement it as a 'driver' as there is no corresponding device.

Tested-by: Steev Klimaszewski <[email protected]>
Tested-by: Alexey Minnekhanov <[email protected]>
Reviewed-by: Chris Lew <[email protected]>
Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[bjorn: include linux/slab.h]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: pdr: extract PDR message marshalling data

The in-kernel PD mapper is going to use same message structures as the
QCOM_PDR_HELPERS module. Extract message marshalling data to separate
modu

soc: qcom: pdr: extract PDR message marshalling data

The in-kernel PD mapper is going to use same message structures as the
QCOM_PDR_HELPERS module. Extract message marshalling data to separate
module that can be used by both PDR helpers and by PD mapper.

Reviewed-by: Bryan O'Donoghue <[email protected]>
Tested-by: Steev Klimaszewski <[email protected]>
Tested-by: Alexey Minnekhanov <[email protected]>
Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD
Signed-off-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: add QCOM PBS driver

Add the Qualcomm PBS (Programmable Boot Sequencer) driver. The QCOM PBS
driver supports configuring software PBS trigger events through PBS RAM
on Qualcomm Technologie

soc: qcom: add QCOM PBS driver

Add the Qualcomm PBS (Programmable Boot Sequencer) driver. The QCOM PBS
driver supports configuring software PBS trigger events through PBS RAM
on Qualcomm Technologies, Inc (QTI) PMICs.

Signed-off-by: Anjelique Melendez <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: aoss: Add tracepoints in qmp_send()

Add tracepoint for tracing the messages being sent and the success
thereof. This is useful as the system has a variety of clients sending
requests to t

soc: qcom: aoss: Add tracepoints in qmp_send()

Add tracepoint for tracing the messages being sent and the success
thereof. This is useful as the system has a variety of clients sending
requests to the always-on subsystem.

Signed-off-by: Bjorn Andersson <[email protected]>
Reviewed-by: Chris Lew <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: pmic_pdcharger_ulog: Search current directory for headers

As specified in samples/trace_events/Makefile:

If you include a trace header outside of include/trace/events
then the fi

soc: qcom: pmic_pdcharger_ulog: Search current directory for headers

As specified in samples/trace_events/Makefile:

If you include a trace header outside of include/trace/events
then the file that does the #define CREATE_TRACE_POINTS must
have that tracer file in its main search path. This is because
define_trace.h will include it, and must be able to find it from
the include/trace directory.

Without this the following compilation error is seen:

CC drivers/soc/qcom/pmic_pdcharger_ulog.o
In file included from drivers/soc/qcom/pmic_pdcharger_ulog.h:36,
from drivers/soc/qcom/pmic_pdcharger_ulog.c:15:
./include/trace/define_trace.h:95:42: fatal error: ./pmic_pdcharger_ulog.h: No such file or directory
95 | #include TRACE_INCLUDE(TRACE_INCLUDE_FILE)
| ^
compilation terminated.

Fixes: 086fdb48bc65 ("soc: qcom: add ADSP PDCharger ULOG driver")
Signed-off-by: Andrew Halaney <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: add ADSP PDCharger ULOG driver

The Qualcomm PMIC PDCharger ULOG driver provides access to logs of
the ADSP firmware PDCharger module in charge of Battery and Power
Delivery on modern syst

soc: qcom: add ADSP PDCharger ULOG driver

The Qualcomm PMIC PDCharger ULOG driver provides access to logs of
the ADSP firmware PDCharger module in charge of Battery and Power
Delivery on modern systems.

Implement trace events as a simple rpmsg driver with an 1s interval
to retrieve the messages.

The interface allows filtering the messages by subsystem and priority
level, this could be implemented later on.

Signed-off-by: Neil Armstrong <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Tested-by: Dmitry Baryshkov <[email protected]>
Link: https://lore.kernel.org/r/20230908-topic-sm8550-upstream-pdcharge-ulog-v1-1-d1b16b02ced2@linaro.org
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: Move power-domain drivers to the genpd dir

To simplify with maintenance let's move the qcom power-domain drivers to
the new genpd directory. Going forward, patches are intended to be mana

soc: qcom: Move power-domain drivers to the genpd dir

To simplify with maintenance let's move the qcom power-domain drivers to
the new genpd directory. Going forward, patches are intended to be managed
through a separate git tree, according to MAINTAINERS.

Cc: Bjorn Andersson <[email protected]>
Cc: Konrad Dybcio <[email protected]>
Cc: Andy Gross <[email protected]>
Cc: <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>

show more ...

soc: qcom: Add RPM processor/subsystem driver

Add a simple driver for the qcom,rpm-proc compatible that registers the
"smd-edge" and populates other children defined in the device tree.

Note that t

soc: qcom: Add RPM processor/subsystem driver

Add a simple driver for the qcom,rpm-proc compatible that registers the
"smd-edge" and populates other children defined in the device tree.

Note that the DT schema belongs to the remoteproc subsystem while this
driver is added inside soc/qcom. I argue that the RPM *is* a remoteproc,
but as an implementation detail in Linux it can currently not benefit
from anything provided by the remoteproc subsystem. The RPM firmware is
usually already loaded and started by earlier components in the boot
chain and is not meant to be ever restarted.

To avoid breaking existing kernel configurations the driver is always
built when smd-rpm.c is also built. They belong closely together anyway.
To avoid build errors CONFIG_RPMSG_QCOM_SMD must be also built-in if
rpm-proc is.

Reviewed-by: Konrad Dybcio <[email protected]>
Signed-off-by: Stephan Gerhold <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: Rename ice to qcom_ice to avoid module name conflict

The following error was reported when building x86_64 allmodconfig:

error: the following would cause module name conflict:
drivers/

soc: qcom: Rename ice to qcom_ice to avoid module name conflict

The following error was reported when building x86_64 allmodconfig:

error: the following would cause module name conflict:
drivers/soc/qcom/ice.ko
drivers/net/ethernet/intel/ice/ice.ko

Seems the 'ice' module name is already used by some Intel ethernet
driver, so lets rename the Qualcomm Inline Crypto Engine (ICE) module
from 'ice' to 'qcom_ice' to avoid any kind of errors/confusions.

Reported-by: Stephen Rothwell <[email protected]>
Fixes: 2afbf43a4aec ("soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver")
Acked-by: Mukesh Ojha <[email protected]>
Signed-off-by: Abel Vesa <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

soc: qcom: Introduce RPM master stats driver

Introduce a driver to query and expose detailed, per-subsystem (as opposed
to the existing qcom_stats driver which exposes SoC-wide data) about low
power

soc: qcom: Introduce RPM master stats driver

Introduce a driver to query and expose detailed, per-subsystem (as opposed
to the existing qcom_stats driver which exposes SoC-wide data) about low
power mode states of a given RPM master. That includes the APSS (ARM),
MPSS (modem) and other remote cores, depending on the platform
configuration.

This is a vastly cleaned up and restructured version of a similar
driver found in msm-5.4.

Reviewed-by: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Konrad Dybcio <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver

This takes the already existing duplicated support in both ufs-qcom
and sdhci-msm drivers and makes it a dedicated driver that can be use

soc: qcom: Make the Qualcomm UFS/SDCC ICE a dedicated driver

This takes the already existing duplicated support in both ufs-qcom
and sdhci-msm drivers and makes it a dedicated driver that can be used
by both mentioned drivers.

The reason for this is because, staring with SM8550, the ICE IP block
is shared between UFS and SDCC, which means we need to probe a dedicated
device and share it between those two consumers.

So let's add the ICE dedicated driver as a soc driver.

Platforms that already have ICE supported, will use it as a library
as the of_qcom_ice_get will return an ICE instance created for the
consumer device. This allows the backwards compatibility with old-style
devicetree approach.

Also, add support to HW version 4.x since it works out-of-the-box with
the current driver. The 4.x HW version is found on SM8550 platform.

Signed-off-by: Abel Vesa <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

soc: qcom: pmic_glink: Introduce altmode support

With the PMIC GLINK service, the host OS subscribes to USB-C altmode
messages, which are sent by the firmware to notify the host OS about
state updat

soc: qcom: pmic_glink: Introduce altmode support

With the PMIC GLINK service, the host OS subscribes to USB-C altmode
messages, which are sent by the firmware to notify the host OS about
state updates and HPD interrupts.

The pmic_glink_altmode driver registers for these notifications and
propagates the notifications as typec_mux, typec_switch and DRM OOB
notifications as necessary to implement DisplayPort altmode support.

Signed-off-by: Bjorn Andersson <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Tested-by: Konrad Dybcio <[email protected]> # SM8350 PDX215
Reviewed-by: Neil Armstrong <[email protected]>
Tested-by: Neil Armstrong <[email protected]> # on SM8550-MTP & SM8450-HDK
Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

soc: qcom: pmic_glink: Introduce base PMIC GLINK driver

The PMIC GLINK service runs on one of the co-processors of some modern
Qualcomm platforms and implements USB-C and battery managements. It use

soc: qcom: pmic_glink: Introduce base PMIC GLINK driver

The PMIC GLINK service runs on one of the co-processors of some modern
Qualcomm platforms and implements USB-C and battery managements. It uses
a message based protocol over GLINK for communication with the OS, hence
the name.

The driver implemented provides the rpmsg device for communication and
uses auxiliary bus to spawn off individual devices in respective
subsystem. The auxiliary devices are spawned off from a
platform_device, so that the drm_bridge is available early, to allow the
DisplayPort driver to probe even before the remoteproc has spun up.

Signed-off-by: Bjorn Andersson <[email protected]>
Tested-by: Konrad Dybcio <[email protected]> # SM8350 PDX215
Reviewed-by: Neil Armstrong <[email protected]>
Tested-by: Neil Armstrong <[email protected]> # on SM8550-MTP & SM8450-HDK
Signed-off-by: Bjorn Andersson <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

soc: qcom: dcc: Drop driver for now

Arnd asks for the DCC driver to be dropped for now, in order to allow
for more thorough review, by a wider audience, of the ABI introduced.

The Devicetree bindin

soc: qcom: dcc: Drop driver for now

Arnd asks for the DCC driver to be dropped for now, in order to allow
for more thorough review, by a wider audience, of the ABI introduced.

The Devicetree binding is adequately describing the hardware block, so
this is kept.

Requested-by: Arnd Bergmann <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)

The DCC is a DMA Engine designed to capture and store data
during system crash or software triggers. The DCC operates
based

soc: qcom: dcc: Add driver support for Data Capture and Compare unit(DCC)

The DCC is a DMA Engine designed to capture and store data
during system crash or software triggers. The DCC operates
based on user inputs via the debugfs interface. The user gives
addresses as inputs and these addresses are stored in the
dcc sram. In case of a system crash or a manual software
trigger by the user through the debugfs interface,
the dcc captures and stores the values at these addresses.
This patch contains the driver which has all the methods
pertaining to the debugfs interface, auxiliary functions to
support all the four fundamental operations of dcc namely
read, write, read/modify/write and loop. The probe method
here instantiates all the resources necessary for dcc to
operate mainly the dedicated dcc sram where it stores the
values. The DCC driver can be used for debugging purposes
without going for a reboot since it can perform software
triggers as well based on user inputs.

Also add the documentation for debugfs entries which explains
the functionalities of each debugfs file that has been created
for dcc.

The following is the justification of using debugfs interface
over the other alternatives like sysfs/ioctls

i) As can be seen from the debugfs attribute descriptions,
some of the debugfs attribute files here contains multiple
arguments which needs to be accepted from the user. This goes
against the design style of sysfs.

ii) The user input patterns have been made simple and convenient
in this case with the use of debugfs interface as user doesn't
need to shuffle between different files to execute one instruction
as was the case on using other alternatives.

Signed-off-by: Souradeep Chowdhury <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
[bjorn: Fixed up a few indents and line wraps]
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/644b4f66a358492a8a6738454035c3b120092fe7.1672148732.git.quic_schowdhu@quicinc.com

show more ...

soc: qcom: Add Qualcomm Ramp Controller driver

The Ramp Controller is used to program the sequence ID for pulse
swallowing, enable sequence and linking sequence IDs for the CPU
cores on some Qualcom

soc: qcom: Add Qualcomm Ramp Controller driver

The Ramp Controller is used to program the sequence ID for pulse
swallowing, enable sequence and linking sequence IDs for the CPU
cores on some Qualcomm SoCs.

Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: Dmitry Baryshkov <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

soc: qcom: icc-bwmon: Add bandwidth monitoring driver

Bandwidth monitoring (BWMON) sits between various subsytems like CPU,
GPU, Last Level caches and memory subsystem. The BWMON can be
configured

soc: qcom: icc-bwmon: Add bandwidth monitoring driver

Bandwidth monitoring (BWMON) sits between various subsytems like CPU,
GPU, Last Level caches and memory subsystem. The BWMON can be
configured to monitor the data throuhput between memory and other
subsytems. The throughput is measured within specified sampling window
and is used to vote for corresponding interconnect bandwidth.

Current implementation brings support for BWMON v4, used for example on
SDM845 to measure bandwidth between CPU (gladiator_noc) and Last Level
Cache (memnoc). Usage of this BWMON allows to remove fixed bandwidth
votes from cpufreq (CPU nodes) thus achieve high memory throughput even
with lower CPU frequencies.

The driver was tested on SDM845.

Co-developed-by: Thara Gopinath <[email protected]>
Signed-off-by: Thara Gopinath <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

soc: qcom: Add Sleep stats driver

Let's add a driver to read the stats from remote processor and
export to debugfs.

The driver creates "qcom_sleep_stats" directory in debugfs and
adds files for var

soc: qcom: Add Sleep stats driver

Let's add a driver to read the stats from remote processor and
export to debugfs.

The driver creates "qcom_sleep_stats" directory in debugfs and
adds files for various low power mode available. Below is sample
output with command

cat /sys/kernel/debug/qcom_sleep_stats/ddr
count = 0
Last Entered At = 0
Last Exited At = 0
Accumulated Duration = 0

Signed-off-by: Mahesh Sivasubramanian <[email protected]>
Signed-off-by: Lina Iyer <[email protected]>
[mkshah: add subsystem sleep stats, create one file for each stat]
Signed-off-by: Maulik Shah <[email protected]>
Tested-by: Shawn Guo <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

cpuidle: qcom_spm: Detach state machine from main SPM handling

In commit a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic
CPUidle driver") the SPM driver has been converted to a
gene

cpuidle: qcom_spm: Detach state machine from main SPM handling

In commit a871be6b8eee ("cpuidle: Convert Qualcomm SPM driver to a generic
CPUidle driver") the SPM driver has been converted to a
generic CPUidle driver: that was mainly made to simplify the
driver and that was a great accomplishment;
Though, at that time, this driver was only applicable to ARM 32-bit SoCs,
lacking logic about the handling of newer generation SAW.

In preparation for the enablement of SPM features on AArch64/ARM64,
split the cpuidle-qcom-spm driver in two: the CPUIdle related
state machine (currently used only on ARM SoCs) stays there, while
the SPM communication handling lands back in soc/qcom/spm.c and
also making sure to not discard the simplifications that were
introduced in the aforementioned commit.

Since now the "two drivers" are split, the SCM dependency in the
main SPM handling is gone and for this reason it was also possible
to move the SPM initialization early: this will also make sure that
whenever the SAW CPUIdle driver is getting initialized, the SPM
driver will be ready to do the job.

Please note that the anticipation of the SPM initialization was
also done to optimize the boot times on platforms that have their
CPU/L2 idle states managed by other means (such as PSCI), while
needing SAW initialization for other purposes, like AVS control.

Signed-off-by: AngeloGioacchino Del Regno <[email protected]>
Reviewed-by: Stephan Gerhold <[email protected]>
Tested-by: Stephan Gerhold <[email protected]>
Acked-by: Daniel Lezcano <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

PM: AVS: qcom-cpr: Move the driver to the qcom specific drivers

The avs drivers are all SoC specific drivers that doesn't share any code.
Instead they are located in a directory, mostly to keep simi

PM: AVS: qcom-cpr: Move the driver to the qcom specific drivers

The avs drivers are all SoC specific drivers that doesn't share any code.
Instead they are located in a directory, mostly to keep similar
functionality together. From a maintenance point of view, it makes better
sense to collect SoC specific drivers like these, into the SoC specific
directories.

Therefore, let's move the qcom-cpr driver to the qcom directory.

Signed-off-by: Ulf Hansson <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Acked-by: Niklas Cassel <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

soc: qcom: Separate kryo l2 accessors from PMU driver

The driver provides kernel level API for other drivers
to access the MSM8996 L2 cache registers.
Separating the L2 access code from the PMU driv

soc: qcom: Separate kryo l2 accessors from PMU driver

The driver provides kernel level API for other drivers
to access the MSM8996 L2 cache registers.
Separating the L2 access code from the PMU driver and
making it public to allow other drivers use it.
The accesses must be separated with a single spinlock,
maintained in this driver.

Signed-off-by: Ilia Lin <[email protected]>
Signed-off-by: Loic Poulain <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>

show more ...

cpuidle: Convert Qualcomm SPM driver to a generic CPUidle driver

The Qualcomm SPM cpuidle driver seems to be the last driver still
using the generic ARM CPUidle infrastructure.

Converting it actual

cpuidle: Convert Qualcomm SPM driver to a generic CPUidle driver

The Qualcomm SPM cpuidle driver seems to be the last driver still
using the generic ARM CPUidle infrastructure.

Converting it actually allows us to simplify the driver,
and we end up being able to remove more lines than adding new ones:

- We can parse the CPUidle states in the device tree directly
with dt_idle_states (and don't need to duplicate that
functionality into the spm driver).

- Each "saw" device managed by the SPM driver now directly
registers its own cpuidle driver, removing the need for
any global (per cpu) state.

The device tree binding is the same, so the driver stays
compatible with all old device trees.

Signed-off-by: Stephan Gerhold <[email protected]>
Reviewed-by: Lina Iyer <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

rpmsg: glink: Integrate glink_ssr in qcom_glink

In all but the very special case of a system with _only_ glink_rpm,
GLINK is dependent on glink_ssr, so move it to rpmsg and combine it with
qcom_glin

rpmsg: glink: Integrate glink_ssr in qcom_glink

In all but the very special case of a system with _only_ glink_rpm,
GLINK is dependent on glink_ssr, so move it to rpmsg and combine it with
qcom_glink_native in the new qcom_glink kernel module.

Acked-by: Chris Lew <[email protected]>
Acked-by: Rishabh Bhatnagar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...

soc: qcom: Introduce Protection Domain Restart helpers

Qualcomm SoCs (starting with MSM8998) allow for multiple protection domains
to run on the same Q6 sub-system. This allows for services like ATH

soc: qcom: Introduce Protection Domain Restart helpers

Qualcomm SoCs (starting with MSM8998) allow for multiple protection domains
to run on the same Q6 sub-system. This allows for services like ATH10K WLAN
FW to have their own separate address space and crash/recover without
disrupting the modem and other PDs running on the same sub-system. The PDR
helpers introduces an abstraction that allows for tracking/controlling the
life cycle of protection domains running on various Q6 sub-systems.

Signed-off-by: Sibi Sankar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Bjorn Andersson <[email protected]>

show more ...