Pull vfs fixes from Al Viro:
"A fs-cache regression fix, and adding a warning about obnoxiou^W
moderation of list given in MAINTAINERS"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
MAINTAINERS: linux-cachefs@redhat.com is moderated for non-subscribers
FS-Cache: Add missing initialization of ret in cachefiles_write_page()
These v4l2_ctrl_ops structures are never modified, like all the other
v4l2_ctrl_ops structures, so declare them as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Pull crypto fix from Herbert Xu:
"This fixes a bug in the qat driver where a user-space pointer is
dereferenced"
* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: qat - don't use userspace pointer
Following changes that appeared in lk 4.0.0, the gadget udc driver for
some ARM based Atmel SoCs (e.g. at91sam9x5 and sama5d3 families)
incorrectly deduced full-speed USB link speed even when the hardware
had negotiated a high-speed link. The fix is to make sure that the
UDPHS Interrupt Enable Register value does not mask the SPEED bit
in the Interrupt Status Register.
For a mass storage gadget this problem lead to failures when the host
had a USB 3 port with the xhci_hcd driver. If the host was a USB 2
port using the ehci_hcd driver then the mass storage gadget worked
(but probably at a lower speed than it should have).
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: <stable@vger.kernel.org> #4.0+
Fixes: 9870d895ad ("usb: atmel_usba_udc: Mask status with enabled irqs")
Signed-off-by: Felipe Balbi <balbi@ti.com>
Change the permission of usb_dma parameter so it can
be used for runtime debug without reboot.
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
of_match_device could return NULL, and so cause a NULL pointer
dereference later.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In some SoCs, dwc3 is implemented as a USB2.0 only
core, meaning that it can't ever achieve SuperSpeed.
Currect driver always sets gadget.max_speed to
USB_SPEED_SUPER unconditionally. This can causes
issues to some Host stacks where the host will issue
a GetBOS() request and we will reply with a BOS
containing Superspeed Capability Descriptor.
At least Windows seems to be upset by this fact and
prints a warning that we should connect $this device
to another port.
[ balbi@ti.com : rewrote entire commit, including
source code comment to make a lot clearer what the
problem is ]
Cc: <stable@vger.kernel.org>
Signed-off-by: Ben McCauley <ben.mccauley@garmin.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Here are a few changes in musb_h_tx_flush_fifo().
- It has been observed that sometimes (if not always) musb is unable
to flush tx fifo during urb dequeue when disconnect a device. But
it seems to be harmless, since the tx fifo flush is done again in
musb_ep_program() when re-use the hw_ep.
But the WARN() floods the console in the case when multiple tx urbs
are queued, so change it to dev_WARN_ONCE().
- applications could queue up many tx urbs, then the 1ms delay could
causes minutes of delay in device disconnect. So remove it to get
better user experience. The 1ms delay does not help the flushing
anyway.
- cleanup the debug code - related to lastcsr.
----
Note: The tx fifo flush issue has been observed during device disconnect
on AM335x.
To reproduce the issue, ensure tx urb(s) are queued when unplug the usb
device which is connected to AM335x usb host port.
I found using a usb-ethernet device and running iperf (client on AM335x)
has very high chance to trigger the problem.
Better to turn on dev_dbg() in musb_cleanup_urb() with CPPI enabled to
see the issue when aborting the tx channel.
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
In commit 734643dfbd ("usb: dwc2: host: add flag to reflect bus
state") we changed dwc2_port_suspend() not to set the lx_state
anymore (instead it sets the new bus_suspended variable). This
introduced a bug where we would fail to detect device insertions if:
1. Plug empty hub into dwc2
2. Plug USB flash drive into the empty hub.
3. Wait a few seconds
4. Unplug USB flash drive
5. Less than 2 seconds after step 4, plug the USB flash drive in again.
The dwc2_hcd_rem_wakeup() function should have been changed to look at
the new bus_suspended variable.
Let's fix it. Since commit b46146d59f ("usb: dwc2: host: resume root
hub on remote wakeup") talks about needing the root hub resumed if the
bus was suspended, we'll include it in our test.
It appears that the "port_l1_change" should only be set to 1 if we were
in DWC2_L1 (the driver currently never sets this), so we'll update the
former "else" case based on this test.
Fixes: 734643dfbd ("usb: dwc2: host: add flag to reflect bus state")
Acked-by: John Youn <johnyoun@synopsys.com>
Tested-by: Gregory Herrero <gregory.herrero@intel.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The preview path only can convert UYVY format to RGB data.
To make preview path work correctly, we need to set up YCC_SWAP
according to sensor output and convert them to UYVY.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The comment for ahbcfg for rk3066 parameters (also used for rk3288)
claimed that ahbcfg was INCR16, but it wasn't. Since the bits weren't
shifted properly, the 0x7 ended up being masked and we ended up
programming 0x3 for the HBstLen. Let's set it to INCR16 properly.
As per Wu Liang Feng at Rockchip this may increase transmission
efficiency. I did blackbox tests with writing 0s to a USB-based SD
reader (forcefully capping CPU Freq to try to measure efficiency):
cd /sys/devices/system/cpu/cpu0/cpufreq
echo userspace > scaling_governor
echo 126000 > scaling_setspeed
for i in $(seq 10); do
dd if=/dev/zero of=/dev/sdb bs=1M count=750
done
With the above tests I found that speeds went from ~15MB/s to ~18MB/s.
Note that most other tests I did (including reading from the same USB
reader) didn't show any difference in performance.
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: John Youn <johnyoun@synopsys.com>
Reviewed-by: Liangfeng Wu <wulf@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Not like codec path, preview path can do downsampling, so we should setup
a extra preview width, height for it.
This patch add preview resolution setup without down sampling. So currently
preview path will output same size as sensor output size.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Atmel ISI support a preview path which can output RGB data.
So this patch introduces a bool variable to choose which path is
enabled currently. And also we need setup corresponding path registers.
By default the preview path is disabled. We only use Codec path.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
we need to configure the YCC_SWAP bits in ISI_CFG2 according to current
sensor output and Atmel ISI output format.
Current there are two cases Atmel ISI supported:
1. Atmel ISI outputs YUYV format.
This case we need to setup YCC_SWAP according to sensor output
format.
2. Atmel ISI output a pass-through formats, which means no swap.
Just setup YCC_SWAP as default with no swap.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The soc-camera host will be probed and register a v4l2_clk, but if at
that moment, the i2c device is not available, then the registered
v4l2_clk name is an OF string not a I2C string.
So when i2c sensor probes and calls v4l2_clk_get(), it only searches a
clock with I2C string, like "1-0030".
This patch will search the clock with OF string name if no clock with
I2C string name could be found.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Make all v4l2-clk's clock name use V4L2_CLK_NAME_SIZE definition.
In future, if the string is increased we just need to change the
V4L2_CLK_NAME_SIZE once.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This macro is used to generate an OF string for a v4l2 clock.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The function graph tracer adds instrumentation that is required to trace
both entry and exit of a function. In particular the function graph
tracer updates the "return address" of a function in order to insert
a trace callback on function exit.
Kernel power management functions like cpu_suspend() are called
upon power down entry with functions called "finishers" that are in turn
called to trigger the power down sequence but they may not return to the
kernel through the normal return path.
When the core resumes from low-power it returns to the cpu_suspend()
function through the cpu_resume path, which leaves the trace stack frame
set-up by the function tracer in an incosistent state upon return to the
kernel when tracing is enabled.
This patch fixes the issue by pausing/resuming the function graph
tracer on the thread executing cpu_suspend() (ie the function call that
subsequently triggers the "suspend finishers"), so that the function graph
tracer state is kept consistent across functions that enter power down
states and never return by effectively disabling graph tracer while they
are executing.
Fixes: 819e50e25d ("arm64: Add ftrace support")
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: <stable@vger.kernel.org> # 3.16+
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
With this patch, vivid capture thread can now generate a video with
frame rate reduced by a factor of 1000 / 1001. This option can be
selected using a control Reduced Framerate from gui.
Signed-off-by: Prashant Laddha <prladdha@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
A boolean control Reduced Framerate is added to vivid controls for
controlling the reduced fps option for vivid capture from gui.
Signed-off-by: Prashant Laddha <prladdha@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
If reduced fps flag is set then check if other necessary conditions
are true for the given bt timing. If yes, then reduce the frame rate.
For vivid transmitter, timeperframe_vid_out controls the frame rate.
Adjusting the timeperframe_vid_out by scaling down pixel clock by
factor of 1000 / 1001.
Signed-off-by: Prashant Laddha <prladdha@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Added a helper function to check necessary conditions required for
reduced fps. The reduced fps is supported for CVT and CEA861 timings.
CVT supports reduced fps only if reduced blanking v2 (indicated by
vsync = 8) is true. Whereas CEA861 supports reduced fps if
V4L2_DV_FL_CAN_REDUCE_FPS flag is true.
Signed-off-by: Prashant Laddha <prladdha@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
When a V4L2 sub-device backed by a DT or ACPI based device was removed,
the device was unregistered as well which certainly was not intentional,
as the client device would not be re-created by simply reinstating the
V4L2 sub-device (indeed the device would have to be there first!).
Skip unregistering the device in case it has non-NULL of_node or fwnode.
Signed-off-by: Tommi Franttila <tommi.franttila@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Initialization of the ADV7180 chip fails on the Renesas R8A7790-based
Lager board about 50% of the time. This patch resolves the issue by
increasing the minimum delay after reset from 2 ms to 5 ms, following the
recommendation in the ADV7180 datasheet:
"Executing a software reset takes approximately 2 ms. However, it is
recommended to wait 5 ms before any further I2C writes are performed."
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This fixes the crash reported in:
http://seclists.org/bugtraq/2015/Oct/35
The interface number needs a sanity check.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Cc: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The sh-vou driver has been converted from videobuf to videobuf2, but
the Kconfig file still lists VIDEOBUF_DMA_CONTIG as a dependency.
Consequently we can build the driver without VIDEOBUF2_DMA_CONTIG
and get a link error:
drivers/built-in.o: In function `sh_vou_probe':
vf610-ocotp.c:(.text+0x2dbf5c): undefined reference to `vb2_dma_contig_init_ctx'
vf610-ocotp.c:(.text+0x2dc0b4): undefined reference to `vb2_dma_contig_cleanup_ctx'
vf610-ocotp.c:(.text+0x2dc144): undefined reference to `vb2_dma_contig_memops'
drivers/built-in.o: In function `sh_vou_remove':
vf610-ocotp.c:(.text+0x2dc190): undefined reference to `vb2_dma_contig_cleanup_ctx'
This changes the dependency to VIDEOBUF2_DMA_CONTIG instead.
Fixes: 57af3ad59d ("[media] sh-vou: convert to vb2")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
cpia2_usb_disconnect() seems to be missing a memory barrier which might
cause the waker to not notice the waiter and miss sending a wake_up as
in the following figure.
cpia2_usb_disconnect sync
------------------------------------------------------------------------
mutex_unlock(&cam->v4l2_lock);
if (waitqueue_active(&cam->wq_stream))
/* The CPU might reorder the test for
the waitqueue up here, before
prior writes complete */
/* wait_event_interruptible */
/* __wait_event_interruptible */
/* ___wait_event */
long __int = prepare_to_wait_event(
&wq, &__wait, state);
if (!cam->streaming ||
frame->status == FRAME_READY)
cam->curbuff->status = FRAME_READY;
cam->curbuff->length = 0;
schedule()
------------------------------------------------------------------------
The attached patch removes the call to waitqueue_active() leaving just
wake_up() behind. This fixes the problem because the call to
spin_lock_irqsave() in wake_up() will be an ACQUIRE operation.
I found this issue when I was looking through the linux source code
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The current cx231xx driver doesn't work with bulk transfer mode.
This patch makes it possible to use bulk transfer mode.
Signed-off-by: Terry Heo <terryheo@google.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The radio_tea5777_ops structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Vidioc-g-ext-ctrls can now be used to get the default value of the
controls.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This driver does not use the control infrastructure.
Add support for the new field which on structure
v4l2_ext_controls
Acked-by: Mike Isely <isely@pobox.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This driver does not use the control infrastructure.
Add support for the new field which on structure
v4l2_ext_controls
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Support for new field which on v4l2_ext_controls, used to get the
default value of one or more controls.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Replace the obsolete field ctrl_class with "which".
Make sure it not used in future modules by commenting out the field with
ifndef __KERNEL_ .
The field cannot be simply removed because that would be change on the
kenel API to the userspace (and we don't like that).
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
So it can be used to get the default value of a control.
Without this change it is not possible to get the
default value of array controls.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The quantization bits are in bits 7-6, not 7-4, so shift by 6 instead of 4.
This bug is caused by a typo in the adv7511 datasheet.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
hsync and hbackporch must also be compared
Signed-off-by: Mats Randgaard <matrandg@cisco.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
If modify_range is called but no range is changed, do not send the
CH_RANGE event.
Reported-by: Dimitrios Katsaros <patcherwork@gmail.com>
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
"len" comes from dvb_video_ioctl() and there is a possibility that it is
zero. We do a divide by len later in the function so that's not ok.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The issue here is that we there is a static checker warning because we
have a user controlled volume setting and we cap the upper bound but we
allow negative numbers. Negative volumes don't make sense, so let's
make these variables unsigned.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
In the 3.17 kernel the poll() behavior changed for output streams:
as long as not all buffers were queued up poll() would return that
userspace can write. This is fine for the write() call, but when
using stream I/O this changed the behavior since the expectation
was that it would wait for buffers to become available for dequeuing.
This patch only enables the check whether you can queue buffers
for file I/O only, and skips it for stream I/O.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: <stable@vger.kernel.org> # for v3.17 and up
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
If vivid is loaded with the no_error_inj=1 option, then v4l2-compliance will
fail for the video and vbi output nodes because the vivid control class has no
controls.
Don't add the control class for video and vbi output if no_error_inj is true.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The wrong flags field was tested for the GO7007_BOARD_HAS_AUDIO flag: that
flag is in board->main_info.flags, not in board->flags.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The term "input stream" is confusing since it is not clear whether this is an
input stream from the point of view of the application or from the point of
view of the hardware. So replace it with the more standard term "capture stream".
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The variable can take negative values.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
