* [PATCH v2 09/10] arm64: dts: qcom: msm8916: normalize I2C and SPI nodes
From: Bjorn Andersson @ 2017-12-16 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-10-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> The QUP core can be used either for I2C or SPI, so the same IP is mapped
> by a driver or the other. SPI bindings use a leading 0 for the start
> address and a size of 0x600, I2C bindings don't have the leading 0 and
> have a size 0x1000.
>
> To make them more similar, add the leading 0 to I2C bindings and changes
> the size to 0x500 for all of them, as this is the actual size of these
> blocks. Also align the second entry of the clocks array.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 08/10] arm64: dts: qcom: msm8916-pins: move sdhc2 cd node with its siblings
From: Bjorn Andersson @ 2017-12-16 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-9-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> Nodes relative to the first sdhc node were interlaced with node of the
> second sdhc. Move sdhc2_cd_pin with its siblings to prevent that. Also
> rename the grouping node from sdhc2_cd_pin to pmx_sdc2_cd_pin, as
> "pmx_sdc" is the prefix used by other nodes.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 07/10] arm64: dts: qcom: msm8916: drop remaining unused pinconfs
From: Bjorn Andersson @ 2017-12-16 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-8-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> This commit drops pin configs that cannot be moved to board files as
> no boards use them.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 06/10] arm64: dts: qcom: msm8916: move pinconfs to board files
From: Bjorn Andersson @ 2017-12-16 5:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-7-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> Following a suggestion from Bjorn Andersson [1], this commit moves
> electrical specifications which were defined in mms8916-pins.dtsi to
> board files, where they actually belong.
>
> Pinmuxing is kept in the platform file because there are no alternative
> pins on which all these functions could be routed, so this part is
> indeed common to all boards using this SoC.
>
> [1] https://www.spinics.net/lists/devicetree/msg201764.html
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
> Suggested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
I like the move, but I would prefer that you mimic the base structure,
rather than just appending properties based on labels.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 05/10] arm64: dts: qcom: apq8016-sbc: sort nodes alphabetically
From: Bjorn Andersson @ 2017-12-16 5:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-6-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> Also, it was using whitespaces for indentation on some lines, fix that
> while moving it.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Rather than extending single nodes like this I would prefer that we
bring in the associated pmic node, by this we avoid just having a huge
flat list of nodes. I.e. that we make this:
&pm8916_1 {
codec at f000 {
status = "okay";
clocks = <&gcc GCC_CODEC_DIGCODEC_CLK>;
clock-names = "mclk";
qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
};
};
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2 04/10] arm64: dts: qcom: msm8916: drop unused board-specific nodes
From: Bjorn Andersson @ 2017-12-16 5:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171207151942.5805-5-damien.riegel@savoirfairelinux.com>
On Thu 07 Dec 07:19 PST 2017, Damien Riegel wrote:
> These nodes reserve and configure some pins as GPIOs. They are not
> generic pinctrls, they actually belong to board files but they are not
> used by any other node, so just drop them altogether.
>
> Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Let's introduce them back into the db410c when we define a client.
Regards,
Bjorn
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: gengdongjiu @ 2017-12-16 4:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79ccc7df-802b-e25c-05cf-b1ecc7c05569@huawei.com>
On 2017/12/16 12:08, gengdongjiu wrote:
> On 2017/12/15 23:50, James Morse wrote:
>> + case ESR_ELx_AET_UER: /* Uncorrected Recoverable */
>> + /*
>> + * The CPU can't make progress. The exception may have
>> + * been imprecise.
>> + */
>> + return true;
> For Recoverable error (UER), the error has not been silently propagated,
> and has not been architecturally consumed by the PE, and
> The exception is precise and PE can recover execution from the preferred return address of the exception.
> so I do not think it should be panic here if the SError come from user space instead of coming from kernel space.
I paste the spec definition for the Recoverable error (UER) which got from [0]
Recoverable error (UER)
The state of the PE is Recoverable if all of the following are true:
? The error has not been silently propagated.
? The error has not been architecturally consumed by the PE. (The PE architectural state is not infected.)
? The exception is precise and PE can recover execution from the preferred return address of the exception, if software locates and repairs the error.
The PE cannot make correct progress without either consuming the error or otherwise making the error unrecoverable. The error remains latent in the system.
If software cannot locate and repair the error, either the application or the VM, or both, must be isolated by software.
[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf
>> +
^ permalink raw reply
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: gengdongjiu @ 2017-12-16 4:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A0B1334.7060500@arm.com>
[...]
>
>> + case ESR_ELx_AET_UER: /* The error has not been propagated */
>> + /*
>> + * Userspace only handle the guest SError Interrupt(SEI) if the
>> + * error has not been propagated
>> + */
>> + run->exit_reason = KVM_EXIT_EXCEPTION;
>> + run->ex.exception = ESR_ELx_EC_SERROR;
>> + run->ex.error_code = KVM_SEI_SEV_RECOVERABLE;
>> + return 0;
>
> We should not pass RAS notifications to user space. The kernel either handles
> them, or it panics(). User space shouldn't even know if the kernel supports RAS
For the ESR_ELx_AET_UER(Recoverable error), let us see its definition
below, which get from [0]
The state of the PE is Recoverable if all of the following are true:
? The error has not been silently propagated.
? The error has not been architecturally consumed by the PE. (The PE
architectural state is not infected.)
? The exception is precise and PE can recover execution from the
preferred return address of the exception, if software locates and
repairs the error.
The PE cannot make correct progress without either consuming the error
or otherwise making the error unrecoverable. The error remains latent
in the system.
If software cannot locate and repair the error, either the application
or the VM, or both, must be isolated by software.
so we can see the exception is precise and PE can recover execution
from the preferred return address of the exception, so let guest
handling it is
better, for example, if it is guest application RAS error, we can kill
the guest application instead of panic whole OS; if it is guest kernel
RAS error, guest will panic.
Host does not know which application of guest has error, so host can
not handle it, panic OS is not a good choice for the Recoverable
error.
[0]
https://static.docs.arm.com/ddi0587/a/RAS%20Extension-release%20candidate_march_29.pdf
> until it gets an MCEERR signal.
user space will detect whether kernel support RAS before handing it.
>
> You're making your firmware-first notification an EL3->EL0 signal, bypassing the OS.
>
> If we get a RAS SError and there are no CPER records or values in the ERR nodes,
> we should panic as it looks like the CPU/firmware is broken. (spurious RAS errors)
>
>
>> + default:
>> + /*
>> + * Until now, the CPU supports RAS and SEI is fatal, or host
>> + * does not support to handle the SError.
>> + */
>> + panic("This Asynchronous SError interrupt is dangerous, panic");
>> + }
>> +
>> + return 0;
>> +}
>> +
>> /*
>> * Return > 0 to return to guest, < 0 on error, 0 (and set exit_reason) on
>> * proper exit to userspace.
>
>
>
> James
> _______________________________________________
> kvmarm mailing list
> kvmarm at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: gengdongjiu @ 2017-12-16 4:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215155101.23505-5-james.morse@arm.com>
On 2017/12/15 23:50, James Morse wrote:
> + case ESR_ELx_AET_UER: /* Uncorrected Recoverable */
> + /*
> + * The CPU can't make progress. The exception may have
> + * been imprecise.
> + */
> + return true;
For Recoverable error (UER), the error has not been silently propagated,
and has not been architecturally consumed by the PE, and
The exception is precise and PE can recover execution from the preferred return address of the exception.
so I do not think it should be panic here if the SError come from user space instead of coming from kernel space.
> +
^ permalink raw reply
* [PATCH] drm: Fix possible deadlock in drm_mode_config_cleanup()
From: kbuild test robot @ 2017-12-16 4:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213085720.6059-1-m.szyprowski@samsung.com>
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on v4.15-rc3]
[cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next drm-intel/for-linux-next next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Marek-Szyprowski/drm-Fix-possible-deadlock-in-drm_mode_config_cleanup/20171216-102239
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
include/net/cfg80211.h:3278: warning: Excess enum value 'WIPHY_FLAG_SUPPORTS_SCHED_SCAN' description in 'wiphy_flags'
kernel/sched/core.c:5113: warning: No description found for parameter 't'
kernel/sched/core.c:5113: warning: Excess function parameter 'interval' description in 'sched_rr_get_interval'
drivers/gpio/gpiolib.c:601: warning: No description found for parameter '16'
drivers/gpio/gpiolib.c:601: warning: Excess struct member 'events' description in 'lineevent_state'
include/linux/iio/iio.h:610: warning: No description found for parameter 'iio_dev'
include/linux/iio/iio.h:610: warning: Excess function parameter 'indio_dev' description in 'iio_device_register'
include/linux/iio/trigger.h:79: warning: No description found for parameter 'owner'
fs/inode.c:1680: warning: No description found for parameter 'rcu'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_transaction'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_next_transaction'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_list'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_vfs_inode'
include/linux/jbd2.h:443: warning: No description found for parameter 'i_flags'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_rsv_handle'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_reserved'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_type'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_line_no'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_start_jiffies'
include/linux/jbd2.h:497: warning: No description found for parameter 'h_requested_credits'
include/linux/jbd2.h:497: warning: No description found for parameter 'saved_alloc_context'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_chkpt_bhs'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_devname'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_average_commit_time'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_min_batch_time'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_max_batch_time'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_commit_callback'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_failed_commit'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_chksum_driver'
include/linux/jbd2.h:1050: warning: No description found for parameter 'j_csum_seed'
fs/jbd2/transaction.c:511: warning: No description found for parameter 'type'
fs/jbd2/transaction.c:511: warning: No description found for parameter 'line_no'
fs/jbd2/transaction.c:641: warning: No description found for parameter 'gfp_mask'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_pin'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_unpin'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_res_obj'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_get_sg_table'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_import_sg_table'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_vmap'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_vunmap'
include/drm/drm_drv.h:594: warning: No description found for parameter 'gem_prime_mmap'
include/drm/drm_mode_config.h:778: warning: No description found for parameter 'connector_free_works'
include/drm/drm_mode_config.h:778: warning: No description found for parameter 'connector_free_queue'
include/drm/drm_mode_config.h:778: warning: No description found for parameter 'modifiers_property'
>> include/drm/drm_mode_config.h:778: warning: Excess struct member 'pending_connector_free_works' description in 'drm_mode_config'
>> include/drm/drm_mode_config.h:778: warning: Excess struct member 'pending_connector_free_queue' description in 'drm_mode_config'
include/drm/drm_mode_config.h:778: warning: Excess struct member 'modifiers' description in 'drm_mode_config'
include/drm/drm_plane.h:552: warning: No description found for parameter 'modifiers'
include/drm/drm_plane.h:552: warning: No description found for parameter 'modifier_count'
drivers/gpu/drm/drm_edid.c:4837: warning: No description found for parameter 'is_hdmi2_sink'
drivers/gpu/drm/drm_syncobj.c:306: warning: No description found for parameter 'file_private'
drivers/gpu/drm/drm_syncobj.c:306: warning: No description found for parameter 'syncobj'
drivers/gpu/drm/drm_syncobj.c:306: warning: No description found for parameter 'handle'
drivers/gpu/drm/drm_syncobj.c:307: warning: No description found for parameter 'file_private'
drivers/gpu/drm/drm_syncobj.c:307: warning: No description found for parameter 'syncobj'
drivers/gpu/drm/drm_syncobj.c:307: warning: No description found for parameter 'handle'
drivers/gpu/drm/i915/i915_gem.c:548: warning: No description found for parameter 'rps_client'
drivers/gpu/drm/i915/i915_gem.c:548: warning: Excess function parameter 'rps' description in 'i915_gem_object_wait'
Error: Cannot open file drivers/gpu/drm/i915/intel_guc_loader.c
WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -function GuC-specific firmware loader drivers/gpu/drm/i915/intel_guc_loader.c' failed with return code 1
Error: Cannot open file drivers/gpu/drm/i915/intel_guc_loader.c
Error: Cannot open file drivers/gpu/drm/i915/intel_guc_loader.c
WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -internal drivers/gpu/drm/i915/intel_guc_loader.c' failed with return code 2
drivers/gpu/host1x/bus.c:50: warning: No description found for parameter 'driver'
drivers/gpu/drm/tve200/tve200_drv.c:1: warning: no structured comments found
net/core/dev.c:1678: warning: Excess function parameter 'dev' description in 'call_netdevice_notifiers_info'
net/core/dev.c:6361: warning: No description found for parameter 'extack'
net/core/dev.c:6384: warning: No description found for parameter 'extack'
include/linux/rcupdate.h:571: ERROR: Unexpected indentation.
include/linux/rcupdate.h:575: ERROR: Unexpected indentation.
include/linux/rcupdate.h:579: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/rcupdate.h:581: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/rcupdate.h:581: WARNING: Inline literal start-string without end-string.
kernel/time/timer.c:1253: ERROR: Unexpected indentation.
kernel/time/timer.c:1255: ERROR: Unexpected indentation.
kernel/time/timer.c:1256: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:110: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/wait.h:113: ERROR: Unexpected indentation.
include/linux/wait.h:115: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/time/hrtimer.c:989: WARNING: Block quote ends without a blank line; unexpected unindent.
kernel/signal.c:325: WARNING: Inline literal start-string without end-string.
include/linux/iio/iio.h:219: ERROR: Unexpected indentation.
include/linux/iio/iio.h:220: WARNING: Block quote ends without a blank line; unexpected unindent.
include/linux/iio/iio.h:226: WARNING: Definition list ends without a blank line; unexpected unindent.
drivers/ata/libata-core.c:5913: ERROR: Unknown target name: "hw".
drivers/message/fusion/mptbase.c:5051: WARNING: Definition list ends without a blank line; unexpected unindent.
drivers/tty/serial/serial_core.c:1899: WARNING: Definition list ends without a blank line; unexpected unindent.
include/linux/regulator/driver.h:271: ERROR: Unknown target name: "regulator_regmap_x_voltage".
include/linux/spi/spi.h:373: ERROR: Unexpected indentation.
drivers/w1/w1_io.c:197: WARNING: Definition list ends without a blank line; unexpected unindent.
net/core/dev.c:4483: ERROR: Unknown target name: "page_is".
Documentation/trace/ftrace-uses.rst:53: WARNING: Definition list ends without a blank line; unexpected unindent.
Documentation/trace/ftrace-uses.rst:89: WARNING: Inline emphasis start-string without end-string.
Documentation/trace/ftrace-uses.rst:89: WARNING: Inline emphasis start-string without end-string.
Documentation/errseq.rst:: WARNING: document isn't included in any toctree
Documentation/networking/msg_zerocopy.rst:: WARNING: document isn't included in any toctree
Documentation/trace/ftrace-uses.rst:: WARNING: document isn't included in any toctree
Documentation/virtual/kvm/vcpu-requests.rst:: WARNING: document isn't included in any toctree
Documentation/dev-tools/kselftest.rst:15: WARNING: Could not lex literal_block as "c". Highlighting skipped.
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 133: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 164: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "~/.fonts.conf", line 193: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 43: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 56: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 69: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 82: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 96: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 109: Having multiple values in <test> isn't supported and may not work as expected
Fontconfig warning: "/home/kbuild/.config/fontconfig/fonts.conf", line 122: Having multiple values in <test> isn't supported and may not work as expected
vim +778 include/drm/drm_mode_config.h
28575f16 Daniel Vetter 2016-11-14 @778
:::::: The code at line 778 was first introduced by commit
:::::: 28575f165d36051310d7ea2350e2011f8095b6fb drm: Extract drm_mode_config.[hc]
:::::: TO: Daniel Vetter <daniel.vetter@ffwll.ch>
:::::: CC: Daniel Vetter <daniel.vetter@ffwll.ch>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6843 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171216/5ccb7fc1/attachment-0001.gz>
^ permalink raw reply
* [PATCH v4 2/2] ARM64: dts: meson-axg: enable ethernet for A113D S400 board
From: Yixun Lan @ 2017-12-16 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216035527.96952-1-yixun.lan@amlogic.com>
This is tested in the S400 dev board which use a RTL8211F PHY,
and the pins connect to the 'eth_rgmii_y_pins' group.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 70eca1f8736a..8932654f5090 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -17,6 +17,13 @@
};
};
+ðmac {
+ status = "okay";
+ phy-mode = "rgmii";
+ pinctrl-0 = <ð_rgmii_y_pins>;
+ pinctrl-names = "default";
+};
+
&uart_AO {
status = "okay";
};
--
2.15.1
^ permalink raw reply related
* [PATCH v4 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-16 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216035527.96952-1-yixun.lan@amlogic.com>
Add DT info for the stmmac ethernet MAC which found in
the Amlogic's Meson-AXG SoC, also describe the ethernet
pinctrl & clock information here.
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index d288d4724ae3..dea1bc31b4de 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/axg-clkc.h>
/ {
compatible = "amlogic,meson-axg";
@@ -155,6 +156,19 @@
};
};
+ ethmac: ethernet at ff3f0000 {
+ compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
+ reg = <0x0 0xff3f0000 0x0 0x10000
+ 0x0 0xff634540 0x0 0x8>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "macirq";
+ clocks = <&clkc CLKID_ETH>,
+ <&clkc CLKID_FCLK_DIV2>,
+ <&clkc CLKID_MPLL2>;
+ clock-names = "stmmaceth", "clkin0", "clkin1";
+ status = "disabled";
+ };
+
gic: interrupt-controller at ffc01000 {
compatible = "arm,gic-400";
reg = <0x0 0xffc01000 0 0x1000>,
@@ -215,6 +229,46 @@
gpio-ranges = <&pinctrl_periphs 0 0 86>;
};
+ eth_rgmii_x_pins: eth-x-rgmii {
+ mux {
+ groups = "eth_mdio_x",
+ "eth_mdc_x",
+ "eth_rgmii_rx_clk_x",
+ "eth_rx_dv_x",
+ "eth_rxd0_x",
+ "eth_rxd1_x",
+ "eth_rxd2_rgmii",
+ "eth_rxd3_rgmii",
+ "eth_rgmii_tx_clk",
+ "eth_txen_x",
+ "eth_txd0_x",
+ "eth_txd1_x",
+ "eth_txd2_rgmii",
+ "eth_txd3_rgmii";
+ function = "eth";
+ };
+ };
+
+ eth_rgmii_y_pins: eth-y-rgmii {
+ mux {
+ groups = "eth_mdio_y",
+ "eth_mdc_y",
+ "eth_rgmii_rx_clk_y",
+ "eth_rx_dv_y",
+ "eth_rxd0_y",
+ "eth_rxd1_y",
+ "eth_rxd2_rgmii",
+ "eth_rxd3_rgmii",
+ "eth_rgmii_tx_clk",
+ "eth_txen_y",
+ "eth_txd0_y",
+ "eth_txd1_y",
+ "eth_txd2_rgmii",
+ "eth_txd3_rgmii";
+ function = "eth";
+ };
+ };
+
pwm_a_a_pins: pwm_a_a {
mux {
groups = "pwm_a_a";
--
2.15.1
^ permalink raw reply related
* [PATCH v4 0/2] Add ethernet support for Meson-AXG SoC
From: Yixun Lan @ 2017-12-16 3:55 UTC (permalink / raw)
To: linux-arm-kernel
This series try to add support for the ethernet MAC controller
found in Meson-AXG SoC, and also enable it in the S400 board.
Hi Kevin:
You still need to at least merge the clock patch[3] in order to
compile the DTS, or just merge the tag from meson-clock's tree[6]
- the tag is 'meson-clk-for-v4.16-2', since the clock part already
taken there.
Changes in v4 since [5]:
- rebase to kevin's v4.16/dt64
- fix order
Changes in v3 since [4]:
- put clock DT info in soc.dtsi
- separate DT for 'add support for the controller' vs 'enable in board'
Changes in v2 since [1]:
- rebase to kevin's v4.16/dt64 branch
- add Neil's Reviewed-by
- move clock info to board.dts instead of in soc.dtsi
- drop "meson-axg-dwmac" compatible string, since we didn't use this
we could re-add it later when we really need.
- note: to make ethernet work properly,it depend on clock & pinctrl[2],
to compile the DTS, the patch [3] is required.
the code part will be taken via clock & pinctrl subsystem tree.
[5]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005783.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005784.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005785.html
[4]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005768.html
[1]
http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005301.html
[2]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005735.html
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005694.html
[3]
http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005738.html
[6] git://github.com/BayLibre/clk-meson.git
Yixun Lan (2):
ARM64: dts: meson-axg: add ethernet mac controller
ARM64: dts: meson-axg: enable ethernet for A113D S400 board
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 7 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
--
2.15.1
^ permalink raw reply
* [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization
From: gengdongjiu @ 2017-12-16 3:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A3419FF.30101@arm.com>
Hi James,
On 2017/12/16 2:52, James Morse wrote:
>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown below:
>>
>> SIGBUS_MCEERR_AR trigger Synchronous External Abort.
>> SIGBUS_MCEERR_AO trigger GPIO IRQ.
>>
>> For the SIGBUS_MCEERR_AO and SIGBUS_MCEERR_AR, we have already specify trigger method, which all
>>
>> not involve _trigger_ an SError.
> It's a policy choice. How does your virtual CPU notify RAS errors to its virtual
> software? You could use SError for SIGBUS_MCEERR_AR, it depends on what type of
> CPU you are trying to emulate.
>
> I'd suggest using NOTIFY_SEA for SIGBUS_MCEERR_AR as it avoids problems where
> the guest doesn't take the SError immediately, instead tries to re-execute the
I agree it is better to use NOTIFY_SEA for SIGBUS_MCEERR_AR in this case.
> code KVM has unmapped from stage2 because its corrupt. (You could detect this
> happening in Qemu and try something else)For something else, using NOTIFY_SEI for SIGBUS_MCEERR_AR? At current implementation,
It seems only have this case that "KVM has unmapped from stage2", do you thing we still have something else?
>
>
> Synchronous/asynchronous external abort matters to the CPU, but once the error
> has been notified to software the reasons for this distinction disappear. Once
> the error has been handled, all trace of this distinction is gone.
>
> CPER records only describe component failures. You are trying to re-create some
> state that disappeared with one of the firmware-first abstractions. Trying to
> re-create this information isn't worth the effort as the distinction doesn't
> matter to linux, only to the CPU.
>
>
>> so there is no chance for Qemu to trigger the SError when gets the SIGBUS_MCEERR_A{O,R}.
> You mean there is no reason for Qemu to trigger an SError when it gets a signal
> from the kernel.
>
> The reasons the CPU might have to generate an SError don't apply to linux and
> KVM user space. User-space will never get a signal for an uncontained error, we
> will always panic(). We can't give user-space a signal for imprecise exceptions,
> as it can't return from the signal. The classes of error that are left are
> covered by polled/irq and NOTIFY_SEA.
>
> Qemu can decide to generate RAS SErrors for SIGBUS_MCEERR_AR if it really wants
> to, (but I don't think you should, the kernel may have unmapped the page at PC
> from stage2 due to corruption).
yes, you also said you do not want to generate RAS SErrors for SIGBUS_MCEERR_AR,
so Qemu does not know in which condition to generate RAS SErrors.
>
> I think the problem here is you're applying the CPU->software behaviour and
> choices to software->software. By the time user-space gets the error, the
> behaviour is different.
In the KVM, as a policy choice to reserve this API to specify guest ESR and drive to trigger SError is OK,
At least for Qemu it does not know in which condition to trigger it.
^ permalink raw reply
* [PATCH v3 1/2] ARM64: dts: meson-axg: add ethernet mac controller
From: Yixun Lan @ 2017-12-16 3:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ho9mz94dg.fsf@baylibre.com>
HI Kevin
On 12/16/2017 03:29 AM, Kevin Hilman wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
>> Add DT info for the stmmac ethernet MAC which found in
>> the Amlogic's Meson-AXG SoC, also describe the ethernet
>> pinctrl & clock information here.
>>
>> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>
> This patch does not apply, and dependencies are not described.
>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 54 ++++++++++++++++++++++++++++++
>> 1 file changed, 54 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index d356ce74ad89..94c4972222b7 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -7,6 +7,7 @@
>> #include <dt-bindings/gpio/gpio.h>
>> #include <dt-bindings/interrupt-controller/irq.h>
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/clock/axg-clkc.h>
>>
>> / {
>> compatible = "amlogic,meson-axg";
>> @@ -148,6 +149,19 @@
>> #address-cells = <0>;
>> };
>>
>> + ethmac: ethernet at ff3f0000 {
>> + compatible = "amlogic,meson-gxbb-dwmac", "snps,dwmac";
>> + reg = <0x0 0xff3f0000 0x0 0x10000
>> + 0x0 0xff634540 0x0 0x8>;
>> + interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
>> + interrupt-names = "macirq";
>> + clocks = <&clkc CLKID_ETH>,
>> + <&clkc CLKID_FCLK_DIV2>,
>> + <&clkc CLKID_MPLL2>;
>> + clock-names = "stmmaceth", "clkin0", "clkin1";
>> + status = "disabled";
>> + };
>> +
>> hiubus: bus at ff63c000 {
>> compatible = "simple-bus";
>> reg = <0x0 0xff63c000 0x0 0x1c00>;
>
> Based on the hiubus node, presumably this depends on the patch from the
> clock series.
>
yes, it depend on clock, also the pinctrl patch
>> @@ -194,6 +208,46 @@
>> #gpio-cells = <2>;
>> gpio-ranges = <&pinctrl_periphs 0 0 86>;
>> };
>
> I'm not sure where this part is coming from, but it causes the rest of
> it to not apply.
>
> Please be sure to describe all dependencies.
>
.
exactly, it depend on pinctrl
actually, once you apply the clock & pinctrl DT patch, this one should
go fine. I will send another v4 which base on your recent v4.16/dt64
branch for your convenience.
Yixun
^ permalink raw reply
* [PATCH v4 0/2] dt: add pinctrl driver for Meson-AXG SoC
From: Yixun Lan @ 2017-12-16 3:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7ha7yj93hu.fsf@baylibre.com>
On 12/16/2017 03:48 AM, Kevin Hilman wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
>> This is DT part patchset for adding pinctrl support for
>> the Amlogic's Meson-AXG SoC.
>>
>> Changes since v3 at [3]
>> -- rebase to khilman's v4.16/dt64 branch and re-send
>> -- add Rob's Ack
>>
>> Changes since v2 at [2]:
>> -- Resend this patch series due to fail to send patch [2/2]
>>
>> Changes since v1 at [1]:
>> -- Separate DT part patches
>> -- Add Neil Armstrong's Ack
>>
>> [3]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005392.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005393.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005394.html
>>
>> [2]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005390.html
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005270.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005271.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005272.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005273.html
>> http://lists.infradead.org/pipermail/linux-amlogic/2017-November/005274.html
>>
>> Xingyu Chen (2):
>> documentation: Add compatibles for Amlogic Meson AXG pin controllers
>> ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
>
> Applied both to v4.14/dt64
>
> Normally, the documentation patch should go with the driver, but since
> Linus has already merged the driver, this time I'll take it with the DT
> itself.
>
Hi Kevin
sorry, I just checked Linus' pinctrl tree - the for-next branch, the
documentation patch is already taken there. so probably you could drop
it here?
Yixun
^ permalink raw reply
* [PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink
From: Brian Norris @ 2017-12-16 3:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171121082517.17233-1-jeffy.chen@rock-chips.com>
Hi,
On Tue, Nov 21, 2017 at 04:25:17PM +0800, Jeffy Chen wrote:
> The rt5514 dsp captures pcm data through spi directly, so we should not
> use rockchip-i2s as it's cpu dai like other codecs.
>
> Use dummy_dai for rt5514 dsp dailink to make voice wakeup work again.
>
> Reported-by: Jimmy Cheng-Yi Chiang <cychiang@google.com>
> Fixes: (72cfb0f20c75 ASoC: rockchip: Use codec of_node and dai_name for rt5514 dsp)
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
I didn't review this closely (and I don't know ASoC that well), but this
does fix regressions I've seen on 4.15 RCs, where
(a) the rt5514 DAI link doesn't get set up
(b) the rt5514 *always* causes my device to wake up, because we arm the
wakeup IRQ even though we never actually configured the DSP
(c) there are system crashes on resume because the rt5514-spi driver
assumes that the DAI link was correctly configured (that's the
subject of another patch I sent [1]
I believe this was working fine on 4.14? At least, I know (b) didn't
happen, and I'm not sure about (a). (c) is a new issue in 4.15-rc1.
Anyway, that's all to say:
Tested-by: Brian Norris <briannorris@chromium.org>
on the "kevin" Chromebook (Samsung Chromebook Plus).
I also suspect this might be regression-fixing material, for 4.15. Or if
not, at least something like patch [1] should be.
Thanks,
Brian
[1] https://patchwork.kernel.org/patch/10116761/
[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"
^ permalink raw reply
* [PATCH] kbuild: fix dependency of dtbs targets
From: Masahiro Yamada @ 2017-12-16 3:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+E-fH1mN8Cxu8=8-wRZ+edF0YK5wCrKavY3frp1opbZA@mail.gmail.com>
2017-12-14 6:31 GMT+09:00 Rob Herring <robh@kernel.org>:
> On Wed, Oct 25, 2017 at 12:40 AM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Hi.
>>
>>
>> 2017-10-10 0:05 GMT+09:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
>>> On Wed, Oct 04, 2017 at 01:27:20PM +0900, Masahiro Yamada wrote:
>>>> The target "dtbs" should depend on "scripts" because it needs to
>>>> build dtc. The "prepare" target is unneeded here.
>>>
>>> Looks fine for ARM, as the only thing the dtbs should depend on is
>>> the kernel configuration (to decide which to build) and DT tooling.
>>>
>>> Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
>>>
>>> --
>>
>>
>> I found a potential issue on this
>> because the default DTB install path depends on $(KERNELRELEASE).
>>
>>
>> In top-level Makefile:
>> export INSTALL_DTBS_PATH ?= $(INSTALL_PATH)/dtbs/$(KERNELRELEASE)
>>
>>
>> The include/config/kernel.release is created by "prepare3" target.
>>
>> If the dependency on "parepare" is removed,
>> it is possible to run "make dtbs" and "make dtbs_install"
>> without creating include/config/kernel.release.
>>
>> So, the $(KERNELRELEASE) could be empty when installing DTB.
>>
>>
>> Maybe, drop this patch, or reduce the dependency to "parepare3"?
>
> I was doing some work to get dtb builds to work without depending on
> $arch cross compiler and this patch fixes some of the issues. The
> dtbs_install target has the prepare dependency,
Which line?
I checked arch/{arm,arm64,mips}/Makefile, but I did not see any
dependency.
> so that should be
> sufficient and your patch should be fine.
Generally, adding dependencies to install targets is dangerous
because install targets are often invoked in root privilege.
This is stated by, for example,
commit 19514fc665ffbce624785f76ee7ad0ea6378a527
> BTW, Based on prior
> discussion on "ARM: kbuild: Fix forced rebuild after 'make dtbs'"
> thread, prepare should not be needed just for $(KERNELRELEASE).
>
> Rob
No.
If "prepare" target is dropped, you can run dtbs_install
without include/config/kenrel.release
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: gengdongjiu @ 2017-12-16 2:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215155101.23505-5-james.morse@arm.com>
On 2017/12/15 23:50, James Morse wrote:
> +asmlinkage void do_serror(struct pt_regs *regs, unsigned int esr)
> +{
> + nmi_enter();
How about firstly let APEI kernel driver to handle it by adding patch[1]? if the handling is successful, do_serror() direct return;
Otherwise continue check the ESR value, for example:
if (!ghes_notify_sei())
return;
[1] https://patchwork.kernel.org/patch/10053027/
> +
> + /* non-RAS errors are not containable */
> + if (!arm64_is_ras_serror(esr) || arm64_is_fatal_ras_serror(regs, esr))
> + arm64_serror_panic(regs, esr);
>
> - panic("Asynchronous SError Interrupt");
> + nmi_exit();
> }
>
^ permalink raw reply
* [RFC 5/5] ARM: dts: sun8i: a83t: bananapi-m3: Enable IR controller
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
The Bananapi M3 has an onboard IR receiver.
This enables the onboard IR receiver subnode.
Other than the other IR receivers this one needs a base clock frequency
of 3000000 Hz (3 MHz), to be able to work.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index c606af3dbfed..2c92c501cd59 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -88,6 +88,13 @@
/* TODO GL830 USB-to-SATA bridge downstream w/ GPIO power controls */
};
+&ir {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_pins_a>;
+ base-clk-frequency = <3000000>;
+ status = "okay";
+};
+
&mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 5dbf2f0891c1..679ce3a66b4b 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -470,7 +470,7 @@
#reset-cells = <1>;
};
- ir: ir at 01f02000 {
+ ir: ir at 1f02000 {
compatible = "allwinner,sun5i-a13-ir";
clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
clock-names = "apb", "ir";
--
2.11.0
^ permalink raw reply related
* [RFC 4/5] ARM: dts: sun8i: a83t: Add support for the ir interface
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
The ir interface is like the H3 at 0x01f02000 located and is exactly
the same. This patch adds support for the ir interface on the A83T.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 5edb645b506f..5dbf2f0891c1 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -470,6 +470,16 @@
#reset-cells = <1>;
};
+ ir: ir at 01f02000 {
+ compatible = "allwinner,sun5i-a13-ir";
+ clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
+ clock-names = "apb", "ir";
+ resets = <&r_ccu RST_APB0_IR>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0x01f02000 0x40>;
+ status = "disabled";
+ };
+
r_pio: pinctrl at 1f02c00 {
compatible = "allwinner,sun8i-a83t-r-pinctrl";
reg = <0x01f02c00 0x400>;
--
2.11.0
^ permalink raw reply related
* [RFC 3/5] ARM: dts: sun8i: a83t: Add the ir pin for the A83T
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
The CIR Pin of the A83T is located at PL12
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 19acae1b4089..5edb645b506f 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -488,6 +488,11 @@
drive-strength = <20>;
bias-pull-up;
};
+
+ ir_pins_a: ir at 0 {
+ pins = "PL12";
+ function = "s_cir_rx";
+ };
};
r_rsb: rsb at 1f03400 {
--
2.11.0
^ permalink raw reply related
* [RFC 2/5] [media] dt: bindings: Update binding documentation for sunxi IR controller
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
This patch updates documentation for Device-Tree bindings for sunxi IR
controller and adds the new requiered property for the base clock frequency.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
Documentation/devicetree/bindings/media/sunxi-ir.txt | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
index 91648c569b1e..5f4960c61245 100644
--- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
+++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
@@ -1,12 +1,13 @@
Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
Required properties:
-- compatible : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
-- clocks : list of clock specifiers, corresponding to
- entries in clock-names property;
-- clock-names : should contain "apb" and "ir" entries;
-- interrupts : should contain IR IRQ number;
-- reg : should contain IO map address for IR.
+- compatible : "allwinner,sun4i-a10-ir" or "allwinner,sun5i-a13-ir"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "apb" and "ir" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+- base-clk-frequency : should contain the base clock frequency
Optional properties:
- linux,rc-map-name: see rc.txt file in the same directory.
@@ -21,5 +22,6 @@ ir0: ir at 1c21800 {
resets = <&apb0_rst 1>;
interrupts = <0 5 1>;
reg = <0x01C21800 0x40>;
+ base-clk-frequency = <8000000>;
linux,rc-map-name = "rc-rc6-mce";
};
--
2.11.0
^ permalink raw reply related
* [RFC 1/5] [media] rc: update sunxi-ir driver to get base frequency from devicetree
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171216024914.7550-1-embed3d@gmail.com>
This patch updates the sunxi-ir driver to set the ir base clock from
devicetree.
This is neccessary since there are different ir recievers on the
market, that operate with different frequencys. So this value needs to
be set depending on the attached receiver.
Signed-off-by: Philipp Rossak <embed3d@gmail.com>
---
drivers/media/rc/sunxi-cir.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 97f367b446c4..55b53d6463e9 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -72,12 +72,6 @@
/* CIR_REG register idle threshold */
#define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
-/* Required frequency for IR0 or IR1 clock in CIR mode */
-#define SUNXI_IR_BASE_CLK 8000000
-/* Frequency after IR internal divider */
-#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
-/* Sample period in ns */
-#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
/* Noise threshold in samples */
#define SUNXI_IR_RXNOISE 1
/* Idle Threshold in samples */
@@ -122,7 +116,7 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
/* for each bit in fifo */
dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
rawir.pulse = (dt & 0x80) != 0;
- rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
+ rawir.duration = ((dt & 0x7f) + 1) * ir->rc->rx_resolution;
ir_raw_event_store_with_filter(ir->rc, &rawir);
}
}
@@ -148,6 +142,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
struct device_node *dn = dev->of_node;
struct resource *res;
struct sunxi_ir *ir;
+ u32 b_clk_freq;
ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
if (!ir)
@@ -172,6 +167,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
return PTR_ERR(ir->clk);
}
+ /* Required frequency for IR0 or IR1 clock in CIR mode */
+ if (of_property_read_u32(dn, "base-clk-frequency", &b_clk_freq)) {
+ dev_err(dev, "failed to get ir base clock frequency.\n");
+ return -ENODATA;
+ }
+
/* Reset (optional) */
ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
if (IS_ERR(ir->rst))
@@ -180,7 +181,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
+ ret = clk_set_rate(ir->clk, b_clk_freq);
if (ret) {
dev_err(dev, "set ir base clock failed!\n");
goto exit_reset_assert;
@@ -225,7 +226,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
ir->rc->dev.parent = dev;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
- ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
+ /* Frequency after IR internal divider with sample period in ns */
+ ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
ir->rc->driver_name = SUNXI_IR_DEV;
--
2.11.0
^ permalink raw reply related
* [RFC 0/5] IR support for A83T - sunxi-ir driver update
From: Philipp Rossak @ 2017-12-16 2:49 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for the sunxi A83T ir module and enhances the sunxi-ir driver.
Right now the base clock frequency for the ir driver is a hard coded define and is set to 8 MHz.
This works for the most common ir receivers. On the Sinovoip Bananapi M3 the ir receiver needs,
a 3 MHz base clock frequency to work without problems with this driver (like in the legacy kernel).
To fix this issue I reworked the driver that this value could be set over the devicetree.
About 37 devices would have a devicetree change if this patch series would be applied.
Therfore I would like to ask you to give me some feedback about the patch series, before I finialize it.
Thanks in advance!
Philipp
Philipp Rossak (5):
[media] rc: update sunxi-ir driver to get base frequency from
devicetree
[media] dt: bindings: Update binding documentation for sunxi IR
controller
ARM: dts: sun8i: a83t: Add the ir pin for the A83T
ARM: dts: sun8i: a83t: Add support for the ir interface
ARM: dts: sun8i: a83t: bananapi-m3: Enable IR controller
Documentation/devicetree/bindings/media/sunxi-ir.txt | 14 ++++++++------
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
arch/arm/boot/dts/sun8i-a83t.dtsi | 15 +++++++++++++++
drivers/media/rc/sunxi-cir.c | 20 +++++++++++---------
4 files changed, 41 insertions(+), 15 deletions(-)
--
2.11.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox