[PATCH 00/12] Re-introduce Exynos4212 support and add Samsung Galaxy Tab 3 8.0 boards

[Artur Weber]

On 16/04/2023 12:53, Krzysztof Kozlowski wrote:
> On 16/04/2023 12:49, Artur Weber wrote:
>> On 16/04/2023 12:34, Krzysztof Kozlowski wrote:
>>> On 16/04/2023 12:26, Artur Weber wrote:
>>>> On 16/04/2023 12:16, Artur Weber wrote:
>>>>> This patches re-introduces the Exynos4212 platform and adds support
>>>>> for the Samsung Galaxy Tab 3 8.0 series of tablets that uses it:
>>>>>
>>>>>     - Samsung Galaxy Tab 3 8.0 WiFi (SM-T310/lt01wifi)
>>>>>     - Samsung Galaxy Tab 3 8.0 3G (SM-T311/lt013g)
>>>>>     - Samsung Galaxy Tab 3 8.0 LTE (SM-T315/lt01lte)
>>>>>
>>>>> What works:
>>>>>
>>>>>     - Display and backlight
>>>>>     - Touchscreen (without touchkeys)
>>>>>     - GPIO buttons, hall sensor
>>>>>     - WiFi and Bluetooth
>>>>>     - USB, fuel gauge, charging (partial)
>>>>>     - Accelerometer and magnetometer
>>>>>     - WiFi model only: light sensor
>>>>
>>>> This patchset depends on "[PATCH 0/3] Add Samsung S6D7AA0 panel
>>>> controller driver" for the display panel support for the Samsung Galaxy
>>>> 3 8.0 boards.
>>>
>>> Why? DTS and ARM code cannot depend on driver changes. Please rework
>>> your patchsets to remove any of such dependencies.
>>
>> Ah, that makes sense. I'll re-send the patchset in a second with the
>> panel node removed.
> 
> I am sorry, I don't understand. Why would you remove anything from DTS?
> Are bindings NAKed?

The dependency display panel patchset introduces the panel and its 
bindings, which in turn are included in the Tab3 DTSI. It was submitted 
at roughly the same time as this series, and hasn't been fully reviewed 
or merged as of writing. (I have seen your comments on that patchset, 
and I will be addressing them shortly.) So the bindings haven't been 
explicitly ACKed yet (assuming you mean the Acked-by reply).

In response to:

 > Please rework your patchsets to remove any of such dependencies.

I suggested that I could remove the panel node from the DTSI for the 
time being. The intent was to submit it in a separate patch later, once 
the display is reviewed/merged, and thus actually available in the 
kernel; this way, the two patches could be reviewed and merged separately.

I could instead wait for the display patchset to get reviewed/merged 
first, then resubmit this series, if that's preferable.

I apologize for the confusion.

Best regards,
Artur Weber