Xmas Offer
You are a recipient to Mrs Julie Leach Donation of $3 million USD. Contact ( julieleac...@gmail.com ) for claims. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Nov 27 05:00:18 CET 2016 media-tree git hash:d3d83ee20afda16ad0133ba00f63c11a8d842a35 media_build git hash: 1606032398b1d79149c1507be2029e1a00d8dff0 v4l-utils git hash: dab9bf5687eddea2f4cb8cdb38b3bbc5b079a037 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.8.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: OK linux-3.12.67-i686: OK linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-rc5-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: OK linux-3.12.67-x86_64: OK linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: OK linux-4.9-rc5-x86_64: OK apps: WARNINGS spec-git: OK smatch: ERRORS sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-keytable: infinite loops, segfaults
>> >> However when you try to use the new mapping in some application then >> it does not work? > > That's correct. ir-keytable seems to be doing the right thing, mapping > the scancode to the input-event-codes.h key code I asked it to. > > The application I am trying to use it with is the mythtv frontend. I > am doing the keycode munging from an SSH session while myth is still > running on the main screen. I didn't think this would matter (since it > worked for KEY_OK->KEY_ENTER) but perhaps it does. Obviously > ir-keytable -t intercepts the scancodes when it is running, but when I > kill it myth responds normally to some keys, but not all. It turned out that that I had to restart X to make it notice the updated keymap. After that, the modfied keymap I set up is mostly working. There is still a bit of a mystery. As I understand it, X should notice key codes less than 255 (0xff). But it seems to be ignoring KEY_STOP (code 128, 0x80) and any key codes higher than that but less than 255. ir-keytable -t shows the right codes. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] smiapp: Implement power-on and power-off sequences without runtime PM
On Fri, 25 Nov 2016, Laurent Pinchart wrote: > Hi Alan, Hello. > On Friday 25 Nov 2016 10:21:21 Alan Stern wrote: > > On Fri, 25 Nov 2016, Sakari Ailus wrote: > > > On Thu, Nov 24, 2016 at 09:15:39PM -0500, Alan Stern wrote: > > >> On Fri, 25 Nov 2016, Laurent Pinchart wrote: > > >>> Dear linux-pm developers, what's the suggested way to ensure that a > > >>> runtime- pm-enabled driver can run fine on a system with CONFIG_PM > > >>> disabled ? > > >> > > >> The exact point of your question isn't entirely clear. In the most > > >> literal sense, the best ways to ensure this are (1) audit the code, and > > >> (2) actually try it. > > >> > > >> I have a feeling this doesn't quite answer your question, however. :-) > > > > > > The question is related to devices that require certain power-up and > > > power-down sequences that are now implemented as PM runtime hooks that, > > > without CONFIG_PM defined, will not be executed. Is there a better way > > > than to handle this than have an implementation in the driver for the PM > > > runtime and non-PM runtime case separately? > > > > Yes, there is a better way. For the initial power-up and final > > power-down sequences, don't rely on the PM core to invoke the > > callbacks. Just call them directly, yourself. > > > > For example, as part of the probe routine, instead of doing this: > > > > pm_runtime_set_suspended(dev); > > pm_runtime_enable(dev); > > pm_runtime_get_sync(dev); > > > > Do this: > > > > pm_runtime_set_active(dev); > > pm_runtime_get_noresume(dev); > > pm_runtime_enable(dev); > > /* > > * In case CONFIG_PM is disabled, invoke the runtime-resume > > * callback directly. > > */ > > my_runtime_resume(dev); > > Wouldn't it be cleaner for drivers not to have to handle this manually (which > gives an opportunity to get it wrong) but instead have pm_runtime_enable() > call the runtime resume callback when CONFIG_PM is disabled ? Well, I admit it would be nicer if drivers didn't have to worry about whether or not CONFIG_PM was enabled. A slightly cleaner approach from the one outlined above would have the probe routine do this: my_power_up(dev); pm_runtime_set_active(dev); pm_runtime_get_noresume(dev); pm_runtime_enable(dev); and have the runtime-resume callback routine call my_power_up() to do its work. (Or make my_power_up() actually be the runtime-resume callback routine.) That's pretty straightforward and hard to mess up. In theory, we could have pm_runtime_enable() invoke the runtime-resume callback when CONFIG_PM is disabled. In practice, it would be rather awkward. drivers/base/power/runtime.c, which is where pm_runtime_enable() is defined and the runtime-PM callbacks are invoked, doesn't even get compiled if CONFIG_PM is off. (Also, it would run against the grain. CONFIG_PM=n means the kernel ignores runtime PM, so pm_runtime_enable() shouldn't do anything.) There's a corollary aspect to this. If you depend on runtime PM for powering up your device during probe, does that mean you also depend on runtime PM for powering down the device during remove? That is likely not to work, because the user can prevent runtime suspends by writing to /sys/.../power/control. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mn88473: refactor and fix statistics
On Sun, Nov 13, 2016 at 10:29 AM, Antti Palosaari wrote: > Remove DVB-T2 BER as it does not work at all and I didn't find > how to fix. > > Fix DVB-T and DVB-C BER. It seems to return new some realistic > looking values. > > Use (1 << 64) base for CNR calculations to keep it in line with > dvb logarithm functions. > > Move all statistic logic to mn88473_read_status() function. > > Use regmap_bulk_read() for reading multiple registers as a one go. > > And many more and less minor changes. > > Cc: Martin Blumenstingl > Signed-off-by: Antti Palosaari Tested-by: Martin Blumenstingl Tested successfully on DVB-C (only, since DVB-T2 is unavailable and DVB-T reception is *very* bad here). -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] [media] tw686x: silent -Wformat-security warning
Using sprintf() with a non-literal string makes some compiler complain
when building with -Wformat-security (eg. clang reports "format string
is not a string literal (potentially insecure)").
Here sprintf() format parameter is indirectly a literal string so there
is no security issue. Nevertheless adding a "%s" format string to
silent the warning helps to detect real bugs in the kernel.
Signed-off-by: Nicolas Iooss
---
drivers/media/pci/tw686x/tw686x-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/tw686x/tw686x-core.c
b/drivers/media/pci/tw686x/tw686x-core.c
index 71a0453b1af1..336e2f9bc1b6 100644
--- a/drivers/media/pci/tw686x/tw686x-core.c
+++ b/drivers/media/pci/tw686x/tw686x-core.c
@@ -74,7 +74,7 @@ static const char *dma_mode_name(unsigned int mode)
static int tw686x_dma_mode_get(char *buffer, struct kernel_param *kp)
{
- return sprintf(buffer, dma_mode_name(dma_mode));
+ return sprintf(buffer, "%s", dma_mode_name(dma_mode));
}
static int tw686x_dma_mode_set(const char *val, struct kernel_param *kp)
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] media: video-i2c: add video-i2c driver
Hi Matt,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.9-rc6 next-20161125]
[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/Matt-Ranostay/media-video-i2c-add-video-i2c-driver/20161126-144805
base: git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-x015-201648 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
drivers/media/i2c/video-i2c.c: In function 'video_i2c_thread_vid_cap':
>> drivers/media/i2c/video-i2c.c:207:12: error: implicit declaration of
>> function 'kthread_should_stop' [-Werror=implicit-function-declaration]
} while (!kthread_should_stop());
^~~
drivers/media/i2c/video-i2c.c: In function 'start_streaming':
>> drivers/media/i2c/video-i2c.c:219:26: error: implicit declaration of
>> function 'kthread_run' [-Werror=implicit-function-declaration]
data->kthread_vid_cap = kthread_run(video_i2c_thread_vid_cap, data,
^~~
>> drivers/media/i2c/video-i2c.c:219:24: warning: assignment makes pointer from
>> integer without a cast [-Wint-conversion]
data->kthread_vid_cap = kthread_run(video_i2c_thread_vid_cap, data,
^
drivers/media/i2c/video-i2c.c: In function 'stop_streaming':
>> drivers/media/i2c/video-i2c.c:253:2: error: implicit declaration of function
>> 'kthread_stop' [-Werror=implicit-function-declaration]
kthread_stop(data->kthread_vid_cap);
^~~~
cc1: some warnings being treated as errors
vim +/kthread_should_stop +207 drivers/media/i2c/video-i2c.c
201 vb2_buffer_done(vb2_buf, ret ?
202 VB2_BUF_STATE_ERROR :
VB2_BUF_STATE_DONE);
203 }
204 spin_unlock(&data->slock);
205
206 schedule_timeout_interruptible(delay - (jiffies -
start_jiffies));
> 207 } while (!kthread_should_stop());
208
209 return 0;
210 }
211
212 static int start_streaming(struct vb2_queue *vq, unsigned int count)
213 {
214 struct video_i2c_data *data = vb2_get_drv_priv(vq);
215
216 if (data->kthread_vid_cap)
217 return 0;
218
> 219 data->kthread_vid_cap = kthread_run(video_i2c_thread_vid_cap,
> data,
220 "%s-vid-cap",
data->v4l2_dev.name);
221
222 if (IS_ERR(data->kthread_vid_cap)) {
223 struct video_i2c_buffer *buf, *tmp;
224
225 list_for_each_entry_safe(buf, tmp,
&data->vid_cap_active, list) {
226 list_del(&buf->list);
227 vb2_buffer_done(&buf->vb.vb2_buf,
228 VB2_BUF_STATE_QUEUED);
229 }
230
231 return PTR_ERR(data->kthread_vid_cap);
232 }
233
234 return 0;
235 }
236
237 static void stop_streaming(struct vb2_queue *vq)
238 {
239 struct video_i2c_data *data = vb2_get_drv_priv(vq);
240
241 if (data->kthread_vid_cap == NULL)
242 return;
243
244 while (!list_empty(&data->vid_cap_active)) {
245 struct video_i2c_buffer *buf;
246
247 buf = list_entry(data->vid_cap_active.next,
248 struct video_i2c_buffer, list);
249 list_del(&buf->list);
250 vb2_buffer_done(&buf->vb.vb2_buf, VB2_BUF_STATE_ERROR);
251 }
252
> 253 kthread_stop(data->kthread_vid_cap);
254 data->kthread_vid_cap = NULL;
255 }
256
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH v2 3/3] stk1160: Add module param for setting the record gain.
On 26 November 2016 at 10:52, Marcel Hasler wrote:
> 2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
>> On 27 October 2016 at 17:35, Marcel Hasler wrote:
>>> Allow setting a custom record gain for the internal AC97 codec (if
>>> available). This can be
>>> a value between 0 and 15, 8 is the default and should be suitable for most
>>> users. The Windows
>>> driver also sets this to 8 without any possibility for changing it.
>>>
>>> Signed-off-by: Marcel Hasler
>>> ---
>>> drivers/media/usb/stk1160/stk1160-ac97.c | 11 ++-
>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c
>>> b/drivers/media/usb/stk1160/stk1160-ac97.c
>>> index 6dbc39f..31bdd60d 100644
>>> --- a/drivers/media/usb/stk1160/stk1160-ac97.c
>>> +++ b/drivers/media/usb/stk1160/stk1160-ac97.c
>>> @@ -25,6 +25,11 @@
>>> #include "stk1160.h"
>>> #include "stk1160-reg.h"
>>>
>>> +static u8 gain = 8;
>>> +
>>> +module_param(gain, byte, 0444);
>>> +MODULE_PARM_DESC(gain, "Set capture gain level if AC97 codec is available
>>> (0-15, default: 8)");
>>> +
>>> static void stk1160_write_ac97(struct stk1160 *dev, u16 reg, u16 value)
>>> {
>>> /* Set codec register address */
>>> @@ -122,7 +127,11 @@ void stk1160_ac97_setup(struct stk1160 *dev)
>>> stk1160_write_ac97(dev, 0x16, 0x0808); /* Aux volume */
>>> stk1160_write_ac97(dev, 0x1a, 0x0404); /* Record select */
>>> stk1160_write_ac97(dev, 0x02, 0x); /* Master volume */
>>> - stk1160_write_ac97(dev, 0x1c, 0x0808); /* Record gain */
>>> +
>>> + /* Record gain */
>>> + gain = (gain > 15) ? 15 : gain;
>>> + stk1160_info("Setting capture gain to %d.", gain);
>>
>> This message doesn't add anything useful, can we drop it?
>>
>
> I think it would make sense to have some kind of feedback, at least
> when the default value has been overridden. How about making this
> conditional?
>
Well, if the user passes a gain, requesting a non-default value, it is
expected that the gain be set by the driver. So printing a message
for something that is just as expected as "the driver will set the
parameter you told him to set".
User messages should only be printed when *unexpected* or otherwise
relevant events happen.
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] stk1160: Remove stk1160-mixer and setup internal AC97 codec automatically.
On 26 November 2016 at 10:38, Marcel Hasler wrote:
> Hello, and thanks for your feedback.
>
> 2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
>> Marcel,
>>
>> On 27 October 2016 at 17:34, Marcel Hasler wrote:
>>> Exposing all the channels of the device's internal AC97 codec to userspace
>>> is unnecessary and
>>> confusing. Instead the driver should setup the codec with proper values.
>>> This patch removes the
>>> mixer and sets up the codec using optimal values, i.e. the same values set
>>> by the Windows
>>> driver. This also makes the device work out-of-the-box, without the need
>>> for the user to
>>> reconfigure the device every time it's plugged in.
>>>
>>> Signed-off-by: Marcel Hasler
>>
>> This patch is *awesome*.
>>
>> You've re-written the file ;-), so if you want to put your
>> copyright on stk1160-ac97.c, be my guest.
>>
>
> Thanks, will do :-)
>
>> Also, just a minor comment, see below.
>>
>>> ---
>>> drivers/media/usb/stk1160/Kconfig| 10 +--
>>> drivers/media/usb/stk1160/Makefile | 4 +-
>>> drivers/media/usb/stk1160/stk1160-ac97.c | 121
>>> +++
>>> drivers/media/usb/stk1160/stk1160-core.c | 5 +-
>>> drivers/media/usb/stk1160/stk1160.h | 9 +--
>>> 5 files changed, 47 insertions(+), 102 deletions(-)
>>>
>>> diff --git a/drivers/media/usb/stk1160/Kconfig
>>> b/drivers/media/usb/stk1160/Kconfig
>>> index 95584c1..22dff4f 100644
>>> --- a/drivers/media/usb/stk1160/Kconfig
>>> +++ b/drivers/media/usb/stk1160/Kconfig
>>> @@ -8,17 +8,9 @@ config VIDEO_STK1160_COMMON
>>> To compile this driver as a module, choose M here: the
>>> module will be called stk1160
>>>
>>> -config VIDEO_STK1160_AC97
>>> - bool "STK1160 AC97 codec support"
>>> - depends on VIDEO_STK1160_COMMON && SND
>>> -
>>> - ---help---
>>> - Enables AC97 codec support for stk1160 driver.
>>> -
>>> config VIDEO_STK1160
>>> tristate
>>> - depends on (!VIDEO_STK1160_AC97 || (SND='n') || SND) &&
>>> VIDEO_STK1160_COMMON
>>> + depends on VIDEO_STK1160_COMMON
>>> default y
>>> select VIDEOBUF2_VMALLOC
>>> select VIDEO_SAA711X
>>> - select SND_AC97_CODEC if SND
>>> diff --git a/drivers/media/usb/stk1160/Makefile
>>> b/drivers/media/usb/stk1160/Makefile
>>> index dfe3e90..42d0546 100644
>>> --- a/drivers/media/usb/stk1160/Makefile
>>> +++ b/drivers/media/usb/stk1160/Makefile
>>> @@ -1,10 +1,8 @@
>>> -obj-stk1160-ac97-$(CONFIG_VIDEO_STK1160_AC97) := stk1160-ac97.o
>>> -
>>> stk1160-y := stk1160-core.o \
>>> stk1160-v4l.o \
>>> stk1160-video.o \
>>> stk1160-i2c.o \
>>> - $(obj-stk1160-ac97-y)
>>> + stk1160-ac97.o
>>>
>>> obj-$(CONFIG_VIDEO_STK1160) += stk1160.o
>>>
>>> diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c
>>> b/drivers/media/usb/stk1160/stk1160-ac97.c
>>> index 2dd308f..d3665ce 100644
>>> --- a/drivers/media/usb/stk1160/stk1160-ac97.c
>>> +++ b/drivers/media/usb/stk1160/stk1160-ac97.c
>>> @@ -21,19 +21,12 @@
>>> */
>>>
>>> #include
>>> -#include
>>> -#include
>>> -#include
>>>
>>> #include "stk1160.h"
>>> #include "stk1160-reg.h"
>>>
>>> -static struct snd_ac97 *stk1160_ac97;
>>> -
>>> -static void stk1160_write_ac97(struct snd_ac97 *ac97, u16 reg, u16 value)
>>> +static void stk1160_write_ac97(struct stk1160 *dev, u16 reg, u16 value)
>>> {
>>> - struct stk1160 *dev = ac97->private_data;
>>> -
>>> /* Set codec register address */
>>> stk1160_write_reg(dev, STK1160_AC97_ADDR, reg);
>>>
>>> @@ -48,9 +41,9 @@ static void stk1160_write_ac97(struct snd_ac97 *ac97, u16
>>> reg, u16 value)
>>> stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x8c);
>>> }
>>>
>>> -static u16 stk1160_read_ac97(struct snd_ac97 *ac97, u16 reg)
>>> +#ifdef DEBUG
>>> +static u16 stk1160_read_ac97(struct stk1160 *dev, u16 reg)
>>> {
>>> - struct stk1160 *dev = ac97->private_data;
>>> u8 vall = 0;
>>> u8 valh = 0;
>>>
>>> @@ -70,81 +63,53 @@ static u16 stk1160_read_ac97(struct snd_ac97 *ac97, u16
>>> reg)
>>> return (valh << 8) | vall;
>>> }
>>>
>>> -static void stk1160_reset_ac97(struct snd_ac97 *ac97)
>>> +void stk1160_ac97_dump_regs(struct stk1160 *dev)
>>
>> static void stk1160_ac97_dump_regs ?
>>
>
> Right, this was just to test the issue addressed in the last patch
> that I submitted separately. I didn't know at that point, whether the
> issue was with writing or reading the registers, or both. This can of
> course be removed, since it's not really needed for anything anymore.
>
I'm not opposed to keeping the dump. Remove it if you think
it's useless, or keep it if you think it has debugging value.
I'm fine either way.
--
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.
Re: [PATCH] stk1160: Give the chip some time to retrieve data from AC97 codec.
2016-11-20 18:37 GMT+01:00 Ezequiel Garcia : > On 28 October 2016 at 05:52, Marcel Hasler wrote: >> The STK1160 needs some time to transfer data from the AC97 registers into >> its own. On some >> systems reading the chip's own registers to soon will return wrong values. >> The "proper" way to >> handle this would be to poll STK1160_AC97CTL_0 after every read or write >> command until the >> command bit has been cleared, but this may not be worth the hassle. >> >> Signed-off-by: Marcel Hasler >> --- >> drivers/media/usb/stk1160/stk1160-ac97.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c >> b/drivers/media/usb/stk1160/stk1160-ac97.c >> index 31bdd60d..caa65a8 100644 >> --- a/drivers/media/usb/stk1160/stk1160-ac97.c >> +++ b/drivers/media/usb/stk1160/stk1160-ac97.c >> @@ -20,6 +20,7 @@ >> * >> */ >> >> +#include >> #include >> >> #include "stk1160.h" >> @@ -61,6 +62,9 @@ static u16 stk1160_read_ac97(struct stk1160 *dev, u16 reg) >> */ >> stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x8b); >> >> + /* Give the chip some time to transfer data */ >> + usleep_range(20, 40); >> + > > I don't recall any issues with this. In any case, we only read the registers > for debugging purposes, so it's not a big deal. > I actually just re-tested this, as I recently replaced my computer's main board. I didn't happen with my old one, but it does with my new one, just as with both of my notebooks. > Maybe it would be better to expand the comment a little bit, > using your commit log: > > "" > The "proper" way to > handle this would be to poll STK1160_AC97CTL_0 after > every read or write command until the command bit > has been cleared, but this may not be worth the hassle. > "" > > This way, if the sleep proves problematic in the future, > the "proper way" is already documented. > >> /* Retrieve register value */ >> stk1160_read_reg(dev, STK1160_AC97_CMD, &vall); >> stk1160_read_reg(dev, STK1160_AC97_CMD + 1, &valh); >> -- >> 2.10.1 >> > > > > -- > Ezequiel García, VanguardiaSur > www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] stk1160: Give the chip some time to retrieve data from AC97 codec.
2016-11-20 18:37 GMT+01:00 Ezequiel Garcia : > On 28 October 2016 at 05:52, Marcel Hasler wrote: >> The STK1160 needs some time to transfer data from the AC97 registers into >> its own. On some >> systems reading the chip's own registers to soon will return wrong values. >> The "proper" way to >> handle this would be to poll STK1160_AC97CTL_0 after every read or write >> command until the >> command bit has been cleared, but this may not be worth the hassle. >> >> Signed-off-by: Marcel Hasler >> --- >> drivers/media/usb/stk1160/stk1160-ac97.c | 4 >> 1 file changed, 4 insertions(+) >> >> diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c >> b/drivers/media/usb/stk1160/stk1160-ac97.c >> index 31bdd60d..caa65a8 100644 >> --- a/drivers/media/usb/stk1160/stk1160-ac97.c >> +++ b/drivers/media/usb/stk1160/stk1160-ac97.c >> @@ -20,6 +20,7 @@ >> * >> */ >> >> +#include >> #include >> >> #include "stk1160.h" >> @@ -61,6 +62,9 @@ static u16 stk1160_read_ac97(struct stk1160 *dev, u16 reg) >> */ >> stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x8b); >> >> + /* Give the chip some time to transfer data */ >> + usleep_range(20, 40); >> + > > I don't recall any issues with this. In any case, we only read the registers > for debugging purposes, so it's not a big deal. > > Maybe it would be better to expand the comment a little bit, > using your commit log: > > "" > The "proper" way to > handle this would be to poll STK1160_AC97CTL_0 after > every read or write command until the command bit > has been cleared, but this may not be worth the hassle. > "" > > This way, if the sleep proves problematic in the future, > the "proper way" is already documented. > Of course, since the register dump isn't needed anymore, this function could also be dropped. But then again, I think it would make sense to keep it, even if it's just for documentation. There might be use for it in the future. I'll add a comment as suggested. Let me know whether I should remove the dump, I guess there's no need to keep it. I'll then prepare a new patchset with all four patches as soon as I can. >> /* Retrieve register value */ >> stk1160_read_reg(dev, STK1160_AC97_CMD, &vall); >> stk1160_read_reg(dev, STK1160_AC97_CMD + 1, &valh); >> -- >> 2.10.1 >> > > > > -- > Ezequiel García, VanguardiaSur > www.vanguardiasur.com.ar Best regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] stk1160: Add module param for setting the record gain.
2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
> On 27 October 2016 at 17:35, Marcel Hasler wrote:
>> Allow setting a custom record gain for the internal AC97 codec (if
>> available). This can be
>> a value between 0 and 15, 8 is the default and should be suitable for most
>> users. The Windows
>> driver also sets this to 8 without any possibility for changing it.
>>
>> Signed-off-by: Marcel Hasler
>> ---
>> drivers/media/usb/stk1160/stk1160-ac97.c | 11 ++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c
>> b/drivers/media/usb/stk1160/stk1160-ac97.c
>> index 6dbc39f..31bdd60d 100644
>> --- a/drivers/media/usb/stk1160/stk1160-ac97.c
>> +++ b/drivers/media/usb/stk1160/stk1160-ac97.c
>> @@ -25,6 +25,11 @@
>> #include "stk1160.h"
>> #include "stk1160-reg.h"
>>
>> +static u8 gain = 8;
>> +
>> +module_param(gain, byte, 0444);
>> +MODULE_PARM_DESC(gain, "Set capture gain level if AC97 codec is available
>> (0-15, default: 8)");
>> +
>> static void stk1160_write_ac97(struct stk1160 *dev, u16 reg, u16 value)
>> {
>> /* Set codec register address */
>> @@ -122,7 +127,11 @@ void stk1160_ac97_setup(struct stk1160 *dev)
>> stk1160_write_ac97(dev, 0x16, 0x0808); /* Aux volume */
>> stk1160_write_ac97(dev, 0x1a, 0x0404); /* Record select */
>> stk1160_write_ac97(dev, 0x02, 0x); /* Master volume */
>> - stk1160_write_ac97(dev, 0x1c, 0x0808); /* Record gain */
>> +
>> + /* Record gain */
>> + gain = (gain > 15) ? 15 : gain;
>> + stk1160_info("Setting capture gain to %d.", gain);
>
> This message doesn't add anything useful, can we drop it?
>
I think it would make sense to have some kind of feedback, at least
when the default value has been overridden. How about making this
conditional?
>> + stk1160_write_ac97(dev, 0x1c, (gain<<8) | gain);
>>
>> #ifdef DEBUG
>> stk1160_ac97_dump_regs(dev);
>> --
>> 2.10.1
>>
>
>
>
> --
> Ezequiel García, VanguardiaSur
> www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] stk1160: Check whether to use AC97 codec or internal ADC.
2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
> On 27 October 2016 at 17:34, Marcel Hasler wrote:
>> Some STK1160-based devices use the chip's internal 8-bit ADC. This is
>> configured through a strap
>> pin. The value of this and other pins can be read through the POSVA
>> register. If the internal
>> ADC is used, there's no point trying to setup the unavailable AC97 codec.
>>
>> Signed-off-by: Marcel Hasler
>> ---
>> drivers/media/usb/stk1160/stk1160-ac97.c | 15 +++
>> drivers/media/usb/stk1160/stk1160-core.c | 3 +--
>> drivers/media/usb/stk1160/stk1160-reg.h | 3 +++
>> 3 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c
>> b/drivers/media/usb/stk1160/stk1160-ac97.c
>> index d3665ce..6dbc39f 100644
>> --- a/drivers/media/usb/stk1160/stk1160-ac97.c
>> +++ b/drivers/media/usb/stk1160/stk1160-ac97.c
>> @@ -90,8 +90,23 @@ void stk1160_ac97_dump_regs(struct stk1160 *dev)
>> }
>> #endif
>>
>> +int stk1160_has_ac97(struct stk1160 *dev)
>> +{
>> + u8 value;
>> +
>> + stk1160_read_reg(dev, STK1160_POSVA, &value);
>> +
>> + /* Bit 2 high means internal ADC */
>> + return !(value & 0x04);
>
> How about define a macro such as:
>
> diff --git a/drivers/media/usb/stk1160/stk1160-reg.h
> b/drivers/media/usb/stk1160/stk1160-reg.h
> index a4ab586fcee1..4922249d7d34 100644
> --- a/drivers/media/usb/stk1160/stk1160-reg.h
> +++ b/drivers/media/usb/stk1160/stk1160-reg.h
> @@ -28,6 +28,7 @@
>
> /* Power-on Strapping Data */
> #define STK1160_POSVA 0x010
> +#define STK1160_POSVA_ACSYNC BIT(2)
>
Good idea, I'll do that.
> Also, the spec mentions another POSVA bit relevant
> to audio ACDOUT. Should we check that too?
>
Yes, that would make sense.
>> +}
>> +
>> void stk1160_ac97_setup(struct stk1160 *dev)
>> {
>> + if (!stk1160_has_ac97(dev)) {
>> + stk1160_info("Device uses internal 8-bit ADC, skipping AC97
>> setup.");
>> + return;
>> + }
>> +
>> /* Two-step reset AC97 interface and hardware codec */
>> stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x94);
>> stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x8c);
>> diff --git a/drivers/media/usb/stk1160/stk1160-core.c
>> b/drivers/media/usb/stk1160/stk1160-core.c
>> index f3c9b8a..c86eb61 100644
>> --- a/drivers/media/usb/stk1160/stk1160-core.c
>> +++ b/drivers/media/usb/stk1160/stk1160-core.c
>> @@ -20,8 +20,7 @@
>> *
>> * TODO:
>> *
>> - * 1. (Try to) detect if we must register ac97 mixer
>> - * 2. Support stream at lower speed: lower frame rate or lower frame size.
>> + * 1. Support stream at lower speed: lower frame rate or lower frame size.
>> *
>> */
>>
>> diff --git a/drivers/media/usb/stk1160/stk1160-reg.h
>> b/drivers/media/usb/stk1160/stk1160-reg.h
>> index 81ff3a1..a4ab586 100644
>> --- a/drivers/media/usb/stk1160/stk1160-reg.h
>> +++ b/drivers/media/usb/stk1160/stk1160-reg.h
>> @@ -26,6 +26,9 @@
>> /* Remote Wakup Control */
>> #define STK1160_RMCTL 0x00c
>>
>> +/* Power-on Strapping Data */
>> +#define STK1160_POSVA 0x010
>> +
>> /*
>> * Decoder Control Register:
>> * This byte controls capture start/stop
>> --
>> 2.10.1
>>
>
>
>
> --
> Ezequiel García, VanguardiaSur
> www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] stk1160: Remove stk1160-mixer and setup internal AC97 codec automatically.
Hello, and thanks for your feedback.
2016-11-20 18:36 GMT+01:00 Ezequiel Garcia :
> Marcel,
>
> On 27 October 2016 at 17:34, Marcel Hasler wrote:
>> Exposing all the channels of the device's internal AC97 codec to userspace
>> is unnecessary and
>> confusing. Instead the driver should setup the codec with proper values.
>> This patch removes the
>> mixer and sets up the codec using optimal values, i.e. the same values set
>> by the Windows
>> driver. This also makes the device work out-of-the-box, without the need for
>> the user to
>> reconfigure the device every time it's plugged in.
>>
>> Signed-off-by: Marcel Hasler
>
> This patch is *awesome*.
>
> You've re-written the file ;-), so if you want to put your
> copyright on stk1160-ac97.c, be my guest.
>
Thanks, will do :-)
> Also, just a minor comment, see below.
>
>> ---
>> drivers/media/usb/stk1160/Kconfig| 10 +--
>> drivers/media/usb/stk1160/Makefile | 4 +-
>> drivers/media/usb/stk1160/stk1160-ac97.c | 121
>> +++
>> drivers/media/usb/stk1160/stk1160-core.c | 5 +-
>> drivers/media/usb/stk1160/stk1160.h | 9 +--
>> 5 files changed, 47 insertions(+), 102 deletions(-)
>>
>> diff --git a/drivers/media/usb/stk1160/Kconfig
>> b/drivers/media/usb/stk1160/Kconfig
>> index 95584c1..22dff4f 100644
>> --- a/drivers/media/usb/stk1160/Kconfig
>> +++ b/drivers/media/usb/stk1160/Kconfig
>> @@ -8,17 +8,9 @@ config VIDEO_STK1160_COMMON
>> To compile this driver as a module, choose M here: the
>> module will be called stk1160
>>
>> -config VIDEO_STK1160_AC97
>> - bool "STK1160 AC97 codec support"
>> - depends on VIDEO_STK1160_COMMON && SND
>> -
>> - ---help---
>> - Enables AC97 codec support for stk1160 driver.
>> -
>> config VIDEO_STK1160
>> tristate
>> - depends on (!VIDEO_STK1160_AC97 || (SND='n') || SND) &&
>> VIDEO_STK1160_COMMON
>> + depends on VIDEO_STK1160_COMMON
>> default y
>> select VIDEOBUF2_VMALLOC
>> select VIDEO_SAA711X
>> - select SND_AC97_CODEC if SND
>> diff --git a/drivers/media/usb/stk1160/Makefile
>> b/drivers/media/usb/stk1160/Makefile
>> index dfe3e90..42d0546 100644
>> --- a/drivers/media/usb/stk1160/Makefile
>> +++ b/drivers/media/usb/stk1160/Makefile
>> @@ -1,10 +1,8 @@
>> -obj-stk1160-ac97-$(CONFIG_VIDEO_STK1160_AC97) := stk1160-ac97.o
>> -
>> stk1160-y := stk1160-core.o \
>> stk1160-v4l.o \
>> stk1160-video.o \
>> stk1160-i2c.o \
>> - $(obj-stk1160-ac97-y)
>> + stk1160-ac97.o
>>
>> obj-$(CONFIG_VIDEO_STK1160) += stk1160.o
>>
>> diff --git a/drivers/media/usb/stk1160/stk1160-ac97.c
>> b/drivers/media/usb/stk1160/stk1160-ac97.c
>> index 2dd308f..d3665ce 100644
>> --- a/drivers/media/usb/stk1160/stk1160-ac97.c
>> +++ b/drivers/media/usb/stk1160/stk1160-ac97.c
>> @@ -21,19 +21,12 @@
>> */
>>
>> #include
>> -#include
>> -#include
>> -#include
>>
>> #include "stk1160.h"
>> #include "stk1160-reg.h"
>>
>> -static struct snd_ac97 *stk1160_ac97;
>> -
>> -static void stk1160_write_ac97(struct snd_ac97 *ac97, u16 reg, u16 value)
>> +static void stk1160_write_ac97(struct stk1160 *dev, u16 reg, u16 value)
>> {
>> - struct stk1160 *dev = ac97->private_data;
>> -
>> /* Set codec register address */
>> stk1160_write_reg(dev, STK1160_AC97_ADDR, reg);
>>
>> @@ -48,9 +41,9 @@ static void stk1160_write_ac97(struct snd_ac97 *ac97, u16
>> reg, u16 value)
>> stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x8c);
>> }
>>
>> -static u16 stk1160_read_ac97(struct snd_ac97 *ac97, u16 reg)
>> +#ifdef DEBUG
>> +static u16 stk1160_read_ac97(struct stk1160 *dev, u16 reg)
>> {
>> - struct stk1160 *dev = ac97->private_data;
>> u8 vall = 0;
>> u8 valh = 0;
>>
>> @@ -70,81 +63,53 @@ static u16 stk1160_read_ac97(struct snd_ac97 *ac97, u16
>> reg)
>> return (valh << 8) | vall;
>> }
>>
>> -static void stk1160_reset_ac97(struct snd_ac97 *ac97)
>> +void stk1160_ac97_dump_regs(struct stk1160 *dev)
>
> static void stk1160_ac97_dump_regs ?
>
Right, this was just to test the issue addressed in the last patch
that I submitted separately. I didn't know at that point, whether the
issue was with writing or reading the registers, or both. This can of
course be removed, since it's not really needed for anything anymore.
>> {
>> - struct stk1160 *dev = ac97->private_data;
>> - /* Two-step reset AC97 interface and hardware codec */
>> - stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x94);
>> - stk1160_write_reg(dev, STK1160_AC97CTL_0, 0x88);
>> + u16 value;
>>
>> - /* Set 16-bit audio data and choose L&R channel*/
>> - stk1160_write_reg(dev, STK1160_AC97CTL_1 + 2, 0x01);
>> -}
>> + value = stk1160_read_ac97(dev, 0x12); /* CD volume */
>> + stk1160_dbg("0x12 == 0x%04x", value);
>>
>> -static struct snd_ac97_bus_ops stk1160_ac97_ops
Re: [RFC] v4l2 support for thermopile devices
Hi! > So want to toss a few thoughts on adding support for thermopile > devices (could be used for FLIR Lepton as well) that output pixel > data. > These typically aren't DMA'able devices since they are low speed > (partly to limiting the functionality to be in compliance with ITAR) > and data is piped over i2c/spi. > > My question is that there doesn't seem to be an other driver that > polls frames off of a device and pushes it to the video buffer, and > wanted to be sure that this doesn't currently exist somewhere. > > Also more importantly does the mailing list thinks it belongs in v4l2? > We already came up the opinion on the IIO list that it doesn't belong > in that subsystem since pushing raw pixel data to a buffer is a bit > hacky. Also could be generically written with regmap so other devices > (namely FLIR Lepton) could be easily supported. > > Need some input for the video pixel data types, which the device we > are using (see datasheet links below) is outputting pixel data in > little endian 16-bit of which a 12-bits signed value is used. Does it > make sense to do some basic processing on the data since greyscale is > going to look weird with temperatures under 0C degrees? Namely a cold > object is going to be brighter than the hottest object it could read. > Or should a new V4L2_PIX_FMT_* be defined and processing done in > software? Another issue is how to report the scaling value of 0.25 C > for each LSB of the pixels to the respecting recording application. Should we get some kind of flag saying "this is deep infrared"? Most software won't care, but it would be nice to have enough information so that userspace can do the right thing automatically... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [bug report] [media] lirc: prevent use-after free
Hi Dan,
On Sat, Nov 26, 2016 at 12:57:17PM +0300, Dan Carpenter wrote:
> Hello Sean Young,
>
> The patch afbb110172b9: "[media] lirc: prevent use-after free" from
> Oct 31, 2016, leads to the following static checker warning:
>
> drivers/media/rc/lirc_dev.c:190 lirc_cdev_add()
> error: potential null dereference 'cdev'. (cdev_alloc returns null)
>
> drivers/media/rc/lirc_dev.c
>158 static int lirc_cdev_add(struct irctl *ir)
>159 {
>160 int retval = -ENOMEM;
>161 struct lirc_driver *d = &ir->d;
>162 struct cdev *cdev;
>163
>164 cdev = cdev_alloc();
>165 if (!cdev)
>166 goto err_out;
>
> Classic one err bug. Just return directly here. return -ENOMEM is 100%
> readable but goto err_out is opaque because you first have to scroll
> down to see what err_out does then you have to scroll to the start of
> the function to verify that retval is set.
>
>167
>168 if (d->fops) {
>169 cdev->ops = d->fops;
>170 cdev->owner = d->owner;
>171 } else {
>172 cdev->ops = &lirc_dev_fops;
>173 cdev->owner = THIS_MODULE;
>174 }
>175 retval = kobject_set_name(&cdev->kobj, "lirc%d", d->minor);
>176 if (retval)
>177 goto err_out;
>178
>179 retval = cdev_add(cdev, MKDEV(MAJOR(lirc_base_dev),
> d->minor), 1);
>180 if (retval) {
>181 kobject_put(&cdev->kobj);
>
> This is a double free, isn't it? It should just be goto del_cdev;
>
>182 goto err_out;
>183 }
>184
>185 ir->cdev = cdev;
>186
>187 return 0;
>188
>189 err_out:
>190 cdev_del(cdev);
>
> Can't pass NULLs to this function.
>
>191 return retval;
>192 }
Oh dear! Thanks for reporting this, you're absolutely right. I'll send
out a patch shortly.
Thanks
Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[bug report] [media] lirc: prevent use-after free
Hello Sean Young,
The patch afbb110172b9: "[media] lirc: prevent use-after free" from
Oct 31, 2016, leads to the following static checker warning:
drivers/media/rc/lirc_dev.c:190 lirc_cdev_add()
error: potential null dereference 'cdev'. (cdev_alloc returns null)
drivers/media/rc/lirc_dev.c
158 static int lirc_cdev_add(struct irctl *ir)
159 {
160 int retval = -ENOMEM;
161 struct lirc_driver *d = &ir->d;
162 struct cdev *cdev;
163
164 cdev = cdev_alloc();
165 if (!cdev)
166 goto err_out;
Classic one err bug. Just return directly here. return -ENOMEM is 100%
readable but goto err_out is opaque because you first have to scroll
down to see what err_out does then you have to scroll to the start of
the function to verify that retval is set.
167
168 if (d->fops) {
169 cdev->ops = d->fops;
170 cdev->owner = d->owner;
171 } else {
172 cdev->ops = &lirc_dev_fops;
173 cdev->owner = THIS_MODULE;
174 }
175 retval = kobject_set_name(&cdev->kobj, "lirc%d", d->minor);
176 if (retval)
177 goto err_out;
178
179 retval = cdev_add(cdev, MKDEV(MAJOR(lirc_base_dev), d->minor),
1);
180 if (retval) {
181 kobject_put(&cdev->kobj);
This is a double free, isn't it? It should just be goto del_cdev;
182 goto err_out;
183 }
184
185 ir->cdev = cdev;
186
187 return 0;
188
189 err_out:
190 cdev_del(cdev);
Can't pass NULLs to this function.
191 return retval;
192 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
